dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 3 March 2010 17:23, John lewis <johnlewis.hisp@xxxxxxxxx> wrote:
> Ok bob, point taken. when you say facility+ unique string what do you mean.
> facility code or name of the facility and unique string is random number
> right?

yup.  and facility code is infinitely better than facility name.
Though its obviously useful for the patient to know the name.

>
> On Wed, Mar 3, 2010 at 6:11 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>>
>> Hi John
>>
>> On 3 March 2010 15:20, John lewis <johnlewis.hisp@xxxxxxxxx> wrote:
>> > Hi bob,
>> > the system generated ID is to one way to identify the case or person.
>> > using
>> > orgunit you mean the code for that organization unit. In india they have
>> > generated a 16 digit ID based on Country, Province,District,Sub-district
>> > and
>> > facility. but the problem with this is what happen if new district
>> > or province is created. In norway the personal id number is
>> > ddmmyy+sex+random number. I thougth we cloud use the same but increasing
>> > the
>> > random number to avoid the duplicate.
>>
>> I think this is a national id number.  In Norway they do indeed use
>> the national ID number as a patient ID.  And, believe it or not,
>> Norway does not follow best practice in this area.  They do it
>> probably because it was convenient and they started doing it at a time
>> before anyone really took much time to think about it.  The hazard of
>> early adoption in the information age.  They are not the only country
>> which now finds itself in this position.
>>
>> I've mentioned a few times on this list that national identifiers are
>> not always suitable for use as patient identifiers.  That they are
>> frequently coerced for this use is now broadly understood to be a
>> common but bad practice, largely because the requirements of national
>> ids are not generally the same as requirements for patient ids.  There
>> are a lot of references out there on what these requirements are - I
>> think myself and Saptarshi have provided some links to literature on
>> the subject.  Just googled this one fresh for example
>>
>> (http://books.google.com/books?id=X0JeKx8-J0cC&pg=PA59&lpg=PA59&dq=norway+patient+identifier&source=bl&ots=6C8eZlwxLb&sig=zTY4mpmxpNtvGGz-hssv3KVEQh8&hl=en&ei=F46OS7KHEJO7jAfZocDpAw&sa=X&oi=book_result&ct=result&resnum=5&ved=0CB8Q6AEwBA)
>> coz it mentions Norway - what a horrible url - and not a great
>> article.  You can I'm sure access better quality stuff through the
>> university.
>>
>> In the case of India, where they are now designing a national ID from
>> scratch, they might have taken this issue into account - ie they have
>> the benefit of hindsight that the identifier might (read it always
>> happens!) be used for many purposes beyond what may have been its
>> original intent.  So the ID could be useful if encoded on a card or
>> something, but the downside being that very few people are going to
>> memorize it if it has many random digits.  Alphanumerics can help keep
>> it shorter.
>>
>> I'm not sure if I get your concern about provinces and districts
>> changing etc.  Using a similar scheme but based on facility+unique
>> string a patient would only really need to commit to memory the unique
>> string part in 95% of cases.  She would only need the full number with
>> prefix part when visiting a different facility at which point it would
>> be useful to have the full number on a card, file or what have you.
>> But even then, if she remembered the facility that she got it from, it
>> could be reasonably reconstructed.
>>
>> I can sympathize with the desire for simplicity and I think we should
>> strive for a simple solution.  But given that is widely accepted that
>> encoding the birthdate and gender in a patient id is a bad practice I
>> don't think it is wise to roll-out a new personal identification
>> system like this.  To me it might indicate a certain amateurism and
>> lack of familiarity with the literature which could reflect badly on
>> the project.  Particularly as you are undergoing your security review.
>>  I also do know that the openmrs guys have really put a lot of thought
>> into this.
>>
>> So my warning would be if you go ahead with birthdates and gender you
>> should be prepared to be hammered from all sides.
>>
>> Cheers
>> Bob
>>
>> >And its also useful that the person
>> > dont have to remember all the 16 or 14 digit number. for the sake of
>> > simplicity we used this method.
>> > John
>> >
>> > On Wed, Mar 3, 2010 at 1:35 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>> > wrote:
>> >>
>> >> Hi
>> >>
>> >> On 3 March 2010 12:20, Viet Nguyen <phamquocviet@xxxxxxxxx> wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > Just a quick update about Patient registration form functionality :
>> >> >
>> >> > * Check duplicate :
>> >> >
>> >> > This function allow user to check for existing patient base on : name
>> >> > ,
>> >> > birthdate, age, gender
>> >> >
>> >> > If there is duplicate patient, a pop up will be showed, with the list
>> >> > of
>> >> > all
>> >> > the duplicated patients.
>> >> >
>> >> > From this pop up, user can have two options :
>> >> >
>> >> > Continue create the current patient. So there will be two patients
>> >> > with
>> >> > the
>> >> > same information like above. But their  identifiers must be different
>> >> > which
>> >> > will be checked later.
>> >> > User can choose a patient from the list duplicated patient to update
>> >> > information for him, by click on the button "Update this patient"
>> >> > that
>> >> > follow by each patient in the list. User will then be redirected to
>> >> > the
>> >> > Update Patient page.
>> >> >
>> >> > * Under age patient :
>> >> >
>> >> > Under age patient can be understand as a child. The purpose of this
>> >> > field is
>> >> > not to hard code the age to define a child, like  age < 5  or age <
>> >> > 15.
>> >> >
>> >> > In the registration form, there is a check box named " Is Underage" .
>> >> > User
>> >> > check on this check box to identify the patient is a child.  A pop up
>> >> > will
>> >> > be showed after clicking.
>> >> >
>> >> > The purpose of this pop up is :  user must choose a representative
>> >> > for
>> >> > this
>> >> > child.  Because , some  identifiers that are mandatory ( can be
>> >> > defined
>> >> > in
>> >> > Patient Identifier Type management page ) . But a child can not have
>> >> > those
>> >> > identifier, so we have to inherit those identifier from the child's
>> >> > representative.
>> >> >
>> >> > Not all identifier can be inherited, you can defined a
>> >> > PatientIdentiferType
>> >> > is able to inherit or not when creating it.  The field name is
>> >> > "Related"
>> >> > ... ( God ...why didn't I use" Inheritable" .... ) .
>> >> >
>> >> > If a PatientIdentifierType with "related" = FALSE and "mandatory" =
>> >> > TRUE
>> >> > then user must enter value for it.
>> >> >
>> >> > Ok, back to the popup, there are two tabs :
>> >> >
>> >> > Search existing person : user can search for an existing patient in
>> >> > system
>> >> > to be the representative of the child.
>> >> > Add new person : said this is person, because this is not really a
>> >> > patient,
>> >> > this person is just giving identifier...not enrolling to any program,
>> >> > at
>> >> > least at this step. Of course the record is also saved to the patient
>> >> > table.
>> >> > The form just only include basic information ( name , birthdate,
>> >> > gender.. )
>> >> > and Identifiers.  No attributes is needed. Of course  user can update
>> >> > attributes for this person later by the Update Patient page.
>> >> >
>> >> > One problem in this function that I can not have enough time to do :
>> >> >
>> >> > In the combo box Relationship Type, there should be Parent and
>> >> > Guardian,
>> >> > I
>> >> > hard coded this. You should create two relationship type  with this
>> >> > information before testing this function :
>> >> >
>> >> >    A is to B : Guardian, B is to A : Child
>> >> >    A is to B : Parent , B is to A : Child.
>> >> >
>> >> > The list of relationship type should be get from the Relationship
>> >> > type
>> >> > table. But if we put everything to the combo box, then user may
>> >> > choose
>> >> > Husband, Wife, or even child...which is so wrong.
>> >> >
>> >> > My plan is creating an object RelationshipGroup, which should be
>> >> > based
>> >> > on
>> >> > the age...
>> >> >
>> >> > Anyway, because we are late for releasing this version in India. so
>> >> > hard
>> >> > code for now is the only solution. I will continue working on this,
>> >> > so
>> >> > ...please don't worry...
>> >> >
>> >> > * System generated identifier :
>> >> >
>> >> > I looked at the id_gen module from OpenMRS. Well , they have a whole
>> >> > module
>> >> > for this which has many functionality for manage system auto
>> >> > generated
>> >> > identifier.
>> >> >
>> >> > I can not have enough time for getting all of that. So what I did is
>> >> > just
>> >> > get a piece of code that is used for generate a check digit for the
>> >> > ID.
>> >> >
>> >> > The format that Indian team chose is :
>> >> > [BirthDate][Gender][XXXXXX][checkdigit]
>> >>
>> >> Encoding the birthdate and gender into a patient identifier is
>> >> considered bad practice.  Using the orgunit+random digits would be
>> >> much better.  It shouldn't matter if the patient "migrates".  The
>> >> number was simply issued by a particular facility.
>> >>
>> >> Regards
>> >> Bob
>> >>
>> >> >
>> >> > BirthDate : yyyyMMdd
>> >> > Gender : Male  = 1 ; Female = 0
>> >> > XXXXXX : a random number  with length = 6   ( 0 - 999999 )
>> >> > checkdigit :  generated using Luhn Algorithm ( thanks to OpenMRS guys
>> >> > )
>> >> >
>> >> > I also changed the way that Abyot generate the birthdate from age (
>> >> > when
>> >> > user only enter age ) .
>> >> > It is :    todayCalendar.add( Calendar.YEAR, -1 * age );
>> >> > What Abyot did is
>> >> >           todayCalendar.set( Calendar.DATE, 1 );
>> >> >           todayCalendar.set( Calendar.MONTH, Calendar.JANUARY );
>> >> >           todayCalendar.add( Calendar.YEAR, -1 * age );
>> >> > Because we generate the id base on birthdate , get current date
>> >> > should
>> >> > be
>> >> > better.
>> >> > Hope this is ok for Abyot....
>> >> >
>> >> > Each country will have different formats...so I think for current we
>> >> > just
>> >> > can change code when implementing in the country. Building a module
>> >> > for
>> >> > this
>> >> > would take time....
>> >> >
>> >> > Finally,  but almost those things only follow India 's requirements.
>> >> > Please give comment then we can try to make it more generic...
>> >> >
>> >> > Regards,
>> >> >
>> >> > Viet Nguyen
>> >> >
>> >> >
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~dhis2-devs
>> >> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>> >> More help   : https://help.launchpad.net/ListHelp
>> >
>> >
>
>