Yes, this is about two different problems 1. having extra RM structures tree be used to group RM data in different ways than the one defined for a composition, in order to use y as a data retrieval for APIs and GUI.
2. another level of definition, above OPTs, to specify GUI structures and attributes, and maybe bindings with specific GUI technologies. This doesn't affect current RM or change anything on the OPT model. On Feb 19, 2018 8:08 AM, "Thomas Beale" <thomas.be...@openehr.org> 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>: > >> 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 >> openEHRfirstname.lastname@example.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >> lists.openehr.org > > > > _______________________________________________ > openEHR-technical mailing > listopenEHRemail@example.com://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 > openEHRfirstname.lastname@example.org > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list openEHRemail@example.com http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org