Similar to others we customize the GUI in the form builder tool where
complex logic (hiding controls, looking up values, validation,
business logic etc) can be added. It would be a large (but noble)
effort to implement that in templates or even separate presentation
templates (my preference) for automation.
However my question is if we want true interoperability are we
expecting a completed form created in PatientOS to be edited in an
external openEHR system?
If we are, I can see issues if I determined a field to be a large
multiline text field (e.g. comments on this vitals form: http://www.patientos.org/forum_temp/vitals_form.png)) but the external
system created a short single text box. The net effect would be
visually truncated data - unless it is unreasonable to expect we can
swap and edit documents. Perhaps that is just an implementation
detail to be hacked out.
I agree that the form design needs to be stored outside the template, though there are times when you will want to set a value of a field in the template and not make it available for edit (or visible). An example is Review of Systems when you might set the symptom to a relevant symptom and have answers to other questions relating to the cough or swelling of ankles.
As far as the number of lines visible in a field is concerned, at this point data should only be edited in a strict form environment that was created using an identical template. In our EhrView component we do not use forms to display the data which gets around the issues you raise.
Generally it will be possible to resize form controls to show the text dynamically if required.
Interestingly, there are data concerns that have implications for the form, such as conditional data entry (say for women only). This will be expressed in the new Template Object Model.
