Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
2009/5/28 Bob Jolliffe bobjolli...@gmail.com 2009/5/27 Lars Helge Øverland larshe...@gmail.com: - I got some incomprehensible errors related to SAX xml parsing. Is this related to our custom code using staxwax+woodstox, or something else? I'm not sure if its relevant to this discussion, but one thing to consider is the availablility of StAX parser within j2ee 6 which can reduce one more dependency. It occurred while initializing Struts. The Struts VelocityManager complained that content is not allowed in prolog while initializing a Toolbox. No idea... You'd have to know what xml file the VelocityManager was trying to read at the time. Seems the parser didn't see it as kosher xml. Could be all manner of reasons. The prolog is the ?xml version=1.0 encoding=utf-8? and the !DOCTYPE ... bits. Usually you see this when trying to process a non-xml eg. binary file. Could also be hidden characters, funny linefeeds in the file. Do you get same error on windoze and linux? Cheers Bob Haven't tried on linux. But I made a simple webapp using struts 2 with an include file and it worked fine. I am a little unsure how the struts config files are loaded. The docs say they are loaded from classpath automatically. ___ 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
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
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 larshe...@gmail.com To: Bob Jolliffe bobjolli...@gmail.com Cc: Ola Hodne Titlestad ol...@ifi.uio.no; Sundeep Sahay sundeep.sa...@yahoo.com; Ola Hodne Titlestad ol...@student.matnat.uio.no; Kristin Braa kristin.b...@gmail.com; Jørn Braa jornb...@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 ___ 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
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
- I got some incomprehensible errors related to SAX xml parsing. Is this related to our custom code using staxwax+woodstox, or something else? I'm not sure if its relevant to this discussion, but one thing to consider is the availablility of StAX parser within j2ee 6 which can reduce one more dependency. It occurred while initializing Struts. The Struts VelocityManager complained that content is not allowed in prolog while initializing a Toolbox. No idea... - It's harder to get hold of the xwork ConfigurationManager (must be done trough a DispatcherListener) which is required for the portal. I think we might be looking at overhauling the configuration framework eg. using the struts 2 plugin mechanism. - Our old acegi security framework had some issues with xwork2. This should be upgraded to Spring security, but will require more work. Agreed. 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. I think there are a few other areas which could do with a dust-up/continued-evolution, including the API and our interoperability import/export format. Of course, with a substantially new model for the new component, we have something of a green field with the API which will allow us to absorb the lessons (the good, the bad and the ugly) of the existing stuff. This is part of the reason I am in favour of maintaining one api. As we add in the new stuff we can be refactoring the old. Having two API modules won't encourage this effect. Sounds fine. Sidenote: I learned today that one of our student groups managed to apply Spring-Hibernate support in dhis2 pretty smoothly. Only a hibernate mapping file provider is left of our custom code. Nice. ___ 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
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
Hi 2009/5/27 Ola Hodne Titlestad ol...@ifi.uio.no: Hi, Abyot, Lars, Jørn and I have had some discussions in Oslo concerning the design of the CBHIS that I thought I would share with you before tomorrow's call. These are my interpretations and views on what has been discussed and do not necessarily reflect what Abyot, Jørn and Lars thinks... Hope this will help to make tomorrow's call more constructive. Summary of functional requirements: I'll do my best to provide a short summary of the three use cases we have seen so far from India, Vietnam and Zanzibar: Please fill in and correct me if needed. India: The type of data captured very similar to routine data in the sense that it is basic health program data like BCG vaccine given, DPT1 vaccine given etc. BUT differs with regards to the owner of the data which are individual clients and households. In that sense the data elements are the same, but the orgunits are extended down to the lowest possible level, the individual. In addition there are requirements for a work planner system that helps to organise the out reach work of the health workers providing schedules and work plans on where to do household visits based on the data available (which chidren in the village are scheduled for DPT3 vaccine next week etc.). There is a clear link to aggregated data as data elements can be derived directly from the household data (can even be the same data element), but aggregation is needed in order to analyse higher levels in the orgunit tree. Zanzibar / DHIS 1.4 patient: In this use case the data elements are also different from the routine as they are typically much more detailes than routine data, in a way zooming in on each case with more details. The orgunits are the same, but data is also belonging to individuals, although more as a reference for later lookup, not to keep track of patients/clients over time. In this use case is is the details of each reported case that are important, not the name of the patient. Routine data are generated based on expressions and criteria to filter and count the detailed patient-level data. Vietnam: I have not fully grasped all the requirements here, but at first glance they seem quite similar to the Indian needs. The idea is for health programs to follow up individual clients (mothers and children) and register essential data on vaccination, ANC check-ups, deliveries. I know that e.g. in the big city of HCMC they want to have a central register with all pregnant mothers and I assume the same for newborn children, so in that sense it is a bit different from India where the focus is on the communities. That means that the link to household and village might not be as important, but the mother-child link is probably important, and the data also belongs to the reporting health facility (ward). So clients and health facilities own the data, similar to the Zanzibar case. But here the tracking of clients over time is important, as it is in India. Also here there is a clear need to produce aggregated reports based on the patient-level data, and from the forms provided by Tran the data elements for patient-level and routine seem very similar, and again like in India the main difference with the data is the owner, so I assume a lot of routine data and patient data can share the same data element name. Design choices: Building on Abyot’s design, discussions we've had in Oslo and also the summary above my feeling is that we can reuse existing design concepts like data element, data set, and data entry form. We should probably differentiate in the GUI between Patient Data Elements and Routine (aggregated) Data Elements, but the same object seems to capture what we need. Similarly all registers/forms seem possible to represent as data sets and then if needed a custom data entry form can be designed on top of that. This seems very similar to what we already have in DHIS2. The expressions for how to generate aggregated data from patient data could fit into the concept of calculated data elements, at least if we extend it a bit. If we go for this approach and reuse data elements and sets then we need to extend the dataset management functionality in order to specify what kind of data that is captured with the dataset since data entry will be quite different for patient and routine data and since we possibly need to use two different data value objects for patient and routine. We could e.g. do like 1.4 and add a data table property to datasets where we can specify whether it is patient or aggregated data (don't like to use routine as it doesn't capture semi-permanent data). Then when you open data entry and select a dataset the screen and procedures will vary depending on what type of data that is going to be captured. This means that we do not really need a new web module for meta data management and data entry for patient data, but in stead can extend the
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
2009/5/27 Ola Hodne Titlestad ol...@ifi.uio.no: 2009/5/27 Bob Jolliffe bobjolli...@gmail.com Hi 2009/5/27 Ola Hodne Titlestad ol...@ifi.uio.no: Hi, Abyot, Lars, Jørn and I have had some discussions in Oslo concerning the design of the CBHIS that I thought I would share with you before tomorrow's call. These are my interpretations and views on what has been discussed and do not necessarily reflect what Abyot, Jørn and Lars thinks... Hope this will help to make tomorrow's call more constructive. Summary of functional requirements: I'll do my best to provide a short summary of the three use cases we have seen so far from India, Vietnam and Zanzibar: Please fill in and correct me if needed. India: The type of data captured very similar to routine data in the sense that it is basic health program data like BCG vaccine given, DPT1 vaccine given etc. BUT differs with regards to the owner of the data which are individual clients and households. In that sense the data elements are the same, but the orgunits are extended down to the lowest possible level, the individual. In addition there are requirements for a work planner system that helps to organise the out reach work of the health workers providing schedules and work plans on where to do household visits based on the data available (which chidren in the village are scheduled for DPT3 vaccine next week etc.). There is a clear link to aggregated data as data elements can be derived directly from the household data (can even be the same data element), but aggregation is needed in order to analyse higher levels in the orgunit tree. Zanzibar / DHIS 1.4 patient: In this use case the data elements are also different from the routine as they are typically much more detailes than routine data, in a way zooming in on each case with more details. The orgunits are the same, but data is also belonging to individuals, although more as a reference for later lookup, not to keep track of patients/clients over time. In this use case is is the details of each reported case that are important, not the name of the patient. Routine data are generated based on expressions and criteria to filter and count the detailed patient-level data. Vietnam: I have not fully grasped all the requirements here, but at first glance they seem quite similar to the Indian needs. The idea is for health programs to follow up individual clients (mothers and children) and register essential data on vaccination, ANC check-ups, deliveries. I know that e.g. in the big city of HCMC they want to have a central register with all pregnant mothers and I assume the same for newborn children, so in that sense it is a bit different from India where the focus is on the communities. That means that the link to household and village might not be as important, but the mother-child link is probably important, and the data also belongs to the reporting health facility (ward). So clients and health facilities own the data, similar to the Zanzibar case. But here the tracking of clients over time is important, as it is in India. Also here there is a clear need to produce aggregated reports based on the patient-level data, and from the forms provided by Tran the data elements for patient-level and routine seem very similar, and again like in India the main difference with the data is the owner, so I assume a lot of routine data and patient data can share the same data element name. Design choices: Building on Abyot’s design, discussions we've had in Oslo and also the summary above my feeling is that we can reuse existing design concepts like data element, data set, and data entry form. We should probably differentiate in the GUI between Patient Data Elements and Routine (aggregated) Data Elements, but the same object seems to capture what we need. Similarly all registers/forms seem possible to represent as data sets and then if needed a custom data entry form can be designed on top of that. This seems very similar to what we already have in DHIS2. The expressions for how to generate aggregated data from patient data could fit into the concept of calculated data elements, at least if we extend it a bit. If we go for this approach and reuse data elements and sets then we need to extend the dataset management functionality in order to specify what kind of data that is captured with the dataset since data entry will be quite different for patient and routine data and since we possibly need to use two different data value objects for patient and routine. We could e.g. do like 1.4 and add a data table property to datasets where we can specify whether it is patient or aggregated data (don't like to use routine as it doesn't capture semi-permanent data). Then when you open data entry and
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
hehe, I can see that my writing might have been misleading. I was not thinking of individuals as orgunits as such, but I was trying to explain how this patient/community data is different from normal data. Its not necessarily as whacky as it sounds. I guess if you think of the base class, source, rather than orgunit it can make sense. And without it you do need to modify the datavalue to indicate the patientId. After all the DataValue was designed to allow for multiple implementations of Source, this might be a viable option... ___ 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
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
2009/5/27 Lars Helge Øverland larshe...@gmail.com hehe, I can see that my writing might have been misleading. I was not thinking of individuals as orgunits as such, but I was trying to explain how this patient/community data is different from normal data. Its not necessarily as whacky as it sounds. I guess if you think of the base class, source, rather than orgunit it can make sense. And without it you do need to modify the datavalue to indicate the patientId. After all the DataValue was designed to allow for multiple implementations of Source, this might be a viable option... Yes, but patient data values will still need to reference patient and dataset and need encryption. ___ 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
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
2009/5/27 Ola Hodne Titlestad ol...@ifi.uio.no: 2009/5/27 Lars Helge Øverland larshe...@gmail.com hehe, I can see that my writing might have been misleading. I was not thinking of individuals as orgunits as such, but I was trying to explain how this patient/community data is different from normal data. Its not necessarily as whacky as it sounds. I guess if you think of the base class, source, rather than orgunit it can make sense. And without it you do need to modify the datavalue to indicate the patientId. After all the DataValue was designed to allow for multiple implementations of Source, this might be a viable option... Yes, but patient data values will still need to reference patient and dataset and need encryption. The datavalues don't necessarily need encryption. Just the identifying data. I think currently we don't explicitly reference dataset when we store a datavalue. We reference the dataelement, the period and the source. The dataset is sort of inferred from the dataelement-source combination. If the source refers to facility then we would need an extra field for personID. This would break the orthogonality of DataValue and personDataValue which might be unavoidable, but would be a pity. Treating the person as the source (note Abyot - I am very deliberately not saying patient!) means that the link back to the relevant collecting facility would have to be done through the organisation hierarchy. Back through the household and up. Which is ok, but might be tricky if that same hierarchy is split in two. But one huge benefit of the person as source is that these persons will never migrate from their source :-) But they will migrate between households and between facilities. Perhaps the model of OpenMRS (with as many addresses as you like) can help here. Particulalry if we additionally have a date related to the address - so we have 'Bob Jolliffe, last known in household/family XXX at address YYY'. formerly of household/family WWW at address ZZZ' etc. This history also helps to bolster confidence in the reliability of identity. Cheers Bob ___ 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
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
2009/5/27 Lars Helge Øverland larshe...@gmail.com: - I got some incomprehensible errors related to SAX xml parsing. Is this related to our custom code using staxwax+woodstox, or something else? I'm not sure if its relevant to this discussion, but one thing to consider is the availablility of StAX parser within j2ee 6 which can reduce one more dependency. It occurred while initializing Struts. The Struts VelocityManager complained that content is not allowed in prolog while initializing a Toolbox. No idea... You'd have to know what xml file the VelocityManager was trying to read at the time. Seems the parser didn't see it as kosher xml. Could be all manner of reasons. The prolog is the ?xml version=1.0 encoding=utf-8? and the !DOCTYPE ... bits. Usually you see this when trying to process a non-xml eg. binary file. Could also be hidden characters, funny linefeeds in the file. Do you get same error on windoze and linux? Cheers Bob - It's harder to get hold of the xwork ConfigurationManager (must be done trough a DispatcherListener) which is required for the portal. I think we might be looking at overhauling the configuration framework eg. using the struts 2 plugin mechanism. - Our old acegi security framework had some issues with xwork2. This should be upgraded to Spring security, but will require more work. Agreed. 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. I think there are a few other areas which could do with a dust-up/continued-evolution, including the API and our interoperability import/export format. Of course, with a substantially new model for the new component, we have something of a green field with the API which will allow us to absorb the lessons (the good, the bad and the ugly) of the existing stuff. This is part of the reason I am in favour of maintaining one api. As we add in the new stuff we can be refactoring the old. Having two API modules won't encourage this effect. Sounds fine. Sidenote: I learned today that one of our student groups managed to apply Spring-Hibernate support in dhis2 pretty smoothly. Only a hibernate mapping file provider is left of our custom code. Nice. ___ 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
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
Hi Saptar and all 2009/5/26 Saptarshi Purkayastha sun...@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 add Agreed. 2.) Having multiple identifiers is a necessity of sorts for community setting... May be not so much in a clinical setting And agreed. 3.) We can store things securely in the same database. Just when doing CRUD on name-based tables we do encryption/decryption. Managing it would be easier with different databases, but don't know if its worth the overhead. Not so sure. The one problem with doing encryption at the field level - eg. encrypting names, is that you can't then search or index on them which is pretty crippling in this kind of application. At least if you supproting different database engines. If we are to encrypt, its much easier to encrypt the entire database, making it transparent from the database perspective - so it's easy enough to point the table storage at encrypted area of the disk but there is of course a performance hit. This is one (other) reason why having separate databases might be better. Just 'coz we are obliged to be more protective of personal data, doesn't mean we have to slow down the whole application. Cheers Bob Other points about the frameworks and design that I have been wanting to say are better discussed during Thursday developer call. 2009/5/25 Abyot Gizaw aby...@gmail.com 2009/5/25 Ola Hodne Titlestad ol...@ifi.uio.no 2009/5/25 Abyot Gizaw aby...@gmail.com 2009/5/25 Ola Hodne Titlestad ol...@ifi.uio.no On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw aby...@gmail.com wrote: On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad ol...@ifi.uio.no wrote: Hi Abyot and others, I am trying to think how this design fits with other use cases that we need to suppport, such as maternal death audits or surveillance of notifiable diseases which are typical use cases in HISP where we extend DHIS to the patient level. How strong is the link/dependency of patient to village and house in this design? Will it cater for use cases where patient and possibly orgunit are the only location references? I can see use cases where an orgunit is reporting patient details of cases/deaths, e.g.a maternal death or a new case of a notifiable disease, with or without location details such as village and house. Such a scenario would then involve meta data such as orgunit, patient, date, and multiple (patient) data elements. Good point! What I have in mind with the village/house thing is that it will be taken as an address for the person/patient so that latter it can be used as an out-reach point. For the scenario you mentioned, probably we can define a dummy/default family/house/village and then the specific orgunit. OK, that sounds fine. Thank you Abyot. Another question/concern I have is related to how you represent data elements in this model. I can see that an XML object contains a set of Data Elements. Will Data Elements be created/edited in GUI and then available for the users to combine in data sets/forms like in DHIS? And will these data elements be easily available when aggregation queries are defined by the user? The dataelements I mentioned in my specification are those dataelements we have/defined in DHIS2. OrganisationUnit, Period, PeriodType are also objects from DHIS2. OK. I was thinking of patient data elements. What I mean is, do you plan to use DHIS2 model for data elements also for patient data elements? If so, how to you plan to distinguish between the two types? Will CBHIS then have its own database when DHIS 2 is also running on the same machine? Patient dataelement? you mean kind of advanced dataelements? if so why don't we extend the current dataelement module in DHIS2? Introducing advanced or extended_dataelements instead of doing it in CBHIS? Basically, what I assume is that data elements (things we want to register data about) for patients are different than for aggregated/statistical data. Different more in the meaning of the data than in the structure. E.g. things related to individuals like Education level, Name of husband etc. are different than aggregated DE of the type: No of maternal deaths where mother has no education. Furthermore, patient and aggregate/routine data elements will also be captured with very different frequencies and also stored in different data tables (I assume a different data stores for sensitive patient data and normal aggregated data). That is why I am thinking that mixing patient and aggregated data elements in the same system (GUI/database) will be messy for the users and ask how this will be separated, both in database and in GUI. Hope
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
Hi Abyot Good to see you back :-) 2009/5/25 Abyot Gizaw aby...@gmail.com: Hi All, In a sort of lose coupling of DHIS2 and CBHIS, I am planning the following coding layout for the CBHIS. dhis-cbhis-api dhis-cbhis-service dhis2-cbhis-web-(datarecording/report/administration/..) A few thoughts and opinions. Feel free to disagree. 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 dhis-support-x and dhis-i18n- 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
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolli...@gmail.com wrote: Hi Abyot Good to see you back :-) Thanks ... came a week back with full of energy :) 2009/5/25 Abyot Gizaw aby...@gmail.com: Hi All, In a sort of lose coupling of DHIS2 and CBHIS, I am planning the following coding layout for the CBHIS. dhis-cbhis-api dhis-cbhis-service dhis2-cbhis-web-(datarecording/report/administration/..) A few thoughts and opinions. Feel free to disagree. Oh ya. If you follow the approach above then try to implement some sort of relationship between modules and packages. I think a module can implement a number of packages, but packages should not be split between modules. We have a lot of that at present which is confusing. All of a package should be defined in one module. Be clear what goes in the api and what goes in the service layer - current rule of thumb seems to be that the api should be free-standing (outside of technology-choice implementation lbraries). A consequence being that the only dependency you would expect to see in the api pom.xml would be probably junit (lets provide unit tests for the api). If its about spring, hibernate, jdbc, jsf or what have you it belongs in a different package in the service module. The spring, hibernate, jdbc .. stuff is something which we already have and it goes on under dhis-support module. The api is to contain · Person o First_name – string o Last_name – string o Age – (integer) or shall we make it dateOfBirth? Because at somepoint we will register birth! · Family o Husband – person o Wife – person o Daughters – SetPerson o Sons – SetPerson o Address – house · House o HouseNo – string o GpsLocation – string · Village o Name – string o Children – SetHouse o Parent – organisationUnit · HealthProgram o Name – string o Freqency – periodType o ProgramPhase – SetRegister · Register o Name – string o Header – ?XMLObject? o Footer – ?XMLObject? o Columns – ?XMLObject · XMLObject o SetdataElement o SethouseHoldVisit o date o village o … · ActivityPlan o Owner – person (Health Extension Worker) o Supervisor – person (Medical Officer) o Date – date o Activities – setPieceOfTask · 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-x and dhis-i18n- 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
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
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 aby...@gmail.com On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolli...@gmail.com wrote: Hi Abyot Good to see you back :-) Thanks ... came a week back with full of energy :) 2009/5/25 Abyot Gizaw aby...@gmail.com: Hi All, In a sort of lose coupling of DHIS2 and CBHIS, I am planning the following coding layout for the CBHIS. dhis-cbhis-api dhis-cbhis-service dhis2-cbhis-web-(datarecording/report/administration/..) A few thoughts and opinions. Feel free to disagree. Oh ya. If you follow the approach above then try to implement some sort of relationship between modules and packages. I think a module can implement a number of packages, but packages should not be split between modules. We have a lot of that at present which is confusing. All of a package should be defined in one module. Be clear what goes in the api and what goes in the service layer - current rule of thumb seems to be that the api should be free-standing (outside of technology-choice implementation lbraries). A consequence being that the only dependency you would expect to see in the api pom.xml would be probably junit (lets provide unit tests for the api). If its about spring, hibernate, jdbc, jsf or what have you it belongs in a different package in the service module. The spring, hibernate, jdbc .. stuff is something which we already have and it goes on under dhis-support module. The api is to contain · Person o First_name – string o Last_name – string o Age – (integer) or shall we make it dateOfBirth? Because at somepoint we will register birth! · Family o Husband – person o Wife – person o Daughters – SetPerson o Sons – SetPerson o Address – house · House o HouseNo – string o GpsLocation – string · Village o Name – string o Children – SetHouse o Parent – organisationUnit · HealthProgram o Name – string o Freqency – periodType o ProgramPhase – SetRegister · Register o Name – string o Header – ?XMLObject? o Footer – ?XMLObject? o Columns – ?XMLObject · XMLObject o SetdataElement o SethouseHoldVisit o date o village o … · ActivityPlan o Owner – person (Health Extension Worker) o Supervisor – person (Medical Officer) o Date – date o Activities – setPieceOfTask · 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-x and dhis-i18n- and others will be shared from the DHIS2 base framework.
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw aby...@gmail.com wrote: On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad ol...@ifi.uio.nowrote: 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 best regards, Ola Hodne Titlestad HISP University of Oslo 2009/5/25 Abyot Gizaw aby...@gmail.com On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolli...@gmail.com wrote: Hi Abyot Good to see you back :-) Thanks ... came a week back with full of energy :) 2009/5/25 Abyot Gizaw aby...@gmail.com: Hi All, In a sort of lose coupling of DHIS2 and CBHIS, I am planning the following coding layout for the CBHIS. dhis-cbhis-api dhis-cbhis-service dhis2-cbhis-web-(datarecording/report/administration/..) A few thoughts and opinions. Feel free to disagree. Oh ya. If you follow the approach above then try to implement some sort of relationship between modules and packages. I think a module can implement a number of packages, but packages should not be split between modules. We have a lot of that at present which is confusing. All of a package should be defined in one module. Be clear what goes in the api and what goes in the service layer - current rule of thumb seems to be that the api should be free-standing (outside of technology-choice implementation lbraries). A consequence being that the only dependency you would expect to see in the api pom.xml would be probably junit (lets provide unit tests for the api). If its about spring, hibernate, jdbc, jsf or what have you it belongs in a different package in the service module. The spring, hibernate, jdbc .. stuff is something which we already have and it goes on under dhis-support module. The api is to contain · Person o First_name – string o Last_name – string o Age – (integer) or shall we make it dateOfBirth? Because at somepoint we will register birth! · Family o Husband – person o Wife – person o Daughters – SetPerson o Sons – SetPerson o Address – house · House o HouseNo – string o GpsLocation – string · Village o Name – string o Children – SetHouse o Parent – organisationUnit · HealthProgram o Name – string o Freqency – periodType o ProgramPhase – SetRegister · Register o Name – string o Header – ?XMLObject? o Footer – ?XMLObject? o Columns – ?XMLObject · XMLObject o SetdataElement o SethouseHoldVisit o date o village o … · ActivityPlan o Owner – person (Health Extension Worker) o Supervisor – person (Medical Officer) o Date – date o Activities – setPieceOfTask · 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
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
2009/5/25 Abyot Gizaw aby...@gmail.com: 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 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 bobjolli...@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 Bob 2009/5/25 Abyot Gizaw aby...@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 – SetPerson o Sons – SetPerson o Address – house · House o HouseNo – string o GpsLocation – string · Village o Name – string o Children – SetHouse o Parent – organisationUnit · HealthProgram o Name – string o Freqency – periodType o ProgramPhase – SetRegister · Register o Name – string o Header – ?XMLObject? o Footer – ?XMLObject? o Columns – ?XMLObject · XMLObject o SetdataElement o SethouseHoldVisit o date o village o … · ActivityPlan o Owner – person (Health Extension Worker) o Supervisor – person (Medical Officer) o Date – date o Activities – setPieceOfTask · PieceOfTask o Where –
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
2009/5/25 Ola Hodne Titlestad ol...@ifi.uio.no On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw aby...@gmail.com wrote: On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad ol...@ifi.uio.nowrote: 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. Thanks, Ola best regards, Ola Hodne Titlestad HISP University of Oslo 2009/5/25 Abyot Gizaw aby...@gmail.com On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolli...@gmail.com wrote: Hi Abyot Good to see you back :-) Thanks ... came a week back with full of energy :) 2009/5/25 Abyot Gizaw aby...@gmail.com: Hi All, In a sort of lose coupling of DHIS2 and CBHIS, I am planning the following coding layout for the CBHIS. dhis-cbhis-api dhis-cbhis-service dhis2-cbhis-web-(datarecording/report/administration/..) A few thoughts and opinions. Feel free to disagree. Oh ya. If you follow the approach above then try to implement some sort of relationship between modules and packages. I think a module can implement a number of packages, but packages should not be split between modules. We have a lot of that at present which is confusing. All of a package should be defined in one module. Be clear what goes in the api and what goes in the service layer - current rule of thumb seems to be that the api should be free-standing (outside of technology-choice implementation lbraries). A consequence being that the only dependency you would expect to see in the api pom.xml would be probably junit (lets provide unit tests for the api). If its about spring, hibernate, jdbc, jsf or what have you it belongs in a different package in the service module. The spring, hibernate, jdbc .. stuff is something which we already have and it goes on under dhis-support module. The api is to contain · Person o First_name – string o Last_name – string o Age – (integer) or shall we make it dateOfBirth? Because at somepoint we will register birth! · Family o Husband – person o Wife – person o Daughters – SetPerson o Sons – SetPerson o Address – house · House o HouseNo – string o GpsLocation – string · Village o Name – string o Children – SetHouse o Parent – organisationUnit · HealthProgram o Name – string o Freqency – periodType o ProgramPhase – SetRegister · Register o Name – string o Header – ?XMLObject? o Footer – ?XMLObject? o
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
2009/5/25 Abyot Gizaw aby...@gmail.com: 2009/5/25 Ola Hodne Titlestad ol...@ifi.uio.no On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw aby...@gmail.com wrote: On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad ol...@ifi.uio.no wrote: Hi Abyot and others, I am trying to think how this design fits with other use cases that we need to suppport, such as maternal death audits or surveillance of notifiable diseases which are typical use cases in HISP where we extend DHIS to the patient level. How strong is the link/dependency of patient to village and house in this design? Will it cater for use cases where patient and possibly orgunit are the only location references? I can see use cases where an orgunit is reporting patient details of cases/deaths, e.g.a maternal death or a new case of a notifiable disease, with or without location details such as village and house. Such a scenario would then involve meta data such as orgunit, patient, date, and multiple (patient) data elements. Good point! What I have in mind with the village/house thing is that it will be taken as an address for the person/patient so that latter it can be used as an out-reach point. For the scenario you mentioned, probably we can define a dummy/default family/house/village and then the specific orgunit. OK, that sounds fine. Thank you Abyot. Another question/concern I have is related to how you represent data elements in this model. I can see that an XML object contains a set of Data Elements. Will Data Elements be created/edited in GUI and then available for the users to combine in data sets/forms like in DHIS? And will these data elements be easily available when aggregation queries are defined by the user? The dataelements I mentioned in my specification are those dataelements we have/defined in DHIS2. OrganisationUnit, Period, PeriodType are also objects from DHIS2. OK. I was thinking of patient data elements. What I mean is, do you plan to use DHIS2 model for data elements also for patient data elements? If so, how to you plan to distinguish between the two types? Will CBHIS then have its own database when DHIS 2 is also running on the same machine? Patient dataelement? you mean kind of advanced dataelements? if so why don't we extend the current dataelement module in DHIS2? Introducing advanced or extended_dataelements instead of doing it in CBHIS? I think extending the DHIS2 datavalue with an optional person record ID field is a feasible way to use DHIS2 dataelements for this. Separate database? I think that will slow down the system - I mean session establishment, connection maintenace and the like because there will be quite a handfull of objects to be shared from the current DHIS2 datamodel - for example dataelement, organisationunit, period and its type, .. This (and my comment above) are good reasons to consider a single DHIS2 API rather than making a new dhis-cbhs-api. And there has already been considerable discussion on the use of separate database. I thought that there was some consensus that they needed to be kept separate, Thank you Abyot. Thanks, Ola best regards, Ola Hodne Titlestad HISP University of Oslo 2009/5/25 Abyot Gizaw aby...@gmail.com On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolli...@gmail.com wrote: Hi Abyot Good to see you back :-) Thanks ... came a week back with full of energy :) 2009/5/25 Abyot Gizaw aby...@gmail.com: Hi All, In a sort of lose coupling of DHIS2 and CBHIS, I am planning the following coding layout for the CBHIS. dhis-cbhis-api dhis-cbhis-service dhis2-cbhis-web-(datarecording/report/administration/..) A few thoughts and opinions. Feel free to disagree. Oh ya. If you follow the approach above then try to implement some sort of relationship between modules and packages. I think a module can implement a number of packages, but packages should not be split between modules. We have a lot of that at present which is confusing. All of a package should be defined in one module. Be clear what goes in the api and what goes in the service layer - current rule of thumb seems to be that the api should be free-standing (outside of technology-choice implementation lbraries). A consequence being that the only dependency you would expect to see in the api pom.xml would be probably junit (lets provide unit tests for the api). If its about spring, hibernate, jdbc, jsf or what have you it belongs in a different package in the service module. The spring, hibernate, jdbc .. stuff is something which we already have and it goes on under dhis-support module. The api is to contain · Person o First_name – string o Last_name – string o Age – (integer) or shall we make it dateOfBirth? Because at somepoint we will register birth! · Family o Husband – person o
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
2009/5/25 Bob Jolliffe bobjolli...@gmail.com 2009/5/25 Abyot Gizaw aby...@gmail.com: 2009/5/25 Ola Hodne Titlestad ol...@ifi.uio.no On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw aby...@gmail.com wrote: On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad ol...@ifi.uio.no wrote: Hi Abyot and others, I am trying to think how this design fits with other use cases that we need to suppport, such as maternal death audits or surveillance of notifiable diseases which are typical use cases in HISP where we extend DHIS to the patient level. How strong is the link/dependency of patient to village and house in this design? Will it cater for use cases where patient and possibly orgunit are the only location references? I can see use cases where an orgunit is reporting patient details of cases/deaths, e.g.a maternal death or a new case of a notifiable disease, with or without location details such as village and house. Such a scenario would then involve meta data such as orgunit, patient, date, and multiple (patient) data elements. Good point! What I have in mind with the village/house thing is that it will be taken as an address for the person/patient so that latter it can be used as an out-reach point. For the scenario you mentioned, probably we can define a dummy/default family/house/village and then the specific orgunit. OK, that sounds fine. Thank you Abyot. Another question/concern I have is related to how you represent data elements in this model. I can see that an XML object contains a set of Data Elements. Will Data Elements be created/edited in GUI and then available for the users to combine in data sets/forms like in DHIS? And will these data elements be easily available when aggregation queries are defined by the user? The dataelements I mentioned in my specification are those dataelements we have/defined in DHIS2. OrganisationUnit, Period, PeriodType are also objects from DHIS2. OK. I was thinking of patient data elements. What I mean is, do you plan to use DHIS2 model for data elements also for patient data elements? If so, how to you plan to distinguish between the two types? Will CBHIS then have its own database when DHIS 2 is also running on the same machine? Patient dataelement? you mean kind of advanced dataelements? if so why don't we extend the current dataelement module in DHIS2? Introducing advanced or extended_dataelements instead of doing it in CBHIS? I think extending the DHIS2 datavalue with an optional person record ID field is a feasible way to use DHIS2 dataelements for this. I see. I was thinking of maintaing a separate datavalue object/table. Separate database? I think that will slow down the system - I mean session establishment, connection maintenace and the like because there will be quite a handfull of objects to be shared from the current DHIS2 datamodel - for example dataelement, organisationunit, period and its type, .. This (and my comment above) are good reasons to consider a single DHIS2 API rather than making a new dhis-cbhs-api. And there has already been considerable discussion on the use of separate database. I thought that there was some consensus that they needed to be kept separate, separate at the database level? Thank you Abyot. Thanks, Ola best regards, Ola Hodne Titlestad HISP University of Oslo 2009/5/25 Abyot Gizaw aby...@gmail.com On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolli...@gmail.com wrote: Hi Abyot Good to see you back :-) Thanks ... came a week back with full of energy :) 2009/5/25 Abyot Gizaw aby...@gmail.com: Hi All, In a sort of lose coupling of DHIS2 and CBHIS, I am planning the following coding layout for the CBHIS. dhis-cbhis-api dhis-cbhis-service dhis2-cbhis-web-(datarecording/report/administration/..) A few thoughts and opinions. Feel free to disagree. Oh ya. If you follow the approach above then try to implement some sort of relationship between modules and packages. I think a module can implement a number of packages, but packages should not be split between modules. We have a lot of that at present which is confusing. All of a package should be defined in one module. Be clear what goes in the api and what goes in the service layer - current rule of thumb seems to be that the api should be free-standing (outside of technology-choice implementation lbraries). A consequence being that the only dependency you would expect to see in the api pom.xml would be probably junit (lets provide unit tests for the api). If its about spring, hibernate, jdbc, jsf or what have you it belongs in a different package in the service module. The spring, hibernate, jdbc .. stuff
Re: [Dhis2-devs] Coding layout - Community-Based Health Information System (CBHIS)
2009/5/25 Ola Hodne Titlestad ol...@ifi.uio.no 2009/5/25 Abyot Gizaw aby...@gmail.com 2009/5/25 Ola Hodne Titlestad ol...@ifi.uio.no On Mon, May 25, 2009 at 1:10 PM, Abyot Gizaw aby...@gmail.com wrote: On Mon, May 25, 2009 at 12:53 PM, Ola Hodne Titlestad ol...@ifi.uio.no wrote: Hi Abyot and others, I am trying to think how this design fits with other use cases that we need to suppport, such as maternal death audits or surveillance of notifiable diseases which are typical use cases in HISP where we extend DHIS to the patient level. How strong is the link/dependency of patient to village and house in this design? Will it cater for use cases where patient and possibly orgunit are the only location references? I can see use cases where an orgunit is reporting patient details of cases/deaths, e.g.a maternal death or a new case of a notifiable disease, with or without location details such as village and house. Such a scenario would then involve meta data such as orgunit, patient, date, and multiple (patient) data elements. Good point! What I have in mind with the village/house thing is that it will be taken as an address for the person/patient so that latter it can be used as an out-reach point. For the scenario you mentioned, probably we can define a dummy/default family/house/village and then the specific orgunit. OK, that sounds fine. Thank you Abyot. Another question/concern I have is related to how you represent data elements in this model. I can see that an XML object contains a set of Data Elements. Will Data Elements be created/edited in GUI and then available for the users to combine in data sets/forms like in DHIS? And will these data elements be easily available when aggregation queries are defined by the user? The dataelements I mentioned in my specification are those dataelements we have/defined in DHIS2. OrganisationUnit, Period, PeriodType are also objects from DHIS2. OK. I was thinking of patient data elements. What I mean is, do you plan to use DHIS2 model for data elements also for patient data elements? If so, how to you plan to distinguish between the two types? Will CBHIS then have its own database when DHIS 2 is also running on the same machine? Patient dataelement? you mean kind of advanced dataelements? if so why don't we extend the current dataelement module in DHIS2? Introducing advanced or extended_dataelements instead of doing it in CBHIS? Basically, what I assume is that data elements (things we want to register data about) for patients are different than for aggregated/statistical data. Different more in the meaning of the data than in the structure. E.g. things related to individuals like Education level, Name of husband etc. are different than aggregated DE of the type: No of maternal deaths where mother has no education. Furthermore, patient and aggregate/routine data elements will also be captured with very different frequencies and also stored in different data tables (I assume a different data stores for sensitive patient data and normal aggregated data). That is why I am thinking that mixing patient and aggregated data elements in the same system (GUI/database) will be messy for the users and ask how this will be separated, both in database and in GUI. Hope that made more sense. Separate database? I think that will slow down the system - I mean session establishment, connection maintenace and the like because there will be quite a handfull of objects to be shared from the current DHIS2 datamodel - for example dataelement, organisationunit, period and its type, .. That was an issue raised by Calle in an earlier mail thread due to security issues related to patient-level data. Yes I got it now. But I am not sure how to balance the very thin boundary between patient-based data and community-based data. For me in the community-based system we just have individuals (not patients) getting standard health service, education, and some benefits available in health extension programs. Thanks Abyot. Ola Thank you Abyot. Thanks, Ola best regards, Ola Hodne Titlestad HISP University of Oslo 2009/5/25 Abyot Gizaw aby...@gmail.com On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe bobjolli...@gmail.com wrote: Hi Abyot Good to see you back :-) Thanks ... came a week back with full of energy :) 2009/5/25 Abyot Gizaw aby...@gmail.com: Hi All, In a sort of lose coupling of DHIS2 and CBHIS, I am planning the following coding layout for the CBHIS. dhis-cbhis-api dhis-cbhis-service dhis2-cbhis-web-(datarecording/report/administration/..) A few thoughts and opinions. Feel free to disagree. Oh ya. If you follow the approach above then try to implement some sort of relationship between modules and packages. I think a module can implement a number of
