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:
Hi!
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
https://drive.google.com/file/d/1kxXeJMe0ltfLlchGA0Lm8mfOD-PQDLFy/view?usp=sharing
//Erik
mån 19 feb. 2018 kl. 10:22 skrev Bert Verhees <bert.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl>>:
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@lists.openehr.org
<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Team, Intermountain Healthcare
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org