Overview

OpenMRS is really a platform for building medical record applications, rather than being primarily an application itself. As such, it doesn't actually include content (e.g. lists of lab tests, questions you'd ask a patient, diagnoses, etc), rather that content is created by the administrators setting up a system. One of the main things that an administrator will do, is create forms. (In nearly all current installations, clinicians fill out paper forms, and data clerks enter those into OpenMRS.)

The process of taking a paper form that has been agreed on by clinicians, and creating an electronic version is laborious, painstaking, and error-prone. This project involves creating a module that to automate and support the workflow of taking a form from paper to the electronic version.

Current workflow (before this project)

A typical process for creating the OpenMRS version of a form would be:

Someone gives you a word document of the form
You print it out
For each question on the form, you search through the OpenMRS concept dictionary, and find the right concept id for that question, then write it onto the corresponding question on the printed form
- An example of having gone partway through this process is archive:here
If any questions do not have concepts in the dictionary yet, you create them, and write the ids of the newly-created concepts onto the corresponding questions on the form
Once everything is done, you go on and do more work in HTML Form Entry, or in Infopath

We want to support this process with a proper electronic workflow.

Here are some examples of forms:

Here are some pieces of forms with questions:

Forms snippets with questions

Homework

Read about the HTML Form Entry Module
- Especially the HTML Reference
Implement archive:this as an HTML Form

Design

Progress, To-Do List, Known Bugs

PresentationToPIH.pdf - Presentation to Partners In Health on July 27, 2010

Proposed features for this module

List all existing draft forms & Add a new one

Old versions

Location and program have been removed from this page

There is now a Preview button on the Overview page. It generates HTML using tags known to the HTML Form Entry module. The html can be copied from this screen into a form being managed by HTML form entry. There is currently no direct integration between the two modules.

After copying this into HTML Form Entry, the user would see. The encounter information is automatically added to each form at the top currently.

Clicking Add new Draft on the Overviews page brings the user to this page:

View/edit a draft form

Version with Tree Structure: This version uses a collapsible tree structure to organize data more clearly. We have also removed a lot of button clutter by having one add button in each area. The add button pulls up a menu where the user would select the type of thing to add. (Shown below) Colors would be used to more clearly distinguish the different rectangular areas.

Add item Dropdown Menu

Dropdown / checkboxes / radio buttons should all be 1 single entry in the menu shown below.

Question: Is this the best order to show things in? Or maybe they should appear in cascading menus?

Question: Are Provider and Attending Physician the same or different things?

Question: Date, Location and Provider are for the 3 special encounter tags in html forms. In these cases, the person creating the form would need to provide a label for the fields, but not other information, right? So, all we would need for those would be a simple pop-up window to enter the item number and item text?