We need to be clear on what we mean by ‘RM’ here. Colloquially, ‘RM’ in openEHR has meant ‘the information model’ (of the EHR and demographics). Now, we create models for everything we want to compute with, otherwise we get instances with no model, and that is not useful.
Hence, we also have the ‘AM’ - Archetype Model, that consists of ADL, the AOM (the actual model of archetypes), and a few other bits and pieces. We also had for a long time the notion of a ‘SM’, or Service Model - a formal model of services. We have only just started to defined that last part.
In more recent times it became clear that we needed to have a set of common models of elements that are re-used across the other models - basic things like primitive data types, identifiers, the notion of a ‘resource’ (a thing that has a lot of authoring and languages meta-data); also generic languages like ODIN, BMM, and so on. So we defined another component called ‘BASE’ to contain those things.
We also create components for
- Querying (‘QUERY’) - to contain models / languages of querying (so far, AQL)
- Process (‘PROC’) - to contain models of clinical process - so far, the Task Planning model
- Clinical decision support (‘CDS’) - to contain models of CDS elements
These components are illustrated on the specs governance page.
So, the kind of proposal we are discussing in this thread is whether it could make sense to try to formalise in an open, standard way, the definition of how data elements and groups are mapped to presentation data sets and groups, where the latter are understandable as e.g. logical visual components, document components, message components etc.
To do this, there could be a new openEHR model component that would contain a few classes, or maybe some language definition, or some other formal specification artefact, that would enable the data <=> presentation elements relationship to be expressed for any particular case, e.g. a screen form. It might be called ‘PRES’, for obvious reasons.
If it were done as a model, we might imagine some classes like DATA_SET, DATA_GROUP, and so on, as proposed in my first rough post. It could mean more classes and/or attributes, e.g. it might make sense to have an attribute DATA_GROUP.can_repeat, or TEXT_FIELD or whatever. Possibly elements that represent ‘selectors’ like menu items, tabs etc need classes as well, or maybe they can be specified by generic meta-data, e.g.
“presentation_characteristics”: [
“visible”: True;
“can_repeat”: True;
“etc”: “etc”;
]
and so on. If it is done like this, then there is another model somewhere else of the above structure - most likely outside of openEHR. On the other hand, it may be that all the externally defined models are concrete and product-specific, i.e. things like React, Angular, Node and so on, and underlying widget primitives. In that case maybe we want a more generic model of visualisation elements such as would be found in XUL, i.e. things like the following (from the XUL wikipedia page):
Top-level elements[window](https://en.wikipedia.org/wiki/Window_%28computing%29), page, [dialog](https://en.wikipedia.org/wiki/Dialog_box), [wizard](https://en.wikipedia.org/wiki/Wizard_%28software%29), etc.Widgetslabel, [button](https://en.wikipedia.org/wiki/Button_%28computing%29), [text box](https://en.wikipedia.org/wiki/Text_box), list box, [combo box](https://en.wikipedia.org/wiki/Combo_box), [radio button](https://en.wikipedia.org/wiki/Radio_button), [check box](https://en.wikipedia.org/wiki/Check_box), [tree](https://en.wikipedia.org/wiki/Tree_view), [menu](https://en.wikipedia.org/wiki/Menu_%28computing%29), [toolbar](https://en.wikipedia.org/wiki/Toolbar), group box, [tab box](https://en.wikipedia.org/wiki/Tab_%28GUI%29), colorpicker, spacer, splitter, etc.Box modelbox, grid, stack, deck, etc.Events and scriptsscript, command, key, broadcaster, observer, etc.Data sourcetemplate, rule, etc.
