Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
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.
A typical process for creating the OpenMRS version of a form would be:
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:
PresentationToPIH.pdf - Presentation to Partners In Health on July 27, 2010
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:
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.
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?
This is the screen for adding text responses:
This screen allows the user to select a coded concept for a question:
When the user clicks "Add Answers", the following screen appears, populated with the coded answers that correspond to the coded question on the previous screen.
This is what the user sees when the user clicks the Edit button in the form above. This is how the user changes the label that will appear for an answer.
After clicking the "ok" button on the form that shows all the answers, the user will return to a page where the form can be edited. In that form, there is a simple preview of the form. The first question below has no explanation field. The second question has an explanation field, but there is no label on the field. The third has a labeled explanation field. The fourth shows explanations for checkboxes.
This following screenshot shows what would appear in an html form entry preview using the html produced by the draftforms module. This is for the same form as in the preceding screen.
The user can enter a Placeholder to mark a place in the HTML where an item must be entered by hand because it is not supported by this module.