This post shows how to build a form, in this case a veterinary skin assessment but the content is less important than the methodology. This does not discuss integration between forms, rather a simple standalone form
I have said 0.87 but there are only a couple of bug fixes since 0.86 that I used to help build this example. I’ll highlight those when I come to them.
There is a video (sorry no sound) that walks through the process but first lets just highlight some terminology that will be foreign to everyone. PatientOS forms and content are intertwined with the following concepts
- Record Items
A model (in PatientOS) is an object representation of one or more related tables which is used to transfer data from the database to the application code and encapsulates some business logic directly related to the model in question.
We have for example a PatientModel which is one-to-one with the patients table, with fields such as first_name, last_name, gender, etc and also has child tables such as addresses, phones etc
To talk about Models in detail is out of scope of this post and for now I want to focus on 3 tables and their corresponding models. The tables are forms, form_records, form_record_details
The models are FormModel, FormRecordModel and FormRecordDetailModel. The FormModel object contains records (i.e. a list of FormRecordModels) and the FormRecordModel contains details.
When we are adding a control to a form we designate a ‘Model Reference’ which is a field on the model, that corresponds to the database tables column. For the most part we are typically assigning a Model Reference If of one of the following
Record items is the name of the data element that contains the value. On the form_records table there is a column record_item_ref_id that stores this record item ref id. So if we want to store the height of a patient we would have a control with
- Model Ref Id: FORMRECORDS_VALUEDOUBLE
- Record Item Ref Id: Height Simple
The system comes preloaded with Height defined as a record item and it is coded so that can be properly used throughout the system or sent externally using OpenEHR, HL7 etc.
Terms are used for a couple of purposes. One they are used to define a concept (similar to a SNOMED concept) or coded value for record items like Symptoms, Diagnoses, Exam Findings etc.
They are also used as a handy method to have a checkbox (or other control) on the form that triggers orders, charges, and other tasks (like a form due).
In the dermatology assessment we use a few very general record item names (dermatology assessment question, etc) and use terms to distinguish each question on the form.
The important point in form building is that each control requires either
- a unique record item or
- a unique combination of record item + term or
- a unique combination of record item + detail item or
- a unique combination of record item + detail item+ term or
- a unique combination of record item + term + term sequence
Details are used to group controls together into a logical record (which is represented in the database as a single form_record row which has multiple form_record_detail rows) and term sequences are used (rarely) to show the same value over time or some other sequential progression.
There is much more to be discussed later on this topic.
With those concepts in mind the video will probably still not make too much sense There is still plenty of work to be done to streamline and help guide the builder through the process but that will come.
Video: Dermatology assessment (Flash)
Dermatology Assessment Creation Video
The video demonstrates the following steps
- Opening Clinical Forms Sections
- Right Click on the Folder Vet Hospital
- Adding a form section for questions
- We start by assing a text field
- First adding a new record item
- Expanding the record item domain tree adding the subfolders
- We add a record item Dermatology Assessment Question as a string
- We switch to the Terms Tool
- We add a term category folder Vet Hospital Assessments
- We add a subcategory Vet Hospital Assessment Questions
- We copy paste and format the text from the form until we have 1 line per term
- We switch back to our Form Editor
- We add a Checkbox Group
(This is a trick… it allows us to select all the terms we built and add them as controls to the form. We then use the multi-select tools to change the controls to the type need…)
- We write a few scripts to change properties on mass (like adding the colon to the end of the label)
- We select a subset of controls and turn then into textfields with a model ref of FORMRECORDS_VALUESTRING
- The toolbar has several shortcuts to actions e.g. to change widths of controls
- We add new record items for Yes/No boolean checkbox controls
- We create a couple of picklists for selecting values from a list.
- When we were finished we adding the section to the main form.
- After one bug fix we finally ended up showing (26 mins 45 seconds into the video) opening a patients forms, viewing the orders, clicking to modify and review the order - which opened our new dermatology assessment form.