Key DHIS2 Integration Discussion Points

(Craig Appl) #1


I have been working on the DHIS2 scoping and recognized a few discussion points that we need to address in the architecture. Please review these comments and we can discuss them based on the numbering below.

1) Will the OpenLMIS tech stack be responsible for pushing data into DHIS2 or will this be the responsibility of a third party system?

1a) No, OpenLMIS will expose an API that a third party system can hit to get a standardized report. The third party will be responsible for consuming it on the schedule they want.
1b) Yes

My Recommendation:
1b - I believe that OpenLMIS implementers want control over how often the report is published and actually want control over the moment they want to publish (i.e. push a button to submit). Furthermore, I believe that OpenLMIS implementers do not want to maintain an independent middle layer between the OpenLMIS tech stack and the DHIS2 system. I believe they want to maintain all of the mapping in the OpenLMIS tech stack as is currently done in eLMIS.

2) Should we keep a map of DHIS2 locations within the OpenLMIS tech stack?

2a) If we choose 1a, the answer is no unless we want to publish the common set of FHIR locations that are considered the “master list”
2b) If we choose 1b, we will need to keep a map of DHIS2 locations cached within the OpenLMIS tech stack.

My Recommendation:
2b) I recommend that we maintain a map of locations natively in the OpenLMIS tech stack so we can reference those locations when submitting an aggregate report.

3) Should we use FHIR4 Measure, ADX or DXF2 to exchange aggregate data?

3a) FHIR 4.0 Measure - This is outlined well in Josh’s comment on Jira. Currently, Measures and Measure Evaluations are not supported in DHIS2. We would need to convert those to ADX using a middle layer so data can get into DHIS2. Currently that means building a translator in Nifi or running OpenHIM with a mediator.
3b) ADX - Only part of the Aggregate Data Exchange standard is supported in DHIS2. Currently, DHIS2 can receive a message using the Aggregate Data Exchange standard, but they do not support getting the Data Set Definition in the ADX format (Section 8.2 on the standard) this means that there is no automated way to identify which fields should be created in DHIS2 using the ADX DSD template. Without this template, we would have to manually map the column values of each report in the system and make sure they exactly fit the indicator names in DHIS2 regardless of what we want to call these indicators in OpenLMIS.
3c) DXF2 - This is the DHIS2 functional standard that is most commonly used. This format does support getting the data set template from DHIS2 using their Web API and submitting that report. DXF2 is an XML standard like ADX. However, you have to submit the GUID of each indicator in DHIS2 to be able to map them.

My Recommendation:
3c - Though it is not a global standard, I recommend we use DXF2 because we can easily get a data set template and map that to the OpenLMIS column names that we output.

4) Once we make these decisions, we need to figure out how much of this should be built in the reporting stack vs. mCSD microservice vs. an OpenLMIS microservice (such as referencedata).

(FYI @Sebastian_Brudzinski and @ibewes )

(Josh Zamor) #2

Thanks @craigappl,

Could you explain more about what problem the options in #2 are solving? I don’t quite understand this one.

My 2 cents overall are:

Much if not all of this can’t really be determined without knowing general LOE and comparing that with other priorities and scope for 3.6. This is the case as in my view 1b is additional scope on top of 1a. i.e. we need to do 1a, publish a metric in some (any) format, in any case before we even think about the mechanics of moving it as a message to DHIS2.

Given the 2/3 formats that are most obvious, FHIR to me makes the most sense (simpler form, experience with JSON > XML, presence of FHIR libraries in our toolchain already) to target until we’re sure that we have the room/scope to include all the extra work (e.g. demo data alignment, see OLMIS-5475) that’d be needed to send the message (1b) to DHIS2 successfully.

I’m essentially restating that we need to complete OLMIS-5475 and OLMIS-5473 (though those tickets could use some cleanup to be more concise and practical) before we know if we have the scope to accomplish 1b. I’ll put some time aside to clean these two tickets up before the start of the next sprint and ping you for review so they may be started.

(Craig Appl) #3

Hi @joshzamor,

I just got back to Seattle and have significantly updated the SRS draft.

I think we are approaching the problem from different angles. I understand this side as we build out the metrics in a standard way and make them available before we consider transportation. My recommendation is that we build the crosswalks and transportation mechanism and then provide a way for the system administrator to match the formats for each specific report. The difference is that we wouldn’t necessarily have to expose a public standardized API for consumption.

(Josh Zamor) #4

Welcome back!

Could we do this in person then? Tomorrow at the VR office? Would help to get this solved for sprint 117.


(Craig Appl) #5

@joshzamor and @ibewes,

TLDR: FHIR doesn’t have a destination that can store requisition information. We need to rethink our strategy and choose to use FHIR differently, or switch to ADX.

Jeanette just completed her analysis of the FHIR server and we have determined that FHIR does not have the appropriate resources to hold the indicators required for this DHIS2 integration. The MeasureReport resource is built to calculate measures on existing resources within the FHIR.

We evaluated the Medication resource, which has the ability to represent a product in FHIR. This resource is primarily meant for patient centered workflows to track prescriptions. We could not find a way within FHIR that would allow us to model quantities of medication available within the system. FHIR clearly has the ability to define medications and perform transactions against them, but does not have a way to model quantity available.

The MeasureReport is meant to provide a standard interface for reporting against the resources that are defined in FHIR. In this case, we need a resource in FHIR for what information was sent on the requisition. I have been through numerous FHIR resources to see if we could somehow fit it in and there isn’t a clear place. There is a SupplyRequest resource, but it doesn’t provide any link to report historical information like a Requisition does. There is a Questionnaire and QuestionnaireResponse resource that is generic, but the description suggests that they are for patient information primarily similar to an observation.

I see four paths forward:

  1. We figure out a way to support FHIR MeasureReports directly from Superset by adding a FHIR MeasureReport API endpoint that returns the measure report for a particular chart type.
  2. We write a custom resource in HAPI FHIR that can receive the requisition information, utilizing the Medication and SupplyRequest request resources where possible.
  3. We switch to supporting ADX as the standard and build an API in Superset that can return results as ADX instead of JSON or CSV.
  4. We publish the Superset reporting API as it is and focus on converting it to ADX or DXF as part of the transportation process.
(Josh Zamor) #6

Thanks @craigappl and Jeanette,

Could you elaborate what you mean when you say this? My initial pass led me to think that we’d define a Measure per product, Facility maps to a Location (we have) in the MeassureReport.reporter field, program period to MeassureReport.period (we’d need to load into FHIR), and Program likely to, though group was the one that need the most exploration. Is this what you’re seeing?

Overall we’re pretty aware that FHIR’s Meassure and MeassureReport are both early in terms of maturity (level 2 atm) and more focused on the clinical side rather than the supply chain side, so I don’t think we’re looking for perfection at this point, only a neutral format to start defining the indicators for now, and a format we think will grow in industry for our future (which will likely require some future work on our part). In other words if we can make it work without much fuss today that’s more valuable to us for now than finding the exact right definition, as so far our research hasn’t lead us to a more perfect supply chain format that also is a strong interop contender for DHIS2.

(Josh Zamor) #7

Also if this is easier to walk through on a call or in person I’m available.