/
2019-01-25 DHIS2 v3.6 scope

2019-01-25 DHIS2 v3.6 scope

Owned by Josh Zamor
Last updated: Feb 07, 2019 by Wesley Brown
4 min read

 

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

Time

Item

Presenter

5m

Intro and agenda review

@Josh Zamor


15m

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:

  1. Compute the indicators (up to 4), and make them available for other systems to consume.

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

 

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

@Craig Appl (Unlicensed) and @Josh Zamor , figure out whether to use ADX or a FHIR Measure Report in the existing FHIR server running next to OpenLMIS
@Wesley Brown to engage BAO for transport piece
@Josh Zamor which DHIS2 versions are supported
@Josh Zamor and @Wesley Brown to discuss meaning of reference

Decisions

  1. For 3.6 we’re going to aim for delivering scope 2
  2. Move up production readiness to high priority
  3. Move transport/hosting priority to medium
  4. Will consider moving to a more robust solution when better tools exist
  5. 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