Hi @erik.sundvall we have discussed this in many occasions, here and in Slack.
Because of the many disadvantages of mixing GUI stuff into a template, my opinion was always to avoid this at all costs.
-
Separation of concerns: visual hints, GUI commands / operators / definitions, etc. are not in the scope of the template, it’s purpose is to specify a data set by constraints, not to define how form fields or data in a screen should be displayed. There is no concept of form, field or data visualization in the template model / AOM, and shouldn’t be added.
-
Adding those GUI elements to the template are conceptually patches to comply with certain system requirements, that should be satisfied by other metadata constructs, not by templates.
-
Opening the door for some GUI hints allows to open the door for many other hints and extra requirements that are not in the current scope/purpose of a template.
-
Limiting the scope of templates just for “defining data sets by constraints” from the start allows these extra GUI requirements to be satisfied elsewhere. For instance, it enables the construction of another model, specific for GUI stuff. I worked on this area before and shared the initial model we reached with the SEC some time ago.
-
Having another model just for GUI stuff, allows to follow the inherent layered architecture openEHR currently has: RM < AOM < TOM < GUI Templates. I have also proposed other layers for that semantic “sandwich”, for instance the CDS rules is another layer, the “data mappings” (to map openEHR data from/to other standards/models/messages) could also be another layer, a “process spec” could be another layer, etc. etc. So instead of adding elements that belong to a different semantic level to the templates, we create a new semantic layer for those, including: expression language, model, tools. This is just the openEHR approach for everything.
This is the spec I was writing some time ago:
User Interface Templates for the openEHR specifications stack - 20200922.pdf (471.5 KB)
That is basically a model that maps items from the template into GUI elements/controls/widgets, and allows to bind data back to the openEHR template for data validation and storage.
So IMHO it is better to the whole architecture to extract those hints into a different layer than actually standardizing those to be part of the AOM.