We are exploring the support for Tuberculosis treatment in OpenMRS. Modeling for Tuberculosis treatment should support its own set of entities like Regimen, Culture, DST, Smear etc. We explored the MDRTB module of openmrs. These entities are built as wrappers around Encounter and Obs/ObsGroup.
We would like to take the opinion of OpenMRS community on the way forward.
Should we have a new data model for these entities defined in OpenMRS or should we rely just on the Service layer depending on top of Encounter/Obs?
We use the notion of EncounterTransaction of EMRAPI for managing the encounters, relevant observations, diagnosis and treatment/drug orders. We expect the provision of regimen & tests like Culture and DST blend well with EncounterTransaction. We are not expecting to have a separate REST requests for EncounterTransaction and TB Regimen/Tests.
I would think we would simply follow the same model that we established with Diagnoses. Diagnosis is a top-level entity in emrapi, but it is simply a wrapper of Obs/ObsGroups itself. This seems like the right pattern to emulate for other constructs such as these, and for them to live in emrapi.
We should have a helpful set of Java classes to represent these higher-level concepts (and also expose them nicely through web services), but under the hood these will remain Encounters/Obs.
@mogoodrich what’s the most recent “best” practice way we handled mapping obs groups to a nicer Java object (e.g. for Diagnoses), and is that relevant here?
@darius, are you asking if there are any better examples of mapping an obs group to nicer Java object than Diagnosis? Nothing initially springs to mind.
If you haven’t already, it’s worth looking at the Specimen, Smear, Culture, and DST wrapper objects in the MDR-TB module. The implementations certainly aren’t best practices of how to map to obs/encounter, but the interfaces could be a valuable starting point in terms of what fields to collect, especially if we are trying to maintain compatibility with the existing MDR-TB module. (Might even be worth keeping the interface and writing a new implementation?)
See interfaces and classes in this package:
I created those classes (though years ago), so feel free to hit me up with questions.