2009/5/25 Abyot Gizaw <aby...@gmail.com>: > > > 2009/5/25 Ola Hodne Titlestad <ol...@ifi.uio.no> >> >> On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw <aby...@gmail.com> wrote: >>> >>> >>> On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad <ol...@ifi.uio.no> >>> 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 <aby...@gmail.com> >>>>> >>>>> On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe <bobjolli...@gmail.com> >>>>> wrote: >>>>> > >>>>> > Hi Abyot >>>>> > >>>>> > Good to see you back :-) >>>>> >>>>> Thanks ... came a week back with full of energy :) >>>>> >>>>> > >>>>> > >>>>> > 2009/5/25 Abyot Gizaw <aby...@gmail.com>: >>>>> > > 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@lists.launchpad.net >>>>> > > Unsubscribe : https://launchpad.net/~dhis2-devs >>>>> > > More help : https://help.launchpad.net/ListHelp >>>>> > > >>>>> > > >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~dhis2-devs >>>>> Post to : dhis2-devs@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>> >>> >> > > _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp