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 <aby...@gmail.com>: > .... > > 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@lists.launchpad.net >> > Unsubscribe : https://launchpad.net/~dhis2-devs >> > More help : https://help.launchpad.net/ListHelp >> > >> > > > _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
