Re: [Dhis2-devs] Greetings + new DHIS patient module

[Lars Helge Øverland]

2010/3/4 Viet Nguyen 

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




> --
> Viet Nguyen
>
>
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Viet Nguyen]

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

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
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Lars Helge Øverland]

2010/3/4 Bob Jolliffe 

> 2010/3/4 Lars Helge Øverland :
> >
> >
> > 2010/3/4 Bob Jolliffe 
> >>
> >> 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.


OK. Good point.

Even if we generate the facility part of the id on-demand we would still
want it to be fixed length...?
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Bob Jolliffe]

2010/3/4 Lars Helge Øverland :
>
>
> 2010/3/4 Bob Jolliffe 
>>
>> 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

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

___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Lars Helge Øverland]

2010/3/4 Bob Jolliffe 

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

>
> 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 :
> >
> >
> > 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
> >
> >
>
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Bob Jolliffe]

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

___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Saptarshi Purkayastha]

I've said my take on the solution before... But here again:

We generate a list of 6-digit Base30 ids(2 million or so ... ) (..or
8-digit). randomly allocate and make them used. During sync when the ids
collide we use the internal uuid to create separate rows and internally we
always use a combination id for each row

---
Regards,
Saptarshi PURKAYASTHA
Director R & D, HISP India
Health Information Systems Programme

My Tech Blog:  http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE


2010/3/4 Lars Helge Øverland 

>
>
> 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
>
>
>
> ___
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Lars Helge Øverland]

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
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Bob Jolliffe]

Hi Thanh

On 3 March 2010 19:59, Ngoc Thanh Nguyen  wrote:
>
>
> On Thu, Mar 4, 2010 at 12:11 AM, Bob Jolliffe  wrote:
>>
>> Hi John
>>
>> On 3 March 2010 15:20, John lewis  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
>>
>
> I think we can take a look at here
> http://en.wikipedia.org/wiki/National_identification_number to see how
> countries in the world dealing with this problem. While putting birthdate in
> the ID is considered as a violence of privacy, most of countries use it in
> their national ID systems. They might do thing wrong? ID system, as I
> perceive, is very similar to a infrastructure with its installed based.
> Addressing it is not the problem of good or bad but what the current
> situation is and how to build upon that, I think.

The wikipedia article you refer to deals with national ids.  From the
same source re patient identifiers:
http://en.wikipedia.org/wiki/ASTM_E_1714#Patient_confidentiality_and_access_security

Not that I'm in favour of the 28 digit sample.  That seems not to be
appropriate where manual systems are the norm.  But the desirable
characteristics of a patient identifier are worthwhile being aware of.
 Its ok of course to deviate from them with good reason, but lets
start from what is generally considered goo

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Ngoc Thanh Nguyen]

On Thu, Mar 4, 2010 at 12:11 AM, Bob Jolliffe  wrote:

> Hi John
>
> On 3 March 2010 15:20, John lewis  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
>
>
I think we can take a look at here
http://en.wikipedia.org/wiki/National_identification_numberto see how
countries in the world dealing with this problem. While putting
birthdate in the ID is considered as a violence of privacy, most of
countries use it in their national ID systems. They might do thing wrong? ID
system, as I perceive, is very similar to a infrastructure with its
installed based. Addressing it is not the problem of good or bad but what
the current situation is and how to build upon that, I think.

Thanh




> >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 
> wrote:
> >>
> >> Hi
> >>
> >> On 3 March 2010 12:20, Viet Nguyen  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 dupli

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Abyot Gizaw]

Hi Viet,

Thanks for the update. But a little afraid that you are making it very much
hard coded to the requirements of India.

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.

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.

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 ?

Thank you
Abyot.

On Wed, Mar 3, 2010 at 1:20 PM, Viet Nguyen  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 :
>
>
>1. 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.
>2. 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 :
>
>1. Search existing person : user can search for an existing patient in
>system to be the representative of the child.
>2. 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 en

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Bob Jolliffe]

On 3 March 2010 17:23, John lewis  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  wrote:
>>
>> Hi John
>>
>> On 3 March 2010 15:20, John lewis  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 
>> > wrote:
>> >>
>> >> Hi
>> >>
>> >> On 3 March 2010 12:20, Viet Nguyen  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 :
>> >

Re: [Dhis2-devs] Greetings + new DHIS patient module

[John lewis]

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

> Hi John
>
> On 3 March 2010 15:20, John lewis  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 
> wrote:
> >>
> >> Hi
> >>
> >> On 3 March 2010 12:20, Viet Nguyen  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
> >>

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Bob Jolliffe]

Hi John

On 3 March 2010 15:20, John lewis  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  wrote:
>>
>> Hi
>>
>> On 3 March 2010 12:20, Viet Nguyen  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

Re: [Dhis2-devs] Greetings + new DHIS patient module

[John lewis]

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. 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  wrote:

> Hi
>
> On 3 March 2010 12:20, Viet Nguyen  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][XX][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 : MMdd
> > Gender : Male  = 1 ; Female = 0
> > XX : a random number  with length = 6  

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Bob Jolliffe]

Hi

On 3 March 2010 12:20, Viet Nguyen  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][XX][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 : MMdd
> Gender : Male  = 1 ; Female = 0
> XX : a random number  with length = 6   ( 0 - 99 )
> 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 N

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Viet Nguyen]

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 :


   1. 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.
   2. 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 :

   1. Search existing person : user can search for an existing patient in
   system to be the representative of the child.
   2. 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][XX][checkdigit]

BirthDate : MMdd
Gender : Male  = 1 ; Female = 0
XX : a random number  with length = 6   ( 0 - 99 )
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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Jason Pickering]

Hi there. Well, nothing has been done yet, but we have been discussing
the need for field-level validation with the use of regular
expressions. I am not sure this impacts the blue print so much
actually, however it would seem there would possibly need to be
another field added to the regex to record which language the
particular regex would apply to if the field is language related.

I can make the update to the blueprint when I get a chance.

Best regards,
Jason


On Mon, Mar 1, 2010 at 1:20 PM, Viet Nguyen  wrote:
>
>
> On Mon, Mar 1, 2010 at 4:02 PM, Bob Jolliffe  wrote:
>>
>> Hi Viet
>>
>> On 1 March 2010 08:22, Viet Nguyen  wrote:
>>>
>>> Hi,
>>>
>>>
>>> On Mon, Mar 1, 2010 at 11:13 AM, Chau Thu Tran
>>>  wrote:

 Hi Abyot and Others,
 I tested the UpdatePatientAttributeValues function. It doesn't show
 anything. I think if we have EditPatient, we don't
 need PatientAttributeValues.
>>>
>>> Yeah, this is a bug, we changed Attribute object so this function should
>>> be updated . I will fix that.
>>> Let's keep it there for a while, later when everything is fine then we
>>> can have a look at all the functions and decide whether to keep it or not.
>>>

 About enter name for Patient and Patient attribute
       - The validate function ( required_group {validate...)  doesn't
 allow to enter Vietnamese in Add/Update patient, Add/Update 
 PatientAttribute
 ,
 VD: Châu --> Warning message: Please Letters, numbers, spaces and
 underscores only.
>>>
>>> This is just rule of jquery validation, I can remove that .
>>
>> This exposes quite an interesting problem regarding the use of regex based
>> validators - such as the jquery validation plugin.  I see that you made some
>> mods to the plugin to allow internationalized messages, nut the bigger
>> problem may be with the underlying regexes themselves.  In Jason's broader
>> vision of regex use we need to take into account internationalized regexes.
>> So for example [a-zA-Z] looks useful but it is of course not universally
>> applicable. If we needed to match Gujerati characters we would need
>> something like [\u0A80-\u0AFF].
>>
>> Not wanting to hijack this thread, I think we need to add this
>> internationalisation requirement to the regex blueprint and maybe discuss it
>> elsewhere.  And meanwhile beware of things like "alphanumeric" in the jquery
>> plugin as it clearly seems to make assumptions about character ranges.
>>
> Ok, I understand the problem. Will remove the alphanumeric things for now.
> I'm not sure how to integrate this client validation with what Jason
> did...will try to have a look at that when I have time.
>
> --
> Viet Nguyen
>
>
> ___
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>



-- 
--
Jason P. Pickering
email: jason.p.picker...@gmail.com
tel:+260968395190

___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Viet Nguyen]

On Mon, Mar 1, 2010 at 4:02 PM, Bob Jolliffe  wrote:

