Tasks for community system

Hi Abyot,

Its good idea to add attribute Group. Some more requirement or change that is required in attribute are

  1. It have a compulsory field: which is mandatory to entry this would be good to identify duplication patient registration

  2. To have option in attribute file just like catergory option so that the patient can select it and we can avoid free text.

Apart from Attribute some more requirements are:

Program:

In your mail you have explained about date of incident. When we implement it hard to get this message across different people. What will be good is to have two more field in the program saying date of incident description and date of enrollment description: As for Mother care program the date of Incident is LMP date and date of enrolment is when the pregnant women come to clinic. Where as for child health program the date of incident is date of birth and date of enrolment is when baby comes to hospital.

Patient module

there are list of modification while adding a patient.

Currently in the system we first add the patient primary information and then fill the attribute. We have to change that. We should not add a patient unless we are sure that its not a duplicate registration. For doing that we need to check the patient at two level one at the Identifier which patient/case specify whether it already in the system and the other place is the combination of name, age/dob, address/contact number/ or husband name. once we have the confirmation we should add the patient not before. In case of child their mother information should be given if mother information is already there we should check the dob of the child if it is already in the system. Incase of twins or more we should display a message that this mother already have child with dob blabla is this a twin.

blood group should be moved from the attribute section to patient as when we inherit the parent attribute this should not be copied. and it static for a case.

not all the orgunit will be having patient registration. it depend on particular orgunit. Yes sevices can be provided at any orgunit but patient registration should be done in specific orgunit. Thus we should have a facility like assiging dataset to orgunit even for adding/ modify patient.

Searching Patient

We have single search depending on the attribute but we need to improve it by added nested search. to search within the searched result.

**System generated unique number: **

currently the system will generate identifier as orgunitname plus some number. This should be change to system generate unique number without any meaning associated to the unique number. Just a random number.

Excellent suggestions from John and some of them are critical…

Identifiers Vs Attributes
I’m quite sure we should not mix the concepts of identifier and attributes. Attributes are characteristics of a person (e.g. Blood group) where as Identifiers are searchable and unique characteristics to the context of search/data store (e.g. Passport no.). and hence searching people while registration on attributes for uniqueness isn’t quite recommended. Searching on identifiers is the right thing and we can make some identifiers compulsory and there should be these compulsory identifiers (mayb an implementation wants fingerprints as compulsory and primary identification… So we should compulsorily want fingerprints for all) for correct identification of the patient on revisit. Categories on attributes are critical for things like Blood group, where we know the possible answers.

Names of Data Elements
We should be able to give multiple names/synonyms/simple names to every data element especially when we have reached the medical informatics domain. Date of incident/LMP/Birthdate is just one example, but more keep coming in these requirement-customization meetings. Shakespeare got it wrong when he said, “What’s in a name”… to me it seems to be all in the name :wink:

Inheritable Attributes
We should be able to select which are inheritable attributes and which are not, when creating new attributes. Blood group is not an inheritable attribute, but caste may be an inheritable attribute. Address I’m not sure is an attribute or not… but that’s a different complexity all together :frowning:

Searching on Identifiers Vs Attributes
Searching on identifiers should “nearly” always result in single results… I say “nearly” because we could badly design identifiers, location-specific identifiers, remote sites, independently generated identifiers etc. But definitely searching on attributes, should be nested. I would actually say searching on attributes should not be internally any different from searching on data elements and should allow composition…

I’ll finish it… No need to re-invent the wheel…

···

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

On 23 January 2010 07:19, John lewis johnlewis.hisp@gmail.com wrote:

Hi Abyot,
Its good idea to add attribute Group. Some more requirement or change that is required in attribute are

  1. It have a compulsory field: which is mandatory to entry this would be good to identify duplication patient registration
  1. To have option in attribute file just like catergory option so that the patient can select it and we can avoid free text.

Apart from Attribute some more requirements are:

Program:

In your mail you have explained about date of incident. When we implement it hard to get this message across different people. What will be good is to have two more field in the program saying date of incident description and date of enrollment description: As for Mother care program the date of Incident is LMP date and date of enrolment is when the pregnant women come to clinic. Where as for child health program the date of incident is date of birth and date of enrolment is when baby comes to hospital.

Patient module

there are list of modification while adding a patient.

Currently in the system we first add the patient primary information and then fill the attribute. We have to change that. We should not add a patient unless we are sure that its not a duplicate registration. For doing that we need to check the patient at two level one at the Identifier which patient/case specify whether it already in the system and the other place is the combination of name, age/dob, address/contact number/ or husband name. once we have the confirmation we should add the patient not before. In case of child their mother information should be given if mother information is already there we should check the dob of the child if it is already in the system. Incase of twins or more we should display a message that this mother already have child with dob blabla is this a twin.

blood group should be moved from the attribute section to patient as when we inherit the parent attribute this should not be copied. and it static for a case.

not all the orgunit will be having patient registration. it depend on particular orgunit. Yes sevices can be provided at any orgunit but patient registration should be done in specific orgunit. Thus we should have a facility like assiging dataset to orgunit even for adding/ modify patient.

Searching Patient

We have single search depending on the attribute but we need to improve it by added nested search. to search within the searched result.

**System generated unique number: **

currently the system will generate identifier as orgunitname plus some number. This should be change to system generate unique number without any meaning associated to the unique number. Just a random number.

Hi

Lots of important issues emerging here which is great. A few general comments:

