Greetings + new DHIS patient module

Support - Assistance technique
41

I agree depending on the uniqueness of names is not a good idea. I
saw John said that facilities in India do have codes - the 16 digit
ones which are built hierarchicly (is that a word?).

Is it possible to for a patient id to continue this hierarchy so that
a patient might have say a 6-8 digit local identifier - preferably
Base30 as I see Saptarshi has just chimed in. But his
"fully-qualified" id would be the 16 digit one + the local part. I
can see that generation and allocation of these might be problematic
and the internal uuid might be a good (if expensive) failsafe. How
does openmrs deal with this? Saptarshi, is at as you have suggested?
I would be a bit concerned that management of a pool of ids strikes me
as something which could easily fall apart. Isn't it better to
generate them on demand from some random source and test for
uniqueness before inserting into the database? If its not unique then
it simply tries another till its happy?

Bob

···

2010/3/4 Lars Helge Øverland <larshelge@gmail.com>:

Been chatting a bit with John and he expressed concern about the
orgunit-randomnumber apprach. In India there are multiple installations and
one cannot know for sure that an orgunit name will be unique. How do we deal
with this?
Using a globally unique identifier could be a solution, but the standard
Java implementation (UUID) uses 32 characters and is a bit long. Is
implementing our own, shorter one an option?

Lars

42

I agree depending on the uniqueness of names is not a good idea. I

saw John said that facilities in India do have codes - the 16 digit

ones which are built hierarchicly (is that a word?).

OK I wasn’t aware of this code… Certainly if we could generate a string based on the orgunit code plus its ancestors it will be unique. How does one generate a fixed-length alphanumeric string based on this sequence of names btw?

···

2010/3/4 Bob Jolliffe bobjolliffe@gmail.com

Is it possible to for a patient id to continue this hierarchy so that

a patient might have say a 6-8 digit local identifier - preferably

Base30 as I see Saptarshi has just chimed in. But his

“fully-qualified” id would be the 16 digit one + the local part. I

can see that generation and allocation of these might be problematic

and the internal uuid might be a good (if expensive) failsafe. How

does openmrs deal with this? Saptarshi, is at as you have suggested?

I would be a bit concerned that management of a pool of ids strikes me

as something which could easily fall apart. Isn’t it better to

generate them on demand from some random source and test for

uniqueness before inserting into the database? If its not unique then

it simply tries another till its happy?

Bob

2010/3/4 Lars Helge Øverland larshelge@gmail.com:

Been chatting a bit with John and he expressed concern about the

orgunit-randomnumber apprach. In India there are multiple installations and

one cannot know for sure that an orgunit name will be unique. How do we deal

with this?

Using a globally unique identifier could be a solution, but the standard

Java implementation (UUID) uses 32 characters and is a bit long. Is

implementing our own, shorter one an option?

Lars

43

I agree depending on the uniqueness of names is not a good idea. I
saw John said that facilities in India do have codes - the 16 digit
ones which are built hierarchicly (is that a word?).

OK I wasn't aware of this code.. Certainly if we could generate a string
based on the orgunit code plus its ancestors it will be unique. How does one
generate a fixed-length alphanumeric string based on this sequence of names
btw?

I'm thinking that we just generate the local part. The facility codes
already exist. So in Db you would have fields for patient id and
issuing-facility. I think it is common to store the issuing authority
with an id anyway. In most cases the issuing-facility might be null
because it could be assumed. If a patient is moved into the db from
somewhere else, or if patients are combined from different facilities
for one of many reasons, then the facility code would need to be
populated to avoid clashes. This bears some resemblance I think to
the uuid disambiguation referred to by Saptarshi.

Regards
Bob

···

2010/3/4 Lars Helge Øverland <larshelge@gmail.com>:

2010/3/4 Bob Jolliffe <bobjolliffe@gmail.com>

