dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi Saptar and all

2009/5/26 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

Agreed.

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

And agreed.

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

Not so sure.  The one problem with doing encryption at the field level
- eg. encrypting names, is that you can't then search or index on them
which is pretty crippling in this kind of application.  At least if
you supproting different database engines.

If we are to encrypt, its much easier to encrypt the entire database,
making it transparent from the database perspective  - so it's easy
enough to point the table storage at encrypted area of the disk but
there is of course a performance hit.  This is one (other) reason why
having separate databases might be better.  Just 'coz we are obliged
to be more protective of personal data, doesn't mean we have to slow
down the whole application.

Cheers
Bob

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