Draft Forms Project

Owned by Former user (Deleted)
Last updated: Aug 25, 2011 by Ellen Ball
5 min read

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:

Homework

  1. Read about the HTML Form Entry Module

  2. 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?

Edit Items Screens

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.

The following windows display, but do nothing when the user clicks Ok.