2009/5/25 Ola Hodne Titlestad <ol...@ifi.uio.no> > 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? >> > > 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 <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<https://launchpad.net/%7Edhis2-devs> >>>>>> > > Post to : dhis2-devs@lists.launchpad.net >>>>>> > > 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@lists.launchpad.net >>>>>> 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 Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
