Versions Compared

Key

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

Overview and Definition

...

Gliffy
imageAttachmentIdatt112580206
baseUrlhttps://openlmis.atlassian.net/wiki
migration1
nameProgram Data Tech Design
diagramAttachmentIdatt112580202
containerId112834164

Open QuestionQuestions:

  • Discussion around the natural key and configuration value or document/source ID.
    • Natural key for requisition service identified as composite of facility, program and processingPeriod, but this may not be true for other services; may need a document/source ID of program data.
    • This natural key may need to be configurable in some way.
  • Configuration may be needed on the requisition template .(does program data need to be checked for, for this program?) - this is true, but this would probably be dealt with in the requisition service; it does not affect the logic in the program data service

Proposal for DHIS2

We propose using DHIS2 as-is to capture data for facilities, programs and periods, because it is a mature product that already supports this use case. We will do a simple connection that allows OpenLMIS to query DHIS2 and determine whether data has been captured or not.

...

  • It fulfills many of the requirements, including all of the Must Haves, out-of-the-box:
    • Form design - can support basic and some complex forms through a WYSIWYG form designer (under Data set, data set management)
    • Data capture - done through Data Entry web app, with some offline support (support for connectivity interruptions measured in seconds/minutes, not hours/days); there is also a mobile web client and an Android app
      • Note: even though the web app does not have full offline support, the fact that many countries with intermittent connectivity are using it, indicates it may be sufficient for program data capture requirements
    • Reporting on data
    • Security - DHIS2 appears to have a robust RBAC design, similar to OpenLMIS
  • It has been proven to be usable by country ministries and facilities, and has a community behind it
  • There are no dependencies on external development; APIs have been released and are available

The weaknesses of this approach are that if we want it integrated into the OpenLMIS UI, we won't get the benefits that come out-of-the-box. Another weakness is that DHIS2 is another system that must be maintained (although often the country already maintains an instance).

MVP using Program Data Service and DHIS2

...

  • 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.
  • If we like DHIS2 and want to invest more in that integration, then:
    • Explore single sign-on (SSO) or synchronize users - 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
    • Explore 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"
  • If we find DHIS2 is unsuitable, then pivot to supporting ODK2 as a "backend"
  • If we find that there is a dependency on the content of the Program Data, then work on returning basic key-value pairs of program data and not just a flag of program data completeness