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 - 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.
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.
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).