dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2009/5/25 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?

I think extending the DHIS2 datavalue with an optional person record
ID field is a feasible way to use DHIS2 dataelements for this.

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

This (and my comment above) are good reasons to consider a single
DHIS2 API rather than making a new dhis-cbhs-api.  And there has
already been considerable discussion on the use of separate database.
 I thought that there was some consensus that they needed to be kept
separate,


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