# Templates for application form development **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2018-02-17 19:06 UTC **Views:** 5 **Replies:** 54 **URL:** https://discourse.openehr.org/t/templates-for-application-form-development/15509 --- ## Post #1 by @system I've been recently messing around with ADL-designer, and thinking more about how to do application building with templates. A few things are becoming clearer to me. Firstly, templates based on COMPOSITION (or PARTY, PERSON etc, for demographics) are potentially good for data capture, but don't in general make sense for data retrieval. For a retrieval data set, e.g. a screen containing a combination of demographics, EHR clinical, other info, we need another kind of container. Let's call this DATA_SET for the moment, and assume it is defined as follows: `class DATA_SET inherit LOCATABLE` `content: LOCATABLE [*]` `end` Then an archetype of this could be built for a screen, and it could insert SECTIONS purely for display purposes. Maybe it could include style information. So let's imagine that instead of just SECTIONs we could use something a bit smarter, like DATA_GROUP. We could then create a template like the following (each included archetype is actually an overlay based on an underlying archetype): `DATA_SET[id1] matches {` `content matches {` `DATA_GROUP[id2] matches {` `name matches {[at20]} -- "Patient details"` `style matches {1} -- area; from an enumeration of tabs|menu|area|etc` `items matches {` `use_archetype PERSON[id3, openEHR-EHR-PERSON.ovl_patient_details_1.v1]` `}` `}` `DATA_GROUP[id4] matches {` `name matches {[at21]} -- "Clinical"` `style matches {1} -- area; from an enumeration of tabs|menu|area|etc` `items matches {` `DATA_GROUP[id6] matches {` `name matches {[at22]} -- "First trimester"` `style matches {0} -- tabs` `items matches {` `use_archetype OBSERVATION [id7, openEHR-EHR-OBERVATION.ovl_first_trimester_summary_1.v1]` `}` `}` `DATA_GROUP[id8] matches {` `name matches {[at23]} -- "Second trimester"` `style matches {0} -- tabs` `items matches {` `use_archetype OBSERVATION [id9, openEHR-EHR-OBERVATION.ovl_second_trimester_summary_1.v1]` `}` `}` `DATA_GROUP[id10] matches {` `name matches {[at24]} -- "Third trimester, first part"` `style matches {0} -- tabs` `items matches {` `use_archetype OBSERVATION [id11, openEHR-EHR-OBERVATION.ovl_third_trimester_summary_1.v1] -- overlay 1` `}` `}` `DATA_GROUP[id12] matches {` `name matches {[at25]} -- "Third trimester, last month"` `style matches {0} -- tabs` `items matches {` `use_archetype OBSERVATION [id13, openEHR-EHR-OBERVATION.ovl_first_trimester_summary_2.v1] -- overlay 2` `}` `}` `}` `}` `}` `}` `` Notice that now we have demographic data (magenta) and EHR data (blue) easily mixed in; we have a rough screen layout defined, something like two HBOX areas, with the second one having tabs inside for the various pregnancy trimesters. In this construction, the only real data are the included archetypes; the outer DATA_SET and DATA_GROUPs are just defined structures that are created on the fly by a screen renderer. Different types of DATA_GROUP could be used to provide the UI hints we often talk about - use tabs, use a box with a name, and so on - people familiar with the typical UI elements like HBOX, VBOX, TREE, MENU, MENU_ITEM, DATE_FIELD, TEXT_FIELD (the names differ across UI toolkits) will see that this approach could be used to more or less fully define whole screens. A similar thing could be done to define messages or documents. Paths through such a structure would effectively be paths to parts of a form (or a message), and could be referenced in other sections of the template to control visualisation. We could embed the generating queries as well for example: `DATA_SET[id1] matches {` `content matches {` `DATA_GROUP[id2] matches {` `name matches {[at20]} -- first trimester` `query matches {` `**"SELECT obs**` `**FROM**` `**EHR[$ehr_id] CONTAINS**` `**summary** **COMPOSITION[openEHR-EHR-COMPOSITION.pregnancy_summary.v1]**` `**WHERE**` `**summary/context/start_dat****e** **>** ```**$current_date -** `P1Y` `**"**` `}` `style matches {0} -- tabs; from an enumeration of tabs|menu|etc` `items matches {` `use_archetype OBSERVATION [id3, openEHR-EHR-OBERVATION.ovl_first_trimester_summary_1.v1]` `}` `}` `etc` `}` `}` Doing the above requires adding some new classes to the RM, or a Presentation Model part of openEHR. It seems to me it would make application software development much easier, and substantially more automatable. I am aware that other people with far more app/UI experience than I have worked intensively on specifying UI forms, application elements and so on, and have some very smart tools for such purposes. I am therefore not really claiming anything new here, just considering ways to formalise such ideas in a way that would make use of existing tools and formalisms that we have. thoughts? - thomas --- ## Post #2 by @system If it was to me to design, I would not change the RM. In fact, I think the RM has already classes which do not belong there in my opinion. I think of AuthoredResources, TranslationDetails, they belong in the AOM. The RM should not be a myriad of classes used left/right in the OpenEhr system. We should leave the idea of OpenEhr being a single system. It is an anti-pattern in the microservices paradigm. Too many dependencies, too much code replication, the monolithic kernel paradigm should be left. So I favour an AOM with no shared dependencies with the EHR RM. The same idea for the Form classes. Have an own class system with no dependencies outside the system. But the idea of a Form RM / template I think is very good, and can be a great help for software designers when tooling supports it. I will study the specs tomorrow, this was what came to mind when I saw your post Best regards Bert --- ## Post #3 by @system these things are generic and are in the , allowing them to be re-used where needed. (They were in the AOM but are needed outside of there). - thomas --- ## Post #4 by @system I know Thomas, but they have dependencies to other classes in the RM. To data types, to support. By the way, I have never seen use for translation details except for the archetype metadata. But maybe i missed it. That is possible, if so, excuse me for this example. The terminology service also has dependencies to rm data types, only because of codephrase. Wouldn't it be possible to avoid that? This also creates a circular dependency at construction of several RM classes. They need the OpenEhr terminology when constructed, and the terminology needs the RM codephrase. The archetype_Id is inherited from object_id, but why is that necessary? What is the advantage? Of course it is not only design, it is also the developers, they create those large libraries, but they are inspired by the theoretical architecture-plan, and maybe they need to do that to avoid circular library references. There is, in my opinion a need to split the RM. Rongs did that a few years ago, he had an Ehr-RM and a (was it...) common RM. A step in a good direction. So splitting up the RM instead of making it larger would be my idea. The first is not easy to do, but the second is, and helps us avoiding further problems and avoiding creating unnecessary large libraries. Bert --- ## Post #5 by @system I think SET has a lot of applications, including result sets. Of course that should interior from LOCATABLE to be archetypable. I'm not sure on the types associated with the UI. I have a specification for UITenplates that includes some of that, I can share it :) I'm interested in moving this idea forward. Please let me know how I can help. --- ## Post #6 by @system Sorry for moving away from the original subject. It was old annoyance coming up when thinking about some RM issues. Maybe when having a strict separation between the common and some other parts the problems I mentioned partly disappear. Anyway, it is not yet the moment to discuss such details in the first announcement of a good plan. Best regards Bert --- ## Post #7 by @system I think any existing UI/template specification / app modelling would be useful to share \- possibly on the wiki \- let me know if you need a page there\. My aim would be to get closer to an IDE application building tool for clinical people to at least build a POC application that works, something like Balsamiq but with real data connections built in\. Marand's EhrExplorer does some of this, and it would also be useful to extract some of the semantics of that tool into a standard specification to support this kind of thing\. \- thomas --- ## Post #8 by @system This is an Interesting topic! Standardised methods for representing application GUI behaviour/appearance in an open vendor neutral way is one of the few still missing pieces in the openEHR ecosystem needed in order to avoid vendor lock in. Some clever choise of split point is likely fruitful since some parts are closer to openEHR data/query definitions and some will be closer to GUI-implementation/visualisation/layout frameworks (like Angular etc) that should likely not be reinvented by openEHR but that (sometimes at an annoying speed) keep changing versions and popularity faster than the RM/AM/AQL related data definition framework should... When designing this, perhaps some (2-5) existing currently popular GUI frameworks could be initial targets for output from the process, and the selection could be updated over time. Perhaps for example [https://angular.io/](https://angular.io/) and [https://reactjs.org/](https://reactjs.org/) are two starting candidates for experimentation? (Both have partially declarative design, but other suggestions are of course welcome) Then mechanisms in those platforms could be reused rather than reinvented. Also looking at the things done in the format used/shared by Marand and DIPS is an interesting input for gathering requirements. //Erik Sundvall sön 18 feb. 2018 kl. 11:51 skrev Thomas Beale <[thomas.beale@openehr.org](mailto:thomas.beale@openehr.org)>: --- ## Post #9 by @system > When designing this, perhaps some (2-5) existing currently popular GUI frameworks could be initial targets for output from the process, and the selection could be updated over time. Perhaps for example [https://angular.io/](https://angular.io/) and [https://reactjs.org/](https://reactjs.org/) are two starting candidates for experimentation? (Both have partially declarative design, but other suggestions are of course welcome) Then mechanisms in those platforms could be reused rather than reinvented. yes - this is the sort of thing I have in mind. The tool would function as follows: - represent UI forms and ?other UI behaviours (some screen workflow) as archetypes+templates of classes that generically represent such things - use one or a set of templates to represent an application - generate the OPTs of these templates, as ADL2 or JSON, YAML, whatever is convenient - perform OPT => GUI transform, injecting some UI styling profile info, to get directly consumable artefacts for the UI framework. experts on the UI side will be able to help refine the details of this. THe 'smart split' of data / UI semantics will be the key to making this workable. - thomas --- ## Post #10 by @system I think I must have been run out of credit, since my emails yesterday. But still I take my chance. I must warn, Angular is a very complex environment, with much more functionality then just showing GUI's. I am afraid you load a lot of complexity which will not pay out. By the way, I thought that Marand still uses AngularJS, I don't know how I got this information, but check it before deciding for it. AngularJS which is the previous version, and is in fact not further developed and not maintained. This for generating Angular code or ReactJS code (which is even more complex because it is a whole different paradigm) There are many disadvantages of using a complex framework. The disadvantage of using Angular or React is that it is not something that works with easy generated code, except when you want to impose the use of Angular to the OpenEhr developers, which will become contradictory with the word "Open". I think it is best to offer the developer as much freedom as necessary, it makes the effort to create this also longer usable and ask for less maintenance. Therefor I wouldn't go the way of an existing framework anyway, it is much easier to generate javascript (as simple as possible) and GUI identifiers together with the necessary REST-calls The generated javascript can be quite simple, a GUI-control, an identifier to read the content, and a REST-call which uses the content to do its thing. When developers want, they an copy and paste the generated javascript into their web-framework in order to maintain the own graphical layout and application functionality around the generated code. Integration will become much easier. You could optionally make it more complex (as a second step goal) and still work for the simple copy/past situation. This complexity could be in validating datasets in the browser by Javascript/Typescript, so there will be only network activity when the dataset is validated and OK. That would really do the user-experience good, especially on mobile devices. But this second step could be a later target, first having the simple javascripts generated and the REST calls generated would be a good target to start with. Best regards Bert --- ## Post #11 by @system > > Best regards > Bert And sorry for the sloppy English \(when reading back\), on Sundays it is worse then on weekdays when I am in working mode\. But I think my message is still understandable, so, have a nice Sunday\-evening\. ;\-\) Bert --- ## Post #12 by @system I have a pdf spec in Spanish, this was a university project to have platform independent GUI definitions based on opts, while creating technology specific GUI generators for data entry and display. I mentioned this a while ago on the lists but catched not much attention. Need to do a little translation work :) --- ## Post #13 by @yampeku --- ## Post #14 by @yampeku Wops, pressed send button too early. We have experimented with lforms and conversions from archetypes are really straightforward --- ## Post #15 by @system Is it an idea to annotate nodes with instructions for display. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #16 by @system I've created a [new wiki page here on this topic](https://openehr.atlassian.net/wiki/spaces/spec/pages/175276035/Application+Data-sets), with the original post contents as background. If others would like to share existing methods or ideas for formalisation of visual or other data sets, I suggest to make a sub-page, and then put a link and short summary description at the bottom of the page I have created. - thomas --- ## Post #17 by @system sön 18 feb. 2018 kl. 23:10 skrev GF <[gfrer@luna.nl](mailto:gfrer@luna.nl)>: > Is it an idea to annotate nodes with instructions for display. Yes, using (mostly shared/standardised) annotations for GUI-rendering hints in templates (or layers of templates) has been a major idea in previous GUI-related discussions in openEHR mailing lists. //Erik (We should link to some old list posts on the topic in that wiki page Tom created) --- ## Post #18 by @system 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 --- ## Post #19 by @yampeku Personally I would prefer if no visualization attributes ended up in the EHR RM, but I'm fine if we want to create an additional RM to handle visualization (and we create templates of that model that point to the EHR model) --- ## Post #20 by @system I agree on this! (again sloppy English in my previous message, this time changing the meaning, I changed the quote below, I am awake now, will not happen again, excuse me) --- ## Post #21 by @system 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](https://drive.google.com/file/d/1kxXeJMe0ltfLlchGA0Lm8mfOD-PQDLFy/view?usp=sharing) //Erik mån 19 feb. 2018 kl. 10:22 skrev Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl)>: --- ## Post #22 by @system 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 --- ## Post #23 by @system 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 --- ## Post #24 by @system 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. --- ## Post #25 by @system Is there a terminology with concepts we can use to annotate? Probably there is and there are more. Which one, will be the question. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #26 by @system 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). 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. 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. We can continue adding layers :) --- ## Post #27 by @system We also have a Final Degree Project where a student made a proposal for a Visual Template Model. It's from 2012, for ISO 13606, and also in Spanish, but the main idea probably remains the same :-) I've been always in favor of having a third layer for visualization purposes that defines some of the expected behaviors and the visual aspect. As Erik said, this is not about reinventing what the existing UI frameworks can do, but to have a way of instructing them on how to show the information on screen. --- ## Post #28 by @system Often Spanish is not always a big problem, let us try drag through Google translate to make it al readable Bert --- ## Post #29 by @system I was reviewing that work, and I found it cited this reference. This is an old topic... H. van der Linden, T. Austin, J. Talmon, Generic screen representations for future-proof systems, is it possible? There is more to a GUI than meets the eye, Comput Methods Programs Biomed. 95 (2009) 213–226. doi:10.1016/j.cmpb.2009.03.003. --- ## Post #30 by @system In fact David, the work is about how an interface should look like, that is interesting for GUI designers. But the discussion here is not about GUI design but about offering a technical environment to GUI designers. Bert --- ## Post #31 by @Jussara_Macedo_Rotz1 Could we have access to that Pablo? Regards Jussara Rotzsch --- ## Post #32 by @system Hi, There is NO need for an other RM. Templates (imo) describe an interface. Templates for an interface used for display only need annotations in the appropriate nodes of the Display Archetype Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #33 by @system Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands > > 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. Or any interface be it for committing, querying, display, data entry, documents, messages, clinical decision support interactions? These all can be dedicated kinds of Template/Interface > 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. Unless the COMPOSITION is the description of any interface. > 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. Why? --- ## Post #34 by @system We need to be clear on what we mean by 'RM' here. Colloquially, 'RM' in openEHR has meant 'the information model' (of the EHR and demographics). Now, we create models for everything we want to compute with, otherwise we get instances with no model, and that is not useful. Hence, we also have the 'AM' - Archetype Model, that consists of ADL, the AOM (the actual model of archetypes), and a few other bits and pieces. We also had for a long time the notion of a 'SM', or Service Model - a formal model of services. We have only just started to defined that last part. In more recent times it became clear that we needed to have a set of common models of elements that are re-used across the other models - basic things like primitive data types, identifiers, the notion of a 'resource' (a thing that has a lot of authoring and languages meta-data); also generic languages like ODIN, BMM, and so on. So we defined another component called 'BASE' to contain those things. We also create components for - Querying ('QUERY') - to contain models / languages of querying (so far, AQL) - Process ('PROC') - to contain models of clinical process - so far, the Task Planning model - Clinical decision support ('CDS') - to contain models of CDS elements These components are [illustrated on the specs governance page](https://www.openehr.org/programs/specification/governance). So, the kind of proposal we are discussing in this thread is whether it could make sense to try to formalise in an open, standard way, the definition of how data elements and groups are mapped to presentation data sets and groups, where the latter are understandable as e.g. logical visual components, document components, message components etc. To do this, there could be a new openEHR model component that would contain a few classes, or maybe some language definition, or some other formal specification artefact, that would enable the data <=> presentation elements relationship to be expressed for any particular case, e.g. a screen form. It might be called 'PRES', for obvious reasons. If it were done as a model, we might imagine some classes like DATA_SET, DATA_GROUP, and so on, as proposed in my first rough post. It could mean more classes and/or attributes, e.g. it might make sense to have an attribute DATA_GROUP.can_repeat, or TEXT_FIELD or whatever. Possibly elements that represent 'selectors' like menu items, tabs etc need classes as well, or maybe they can be specified by generic meta-data, e.g. "presentation_characteristics": [ "visible": True; "can_repeat": True; "etc": "etc"; ] and so on. If it is done like this, then there is another model somewhere else of the above structure - most likely outside of openEHR. On the other hand, it may be that all the externally defined models are concrete and product-specific, i.e. things like React, Angular, Node and so on, and underlying widget primitives. In that case maybe we want a more generic model of visualisation elements such as would be found in XUL, i.e. things like the following (from the [XUL wikipedia page](https://en.wikipedia.org/wiki/XUL)):
Top-level elements
[window](https://en.wikipedia.org/wiki/Window_%28computing%29), page, [dialog](https://en.wikipedia.org/wiki/Dialog_box), [wizard](https://en.wikipedia.org/wiki/Wizard_%28software%29), etc.
Widgets
label, [button](https://en.wikipedia.org/wiki/Button_%28computing%29), [text box](https://en.wikipedia.org/wiki/Text_box), list box, [combo box](https://en.wikipedia.org/wiki/Combo_box), [radio button](https://en.wikipedia.org/wiki/Radio_button), [check box](https://en.wikipedia.org/wiki/Check_box), [tree](https://en.wikipedia.org/wiki/Tree_view), [menu](https://en.wikipedia.org/wiki/Menu_%28computing%29), [toolbar](https://en.wikipedia.org/wiki/Toolbar), group box, [tab box](https://en.wikipedia.org/wiki/Tab_%28GUI%29), colorpicker, spacer, splitter, etc.
Box model
box, grid, stack, deck, etc.
Events and scripts
script, command, key, broadcaster, observer, etc.
Data source
template, rule, etc.
--- ## Post #35 by @system Hi Thomas, good clarification, although too much in detail at some points in this moment of thinking about it\. I see it as more simple, 1\) about the classes, it would be nice, in my opinion, if they can stand alone, without needing other RM\-classes\. I think this will makes life easier in the future\. 2\) about XUL, the workout is very usable, and it defines, as I read, in a standardized way GUI\-components\. I don't know if XUL also offers ways to constraint the input in the components, if not, then that is a shortcoming\. We need to solve that\. It will be so good for the user experience if validation of component content can be validated client\-side\. 3\) The targetting to frameworks \(like Angular or \(stupid simple\) javascript\), I think that is something for the community to write, we do not need a standard for that\. As contribution to the community I \(or some else\) could write a tool to generate very simple javascripts which instantiate the GUI\-elements, activate the constraints for them, and gather the validated contents of them to the REST\-calls, or in case of displaying data, retrieve them from the REST calls and spread them over the components\. Such simple scripts could be used in almost any framework by just adding the URL of that script to the target \(maybe Angular, simple HTML or any other framework\.\) Also important is that the Javascripts do not contain CSS, so that styling will be imposed by the container which links the script\. This makes it usable in all platforms without any target defined in the presentation\-archetype\. Visually testing those Javascripts is very easy\. There is no need to define datasources, because the REST calls handle that, even for AQL this could be possible to work that way\. In fact, it is how 99% of the Javascripts\-frameworks do their job\. Bert --- ## Post #36 by @system > 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 --- ## Post #37 by @yampeku These rules/assertions are things we can express with the AM right now, right? :D --- ## Post #38 by @system Let me look for it, haveit on a backup disk somewhere :) --- ## Post #39 by @system Templates have no information about user interfaces, are mainly full document data structures + semantic definitions + constraints + terminology (local and bindings). User interface information includes layout, form composition, position, size, style, etc. Clearly this is not included in current openEHR templates. BTW all those elements are part of the UITemplate model that I mentioned before. Will try to have an english translation to share next week. --- ## Post #40 by @system We're still [working on this somewhat](https://www.openehr.org/releases/BASE/latest/docs/expression/expression.html), using Task Planning as the excuse to finally get it right.... --- ## Post #41 by @system that should not be the case - that's exactly what we are avoiding. If we missed something it is an error. But note - most of the RM 'Support IM' model moved to BASE. We think it will get used for Task Plans, and maybe GDL guides. Yes, there is a new class TERMINOLOGY_CODE that is used in BASE instead of CODE_PHRASE; eventually, the RM should just use that. If you found any use of CODE_PHRASE in BASE, please let us know. Not much admittedly, since OBJECT_ID is just an identifier with a concrete String representation, but it does mean that an OBJECT_REF can point to any kind of OBJECT_ID, including an ARCHETYPE_ID. yes, as I say, there should be absolutely none of these. Any you see need to be reported. We are not intending to make the RM any larger, not sure why you think we are. - thomas --- ## Post #42 by @system I must have missed new developments, I am still working with RM 1\.0\.3 which, I was thinking, is the production version My remarks were for that version, and for my idea, there were some inconveniences in it\. But I will study the new RM, and if I find some similar inconveniences, I report them\. This is a bit another subject, but I explain it anyway, because last weekend, I was not satisfied about my emails Please let me explain why it is an important problem to me\. Maven \(Java dependency tool\) gets grumpy about circular library references, and the Golang compiler does accept circular package references and restricts using circular struct references\. C\+\+ does not accept circular class references, but can be worked around in a tricky way\. Circular references The Dependency Rule says that source code dependencies can only point inwards\. Nothing in an inner circle can know anything at all about something in an outer circle\. In particular, the name of something declared in an outer circle must not be mentioned by the code in an inner circle\. That includes, functions, classes\. variables, or any other named software entity\. As you move inwards the level of abstraction increases\. The outermost circle is low level concrete detail\. As you move inwards the software grows more abstract, and encapsulates higher level policies\. Robert C Martin\. Terminologyservice needs codephrase, and codeprase is part of the datatypes, dvtext \(also datatype\) needs terminologyservice \(in constructor\)\. \(circular reference\) Other datatypes, for example, dvtext also need a ready compiled terminologyservice and codephrase for checking the charset and language in the constructor This situation makes it impossible to separate the terminologyservice from the datatypes, although they have no similar abstraction level In OpenEhr this is solved by using an interface of terminologyService inside the support\-part, and that would be a good solution if the interface did not have the codephrase also in its declarations\. So it did not solve it the violation of the dependency rule, but it makes it compilable\. So it is a problem, and causes dirty code to solve\. The solution is simple\. Make CodePhrase a part of TerminologyService and remove it from datatypes\. Then all classes which need code\-phrase have to link in terminologyservice, but terminology can be compiled independently from other classes The most inner circle of the dependencies should be a group libraries/classes which do not need each other by the route of an outer circle\. The most inner group should be AOM, TerminologyService, EHR\-RM, around that should be the Support, and around that should be the datatypes\. Then there would be no problem, the datatypes can be linked against every library and will never cause a circular reference\. Best regards Bert --- ## Post #43 by @system My problem description was good, the solution, is not really good. In fact the metaphore of circles does not work completely in openehr. I believe it is the other way around. All higher level classes may use the datatypes, but datatypes may not use the higher level classes. So datatypes must be the most inner circle so that all classes around can use datatypes. This also has an inconvenience because of dvtext which has that dependency to higher level terminology. So what do we do with on terminology depending datatypes? Make them part of the terminology related software of which terminology service also will become a part? Or do we remove codephrase from terminology service so that terminology service can be an inner circle of datatypes? So codephrase will then be in the datatypes, and terminologyid should not be inherited from object_id which else causes a conflict with support, so terminologyId would be a part of terminology service. Or support should be the inner most circle, then terminology and then datatypes? Bert --- ## Post #44 by @system > > So splitting up the RM instead of making it larger would be my idea. The first is not easy to do, but the second is, and helps us avoiding further problems and avoiding creating unnecessary large libraries. > > We are not intending to make the RM any larger, not sure why you think we are. In your first message about this proposal was something that made me think you were about to enlarge the RM and also to have all in a large pile of classes. I quote: "Doing the above requires adding some new classes to the RM, or a Presentation Model part of openEHR." I think you changed your mind now, so that is not important. Bert --- ## Post #45 by @system I wrote this afternoon, and I see that it is not sufficient. It could work for archetypes, because the have clear and simple identifiers which could be used to connect the generated component-values and parameter-naming inside the generated rest-calls inside the javascripts, but it would not work in representing query results. So I came to another idea One could also create path-values in JSON, in that way there would be only very simple rest calls necessary with only a few, or maybe one parameter in the rest-calls, the JSON-structure and maybe one or two more which I have not thought of yet. In this way, every archetype datavalue-set can be represented, and also every query result. And the rest as described below remains in that case about the same. But I am sure there are very good ideas of others, so I wait sometime to get a point of what is generally agreed about. Best regards Bert --- ## Post #46 by @system I didn't change my mind, I was just not precise when I said that ;) - t --- ## Post #47 by @system Jussara, Here is a copy of the paper we presented on INFOLAC 2014 [https://www.slideshare.net/pablitox/generacin-automtica-de-interfaces-de-usuario-para-sistemas-de-informacin-clnicos-basados-en-una-metodologa-multinivel](https://www.slideshare.net/pablitox/generacin-automtica-de-interfaces-de-usuario-para-sistemas-de-informacin-clnicos-basados-en-una-metodologa-multinivel) The presentation [http://www.sueiidiss.org/images/archivos2015/temasinfolac/22.pdf](http://www.sueiidiss.org/images/archivos2015/temasinfolac/22.pdf) That paper is referenced from my MEDINFO 2015 paper [https://books.google.com.uy/books?id=OmZrCgAAQBAJ&pg=PA49&lpg=PA49&dq=Generaci%C3%B3n+autom%C3%A1tica+de+interfaces+de+usuario+para+sistemas+de+informaci%C3%B3n+cl%C3%ADnicos+basados+en+la+metodolog%C3%ADa+multinivel&source=bl&ots=GAd8sfgJuz&sig=UK5rAgO1xrSUEnrUPpWPxDdSJ-E&hl=en&sa=X&ved=0ahUKEwjh_vPPoLbZAhWimeAKHaexDkoQ6AEIMDAB#v=onepage&q=Generaci%C3%B3n%20autom%C3%A1tica%20de%20interfaces%20de%20usuario%20para%20sistemas%20de%20informaci%C3%B3n%20cl%C3%ADnicos%20basados%20en%20la%20metodolog%C3%ADa%20multinivel&f=false](https://books.google.com.uy/books?id=OmZrCgAAQBAJ&pg=PA49&lpg=PA49&dq=Generaci%C3%B3n+autom%C3%A1tica+de+interfaces+de+usuario+para+sistemas+de+informaci%C3%B3n+cl%C3%ADnicos+basados+en+la+metodolog%C3%ADa+multinivel&source=bl&ots=GAd8sfgJuz&sig=UK5rAgO1xrSUEnrUPpWPxDdSJ-E&hl=en&sa=X&ved=0ahUKEwjh_vPPoLbZAhWimeAKHaexDkoQ6AEIMDAB#v=onepage&q=Generaci%C3%B3n%20autom%C3%A1tica%20de%20interfaces%20de%20usuario%20para%20sistemas%20de%20informaci%C3%B3n%20cl%C3%ADnicos%20basados%20en%20la%20metodolog%C3%ADa%20multinivel&f=false) All are also here [http://independent.academia.edu/pablopazos](http://independent.academia.edu/pablopazos) Since then, I have updated the UITemplate model to use OPTs instead of archetypes directly, added improvements and features that are not in the initial model from the paper. The new model still needs work, but we proven we can use it as an abstract, generic, declarative openEHR UI definition focused on data entry and form-oriented visualization. And that technology specific UI generators can use it to output other declarative form UI specifications, that dev tools / IDEs can take in order to render UIs. E.g. from an UITemplate instance in XML, different generators can generate XAML (.NET UI definitions), SwiXML (Java Swing UI definitions), XHTML/HTML5 (for web), and there are XML UI definitions also for Android and iOS that can be generated. Basically generators are XML mappers, and knowing the destination schema is really easy to create the maping rules between input UITemplates and X technology UI definition. A second level, of definition is also missing, about the rules for data input, like "if field X has a value, show field Y". I don't think we need to specify mandatory or cardinality constraints on the UITemplate since the OPT already has those and the UITemplate should just define UI stuff that is not on the referenced OPT. I hope to have an updated & translated spec for next week. Best, Pablo. --- ## Post #48 by @system This is of course a good thing\. But now the question, how do I know which definition to use\. I always looked at this URL: http://www.openehr.org/programs/specification/workingbaseline There I found "Support", which brings me to: http://www.openehr.org/releases/RM/latest/docs/support/support.html In that, there is CODE\_PHRASE still used in TERMINOLOGY\_ACCESS\. Now I read that there is a new class in BASE, I found the link: http://www.openehr.org/releases/BASE/latest/docs/index And I found Terminology\_Code: http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_terminology_code_class Which is a real improvement, exactly what I was hoping for, it did not only remove the CODE\_PHRASE from datatypes, but also TERMINOLOGY\_ID class from SUPPORT It has a property/field which is named terminology\_id and is of type string Is this what is going to be the new standard? And when will this be like that? When looking further, I also see that there is still a TERMINOLOGY\_ID class in that document which is the old support terminology which is derived from OBJECT\_ID http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_terminology_id_class Is this confusing, or am I missing something stupid? Am I the only person asking this kind of questions? If yes, where do others get their information from? Please help me, because, I think, this is very important\. Thanks Bert --- ## Post #49 by @system >>> >>> The terminology service also has dependencies to rm data types, only because of codephrase\. Wouldn't it be possible to avoid that? >> >> Yes, there is a new class TERMINOLOGY\_CODE that is used in BASE instead of CODE\_PHRASE; eventually, the RM should just use that\. If you found any use of CODE\_PHRASE in BASE, please let us know\. > > This is of course a good thing\. > > But now the question, how do I know which definition to use\. > > I always looked at this URL: http://www.openehr.org/programs/specification/workingbaseline > > There I found "Support", which brings me to: > > http://www.openehr.org/releases/RM/latest/docs/support/support.html > > In that, there is CODE\_PHRASE still used in TERMINOLOGY\_ACCESS\. yes \- we are still working on this \- to find the cleanest way to separate it out without breaking current code\. > Now I read that there is a new class in BASE, I found the link: http://www.openehr.org/releases/BASE/latest/docs/index > > And I found Terminology\_Code: http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_terminology_code_class > > Which is a real improvement, exactly what I was hoping for, it did not only remove the CODE\_PHRASE from datatypes, but also TERMINOLOGY\_ID class from SUPPORT > > It has a property/field which is named terminology\_id and is of type string > > Is this what is going to be the new standard? > > And when will this be like that? Well it will be the new standard for BASE classes very soon\. Over time, we will start either replacing CODE\_PHRASE in the upper models with TERMINOLOGY\_CODE, or possibly adding some sort of mapping / conversion logic\. But we'll only do that based on input from implementers \- we need to find a way to update the models without breaking existing systems\. > When looking further, I also see that there is still a TERMINOLOGY\_ID class in that document which is the old support terminology which is derived from OBJECT\_ID > > http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_terminology_id_class > > Is this confusing, or am I missing something stupid? Am I the only person asking this kind of questions? If yes, where do others get their information from? > > Please help me, because, I think, this is very important\. you should consider the classes you see in BASE today as being what will be issued, unless anyone finds a problem with them\. In the near future, we will continue the cleanup around terminology\. One reason we have not cleaned it up yet is because noone in industry agrees on what standard or tools to use\. Noone faithfully implements CTS2 for example, except a non\-maintained server from Mayo \(LexGrid from memory\)\. IHTSDO did something different, and FHIR did something else\. All have good and bad points, but there has been no clear specification\. I am inclined to think that the specification of the future is a kind of stripped down CTS2 that gets rid of XML/XSD, and can be used with multiple serialisation formats, and cleaner models, but semantically, more or less the same\. But we have to be practical too\. Maybe the FHIR terminology service will evolve in the most appropriate way; they already have the same URI representation of terms as our BASE classes now have\. All input on this welcome, as usual\. \- thomas --- ## Post #50 by @system Well, this sounds very good, so I can forget my babble about dependency circles, concerning this part of the specs I hope this will be in stable release very soon, because I need to have a stable definition for a project Thanks Bert --- ## Post #51 by @system Hi all, I manage to translate / update part of the work we did some years ago in terms of UI definition and generation for the openEHR stack. Here is the doc, feedback is very welcome! [https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe-_T9H6UMsGNkiZoU7Iw/edit?usp=sharing](https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe-_T9H6UMsGNkiZoU7Iw/edit?usp=sharing) --- ## Post #52 by @system Pablo, Good work - I've included a reference to this doc in the [original wiki page](https://openehr.atlassian.net/wiki/spaces/spec/pages/175276035/Application+Data-sets), and added a few ideas about how to use it. It is very close to what I was thinking of. - thomas --- ## Post #53 by @system Thanks Thomas, I added a paragraph about the UI generation modes at the end, I forgot to mention that yesterday. --- ## Post #54 by @system Hi! I have also updated the [https://openehr.atlassian.net/wiki/spaces/spec/pages/175276035/Application+Data-sets](https://openehr.atlassian.net/wiki/spaces/spec/pages/175276035/Application+Data-sets) wikipage to include - references to some previous GUI discussions and - Region Östergötlands current use case and initial Ethercis-OPT-introspector+Angular-based design plans (See heading "OPT form renderer needed for pilot testing of surgery process supporting system" near the end of the page. --- ## Post #55 by @system Hi contributors on this, I am sorry not contributing so much, it is not my piece of cake to work on defining standards, I like better using them\. So I like to express that I am very grateful for the work which is being done in this context and the way it is being done\. I think that it will be a big step forwards for OpenEhr\. Best regards Bert Verhees --- **Canonical:** https://discourse.openehr.org/t/templates-for-application-form-development/15509 **Original content:** https://discourse.openehr.org/t/templates-for-application-form-development/15509