Is it possible to for a patient id to continue this hierarchy so that
a patient might have say a 6-8 digit local identifier - preferably
Base30 as I see Saptarshi has just chimed in. But his
"fully-qualified" id would be the 16 digit one + the local part. I
can see that generation and allocation of these might be problematic
and the internal uuid might be a good (if expensive) failsafe. How
does openmrs deal with this? Saptarshi, is at as you have suggested?
I would be a bit concerned that management of a pool of ids strikes me
as something which could easily fall apart. Isn't it better to
generate them on demand from some random source and test for
uniqueness before inserting into the database? If its not unique then
it simply tries another till its happy?

Bob

2010/3/4 Lars Helge Øverland <larshelge@gmail.com>:
>
>
> Been chatting a bit with John and he expressed concern about the
> orgunit-randomnumber apprach. In India there are multiple installations
> and
> one cannot know for sure that an orgunit name will be unique. How do we
> deal
> with this?
> Using a globally unique identifier could be a solution, but the standard
> Java implementation (UUID) uses 32 characters and is a bit long. Is
> implementing our own, shorter one an option?
>
> Lars
>
>

44

OK. Good point.

Even if we generate the facility part of the id on-demand we would still want it to be fixed length…?

···

2010/3/4 Bob Jolliffe bobjolliffe@gmail.com

2010/3/4 Lars Helge Øverland larshelge@gmail.com:

2010/3/4 Bob Jolliffe bobjolliffe@gmail.com

I agree depending on the uniqueness of names is not a good idea. I

saw John said that facilities in India do have codes - the 16 digit

ones which are built hierarchicly (is that a word?).

OK I wasn’t aware of this code… Certainly if we could generate a string

based on the orgunit code plus its ancestors it will be unique. How does one

generate a fixed-length alphanumeric string based on this sequence of names

btw?

I’m thinking that we just generate the local part. The facility codes

already exist. So in Db you would have fields for patient id and

issuing-facility. I think it is common to store the issuing authority

with an id anyway. In most cases the issuing-facility might be null

because it could be assumed. If a patient is moved into the db from

somewhere else, or if patients are combined from different facilities

for one of many reasons, then the facility code would need to be

populated to avoid clashes. This bears some resemblance I think to

the uuid disambiguation referred to by Saptarshi.

45

Hi Abyot,

Any change you are making is fine with me as long as it makes sense to broader use cases. The ID for example is better if we could keep it as it was before. I remember the ID was made of organization unit code or short name plus a 5 (or 6??) digit number. It was made like this on the assumption that each registering unit will be a facility to serve a population of hundred thousand and remember that our assumption is this system is going to be used by the lowest possible health administrative units (at least as far as registration is concerned). And whenever a migration occurs we have to update the person’s ID. We should only keep the UUID unique, unchanged and one-to-one. So the patient ID should be somewhat floating — it could also be possible for a person to have more than one identifier.

Let others discuss about this , then I do the coding part.

Calculating birth date from a given age - yes you will have conflicts if all ages are calculated relative to the first of January (that is how it is currently). But then your new approach makes sense if everyone if telling age relative to the current date.

So this is not problem right :slight_smile:

And the relationship type - instead of assuming there will always be parent/guardian vs child relationship, why don’t you provide users with the list of available relationships so that they can choose ?

This is all about validation. We give the user options for choosing. Those options should be correct on logical meaning …

IE: for the birthdate field, the rule is user can not select a date in the future. So we can just don’t display all the future dates in the calendar, or let user choose then show error.

The same thing happen to this relationship type. User adding a representative for a child, and we show them the relationship like Child, Husband, Mother, etc… is not correct … Of course user can choose what is right. But on the side of the quality of an application, I think we should filter this list.

We are not giving this software to STQC for testing now, but in the future I think India team will have to do that.

There are some more functions that we plan to do :

* Paging

The list patients will get really big, like thousands … So paging functionality is a must I think.

There are some options to do this :

  1. Paging on client side
  2. Paging on server side, but ajax loading the page.
  3. Paging on server side, reload page.
    I prefer option 3, because I won’t have to change too much the current layout …

