2019-01-25 DHIS2 v3.6 scope
Date
Jan 25, 2019
11am - 12pm PST
Meeting location
Skype
Participants
@Josh Zamor
@Mary Jo Kochendorfer (Deactivated)
@Wesley Brown
@Craig Appl (Unlicensed)
Goals
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.
Discussion topics
Time | Item | Presenter |
|---|---|---|
5m | Intro and agenda review | @Josh Zamor |
| Present background for scope | @Josh Zamor |
30m | Open Discussion | All |
10m | Make & Log decision | Decision holder: @Wesley Brown |
Background
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 - deliver in 3.6 | Risk to project |
|---|---|---|---|---|---|
(#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. | Either way, both options have risks. Both are manageable. |
Options for scope
#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
If we didn’t do scope #2, what would we do?
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.
Why is transporting metrics to DHIS2 optional?
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.
Discussion
Can Ona deliver the production readiness epic with both scopes?
We would have to down scope the production readiness and identify exactly what we could deliver as a team.
Josh: we would want to improve the CI/CD process
Mary Jo: If we cut scope, we should focus on end user facing information
Josh: Key thing here is DHIS2 needing to have a list of products that map to OpenLMIS. Assumption: should we just send tracer products? What about all products?
Mapping products across multiple systems is challenging in these environments without a product master list. Is DHIS2 a product master list in some way?
The rest of the community has gotten to a place where you can integrate with DHIS2, but there isn’t a champion in this space
Action items
Decisions
- For 3.6 we’re going to aim for delivering scope 2
- Move up production readiness to high priority
- Move transport/hosting priority to medium
- Will consider moving to a more robust solution when better tools exist
- The transport that we deliver is a reference - and we need to be clear what that means for maintainence
OpenLMIS: the global initiative for powerful LMIS software