These rules/assertions are things we can express with the AM right now, right? :D
El 20 feb. 2018 5:37 p. m., "Thomas Beale" <thomas.be...@openehr.org> escribió: > > On 19/02/2018 10:47, Pablo Pazos wrote: > >> IMO annotating templates with UI info is not a good idea. A layered >> approach is much cleaner and scalable, i.e. to define a new artifact on top >> of current templates / archetypes / RM (these are also examples of layered >> design). >> > > here, 'templates' means pure data templates, i.e. pure RM or other data > constructs, e.g. PROC (Task Planning) or CDS etc. > > >> Under this approach, if we have UITemplates on top of openEHR Templates, >> when we generate Operational UITemplates, that will contain UI + structure >> (template and archetype constraints) + RM references. This would be the >> final element to be used to feed software. but the underlying models are >> all separated and have a specific responsibility. >> > > So what I am proposing is what you are calling UITemplates (one could also > think of DOCTemplates and MSGTemplates) - they are openEHR templates, as in > being ADL/AOM artefacts, but based on a model of UI/presentation primitives > that enables RM and other data elements to be embedded. > > >> If we go ahead, we can add another level for workflow, defining an order >> and conditions under which each "screen" should be displayed, like a >> WFTemplate, having an Operational WFTemplate that will include all WF + GUI >> + structure + RM references. >> > > I think this can make sense as either another model layer, or maybe better > as specific annotations that use FOPL-like or rule statements to define > work flow, e.g. > > when /data/path1/value = "coded" then display (/ui/path5) > > where /data/path1 is an archetype path of the kind we are used to, > pointing to some DV_TEXT element and /ui/path5 is a path through the UI > template that points to a sub-form, presumably one that knows how to ask > for a coded text. > > If we separate out screen workflow from screen logical layout, then we can > re-use the latter with different workflows, reprocess it into a PDF or > other document structure and so on. > > >> We can continue adding layers :) >> > > exactly right. > > - thomas > > _______________________________________________ > 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
