Encounter notes from a form

Often there is a need to have a custom complex form in Profile for collecting a large amount of information from checkboxes, drop downs, edit boxes, etc. and sometimes including a final edit box to summarize.  Some of this information would be important to putting into the encounter notes so the next clinician can review a summary and not have to click through to parsing a complex form.  Of course double entry is an option but frowned upon and rightfully so as we humans have horrible consistency to errorless duplication.

Intrahealth has made this task very simple to implement.  When saving your form the forms event OnMGetTextForContact gets triggered.  And in most cases that event macro can be a single line of code to get the expected behaviour.

An example:

Profile.Variable("TextForContact").Value = Controls_("memNotes").Text

This takes the text contents of a memo/text field and will instantly insert it into the Encounter the form was launched from.
No complex macro coding to hook the encounter editor or other complexities are needed.

It wouldn't be much more complex if you wanted multiple values from a form to be inserted into the notes.  You simply set the Value to a composed string from multiple controls values, like composing a paragraph of sentences into a single string.

That's it. Sweet simple, and powerful.


Form design in Profile 8.4.x

Building forms in Profile isn't necessarily a complex or complicated task but there are a bunch of steps that can make building forms tedious.  The general steps are to define the termset codes, design a visual form, add the termset codes to the form, then individually associate every code to a control on the form.  

A new and very welcome improvement is when designing a form from scratch some of the steps are combined saving a load of time and frustration. 

In our example we created a RUCS Form for Sexual Health with approx 35 coded fields.


Starting first with defining the fields in termset maintenance.

Second create a new form tied to the termset of the RUCS Form and get prompted by the collections list of fields in which the type of field can be defined.

This saves time from individually or even using drag and drop having to search for all the terms to go on a form as well as defining the data type behind the coded terms.

The next step is to start visually designing the form by dropping controls onto the page.  This is where another huge time-saver could be done but unfortunately it doesn't exist (yet).  If only you could now drag the coded field onto the page and the appropriate control type is created and linked to the coded term.  Maybe we will see this in the future.

After dropping a control onto the page and setting any properties needed the HRI must be defined by choosing the coded term to link the control to.  When this is performed the name of the control automatically updates to a human readable string.  This is a good practice to name all your controls both for clarity and in the case you want to add macro code it will be much easier to find the control by its name with proper naming.

So this might not seem like a huge improvement but rather it eliminates many many clicks which will add up quickly with forms containing a high amount of fields.

I hope to see more improvements like this in the near future.

If you have any suggestions on improvements let me know in the comments.