Notes: OpenSRP, OpenLMIS, DHIS2

Owned by Mary Jo Kochendorfer (Deactivated)
Last updated: Oct 25, 2017
7 min read

Day 1

Day 1 Opening

Craig A (Unlicensed)

Greg Wilson (ETL, security, implementer)

Timothy Harding (Unlicensed) (reporting)

Seffen (partnership, future work, DATUM and DATUM4U)

Jen

(see full list of attendees here: In-Person Meetings: DHIS2, OpenLMIS, OpenSRP)

OpenLMIS 101

https://docs.google.com/presentation/d/1xv1Q1az-dA4uXhFNRb0vbYx7LAICI3D_O-NU70-f6Mo/edit#slide=id.g28bc0b16c3_0_147


Interoperability

Challenges: 

  • we are more restful than rest


HISP nodes are all independently. Consulting group with one core developer in each of one of them.  HISP nodes support DHIS2 regionally and countries directly. HISP nodes don't usually host DHIS2. HISP South Africa hosts 130 instances.

Example: DATIM4U

PEPFAR vision for the world

  • DHIS2 at global scale.
  • Datim4U - is at the USAID mission level (a separate instance of DHIS2 per country)
  • 13 countries were synced up 
  • Uganda is the first country. Their system already looked like DATIM4U, so was relatively easy.
  • Updating indicators once a quarter
  • 50 million records in DATIM4U
  • Future plans: "Datim 4 Everything" to launch Datim's for partners, for ministries, etc. There are other existing systems in that space.

 

Vision

Problem Statement: Silo'd approach to data management at a national scale.
Opportunity: Take a holistic approach to managing data at a national level. Offer a suite of open source tools. Harmonize the open source tools.

My increasing visability MOH can reduce the amount of capital tied up in the supply chain and avoid stock outs.


PSNU = Primary Sub-National Unit - a geographic unit such as a province, region, etc where indicators are measured and goals are established

RHIO = Regional Health Information Officer - responsibility for getting all the health reports from that region to put into DHIS2/reporting

CRVS = Civil Registry of Vital Statistics - e.g., birth and death, drivers' licenses, etc


Zambia Use Case

OpenSRP Goal is to monitor health for children. Replacing the registry of kids and the tally sheet (usage for that day).

Health Center:

  • Growth monitoring
  • vaccines

Demographic coverage versus lots of kids showed up (using our numbers)

Reporting module. Aggregates usage data and allows for editing for the numbers prior to submission. Currently if the tally is modified it doesn't update stock management usage.

DHIS2 OrgIDs are pulled into OpenSRP.


Use Cases for Integrations

Where is the largest value add?

  • Stock managment at the facility
    • Wastage tracking
  • link usage to stock levels
  • Demand forecasting (accurate registration of kids)
  • requisitining/ordering stock
  • visability into other SOH of other facilities
  • Lot to dose/chid for adverse effents
  • Rebalancing between facilities
  • Advanced shipment notice
  • DHIS2 scorecard view - of what facilities have what have what Stock 
  • Recording VVM
  • Bring together data for reporting across HMIS/LMIS
  • Labs/reagents/lesults OpenELIS (are the analyzers)
  • adverse events tracking (bridges these two worlds; and it should flow into DHIS2, have alerts triggered when there are increases)
  • Cold Chain Equipment






If we want to view consumption side-by-side (OpenSRP and OpenLMIS), we would need:

Mary Jo Kochendorfer (Deactivated) & Brandon Bowersox-Johnson, please review

A sample Minimum Viable Product (MVP) would include:

  • Linking aggregate care numbers for a given DHIS2 organization unit. This would be a map of health centered indicators, which are already in DHIS2 and supplied by OpenSRP in their standard reports against the commodity indicators from OpenLMIS
    • We would have to have a mapper betwen the DHIS2 org unit hierarchy and the OpenLMIS representation of org units
    • We would need a map between core indicators in the DHIS2 system and the OpenLMIS indicators that are generated in a report
      • Note that there is likely a many-to-one relationship between a stock item in OpenLMIS and an indicator in DHIS2. For example, number of Units dispensed by commodity type (OPV) would be a single item in DHIS2, but there may be multiple manufactured stock items that roll up into that single indicator.
    • There is precident for this in the ADX standard and implementation of this in the OpenMRS community with the DHIS Report module (source)and OpenSRP Server's DHIS2 connector (which uses the DataSets web API, not ADX)
      • Essentially, OpenLMIS would have to:
        • Build an authentication path to DHIS2 (somehow exposing a DHIS2 username and password as a configurable variable)
        • Pull in a DataSet Definition using the ADX standard
        • Provide a way to map a report in OpenLMIS to the fields in the ADX DataSet Definition (this is often column mapping)
        • Provide a view before providers push the report
        • Provide validation and error handling, including the ability to identify if columns aren't appropraitely mapped, if DHIS2 isn't responding, or if there are user account issues.
        • (Optional: Structure the system to support pushing to multiple DHIS2 instances, assuming they would need to push to DATIM for some variables and Ministry DHIS2 for others)
    • At the DHIS2 level, users would want a view that provides a side-by-side look at the OpenSRP information and the OpenLMIS information that was submitted with the ability to link to drill down for better understanding.
      • (Decision Point, should this link happen in DHIS2, or should there be an OpenSRP-OpenLMIS aggregate information portal? Who owns the the individual patient information and who should have access to see it?)
  • Linking Program data across systems: After the Org Units are appropriately mapped, major value will be added if OpenLMIS can share program specific commodity information with DHIS2.
    • DHIS2 Programs have indicators associated with them that may be similar to those in OpenLMIS. Core here is a program-level semantic understanding in both systems. Likely, the owners of a program will need to have a stake in the program in both systems.
    • (BAO can give a better definition of DHIS2 program examples here)
  1. facilities
  2. products classification


