Thanks for the chance to present yesterday @jennifer. As a followup, I’d like to share a little more detail on our project proposal. As part of Jembi’s COVID-19 response, we are evaluating how we can extend the OpenHIM to support COVID-19 data exchange use cases.
One of the proposals is to develop an OpenHIM mediator to provide out-the-box support for submitting COVID-19 case data to DHIS2 Tracker in compliance with the DHIS2 COVID-19 Surveillance Digital Data Package and data model that has been developed. We are evaluating if this would be of value to the OpenMRS community and if there are any implementations that would look to make use of this.
As a first step I’ve done an initial pass at mapping the OpenMRS COVID-19 data dictionary to the DHIS2 COVID-19 Surveillance data model. It’d be great to get eyes on this and any comments/feedback on the mappings from those that have been involved with the OpenMRS data dictionary:
Thanks for the suggestion @mksd, that definitely sounds like a viable option.
Will do a bit more reading to understand how the JSON marshalling/unmarshalling works, as I understand the Camel component could be configured to forward an unmarshalled payload to the OpenHIM via REST.
@mksd One quick question - could the Camel component be configured or extended to support outputting a FHIR resource/bundle? i.e. if the unmarshalling outputs to JSON, can the JSON format be configured/templated as a FHIR resource/bundle (conceptually, I’m sure there’d need to be some work done to support this)? Thanks
That’s a great question. DB Sync’s OpenMRS Camel Component defines a model for each entity that it supports. Right now this model is some OpenMRS-looking JSON representation, there is no good reason for that except practicality/ease/velocity when this was initially developed.
However this model could (and should) be FHIRzed. This is something we would like to start doing progressively from here on, and surely we’ll need some guidance from @ibacher in doing so. This FHIRzation is loosely on our roadmap and @wyclif and I we already discussed that we would FHIRze a couple of entities as a POC. If you guys would like to prioritise this we would be more than happy to do it as a joint piece of work.
More than happy to help out with the FHIRization of this, though it can get a bit messy (since the OpenMRS data model does not map one-to-one onto all FHIR resources). Camel does appear to have some support for FHIR, albeit the only examples I’ve seen are for converting from HL7v2.
The easiest way to get things into a FHIR format is probably to rely on the OpenMRS FHIR2 API module, since we’ve done at least some of the work mapping OpenMRS entities into HAPI FHIR representations.
Strategically, I like the idea of having a piece of middleware to handle upstream reporting from OpenMRS to DHIS2, since it can get rid of some of the load we may otherwise be placing on OpenMRS.
Thanks @mksd and @ibacher! We may look at the simple case first of getting the data out of OpenMRS in any existing custom format (e.g. JSON), but as part of the OpenHIE COVID task force activities, also considering the potential of leveraging FHIR to allow for additional use cases over and above DHIS2 data exchange.
I guess one of the first activities would be to map the OpenMRS COVID-19 data dictionary to FHIR to understand this better, there’s a (US-centric) COVID-19 FHIR IG that’s being explored as a starting point. Once there’s more clarity there, it’d be great to get more insight on supporting a FHIR payload export of this data through DB Sync and/or the FHIR2 API module.
Do you do any processing on this metadata template from DHIS2? Or do you just take it as is and specify it for the OpenMRS reporting module configuration?
