Program Data Requirements
For OpenLMIS, there is a certain need to collect programmatic data during the requisition process (and possibly other processes); this is called "program data". In order for OpenLMIS to support program data, several requirements need to be fulfilled:
- 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:
- Have full offline support (easy to go offline, capture data and sync it back to the server once online)
- Have an integrated look and feel with OpenLMIS, particularly during the data capture process
- Have a fully-featured form designer, to handle different possible complex forms
- Support a complex model for role-based access control (RBAC), similar to OpenLMIS
However, the ideal solution will take multiple iterations to accomplish, and the first iteration should focus on an MVP. This would fulfill the requirements in the previous section 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
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 other services–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
- Call to DHIS2 APIs, probably /api/<version>/dataValueSets
- Input: a mapped program data composite (facility maps to orgUnit, program maps to program, processingPeriod maps to period)
- Output: dataValueSet result, with completeDate if program data is complete)
A look at how this proposal fulfills the MVP requirements:
- No offline support for now - DHIS2 has support for "intermittent connections" (based on info received from DHIS2 training); it is still uncertain at this time if it has full offline support
- 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 is unclear at this time how fully-featured forms can be made. Based on looking at the DHIS2 demo (https://play.dhis2.org/demo/dhis-web-dashboard-integration/index.html), basic forms should be possible to do
- 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