App Features

As of release v1.0.1 (September 21st, 2023)

Patient and family registration

A common step in community health programs is creating a list of all persons and households in a health worker's area. OpenSRP supports registering households and people quickly using simple forms.

Patients and households are associated to a health worker through a location. A health worker is assigned to a specific area or set of areas, and every person they register is assigned to the same area or set of areas.

In cases where patients visit or health workers cover multiple clinics across area, both the patient and the health worker would be assigned to a higher level location. For example, instead of being assigned to a village, they would be assigned to a facility area or county. That would result in a patient showing up on any of the facility patient lists in that higher level area, and for that patients medical record to be synced to the health worker's device.

Editing submitted data

You can configure the app to allow data editing to fix mistakes or account for changes to information like name or address. Configuration options give you the flexibility to specify what fields can be edited. It is important to assess the downstream impacts of edits when designing your app.

Finding patients

Navigating to a patient quickly is paramount for health work, especially when in the community. Because it is common for OpenSRP to be used in places where many people may share similar names, we offer many ways for patient look-up.

Patients can be searched by NAME or ID. This is a manual search where the patient list is updated after two characters are entered (the results update without pressing "enter"). The search will display patients only assigned to the health worker (Read: how patients are assigned to health workers - this is linked to the appropriate management section)

The ID can be a national ID number, a local ID number, or an app-generated ID. For a national ID number or local ID number, there is an option to either have the IDs be non-unique (there is no restriction on reusing IDs) or system-unique (it is enforced that IDs are not shared across the system). App-generated IDs are 32 character long strings that are always unique.

Patients are listed in order of time overdue in each patient register, and can be configured to be listed according to other criteria. For households and patients, that means households with more tasks and more overdue tasks are listed first, and households with fewer tasks and fewer overdue tasks are listed last.

Patient records

Patient records can be configured to show specific information about the patient, such as their demographic details, as well as upcoming Tasks and list of recent visits. What information is shown, the order in which it is shown, and the color and highlighting of the information show are configurable.

Recording services

Patient and health service information is captured using forms with questions and fields. The app keeps the interaction as simple as possible and has error-checking to keep entered data accurate.

Input fields

A range of input fields are available: text/string, , number, boolean, single choice, multiple choice, dropdown, date picker, date and time picker, slider, attachment, display an image and display a label. Fields can be restricted to specific related entires — for example if there is a number entry used for phone number, it can be set to only accept a certain number of digits or else show an error message. Fields can also be set to required, which highlights the field with an error if the user tries to save the form without filling in that field. Each fIeld can have helper text which is accessible when the user taps a question mark icon.

Field styling

Field styling is flexible with regards to font size and styling. Labels for form can use any font (applying to the entire form), and individual words or sections can have fonts be styled as italic, bold, underline, and color. The back and next button colors and font can also be configured.

To style without any changes in the FHIRCore/SDK, use HTML tags as part of the question text. The following tags are supported:

• Bold: <b>text </b>
• Italic: <i>text</i>
• Underline: <u>text</u>
• Strikethrough: <s>text</s>
• Coloring: <span style="color:#006EB8">text</span>

Progress bar

A form progress bar can be configured to show or not. A progress bar is helpful in multi-page forms. It shows how far into a form a user is based on the current question viewed within the current total number of questions — and not based on the number of fields answered.

Care plans

Care plans are the health service tasks and protocols a patient should receive depending on their status or condition, with the purpose of making sure the right services are provided to patients when they are supposed to be given. The tasks in the care plan are scheduled at the patient receives the updated status.

For example, a patient who has just been recorded as pregnant will receive a schedule of antenatal visit tasks associated with their gestational age. Each task is completed based on completing a form associated with that task. For example, an antenatal visit in pregnancy week 32 might include a form to check for pregnant danger signs, baby heart beats per minute, and a counseling session, which the health worker can fill out.

Tasks can be constrained with dates that make them inactive, active/due, overdue, and expired. Taking the example pregnancy scenario above, the week 32 pregnancy visit task can be inactive until week 30, then become active for weeks 30–32, then overdue in weeks 32-35, and expire after week 35.

