dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

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

I see. I was thinking of maintaing a separate datavalue object/table.


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


separate at the database level?



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