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.
Bert
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:
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
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
