dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

2009/5/25 Ola Hodne Titlestad <olati@xxxxxxxxxx>

> On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw <abyota@xxxxxxxxx> wrote:
>
>>
>>
>> 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.
>>
>
> OK, that sounds fine.
>
>
>>
>>
>> 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.
>>
>>
> OK.
> I was thinking of "patient" data elements. What I mean is, do you plan to
> use DHIS2 model for data elements also for patient data elements?
> If so, how to you plan to distinguish between the two types? Will CBHIS
> then have its own database when DHIS 2 is also running on the same machine?
>

Patient dataelement? you mean kind of advanced dataelements? if so why don't
we extend the current dataelement module in DHIS2? Introducing advanced or
extended_dataelements instead of doing it in CBHIS?

Separate database? I think that will slow down the system - I mean session
establishment, connection maintenace and the like because there will be
quite a handfull of objects to be shared from the current DHIS2 datamodel -
for example dataelement, organisationunit, period and its type, ......

Thank you
Abyot.



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