> Hi Viet
>
> On 1 March 2010 08:22, Viet Nguyen  wrote:
>
>> Hi,
>>
>>
>> On Mon, Mar 1, 2010 at 11:13 AM, Chau Thu Tran <
>> tran.hispviet...@gmail.com> wrote:
>>
>>> Hi Abyot and Others,
>>>
>>> I tested the* UpdatePatientAttributeValues *function. It doesn't show
>>> anything. I think if we have *EditPatient*, we don't need *
>>> PatientAttributeValues*.
>>>
>>
>> Yeah, this is a bug, we changed Attribute object so this function should
>> be updated . I will fix that.
>> Let's keep it there for a while, later when everything is fine then we can
>> have a look at all the functions and decide whether to keep it or not.
>>
>>
>>>
>>> *About enter name for Patient and Patient attribute*
>>>   - The validate function ( *required_group {validate...*)  doesn't
>>> allow to enter Vietnamese in Add/Update patient, Add/Update PatientAttribute
>>> ,
>>> *VD: Châu --> Warning message: Please Letters, numbers, spaces and
>>> underscores only.*
>>>
>>
>> This is just rule of jquery validation, I can remove that .
>>
>
> This exposes quite an interesting problem regarding the use of regex based
> validators - such as the jquery validation plugin.  I see that you made some
> mods to the plugin to allow internationalized messages, nut the bigger
> problem may be with the underlying regexes themselves.  In Jason's broader
> vision of regex use we need to take into account internationalized regexes.
> So for example [a-zA-Z] looks useful but it is of course not universally
> applicable. If we needed to match Gujerati characters we would need
> something like [\u0A80-\u0AFF].
>
> Not wanting to hijack this thread, I think we need to add this
> internationalisation requirement to the regex blueprint and maybe discuss it
> elsewhere.  And meanwhile beware of things like "alphanumeric" in the jquery
> plugin as it clearly seems to make assumptions about character ranges.
>
> Ok, I understand the problem. Will remove the alphanumeric things for now.
I'm not sure how to integrate this client validation with what Jason
did...will try to have a look at that when I have time.

-- 
Viet Nguyen
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Bob Jolliffe]

Hi Viet

On 1 March 2010 08:22, Viet Nguyen  wrote:

> Hi,
>
>
> On Mon, Mar 1, 2010 at 11:13 AM, Chau Thu Tran  > wrote:
>
>> Hi Abyot and Others,
>>
>> I tested the* UpdatePatientAttributeValues *function. It doesn't show
>> anything. I think if we have *EditPatient*, we don't need *
>> PatientAttributeValues*.
>>
>
> Yeah, this is a bug, we changed Attribute object so this function should be
> updated . I will fix that.
> Let's keep it there for a while, later when everything is fine then we can
> have a look at all the functions and decide whether to keep it or not.
>
>
>>
>> *About enter name for Patient and Patient attribute*
>>   - The validate function ( *required_group {validate...*)  doesn't
>> allow to enter Vietnamese in Add/Update patient, Add/Update PatientAttribute
>> ,
>> *VD: Châu --> Warning message: Please Letters, numbers, spaces and
>> underscores only.*
>>
>
> This is just rule of jquery validation, I can remove that .
>

This exposes quite an interesting problem regarding the use of regex based
validators - such as the jquery validation plugin.  I see that you made some
mods to the plugin to allow internationalized messages, nut the bigger
problem may be with the underlying regexes themselves.  In Jason's broader
vision of regex use we need to take into account internationalized regexes.
So for example [a-zA-Z] looks useful but it is of course not universally
applicable. If we needed to match Gujerati characters we would need
something like [\u0A80-\u0AFF].

Not wanting to hijack this thread, I think we need to add this
internationalisation requirement to the regex blueprint and maybe discuss it
elsewhere.  And meanwhile beware of things like "alphanumeric" in the jquery
plugin as it clearly seems to make assumptions about character ranges.

Regards
Bob


>
>
>>   -  For mother, we have attributes, such as age, pre-pregnancy, 
>> *housenumber,
>> street name*. We want to enter *street name* next to *housenumber*. So, I
>> think  we have to sort attributes in groups ?
>>
>
> Yeah sure. there should be a sort-order while assign attribute to attribute
> group.
>
>
>> *Patient Identifier Type*
>>   - In Add Patient form, only show *Patient Identifier Type* when
>> object has age *less then 5*. In Mother-Child Record in Vietnam, besides
>> the children object, we also manage children *less then or equal 15*. How
>> do you think if we have a parameter ( user input ) for it ?
>>
>
> Current, we have added a boolean  field "underAge" in Patient object.  In
> the registration form, there will be a checkbox call "Is Underage"
> user have to check that to define this patient is a child.  By this way, we
> don't hardcode  the age <5 or < 15.
>
> I'm working on this function, will update you when i finish.
>
>
>>
>> *Dataentry*
>> *Program Stages History/Plan*
>>   *Sau khi sanh (After to born):*  Scheduled For 2010-02-04   *Kết quả
>> (Result):*  Scheduled For 2010-02-04   *Trước khi sanh (Before to born):* 
>> Scheduled For 2010-02-01
>> *
>> *
>> The stages aren't listed in order. I want them to list, as follows :
>> Before - After - Result.
>>
>
> Have not touched this yet, Will have a  look.
>
>
>>
>> Yes/No datatype shown dataentry is a combobox. How do you think if we use
>> a checkbox ?
>>
>
> We can do this in the default dataetry, but not in custom dataentry.
>
> In custom dataentry there is a checkbox right beside each entry field (
> textbox or combobox ). If user check on this checkbox, means that the data
> value has just been entered is provided by another facility.  So if we
> replace boolean entryfield by a checkbox. there will be two checkboxes
> that stay beside each other, I think it may confuse user.
>
>
>>
>> *- Programs for patient*
>>
>> Why don't assign program for patient when to add a new patient. And in the
>> future, if the patient attends other programs, we will assign them again.
>>
>>
> This should make the registration function becomes...complicated.
> Current, we already put a lot of things into the patient registration form
> : Patient Attributes , Patient Identifiers, under age things.
> Program enrollment is not a step of Patient Registration. It should be done
> after the registration I think.
>
>
>
>> - *RelationShip*
>> I can't create relationship between two objects.
>>
>
> It worked hereI will test it again...
>
>
>
> --
> Viet Nguyen
>
>
> ___
> Mailing list: 
> https://launchpad.net/~dhis2-devs
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : 
> https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Chau Thu Tran]

Hi all,

Sorry. I sorted them. It's Ok.


Châu Thu Trân
HISP Viet Nam
Email: tran.hispviet...@gmail.com
Cell phone: +84 97 324 1542



On Mon, Mar 1, 2010 at 3:38 PM, Abyot Gizaw  wrote:

>
>
> On Mon, Mar 1, 2010 at 9:22 AM, Viet Nguyen wrote:
>
>> Hi,
>>
>>
>> On Mon, Mar 1, 2010 at 11:13 AM, Chau Thu Tran <
>> tran.hispviet...@gmail.com> wrote:
>>
>>> Hi Abyot and Others,
>>>
>>> I tested the* UpdatePatientAttributeValues *function. It doesn't show
>>> anything. I think if we have *EditPatient*, we don't need *
>>> PatientAttributeValues*.
>>>
>>
>> Yeah, this is a bug, we changed Attribute object so this function should
>> be updated . I will fix that.
>> Let's keep it there for a while, later when everything is fine then we can
>> have a look at all the functions and decide whether to keep it or not.
>>
>>
>>>
>>> *About enter name for Patient and Patient attribute*
>>>   - The validate function ( *required_group {validate...*)  doesn't
>>> allow to enter Vietnamese in Add/Update patient, Add/Update PatientAttribute
>>> ,
>>> *VD: Châu --> Warning message: Please Letters, numbers, spaces and
>>> underscores only.*
>>>
>>
>> This is just rule of jquery validation, I can remove that .
>>
>>
>>>   -  For mother, we have attributes, such as age, pre-pregnancy, 
>>> *housenumber,
>>> street name*. We want to enter *street name* next to *housenumber*. So,
>>> I think  we have to sort attributes in groups ?
>>>
>>
>> Yeah sure. there should be a sort-order while assign attribute to
>> attribute group.
>>
>>
>>> *Patient Identifier Type*
>>>   - In Add Patient form, only show *Patient Identifier Type* when
>>> object has age *less then 5*. In Mother-Child Record in Vietnam, besides
>>> the children object, we also manage children *less then or equal 15*.
>>> How do you think if we have a parameter ( user input ) for it ?
>>>
>>
>> Current, we have added a boolean  field "underAge" in Patient object.  In
>> the registration form, there will be a checkbox call "Is Underage"
>> user have to check that to define this patient is a child.  By this way,
>> we don't hardcode  the age <5 or < 15.
>>
>> I'm working on this function, will update you when i finish.
>>
>>
>>>
>>> *Dataentry*
>>> *Program Stages History/Plan*
>>>   *Sau khi sanh (After to born):*  Scheduled For 2010-02-04   *Kết quả
>>> (Result):*  Scheduled For 2010-02-04   *Trước khi sanh (Before to born):
>>> *  Scheduled For 2010-02-01
>>> *
>>> *
>>> The stages aren't listed in order. I want them to list, as follows :
>>> Before - After - Result.
>>>
>>
>> Have not touched this yet, Will have a  look.
>>
>
> Have you sorted your program stages?
>
>
>>
>>
>>>
>>> Yes/No datatype shown dataentry is a combobox. How do you think if we use
>>> a checkbox ?
>>>
>>
>> We can do this in the default dataetry, but not in custom dataentry.
>>
>> In custom dataentry there is a checkbox right beside each entry field (
>> textbox or combobox ). If user check on this checkbox, means that the data
>> value has just been entered is provided by another facility.  So if we
>> replace boolean entryfield by a checkbox. there will be two checkboxes
>> that stay beside each other, I think it may confuse user.
>>
>>
>>>
>>> *- Programs for patient*
>>>
>>> Why don't assign program for patient when to add a new patient. And in
>>> the future, if the patient attends other programs, we will assign them
>>> again.
>>>
>>>
>> This should make the registration function becomes...complicated.
>> Current, we already put a lot of things into the patient registration form
>> : Patient Attributes , Patient Identifiers, under age things.
>> Program enrollment is not a step of Patient Registration. It should be
>> done after the registration I think.
>>
>>
>>
>>> - *RelationShip*
>>> I can't create relationship between two objects.
>>>
>>
>> It worked hereI will test it again...
>>
>>
>>
>> --
>> Viet Nguyen
>>
>>
>
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Abyot Gizaw]

