← Back to team overview

dhis2-devs team mailing list archive

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