Versions Compared

Old Version 13

changes.mady.by.user Chongsun Ahn

Saved on

compared with

New Version 14

changes.mady.by.user Mary Jo Kochendorfer

Saved on

Key

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

Overview and Definition

...

RequirementSub-requirementMust Have / Nice to Have

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)

Basic forms - enough to facilitate basic program data capture

  • A user can define the questions of the form, but the layout is just one question after another
Must Have

Complex forms - a fully featured form designer. Could potentially include (this list is not exhaustive):

  • Layout - how fields, labels and headers are organized
  • Skip - allowing fields or rows to be skipped
  • Validation - validating input is "correct"
  • Calculations - showing calculations in forms
Nice to Have

Data capture - entering data into and completing a form as part of a workflow

  • 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)

Online data capture support (one way sync)

Must Have
Offline data capture support - easy to go offline, capture data and sync it back to the server once onlineVery Nice to Have

Mobile (tablet or smartphone) data capture - either through a web or native app

  • Note: this is not mutually exclusive with the offline sub-requirement
Nice to Have
Two way syncNice to Have

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

Must Have

Integrated "look and feel" - elements of program data look like part of the OpenLMIS system (users do not need to go to a separate system to fulfill program data requirements)

  • This requirement is most important during the data capture process

Nice to Have
Security - ensuring OpenLMIS users can access their program data and cannot access other program data for which they are not authorizedQuick to implement:
  • Within OpenLMIS UI, only see data for your facilities/programs
  • Users need to sign onto another system to enter program data
  • Admin maintains users in 2 systems
Must Have

Better:

  • Single sign-on (SSO) for OpenLMIS and Program Data system
  • Unified RBAC across OpenLMIS and Program Data system
Nice to Have

...

  • 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

...