On Mon, Mar 1, 2010 at 9:22 AM, Viet Nguyen  wrote:

> Hi,
>
>
> On Mon, Mar 1, 2010 at 11:13 AM, Chau Thu Tran  > wrote:
>
>> Hi Abyot and Others,
>>
>> I tested the* UpdatePatientAttributeValues *function. It doesn't show
>> anything. I think if we have *EditPatient*, we don't need *
>> PatientAttributeValues*.
>>
>
> Yeah, this is a bug, we changed Attribute object so this function should be
> updated . I will fix that.
> Let's keep it there for a while, later when everything is fine then we can
> have a look at all the functions and decide whether to keep it or not.
>
>
>>
>> *About enter name for Patient and Patient attribute*
>>   - The validate function ( *required_group {validate...*)  doesn't
>> allow to enter Vietnamese in Add/Update patient, Add/Update PatientAttribute
>> ,
>> *VD: Châu --> Warning message: Please Letters, numbers, spaces and
>> underscores only.*
>>
>
> This is just rule of jquery validation, I can remove that .
>
>
>>   -  For mother, we have attributes, such as age, pre-pregnancy, 
>> *housenumber,
>> street name*. We want to enter *street name* next to *housenumber*. So, I
>> think  we have to sort attributes in groups ?
>>
>
> Yeah sure. there should be a sort-order while assign attribute to attribute
> group.
>
>
>> *Patient Identifier Type*
>>   - In Add Patient form, only show *Patient Identifier Type* when
>> object has age *less then 5*. In Mother-Child Record in Vietnam, besides
>> the children object, we also manage children *less then or equal 15*. How
>> do you think if we have a parameter ( user input ) for it ?
>>
>
> Current, we have added a boolean  field "underAge" in Patient object.  In
> the registration form, there will be a checkbox call "Is Underage"
> user have to check that to define this patient is a child.  By this way, we
> don't hardcode  the age <5 or < 15.
>
> I'm working on this function, will update you when i finish.
>
>
>>
>> *Dataentry*
>> *Program Stages History/Plan*
>>   *Sau khi sanh (After to born):*  Scheduled For 2010-02-04   *Kết quả
>> (Result):*  Scheduled For 2010-02-04   *Trước khi sanh (Before to born):* 
>> Scheduled For 2010-02-01
>> *
>> *
>> The stages aren't listed in order. I want them to list, as follows :
>> Before - After - Result.
>>
>
> Have not touched this yet, Will have a  look.
>

Have you sorted your program stages?


>
>
>>
>> Yes/No datatype shown dataentry is a combobox. How do you think if we use
>> a checkbox ?
>>
>
> We can do this in the default dataetry, but not in custom dataentry.
>
> In custom dataentry there is a checkbox right beside each entry field (
> textbox or combobox ). If user check on this checkbox, means that the data
> value has just been entered is provided by another facility.  So if we
> replace boolean entryfield by a checkbox. there will be two checkboxes
> that stay beside each other, I think it may confuse user.
>
>
>>
>> *- Programs for patient*
>>
>> Why don't assign program for patient when to add a new patient. And in the
>> future, if the patient attends other programs, we will assign them again.
>>
>>
> This should make the registration function becomes...complicated.
> Current, we already put a lot of things into the patient registration form
> : Patient Attributes , Patient Identifiers, under age things.
> Program enrollment is not a step of Patient Registration. It should be done
> after the registration I think.
>
>
>
>> - *RelationShip*
>> I can't create relationship between two objects.
>>
>
> It worked hereI will test it again...
>
>
>
> --
> Viet Nguyen
>
>
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Viet Nguyen]

Hi,


On Mon, Mar 1, 2010 at 11:13 AM, Chau Thu Tran
wrote:

> Hi Abyot and Others,
>
> I tested the* UpdatePatientAttributeValues *function. It doesn't show
> anything. I think if we have *EditPatient*, we don't need *
> PatientAttributeValues*.
>

Yeah, this is a bug, we changed Attribute object so this function should be
updated . I will fix that.
Let's keep it there for a while, later when everything is fine then we can
have a look at all the functions and decide whether to keep it or not.


>
> *About enter name for Patient and Patient attribute*
>   - The validate function ( *required_group {validate...*)  doesn't
> allow to enter Vietnamese in Add/Update patient, Add/Update PatientAttribute
> ,
> *VD: Châu --> Warning message: Please Letters, numbers, spaces and
> underscores only.*
>

This is just rule of jquery validation, I can remove that .


>   -  For mother, we have attributes, such as age, pre-pregnancy, 
> *housenumber,
> street name*. We want to enter *street name* next to *housenumber*. So, I
> think  we have to sort attributes in groups ?
>

Yeah sure. there should be a sort-order while assign attribute to attribute
group.


> *Patient Identifier Type*
>   - In Add Patient form, only show *Patient Identifier Type* when
> object has age *less then 5*. In Mother-Child Record in Vietnam, besides
> the children object, we also manage children *less then or equal 15*. How
> do you think if we have a parameter ( user input ) for it ?
>

Current, we have added a boolean  field "underAge" in Patient object.  In
the registration form, there will be a checkbox call "Is Underage"
user have to check that to define this patient is a child.  By this way, we
don't hardcode  the age <5 or < 15.

I'm working on this function, will update you when i finish.


>
> *Dataentry*
> *Program Stages History/Plan*
>   *Sau khi sanh (After to born):*  Scheduled For 2010-02-04   *Kết quả
> (Result):*  Scheduled For 2010-02-04   *Trước khi sanh (Before to born):* 
> Scheduled For 2010-02-01
> *
> *
> The stages aren't listed in order. I want them to list, as follows : Before
> - After - Result.
>

Have not touched this yet, Will have a  look.


>
> Yes/No datatype shown dataentry is a combobox. How do you think if we use a
> checkbox ?
>

We can do this in the default dataetry, but not in custom dataentry.

In custom dataentry there is a checkbox right beside each entry field (
textbox or combobox ). If user check on this checkbox, means that the data
value has just been entered is provided by another facility.  So if we
replace boolean entryfield by a checkbox. there will be two checkboxes
that stay beside each other, I think it may confuse user.


>
> *- Programs for patient*
>
> Why don't assign program for patient when to add a new patient. And in the
> future, if the patient attends other programs, we will assign them again.
>
>
This should make the registration function becomes...complicated.
Current, we already put a lot of things into the patient registration form :
Patient Attributes , Patient Identifiers, under age things.
Program enrollment is not a step of Patient Registration. It should be done
after the registration I think.



> - *RelationShip*
> I can't create relationship between two objects.
>

It worked hereI will test it again...



-- 
Viet Nguyen
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Chau Thu Tran]

Hi Abyot and Others,

I tested the* UpdatePatientAttributeValues *function. It doesn't show
anything. I think if we have *EditPatient*, we don't need *
PatientAttributeValues*.

*About enter name for Patient and Patient attribute*
  - The validate function ( *required_group {validate...*)  doesn't
allow to enter Vietnamese in Add/Update patient, Add/Update PatientAttribute
,
*VD: Châu --> Warning message: Please Letters, numbers, spaces and
underscores only.*
  -  For mother, we have attributes, such as age, pre-pregnancy,
*housenumber,
street name*. We want to enter *street name* next to *housenumber*. So, I
think  we have to sort attributes in groups ?

*Patient Identifier Type*
  - In Add Patient form, only show *Patient Identifier Type* when object
has age *less then 5*. In Mother-Child Record in Vietnam, besides the
children object, we also manage children *less then or equal 15*. How do you
think if we have a parameter ( user input ) for it ?

*Dataentry*
*Program Stages History/Plan*
  *Sau khi sanh (After to born):*  Scheduled For 2010-02-04   *Kết quả
(Result):*  Scheduled For 2010-02-04   *Trước khi sanh (Before to
born):* Scheduled For 2010-02-01
*
*
The stages aren't listed in order. I want them to list, as follows : Before
- After - Result.

Yes/No datatype shown dataentry is a combobox. How do you think if we use a
checkbox ?

*- Programs for patient*

Why don't assign program for patient when to add a new patient. And in the
future, if the patient attends other programs, we will assign them again.

- *RelationShip*
I can't create relationship between two objects.

Best regards,


Châu Thu Trân
HISP Viet Nam
Email: tran.hispviet...@gmail.com
Cell phone: +84 97 324 1542



On Mon, Feb 1, 2010 at 3:23 PM, Knut Staring  wrote:

> I think the OpenMRS project has considered this question extensively (and
> many others that are relevant for a patient system).
>
> Knut
>
> On Mon, Feb 1, 2010 at 7:31 AM, Jason Pickering <
> jason.p.picker...@gmail.com> wrote:
>
>> > So we are thinking of an algorithm to generate the id for the whole
>> country,
>> > but not depend on the organisation unit. It should only depend on
>> patient
>> > information and the time of creating...
>>
>> A UUID perhaps? Seems to be the only way to guarantee you will end up
>> with a unique ID, especially in a federated setting. Otherwise,
>> national identity numbers, but there are privacy issues here to
>> consider.
>>
>> http://java.sun.com/j2se/1.5.0/docs/api/java/util/UUID.html
>>
>> Regards,
>> Jason
>>
>> ___
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to : dhis2-devs@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> Cheers,
> Knut Staring
>
> ___
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Knut Staring]

