dhis2-devs team mailing list archive

[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.

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.

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