dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #04197
Re: Patient Identifier Management functions
Hi,
Is there some reason for not simply reusing what OpenMRS has done in this
area?
Seems like we are dealing with a lot of fundamental patient level issues
(not just in this thread) that I am sure have been discussed and taken care
of already in a mature and widely used application like OpenMRS.
Ola
----------
2010/2/4 Lars Helge Øverland <larshelge@xxxxxxxxx>
>
>
> 2010/2/1 Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>
>> 2010/2/1 Lars Helge Øverland <larshelge@xxxxxxxxx>
>>
>>>
>>>
>>> 2010/2/1 Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>>>
>>> you are taking about me? What silly names do we have in mind?
>>>>
>>>
>>> Yes. Just kidding, no silly names this time.
>>>
>>
>> Oh well. I guess we can always try silly indentifiers instead :-)
>>
>> We are going to implement system generated patient identifiers for the
>>> patient module.
>>>
>>> VN team has suggested:
>>>
>>> - Set of characters dependent on the organisation unit
>>> - Set of digits, include date and number of patients in the day.
>>>
>>> Viet has suggested an algorithm dependent on patient information and the
>>> time of creation.
>>>
>>> Jason has suggested an UUID.
>>>
>>> I think identifier for a person and identifier for a person's file are
>> subtley different. Patients may already have a number of personal
>> state-issued identifiers (hence the flexible identifier type). Many of
>> these might well provide the quality of uniqueness but not necessarily the
>> anonymity you would look for when for example tracking lab samples. But it
>> seems what you are looking at is the generation of a file number for the
>> patient. Like would be written on top of the cardboard folder in "real
>> life". In which case I would be tempted to follow the simplicity of the VN
>> team suggestion. Of course patients can migrate between org units which
>> needs to be taken into account. If privacy is more of a concern then this
>> information can instead be hashed, probably along similar lines to Viet's
>> algorithm.
>>
>> A few things to consider:
>> 1. there should be a check digit built in to the identifier
>> 2. regular expression validation can be useful
>> 3. if the identifier is meant to be human readable (and writable) as well
>> as machine readable then you don't want to go much over 8 characters
>> 4. before designing an identifier we should be very clear what the
>> identifier should be used for. There are lots of examples of "scope creep"
>> where identifiers primarily designed for social security, tax, national
>> identification etc are "repurposed" as health identifiers. Often they do
>> not have the required characteristics for this. So maybe that's the
>> starting point - what exactly can we say this identifier is to be used for
>> and not used for.
>>
>
> Hi Viet,
>
> what are your thoughts on this? Is the identifier meant to be human
> readable? What is the main purpose of the identifier?
>
> Lars
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> Post to : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> More help : https://help.launchpad.net/ListHelp
>
>
Follow ups
References