Objectives
Provide flexible data storage & retrieval mechanisms for classified health (or other domain) data by diseases, sex, age, and possibly other category (e.g. outpatient visit, discharges) for various areas/health programs.
Proposed Activities to achieve the goal
- Design & test model classes, Interfaces, and implementations for data management (CRUD operations)
- Design & test form classes, Interfaces, and implementations for form data management. Forms are used for data capturing and presentation.
- Documentation (UML & textual description)
Milestones
2005-11-11, Milestone 1:
- Identify and define all interfaces for model components – done.
- Write documentation – The documentation is mostly done, and it's written in the interfaces. Available through JavaDoc- See Documentation & Illustration below.
2005-12-16, Milestone 2:
- Implement the interfaces defined – done.
- White Box testing – done.
- Update documentation – done.
- Remove all bugs uncovered by the tests – done.
Detailed information and description
The ICD-module follows the same guidelines as the core module. It has the same technical requirements as the core module. The ICD-module is located in the dhis-cds (cds stands for 'Classified Data Store') project directory. As with the core module the beans are located in src/main/resources/META-INF/dhis/beans.xml.
Background information
Morbidity and Mortality data are generated through the consultation of patients, and the diagnoses are represented by the ICD code (International Classification of Diseases) in addition to the disease name. ICD codes are a standard diagnostic classification of diseases published by WHO first in 1948, it is used for epidemiological and health management purposes. Some countries using DHIS need to persist information about the number of patients in a given period with a specific disease (identified by it's ICD code) classified by age, sex and health service. The disease list can be ICD or any local disease list. Examples of health service include out-patient regular, in-patient, etc. A sample input form used in Ethiopia when collecting patient information: http://heim.ifi.uio.no/woinshem/OutPatientRegular.pdf
. This input form is only for the category Regular Out-Patient. There are separate input forms for Emergency Out-Patients, In-Patient and Deaths.
The core module does not support such a need. A previous version of ICD-module was implemented by Woinshet Abdella Mohammed for DHIS 1.3. The countries using this module were unable to upgrade to DHIS 1.4 once it became available because DHIS 1.4 did not implement the ICD module yet.
The "new" ICD-module for DHIS 2 should store data in a flexible way to allow different countries to use it for their specific needs.
The module
Though persisting ICD-data could be solved by giving each combination of disease, age category, gender and health service a unique DataElement, this would lead to tens of thousands of different DataElements, which in turn would make the database messy. A better solution is to make an extra module for the countries requiring this sort of information, which would store additional information for the services provided to patients divided by diseases and the other categories mentioned above.
We have two UML-diagrams presenting the classes and interfaces we've implemented in the project.
- This diagram
shows the module's classes and interfaces.
- The bottom left box contains the additional classes we've identified. The DataElementGroup is an exisiting class from dhis-core.
- The top left box contains the two interfaces we've defined. Other modules that need to work with dhis-cds (for example the Data Entry module) will use the methods provided here.
- The top right box contains the two implementions of the interfaces.
- This diagram shows the UML class diagram and our version of DataValue, ClassifiedDataValue. The subclass relationships make the implementation slightly easier as the database implementation need only worry about two classes rather than five.
- The Group class has two subclasses; DataElementSuperGroup and GeneralCategoryGroup.
- DataElementSuperGroup can have any number of DataElementGroups, which is defined in the dhis-core. This allows the same health instituion keep different disease list (e.g local and international) or health service / programme (e.g. Intergrated Disease Surveillance and Response - IDSR)
- GeneralCategoryGroup can have any number of GeneralCategories, for example an Out-Patient group contains Regular & Emergency Out-Patient visits.
- The Category class has three subclasses; Gender, GeneralCategory and AgeCategory.
- GeneralCategory can be Regular Out-Patient, Emergency Out-Patients, In-Patient and Deaths, but also something else as the country sees fitting to divide data in.
- Gender can be male, female, or all. Though the system does not prohibt the use of other genders, it should hardly be nescessary.
- AgeCategory can be any age category the country needs; these are just defined with a min and max age (or anything below or above a given age).
- The ClassifieDataValue holds number of patients seen or discharged with a certain disease, age group, sex for a given period and source (health institution). This is an extension of the DataValue class defined in dhis-core. The ClassifieDataValue can then be uniquely identified with all of the above information in addition to the identifiers a "normal" DataValue has.
The structure
All the packages are subpackages of org.hisp.dhis.
- service.datastore
contains all the classes in the domain model.
- service.datastore.dataelement
contains the interface ClassifiedDataElementStore and an exception the interface can throw.
Also contains ClassifiedDataElementStore which tests the implemention of the interface.
- service.datastore.datastore.routine
contains the interface RoutineClassifiedDataStore and an exception the interface can throw.
Also contains RoutineClassifiedDataStoreTest which tests the implemention of the interface.
- service.datastore.hibernate
contains the hibernate implementaions for both of the interfaces defind above.
Using the module
The module provides methods defined in the two interfaces ClassifiedDataElementStore and RoutineClassifiedDataStore. Both of the interfaces are documented with JavaDoc
Remaining tasks
The current project handles storage and retrieval, but does not support the other functionalities required to complete the ICD module including
Data Entry
Import / export
Validation
Indicator definitions
Report design
References
For information about what an ICD code is, please visit WHO ICD information.
For the specifications, see javadoc
Log
18/10-2005: Met with Kristian and Knut. Woinshet brought a suggestion for a model that we all agreed upon. Lene not present.
20/10-2005: Met with Torgeir, got a demonstration of the customized Data entry. Decided to abondon the specific form interface/implementation. Decided upon a initial plan, updated the JIRA page with all issues. Nothing assigned yet.
25/10-2005: Split the work on the interfaces/domain model. See the Progress Plan above.
1/11-2005: Woinshet and Lene met and discussed some of the interfaces. All interfaces will be finished and checked-in by next Tuesday.
8/11-2005: Finished the interfaces, cleared up some misunderstandings. Most of milestone 1 is done. The rest will be finished within the week.
15/11-2005: Lene was absent due to illness. We made a new deadline for ourselves and divided the work.
22/11-2005: Woinshet and Lene met and changed the interfaces one final time (hopefully...).
29/11-2005: Woinshet and Lene worked on the implementation, almost finished.
1/12-2005: Woinshet finished and checked in the last part of the implementation. The first version of the tests completed.
6/12-2005: Lene started working on the debugging, lots of bugs uncovered in both the tests and the implementation. The tests must be reworked for easier testing to seperate tests for each method. For now a single methods tests all the functionality.
9/12-2005: Both tests rewritten by Marius. Probably contains a lot of errors, but much simpler and easier to work with. Woinshet starts extensively testing and finding bugs.
12/12-2005: Meeting for planning the presentation and exchanging experiences. Woinshet is done debugging one of the implementations, started working with the next.
13/12-2005: Presentation for the other groups.
15/12-2005: Debugging finished.
16/12-2005: Documentation finished. Project delievered in its current form.
Developers
Just change AT into @. To prevent spam.
