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 :-) ] 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 <sun...@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 ;-) > > *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 :( > > *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.h...@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 >> 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. >> >> >> >> > > _______________________________________________ > Mailing list: > https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs> > Post to : dhis2-devs@lists.launchpad.net > Unsubscribe : > https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-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
