Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
A standard OpenMRS implementation focuses on collecting data within and about a patient - encounters, observations, orders, etc. However, at many health facilities, only a fraction of the overall patients are actually captured in OpenMRS. Some implementations may only manage HIV patients, or only TB patients, or only collect limited patient registration data. Although other patients are still being seen and cared for at the health facility, the data surrounding their care is not captured within OpenMRS. Reporting requirements - to funding agencies, for monitoring and evaluation, etc - may be such that some of a given report's data is captured in OpenMRS patient records and some of it is not. This leaves a gap in what is achievable with standard OpenMRS tools to fully produce such reports.
Additionally, there are many important pieces of data within a health facility that are not patient-centric at all. These include questions such as "Are critical supplies in stock?", "Are services like internet, power, and lab equipment functioning correctly?", "How many community health worker training sessions were held last month?" etc. Although not patient-centric, these data points may still be important for monitoring and evaluation and ensuring quality care at a particular health facility.
The facility data module is meant to address these gaps. It's goal is to provide a mechanism for defining facility-level data collection forms, which are filled out on a regular, periodic basis, and which can capture the data points which are important to your organization.
Using the facility data module is a fairly simple process. Your first step is to figure out what data you wish to collect and how often you wish to collect it. Currently the facility data module supports forms that are entered daily (either every day or a subset of days per week, per the global property above) or monthly. Each form can contain one or more sections to logically group questions together. Questions are defined independently of forms, and the same question can be added to multiple forms. Each form can customize the display label and question number that is associated with a particular question that has been added to it. Each question that you create must be associated with a particular user-defined question type. Question types fall into 2 broad categories - numeric or coded, and fully control the allowable answers for a given question. Users should define as many instances of numeric and coded question types as they need to meet their specific data collection requirements.
As described above, question types are the means for specifying the allowable answers for a given question. Because of this, defining these will likely be done at the same time that you defining your first questions. However, ongoing these are likely to be rather stable and will be continually re-used among new questions that you define. Because you must specify a valid question type when you create a new question, creating your question types come first. Here are some examples of how question types are envisioned in use:
Steps for creating or editing a question type:
Once your question types are defined, creating questions is very simple.
Steps for creating or editing a question:
Once you have your questions defined, you can put these together into forms, within one or more sections. To be more precise, once your questions are defined, you can put these together into one or more form schemas, within one or more sections. A schema is the actual part of the form that contains the questions, and a particular form may have one ore more schemas associated with it. The reason why this is done is to support versioning. It is common, particularly for forms which are filled out in order to report a particular set of values to a funder or Ministry of Health, for the questions on these forms to change constantly. By abstracting out the questions that are asked for a given time frame from the conceptual form that is being completed, we can support this more easily.
For example, let's say we want to create a form for capturing daily vaccination metrics to report to the ministry of health. We have defined our question types and questions, and now it is time to build the form. We can do this by completing the following steps:
Step 1: Create a new form
Step 2: Add one or more sections to the form
Let's say we want to add 2 sections to this form: "Vaccinations administered", and "Vaccination stock status". We can do this by clicking on the "Add new form section" link on the schema summary page, and providing the appropriate name when prompted - once for each section. Once these have been created, you will notice that each section has the following actions available:
Step 3: Add one or more questions to each section
To add questions to a particular section, you first need to select the section you wish to work with from the select list on the right of the schema overview page. Once you have done that, clicking "Add a new question to this section" will give you a dialog box with 3 fields:
At this point, your form is ready to use, and you can skip down to the next section on Entering and Viewing Data. However, to continue the documentation on Administering forms, we will continue here with further steps for how to adjust to changing form requirements over time...
Step 4: Make a new version of an existing form
It is very common for data collection forms such as these to change over time - questions are added, questions are removed, questions are changed slightly, etc. To handle this in a way that preserves existing form data faithfully, we can create new form schemas that are associated with an existing form, and set validity periods on each schema to record which questions were in use at which point in time. To carry on with the above example, let's say that we wanted to add some additional vaccination stock status questions that we were not previously tracking:
Once forms are created, users can start entering data. To facilitate this, a dashboard is presented for each form that displays the data entry status of a range of dates, by facility. This provides a useful summary of what data entry forms are not yet entered, entered incompletely, or completed, as well as what dates are not applicable for entry, due to schema validity periods or global property configuration. See the screenshots below for examples of what this looks like for new forms which are entered Daily and Monthly.
From this dashboard view, users can click "Enter" on a particular cell to fill out a form for the selected period and location. Each form provides an appropriate input for each type of question that is defined, as well as a field for recording any comments, as needed. Once saved, a report displays in view mode, with a button to further edit it if desired. When you return to the dashboard, if a report is partially completed, it will show up as yellow. If a report is fully completed, it will show up as green.
For the initial release of the module, this section contains a single tool, available by clicking "Data completion and aggregate analysis". This tool allows you to choose a Schema, optionally limited by Facility and date range, and to generate a summary report that provides the aggregate answers to each question in the schema for the criteria specified, as well as an indication of how many reports were completed.
For the initial release of the module, this section contains a single tool, available by clicking "Export raw values to Excel". This tool allows you to choose either a form or a question, optionally limited by Facility, date range, and entered date range, and to export all entered values to Excel that match this criteria. This exported spreadsheet contains 2 sheets - one with the exported data, and one that contains the details of the export query. See screenshots below and to the right