dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad <olati@xxxxxxxxxx>wrote:

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


Good point!

What I have in mind with the village/house thing is that it will be taken as
an address for the person/patient so that latter it can be used as an
out-reach point. For the scenario you mentioned, probably we can define a
dummy/default family/house/village and then the specific orgunit.


Thank you
Abyot.



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

The dataelements I mentioned in my specification are those dataelements we
have/defined in DHIS2. OrganisationUnit, Period, PeriodType are also objects
from DHIS2.


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