11am - 12pm PST
Skype
Reach common understanding of optional scope(s) - transport of metrics to DHIS2
Decide if Ona, in v3.6, will tackle the additional scope needed to transport metrics to DHIS2, before sprint 118.
Time | Item | Presenter |
|---|---|---|
5m | Intro and agenda review | |
| Present background for scope | |
30m | Open Discussion | All |
10m | Make & Log decision | Decision holder: Mary Jo Kochendorfer (Deactivated) |
There is a need to send a limited (up to 4) number of supply chain indicators from OpenLMIS to DHIS2.
To achieve this we’ve broken this work down into two broad scopes of work:
Compute the indicators (up to 4), and make them available for other systems to consume.
Transport these indicators, regularly, to an available and appropriate DHIS2 system.
LOE of each scope
t-shirt sizes | priority | able to be done in parallel? | Risk | |
|---|---|---|---|---|
(#1) Make available the indicators | 1 x Small | 1 | N/A | Low - tech is in use and well understood. Publishing is simplified in FHIR as we already have a FHIR server. |
(#2) Transport the indicators to DHIS2 | 2 x Medium + 1 x Small/Medium | 2 | Significant work here can be done in parallel even before the computed metrics are available (#1). e.g. acquiring and configuring a DHIS2 instance | High - LOE is significant, and represents the need to acquire servers, configure them, and build the transport mechanism. LOE doesn’t account for ongoing maintenance to keep the systems up and aligned which also adds to the risk. |
#1, compute the indicators and make them available must be done.
#2, transport the indicators, regularly, to an available and appropriate DHIS2 system is optional
It frees up 2 mediums and 1 small/medium to tackle critical concerns with the reporting stack’s production readiness.
Addressing these issues is aligned with the goal of interfacing with DHIS2, as this stack forms the basis for accomplishing scope #1 (compute the indicators) in a way that’s more usable by stakeholders.
TODO: add items from spreadsheet here
We can engage other community members, esp if they have ready DHIS2 environments, in helping us transport these metrics.
We can engage the OpenHIE (likely interoperability layer community) with our progress and ask for assistance in finding an appropriate vehicle for building the transport.
For OpenLMIS to claim that we’ve integrated with DHIS2, we can’t say the transport piece is optional, however actually providing a re-usable solution is difficult:
In practice many integrations with DHIS2 are direct and bespoke to the implementation.
Our vision of delivering a reusable integration is hampered by:
A common OpenHIE interoperability layer isn’t a specific tech that OpenLMIS can develop against. Each implementation, if it has such a layer, uses different tech.
Existing re-usable, automated, integrations rely on a community effort to define an ADX DSD (e.g. PEPFAR has done this). To get to this level we’d need in part to have a reusable Product Master. We can’t solve this only with OpenLMIS nor in the gap project.
While we can’t say we’ve integrated with OpenHIE, we can say OpenLMIS is integration ready, having helped:
OpenLMIS follows a facility registry using the FHIR standards, solving a key challenge for an interoperability layer.
OpenLMIS would publish indicators in FHIR standard, helping the interoperability layer maintain a mapping to DHIS2 IDs
OpenLMIS will be compliant with the Product Registry work, which will further assist interoperable product masters, needed for re-usable integrations with DHIS2.
Add action items to close the loop on open questions or discussion topics:
Type /decision to record the decisions you make in this meeting: