dhis2-devs team mailing list archive

[John lewis <johnlewis.hisp@xxxxxxxxx>]

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?

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
> >
> >
>