It can be that Compositions appear in a single GUI-form (in GP applications this happens regularly), but there is still no need to to show them from a single template. That can be up to the GUI-designer, he can use HTML-features to handle one or more entries in a single GUI-view. Having the entries offered to the GUI-developer separated from the composition offers all the flexibility the GUI-developer needs.

He can show a complete composition by connecting GUI-blocks on client-level, he can show history-lists of medications or observations without composition context, what ever is desired.


On 19-02-18 12:07, Thomas Beale wrote:

note that a key problem I want to address is that templates based on COMPOSITIONs don't really make sense as models of data retrieval/display forms - they are really only useful for data capture forms (or messages, or documents), because COMPOSITION is a container for committing data to the EHR.

Displaying data is a different question - it may be EHR data, it may be demographic data, and it may be something else entirely. So the data items we want to mention in templates are mostly of ENTRY level, and will be the results of queries; the relevant queries could be included in such templates.

So the starting point for many forms won't be a COMPOSITION - it is instead a different logical container that groups data that result from one or more queries, into a 'use group', i.e the group of data items intended to be visualised or used as a report etc.

One problem today is that people trying to define screens for visual applications are forced (more or less) to create templates starting with COMPOSITIONs, which is incorrect; my impression is that such templates are only used for data capture and that other display forms are modelled in various non-standard ways, or not at all.

I think annotations (based on paths) will be useful, but I not completely adequate to achieved what is needed.

- thomas

On 19/02/2018 07:49, Erik Sundvall wrote:

I agree that in many use-cases it is better to have a separate template intended for GUI/application hints overlayed on a "normal" data content definition template. (Quick experimentation may be an exception.)

That is why I added "layers of templates" in my previous comment - sorry for not explaining in detail. So a GUI-hint-annotated template based on another "normal" content aggregation/constraint-focused template would be a way to do it. I guess the effect in a resulting operational template (OPT) is essentially the same no matter how many layers of templates you choose to work with, right? So a form/GUI-renderer based on OPTs does not care how you layer the design, but your maintenance headaches might be affected if not separating things at design time.

I agree with Diego and Bert and suggest starting experimenting in the AM end (for example using annotations with GUI-hints in templates) and see how far that takes us, before possibly considering extending the RM (or whatever *M).

Annotations do not require any changes to AM or RM, the mechanism is already defined in the specifications. Conventions regarding patterns or prefixes in annotation keys and/or annotation values will likely give enough to start with.

A (not so very thought through yet) possible example of annotation use for application building is available in picture 40 (and supported by picture 36 in


mån 19 feb. 2018 kl. 10:22 skrev Bert Verhees < <>>:

    On 18-02-18 23:09, GF wrote:
    > Is it an idea to annotate nodes with instructions for display.

    Personally I think having special templates/archetypes for display is
    better. Templates are create per purpose, and mixing purposes in a
    single template does  seem good idea to me

    openEHR-technical mailing list

openEHR-technical mailing list

Thomas Beale
Principal, Ars Semantica <>
Consultant, ABD Team, Intermountain Healthcare <> Management Board, Specifications Program Lead, openEHR Foundation <> Chartered IT Professional Fellow, BCS, British Computer Society <> Health IT blog <> | Culture blog <>

openEHR-technical mailing list

openEHR-technical mailing list

Reply via email to