I do agree with Saptarshi regarding distinguishing between names and unique identifiers. The principle of keeping these two concepts divorced is generally well documented. The use of the name as the determinant of uniqueness in dhis may well start to become more of a hindrance than a help. But moving away from it is also not a simple proposition. There are many possibilities including URI based schemes but they have to looked at carefully in terms of maintainability, efficiency and suitability. And the name-based uniqueness idea is quite deeply ingrained in much of the existing model so any proposal to change this should be made with full awareness of the challenge.

On the issue of attributes, I think it has opened an area of dhis which is ripe for the “next step”. Prior to the flexible person-attributes model there was not a way to add generic metadata to dhis entitities - be they persons, dataelements, indicators, categories or what have you. If we needed more metadata about an entity we added another field. Or a bunch of them as in extended dataelement. What Abyot has now done, by creating attributes on person, opens up a vision of the possibility of a richer metadata model for dhis. It would be good to think more generally about this before reacting to the requirements coming in as a result of new possibilities being exposed. [ie. respond rather than react. Be responsive not reactionary :slight_smile: ]

Two questions which spring to my mind are:

  1. If persons can have attributes then couldn’t other entities also have them? What would be required to facilitate this? Currently, for example, if we import a rich set of indicator descriptions which has tags which we can’t match then we end up with a lossy import. The same could be true of a set of organisation units, persons or what ever. Ideally we should be able to extend metadata about an object dynamically.

  2. As soon as we start adding metadata, like with a person, it seems that it immediately throws up new requirements to group them, tag them, categorize them etc. Before we end up reinventing what can be a complex wheel I would suggest that it might be worth looking at some existing standards in the area of metadata, like for example RDF. And look at how we can better interact with things like the OpenMRS concept dictionary, SDMX etc.

I wonder do we have any metadata fundi’s out there would care to investigate where we might go with this?

Cheers
Bob

···

On 23 January 2010 18:37, Saptarshi Purkayastha sunbiz@gmail.com wrote:

Excellent suggestions from John and some of them are critical…

Identifiers Vs Attributes

I’m quite sure we should not mix the concepts of identifier and attributes. Attributes are characteristics of a person (e.g. Blood group) where as Identifiers are searchable and unique characteristics to the context of search/data store (e.g. Passport no.). and hence searching people while registration on attributes for uniqueness isn’t quite recommended. Searching on identifiers is the right thing and we can make some identifiers compulsory and there should be these compulsory identifiers (mayb an implementation wants fingerprints as compulsory and primary identification… So we should compulsorily want fingerprints for all) for correct identification of the patient on revisit. Categories on attributes are critical for things like Blood group, where we know the possible answers.

Names of Data Elements
We should be able to give multiple names/synonyms/simple names to every data element especially when we have reached the medical informatics domain. Date of incident/LMP/Birthdate is just one example, but more keep coming in these requirement-customization meetings. Shakespeare got it wrong when he said, “What’s in a name”… to me it seems to be all in the name :wink:

Inheritable Attributes
We should be able to select which are inheritable attributes and which are not, when creating new attributes. Blood group is not an inheritable attribute, but caste may be an inheritable attribute. Address I’m not sure is an attribute or not… but that’s a different complexity all together :frowning:

Searching on Identifiers Vs Attributes
Searching on identifiers should “nearly” always result in single results… I say “nearly” because we could badly design identifiers, location-specific identifiers, remote sites, independently generated identifiers etc. But definitely searching on attributes, should be nested. I would actually say searching on attributes should not be internally any different from searching on data elements and should allow composition…

I’ll finish it… No need to re-invent the wheel…


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

On 23 January 2010 07:19, John lewis johnlewis.hisp@gmail.com wrote:

Hi Abyot,
Its good idea to add attribute Group. Some more requirement or change that is required in attribute are

  1. It have a compulsory field: which is mandatory to entry this would be good to identify duplication patient registration
  1. To have option in attribute file just like catergory option so that the patient can select it and we can avoid free text.

Apart from Attribute some more requirements are:

Program:

In your mail you have explained about date of incident. When we implement it hard to get this message across different people. What will be good is to have two more field in the program saying date of incident description and date of enrollment description: As for Mother care program the date of Incident is LMP date and date of enrolment is when the pregnant women come to clinic. Where as for child health program the date of incident is date of birth and date of enrolment is when baby comes to hospital.

Patient module

there are list of modification while adding a patient.

Currently in the system we first add the patient primary information and then fill the attribute. We have to change that. We should not add a patient unless we are sure that its not a duplicate registration. For doing that we need to check the patient at two level one at the Identifier which patient/case specify whether it already in the system and the other place is the combination of name, age/dob, address/contact number/ or husband name. once we have the confirmation we should add the patient not before. In case of child their mother information should be given if mother information is already there we should check the dob of the child if it is already in the system. Incase of twins or more we should display a message that this mother already have child with dob blabla is this a twin.

blood group should be moved from the attribute section to patient as when we inherit the parent attribute this should not be copied. and it static for a case.

not all the orgunit will be having patient registration. it depend on particular orgunit. Yes sevices can be provided at any orgunit but patient registration should be done in specific orgunit. Thus we should have a facility like assiging dataset to orgunit even for adding/ modify patient.

Searching Patient

We have single search depending on the attribute but we need to improve it by added nested search. to search within the searched result.

**System generated unique number: **

currently the system will generate identifier as orgunitname plus some number. This should be change to system generate unique number without any meaning associated to the unique number. Just a random number.


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