OpenSRP has prebuilt care plans for antenatal care, postnatal care, childhood health, and maternal health.

Offline mode

OpenSRP stores patient records entirely offline and is able to register patients and record services without internet or data access.

Data syncing

When a user is offline and then gets access to the internet with the app is open, records sync automatically with the centralized cloud-based server. Syncing can take place at specific intervals (in order to save battery life) or triggered manually by the user.

When offline, the most up-to-date patient data exists on the user's device. If a patient record is recorded on another offline device, the data from the more recent encounter is used.

Fully offline record sync

Sometimes, community health workers or other devices can be so remote as to never be connected to the internet or data connection. In this scenario, OpenSRP supports device-to-device data transfer to update a centralized cloud-based server. The way it works is a person with a device who does access the internet meets with the person with a device who never connects to the internet. Patient records are transferred up the line, from device to device, until records can be synced to the cloud to an internet-connected device.

Data can be transferred without exposing the patient records in the OpenSRP app. For example, if a health worker does not have access to another health worker's patient data because they are assigned to a different location, data can still be transferred through their device and to the cloud.

Tasks

Tasks are used to identify patients that are due for health services. They are meant to help health workers prioritize who to visit at any given time by prominently appearing in the register list views.

Tasks in OpenSRP can fit into five categories: (1) inactive and not completable, (2) inactive but completable, (3) active and due, (4) overdue, and (5) expired. Tasks are represented in the app in both register lists and profiles in configurable colors. They are listed in order of due date, and can be configured to be listed according to other criteria stored in the Task.

Tasks can be due on a specific day or for a time period. The primary settings for a task are the health service form that closes the task and time periods for when the task becomes active, remains active, becomes overdue, and expires.

In-app reports

OpenSRP can generate easy-to-understand indicators used by community health workers to track progress, celebrate successes, and learn about gaps in coverage. Indicators are calculated from a user's patient list (and so show a health worker's achievements) and are often tied to goals or targets set by health supervisors.

Stock and commodity management

OpenSRP makes stock and commodity management easier for health workers to anticipate how much they need and thus avoid stock outs.

When stock is received by a health worker, they use a consumption log form to document commodities received. As commodities are provided or used with patients during health services, stock is automatically deducted. If a stock level reaches a predetermined threshold, the app will highlight that commodity so the health worker can obtain more. During the next commodity refill, the app can calculate the correct balance the health worker should receive.

Multi-language support

OpenSRP supports multiple languages through translatable built in content and user managed translations of form and configuration content.

Peer-to-peer data transfer

OpenSRP supports peer-to-peer data transfer using “WiFi-direct” technology so that 2 off-line devices can connect to each other and synchronize information from one device to another. The receiving device will only be able to view devices it has permission to view, even though it may receive and store in its device database information it does not have permission to view.

Sync insights

Through sync insights OpenSRP makes it possible to understand which data has been synced back to the remote server and what data remains unsynced on your device. These insights help provide assurances that data is synced securely and timely. Sync insights also helps the health worker navigate and troubleshoot data connectivity issues, and is invaluable to teams when providing remote support.

Known limitations and potential risks

OpenSRP 2 allows a large amount of flexiblity in the creation of apps that run on it. This means that an app's correctness, usability, and effectiveness is dependent upon the content written for that app. To address this it is important to have a comprehensive testing and quality assurance process for the app's content.

Relatedly, an app's content is run through the various software layers of OpenSRP 2, including the Android FHIR SDK and it's underlying libraries, e.g. cql-ruler. A change in these components may affect the way the content is interpreted, and it is therefore essential to validate existing app content against new releases of OpenSRP 2 before upgrading.

Roadmap features

• Background capture of GPS linked to stored with specific actions (in progress)
• Content versioning linked to release versioning (in progress)
• Draft and in-progress forms
• Library of content configuration patterns and common use cases, e.g.:
  • Editing data that is not related to further generated data, e.g. names
  • Editing data that is related to further generated data, e.g. age or pregnancy status
  • Load all the members of a family into a Questionnaire, e.g. to select a caregiver.
• Questionnaire widget to capture GPS (in progress)