I think the OpenMRS project has considered this question extensively (and
many others that are relevant for a patient system).

Knut

On Mon, Feb 1, 2010 at 7:31 AM, Jason Pickering  wrote:

> > So we are thinking of an algorithm to generate the id for the whole
> country,
> > but not depend on the organisation unit. It should only depend on patient
> > information and the time of creating...
>
> A UUID perhaps? Seems to be the only way to guarantee you will end up
> with a unique ID, especially in a federated setting. Otherwise,
> national identity numbers, but there are privacy issues here to
> consider.
>
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/UUID.html
>
> Regards,
> Jason
>
> ___
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Cheers,
Knut Staring
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Jason Pickering]

> So we are thinking of an algorithm to generate the id for the whole country,
> but not depend on the organisation unit. It should only depend on patient
> information and the time of creating...

A UUID perhaps? Seems to be the only way to guarantee you will end up
with a unique ID, especially in a federated setting. Otherwise,
national identity numbers, but there are privacy issues here to
consider.

http://java.sun.com/j2se/1.5.0/docs/api/java/util/UUID.html

Regards,
Jason

___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Viet Nguyen]

Hi,

The reason of not put the organisation unit in the System generated Patient
Id is :

An organisation unit can be changed the name. Or it can be splited into two
smaller organisation unit ( This is happening in India ) . Or even it can be
merge with another organisationUnit to make a bigger one 

So we are thinking of an algorithm to generate the id for the whole country,
but not depend on the organisation unit. It should only depend on patient
information and the time of creating...

On Mon, Feb 1, 2010 at 8:25 AM, Chau Thu Tran wrote:

> Hi,
>
> In Vietnam, code of patient likes this:
> - Set of characters dependent on the organisation unit
> - Set of digits, include date and number of patients in the day.
>
> 
> Châu Thu Trân
> HISP Viet Nam
> Email: tran.hispviet...@gmail.com
> Cell phone: +84 97 324 1542
> 
>
>
> On Sat, Jan 30, 2010 at 6:14 PM, Viet Nguyen wrote:
>
>> Hi,
>>
>> Here are things that I've changed for patient - branch
>>
>>
>>- Add  Date of Enrollment Description , Date of Incident Description
>>for Program.  This is because those description is differ from each
>>program,  when user enroll to a program, we need to show them the
>>descriptions.
>>- Move blood group to Patient table.
>>- Merge Patient Attribute Group from trunk.
>>- Add Patient Attribute Option . This is for any attribute that can
>>have predefined value.
>>- Bring all attribute groups to patient registration screen.
>>
>>
>> Tasks for next week :
>>
>>
>>- Check duplicate patient base on first name, last name, middle name,
>>birthdate, genre. If there is a patient existing,  display all the
>>information of that patient for user.
>>- If a child < 5 years old. Then all of the identifier information
>>should take from mother / father / guardian , So we have to put that
>>person's name to identifier information.
>>- Bring all identifiers  to patient registration screen.
>>- System generated Random Unique Id.  Organisation Unit name should
>>not be in the Id.
>>- Patient Identifier  management.
>>
>> If there is anything that you think we can make it generic and merge to
>> trunk, please tell.
>>
>> Regards,
>>
>>
>>
>>
>>
>>
>> On Fri, Jan 29, 2010 at 2:06 PM, Chau Thu Tran <
>> tran.hispviet...@gmail.com> wrote:
>>
>>> Hi Abyot,
>>>
>>> I assigned mandatory attributes under the patient registration screen.
>>>
>>> Please find enclosed the attached file to see patch file.
>>>
>>> Best regards,
>>>
>>> 
>>> Châu Thu Trân
>>> HISP Viet Nam
>>> Email: tran.hispviet...@gmail.com
>>> Cell phone: +84 97 324 1542
>>> 
>>>
>>>
>>> 2010/1/29 Lars Helge Øverland 
>>>
>>>

 On Thu, Jan 28, 2010 at 8:45 AM, Chau Thu Tran <
 tran.hispviet...@gmail.com> wrote:

> Hi Abyot,
>
> I modify the source.
>
> Please find enclosed the attached file to see the patch.diff file.
>
> Best regards,
>
>
 Nice work Tran...


>>>
>>
>>
>> --
>> Viet Nguyen
>>
>>
>> ___
>> Mailing list: 
>> https://launchpad.net/~dhis2-devs
>> Post to : dhis2-devs@lists.launchpad.net
>> Unsubscribe : 
>> https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>


-- 
Viet Nguyen
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Chau Thu Tran]

Hi,

In Vietnam, code of patient likes this:
- Set of characters dependent on the organisation unit
- Set of digits, include date and number of patients in the day.


Châu Thu Trân
HISP Viet Nam
Email: tran.hispviet...@gmail.com
Cell phone: +84 97 324 1542



On Sat, Jan 30, 2010 at 6:14 PM, Viet Nguyen  wrote:

> Hi,
>
> Here are things that I've changed for patient - branch
>
>
>- Add  Date of Enrollment Description , Date of Incident Description
>for Program.  This is because those description is differ from each
>program,  when user enroll to a program, we need to show them the
>descriptions.
>- Move blood group to Patient table.
>- Merge Patient Attribute Group from trunk.
>- Add Patient Attribute Option . This is for any attribute that can
>have predefined value.
>- Bring all attribute groups to patient registration screen.
>
>
> Tasks for next week :
>
>
>- Check duplicate patient base on first name, last name, middle name,
>birthdate, genre. If there is a patient existing,  display all the
>information of that patient for user.
>- If a child < 5 years old. Then all of the identifier information
>should take from mother / father / guardian , So we have to put that
>person's name to identifier information.
>- Bring all identifiers  to patient registration screen.
>- System generated Random Unique Id.  Organisation Unit name should not
>be in the Id.
>- Patient Identifier  management.
>
> If there is anything that you think we can make it generic and merge to
> trunk, please tell.
>
> Regards,
>
>
>
>
>
>
> On Fri, Jan 29, 2010 at 2:06 PM, Chau Thu Tran  > wrote:
>
>> Hi Abyot,
>>
>> I assigned mandatory attributes under the patient registration screen.
>>
>> Please find enclosed the attached file to see patch file.
>>
>> Best regards,
>>
>> 
>> Châu Thu Trân
>> HISP Viet Nam
>> Email: tran.hispviet...@gmail.com
>> Cell phone: +84 97 324 1542
>> 
>>
>>
>> 2010/1/29 Lars Helge Øverland 
>>
>>
>>>
>>> On Thu, Jan 28, 2010 at 8:45 AM, Chau Thu Tran <
>>> tran.hispviet...@gmail.com> wrote:
>>>
 Hi Abyot,

 I modify the source.

 Please find enclosed the attached file to see the patch.diff file.

 Best regards,


>>> Nice work Tran...
>>>
>>>
>>
>
>
> --
> Viet Nguyen
>
>
> ___
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Viet Nguyen]

Hi,

Here are things that I've changed for patient - branch


   - Add  Date of Enrollment Description , Date of Incident Description  for
   Program.  This is because those description is differ from each program,
   when user enroll to a program, we need to show them the descriptions.
   - Move blood group to Patient table.
   - Merge Patient Attribute Group from trunk.
   - Add Patient Attribute Option . This is for any attribute that can have
   predefined value.
   - Bring all attribute groups to patient registration screen.


Tasks for next week :


   - Check duplicate patient base on first name, last name, middle name,
   birthdate, genre. If there is a patient existing,  display all the
   information of that patient for user.
   - If a child < 5 years old. Then all of the identifier information should
   take from mother / father / guardian , So we have to put that person's name
   to identifier information.
   - Bring all identifiers  to patient registration screen.
   - System generated Random Unique Id.  Organisation Unit name should not
   be in the Id.
   - Patient Identifier  management.

If there is anything that you think we can make it generic and merge to
trunk, please tell.

Regards,





On Fri, Jan 29, 2010 at 2:06 PM, Chau Thu Tran
wrote:

