dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olati@xxxxxxxxxx>]

Hi Abyot and others,

I am trying to think how this design fits with other use cases that we need
to suppport, such as maternal death audits or surveillance of notifiable
diseases which are typical use cases in HISP where we extend DHIS to the
patient level.

How strong is the link/dependency of patient to village and house in this
design? Will it cater for use cases where patient and possibly orgunit are
the only "location" references? I can see use cases where an orgunit is
reporting patient details of cases/deaths, e.g.a maternal death or a new
case of a notifiable disease, with or without location details such as
village and house. Such a scenario would then involve meta data such as
orgunit, patient, date, and multiple (patient) data elements.

Another question/concern I have is related to how you represent data
elements in this model. I can see that an XML object contains a set of Data
Elements. Will Data Elements be created/edited in GUI and then available for
the users to combine in data sets/forms like in DHIS? And will these data
elements be easily available when aggregation queries are defined by the
user?


best regards,
Ola Hodne Titlestad
HISP
University of Oslo


2009/5/25 Abyot Gizaw <abyota@xxxxxxxxx>

>
> On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
> wrote:
> >
> > Hi Abyot
> >
> > Good to see you back :-)
>
> Thanks ... came a week back with full of energy :)
>
> >
> >
> > 2009/5/25 Abyot Gizaw <abyota@xxxxxxxxx>:
> > > Hi All,
> > >
> > > In a sort of lose coupling of DHIS2 and CBHIS, I am planning the
> following
> > > coding layout for the CBHIS.
> > >
> > > dhis-cbhis-api
> > > dhis-cbhis-service
> > > dhis2-cbhis-web-(datarecording/report/administration/......)
> >
> > A few thoughts and opinions.  Feel free to disagree.
>
> Oh ya.
>
> >
> > If you follow the approach above then try to implement some sort of
> > relationship between modules and packages.  I think a module can
> > implement a number of packages, but packages should not be split
> > between modules.  We have a lot of that at present which is confusing.
> >  All of a package should be defined in one module.
> >
> > Be clear what goes in the api and what goes in the service layer -
> > current rule of thumb seems to be that the api should be free-standing
> > (outside of "technology-choice" implementation lbraries).  A
> > consequence being that the only dependency you would expect to see in
> > the api pom.xml would be probably junit (lets provide unit tests for
> > the api).  If its about spring, hibernate, jdbc, jsf or what have you
> > it belongs in a different package in the service module.
>
> The spring, hibernate, jdbc ...... stuff is something which we already have
> and it goes on under dhis-support module.
>
> 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
> > >
> > >
>
>
> _______________________________________________
> 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
>
>