This page documents the discussion we had on 29th Aug 2018

Participants:

Discussion:

We need to decide on the role of OpenLMIS and interoperability strategy as a community.
- Idea: We develop to a specification and the implementer is responsible for performing that integration.
  - It's important to use standards in this space.
  - Do we create a list of features that are point to point integrations or
- This discussion is really interoperability vs integrations
  - Interoperability is standard based
  - Integrations leverage interoperability interfaces to deliver a specific connection between the two systems.

Conversation with Carl Leitner:

DHIS2 is very interested in FHIR at the transactional level, not necessarily the aggregate indicators
At the aggregate level, they support ADX.
Currently, DHIS2 is not able to consume a Dataset definition
- We would have to do a human process where they create the data element in DHIS2, get the UUID and cross reference it.
- This requires humans and is tightly coupled on DHIS2 workflows.
FHIR Measure and Measure Reports are intriguing because it removes the human requirements.
In order to do that, we get into the space where we need an ETL to convert the FHIR measure and Measure Report resources to create the indicators in DHIS2.
There is a mapping between measure and measure report and ADX
Each implementation may perform indicator reviews and this could help.
This adds value when a DHIS2 domain
There needs to be a map between DHIS2 org units and OpenLMIS geographic levels and locations.
- This integration assumes that there is a map between these systems
- OpenLMIS may have sublocations that roll up into a different unit.
Master Facility Registry
- There is a facility reconciliation where there are multiple sources of facility information.
- Global Open Facility Registry (GOFR) tools.
  - This maps DHIS2 into the Org unit hierarchy.
  - There is also a tool used for matching two facility lists. It steps through the hierarchy levels and makes sure the geographic levels agree. I then matches facilities at the lowest level of the geographic hierarchy. It then provides a "guess" based on statistics that is verified by a human. Once matched, it's stored in the interlinked registry.
  - This will be linked to healthsites.io
OpenLMIS has a list of KPIs from developers who worked on eLMIS and OpenLMIS v2.
DISC indicators are mostly based on
The Gap here is that no one has a standard list of indicators that are supply chain specific. OpenLMIS has the opportunity to do this. Ideally, the Health Data Collaborative LMIS working group could develop this. The interagency supply chain group may also develop this.
This integration assumes alignment on:
- Locations
- Periods
- Indicators (semantically defined)
OpenLMIS is not the only system that reports indicators to DHIS2. We should have a more generic tool to go from the FHIR Measure tool to utilize.
- If we publish FHIR Measure and Measure Report, then who can consume it right now?
  - This will use a FHIR server like Hearth or library like HAPI
- We would need a transform from FHIR Measure to ADX.
- The biggest problem with DHIS2 is that you can define an indicator externally and publish it to DHIS2. DHIS2 is really the only client of ADX in use in our space.
Regarding FHIR Measure and ADX. How does this add value?
- This adds a looser coupling of indicators between systems given that DHIS2 is the only consumer.
In the future, it would be good to have multiple systems publishing their indicators and DHIS2 consumes those.
- Ownership of DHIS2 implementations is critical. This requires a change in how DHIS2 ownership takes place. DHIS2 would be a client.
In the supply chain, there are NCx12 and EDI that are standard documents. These are robust standards in supply chain domain and FHIR is health business domains.

How do we drive to a decision?

We need to review the current metrics (Clay)
1. Define them (Josh says there are 4)
2. Write a data dictionary - This is the indicator, this is how it's defined in OpenLMIS. (publish this)
3. Identify if they should come from the reporting stack.
4. How do we take something from the reporting stack and publish it as a feed.
We need to do a spike to look at the FHIR measure and measure report specifications in FHIR and ADX. For ADX specifically look at the HIV profile. (https://wiki.ihe.net/index.php/Aggregate_Data_Exchange_-_HIV)
1. Analysis includes:
  1. Complexity of generating it
We need to decide on how to demo and help implementations integrate with DHIS2.
1. Jembi is working on the ETL process to read FHIR measure resources and push to ADX.
2. We need to figure out what a DHIS2 demo looks like. How do we stand up DHIS2 and make sure there are indicators in it that are supply chain relevant.

Browser not supported