> Hi Abyot,
>
> I assigned mandatory attributes under the patient registration screen.
>
> Please find enclosed the attached file to see patch file.
>
> Best regards,
>
> 
> Châu Thu Trân
> HISP Viet Nam
> Email: tran.hispviet...@gmail.com
> Cell phone: +84 97 324 1542
> 
>
>
> 2010/1/29 Lars Helge Øverland 
>
>
>>
>> On Thu, Jan 28, 2010 at 8:45 AM, Chau Thu Tran <
>> tran.hispviet...@gmail.com> wrote:
>>
>>> Hi Abyot,
>>>
>>> I modify the source.
>>>
>>> Please find enclosed the attached file to see the patch.diff file.
>>>
>>> Best regards,
>>>
>>>
>> Nice work Tran...
>>
>>
>


-- 
Viet Nguyen
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Lars Helge Øverland]

On Thu, Jan 28, 2010 at 8:45 AM, Chau Thu Tran
wrote:

> Hi Abyot,
>
> I modify the source.
>
> Please find enclosed the attached file to see the patch.diff file.
>
> Best regards,
>
>
Nice work Tran...
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Viet Nguyen]

ividuals
>> we will be registering. Other, if we have a scenario of mandatory for males,
>> females, mothers, children, then we are in trouble of slipping into
>> multiple registration forms varied for males, females, mothers, babies
>> -- what do you people think, especially those of you who have had the
>> experience of the field?
>>
>>
>> Tran, is this any thing helpful for the question you asked? I know you
>> asked me for specific places to put the functionality you are making ... but
>> I thought raising these issues will also guide you.
>>
>> Thank you
>>  Abyot.
>>
>>
>>
>> On Mon, Jan 25, 2010 at 10:36 AM, Chau Thu Tran <
>> tran.hispviet...@gmail.com> wrote:
>>
>>> Hi Abyot and others,
>>>
>>> I created the function of attribute group management. And now, I don't
>>> know where is suitable place to add that function. I thought to put on one
>>> of three places as below, but i am not sure.
>>> 1. Create groups property for patient and request users add it in new
>>> patient GUI
>>> 2. Create other function named Add Groups for each in list of patients.
>>> 3. Create combox to load all of groups existing in the system and
>>> end-user has to choose each group to enter attribute.
>>>
>>> What is your suggestion?
>>>
>>> 
>>> Châu Thu Trân
>>> HISP Viet Nam
>>> Email: tran.hispviet...@gmail.com
>>> Cell phone: +84 97 324 1542
>>> 
>>>
>>>
>>> On Thu, Jan 21, 2010 at 8:58 PM, Cong Duong Dinh <
>>> duong_dinhc...@hotmail.com> wrote:
>>>
>>>>  OK Tran that's good,
>>>> Try to go ahead..
>>>>
>>>> Duong Dinh Cong MD. PhD
>>>> Community Health Department
>>>> Medical School Pham Ngoc Thach
>>>> Home 22 Ho Huan Nghiep Q1 HCM City
>>>> 0903359924
>>>>
>>>> --- @ WiseStamp 
>>>> Signature<http://my.wisestamp.com/link?u=6zk6hnnyzjswmm3g&site=www.wisestamp.com/email-install>.
>>>> Get it 
>>>> now<http://my.wisestamp.com/link?u=6zk6hnnyzjswmm3g&site=www.wisestamp.com/email-install>
>>>>
>>>>
>>>> Duong Dinh Cong CUF/UTC 520 Ng Tri Phuong QX HCM-City Vietnam Tel 84 8
>>>> 8631383 Fax 84 8 650025
>>>>
>>>>
>>>>
>>>> --
>>>> Date: Thu, 21 Jan 2010 17:41:39 +0700
>>>>
>>>> Subject: Re: [Dhis2-devs] Greetings + new DHIS patient module
>>>> From: tran.hispviet...@gmail.com
>>>> To: aby...@gmail.com
>>>> CC: duong_dinhc...@hotmail.com; tranthanhtr...@gmail.com;
>>>> sam.hispviet...@gmail.com; thuy.hispviet...@gmail.com;
>>>> hieu.hispviet...@gmail.com; cata...@gmail.com
>>>>
>>>>
>>>> Hi Abyot,
>>>>
>>>> The Mother Form system has two objects, mother and child. There are
>>>> somes attributes belonging to mother that does not belong to child and vice
>>>> versa. For example, the atributes of mother are housenumber, street and 
>>>> pre-prefnacy
>>>> (***). And the attributes of child are information when to be born,
>>>> include apgar 1, apgar 5, weight and malformation
>>>>
>>>> When I build attributes for the object in your module, I have to define
>>>> all of  the attributes of the mother and child. So, when to create a new
>>>> object and input attributes for it, all of the attributes of both objects
>>>> are displayed in the form. How do you think if we have a function to group
>>>> attributes of each.
>>>>
>>>> Now, I created attributes, dataelements, relationship and a program for
>>>> Mother Form, as follows:
>>>>  - Attribute : pre-pegnacy, housenumber, street, weight, apgar 1, apgar
>>>> 2, malformation.
>>>>  - Relationship: is mother of / is child of
>>>>  - Program : Mother Form with stages: Before to born, After to born and
>>>> Result
>>>>
>>>> and try to enter some forms.
>>>>
>>>> However, I do not created  the realationship for mother and child
>>>> objects (because when I choose the relationship to add,  the system reload
>>>> the page without saving the selected objects to create relationship).
>>>>
>>>> When will 

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Chau Thu Tran]

o bring these mandatory attributes to 
>>>> the
>>>> screen where we are entering patient parameters. So this implies two 
>>>> changes
>>>> then: the first one adding additional Boolean parameter with a value of
>>>> yes/no for attributes and the second one, at the bottom of the patient
>>>> registration screen (under name, sex, age), we need to list these mandatory
>>>> attributes and enforce users put values while registering patients. But for
>>>> this to work, pray that mandatory attributes are valid for all individuals
>>>> we will be registering. Other, if we have a scenario of mandatory for 
>>>> males,
>>>> females, mothers, children, then we are in trouble of slipping into
>>>> multiple registration forms varied for males, females, mothers, babies
>>>> -- what do you people think, especially those of you who have had the
>>>> experience of the field?
>>>>
>>>>
>>>> Tran, is this any thing helpful for the question you asked? I know you
>>>> asked me for specific places to put the functionality you are making ... 
>>>> but
>>>> I thought raising these issues will also guide you.
>>>>
>>>> Thank you
>>>>  Abyot.
>>>>
>>>>
>>>>
>>>> On Mon, Jan 25, 2010 at 10:36 AM, Chau Thu Tran <
>>>> tran.hispviet...@gmail.com> wrote:
>>>>
>>>>> Hi Abyot and others,
>>>>>
>>>>> I created the function of attribute group management. And now, I don't
>>>>> know where is suitable place to add that function. I thought to put on one
>>>>> of three places as below, but i am not sure.
>>>>> 1. Create groups property for patient and request users add it in new
>>>>> patient GUI
>>>>> 2. Create other function named Add Groups for each in list of patients.
>>>>> 3. Create combox to load all of groups existing in the system and
>>>>> end-user has to choose each group to enter attribute.
>>>>>
>>>>> What is your suggestion?
>>>>>
>>>>> 
>>>>> Châu Thu Trân
>>>>> HISP Viet Nam
>>>>> Email: tran.hispviet...@gmail.com
>>>>> Cell phone: +84 97 324 1542
>>>>> 
>>>>>
>>>>>
>>>>> On Thu, Jan 21, 2010 at 8:58 PM, Cong Duong Dinh <
>>>>> duong_dinhc...@hotmail.com> wrote:
>>>>>
>>>>>>  OK Tran that's good,
>>>>>> Try to go ahead..
>>>>>>
>>>>>> Duong Dinh Cong MD. PhD
>>>>>> Community Health Department
>>>>>> Medical School Pham Ngoc Thach
>>>>>> Home 22 Ho Huan Nghiep Q1 HCM City
>>>>>> 0903359924
>>>>>>
>>>>>> --- @ WiseStamp 
>>>>>> Signature<http://my.wisestamp.com/link?u=6zk6hnnyzjswmm3g&site=www.wisestamp.com/email-install>.
>>>>>> Get it 
>>>>>> now<http://my.wisestamp.com/link?u=6zk6hnnyzjswmm3g&site=www.wisestamp.com/email-install>
>>>>>>
>>>>>>
>>>>>> Duong Dinh Cong CUF/UTC 520 Ng Tri Phuong QX HCM-City Vietnam Tel 84 8
>>>>>> 8631383 Fax 84 8 650025
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Date: Thu, 21 Jan 2010 17:41:39 +0700
>>>>>>
>>>>>> Subject: Re: [Dhis2-devs] Greetings + new DHIS patient module
>>>>>> From: tran.hispviet...@gmail.com
>>>>>> To: aby...@gmail.com
>>>>>> CC: duong_dinhc...@hotmail.com; tranthanhtr...@gmail.com;
>>>>>> sam.hispviet...@gmail.com; thuy.hispviet...@gmail.com;
>>>>>> hieu.hispviet...@gmail.com; cata...@gmail.com
>>>>>>
>>>>>>
>>>>>> Hi Abyot,
>>>>>>
>>>>>> The Mother Form system has two objects, mother and child. There are
>>>>>> somes attributes belonging to mother that does not belong to child and 
>>>>>> vice
>>>>>> versa. For example, the atributes of mother are housenumber, street and 
>>>>>> pre-prefnacy
>>>>>> (***). And the attributes of child are infor

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Chau Thu Tran]