Use cases: integrations

We refined/re-formulated the list:

  1. Adverse events
    • CCE
    • Batch/lot tracking
    • notifications
    • EMR notifications (adverse reactions found)
  2. Stock/inventory management (7 votes)
    • OpenSRP → OpenLMIS usage/consumption of commodities
      • Emergency Requisition?
    • OpenSRP → DHIS2 aggregated stock usage (replace this with OpenLMIS?)
    • rebalancing
  3. EMR (OpenSRP)
    • OpenSRP → DHIS2 aggregated health indicators
    • OpenSRP → DHIS2 forecasting / case level
  4. EPI manager
  5. Team management
    • Reporting rates: non-reporting (in OpenSRP and/or OpenLMIS)
    • Nurse reporting rates (OpenSRP)
  6. Reporting & dashboarding (7 votes)
    • map view of ... everything
    • manage by exception or event
    • feedback component (to CHW, nurse, to patient?, e.g. a Chatbot)
    • data cleaning / quality / fraud / leakage
    • cost performance / forecasting
  7. Campaign management
    • when/where to start a campaign
    • coverage
    • stock availability → drive a decision
    • evaluating and reporting (#6)

Show and Tell on Reports

https://play.dhis2.org/demo/dhis-web-commons/security/login.action

Login and play around


Day 1 Recap

1. Map the Full Vertical Stack vision
Done: Tools and use cases
What next: articulate value proposition; define HOW

2. Define the DHIS2-OpenLMIS+OpenSRP integration
Done: How tools relate to each other, overlap, value of it, what belongs where


Day 2

OpenLMIS 201

- user roles and interactions for a Requisition, Stock Management


Define DHIS2-OpenLMIS+OpenSRP Integration and Proof-of-Concept + Reporting Vision (HOW the data flows between systems)

We diagramed user journeys for combining health and stock data:

Detail Views:

(See below for User Journeys for District/DVDMT/SMT and Donor View)


Technical deep dive 

Josh Zamor shared the approach OpenLMIS is taking with NexLeaf. <insert presentation>

Simple scenario

2 systems (no openHIE or DHIS2 etc.)

OpenHIE scenario 

We just plug in.

Middle scenario

What do we do when there are more than two systems?


Details: 

Areas to integrate

  1. Facilities: mCSD-FHIR with more details to discuss (DHIS2 v2.29-Jan18, OpenInfoMan could potentially manage facilities)
  2. Products: exchange is still up in the air.  Classification system (UNSPSC, GPC) / GTIN
    • Agree on using a standard classification system (GPC or UNSPSC) 
    • OpenSRP may only receive OPV usage
    • DHIS2 will need to make appropriate data element group (DEG and DEGS)
    • How does OpenLMIS update other systems? Or how does the other systems stay up to date?
    • Simplest product alignment could just be using a classification system (UNSPSC or GPC)
    • More advanced alignment could be a Product Registry in the future
    • Also advanced needs around managing Lots
    • OpenLMIS could be a product registry for now.
    • What standard to use for a Product Registry? TBD → Need to talk with USAID and others.
  3. Programs
  4. Providers: want auth - for now and leave Health worker reistry alone
    • nurses and doctors with certifications who have an encounter with a patient
  5. Stocking events (requisition stock): EPCIS, 
    1. Need to figure out the steps to getting there
  6. Authentication: OAUTH

EPICS

DHIS2

  • Data element (where the data is stored)
  • Indicators (metric I want to measure, data element and a formula, metric, composite, etc.)
  • Category option combo

Open Question:

Does the storeroom manager need to be registered in the HIE space?


User Journeys for District/DVDMT/SMT and Donor View

Overview:

Value/Benefits:

Global Digital Health Forum Next Steps

See GDHF: DHIS 2, OpenLMIS and OpenSRP Integration POC for details on next steps.


Day 3

Reporting

The team went through the initial DISC indicator, Full Stock Availability (defined as absence of stockouts between resuppply periods). The DISC indicators are defined on Reporting and Analytics

Peter Lubell-Doughtie (Unlicensed) or Brandon Bowersox-Johnson could you insert an key notes/take aways or the next steps (if there were any)?

Mobile 

Mobile development concerns

  • Style consistency (and maintaining that)
  • DRY business logic
  • Avoid multiple data caches and data caching stratedgies
  • Mobile tools need focused single task experiences


Notes on the scope of work is taken on OpenSRP and OpenLMIS Integration




OpenLMIS: the global initiative for powerful LMIS software