dhis2-devs team mailing list archive

[Saptarshi Purkayastha <sunbiz@xxxxxxxxx>]

There are few important things to consider:

1.) Person should be able to have any type of relationship with another
person (eg. other members of the community)/user (e.g. health workers).
Basically the associated relationship can be stored as a relationship table
and that can be anything that the user wants to add

2.) Having multiple identifiers is a necessity of sorts for community
setting... May be not so much in a clinical setting

3.) We can store things securely in the same database. Just when doing CRUD
on name-based tables we do encryption/decryption. Managing it would be
easier with different databases, but don't know if its worth the overhead.

Other points about the frameworks and design that I have been wanting to say
are better discussed during Thursday developer call.


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