rote:
>>>
>>>> Hi Abyot and others,
>>>>
>>>> I created the function of attribute group management. And now, I don't
>>>> know where is suitable place to add that function. I thought to put on one
>>>> of three places as below, but i am not sure.
>>>> 1. Create groups property for patient and request users add it in new
>>>> patient GUI
>>>> 2. Create other function named Add Groups for each in list of patients.
>>>> 3. Create combox to load all of groups existing in the system and
>>>> end-user has to choose each group to enter attribute.
>>>>
>>>> What is your suggestion?
>>>>
>>>> ================
>>>> Châu Thu Trân
>>>> HISP Viet Nam
>>>> Email: tran.hispviet...@gmail.com
>>>> Cell phone: +84 97 324 1542
>>>> 
>>>>
>>>>
>>>> On Thu, Jan 21, 2010 at 8:58 PM, Cong Duong Dinh <
>>>> duong_dinhc...@hotmail.com> wrote:
>>>>
>>>>>  OK Tran that's good,
>>>>> Try to go ahead..
>>>>>
>>>>> Duong Dinh Cong MD. PhD
>>>>> Community Health Department
>>>>> Medical School Pham Ngoc Thach
>>>>> Home 22 Ho Huan Nghiep Q1 HCM City
>>>>> 0903359924
>>>>>
>>>>> --- @ WiseStamp 
>>>>> Signature<http://my.wisestamp.com/link?u=6zk6hnnyzjswmm3g&site=www.wisestamp.com/email-install>.
>>>>> Get it 
>>>>> now<http://my.wisestamp.com/link?u=6zk6hnnyzjswmm3g&site=www.wisestamp.com/email-install>
>>>>>
>>>>>
>>>>> Duong Dinh Cong CUF/UTC 520 Ng Tri Phuong QX HCM-City Vietnam Tel 84 8
>>>>> 8631383 Fax 84 8 650025
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Date: Thu, 21 Jan 2010 17:41:39 +0700
>>>>>
>>>>> Subject: Re: [Dhis2-devs] Greetings + new DHIS patient module
>>>>> From: tran.hispviet...@gmail.com
>>>>> To: aby...@gmail.com
>>>>> CC: duong_dinhc...@hotmail.com; tranthanhtr...@gmail.com;
>>>>> sam.hispviet...@gmail.com; thuy.hispviet...@gmail.com;
>>>>> hieu.hispviet...@gmail.com; cata...@gmail.com
>>>>>
>>>>>
>>>>> Hi Abyot,
>>>>>
>>>>> The Mother Form system has two objects, mother and child. There are
>>>>> somes attributes belonging to mother that does not belong to child and 
>>>>> vice
>>>>> versa. For example, the atributes of mother are housenumber, street and 
>>>>> pre-prefnacy
>>>>> (***). And the attributes of child are information when to be born,
>>>>> include apgar 1, apgar 5, weight and malformation
>>>>>
>>>>> When I build attributes for the object in your module, I have to define
>>>>> all of  the attributes of the mother and child. So, when to create a new
>>>>> object and input attributes for it, all of the attributes of both objects
>>>>> are displayed in the form. How do you think if we have a function to group
>>>>> attributes of each.
>>>>>
>>>>> Now, I created attributes, dataelements, relationship and a program for
>>>>> Mother Form, as follows:
>>>>>  - Attribute : pre-pegnacy, housenumber, street, weight, apgar 1, apgar
>>>>> 2, malformation.
>>>>>  - Relationship: is mother of / is child of
>>>>>  - Program : Mother Form with stages: Before to born, After to born and
>>>>> Result
>>>>>
>>>>> and try to enter some forms.
>>>>>
>>>>> However, I do not created  the realationship for mother and child
>>>>> objects (because when I choose the relationship to add,  the system reload
>>>>> the page without saving the selected objects to create relationship).
>>>>>
>>>>> When will we be able to start develop with you in this patient system ?
>>>>>
>>>>> --
>>>>> *** pre-pregnacy : it has four digits.
>>>>>   - First: number of *unpremature-birth* children
>>>>>   - Second : number of *premature-birth* children
>>>>>   - Third:  number of *abortion*
>>>>> *  *- Forth

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Hieu Dang Duy]

Dear Abyota*,*

I'm trying to follow your working on Patient module so that I've got some
questions wanna ask you like this:
*
Creating attribute group*

>
> For step 1 you can follow the approach we have in DataElements and
> DataElementGroups. At the same I would suggest for a restriction of putting
> an attribute only in one group - otherwise it will be ugly down the road.
> Because, for example in your case of permanent and temporary address
>
> Temporary Address Group
>
>- street
>- village
>- province
>- ...
>- ..
>- phone
>
> then Permanent Address Group arrangement of the same attributes
>
>- street
>- village
>- province
>- ...
>- ..
>- phone
>
> will create a problem in fetching the values ... otherwise we need to also
> store attribute group id when persisting attribute values.I prefer to
> append something like "temp" and create slightly different attributes than
> persisting attribute group id when storing attribute values - I don't know
> others can comment on this and come up with a better suggestion.
>
>
You suggested that the attribute group and attributes which have a
relationship as one to many, didn't you? But the approach in Dataelement
management with the relationship is many to many.

Btw, you said also that *"otherwise we need to also store attribute group id
when persisting attribute values" *but its seemly opposite to *"I prefer to
append something like "temp" and create slightly different attributes
than persisting
attribute group id when storing attribute values"*.

Or I'm misunderstanding your idea?

On the other hand, Can you please explaining to me more about
*PatientIdentifier
*and *PatientIdentifierType*. What are they used for ?

Thanks !

-- 
Hieu.HISPVietnam
Good Health !
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Abyot Gizaw]

Hi Tran,

Great that you already started working on the attribute group .. and
treating the whole thing as a two step process will be nice

   1. creating  the attribute group  with all the parameters it is
   required to have - including assigning/reassigning attribute(s)
   2. assigning attribute(s) to patients

*Creating attribute group*

For step 1 you can follow the approach we have in DataElements and
DataElementGroups. At the same I would suggest for a restriction of putting
an attribute only in one group - otherwise it will be ugly down the road.
Because, for example in your case of permanent and temporary address

Temporary Address Group

   - street
   - village
   - province
   - ...
   - ..
   - phone

then Permanent Address Group arrangement of the same attributes

   - street
   - village
   - province
   - ...
   - ..
   - phone

will create a problem in fetching the values ... otherwise we need to also
store attribute group id when persisting attribute values.I prefer to
append something like "temp" and create slightly different attributes than
persisting attribute group id when storing attribute values - I don't know
others can comment on this and come up with a better suggestion.

*Assigning attributes to patients*

We need to make a little adjustment for this one. Because if we plan to
enforce users put value, the moment they register a patient, for some
selected attributes, then we need to bring these mandatory attributes to the
screen where we are entering patient parameters. So this implies two changes
then: the first one adding additional Boolean parameter with a value of
yes/no for attributes and the second one, at the bottom of the patient
registration screen (under name, sex, age), we need to list these mandatory
attributes and enforce users put values while registering patients. But for
this to work, pray that mandatory attributes are valid for all individuals
we will be registering. Other, if we have a scenario of mandatory for males,
females, mothers, children, then we are in trouble of slipping into
multiple registration forms varied for males, females, mothers, babies
-- what do you people think, especially those of you who have had the
experience of the field?


Tran, is this any thing helpful for the question you asked? I know you asked
me for specific places to put the functionality you are making ... but I
thought raising these issues will also guide you.

Thank you
Abyot.


On Mon, Jan 25, 2010 at 10:36 AM, Chau Thu Tran
wrote:

> Hi Abyot and others,
>
> I created the function of attribute group management. And now, I don't know
> where is suitable place to add that function. I thought to put on one of
> three places as below, but i am not sure.
> 1. Create groups property for patient and request users add it in new
> patient GUI
> 2. Create other function named Add Groups for each in list of patients.
> 3. Create combox to load all of groups existing in the system and end-user
> has to choose each group to enter attribute.
>
> What is your suggestion?
>
> 
> Châu Thu Trân
> HISP Viet Nam
> Email: tran.hispviet...@gmail.com
> Cell phone: +84 97 324 1542
> 
>
>
> On Thu, Jan 21, 2010 at 8:58 PM, Cong Duong Dinh <
> duong_dinhc...@hotmail.com> wrote:
>
>>  OK Tran that's good,
>> Try to go ahead..
>>
>> Duong Dinh Cong MD. PhD
>> Community Health Department
>> Medical School Pham Ngoc Thach
>> Home 22 Ho Huan Nghiep Q1 HCM City
>> 0903359924
>>
>> --- @ WiseStamp 
>> Signature<http://my.wisestamp.com/link?u=6zk6hnnyzjswmm3g&site=www.wisestamp.com/email-install>.
>> Get it 
>> now<http://my.wisestamp.com/link?u=6zk6hnnyzjswmm3g&site=www.wisestamp.com/email-install>
>>
>>
>> Duong Dinh Cong CUF/UTC 520 Ng Tri Phuong QX HCM-City Vietnam Tel 84 8
>> 8631383 Fax 84 8 650025
>>
>>
>>
>> --
>> Date: Thu, 21 Jan 2010 17:41:39 +0700
>>
>> Subject: Re: [Dhis2-devs] Greetings + new DHIS patient module
>> From: tran.hispviet...@gmail.com
>> To: aby...@gmail.com
>> CC: duong_dinhc...@hotmail.com; tranthanhtr...@gmail.com;
>> sam.hispviet...@gmail.com; thuy.hispviet...@gmail.com;
>> hieu.hispviet...@gmail.com; cata...@gmail.com
>>
>>
>> Hi Abyot,
>>
>> The Mother Form system has two objects, mother and child. There are somes
>> attributes belonging to mother that does not belong to child and vice versa.
>> For example, the atributes of mother are housenumber, street and pre-prefnacy
>> (***). And the attributes of child are information when to be born,
>> include apgar 1, apgar 5, weight and malformation
>>
>

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Chau Thu Tran]

