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/…)
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.
Hi Abyot
Good to see you back 
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.
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.
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.
Regards
Bob
2009/5/25 Abyot Gizaw <abyota@gmail.com>:
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
Hi Abyot
Good to see you back
Thanks … came a week back with full of energy
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
¡P 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!
¡P Family
o Husband – person
o Wife – person
o Daughters – Set
o Sons – Set
o Address – house
¡P House
o HouseNo – string
o GpsLocation – string
¡P Village
o Name – string
o Children – Set
o Parent – organisationUnit
¡P HealthProgram
o Name – string
o Freqency – periodType
o ProgramPhase – Set
¡P Register
o Name – string
o Header – ?XMLObject?
o Footer – ?XMLObject?
o Columns – ?XMLObject
¡P XMLObject
o Set
o Set
o date
o village
o …
¡P ActivityPlan
o Owner – person (Health Extension Worker)
o Supervisor – person (Medical Officer)
o Date – date
o Activities – set
¡P 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.
On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:
2009/5/25 Abyot Gizaw abyota@gmail.com:
Regards
Bobdhis-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
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.
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?
best regards,
Ola Hodne Titlestad
HISP
University of Oslo
2009/5/25 Abyot Gizaw abyota@gmail.com
On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Hi Abyot
Good to see you back
Thanks … came a week back with full of energy
2009/5/25 Abyot Gizaw abyota@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 splitbetween 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 inthe 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
o Sons – Set
o Address – house
· House
o HouseNo – string
o GpsLocation – string
· Village
o Name – string
o Children – Set
o Parent – organisationUnit
· HealthProgram
o Name – string
o Freqency – periodType
o ProgramPhase – Set
· Register
o Name – string
o Header – ?XMLObject?
o Footer – ?XMLObject?
o Columns – ?XMLObject
· XMLObject
o Set
o Set
o date
o village
o …
· ActivityPlan
o Owner – person (Health Extension Worker)
o Supervisor – person (Medical Officer)
o Date – date
o Activities – set
· 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 sometimesassumes 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
Bobdhis-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-devsMore 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
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.
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.
On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:
best regards,
Ola Hodne Titlestad
HISP
University of Oslo
2009/5/25 Abyot Gizaw abyota@gmail.com
On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Hi Abyot
Good to see you back
Thanks … came a week back with full of energy
2009/5/25 Abyot Gizaw abyota@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 splitbetween 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 inthe 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
o Sons – Set
o Address – house
· House
o HouseNo – string
o GpsLocation – string
· Village
o Name – string
o Children – Set
o Parent – organisationUnit
· HealthProgram
o Name – string
o Freqency – periodType
o ProgramPhase – Set
· Register
o Name – string
o Header – ?XMLObject?
o Footer – ?XMLObject?
o Columns – ?XMLObject
· XMLObject
o Set
o Set
o date
o village
o …
· ActivityPlan
o Owner – person (Health Extension Worker)
o Supervisor – person (Medical Officer)
o Date – date
o Activities – set
· 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 sometimesassumes 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
Bobdhis-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-devsMore 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
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?
Thanks,
Ola
On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw abyota@gmail.com wrote:
On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:
best regards,
Ola Hodne Titlestad
HISP
University of Oslo
2009/5/25 Abyot Gizaw abyota@gmail.com
On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Hi Abyot
Good to see you back
Thanks … came a week back with full of energy
2009/5/25 Abyot Gizaw abyota@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 splitbetween 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 inthe 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
o Sons – Set
o Address – house
· House
o HouseNo – string
o GpsLocation – string
· Village
o Name – string
o Children – Set
o Parent – organisationUnit
· HealthProgram
o Name – string
o Freqency – periodType
o ProgramPhase – Set
· Register
o Name – string
o Header – ?XMLObject?
o Footer – ?XMLObject?
o Columns – ?XMLObject
· XMLObject
o Set
o Set
o date
o village
o …
· ActivityPlan
o Owner – person (Health Extension Worker)
o Supervisor – person (Medical Officer)
o Date – date
o Activities – set
· 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 sometimesassumes 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
Bobdhis-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-devsMore 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
Hi
OK, by API we are really talking about the data model. That is fine.
I do think that what you have proposed as a "demographic person" is
maybe too simplistic. I have posted earlier about using the OpenMRS
demographic model or perhaps even the HL7 RIM model.
I have neither in front of me right now, but there a few things I
recall from the openmrs model which we also incorporated into debo:
1. a person may have one or more identifiers (patient number,
national id number, electoral register number etc). These can
sometimes be useful in ironing out duplicates without getting into a
tyranny of identifying numbers.
2. a person may have one or more addresses (or none). Unfortunately
reality will rarely be as neat as a population of husband and wife and
sons and daughters living in a household. I think that's my biggest
concern about how to implement this household system - children stay
with grandparents, brothers live together into old age, husbands have
more than one wife, etc etc. We are complicated. Families are
amorphous, organic things. A system based on a rigid conception of
members of a family and on the premise that a household then
corresponds to a family will not work. I'm not sure of the answers
here, but we should anticipate a slightly more complex model.
3. Definitely do store date of birth instead of age. Though an api
can easily provide getAgeInYears() and getAgeInMonths() methods.
[I'll have to read up some more, but what is XMLObject here? It seems
out of place at this level where we are talking about the objects
rather the way they might be encoded.]
Regards
Bob
2009/5/25 Abyot Gizaw <abyota@gmail.com>:
....
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
apiThe 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
>
>
Yes it is very simplified and I do hope that things will be shaped in the process. Because right now I don’t have the complete answer.
And I am looking into the OpenMRS code aswell, especially the object person and its associates. The biggest question I have is the issue of ID and right now thinking of two IDs with one of them sort of floating with migration and villages and the other one sort of permanent. How exactly, I don’t really have the answer right now.
But, at the same time, we shouldn’t make things hard onto ourselves. I mean a husband and wife living/or-not-living in a household together with their sons and daughters … honestly that won’t bother me a bit (I don’t know may be I am wrong). The idea it to provide a primary health care to a community of what ever blood/marriage relationship - primary healthcare for all. But to simplify things introducing the “confusing” concept of family/marriage … and then a household as that is the primary contact point for the house-to-house visit.
Again objects for family/household are introduced to simplify activity planning, migration and outreaching. In addition the focus with the system, at least what I have in mind, is on the prevention side not treatment and hence I am not sure to what extent issues of history, patient journal and little basic ingredients for this are going to be considered. Otherwise we have to go to OpenMRS or other Medical Record systems.
Thanks
Abyot.
On Mon, May 25, 2009 at 2:14 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Hi
OK, by API we are really talking about the data model. That is fine.
I do think that what you have proposed as a “demographic person” is
maybe too simplistic. I have posted earlier about using the OpenMRS
demographic model or perhaps even the HL7 RIM model.
I have neither in front of me right now, but there a few things I
recall from the openmrs model which we also incorporated into debo:
- a person may have one or more identifiers (patient number,
national id number, electoral register number etc). These can
sometimes be useful in ironing out duplicates without getting into a
tyranny of identifying numbers.
- a person may have one or more addresses (or none). Unfortunately
reality will rarely be as neat as a population of husband and wife and
sons and daughters living in a household. I think that’s my biggest
concern about how to implement this household system - children stay
with grandparents, brothers live together into old age, husbands have
more than one wife, etc etc. We are complicated. Families are
amorphous, organic things. A system based on a rigid conception of
members of a family and on the premise that a household then
corresponds to a family will not work. I’m not sure of the answers
here, but we should anticipate a slightly more complex model.
- Definitely do store date of birth instead of age. Though an api
can easily provide getAgeInYears() and getAgeInMonths() methods.
[I’ll have to read up some more, but what is XMLObject here? It seems
out of place at this level where we are talking about the objects
rather the way they might be encoded.]
Regards
Bob
2009/5/25 Abyot Gizaw abyota@gmail.com:
…
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
o Sons – Set
o Address – house
· House
o HouseNo – string
o GpsLocation – string
· Village
o Name – string
o Children – Set
o Parent – organisationUnit
· HealthProgram
o Name – string
o Freqency – periodType
o ProgramPhase – Set
· Register
o Name – string
o Header – ?XMLObject?
o Footer – ?XMLObject?
o Columns – ?XMLObject
· XMLObject
o Set
o Set
o date
o village
o …
· ActivityPlan
o Owner – person (Health Extension Worker)
o Supervisor – person (Medical Officer)
o Date – date
o Activities – set
· 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
Yes it is very simplified and I do hope that things will be shaped in the
process. Because right now I don't have the complete answer.And I am looking into the OpenMRS code aswell, especially the object person
and its associates. The biggest question I have is the issue of ID and right
now thinking of two IDs with one of them sort of floating with migration and
villages and the other one sort of permanent. How exactly, I don't really
have the answer right now.
One of the things which I think OpenMRS does right is that the model
caters for the fact that a person may have any number of identifiers
from different sources. Whether they use it or not I don't know, but
that makes sense to me.
But, at the same time, we shouldn't make things hard onto ourselves. I mean
a husband and wife living/or-not-living in a household together with their
sons and daughters ... honestly that won't bother me a bit (I don't know may
be I am wrong). The idea it to provide a primary health care to a community
of what ever blood/marriage relationship - primary healthcare for all. But
to simplify things introducing the "confusing" concept of family/marriage
...... and then a household as that is the primary contact point for the
house-to-house visit.
I think my main aim is to ensure that people are not excluded because
they don't fit the model. And households (in their real incarnation)
are really difficult to model. Not all households will consist of a
family which in turn consists of man-wife-sons-daughters. So lets not
jump into constructing a model which assumes that they do,
Regards
Bob
2009/5/25 Abyot Gizaw <abyota@gmail.com>:
Again objects for family/household are introduced to simplify activity
planning, migration and outreaching. In addition the focus with the system,
at least what I have in mind, is on the prevention side not treatment and
hence I am not sure to what extent issues of history, patient journal and
little basic ingredients for this are going to be considered. Otherwise we
have to go to OpenMRS or other Medical Record systems.Thanks
Abyot.On Mon, May 25, 2009 at 2:14 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
Hi
OK, by API we are really talking about the data model. That is fine.
I do think that what you have proposed as a "demographic person" is
maybe too simplistic. I have posted earlier about using the OpenMRS
demographic model or perhaps even the HL7 RIM model.I have neither in front of me right now, but there a few things I
recall from the openmrs model which we also incorporated into debo:1. a person may have one or more identifiers (patient number,
national id number, electoral register number etc). These can
sometimes be useful in ironing out duplicates without getting into a
tyranny of identifying numbers.2. a person may have one or more addresses (or none). Unfortunately
reality will rarely be as neat as a population of husband and wife and
sons and daughters living in a household. I think that's my biggest
concern about how to implement this household system - children stay
with grandparents, brothers live together into old age, husbands have
more than one wife, etc etc. We are complicated. Families are
amorphous, organic things. A system based on a rigid conception of
members of a family and on the premise that a household then
corresponds to a family will not work. I'm not sure of the answers
here, but we should anticipate a slightly more complex model.3. Definitely do store date of birth instead of age. Though an api
can easily provide getAgeInYears() and getAgeInMonths() methods.[I'll have to read up some more, but what is XMLObject here? It seems
out of place at this level where we are talking about the objects
rather the way they might be encoded.]Regards
Bob2009/5/25 Abyot Gizaw <abyota@gmail.com>:
> ....
>
> 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
>> >
>> >
>
>
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?
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, …
Thank you
Abyot.
2009/5/25 Ola Hodne Titlestad olati@ifi.uio.no
On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw abyota@gmail.com wrote:
On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:
Thanks,
Ola
best regards,
Ola Hodne Titlestad
HISP
University of Oslo
2009/5/25 Abyot Gizaw abyota@gmail.com
On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Hi Abyot
Good to see you back
Thanks … came a week back with full of energy
2009/5/25 Abyot Gizaw abyota@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 splitbetween 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 inthe 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
o Sons – Set
o Address – house
· House
o HouseNo – string
o GpsLocation – string
· Village
o Name – string
o Children – Set
o Parent – organisationUnit
· HealthProgram
o Name – string
o Freqency – periodType
o ProgramPhase – Set
· Register
o Name – string
o Header – ?XMLObject?
o Footer – ?XMLObject?
o Columns – ?XMLObject
· XMLObject
o Set
o Set
o date
o village
o …
· ActivityPlan
o Owner – person (Health Extension Worker)
o Supervisor – person (Medical Officer)
o Date – date
o Activities – set
· 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 sometimesassumes 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
Bobdhis-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-devsMore 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
Yes it is very simplified and I do hope that things will be shaped in the
process. Because right now I don’t have the complete answer.
And I am looking into the OpenMRS code aswell, especially the object person
and its associates. The biggest question I have is the issue of ID and right
now thinking of two IDs with one of them sort of floating with migration and
villages and the other one sort of permanent. How exactly, I don’t really
have the answer right now.
One of the things which I think OpenMRS does right is that the model
caters for the fact that a person may have any number of identifiers
from different sources. Whether they use it or not I don’t know, but
that makes sense to me.
But, at the same time, we shouldn’t make things hard onto ourselves. I mean
a husband and wife living/or-not-living in a household together with their
sons and daughters … honestly that won’t bother me a bit (I don’t know may
be I am wrong). The idea it to provide a primary health care to a community
of what ever blood/marriage relationship - primary healthcare for all. But
to simplify things introducing the “confusing” concept of family/marriage
… and then a household as that is the primary contact point for the
house-to-house visit.
I think my main aim is to ensure that people are not excluded because
they don’t fit the model. And households (in their real incarnation)
are really difficult to model. Not all households will consist of a
family which in turn consists of man-wife-sons-daughters. So lets not
jump into constructing a model which assumes that they do,
Ok. But how do we deal with house-to-house visit then? I mean that is the corner of the Health Extension Program for rural primary health care.
How about adding an address attribute to a person and linking that to a house?
Thanks
Abyot.
On Mon, May 25, 2009 at 3:19 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:
2009/5/25 Abyot Gizaw abyota@gmail.com:
Regards
Bob
Again objects for family/household are introduced to simplify activity
planning, migration and outreaching. In addition the focus with the system,
at least what I have in mind, is on the prevention side not treatment and
hence I am not sure to what extent issues of history, patient journal and
little basic ingredients for this are going to be considered. Otherwise we
have to go to OpenMRS or other Medical Record systems.
Thanks
Abyot.
On Mon, May 25, 2009 at 2:14 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Hi
OK, by API we are really talking about the data model. That is fine.
I do think that what you have proposed as a “demographic person” is
maybe too simplistic. I have posted earlier about using the OpenMRS
demographic model or perhaps even the HL7 RIM model.
I have neither in front of me right now, but there a few things I
recall from the openmrs model which we also incorporated into debo:
- a person may have one or more identifiers (patient number,
national id number, electoral register number etc). These can
sometimes be useful in ironing out duplicates without getting into a
tyranny of identifying numbers.
- a person may have one or more addresses (or none). Unfortunately
reality will rarely be as neat as a population of husband and wife and
sons and daughters living in a household. I think that’s my biggest
concern about how to implement this household system - children stay
with grandparents, brothers live together into old age, husbands have
more than one wife, etc etc. We are complicated. Families are
amorphous, organic things. A system based on a rigid conception of
members of a family and on the premise that a household then
corresponds to a family will not work. I’m not sure of the answers
here, but we should anticipate a slightly more complex model.
- Definitely do store date of birth instead of age. Though an api
can easily provide getAgeInYears() and getAgeInMonths() methods.
[I’ll have to read up some more, but what is XMLObject here? It seems
out of place at this level where we are talking about the objects
rather the way they might be encoded.]
Regards
Bob
2009/5/25 Abyot Gizaw abyota@gmail.com:
…
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
o Sons – Set
o Address – house
· House
o HouseNo – string
o GpsLocation – string
· Village
o Name – string
o Children – Set
o Parent – organisationUnit
· HealthProgram
o Name – string
o Freqency – periodType
o ProgramPhase – Set
· Register
o Name – string
o Header – ?XMLObject?
o Footer – ?XMLObject?
o Columns – ?XMLObject
· XMLObject
o Set
o Set
o date
o village
o …
· ActivityPlan
o Owner – person (Health Extension Worker)
o Supervisor – person (Medical Officer)
o Date – date
o Activities – set
· 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
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,
2009/5/25 Abyot Gizaw <abyota@gmail.com>:
2009/5/25 Ola Hodne Titlestad <olati@ifi.uio.no>
On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw <abyota@gmail.com> wrote:
On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad <olati@ifi.uio.no> >>> wrote:
Thank you
Abyot.Thanks,
Ola
------------best regards,
Ola Hodne Titlestad
HISP
University of Oslo2009/5/25 Abyot Gizaw <abyota@gmail.com>
On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe <bobjolliffe@gmail.com> >>>>> wrote:
>
> Hi Abyot
>
> Good to see you backThanks ... came a week back with full of energy
>
>
> 2009/5/25 Abyot Gizaw <abyota@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 apiThe 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
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?
2009/5/25 Bob Jolliffe bobjolliffe@gmail.com
2009/5/25 Abyot Gizaw abyota@gmail.com:
2009/5/25 Ola Hodne Titlestad olati@ifi.uio.no
On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw abyota@gmail.com wrote:
On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad olati@ifi.uio.no > > >>> wrote:
Thank you
Abyot.
Thanks,
Ola
best regards,
Ola Hodne Titlestad
HISP
University of Oslo
2009/5/25 Abyot Gizaw abyota@gmail.com
On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolliffe@gmail.com > > >>>>> wrote:
Hi Abyot
Good to see you back
Thanks … came a week back with full of energy
2009/5/25 Abyot Gizaw abyota@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
o Sons – Set
o Address – house
· House
o HouseNo – string
o GpsLocation – string
· Village
o Name – string
o Children – Set
o Parent – organisationUnit
· HealthProgram
o Name – string
o Freqency – periodType
o ProgramPhase – Set
· Register
o Name – string
o Header – ?XMLObject?
o Footer – ?XMLObject?
o Columns – ?XMLObject
· XMLObject
o Set
o Set
o date
o village
o …
· ActivityPlan
o Owner – person (Health Extension Worker)
o Supervisor – person (Medical Officer)
o Date – date
o Activities – set
· 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
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.
Ola
2009/5/25 Abyot Gizaw abyota@gmail.com
2009/5/25 Ola Hodne Titlestad olati@ifi.uio.no
On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw abyota@gmail.com wrote:
On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:
Thank you
Abyot.
Thanks,
Ola
best regards,
Ola Hodne Titlestad
HISP
University of Oslo
2009/5/25 Abyot Gizaw abyota@gmail.com
On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Hi Abyot
Good to see you back
Thanks … came a week back with full of energy
2009/5/25 Abyot Gizaw abyota@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 splitbetween 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 inthe 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
o Sons – Set
o Address – house
· House
o HouseNo – string
o GpsLocation – string
· Village
o Name – string
o Children – Set
o Parent – organisationUnit
· HealthProgram
o Name – string
o Freqency – periodType
o ProgramPhase – Set
· Register
o Name – string
o Header – ?XMLObject?
o Footer – ?XMLObject?
o Columns – ?XMLObject
· XMLObject
o Set
o Set
o date
o village
o …
· ActivityPlan
o Owner – person (Health Extension Worker)
o Supervisor – person (Medical Officer)
o Date – date
o Activities – set
· 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 sometimesassumes 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
Bobdhis-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-devsMore 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
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.
2009/5/25 Ola Hodne Titlestad olati@ifi.uio.no
2009/5/25 Abyot Gizaw abyota@gmail.com
2009/5/25 Ola Hodne Titlestad olati@ifi.uio.no
On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw abyota@gmail.com wrote:
On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:
Ola
Thank you
Abyot.
Thanks,
Ola
best regards,
Ola Hodne Titlestad
HISP
University of Oslo
2009/5/25 Abyot Gizaw abyota@gmail.com
On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Hi Abyot
Good to see you back
Thanks … came a week back with full of energy
2009/5/25 Abyot Gizaw abyota@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 splitbetween 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 inthe 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
o Sons – Set
o Address – house
· House
o HouseNo – string
o GpsLocation – string
· Village
o Name – string
o Children – Set
o Parent – organisationUnit
· HealthProgram
o Name – string
o Freqency – periodType
o ProgramPhase – Set
· Register
o Name – string
o Header – ?XMLObject?
o Footer – ?XMLObject?
o Columns – ?XMLObject
· XMLObject
o Set
o Set
o date
o village
o …
· ActivityPlan
o Owner – person (Health Extension Worker)
o Supervisor – person (Medical Officer)
o Date – date
o Activities – set
· 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 sometimesassumes 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
Bobdhis-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-devsMore 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
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@gmail.com
2009/5/25 Ola Hodne Titlestad olati@ifi.uio.no
2009/5/25 Abyot Gizaw abyota@gmail.com
2009/5/25 Ola Hodne Titlestad olati@ifi.uio.no
On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw abyota@gmail.com wrote:
On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad olati@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 abyota@gmail.com
On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Hi Abyot
Good to see you back
Thanks … came a week back with full of energy
2009/5/25 Abyot Gizaw abyota@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 splitbetween 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 inthe 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
o Sons – Set
o Address – house
· House
o HouseNo – string
o GpsLocation – string
· Village
o Name – string
o Children – Set
o Parent – organisationUnit
· HealthProgram
o Name – string
o Freqency – periodType
o ProgramPhase – Set
· Register
o Name – string
o Header – ?XMLObject?
o Footer – ?XMLObject?
o Columns – ?XMLObject
· XMLObject
o Set
o Set
o date
o village
o …
· ActivityPlan
o Owner – person (Health Extension Worker)
o Supervisor – person (Medical Officer)
o Date – date
o Activities – set
· 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 sometimesassumes 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
Bobdhis-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-devsMore 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
Hi Saptar and all
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
2009/5/26 Saptarshi Purkayastha <sunbiz@gmail.com>:
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@gmail.com>
2009/5/25 Ola Hodne Titlestad <olati@ifi.uio.no>
2009/5/25 Abyot Gizaw <abyota@gmail.com>
2009/5/25 Ola Hodne Titlestad <olati@ifi.uio.no>
On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw <abyota@gmail.com> wrote:
On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad >>>>>> <olati@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 Oslo2009/5/25 Abyot Gizaw <abyota@gmail.com>
On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe >>>>>>>> <bobjolliffe@gmail.com> wrote:
>
> Hi Abyot
>
> Good to see you backThanks ... came a week back with full of energy
>
>
> 2009/5/25 Abyot Gizaw <abyota@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 apiThe 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_______________________________________________
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
Hi Saptarshi
I think the more that can be said in advance of the call the better.
Otherwise we spend 2 hours talking in circles. I know you have some
ideas of technology stacks you have discussed before. Would be a good
idea to lay that out a bit if possible.
Similarly there has been some talk of *possible* migration of DHIS2
towards struts 2 - at least there is a reasonably clear migration path
and I know Murod has done some work with experimental module. Is this
something to be considered? Lars what do you think?
Regards
Bob
2009/5/26 Saptarshi Purkayastha <sunbiz@gmail.com>:
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 add2.) Having multiple identifiers is a necessity of sorts for community
setting... May be not so much in a clinical setting3.) 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.
Similarly there has been some talk of possible migration of DHIS2
towards struts 2 - at least there is a reasonably clear migration path
and I know Murod has done some work with experimental module. Is this
something to be considered? Lars what do you think?
Regards
Bob
I actually gave it a try yesterday. Migrating action classes/interceptors is easy. I ran into some problems though:
I got some incomprehensible errors related to SAX xml parsing.
It’s harder to get hold of the xwork ConfigurationManager (must be done trough a DispatcherListener) which is required for the portal.
Our old acegi security framework had some issues with xwork2. This should be upgraded to Spring security, but will require more work.
Anyways I think this is the way to go if we are to upgrade the existing webwork code as this requires little modification to the hundreds of action classes and interceptors, in contrast to eg spring mvc.
When it comes to technology stack for the houshold system my opinion is that using something completely new like j2ee 6 is unrealistic if we are gonna come up with something pretty soon as it requires all of us to learn new technologies and start from scratch. I believe that, if necessary, we could upgrade a few things in dhis2, like acegi and webwork, and then continue with the same technology / components as today. If we want to use more Spring out-of-the-box components later there is nothing stopping us.
Lars
Hi people,
If you like I can commit my work on struts2 integration into bazaar. These are copy of modules from existing webwork implementations, we can have all in one and even exclude new modules from the rest via poms. Currently two main modules - support-struts2 and web-commons-resources-struts2 and one working module - web-importexport-struts2 are converted.
regards,
murod
From: Lars Helge Øverland larshelge@gmail.com
To: Bob Jolliffe bobjolliffe@gmail.com
Cc: Ola Hodne Titlestad olati@ifi.uio.no; Sundeep Sahay sundeep.sahay@yahoo.com; Ola Hodne Titlestad olati@student.matnat.uio.no; Kristin Braa kristin.braa@gmail.com; Jørn Braa jornbraa@gmail.com; dhis2-devs dhis2-devs@lists.launchpad.net
Sent: Wednesday, May 27, 2009 11:01:21 AM
Subject: Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
Similarly there has been some talk of possible migration of DHIS2
towards struts 2 - at least there is a reasonably clear migration path
and I know Murod has done some work with experimental module. Is this
something to be considered? Lars what do you think?
Regards
Bob
I actually gave it a try yesterday. Migrating action classes/interceptors is easy. I ran into some problems though:
I got some incomprehensible errors related to SAX xml parsing.
It’s harder to get hold of the xwork ConfigurationManager (must be done trough a DispatcherListener) which is required for the portal.
Our old acegi security framework had some issues with xwork2. This should be upgraded to Spring security, but will require more work.
Anyways I think this is the way to go if we are to upgrade the existing webwork code as this requires little modification to the hundreds of action classes and interceptors, in contrast to eg spring mvc.
When it comes to technology stack for the houshold system my opinion is that using something completely new like j2ee 6 is unrealistic if we are gonna come up with something pretty soon as it requires all of us to learn new technologies and start from scratch. I believe that, if necessary, we could upgrade a few things in dhis2, like acegi and webwork, and then continue with the same technology / components as today. If we want to use more Spring out-of-the-box components later there is nothing stopping us.
Lars