dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

On Mon, May 25, 2009 at 3:19 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> 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,


Ok. But how do we deal with house-to-house visit then? I mean that is the
corner of the Health Extension Program for rural primary health care.

How about adding an address attribute to a person and linking that to a
house?

Thanks
Abyot.


>
>
> 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<https://launchpad.net/%7Edhis2-devs>
> >> >> > Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> >> >> > Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> >> >> > More help   : https://help.launchpad.net/ListHelp
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>