Hi Abyot and others,

I created the function of attribute group management. And now, I don't know
where is suitable place to add that function. I thought to put on one of
three places as below, but i am not sure.
1. Create groups property for patient and request users add it in new
patient GUI
2. Create other function named Add Groups for each in list of patients.
3. Create combox to load all of groups existing in the system and end-user
has to choose each group to enter attribute.

What is your suggestion?


Châu Thu Trân
HISP Viet Nam
Email: tran.hispviet...@gmail.com
Cell phone: +84 97 324 1542



On Thu, Jan 21, 2010 at 8:58 PM, Cong Duong Dinh  wrote:

>  OK Tran that's good,
> Try to go ahead..
>
> Duong Dinh Cong MD. PhD
> Community Health Department
> Medical School Pham Ngoc Thach
> Home 22 Ho Huan Nghiep Q1 HCM City
> 0903359924
>
> --- @ WiseStamp 
> Signature<http://my.wisestamp.com/link?u=6zk6hnnyzjswmm3g&site=www.wisestamp.com/email-install>.
> Get it 
> now<http://my.wisestamp.com/link?u=6zk6hnnyzjswmm3g&site=www.wisestamp.com/email-install>
>
>
> Duong Dinh Cong CUF/UTC 520 Ng Tri Phuong QX HCM-City Vietnam Tel 84 8
> 8631383 Fax 84 8 650025
>
>
>
> --------------
> Date: Thu, 21 Jan 2010 17:41:39 +0700
> Subject: Re: [Dhis2-devs] Greetings + new DHIS patient module
> From: tran.hispviet...@gmail.com
> To: aby...@gmail.com
> CC: duong_dinhc...@hotmail.com; tranthanhtr...@gmail.com;
> sam.hispviet...@gmail.com; thuy.hispviet...@gmail.com;
> hieu.hispviet...@gmail.com; cata...@gmail.com
>
>
> Hi Abyot,
>
> The Mother Form system has two objects, mother and child. There are somes
> attributes belonging to mother that does not belong to child and vice versa.
> For example, the atributes of mother are housenumber, street and pre-prefnacy
> (***). And the attributes of child are information when to be born,
> include apgar 1, apgar 5, weight and malformation
>
> When I build attributes for the object in your module, I have to define all
> of  the attributes of the mother and child. So, when to create a new object
> and input attributes for it, all of the attributes of both objects are
> displayed in the form. How do you think if we have a function to group
> attributes of each.
>
> Now, I created attributes, dataelements, relationship and a program for
> Mother Form, as follows:
>  - Attribute : pre-pegnacy, housenumber, street, weight, apgar 1, apgar 2,
> malformation.
>  - Relationship: is mother of / is child of
>  - Program : Mother Form with stages: Before to born, After to born and
> Result
>
> and try to enter some forms.
>
> However, I do not created  the realationship for mother and child objects
> (because when I choose the relationship to add,  the system reload the page
> without saving the selected objects to create relationship).
>
> When will we be able to start develop with you in this patient system ?
>
> --
> *** pre-pregnacy : it has four digits.
>   - First: number of *unpremature-birth* children
>   - Second : number of *premature-birth* children
>   - Third:  number of *abortion*
> *  *- Forth: number of *alive *children
>   Example: a mother A has a unpremature-birth child --> pre-pregnacy
> is 1001
>
> 2010/1/21 Chau Thu Tran 
>
> Chào thầy và các bạn
>
> Em đã tạo các DEs của phiếu sanh để test thử module DHIS2 và phát hiện một
> số vấn đề (đã gửi mail và Abyot đã trả lời mail ).
>
> Em đang thảo luận với Abyot về các vấn đề khi áp dụng chương trình Patient
> cho Việt Nam. Sau khi đã rõ ràng về requirements ở Việt Nam, em sẽ thảo luận
> tiếp các việc phải làm cho module này.
>
>
> Great that you have started looking into the patient module of DHIS2. The
> advantage with this module is that it is part of DHIS2 - no installation of
> other system and also easy sharing of dataelements and orgunits defined
> under DHIS2.
>
> Below is a little clarification for some of the questions you raised.
>
>1. *Issue with multiple address* - Address is a little tricky concept,
>I believe. If treated with a single object, say for example Address, and 
> set
>of attributes then we will end up in a difficulty of entertaining all the
>possible definitions an address is supposed to have. For a global software
>like DHIS2 we need to treat the address concept as open as possible there 
> by
>allowing a flexibility for specific local definitions of addresses. So how
>we treat address is then is using objects PersonAttribute and
>PersonAttributeValue. Using PersonAttribute we can create as many custom
>objects as p

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Abyot Gizaw]

2010/1/21 Chau Thu Tran 

> Hi Abyot,
>
> The Mother Form system has two objects, mother and child. There are somes
> attributes belonging to mother that does not belong to child and vice versa.
> For example, the atributes of mother are housenumber, street and pre-prefnacy
> (***). And the attributes of child are information when to be born,
> include apgar 1, apgar 5, weight and malformation
>
> When I build attributes for the object in your module, I have to define all
> of  the attributes of the mother and child. So, when to create a new object
> and input attributes for it, all of the attributes of both objects are
> displayed in the form. How do you think if we have a function to group
> attributes of each.
>
> Now, I created attributes, dataelements, relationship and a program for
> Mother Form, as follows:
>  - Attribute : pre-pegnacy, housenumber, street, weight, apgar 1, apgar 2,
> malformation.
>  - Relationship: is mother of / is child of
>  - Program : Mother Form with stages: Before to born, After to born and
> Result
>
> and try to enter some forms.
>
> However, I do not created  the realationship for mother and child objects
> (because when I choose the relationship to add,  the system reload the page
> without saving the selected objects to create relationship).
>
> When will we be able to start develop with you in this patient system ?
>
>
Hi Tran,

Ready to work in the patient module? Last time I was telling you to develop
grouping functionality for PatientAttributes.

Abyot.


--
> *** pre-pregnacy : it has four digits.
>   - First: number of *unpremature-birth* children
>   - Second : number of *premature-birth* children
>   - Third:  number of *abortion*
> *  *- Forth: number of *alive *children
>   Example: a mother A has a unpremature-birth child --> pre-pregnacy
> is 1001
>
> 2010/1/21 Chau Thu Tran 
>
>> Chào thầy và các bạn
>>
>> Em đã tạo các DEs của phiếu sanh để test thử module DHIS2 và phát hiện một
>> số vấn đề (đã gửi mail và Abyot đã trả lời mail ).
>>
>> Em đang thảo luận với Abyot về các vấn đề khi áp dụng chương trình Patient
>> cho Việt Nam. Sau khi đã rõ ràng về requirements ở Việt Nam, em sẽ thảo luận
>> tiếp các việc phải làm cho module này.
>>
>>
>>> Great that you have started looking into the patient module of DHIS2. The
>>> advantage with this module is that it is part of DHIS2 - no installation of
>>> other system and also easy sharing of dataelements and orgunits defined
>>> under DHIS2.
>>>
>>> Below is a little clarification for some of the questions you raised.
>>>
>>>1. *Issue with multiple address* - Address is a little tricky
>>>concept, I believe. If treated with a single object, say for example
>>>Address, and set of attributes then we will end up in a difficulty of
>>>entertaining all the possible definitions an address is supposed to have.
>>>For a global software like DHIS2 we need to treat the address concept as
>>>open as possible there by allowing a flexibility for specific local
>>>definitions of addresses. So how we treat address is then is using 
>>> objects
>>>PersonAttribute and PersonAttributeValue. Using PersonAttribute we can
>>>create as many custom objects as possible - say for example StreetAddress
>>>with a datavalue type of text, HouseNumber with a datavalue type of 
>>> number
>>>or text, PhoneNumber with number, ... any custom object with 
>>> datavalue
>>>type of text/number/yes_no/date... once we defined such custom 
>>> objects,
>>>we can latter put specific values through PersonAttributeValue. My
>>>suggestion for your case will be to define the parameters of your 
>>> temporary
>>>and resident addresses as PersonAttributes and for each person attribute
>>>create a person attribute value - then latter you can group these 
>>> attributes
>>>into "Temporary Address" and "Resident Address" of course we 
>>> need to
>>>first provide a functionality for grouping of person attributes
>>>
>>>
>>
>>>
>>>1. *Integration with DataElements* - Yes the patient module uses
>>>dataelements defined under DHIS2. But to avoid confusion with the value
>>>types and aggregation operation we have introduced an attribute called
>>>domainType with a possible values of patient and aggregate for the time
>>>being. The reason for this is for example in the patient module you might
>>>only be interested in putting a yes or no value for a specific vaccine 
>>> type,
>>>but in the aggregate/DHIS you might only be interested in knowing for how
>>>many babies this specific vaccine is given. So the bottom line is when
>>>defining your dataelements specify for which domain you are creating them
>>>--- then those with patient type will appear in the patient module and 
>>> those
>>>with aggregate type will appear in DHIS
>>>2. *Health Program Stage* - this is to handle specific stages of a
>>>health p

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Abyot Gizaw]

