Program Data Capture

Target release
Epic
Document status	DRAFT
Document owner	@Brandon Bowersox-Johnson
Technical Lead

Scope

Existing Examples

Program Data Example: VIMS IVD Form

Program Data Example: SIIL and SELV Distribution Form

Program Data Example: Regimens in V2

Program Data Example: Malawi TB paper form (paper example)

Desired Functionality

Based on reviewing the existing examples above, we identified the following desired functionality:

Feature	Description	Examples	Feasibility (Y/N/Maybe)	Notes

Feature	Description	Examples	Feasibility (Y/N/Maybe)	Notes
Easy Form Editing	Add/edit form fields without a programmer	Regimens admin UI offers limited capability
Place Forms into OpenLMIS	Drop forms into R&R process or the Distribution Form, perhaps as tabs or "steps" in a sequence	In the existing systems, programmer coding was required to build these forms. But the desire is for non-programmers to build the forms and somehow connect them into OpenLMIS, ideally by configuration in OpenLMIS (such as linking to a Form URL or UUID from a configuration screen).	will this require code?	how?
Connected to OpenLMIS Workflow	The program data form would be part of the workflow for the R&R or Distribution Form.	All (VIMS IVD Form, SIIL/SELV Distribution Form, and Regimens)
Numeric and Other Field Type Validations	When building a form, users could set a field type that would offer client-side validation. Types of fields and validations identified: non-negative integers (Regimens, SIIL/SELV EPI, and VIMS) temperature fields with decimals (for capturing degrees Celcius, eg 7.2; in SIIL/SELV Refrigerators tab) date fields (SIIL/SELV, and VIMS adverse effects) dropdown with multiple choices (VIMS fridge status) boolean yes/no (VIMS adverse effects)	All (VIMS IVD Form, SIIL/SELV Distribution Form, and Regimens)
Skip	Ability to skip a field or skip a row.	VIMS has a Skip option on multiple tabs to skip a whole row. SIIL/SELV ability to enter a number or leave it blank ("NR" checkbox if not reporting; and a "Apply NR to All Fields" button)
Calculators	Ability for numerical fields to total up (sum) or compute a percentage (eg, coverage rate)	VIMS has calculators to show a total (sum of other fields) as well as a Percentage (Immunization Sessions). VIMS Stock Status tabs also has many calculations that compute from previous columns. Finally, VIMS Drop-Out Rates on the Stock Status tab appear to compute based on data in the Vaccinations Coverage (tab 3). SIIL/SELV Coverage tabs have a few calculations that are percentages based on multiple fields entered.	maybe not?
Tables	Ability to layout the data fields in a tabular grid (so much of the current Program Data forms are tabular)	All (VIMS IVD Form, SIIL/SELV Distribution Form, and Regimens)	maybe not?
Layouts	Some ability to choose a layout where fields are side-by-side (not just all vertically stacked like a Google Forms tool) (note: ODK was always about swiping left and right, and supporting "matrices" of fields)	All (VIMS IVD Form, SIIL/SELV Distribution Form, and Regimens)
Progress Indicator	To show the user progress as they complete the form	SIIL/SELV has color-coded dots to show completion and sync status.
Connect by Facility, Program, Period	When we collect this data, it needs to be tied (by ID) to a Facility, to a Program, and often to a Period and User Account	All (VIMS IVD Form, SIIL/SELV Distribution Form, and Regimens) Also, VIMS adverse effect screen has a Product and Manufacturer dropdown to pick from those existing lists.		how?
Ability to Edit/Revise Data In Workflow	If one user starts the data submission, later in the Workflow (during Authorization) another user may be able to view and then edit the same data. (We hope this is not needed, because this it has complex edge cases around concurrent editing, syncing and conflict resolution.)	This is not needed for VIMS IVD form. The Regimens feature in V2 is editable in INITIATED and SUBMITTED states, but not editable in any later states*.
Pre-Populate Certain Fields	Certain fields, such as population/target numbers, are pre-populated. (There is a concern that this feature may be too complex for offline, distributed data collection. If a user is manually entering forms for 10 facilities, such as on a Distribution Informed Push process, would they have to download 10 copies of the form before they leave for their travels?)	We see this on SELV/SIIL and VIMS IVD Form.		how?
Connect to OpenLMIS Business Logic	Filling out one of these Program Data fields then becomes the input to other OpenLMIS calculations or business rules (eg, notifications).	VIMS Cold Chain tab creates new cold chain device records in the software. Those CCE records are then available for other business processes. The VIMS Stock Status tab and SIIL/SELV EPI tabs do not generate stock card line items (flagged as an Open Question to discuss.)	maybe not? (This might define what can/cannot be Program Data. See below.)
Reporting	Data collected in these forms should be available to some reporting/visualization/export engine.	All 3 examples do reporting in different ways. But all of them do make the data collected available for reporting.
Offline Data Capture	Ideally these forms could be downloaded to a device for offline fill-out.	SIIL/SELV do have a purposeful offline mode and sync support.

*Elias emailed about VIMS: "VIMS only supports one approval step for IVD forms. That approval is done at district level. Once submitted, the District Supervisor would be able to either approve or reject it with some comment. No other values are editable at the approval stage."

**Regimens in OpenLMIS Version 2 are only editable up until the R&R is Authorized. So it is editable during INITIATED and SUBMITTED states. Those editable states would all be happening at the same facility, although it could be conducted by two different logged-in users. Data is not editable once it leaves the facility for higher-level reviews and approvals (not editable once it is AUTHORIZED).

What is Program Data?

Working Definition:

We call it "Program Data" when:

a non-programmer would want to change the fields and data collected for implementation-specific needs; and when
OpenLMIS only needs to know WHETHER the data has been collected, but does not need to know the CONTENTS of what data is collected.

In other words, it is data that is not tied to the OpenLMIS system (its business logic, calculations, notifications). The timing of when this data is received can be asynchronous (collected at a different time).

We may decide to pick a different name. Examples: user-defined data, custom data, non-logistics data, non-stock data, un-actionable data.

There may also be a Program Data Persona who is the sort of person who defines what fields of information are collected. They are interested in getting this data so it's available for reporting, decision-making and analysis.

Open Questions

Below is a list of questions to be addressed as a result of this requirements document:

	Question	Outcome	Status

	Question	Outcome	Status
1	When stock transactions are captured, such as the SIIL/SELV EPI tabs or the VIMS Stock Status tab, does it generate stock card line items in the software? Or is it just captured as a monthly report that is visible for reporting but not in the system as a stock event/line item? (Josh talked about low-fidelity data that is not appropriate for populating our stock cards.)		Open
2	Should we change our terminology to call it something other than "program data"? (See notes above in "What is Program Data?" section)		Open