dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

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

> 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?
>>
>
> Basically, what I assume is that data elements (things we want to register
> data about) for patients are different than for aggregated/statistical data.
> Different more in the meaning of the data than in the structure. E.g. things
> related to individuals like "Education level", "Name of husband" etc. are
> different than aggregated DE of the type: "No of maternal deaths where
> mother has no education". Furthermore, patient and aggregate/routine data
> elements will also be captured with very different frequencies and also
> stored in different data tables (I assume a different data stores for
> sensitive patient data and normal aggregated data). That is why I am
> thinking that mixing patient and aggregated data elements in the same system
> (GUI/database) will be messy for the users and ask how this will be
> separated, both in database and in GUI.
> Hope that made more sense.
>
>
>
>>
>> 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, ......
>>
>
> That was an issue raised by Calle in an earlier mail thread due to security
> issues related to patient-level data.
>


Yes I got it now. But I am not sure how to balance the very thin boundary
between patient-based data and community-based data. For me in the
community-based system we just have individuals (not patients) getting
standard health service, education, and some benefits available in health
extension programs.

Thanks
Abyot.



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