dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

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 relationships, and I think this again depends on
   specific implementations. I think of displaying relationship types in
   reports and dataentry screens
   7. *Registering a newly born baby *- This I would say is a limitation of
   the system ... if you all think we can't assign a name for a newly born baby
   before giving the baby any treatment we will be recording in our system. My
   argument is any individual should first be registered in the system before
   getting any treatment which we will be interested to record data for - I
   could be wrong :)

Hope I have addressed all your questions, but I couldn't understand one of
your question shown below

"The program have two objects, mother and child. They have some different
properties. For example, mother has pre-pregnacy, child has apgar 1, apgar
5, malformation. We defines all of attributes for the objects. Because the
system doesn't separates objects, so when to create a branch new object and
input the attributes to it, the system show all of the attributes.How do you
only show information for each object ?"


Thank you
Abyot.


2010/1/21 Kim Anh Thi Vo <catakim@xxxxxxxxx>

> hei all,
>
> How's it going?
>
> Thanks for the reply!
>
> 2010/1/20 Jørn Braa <jornbraa@xxxxxxxxx>
>
> Hi all,
>> I suggest that
>> Tran and Abyot work together on the DHIS patient module and that
>>  we implement the patient module on the Mother and Child records in
>> the centre  - and maybe other areas, and
>>  use the concrete Vietnamese useers requirements and use situation to
>> make the module much better.
>>
>
> I checked out the DHIS patient module yesterday and it seems very open and
> good with design... simple, flexible and intergatable.
> Referring to the explaination by Jørn a few days ago, this module is clear
> to me :)
> And here is some questions I'd like to ask Abyot maybe about this module:
>
> 1. I created patients with all attributes + add some more ones (esp. the
> case in Vietnam... there are two address: "current address" and "permanent
> address", etc.) and then created some relationships (for example, for Mother
> and Child programs, that is "is a mother of", "is a child of"), but when
> going back to the patient lists to assign the relationship... this function
> couldn't be through... choosing the list of relationships but nothing
> HAPPEND next...???
> 2. I see the integration part for Program with DAEL... but don't know how
> to link/integrate with the current/existing DAELs of DHIS2?
> 3. About come concepts:
> 3.1. Incident? What is "Date of incident"?
> 3.2. What is "Health Program State"?
>
> Maybe further question relating to this... will come later :)
>
>
>>
>> Another issue; Quang is supposed to start work with us from March?
>> Everybody agrees? and have you discussed with him?
>>
>
> Remember mentioning this before and also talked to him... when I attended
> GNOME ASIA last year, and will contact with Quang for this after having the
> related information as I ask below!
> Jørn, will he work part-time for HISP Vietnam to support dev team?
> Are there any previous information about this connection/discussion with
> him (Quang) between HISP in general and HISP Vietnam in particular?
> If having, it'd be great you can give them to me... because I wanna know
> the status referring to this!
>
> Thank you!
>
>
>> Regards
>>
>> jorn
>>
>>
>> 2010/1/18 Jørn Braa <jornbraa@xxxxxxxxx>:
>> > Dear all,
>> > Hope everything is fine in the new year and that next (Vietnamese)
>> > year will be even better for HISP.
>> >
>> > I write to update you on the new DHIS patient module. It is generic
>> > and flexible and easy to set up. The use area is exactly what you are
>> > working on with the Mother and Child records, and what we discussed in
>> > Can Tho on for example vaccination (child) records.
>> >
>> > This patient (/client) module is
>> > - registering names, birth dates, sex, adresses, IDs etc
>> >
>> > Persons may be (optional)
>> > - grouped in households (or mother - children)
>> >
>> > Then for each patient/client
>> > - each Encounter with the health services is registered
>> >
>> > Encounters are then linked to
>> > - health facility (org unit), and
>> > - Programs (e.g. RCH, EPI) which includes Schedules (e.g. sequence and
>> > months after birth of required vaccines for an infant)
>> >
>> > Programs are then linked to
>> > - data sets and data elements. These data elements are as DHIS data
>> elements.
>> >
>> > INTEGRATION with aggregated HMIS data:
>> > - data is aggregated by the end of each reporting period as according
>> > to the reporting requirements
>> >
>> > For example the number of ANC first visits, or BCGs, Polio1s, Measle
>> > vaccines etc.
>> >
>> > This system will be very well suited for the Mother and CHild - or
>> > vaccination -  registers.
>> >
>> > The system is easy to design so it fits various patient data
>> > requirements from health programs. It may be regarded as an extension
>> > of the DHIS reporting system for statistical data.
>> >
>> > This system is now being tested in India. Here they are also using
>> mobile
>> > telephones - which we should also test in Vietnam.
>> >
>> > This was a very quick run-through. Lars and AByot can update on current
>> "state
>> > of the art", and other issues.
>> >
>> > As discussed before, I suggest that we start working on this DHIS
>> > patient module system in Vietnam now.
>> >
>> > best regards,
>> > jorn
>> >
>>
>
>
>
> --
> --
> Best regards,
> Kim Anh Vo
>
> +84.906612246
> kavo@xxxxxxxxxx
> Coordinator of HISP(hisp.info) in Vietnam
> Master of Information Systems
> at the University of Oslo
> ------------------------------------
> join facebook at www.facebook.com join LinkedIn at www.linkedin.com
>