Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Form design - determining what data needs to be captured and how, and designing a form to facilitate that data capture
    • This part of the system should be able to accommodate a user that is mostly non-technical (can use Excel or an interactive form designer tool to design forms)
  • Data capture - entering data into and completing a form as part of the requisition process
    • This part of the system should be able to accommodate a user that is completely non-technical (simple, straightforward form of entering relevant data; cues of what is incomplete)
    • There is additional value if this feature can be done offline
    • NOTE: data capture may be integrated into other processes (informed push, stock management), not just requisition
  • Reporting on data - taking the data, running reports and doing visualization on it
    • This part of the system should be able to accommodate a user that is mostly non-technical (can use reporting tool to generate reports or interact with tool)

Ideal Solution and MVP

For implementing Program Data in OpenLMIS, there is a difference between an ideal solution and a minimum-viable product (MVP). An ideal solution would fulfill all of the above requirements and:

...

  • No offline support for now
  • No integrated look and feel
  • Have a form designer to support basic forms
  • Have a single "admin" user for access

MVP Proposal with DHIS2

DHIS2 has features to facilitate both form design and data capture. Forms can be designed through the Tracker web app, or form metadata can be imported through the APIs. Data can be collected using the robust Data Entry web app (and potentially others in the DHIS2 ecosystem), which has some offline support. A user, as part of their requisitioning process, could enter programmatic data into DHIS2. As part of the same requisitioning process, that user uses OpenLMIS to perform the requisition. In order for OpenLMIS not to complete the requisition unless the dependent program data has been completed, OpenLMIS needs to query DHIS2

...

An to check for completeness.

Therefore, an MVP for Program Data with OpenLMIS and DHIS2, would require creating a new Program Data microservice. It would look as such:

  • This service would handle requests from consumers–Requisition service for MVP, but other services in the future like stock management or informed push
    • Input: a program data composite (facility, program, processingPeriod, and possibly isEmergency)
    • Output: true/false depending on whether that program data is complete
  • To answer these requests, it would make an external call to DHIS2 to get relevant data (integration piece)
    • Authenticate with a DHIS2 "admin" user dedicated to OpenLMIS integration
      • NOTE: this "admin" user does not have to be an admin of the system, but has the correct DHIS2 permissions to return data required by OpenLMIS
    • Call to DHIS2 APIs, /api/<version>/dataValueSets
    • Input: a mapped program data composite (facility maps to orgUnit, program maps to program, processingPeriod maps to period between OpenLMIS and DHIS2
      • An OpenLMIS Facility maps to a DHIS2 Org Unit
      • An OpenLMIS Program maps to a DHIS2 Program
      • An OpenLMIS Processing Period maps to a DHIS2 Period)
    • Output: dataValueSet result, with completeDate if program data is complete)

...

A look at how this proposal fulfills the MVP Program Data requirements:

  • No offline support for now - since there is no requirement here, DHIS2 would be sufficient to fulfill this
  • No integrated look and feel - since there is no requirement here, DHIS2 would be sufficient to fulfill this
  • Have a form designer to support basic forms - DHIS2 does have tools to design forms, although it Form design - forms can be designed through the Tracker web app, or form metadata can be imported through the APIs
  • Data capture - data can be collected using the robust Data Entry web app (and potentially others in the DHIS2 ecosystem)
    • Offline support - DHIS2 can support much of the requirements out-of-the-box:
      • DHIS2 (desktop client) has support for "intermittent connections" (based on info received from DHIS2 training)
      • Additionally, it appears that the client-server setup has support for connectivity interruptions measured in seconds/minutes, but not hours/days. For more complete offline support, there is an option to create an offline instance that syncs with an online server during connectivity
  • Reporting on data
  • Have a single "admin" user for access - Since DHIS2 does have authentication support (including OAuth2) and appears to have some RBAC, it should be easy enough to create an "admin" user for OpenLMIS to use

...

  • Support for Informed Push should be straightforward, as it would access the same Program Data endpoint with the same criteria (facility, program, processingPeriod). See interaction diagram above.
  • Offline data capture support
  • DHIS2 (desktop client) has support for "intermittent connections" (based on info received from DHIS2 training)
  • Additionally, it appears that the client-server setup has support for connectivity interruptions measured in seconds/minutes, but not hours/days. For more complete offline support, there is an option to create an offline instance that syncs with an online server during connectivity
  • Support a complex model for role-based access control (RBAC), similar to OpenLMIS - DHIS2 appears to have RBAC, similar to how OpenLMIS is set up, so it should be possible to create mappings of users between systems and potentially single sign-on (SSO)
  • Integrated "look and feel" - with SSO, it may be possible to put access to DHIS2 in an iframe in the OpenLMIS UI, but effort would be required to give it the same "look and feel"