* Functionality for add a child after completing Delivery Stage

In India, there is another requirement : for mother care program, after completing the Delivery stage, user want to add the child to the system immediately . They want a pop up after click on complete button…

I’m thinking of create a new page call addRelationShipPatient , where user can add a new patient/person that has relationship with another patient. In this situation is a mother and a child.

User can go to this page by click on a button “Add new patient” in current Patient Relationship Management page.

The addRelationShipPatient page will be almost the same with the patient registration screen. Just only some small changes :

  • Add a RelationShip type combo box on top of the form
  • Don’t show a pop up for adding new patient when user check on “Is Under age” , because we already have the id of the patient .
    By the way, this is just the beginning , there will be many more India requirements that does not fit the gobal requirements. I think we should have a solution for this…If we can not come to an end for any problem… working on both patient-branch and trunk at the same time is fine with me.

More things will come soon…

···

–
Viet Nguyen

46

Hi Abyot,

Any change you are making is fine with me as long as it makes sense to broader use cases. The ID for example is better if we could keep it as it was before. I remember the ID was made of organization unit code or short name plus a 5 (or 6??) digit number. It was made like this on the assumption that each registering unit will be a facility to serve a population of hundred thousand and remember that our assumption is this system is going to be used by the lowest possible health administrative units (at least as far as registration is concerned). And whenever a migration occurs we have to update the person’s ID. We should only keep the UUID unique, unchanged and one-to-one. So the patient ID should be somewhat floating — it could also be possible for a person to have more than one identifier.

Let others discuss about this , then I do the coding part.

Calculating birth date from a given age - yes you will have conflicts if all ages are calculated relative to the first of January (that is how it is currently). But then your new approach makes sense if everyone if telling age relative to the current date.

So this is not problem right :slight_smile:

And the relationship type - instead of assuming there will always be parent/guardian vs child relationship, why don’t you provide users with the list of available relationships so that they can choose ?

This is all about validation. We give the user options for choosing. Those options should be correct on logical meaning …

IE: for the birthdate field, the rule is user can not select a date in the future. So we can just don’t display all the future dates in the calendar, or let user choose then show error.

The same thing happen to this relationship type. User adding a representative for a child, and we show them the relationship like Child, Husband, Mother, etc… is not correct … Of course user can choose what is right. But on the side of the quality of an application, I think we should filter this list.

We are not giving this software to STQC for testing now, but in the future I think India team will have to do that.

There are some more functions that we plan to do :

* Paging

The list patients will get really big, like thousands … So paging functionality is a must I think.

There are some options to do this :

  1. Paging on client side
  2. Paging on server side, but ajax loading the page.
  3. Paging on server side, reload page.
    I prefer option 3, because I won’t have to change too much the current layout …

* Functionality for add a child after completing Delivery Stage

In India, there is another requirement : for mother care program, after completing the Delivery stage, user want to add the child to the system immediately . They want a pop up after click on complete button…

I’m thinking of create a new page call addRelationShipPatient , where user can add a new patient/person that has relationship with another patient. In this situation is a mother and a child.

User can go to this page by click on a button “Add new patient” in current Patient Relationship Management page.

The addRelationShipPatient page will be almost the same with the patient registration screen. Just only some small changes :

  • Add a RelationShip type combo box on top of the form
  • Don’t show a pop up for adding new patient when user check on “Is Under age” , because we already have the id of the patient .
    By the way, this is just the beginning , there will be many more India requirements that does not fit the gobal requirements. I think we should have a solution for this…If we can not come to an end for any problem… working on both patient-branch and trunk at the same time is fine with me.

More things will come soon…

Hi Viet,

thanks for doing a great job both with coding and information. These suggestions sounds sensible to me. Regarding the local-global requirement issue I have strong faith in solving this through system settings and generic solutions… Keep bringing the requirements on the table and we can see how to find a solution to them.

Lars

···

2010/3/4 Viet Nguyen phamquocviet@gmail.com

–
Viet Nguyen