dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2009/5/25 Abyot Gizaw <abyota@xxxxxxxxx>:
> Yes it is very simplified and I do hope that things will be shaped in the
> process. Because right now I don't have the complete answer.
>
> And I am looking into the OpenMRS code aswell, especially the object person
> and its associates. The biggest question I have is the issue of ID and right
> now thinking of two IDs with one of them sort of floating with migration and
> villages and the other one sort of permanent. How exactly, I don't really
> have the answer right now.

One of the things which I think OpenMRS does right is that the model
caters for the fact that a person may have any number of identifiers
from different sources.  Whether they use it or not I don't know, but
that makes sense to me.

> But, at the same time, we shouldn't make things hard onto ourselves. I mean
> a husband and wife living/or-not-living in a household together with their
> sons and daughters ... honestly that won't bother me a bit (I don't know may
> be I am wrong). The idea it to provide a primary health care to a community
> of what ever blood/marriage relationship - primary healthcare for all. But
> to simplify things introducing the "confusing" concept of family/marriage
> ...... and then a household as that is the primary contact point for the
> house-to-house visit.

I think my main aim is to ensure that people are not excluded because
they don't fit the model.  And households (in their real incarnation)
are really difficult to model.  Not all households will consist of a
family which in turn consists of man-wife-sons-daughters.  So lets not
jump into constructing a model which assumes that they do,

Regards
Bob

> Again objects for family/household are introduced to simplify activity
> planning, migration and outreaching. In addition the focus with the system,
> at least what I have in mind, is on the prevention side not treatment and
> hence I am not sure to what extent issues of history, patient journal and
> little basic ingredients for this are going to be considered. Otherwise we
> have to go to OpenMRS or other Medical Record systems.
>
> Thanks
> Abyot.
>
> On Mon, May 25, 2009 at 2:14 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>>
>> Hi
>>
>> OK, by API we are really talking about the data model.  That is fine.
>> I do think that what you have proposed as a "demographic person" is
>> maybe too simplistic. I have posted earlier about using the OpenMRS
>> demographic model or perhaps even the HL7 RIM model.
>>
>> I have neither in front of me right now, but there a few things I
>> recall from the openmrs model which we also incorporated into debo:
>>
>> 1.  a person may have one or more identifiers (patient number,
>> national id number, electoral register number etc).  These can
>> sometimes be useful in ironing out duplicates without getting into a
>> tyranny of identifying numbers.
>>
>> 2.  a person may have one or more addresses (or none).  Unfortunately
>> reality will rarely be as neat as a population of husband and wife and
>> sons and daughters living in a household.  I think that's my biggest
>> concern about how to implement this household system - children stay
>> with grandparents, brothers live together into old age,  husbands have
>> more than one wife, etc etc.  We are complicated.  Families are
>> amorphous, organic things.  A system based on a rigid conception of
>> members of a family and on the premise that a household then
>> corresponds to a family will not work.  I'm not sure of the answers
>> here, but we should anticipate a slightly more complex model.
>>
>> 3.  Definitely do store date of birth instead of age.  Though an api
>> can easily provide getAgeInYears() and getAgeInMonths() methods.
>>
>> [I'll have to read up some more, but what is XMLObject here?  It seems
>> out of place at this level where we are talking about the objects
>> rather the way they might be encoded.]
>>
>> Regards
>> Bob
>>
>> 2009/5/25 Abyot Gizaw <abyota@xxxxxxxxx>:
>> > ....
>> >
>> > The api is to contain
>> >
>> > ·         Person
>> >
>> > o   First_name – string
>> >
>> > o   Last_name – string
>> >
>> > o   Age – (integer) or shall we make it dateOfBirth? Because at
>> > somepoint we
>> > will register birth!
>> >
>> > ·         Family
>> >
>> > o   Husband – person
>> >
>> > o   Wife – person
>> >
>> > o   Daughters – Set<Person>
>> >
>> > o   Sons – Set<Person>
>> >
>> > o   Address – house
>> >
>> > ·         House
>> >
>> > o   HouseNo – string
>> >
>> > o   GpsLocation – string
>> >
>> > ·         Village
>> >
>> > o   Name – string
>> >
>> > o   Children – Set<House>
>> >
>> > o   Parent – organisationUnit
>> >
>> > ·         HealthProgram
>> >
>> > o   Name – string
>> >
>> > o   Freqency – periodType
>> >
>> > o   ProgramPhase – Set<Register>
>> >
>> > ·         Register
>> >
>> > o   Name – string
>> >
>> > o   Header – ?XMLObject?
>> >
>> > o   Footer – ?XMLObject?
>> >
>> > o   Columns – ?XMLObject
>> >
>> > ·         XMLObject
>> >
>> > o   Set<dataElement>
>> >
>> > o   Set<houseHoldVisit>
>> >
>> > o   date
>> >
>> > o   village
>> >
>> > o   …
>> >
>> > ·         ActivityPlan
>> >
>> > o   Owner – person (Health Extension Worker)
>> >
>> > o   Supervisor – person (Medical Officer)
>> >
>> > o   Date – date
>> >
>> > o   Activities – set<PieceOfTask>
>> >
>> > ·         PieceOfTask
>> >
>> > o   Where – house
>> >
>> > o   When – date
>> >
>> > o   ForWhom – person
>> >
>> > o   What – houseHoldVisit
>> >
>> >
>> > and some others which I couldn't forsee the whole picture right now and
>> > list
>> > here. of course exceptions, logics (query), .... will also be part of
>> > the
>> > api
>> >
>> > The service is to contain the processing of the api's - database
>> > persisting
>> > and any other business logic - like querying, activity plan generation,
>> > ....
>> >
>> > Finally the web part is to contain the presentation of the business
>> > logic.
>> >
>> >
>> >>
>> >> Use the api to enforce business rules which are not enforced via the
>> >> database.  We don't do enough of that at present.  The API sometimes
>> >> assumes that its users are always benign.  Don't do this.  Expect the
>> >> worst and code for it.  Part of the api should be a definition of
>> >> exceptions.
>> >>
>> >> Is there a really good reason to have dhis-cbhis-api or should cbhis
>> >> be a package within dhis-api?  I would lean towards having one dhis2
>> >> API.
>> >
>> > Not really ... just easy plugability and lost coupling. Didn't want to
>> > clutter the very strong sense of aggregate system - I just want to
>> > contain
>> > the objects of individual/patient/person and its related stuff.
>> >
>> >
>> > Thank you
>> > Abyot.
>> >
>> >>
>> >>
>> >> Regards
>> >> Bob
>> >>
>> >> > dhis-support-xxxxx and dhis-i18n-xxxx and others will be shared from
>> >> > the
>> >> > DHIS2 base framework.
>> >> >
>> >> >
>> >> > Any comments or suggestions would be appreciated.
>> >> >
>> >> > Thank you
>> >> > Abyot.
>> >> >
>> >> > _______________________________________________
>> >> > Mailing list: https://launchpad.net/~dhis2-devs
>> >> > Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> >> > Unsubscribe : https://launchpad.net/~dhis2-devs
>> >> > More help   : https://help.launchpad.net/ListHelp
>> >> >
>> >> >
>> >
>> >
>
>