Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

<html><head><title></title></head><body>h1. Introduction

This document is a summary of community suggestions for a module that will render OpenMRS forms in a web browser. This discussion from the OpenMRS developer mailing list is archived at https://listserv.iupui.edu/cgi-bin/wa-iupui.exe?A1=ind0705&amp;L=openmrs-devel-l&amp;F=&amp;S=&amp;O=T&amp;H=0&amp;D=0&amp;T=1#5

Goal

Create a module that will render forms in a web browser using metadata already in OpenMRS system.

Proposed Roadmap

  • 0.1: Very simple form rendering – no additional display object; instead, control layout via CSS.
    • See if we can use FieldGen to generate web forms.
  • 0.2: Add attributes and attribute_types tables for both form & form_field along with metadata (xml) and view (xslt/css) columns for the form table.
  • 0.3: Enable rendering as XForms – perhaps choice between html and xforms.
  • 0.4: Add flow process to guide user through forms - wizard style.

Current data model background

Burke Mamlin:

  • field = widget-specific details or all of the meta-data needed to define a re-usable widget (e.g., max length, input filters, where to go for choice lookups, etc.)
  • form_field = all metadata needed to adapt a field for use on a specific form (e.g. form-specific details like prompt text, required vs. optional, drop-down vs. list, etc.)
  • form = metadata that applies to the form (across fields), including skip logic, UI details that's not specific to a field, etc.)

Schema additions

Mike McKay proposed the following schema additions, and Burke Mamlin tightened up the names to enable use of these tables for both fields and forms:

attributes

id
field_id
form_field_id
field_attribute_type_id
value

attribute_types

id
name
description

We may wish to spec these new tables out in the module, or they may become a part of the OpenMRS schema.

Code ideas

Use/refactor FieldGen

Christian Allen - FieldGen is a framework for having OpenMRS automatically render fields (in any web-based form) properly, by using reflection to find their type, and then finding the correct handler for that type (you can also override this). The Handler can add to the model, and then at this point, there are several handlers for different OpenMRS types, such as Concept, User, etc., but I'm sure more will be built. In addition, I think the framework could probably use an overhaul (it hasn't been touched since the early days of OpenMRS). But I think it could prove very useful.

Getting data from attributes tables to render webforms

We may be able to refactor FieldGen to use the new attributes tales to render the display. These new tables may help find the correct handler for a field in the FieldGen framework.

Mike McKay: The field_attributes table will capture the actual value of the attribute and allow it to be a foreign key for a either a field or a form_field. This allows for form specific field attributes, and general field attributes as well.

So from my examples above I would define the following
field_attribute_types:
min, max, condition, user_interface

Then of course, we add entries to field_attributes. Finally, when we render the html or xform or whatever we can write code that uses the attributes to modify the output accordingly.

Attribute suggestions

  • Simon Kelly: relevancy, calculation
  • Andy Kanter: language/location metadata for the form elements, like prompt text (smile). We'd want to auto translate the prompt text, be able to assign language/location to taskpane queries, etc. We'd probably also like to have some formating elements like word-wrap, or fixed length so that we can predict how changing prompt text would affect the final form (designing layout in one language then might not drastically change the layout when it is translated into another).

Form rendering suggestions

Ease of use

Burke Mamlin: One clear lesson from InfoPath is the power of the MVC pattern, so I'd strive to maintain some separation of these concerns in design...ideally without forcing users to work separately on the M, then the C, then the V. :o)

Validation

Mike McKay: I want to be able to add validation to the FormField. Allow us to indulge our imaginations for one second. Imagine that on ART Vitals forms, we want to add simple min and max (I know this can be done on the concept, already, but stick with me...). I want a min and max attribute tied to the formfield. Maybe I also want to skip the weight question on the field if the patient's height is less 20cm. Finally, perhaps I want to specify that this type of form should use the "number collection" user interface.

Easy widget addition

Chris Kelley: Sometimes widget rendering has to be rather specific-- a Date widget with no preset date, Date widget w/ preset date, Date widget preset 3 months in advance. I implemented these using Struts custom tags – include files w/ html/jstl syntax – that were rendered when the form was requested. I'm hoping we can make the process for adding a new display widget as simple as:

  • Write the text in html/jstl and save as a jsp file
  • The field admin page would query the filesystem for files in a widgets dir and present them in a dropdown. (Perhaps this would be done at startup and cached. Metadata in the jsp file would provide a description to be used as text in the dropdown.) Saving the field would then create/edit a record in attributes table with the value of the widget (the filename?), field_id, etc.

Community members interested in form-rendering

  • Carl Fourie - OpenMRS conference April 2007 presentation - developing DHTML XForms designer
  • Chris Kelley: Form rendering in ZEPRS, patient record system in Lusaka, Zambia that focuses on perinatal patients
  • Simon Kelly - OpenMRS conference April 2007 presentation - demonstration of XForms-based handheld system; schema designer from OpenMRS provides model instance data
  • Neal Lesh - OpenMRS conference April 2007 presentation - Mobile data collection - handheld system that integrates w/ OpenMRS
  • Mike McKay - OpenMRS conference April 2007 presentation - Form rendering on touchscreens for his ROR-based OpenMRS system in Malawi.

Other projects that use form rendering

  • Chris Kelley: Form rendering in ZEPRS, patient record system in Lusaka, Zambia that focuses on perinatal patients - tracking a pregnancy and postnatal care of mother and child. It's based on an earlier system I developed for ARV care in Lusaka in 2004. The architecture is somewhat similar to OpenMRS – tomcat/mysql, forms/fields – but is focused on live entry of data by nurses/clinicians rather than data entry from paper forms. The user interface is rendered "live" from form objects that have some similarities to what you’ve got in OpenMRS. The main difference is that there's an extra table, called pageitems, which stores UI-related information.

Links

  • Carl Fourie mentioned a product that converts InfoPath forms to web forms - not open source - called InfoView ( http://www.infoview.net/) I know that some implementors would like to reuse their InfoPath forms maybe this can help.
  • Mike McKay has released formtastic.us which designs and renders forms in html: http://formtastic.us/. He hopes to see it integrated into OpenMRS proper in the future (currently it is implemented as a rails application).

    </body></html>

  • No labels