OpenEMR Xml Form Generator

The XML based form generator (xmlformgen) is available at the following link:

XML Form Generator

It contains a series of XSLT stylesheets, a Makefile, and a pile of .xml files.

The XML files (at least the more recent ones) contain form definitions. (look at initial_contact_sheet.xml and communication_log.xml for examples)

Dependencies

This form generator uses xalan-c++ to interpret the contents of XSLT files. it also uses a simple Makefile, so requires (likely) GNU Make.

Filesystem access is required to install a generated form into an OpenEMR installation.

Using

To 'compile' a form, run "make INFILE=filename.xml". This will create a directory with 7 .php files, and one .sql file, hopefully conforming to The Forms API. to import one of these forms, copy it to the interface/forms location in your openemr install. then go to the administration->forms page, and the form should be shown at the bottom of the page. Register it, run its sql, enable it, and you're done!

XML File Format

Header

Version

<?xml version="1.0" encoding="ISO-8859-1"?>

Generation information

Indicates how generated and by whom

<!-- Generated by Hand -->
<!-- Created by Rix White on 2010-01-27 -->

Open the form tag

<form>

Comments

Comments regarding the form and its approval by the CRRT

  <!-- MHP Progress Note -->
  <!-- this OpenEMR form has not yet been approved by CRRT -->

Table

Content

Indicates the sql-safe name of the table where the data for this form will be stored.

Attributes

The 'type' option indicates the table type

• form indicates that this form happens in an encounter, and it will not have a history. (this is what formscript.pl does)
• extended indicates that this form can fall outside of the encounter system (like 'history'), but it doesn't prevent it from being part of the encounter system. Mainly, it gives us a form that saves edit history. CAVEAT: don't use the same extended form to replace history, AND as an encounter form. this requires the signature system (not yet built) to function.

 <table type="extended">form_mhp_progress_note</table>

Names

Both of these names will show up in the `registry` table. 'RealName' will be in `registry`.`name` and 'safename' will be in `registry`.`directory`

RealName

Indicates the name as it will show up in the GUI

 <RealName>MHP Progress Note</RealName>

safename

Indicates the html-safe name

 <safename>mhp_progress_note</safename>

Style

Content

• Layouts: similar to the layout engine
• Paper: similar to the encounter system forms style

Attributes

• cells_per_row: Indicates how to build the html table structure (i.e., how many <td>s per <tr>)

 <style cells_per_row="4">layout</style>

Acl

We don't know how this stuff works yet.

Attributes

• table:

 <acl table="patients">med</acl>

Body

<Manual> and <Layout> tags

The <manual> tag and the <layout> tag both enclose a part of the XML document that indicates sections and fields the form generator will generate. The difference between the tags is that layout will create a php page that honors the layout engine (this functionality is currently broken), whereas manual dictates specifically how the layout will look.

<manual>
  ... some sections with fields ...
</manual>

<Section> tag

The <section> tag begins a named, collapsible section of the form.

• Content: The content of this tag consists of the fields (see next wikisection)
• Attributes: The attributes that this tag requires are
  • name: indicates the name used for the div in the html
  • label: indicates the visible name of the secton that will show up in the GUI and (I assume in the <layout> mode will be the name of the section that goes into the `layout_options`.`group_name` field

<section name="client_info" label="Client Info">
  ... some fields ...
</section>

<Field> tag

This tag is where the rubber meets the road. It creates the fields at every level: sql table structure, html forms, etc. It has no content, only attributes, and it closes itself thusly:

<field [put some attributes here] />

Basic attributes

• name: dictates both the column name in the sql table and the name of the html form field
• label: dictates the label for the html form field that will be visible in the GUI
• type: dictates the data type both for the html form field and the sql table (more on this below, as each type dictates further required and optional attributes)
• hoverover: dictates the title attribute of the html form field (be careful with single quotes here, they should be escapable with a backslash, but this needs to be tested)
• labelcols: dictates the html table colspan that the label will use
• cols : dictates the html table colspan that the form field will use

Text types

textfield: dictates a varchar text field

• required extra attributes
  • maxlength: dictates the varchar length of the table column where the list data will be stored
• optional extra attributes
  • length: dictates the size of the html form length - defaults to 10

     <field name="test_textfield" label="Textfield" type="textfield" hoverover="" length="50" maxlength="255" labelcols="1" cols="3"/>

textbox: dictates a textbox capable of 64k of text

• no additional attributes

     <field name="test_textbox" label="Textbox" type="textbox" hoverover="" labelcols="1" cols="3"/>

textarea: dictates a textarea capable of 64k of text

• optional extra attributes
  • rows: indicates the number of rows in the visible textarea - defaults to 4
  • columns indicates the number of columns in the visible textarea - defaults to 40

     <field name="test_textarea" label="Textarea" type="textarea" rows="10" columns="80" labelcols="1" cols="1"/>

List types

checkbox_list: creates a checkbox list which allows for multiple selections to be save in a pipe-delimited format

• required extra attributes
  • list: this references the 'listid' of a list in a <list> tag (which, itself, should refrence the listid from the list_options table)

     <field name="test_checkbox" label="Checkbox" type="checkbox_list" list="yesno" hoverover="" labelcols="1" cols="1"/>

dropdown_list: creates a dropdown list which allows for single selections to be saved

• required extra attributes
  • list: this references the 'listid' of a list in a <list> tag (which, itself, should refrence the listid from the list_options table)
  • maxlength: dictates the varchar length of the table column where the list data will be stored

     <field name="test_dropdown" label="Dropdown" type="dropdown_list" list="status" maxlength="30" hoverover="" labelcols="1" cols="1"/>

Other types

date: indicates a datetime sql field (stripped of the time) and ensures a calendar widget next to the field in the GUI

• no additional attributes

     <field name="test_date" label="Date" type="date" hoverover="" labelcols="1" cols="3"/>

provider: creates an int(11) field that references the "providers" from the `users` table

• no additional attributes

     <field name="test_provider" label="Provider" type="provider" hoverover="" labelcols="1" cols="1"/>

List

Every list type in the <sections> above should have a list in the <list> area. Right now we're not importing lists (notice that the import attribute ="no") so there is no need to have content for these tags (which would normally be the list items) and the list tag can close itself. Both self-closing and with-list-options are shown below.

Please keep in mind, that OpenEMR's lists system has a 31 character limit for list ids and listitem ids.

Note: if you don't have the list created in Oemr already and/or your list id attribute isn't referencing a real list, then the field won't show up in the GUI.

List with options:

  <list name="yesno" label="Yes/No" type="standard" id="yesno" import="no">
    <listitem id="NO" label="NO" order="1">NO</listitem>
    <listitem id="YES" label="YES" order="2">YES</listitem>
  </list>

List without options that closes itself:

 <list name="marital_status" label="Marital Status" type="standard" id="marital" import="no"/>

Justin Doiel is probably working on this as you're reading this page.

formscript.pl

Q: hey, Out of curiosity is this using the formscript.pl script? Just noted it in the 'make' file?

A: Not at all. its meerly there because i was using it for comparison purposes.