dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #04017
Re: Tasks for community system
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.hisp@xxxxxxxxx> 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.
>
>
>
>
Follow ups
References