Hi Tran,

Ok, now I got it :)

You want to see only those attributes that you intened to fill - for example
you don't want to see attributes like apgarXXX when dealing with Mother; and
also things related with pre-pregnancy when dealing with babies. Is that
your quesion?

If so then we can solve this by implementing a new feature - *Attribute
Group* - which I suggested in my earlier mail. If we have this feature we
can think of groups like containing mandatory attributes and optional
attributes. In the mandatory group we put all attributes we think will be
common for all individuals - be it baby, mother, male or female,. Then
we can think of other groups like "Attributes for Mothers", "Attributes for
Babies",... then everytime you register an individual you should also
specify the attributes you want to record data for by choosing attribute
group(s) and only those attributes associated will be shown for when you try
to record data. By default all individuals need to have the mandatory
attribute group.

So, this I think is a perfect opportunity for you to start working on the
patient module. Checkout the code, see the internals of the patient module
and start working in implementing the new feature suggested - *Attribute
Group*. Then we will move to other issues?

You can always ask for any question you will have ... but make sure you send
your mails to the devs list so that others can also comment.

Abyot.

2010/1/21 Chau Thu Tran 

> Hi Abyot,
>
> The Mother Form system has two objects, mother and child. There are somes
> attributes belonging to mother that does not belong to child and vice versa.
> For example, the atributes of mother are housenumber, street and pre-prefnacy
> (***). And the attributes of child are information when to be born,
> include apgar 1, apgar 5, weight and malformation
>
> When I build attributes for the object in your module, I have to define all
> of  the attributes of the mother and child. So, when to create a new object
> and input attributes for it, all of the attributes of both objects are
> displayed in the form. How do you think if we have a function to group
> attributes of each.
>
> Now, I created attributes, dataelements, relationship and a program for
> Mother Form, as follows:
>  - Attribute : pre-pegnacy, housenumber, street, weight, apgar 1, apgar 2,
> malformation.
>  - Relationship: is mother of / is child of
>  - Program : Mother Form with stages: Before to born, After to born and
> Result
>
> and try to enter some forms.
>
> However, I do not created  the realationship for mother and child objects
> (because when I choose the relationship to add,  the system reload the page
> without saving the selected objects to create relationship).
>
> When will we be able to start develop with you in this patient system ?
>
> --
> *** pre-pregnacy : it has four digits.
>   - First: number of *unpremature-birth* children
>   - Second : number of *premature-birth* children
>   - Third:  number of *abortion*
> *  *- Forth: number of *alive *children
>   Example: a mother A has a unpremature-birth child --> pre-pregnacy
> is 1001
>
> 2010/1/21 Chau Thu Tran 
>
>> Chào thầy và các bạn
>>
>> Em đã tạo các DEs của phiếu sanh để test thử module DHIS2 và phát hiện một
>> số vấn đề (đã gửi mail và Abyot đã trả lời mail ).
>>
>> Em đang thảo luận với Abyot về các vấn đề khi áp dụng chương trình Patient
>> cho Việt Nam. Sau khi đã rõ ràng về requirements ở Việt Nam, em sẽ thảo luận
>> tiếp các việc phải làm cho module này.
>>
>>
>>> Great that you have started looking into the patient module of DHIS2. The
>>> advantage with this module is that it is part of DHIS2 - no installation of
>>> other system and also easy sharing of dataelements and orgunits defined
>>> under DHIS2.
>>>
>>> Below is a little clarification for some of the questions you raised.
>>>
>>>1. *Issue with multiple address* - Address is a little tricky
>>>concept, I believe. If treated with a single object, say for example
>>>Address, and set of attributes then we will end up in a difficulty of
>>>entertaining all the possible definitions an address is supposed to have.
>>>For a global software like DHIS2 we need to treat the address concept as
>>>open as possible there by allowing a flexibility for specific local
>>>definitions of addresses. So how we treat address is then is using 
>>> objects
>>>PersonAttribute and PersonAttributeValue. Using PersonAttribute we can
>>>create as many custom objects as possible - say for example StreetAddress
>>>with a datavalue type of text, HouseNumber with a datavalue type of 
>>> number
>>>or text, PhoneNumber with number, ... any custom object with 
>>> datavalue
>>>type of text/number/yes_no/date... once we defined such custom 
>>> objects,
>>>we can latter put specific values through PersonAttributeValue. My
>>>suggestion for your case will be to define the parameters of your 
>>> temp

Re: [Dhis2-devs] Greetings + new DHIS patient module

[Abyot Gizaw]

Dear Tran, Thuy, Kim and others,

Great that you have started looking into the patient module of DHIS2. The
advantage with this module is that it is part of DHIS2 - no installation of
other system and also easy sharing of dataelements and orgunits defined
under DHIS2.

Below is a little clarification for some of the questions you raised.

   1. *Issue with multiple address* - Address is a little tricky concept, I
   believe. If treated with a single object, say for example Address, and set
   of attributes then we will end up in a difficulty of entertaining all the
   possible definitions an address is supposed to have. For a global software
   like DHIS2 we need to treat the address concept as open as possible there by
   allowing a flexibility for specific local definitions of addresses. So how
   we treat address is then is using objects PersonAttribute and
   PersonAttributeValue. Using PersonAttribute we can create as many custom
   objects as possible - say for example StreetAddress with a datavalue type of
   text, HouseNumber with a datavalue type of number or text, PhoneNumber with
   number, ... any custom object with datavalue type of
   text/number/yes_no/date... once we defined such custom objects, we can
   latter put specific values through PersonAttributeValue. My suggestion for
   your case will be to define the parameters of your temporary and resident
   addresses as PersonAttributes and for each person attribute create a person
   attribute value - then latter you can group these attributes into "Temporary
   Address" and "Resident Address" of course we need to first provide a
   functionality for grouping of person attributes
   2. *Integration with DataElements* - Yes the patient module uses
   dataelements defined under DHIS2. But to avoid confusion with the value
   types and aggregation operation we have introduced an attribute called
   domainType with a possible values of patient and aggregate for the time
   being. The reason for this is for example in the patient module you might
   only be interested in putting a yes or no value for a specific vaccine type,
   but in the aggregate/DHIS you might only be interested in knowing for how
   many babies this specific vaccine is given. So the bottom line is when
   defining your dataelements specify for which domain you are creating them
   --- then those with patient type will appear in the patient module and those
   with aggregate type will appear in DHIS
   3. *Health Program Stage* - this is to handle specific stages of a health
   program - because you might have multiple encounters for a given health
   program. For example in your case there will be a scenario where a pregnant
   woman will be treated for her first trimester, second trimester and/or third
   trimester once she is in "ANC Program". This encounters in most cases are
   mandatory, of course there will be dropouts in some cases, which a pregnant
   woman should go through once she is in the "ANC Program". So when creating a
   health program you can also define the specific stages of the health
   program. Because you will be recording observations (collecting values)
   during each of these specific stages, then you associate dataelements with
   program stages not programs. To make it more general a health program can
   have one or more program stages - like you observe a patients cases once or
   multiple times. This approach works fine for ANC, Immunization, TB,
   Malaria,
   4. *Date of Incidence* - Let's say you define a health program and its
   stages as mentioned above. And a person comes for treatment, say for example
   pregnant woman. Then the system should automatically generate visit dates
   for the subsequent ANC visits - or program stages. But to generate these
   visit schedules we need to ask the mother when is the first time she got
   pregnant, or in the standard ANC term ??LMP Date??. The day she came for
   treatment might not necessarily be the day she got pregnant, therefore for a
   better treatment (by having appropriate visit dates) it will be nice if we
   can get information about the date she got pregnant - that is what the Date
   of Incidence is all about. The same logic also works for a TB patient for
   example - the date the person came for treatment might not necessarily be
   the date he/she got the disease --- so better to know the date of incidence.
   5. *Custom Data Entry Form and Reports *- I think Viet has answered this
   partly - as he is working on custom data entry screens. What we have right
   now is more of a generic framework - input screens, reports layouts,... are
   something which we need to further work for specific implementations.
   6. *Relationships* - Yes we can define any relationship types and link
   individuals through these relationship types by creating specific
   relationships.And we have this feature currently. What is missing is where
   to specifically use these relatio