# GUI-directives/hints again (Was: Developing usable GUIs) **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2010-12-01 12:24 UTC **Views:** 22 **Replies:** 82 **URL:** https://discourse.openehr.org/t/gui-directives-hints-again-was-developing-usable-guis/15029 --- ## Post #1 by @system Hi All! There was a related discussion regarding GUI-directives/hints around june 2008, that I tried to summarize in the post [http://www.openehr.org/mailarchives/openehr-technical/msg03755.html](http://www.openehr.org/mailarchives/openehr-technical/msg03755.html) As you will see that post is somewhere in the middle of the thread, so you can find other interesting things before and after that post in the archives. Now, if I understand things correctly there is now implementatin experience from at least three projects regarding GUI-hints/directives (please add more if you know any): - Zilics ([http://www.openehr.org/mailarchives/openehr-technical/msg03767.html](http://www.openehr.org/mailarchives/openehr-technical/msg03767.html)) - GastrOs Endoscopy Application by Koray Atalag [et.al](http://et.al). - Open EHR-Gen by Pablo Pazos [et.al](http://et.al). What about trying to formalize some recommendations based on this experience, and perhaps even write a piece of specification draft that fits the new ADL 1.5 thinking regarding templates and archetypes. Would it be possible for anybody from any of the three projects to start a wiki page to describe your GUI-directives/hints and then we could compare them all and get a discussion going on the list possibly followed by some community driven development of a draft specification to try out. Best regards, Erik Sundvall [erik.sundvall@liu.se](mailto:erik.sundvall@liu.se) [http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/~erisu/) Tel: +46-13-286733 --- ## Post #2 by @yampeku There's also an opensource project called EHRFlex, which is an archetype\-based clinical registry system \(EHR\) independent of a particular reference model\. It uses clinical archetypes as guidelines for the automatic generation of web interfaces, oriented to a clinical use and data introduction\. Currently only supports ISO/CEN EN13606 archetypes \(but could be extended to work with archetypes of any other reference model\) and doesn't support templates yet here is the sourceforge website http://ehrflex.sourceforge.net/ --- ## Post #3 by @ian.mcnicoll Thanks Eric, This is an excellent suggestion\. With respect to ADL 1\.5, the operational template is, I think, the key artefact\. It is the 'close to run\-time' data definition, and can act as the start point for a great deal of downstream tooling support\. It would be interesting t know how readily other local template\-based openEHR projects can generate an operational template, since this not only gives a pivot oint for GUI directives etc but makes it possible to switch back\-end persistence very easily\. Ian Ian McNicoll office / fax \+44\(0\)1536 414994 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www\.phcsg\.org --- ## Post #4 by @Olof_Torgersson Hi, When it comes to templates, what I would like to see is that they are finalized and become a part of standard implementations such as the Java reference model. This is something I've been waiting for since I first viewed this list a couple of years ago. Then, as a next step one could start discussing various extensions, directives etc. Regards Olof Torgersson 1 dec 2010 kl. 13.24 skrev Erik Sundvall: --- ## Post #5 by @ian.mcnicoll Hi Olof, I agree this is a significant missing piece of the reference model and I am not sure how close the overall ADL 1\.5 spec is to being finalised but the operational template definition appears to be very stable and can act as a reference point for coalescing various local template implementations and tooling developments\. Thomas has already added ADL1\.5 support to the ADL Workbench and the specs seem to me to be stable enough to start implementation in Java\. I think the issue is lack of time/resource, rather than immaturity of the specifications \- it would be interesting to get Rong's take on this but I suspect he implemented a great deal of the current Java model prior to a stable RM being specified\. Indeed I would only expect a truly stable specification to emerge after some implementation experience\. IMO most real\-world implementations which strive for interoperability and maximally\-defined archetypes will almost all work via operational templates for validation, code \-generation GUI integration\. I don't think we have to wait for the full ratification of ADL1\.5 and template spec to start doing interesting things in downstream support, assuming that the opt definition is pretty stable\. The issues of extra directives and extensions are important at this stage as arguably some should be supported in the operational template, as I discussed above\. Ian Dr Ian McNicoll office / fax \+44\(0\)1536 414994 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www\.phcsg\.org --- ## Post #6 by @Tim_Cook2 IMO templates are an implementation specific issue and should not be part of the reference model\. Archetypes that express a concept as a maximal dataset are sufficient for interoperability\. Local templates are just that; local templates\. Certain implementations may share templates between applications but I dare say any attempt to 'standard' across implementations is wheel\-spinning\. If people are expecting magic pop\-out\-of\-the\-box applications then they are taking something mind\-altering\. :\-\) My 2 cents, Tim --- ## Post #7 by @thomas.beale Yes and no... we used to think that templates would be only local, but it is now clear that governments want a way to standardise whole data-sets, which is what an (ADL 1.5) template is - effectively an archetype that grabs bits of other archetypes and puts them together to create a specific data set, e.g. mixture of data captured in a specific kind of consultation, or lab result, or a discharge summary or whatever. These templates are very likely to be standardised, and offer a much better way to do this than the current way of doing it which is generally via ad hoc XML schemas. An ADL 1.5 template can be expressed as an XSD of course, but this is a downstream tool generated schema, not a hand-designed one. Further it turns out that a lot of institutions really do want to share templates, so a shareable formalism is actually important here. The ADL 1.5 spec is moving along ;-) I agree with the 'mind-altering' comment. - thomas --- ## Post #8 by @system I am happy to read this opinion and I do fully agree on this. This makes it possible to use templates for any purpose desired. I already had thought of some template enrichments which work with CSS. Now that there is template parsing software in Java, I am thinking of further developing/implementing it. Next step will be a repository with archetyped controls, like a GUI building developing tool, it even could be an eclipse or visual studio plugin, or write an own development environment, and so enabling a drag and drop development tool for people close to the medical professions. The templates could be the base of a Windows-executable GUI, or Mono, or Java, or PHP, or Javascript/HTML (AJAX), a client application that changes, depending on the template loaded. It is all a matter of just work to do. Maybe I am jumping too many steps in one time, but something like that is my bit further goal. Bert Op 1-12-2010 19:30, Tim Cook schreef: --- ## Post #9 by @thomas.beale Well we are pretty close with ADL 1.5, and I would expect that the Java project could safely start implementing what is in the current draft of ADL 1.5 and the Template document. So, hopefully not too many months now. - thomas [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #10 by @ian.mcnicoll Hi Thomas, It is not just governments who will want to use templates to define agreed minimum datasets\. At present all decent attempts at interoperability are essentially project\-driven and often quite local e\.g\. Diabetes shared care dataset, Palliative care message, Emergency care summary\. The difficulty has always been to ensure that each project does not end up defining variant semantics for the same core concept as they all tend to have slightly differing end\-requirements\. Templates turn out to be an excellent way to allow these specific use\-case datasets to be defined whilst ensuring that the underlying semantics do not end up in silos since they are expressed in the underlying archetypes\. Even when semantic differences cannot be resolved, it helps to express genuine disparity within the same archetype e\.g differing pain scales, as it helps to concentrate any on\-going debate into the enclosed scope of a single archetype\. Ian Dr Ian McNicoll office / fax \+44\(0\)1536 414994 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www\.phcsg\.org --- ## Post #11 by @system We had a similar discussion at the EN13606 web page. These are the conclussions I got. We should distinguish two types of templates: - Structural templates (specific use). Artefacts that constrain archetypes for specific uses or aggregate them in order to build more complex structures. These are the current openEHR templates. - Visualization templates (local use). These are a new idea. Local templates are just for visualization configuration (for example, positioning of the elements, definition of the size of a field, selection of a visual representation for a class or selection of the interface language). The important here is to distinguish “specific use” from “local use”. In my mind, a specific use is to define a use case where only a part of the archetypes or several archetypes are used. This is related to data structures. For example, to keep only the part of the blood pressure archetype that is important for the Primary Care measurement of vital signs. This specific use further constrains archetypes and these kind of structural templates should be also shared as the archetypes themselves since they will be needed to fully interpret the data. On the other hand, a local use is when you define constraints that are only useful for your own use or specific system. This is related to GUIs. These visualization templates are not meant to be shared outside your institution. ADL 1.5 is enough for defining the structural templates. Visualization templates needs something else to be defined. I would not recommend the use of those GUI-directives mixed with the structural templates, but to define a new level (maybe a specific model) for them. As some of you said, maybe these visualization or local templates do not need to be a part of "standardized" architecture since they are local implementations, but I think that it is possible to design a kind of common framework to deal with them together with archetypes and structural templates. David --- ## Post #12 by @Olof_Torgersson I definitely agree with this separation into what you call structural and visualization templates. It would be really nice if the structural ones became a reality and were implemented into for instance the Java reference implementation. These were almost finished a couple of years ago and seem to still be almost finished. Then one could use these as the basis for looking into ways of doing the visualization templates. This would be cleaner then having many different variations on the structural templates with different kinds of hints etc. Olof Torgersson --- ## Post #13 by @Tim_Cook2 Hmmm,I am very interested in hearing about a use case where these templates are 'needed' to 'fully interpret' the data\. Thanks, Tim --- ## Post #14 by @thomas.beale Tim, if someone designs a template that has say a more limited set of Snomed or other codes on a field than the original archetypes had, then querying the data may be enabled with the template at hand, since it would tell you what (reduced) set of code values could be possible in that field. This is one of the most common uses of templates we are finding. I can imagine other thing, e.g. coding of fields that were just DV_TEXT in the archetype. In ADL 1.5-land, a template is just another layer of archetyping, with some extra features. This is distinct from any 'visual template' stuff, which I agree should be a distinct artefact and probably formalism. - thomas --- ## Post #15 by @Tim_Cook2 > > Tim, > > if someone designs a template that has say a more limited set of > Snomed or other codes on a field than the original archetypes had, > then querying the data may be enabled with the template at hand, since > it would tell you what \(reduced\) set of code values could be possible > in that field\. So are you introducing some mind reading into this situation? Otherwise I cannot see any other outcome\. Because what you are telling me is that it is somehow meaningful in discovering the rational for choosing a Snomed code from a set as opposed to choosing the same Snomed code from some subset\. Hopefully, my healthcare provider is choosing their codes based on science\. Therefore they choose the correct one either way\. Of course if the correct one was subsetted out; that just equals BAD TEMPLATE\. But if there is some business case for this mind reading adventure\. I believe you'll need the luck of this guy http://www.youtube.com/user/failblog?blend=2&ob=4#p/u/85/woCCTm5m3qY to get any real information\. > This is one of the most common uses of templates we are finding\. So somehow knowing the possible choices somehow affects the actual code in the field you are querying? > I can imagine other thing, e\.g\. coding of fields that were just > DV\_TEXT in the archetype\. While I still think that this is a bad idea anyway\. After all; it is either free text or coded text\. Pick one\. I still don't understand how knowing what set was available is meaningful to the code chosen\. > In ADL 1\.5\-land, a template is just another layer of archetyping, with > some extra features\. I still fail to see the need\. It seems to me to be a useless layer of complexity\. But, I am still interested in a use case where templates are 'needed' to 'fully interpret' the data\. > This is distinct from any 'visual template' stuff, which I agree > should be a distinct artefact and probably formalism\. And this level is dependent on implementation choices\. Only applications built using the same framework can share these templates\. If an entity is going to dictate presentation options and layout then they are likely \(IMO\) going to do so in the context of the same framework\. \-\-Tim --- ## Post #16 by @thomas.beale > ``` > > ``` > > > ``` > > This is one of the most common uses of templates we are finding. > > > > ``` > > ``` > So somehow knowing the possible choices somehow affects the actual code > in the field you are querying? > > ``` in theory no, but it could affect what you consider to be correct. If you knew there were only 3 possible codes due to a template that had been used, then you might query directly using those codes, rather than the 20,000 allowed by the archetype. > > ``` > > I can imagine other thing, e.g. coding of fields that were just > > DV_TEXT in the archetype. > > > > ``` > > ``` > While I still think that this is a bad idea anyway. After all; it is > either free text or coded text. Pick one. I still don't understand how > knowing what set was available is meaningful to the code chosen. > > ``` well the user often picks whether to code or not; a quite common visual control is one that allows either to be entered. So the template might define a preferred value set of codes, while still allowing for plain text. The archetype probably only had the plain text constraint. If you have the template at hand, you could do some querying based on the knowledge of the code subset used by the template. > > ``` > > In ADL 1.5-land, a template is just another layer of archetyping, with > > some extra features. > > > > ``` > > ``` > I still fail to see the need. It seems to me to be a useless layer of > complexity. But, I am still interested in a use case where templates > are 'needed' to 'fully interpret' the data. > > ``` you mean the need of having the template to interpret the data? You can undoubtedly do it without the template. But since a lot of coding is defined locally, I think it is going to turn out to be useful. > > ``` > > This is distinct from any 'visual template' stuff, which I agree > > should be a distinct artefact and probably formalism. > > > > ``` > > ``` > And this level is dependent on implementation choices. Only > applications built using the same framework can share these templates. > If an entity is going to dictate presentation options and layout then > they are likely (IMO) going to do so in the context of the same > framework. > > ``` sure. This would imply yet another technology-independent formalism, if gui directive templates are also going to be portable. - thomas --- ## Post #17 by @Koray_Atalag Hi All, late to respond but here are a few thoughts: - While having ‘another layer’ of modelling to handle presentation I think we already have enough of those layers. I believe the common sense of doing this will be to sort out the GUI Directives stuff we all have come up with and do a careful analysis (led by the core team of course). Decide which ones are ‘universal’ and which ones are data-set specific. Then like annotations in templates invent new optional keywords to accommodate these. The operational template will then contain everything an application would need to function. - I strongly believe that the presentation information should not be separated from data-set definitions – templates. As archetypes and templates are designed to handle ‘*change*’ this means that the model will be on constant change so maintaining two models – kind of shadows of each other does not make sense to me. Perhaps not so good design from a puristic point of view ;) - I am also pretty sure that with a handful of those GUI directives we can cover %80 of all presentation requirements in any clinical domain – we’ll worry about the rest later on. So it may well be the case that some of these directives may become concrete and be part of the specifications – which will boost consistency among different implementations. - I also think while thinking on these issues we should also have a look at other facades of GUI – such as implementation technologies, Web/client forms and MVC etc. methodologies. These may have an influence on the directives we will likely to come up with. My 4 cents...Cheers, -koray P.S. Our developer Mr. Hong Yul Yang (also an awesome pianist!) now has a good understanding of openEHR and I think he has much to contribute to this community...he gave a good deep thought to the above implementation technologies and MVC approach before going on with GastrOS. Hong Yul I think it is now time to talk for yourself – don’t be shy! And people don’t hesitate to ask all your hard questions... --- ## Post #18 by @pablo Hi Erik, great idea. I have created this page: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates With a short description of our templates and how they are used in the framework --- ## Post #19 by @system 2010/12/2, Tim Cook > > Hmmm,I am very interested in hearing about a use case where these > templates are 'needed' to 'fully interpret' the data\. > > Thanks, > Tim > Maybe I do not have the knowledge to give a valid clinical example but it is reasonable to think that constraining an archetype in the way a template does can influence the interpretation of the data\. Imagine you have a set of archetypes and you define a template constraining some items to not allowed\. You use that template to fill some data and then you require the collaboration of a physician from an external organisation\. You share the archetypes but not the template\. And then the other physician fills some more data \(including the one you marked as not allowed\) and returns it to you\. There is the problem, when you revise the data using again your own template you will never see part of the new data and that can affect your interpretation of it\. That's why structural templates must be also shared in some cases\. --- ## Post #20 by @Tim_Cook2 Hi David, Thanks for the reply\. > Maybe I do not have the knowledge to give a valid clinical example but > it is reasonable to think that constraining an archetype in the way a > template does can influence the interpretation of the data\. What is reasonable is subjective; but okay\. > Imagine you have a set of archetypes and you define a template > constraining some items to not allowed\. Okay\. > You use that template to fill > some data and then you require the collaboration of a physician from > an external organisation\. You share the archetypes but not the > template\. And then the other physician fills some more data \(including > the one you marked as not allowed\) and returns it to you\. Okay\. > There is the > problem, when you revise the data using again your own template you > will never see part of the new data and that can affect your > interpretation of it\. It that \*is\* a problem then ==> Bad application design\. > That's why structural templates must be also shared in some cases\. \#1\. You do not revise data in a health record\. You version it with additional information\. \#2\. Any well designed archetype / template combination is going to use the same 'data structure'\. Irregardless of the available options\. \#3\. The templates you use should only restrict data entry\. It should not filter existing data of the same structure\. If it does; there goes interoperability\. Along with the entire premise for the use of and purpose of archetypes\. \-\-Tim --- ## Post #21 by @Hong_Yul_Yang Hi All, late to respond but here are a few thoughts: - While having ‘another layer’ of modelling to handle presentation I think we already have enough of those layers. I believe the common sense of doing this will be to sort out the GUI Directives stuff we all have come up with and do a careful analysis (led by the core team of course). Decide which ones are ‘universal’ and which ones are data-set specific. Then like annotations in templates invent new optional keywords to accommodate these. The operational template will then contain everything an application would need to function. - I strongly believe that the presentation information should not be separated from data-set definitions – templates. As archetypes and templates are designed to handle ‘*change*’ this means that the model will be on constant change so maintaining two models – kind of shadows of each other does not make sense to me. Perhaps not so good design from a puristic point of view ;) - I am also pretty sure that with a handful of those GUI directives we can cover %80 of all presentation requirements in any clinical domain – we’ll worry about the rest later on. So it may well be the case that some of these directives may become concrete and be part of the specifications – which will boost consistency among different implementations. - I also think while thinking on these issues we should also have a look at other facades of GUI – such as implementation technologies, Web/client forms and MVC etc. methodologies. These may have an influence on the directives we will likely to come up with. My 4 cents...Cheers, -koray P.S. Our developer Mr. Hong Yul Yang (also an awesome pianist!) now has a good understanding of openEHR and I think he has much to contribute to this community...he gave a good deep thought to the above implementation technologies and MVC approach before going on with GastrOS. Hong Yul I think it is now time to talk for yourself – don’t be shy! And people don’t hesitate to ask all your hard questions... --- ## Post #22 by @Paria_Kashfi Dear Tim, Thank you for your response Could you please provide me with more detail about this? Would it need manual adjustment of any css/style file or would it be totally dynamic? Is it based on the templates, archetypes, or both? I am trying to summarize the answers from different contributors, so that we can have a better image of the situation when it comes to GUI generation. Best Regards Pariya MSc; PhD Candidate Department of Computing Science and Engineering Chalmers University of Technology [http://www.ait.gu.se/kontaktaoss/personal/hajar-kashfi/](http://www.ait.gu.se/kontaktaoss/personal/hajar-kashfi/) --- ## Post #23 by @Tim_Cook2 > Dear Tim, > > Thank you for your response > Could you please provide me with more detail about this? > Would it need manual adjustment of any css/style file or would it be > totally dynamic? Well, you can generate dynamic UIs; but I really doubt that they are useful in any real world situation\. :\-\) > Is it based on the templates, archetypes, or both? Archetype based; with a layer of templating for local constraints\. > I am trying to summarize the answers from different contributors, so > that we can have a better image of the situation when it comes to GUI > generation\. Have you considered that it would be a good idea to conform to MSCUI? \-\-Tim --- ## Post #24 by @Paria_Kashfi Hi, From your response, my understanding is that one can generate such a GUI in OSHIP, but is also needs manual adjustments to reach the ideal GUI design. I'm not sure if I understand your last phrase. Do you mean considering design guidelines while generating GUIs? Best Regards Pariya MSc; PhD Candidate Department of Computing Science and Engineering Chalmers University of Technology [http://www.ait.gu.se/kontaktaoss/personal/hajar-kashfi/](http://www.ait.gu.se/kontaktaoss/personal/hajar-kashfi/) --- ## Post #25 by @Tim_Cook2 > > I'm not sure if I understand your last phrase\. > Do you mean considering design guidelines while generating GUI Yes\. \-Tim --- ## Post #26 by @ian.mcnicoll Hi Tim, I do tend to agree with you that GUI generation can be useful as a startpoint, but that most real\-world applications will demand much a richer GUI that will need subsequent, manual intervention\. There are 2 other areas where auto\-GUI generation can be useful\. One is in the area of user\-defined forms, a common feature in many applications\. The other is in the area of requirements gathering and prototyping, either for EHR aplication development or wider standards development work\. Dr Ian McNicoll office / fax \+44\(0\)1536 414994 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www\.phcsg\.org --- ## Post #27 by @pablo Hi Ian, I think there is a way to customize the GUI without (direct) manual manipulation. If an application can generate expressive HTML, you can do all the customization with CSS (a good web designer can make this work for us). For "expressive HTML" I mean, HTML code with tags, ids and classes that let you customize every aspect of the way each template/archetype node is displayed: position, size, labels, etc. This is the only way to do GUI customization for projects that generate the GUI on the fly and that are web-based. (like the Open EHR-Gen). Example: This is an inexpressive HTML:
a label:
This is an expressive HTML:
Other idea is to use some CMS-like functions, like dragging and dropping generated components on different zone of a web page layout. So, each user can have its own customized GUI. We can create a couple of these layouts, based on some GUI patterns and good practices, and adjust our GUI generators to use one layout or the other to see if the page generated is usable or not. Our Open EHR-Gen Framework has some of this ideas already developed (each node in our GUI-templates have a "pageZone" attribute that indicates in wich zone of the web layout, this node has to be displayed). See: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates --- ## Post #28 by @system > > \#1\. You do not revise data in a health record\. You version it with > additional information\. You are right, I was not precise enough\. > \#2\. Any well designed archetype / template combination is going to use > the same 'data structure'\. Irregardless of the available options\. Of course, both revisions of data are valid and correct regarding the archetypes, I did not say the contrary\. > \#3\. The templates you use should only restrict data entry\. It should > not filter existing data of the same structure\. If it does; there goes > interoperability\. Along with the entire premise for the use of and > purpose of archetypes\. Interesting\.\.\. If templates are only used for data entry and not for data reading and revision that should be stated clearly for all developers, since I think it is not said anywhere at the specifications, the web or the wiki\. Every developer should know that \(coming back to the topic of this thread\) if they hand\-code a visualization template all that work is only useful for the data generated at their own system and not for the data from an external one, even if it is using the same archetypes\. --- ## Post #29 by @thomas.beale the general idea has always been that data can always be interpreted by a receiver using just the archetypes declared in the data. I believe this will continue to be a reliable assumption into the future. However, with the new style templates, which are essentially just archetypes, it may be that templates will be shared quite often as well, since the computing machinery that can deal with archetypes will be able to deal with ADL 1.5 templates as well (with only very minor upgrades from today, since we are talking about operational templates, which are essentially big archetypes). This is not going to add much information, since the information structures themselves (i.e. the compositional hierarchy of Composition, Sections, Entries etc) will reflect the structure of the template that was used. But if the receiver wants to validate the received data against the template, which is likely to include a) numerous removed optional items and b) further constrained coded text fields, then it will need the template. Note that the data as received must be definition already be valid with respect to the implicated archetypes, and if the receiver is interested in what the template says, then it means they probably have some agreement with the sender institution about using their templates. This will almost certainly happen with nationally standardised templates for referrals, discharge summaries and so on. In summary: displaying and using the data with just the archetypes used to build it will be fine, since the data will reflect accurately the removed optional items, reduced terminology choices etc. Any site wanting to do processing against the template will undoubtedly be in some kind of communication with the publisher of the template. - thomas --- ## Post #30 by @system Thanks Thomas\. I will resume the reasoning that brought us here: "in some cases" templates will also be shared together with archetypes, then, in my opinion, they should not incorporate GUI related stuff and be only about data constraints\. David --- ## Post #31 by @Tim_Cook2 Hi Tom, > the general idea has always been that data can always be interpreted > by a receiver using just the archetypes declared in the data\. I > believe this will continue to be a reliable assumption into the > future\. So this begs the question\. Do you think that there is a possibility that it will NOT continue to be a reliable assumption? > However, with the new style templates, which are essentially just > archetypes, it may be that templates will be shared quite often as > well, since the computing machinery that can deal with archetypes will > be able to deal with ADL 1\.5 templates as well \(with only very minor > upgrades from today, since we are talking about operational templates, > which are essentially big archetypes\)\. So in a paragraph or less can you explain the difference between templates and simply constructing archetypes that use slots for extendability? > This is not going to add much information, since the information > structures themselves \(i\.e\. the compositional hierarchy of > Composition, Sections, Entries etc\) will reflect the structure of the > template that was used\. But if the receiver wants to validate the > received data against the template, But if the data validates against the archetype\(s\) \(and therefore the reference model\) there is no need to validate against templates\. > and if the receiver is interested in what the template says, then it > means they probably have some agreement with the sender institution > about using their templates\. Correct\. So this is not a technical issue at all\. It is a socio\-political issue\. > This will almost certainly happen with nationally standardised > templates for referrals, discharge summaries and so on\. Makes sense\. > In summary: displaying and using the data with just the archetypes > used to build it will be fine, since the data will reflect accurately > the removed optional items, reduced terminology choices etc\. Actually the data will reflect the 'chosen' option\(s\)\. It is a historical artifact\. > Any site wanting to do processing against the template will > undoubtedly be in some kind of communication with the publisher of the > template\. Right; and otherwise the data is still valid against the archetype and should be valid in any conforming application\. Since my original question was asking for a use case where templates were required to fully interpret the data\. Based on this assertion: > This specific use further constrains archetypes and these kind of > structural templates should be also shared as the archetypes > themselves since they will be needed to fully interpret the data\. David and I agree that GUI directives have no place in structural definitions\. Therefore, templates should not filter out existing \(valid\) data\. At least I think that is what he is saying\. But the point I am making is that templates do not have to be shared in order to interpret the data\. Again, the only information a template can add is what particular subsets were available at the time a specific entry was chosen\. I simply do not see a purpose for this 'requirement'\. The data has been entered\. It is now part of a historical record\. Since the archetype describes the data model of the concept as a set of constraints against the reference model\. That is all the validation required\. Again, if I am missing something I am very interested in what it is\. Thanks, Tim --- ## Post #32 by @thomas.beale > ``` > Hi Tom, > > > ``` > > > ``` > > the general idea has always been that data can always be interpreted > > by a receiver using just the archetypes declared in the data. I > > believe this will continue to be a reliable assumption into the > > future. > > > > ``` > > ``` > So this begs the question. Do you think that there is a possibility > that it will NOT continue to be a reliable assumption? > > ``` The current design of ADL 1.5 is that template ids will be declared in the data (since they are just like archetype ids) - see [http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf](http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf) So it is really about the mechanisms for sharing archetypes and templates. If specific templates are made available for sharing, then they will be used, just like archetypes. If locally produced specialised archetypes are made available for sharing, the same for them; otherwise the receiver system has to revert back to whatever archetypes and templates it can access. Now, assuming a standardised kind of published service (of which CKM can be considered an initial example) is used, then it just depends on producers 'publishing' archetypes and templates. So far in the national programmes we have seen the intention is to create most templates nationally and share them at that level. The key point to remember is that no matter what reduced set of archetypes or templates are available, **the data received are always correct according to the local artefacts** in use at the sender side (barring software or other system errors of course). So the potential limitations at the receiver are to do with: - not having the archetype information for **added data points**, due to not having specialised archetypes produced locally at the origin. - this is correct: if the definition of those added items were of interest outside the producer site, it would have published the relevant archetypes somewhere - regardless, the data structures are always openEHR standard structures, and the receiver can always process them in a generic way.- not having the templates: the only limitation here is not knowing what restrictions (**removed data points, more constrained term sets**) were specified in the template above those of the underlying archetypes. - this is also correct: this would only matter if the receiver wanted to allow users to modify the data according to the same templates as at the senders location; if this is true, it means that the receiver wants to share the templates, and they will have arranged to do this. > ``` > > ``` > > > ``` > > However, with the new style templates, which are essentially just > > archetypes, it may be that templates will be shared quite often as > > well, since the computing machinery that can deal with archetypes will > > be able to deal with ADL 1.5 templates as well (with only very minor > > upgrades from today, since we are talking about operational templates, > > which are essentially big archetypes). > > > > ``` > > ``` > So in a paragraph or less can you explain the difference between > templates and simply constructing archetypes that use slots for > extendability? > > ``` Archetypes contain slots; templates fill them and remove unwanted archetype data points (generally most of them in any given template). It is a matter for discussion whether templates should ever be allowed to add new data points the way an archetype can. > > ``` > > This is not going to add much information, since the information > > structures themselves (i.e. the compositional hierarchy of > > Composition, Sections, Entries etc) will reflect the structure of the > > template that was used. But if the receiver wants to validate the > > received data against the template, > > > > ``` > > ``` > But if the data validates against the archetype(s) (and therefore the > reference model) there is no need to validate against templates. > > ``` at the receiver side, correct. Unless the receiver wants to do that for some reason, e.g. to enable users to further modify the data according to the same rules as at the sender, in which case sharing is required. > ``` > But the point I am making is that templates do not have to be shared in > order to interpret the data. Again, the only information a template can > add is what particular subsets were available at the time a specific > entry was chosen. I simply do not see a purpose for this 'requirement'. > The data has been entered. It is now part of a historical record. > Since the archetype describes the data model of the concept as a set of > constraints against the reference model. That is all the validation > required. > > Again, if I am missing something I am very interested in what it is. > > Thanks, > Tim > > ``` for interpreting data, I would agree. For doing other things, possibly not. - thomas --- ## Post #33 by @thomas.beale I would regard this as a base assumption, and a clear separation of concerns. - thomas --- ## Post #34 by @Tim_Cook2 Hi Tom, > The current design of ADL 1\.5 is that template ids will be declared in > the data \(since they are just like archetype ids\) \- see > http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf > > So it is really about the mechanisms for sharing archetypes and > templates\. If specific templates are made available for sharing, then > they will be used, just like archetypes\. If locally produced > specialised archetypes are made available for sharing, the same for > them; otherwise the receiver system has to revert back to whatever > archetypes and templates it can access\. \.\.\. > Archetypes contain slots; templates fill them and remove unwanted > archetype data points \(generally most of them in any given template\)\. > It is a matter for discussion whether templates should ever be allowed > to add new data points the way an archetype can\. Thanks for these clarifications\. They are \*very\* important points to consider\. IMHO, if templates are permitted to add to the constraints published by an archetype then it changes the basic design paradigm\. Something to consider very seriously\. Regards, Tim --- ## Post #35 by @thomas.beale I mostly agree: it just makes it clearer if templates are not adding any more data points. The formalism will in fact allow this, so it will be up to tools to prevent it. That is not hard to do. On the other hand, one could make the same argument about added data items in templates as for purely locally used archetypes: they are of local interest only (e.g. some kind of hospital specific business process study), and have really no meaning whatever outside. I personally think it makes it simpler for everyone to think of templates as only being used for 1. slot-filling 2. removal of unneeded optional data points and 3. tightening of some leaf value constraints, nearly always coded terms. If it turns out that data node additions make sense, we will deal with it when a true need is clear. - thomas --- ## Post #36 by @Olof_Torgersson 5 dec 2010 kl. 18.04 skrev Thomas Beale: > > > > > I personally think it makes it simpler for everyone to think of templates as only being used for 1. slot-filling 2. removal of unneeded optional data points and 3. tightening of some leaf value constraints, nearly always coded terms. If it turns out that data node additions make sense, we will deal with it when a true need is clear. Returning to the original topic of what should go into a template, I would say that this statement supports that template should not contain GUI-directives, but that such information should go into a special visualization layer? regards Olof --- ## Post #37 by @Olof_Torgersson Hi All, late to respond but here are a few thoughts: - While having ‘another layer’ of modelling to handle presentation I think we already have enough of those layers. I believe the common sense of doing this will be to sort out the GUI Directives stuff we all have come up with and do a careful analysis (led by the core team of course). Decide which ones are ‘universal’ and which ones are data-set specific. Then like annotations in templates invent new optional keywords to accommodate these. The operational template will then contain everything an application would need to function. - I strongly believe that the presentation information should not be separated from data-set definitions – templates. As archetypes and templates are designed to handle ‘*change*’ this means that the model will be on constant change so maintaining two models – kind of shadows of each other does not make sense to me. Perhaps not so good design from a puristic point of view ;) - I am also pretty sure that with a handful of those GUI directives we can cover %80 of all presentation requirements in any clinical domain – we’ll worry about the rest later on. So it may well be the case that some of these directives may become concrete and be part of the specifications – which will boost consistency among different implementations. - I also think while thinking on these issues we should also have a look at other facades of GUI – such as implementation technologies, Web/client forms and MVC etc. methodologies. These may have an influence on the directives we will likely to come up with. My 4 cents...Cheers, -koray P.S. Our developer Mr. Hong Yul Yang (also an awesome pianist!) now has a good understanding of openEHR and I think he has much to contribute to this community...he gave a good deep thought to the above implementation technologies and MVC approach before going on with GastrOS. Hong Yul I think it is now time to talk for yourself – don’t be shy! And people don’t hesitate to ask all your hard questions... --- ## Post #38 by @thomas.beale > 5 dec 2010 kl. 18.04 skrev Thomas Beale: > > Returning to the original topic of what should go into a template, I would say that this statement supports that template should not > contain GUI-directives, but that such information should go into a special visualization layer? Yes. Visualisation / GUI hints could be written on a per-form basis, probably 1:1 or maybe 1:N with respect to templates, and could use archetype paths, same as in AQL to reference things. E.g. it could have statements logically like: id = <"some form id"> templates = <"template 1", "template 2"> structure = < [1] = (VBOX) < [1] = (HBOX) < location = < x = <> y = <> > controls = < [1] = [2] = etc > > [2] = (HBOX) < controls = < [1] = > > [3] = (VBOX) < etc > etc > > I just made this up in dADL, the real thing will be in some XML format, the point is to use archetype paths, and also potentially to have a way of mapping back from archetype/template paths to locations in the visual structure. In the above, the archetype path **[diagnosis_archetype_id]/path/to/diagnosis** is at **/structure[1][1]/controls[1]** in the specification structure, which is a **text_and_coded_text_control**. You might also map a complex custom built control that captures 4 or 5 commonly grouped data elements, to a non-terminal path within a template structure. Please note: I am just thinking out aloud here, and a working 'GUI hints' language / file format will no doubt look completely different. - thomas --- ## Post #39 by @Tim_Cook2 Exactly, we have some researchers here doing exactly that work\. I am certain that their results will be open sourced\. \-\-Tim --- ## Post #40 by @ian.mcnicoll Hi Olof, I agree but I think there are some directives that are actually not purely GUI directives but which say something meaningful about the underlying information\. For instance Koray's directive isCoreConcept \(g\): "This is an abstract concept; but we can say that Core Concepts are real\-world entities which we can talk about their abscence \(i\.e\. a clinical finding, a disease but not tumour grade or physical examination\)\. The directive depicts whether a node with all its children \(if any\) shall be handled and repeated as a whole in an archetype \(i\.e\. makes sense together such as a clinical finding with other attributes defining its nature\)\. When the node and/or its children are selected, its presence information is stored in the corresponding ELEMENT node which records this \(i\.e\. in MST Findings archetypes \[Present?\] node\)\." This seems to me to represent some sort of association between a parent concept and potential children which is independent of any GUI representation\. These, I believe, should be considered for inclusion within archetypes/templates\. Ian Dr Ian McNicoll office / fax \+44\(0\)1536 414994 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www\.phcsg\.org --- ## Post #41 by @Koray_Atalag Hi Ian, others We've had a bit of discussion on this at Medinfo and that you pointed to separation of pure GUI stuff from others where there is an inherent relationship with the semantics and structure of information \- fully agree\. The question is how to do that and when; i\.e\. the process\. I think the time is just about right as implementations start and progress rapidly\. As to how I think having these discussions is a great start\. But it'd be great if someone from the core group 'owns' this thread and puts some pressure on us\. As Ian pointed out we have some 10 directives, which turned out to be all generic \(i\.e\. not specific to our endoscopy application\) which is great\. The isCoreConcept directive really is a special one which deeply involves semantics and structure of the clinical information being modelled\. Rest of the directives are not so much like this but there is an obvious need to separate\. The mantra of openEHR modelling says that anything that has to do with structure and semantics goes into clinical models\. Then which models? I think we must first make clear what we are talking about: out of models or within models and then Archetypes or Templates\. For us this was a no brainer because I think ALL pure GUI stuff should go to Templates\. I have explained my reasoning in a previous message but shortly archetypes and templates are all about information capture and validation \(i\.e\. which data items, their organisation, and basic constraints for validation\)\. Real world semantics are delegated to terminology \(i\.e\. heart murmur IS\-A symptom of heart disease or cardia is PART\-OF stomach etc\)\. I think we need to keep archetypes fairly pure and generic with large scale interoperability in mind\. However templates provide all the convenience needed otherwise\. I strongly believe we do\_not\_need another layer of modelling for GUI because referring back to my definition of clinical models, these are to do with information capture and validation\.\.\.And that's what GUI is tightly coupled with this\. Our models are designed for change; indeed this is the very reason we split into multi\-levels\. So maintaining two different models serving similar purposes is not good modelling design I think\. At least that wouldn't work for us with >3000 lines of ADL plus 9 language translations x 10 archetypes and many others\.\.\.The mode of change has to be together; that is when I am making a change to an archetype or template I must immediately take care of its GUI behaviour\. That said, returning back to Ian's suggestion, other directives should probably be incorporated into templates and really hard ones into archetypes\. For example we need some means to depict whether a clinical finding \(aka core concept\) is present or not I had to introduce an extra ELEMENT to each and every node of my MST archetypes\. The flavours of null on ELEMENT is not sufficient for that and after all it has to be depicted at CLUSTER level\. CoreConcept is also another one, perhaps need an abstract ITEM over CLUSTER and ELEMENT just to provide that semantics\. We have studied this core concept stuff in detail and I also have substantial amount of practical experience on this\. I must say that we drew the line by referring to Astrid van Ginneken's work \- openSDE \(from Erasmus Univ\)\. There are REALLY good GUI related stuff there which openEHR can benefit \- I have been saying this for long\! The key phrase is whether you can talk about absence of something or not \- if you can then it is a core concept which needs special attention in modelling\. http://opensde.sourceforge.net/ Here is the link to our original paper on the GUI Directives and how we implemented: http://openehr.org/wiki/download/attachments/18513934/Atalag_HINZ2010-Paper.pdf?version=1&modificationDate=1291667587000 This is also another recent paper came out of the same study which mentions about implementation strategy including GUI stuff: http://openehr.org/wiki/download/attachments/18513934/Atalag_1_5.pdf?version=1&modificationDate=1291667587000 Hope stimulates more discussions\.\.\. Greetings from Auckland :\) \-koray Skype: atalagk --- ## Post #42 by @thomas.beale Only one problem with this reasoning: templates are often used for things other than the GUI, e.g. messages. In the future, they will end up being used for reports as well. In general, I believe the openEHR template will be an artefact defining a specific data set (including optionality where needed), and auxiliary artefacts will always be needed to connect that definition to its target technology: a specific kind of GUI form, message infrastructure or relational mapping or querying environment - thomas --- ## Post #43 by @ian.mcnicoll Hi Koray, I agree with Thomas here, Koray, but I take your point about the separation into a further layer represents added potential development complexity\. I think we should expect tools to handle this in the same way that a complex development environment like Visual Studio handles various layers of application 'code' and resources within a seamless environment\. You should not have to think about these separate layers during development\. Your comments about 'isCoreConcept' are very interesting because I think you have touched upon an issue in semantics that we are coming across, particularly when modelling detailed clinical findings\. I had been thinking about the same issue from a different angle, essentially how to cleanly model findings where the requirement might expand gradually from a Y/N response to a full blown complex structure, in different clinical contexts and over time as more detailed requirements emerge\. It touches upon the crucial areas of integration with SNOMED post\-coordinations and the handling of Questionnaire type structures but I think we should continue this discussion is a separate clinical thread because it is definitely not just an issue of GUI\. Ian Dr Ian McNicoll office / fax \+44\(0\)1536 414994 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www\.phcsg\.org --- ## Post #44 by @thomas.beale > ``` > Hi Koray, > > I agree with Thomas here, Koray, but I take your point about the > separation into a further layer represents added potential development > complexity. > ``` well... software engineering history would say otherwise. Where a concept is needed you have two choices: - A) mix it in with the languages & architectural layers you already have - B) create a dedicated layer or component type, and possibly dedicated formalism if needed A) represents the history of large scale systems built in the 60s, 70s and 80s - unmaintainable spaghetti. B), if done right is always better. > ``` > I think we should expect tools to handle this in the same > way that a complex development environment like Visual Studio handles > various layers of application 'code' and resources within a seamless > environment. You should not have to think about these separate layers > during development. > > ``` exactly - thomas --- ## Post #45 by @pablo May be if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems. I think the only thing in common of those two type of template is that they reference a set of archetypes to do something. --- ## Post #46 by @thomas.beale I would suggest that the GUI templates just reference paths found in the openEHR template. - thomas --- ## Post #47 by @pablo I agree with your comment, but only for v1.5 templates and archetypes. For v1.4 I think that GUI Templates must reference archetypes ids and paths. --- ## Post #48 by @ian.mcnicoll Hi Pablo, In both ADL1\.4 and 1\.5 every path is still an archetype\-based path\. The proposed schema for an operational template is very similar to the XML schema of an individual archetype but obviously includes multiple aggregated archetypes and omits any nodes which are constrained out\. Templates are technically identical to specialised archetypes\. The difference is that specialised archetypes support templating features such as constraining out unwanted elements and aggregating archetypes\. The only difference between an archetype and a template is that new content i\.e\. new nodes or terms cannot be added to a template\. Ian Dr Ian McNicoll office / fax \+44\(0\)1536 414994 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www\.phcsg\.org --- ## Post #49 by @pablo Hi Ian, If I understand what Thomas said "I would suggest that the GUI templates just reference paths found in the openEHR template", the paths in a GUI Template will come "only" from openEHR templates (the structural ones), not from archetypes (this is apart from that they are technically the same thing). I think in ADL 1.4 the template specification is not complete, I would say that in 1.4 Templates are not so clear Archetype specializations. In ADL 1.5 is more clear the relationship of Templates and Archetypes. What I meant in the previous mail was: for us who have developed applications over ADL 1.4, our GUI Templates will use paths "directly" from Archetypes, instead of paths from openEHR structural Templates. --- ## Post #50 by @Koray_Atalag Hi All, I’ve read similar work before starting with our design and found Thilo’s prior work very relevant and well researched. This MIEUR 2006 paper describes a new layer of GUI model using Mozilla XUL – an XML based open web layout standard. AT the time of writing templates were not out there yet and from his discussion I reckon much of the GUI definition could be handled by templates. I now agree that pure GUI stuff must be represented elsewhere – but at the moment we find template annotations quite useful and sufficient. Be aware that our app is a Winforms one – not Web based. So the kind of GUI rules might differ from others which are almost all Web based. And one note to Thomas: we actually use templates for defining a minimum data set (yes not a maximal) for the purpose of reporting…So w have both data entry/validation and reporting layout issues. Not messaging though but we are planning to transform the openEHR instance of endoscopy report into CDA and exchange with HL7 V2.x in near future. Cheers, -koray --- ## Post #51 by @Koray_Atalag Sorry forgot Thilo’s paper info:
1. Schuler T, Garde S, Heard S, Beale T. Towards automatically generating graphical user interfaces from openEHR archetypes. Stud Health Technol Inform 2006;124:221-6.
Cheers, -koray --- ## Post #52 by @thomas.beale Hi All, I’ve read similar work before starting with our design and found Thilo’s prior work very relevant and well researched. This MIEUR 2006 paper describes a new layer of GUI model using Mozilla XUL – an XML based open web layout standard. AT the time of writing templates were not out there yet and from his discussion I reckon much of the GUI definition could be handled by templates. I now agree that pure GUI stuff must be represented elsewhere – but at the moment we find template annotations quite useful and sufficient. Be aware that our app is a Winforms one – not Web based. So the kind of GUI rules might differ from others which are almost all Web based. And one note to Thomas: we actually use templates for defining a minimum data set (yes not a maximal) for the purpose of reporting… --- ## Post #53 by @system Hi! A very interesting discussion, thanks to everybody here! Great with all references too! > Maybe if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems. Or perhaps "GUI focused templates" and "Structurally focused templates" (since both will be openEHR based). Correct me if I'm wrong: If templates can specialize templates in several generations of inheritance/specialisation (This is the case, right?), then we could use the same basic annotation formalism for different purposes in different layers, only the annotation names would be different. So an example inheritance/specialisation hierarchy in a running system could be: A bunch of clinical archetypes (mostly international, and some regional ones) ...are used as building blocks in... a "structural" template (maybe national/regional) often creating a composite SECTION or COMPOSITION [add more structural layers if useful] ...that is then annotated with GUI-hints by... a set of "GUI templates" with each template fitting a different recurring use case ...for a specific GUI, the most fitting of those GUI templates is then picked and might be further annotated/specialized with yet another template layer or used directly as input to GUI-generation or GUI-building tools > you have two choices: > > - A) mix it in with the languages & architectural layers you already have > - B) create a dedicated layer or component type, and possibly dedicated formalism if needed I believe there is (as usual) a context dependent gray-zone, not a clear breakpoint, regarding what annotations would be most useful to have in which layer. So, yes I agree layers are good for separation of concerns, but it is not always (at least not at an early stage) easy to forsee exactly what best fits into each layer and how many layers there should be. If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) and if could be reused also for GUI-stuff instead of creating another different formalism, then we should take a close look at that option before thinking of specifying another mechanism for GUI-concerns. You'd still get layers (if you sensibly use specialisation) but more flexible boundaries during the needed upcoming period of collaborative experimentation and real use. --- ## Post #54 by @Thilo_Schuler1 Hi Koray, Erik, Pablo, Pariya and other GUI interested These are very exciting times for me. I have been interested in openEHR GUIs and GUI generation since the first experiments that the co-authors and I did prior to publishing the MIE 2006 paper that Koray mentioned. For those still interested I uploaded a very late draft [;)] of this old paper to the [wiki](http://openehr.org/wiki/display/resources/MIE+2006+-+Maastricht%2C+Netherlands). After that Helma, her supervisor, Rong and I published a very future-oriented [paper](http://www.ncbi.nlm.nih.gov/pubmed/17911890?ordinalpos=1&itool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_RVDocSum) about sharing not only archetypes but also GUI artefacts. Helma later extended this idea in a chapter of her thesis and [(re)published](http://www.ncbi.nlm.nih.gov/pubmed/19368989) it. I will ask her whether we can put the paper and her thesis on the wiki (maybe she reads this anyway... Hello Helma?). This is definitely far away from end-to-end applications and it is unclear whether it will ever be realisable but it still has some very interesting thoughts for our discussion. An extended version of [Lisa's EhrView mechanism](http://openehr.org/wiki/display/dev/openEHR+Composition+XML+to+HTML) with a repository of XSLT-fragments is - IMO - something that could definitely be realised in the midterm to provide an enhanced read-only view of arbitrary openEHR information. It is great to see/hear that GUI generation is working in two proper end-to-end applications now: - Next week I will continue my [exploration](http://openehr.org/wiki/display/impl/Playing+with+Pablo%27s+Open+EHR-Gen+Framework) of Open Ehr-Gen - As soon as GastrOS is open-sourced I will give it a spin as well Due to lack of time, money, programming skill, openEHR maturity,... I haven't been involved in this topic anymore lately. This discussion and the before mentioned applications are motivation for me to start again providing my small share to drive this topic further. I think this could be very important for openEHR overall as e.g. web-based Open EHR-Gen will make it easy to demonstrate openEHR to a wider audience. Erik makes a very good point about "ownership" of this issue. We who are interested and especially those with practical experience should drive this topic. Here from memory a group that has been or is involved with openEHR GUI generation (please add those who I forgot) - Koray & Hong Yul - Pablo & Leandro - Seref & Tony - Helma - Lisa - Rong - Thilo Let's take the max leverage for openEHR out of this discussion! Cheers, Thilo --- ## Post #55 by @pablo Hi Thilo, Is great to see such enthusiasm on the subject of GUI definition & generation (subject I love). I see we have many people interested in the subject too. I think your work in exploring tools like ours, is of great importance, because without these explorations and trials we could not improve our tools (owned by the community). I really think that your work exploring the tools is as important as our work making them. Without people like you, our work is senseless. I hope to see more advance in your the exploration of the EHR-Gen next week. All your comments and thoughts will be considered to improve the tool. And anyone who want to participate in the improvement, is welcome. Of course, any questions or comments are welcome. --- ## Post #56 by @Thilo_Schuler1 Hi everybody, I got permission to publish the MedInfo paper and its successor mentioned below. You can find it here (last row of table): [http://www.openehr.org/wiki/display/resources/MedInfo+2007+-+Brisbane+Australia](http://www.openehr.org/wiki/display/resources/MedInfo+2007+-+Brisbane+Australia) Cheers, Thilo --- ## Post #57 by @Koray_Atalag Thanks Thile, didn’t have this paper before – will read now with much pleasure J Hong Yul and I had a long discussion yesterday and will prepare a joint response today or tomorrow (well NZ time of course!). Especially Tom has asked whether we have any issues which might need to go into Templates or Archetypes that has to do with the semantics and structure rather than GUI only. We think that we do but need first to define and be able to articulate in plain words. Cheers, -koray --- ## Post #58 by @Koray_Atalag Hi Tom, here is our response: We have so far came across two issues which we believe should be handled at the clinical modelling levels (i.e. RM, archetypes and templates). These have to do with the structure and semantics of the clinical information and underpinned by domain knowledge. 1) During our implementation one change request mandated that we should be able to depict certain data items (endoscopic findings) as present|unknown|absent as well as null if nothing has been specified about it. In the work for Nehta on anatomical pathology models Ian followed a similar approach where some findings were expressed as present, absent or indeterminate as far as I remember and this was definitely a repeating pattern. This caused us to look more carefully into the whole thing and we came to a conclusion that not all data items need/can be represented like that. For example it doesn’t really make sense to indicate absence of a drug in patient’s medication list or a medical procedure performed; they are either present and further qualified (i.e. Aspirin 300mg tid or biopsy performed) or not mentioned at all. However clinical findings, as in our case, essentially require to be depicted as unknown or absent explicitly. We have initially thought we could solve the issue by using flavours of null which is defined by openEHR RM for each ELEMENT data item (caution here it is only for ELEMENT) but the problem is that these findings are represented using CLUSTERs not ELEMENTs in our MST Archetypes. This is because we use ELEMENTs under each CLUSTER to depict properties or attributes of those findings such as size, number extent etc. And we cannot represent Absent with flavours of null either. Our workaround in current implementation is that we have inserted to each and every clinical finding CLUSTER a special ELEMENT data item called “Present?” of DV_CODED_TEXT which have the following values: 0>Null, 1>Present, 2>Unknown, 3>Absent. We don’t further specify the reasons of Unknown but using flavours of null would be logical. Even more interesting when nothing is entered on GUI for a clinical finding or when entered but later on it is ‘cleared’ instead of putting value 0 for null we can actually ‘prune’ that particular CLUSTER (and all downstream items); i.e. remove altogether from the value instance. Our solution to this issue was to come up with a GUI Directive called “isCoreConcept”. This instructs our GUI generator to render that item with 3- state checkbox and also hide all its children until a value has been selected. This directive also imposes an implicit precondition that the affected CLUSTER define the special child ELEMENT that denotes "Present?" - otherwise the GUI generator will render the model invalid. Actually when we rethink about this we found out that this particular directive actually is overloaded and has elements of both semantic and presentation information. So we propose to delegate the semantics part to modelling side and use another GUI directive called “hideChildren” (which actually we have also defined before but not used. This directive can then be used for core and non-core concepts. We think this might best be denoted in the RM; either at CLUSTER or ITEM classes. Something like null flavours but not quite the same. Or perhaps a dedicated new class?? That’s up to the discussions. 2) We also saw that some clinical findings can exist alone; i.e. without further qualification or depicting anatomical sites. Example is haemorrhoids where anatomical site is implied and it can just be reported as “haemorrhoids were observed” (can be qualified as internal external or even a grade but the point is it can exist on its own). But when you talk about a tumour you need further description” i.e. site, type, grade etc. It is not a valid clinical expression to say “tumour was present” in an endoscopy report (yes context is important, in some other contexts this expression may well be valid). This indeed was also denoted in openSDE with a GUI directive called “selection requires further description”. To depict standalone findings during archetype design setting the cardinality of CLUSTER to 0..* or 0..n can be used. But currently we cannot set cardinality to 0 for CLUSTER: this is not allowed according to AOM (although in openEhrV1 it's possible to have CLUSTER's with 0 ITEM's as long as it isn't validated by the RmValidator, this isn't considered a desirable usage). The real issue is a bit more tricky and has to do with core semantics: it doesn’t make sense to depict a finding as absent or unknown when qualified by certain attributes. One example is: “Three polyps were observed at ascending colon” there is no point in saying “Three polyps were absent at ...” But this is a perfectly valid (and quite frequently used) expression in endoscopy reporting: “Villous polyps were absent at ascending colon” (here villous is an attribute for type of polyp). Another invalid expression: “3 cm long stenosis was been absent...” So it looks like some qualifiers may change the existence of core concepts – so perhaps we need some means to tag them during modelling. It looks like these are ‘physical’ properties and not ‘man-made’ concepts. Hope this helps to elaborate things... Cheers, -koray & hong yul --- ## Post #59 by @thomas.beale Hi Tom, here is our response: We have so far came across two issues which we believe should be handled at the clinical modelling levels (i.e. RM, archetypes and templates). These have to do with the structure and semantics of the clinical information and underpinned by domain knowledge. 1) During our implementation one change request mandated that we should be able to depict certain data items (endoscopic findings) as present|unknown|absent as well as null if nothing has been specified about it. In the work for Nehta on anatomical pathology models Ian followed a similar approach where some findings were expressed as present, absent or indeterminate as far as I remember and this was definitely a repeating pattern. This caused us to look more carefully into the whole thing and we came to a conclusion that not all data items need/can be represented like that. For example it doesn’t really make sense to indicate absence of a drug in patient’s medication list or a medical procedure performed; they are either present and further qualified (i.e. Aspirin 300mg tid or biopsy performed) or not mentioned at all. However clinical findings, as in our case, essentially require to be depicted as unknown or absent explicitly. We have initially thought we could solve the issue by using flavours of null which is defined by openEHR RM for each ELEMENT data item (caution here it is only for ELEMENT) but the problem is that these findings are represented using CLUSTERs not ELEMENTs in our MST Archetypes. This is because we use ELEMENTs under each CLUSTER to depict properties or attributes of those findings such as size, number extent etc. And we cannot represent Absent with flavours of null either. --- ## Post #60 by @Helma Hi everyone, for those interested, my full thesis is available here: http://www.sourcefusion.nl/thesis/Dissertation-HvdL.pdf A link on the openEHR website to this PDF is appreciated\. Sorry for not participating in the discussion, but my current job has me swamped with work and deadlines\. With regards, Helma van der Linden Thilo Schuler said the following on 13/12/2010 07:20: --- ## Post #61 by @Koray_Atalag Thanks a lot Helma \- lots of reading material for Xmas\! Cheers, \-koray --- ## Post #62 by @thomas.beale > Hi! > > A very interesting discussion, thanks to everybody here! Great with all references too! > > > > Maybe if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems. > > Or perhaps "GUI focused templates" and "Structurally focused templates" (since both will be openEHR based). > > Correct me if I'm wrong: > If templates can specialize templates in several generations of inheritance/specialisation (This is the case, right?), then we could use the same basic annotation formalism for different purposes in different layers, only the annotation names would be different. > > So an example inheritance/specialisation hierarchy in a running system could be: > > A bunch of clinical archetypes (mostly international, and some regional ones) > ...are used as building blocks in... > > a "structural" template (maybe national/regional) often creating a composite SECTION or COMPOSITION > > [add more structural layers if useful] all correct up to here > ...that is then annotated with GUI-hints by... > a set of "GUI templates" with each template fitting a different recurring use case not forgetting that GUI is only one place to deploy a template (e.g. messages etc), so there might be some other kind of 'deployment templates' as well. > ...for a specific GUI, the most fitting of those GUI templates is then picked and might be further annotated/specialized with yet another template layer or used directly as input to GUI-generation or GUI-building tools > > > > you have two choices: > > > > - A) mix it in with the languages & architectural layers you already have > > - B) create a dedicated layer or component type, and possibly dedicated formalism if needed > > I believe there is (as usual) a context dependent gray-zone, not a clear breakpoint, regarding what annotations would be most useful to have in which layer. So, yes I agree layers are good for separation of concerns, but it is not always (at least not at an early stage) easy to forsee exactly what best fits into each layer and how many layers there should be. I agree - we don't yet have a clear list of the GUi semantics that would need to be in a UI template... > If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section? > and if could be reused also for GUI-stuff instead of creating another different formalism, then we should take a close look at that option before thinking of specifying another mechanism for GUI-concerns. You'd still get layers (if you sensibly use specialisation) but more flexible boundaries during the needed upcoming period of collaborative experimentation and real use. > > > > I think having these discussions is a great start. But it'd be great if someone from the core group 'owns' this thread and puts some pressure on us. > > Koray, what makes you exclude yourself from the "core group"? Shouldn't openEHR be a community with peers trying to solve common problems, where people like you with specific implementation experience can help collaboratively lead a specific exploration tangents at least as well as some official "core" that is busy prioritizing other important explorations. Whatever that "core" is I believe it will be actively involved in, and appreciate, the discussions. Erik, is right. There is no special 'core group' like in the old days - these days, it is whoever is here. In terms of ADL/AOM 1.5 specs, I will simply take into account any requirements that are clearly enough documented for me to understand... - thomas --- ## Post #63 by @pablo Hi Thomas, > > Correct me if I'm wrong: > > If templates can specialize templates in several generations of inheritance/specialisation (This is the case, right?), then we could use the same basic annotation formalism for different purposes in different layers, only the annotation names would be different. > > > > So an example inheritance/specialisation hierarchy in a running system could be: > > > > A bunch of clinical archetypes (mostly international, and some regional ones) > > ...are used as building blocks in... > > > > a "structural" template (maybe national/regional) often creating a composite SECTION or COMPOSITION > > > > [add more structural layers if useful] > > all correct up to here > > > ...that is then annotated with GUI-hints by... > > a set of "GUI templates" with each template fitting a different recurring use case > > not forgetting that GUI is only one place to deploy a template (e.g. messages etc), so there might be some other kind of 'deployment templates' as well. > > > ...for a specific GUI, the most fitting of those GUI templates is then picked and might be further annotated/specialized with yet another template layer or used directly as input to GUI-generation or GUI-building tools You describe a very big picture and sounds logic, so we'll have: - Level 1: archetypes (for model complete data sets about a concept, general and specialized ones) - Level 2: structural templates (for localized use of archetypes, general and specialized templates) - Level 3: define the use of the structural templates - GUI Templates: define directives over a couple of Structural Templates to create a graphic representations of some archetyped data. - Message Templates: define directives to structure archetyped data into messages with some syntax (HL7 v2, v3, 13606, CCR, CCD, CDA ...). - Report Templates: create reports with aggregated data and graphic representations like charts. Can be used by GUI Templates. - Information Aggregation Templates: to define data aggregation rules over a set of archetyped data. Can be used by GUI Templates, Report Templates, etc. - Rule Templates: to define rules over a set of archetyped data to check validity, consistency, etc, etc. Can be used by Decision Support Modules, e.g. to check medication reactions. - ... > > If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) > > to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section? I have a couple ideas that can improve what we've done on the EHR-Gen framework. If you want I can put them in the wiki. Cheers, -Pablo. --- ## Post #64 by @grahamegrieve hi Koray Unknown <> Indeterminate\. \(though they overlap\) Generally, this is not really an endoscopy requirement\. I've seen it come up in all sorts of contexts\. \(for instance, the Australias structured pathology reports\)\. Even in the case of a list of medications: you can assert that the patient \*isn't\* taking any medication\. Also, you can assert that you're not sure of the entire list, but you know that the patient is \*not\* taking a medication But it doesn't apply generally \- it's a pattern that varies across particular issues\. Frustratingly, there's no consistency in the way people think, as far as I can tell, and the various coding systems are even more inconsistent than people's thinking \(mainly due to variations in total capture of woolly thinking across issues\) With regard to the proposal to have nullFlavor on cluster, HL7 pretty much does this in v3 \- all associations have a nullFlavor\. But it's a difficult concept \- when you say the association is not a proper value \- which parts of it? It's like negation \- what parts of observed as improper, and what parts properly define the improperness? \(LIke negation \- what's the scope of the negation?\)\. I don't see why the same concern wouldn't apply to a cluster\. It seems to me that this was meant to be solved by having optional clusters with mandatory items\. Because of the variations in the pattern, you sometimes write additional constraints \- like, for instance, you can't observe any features of a carcinoma if the carcinoma is not present\. But usually we don't bother encoding these very obvious things in the models I do think that you have GUI hinting requirements for the template language here\. These are the kind of things our kind\-of\-like\-archetype\-system focuses on: GUI hints in the templating language Grahame --- ## Post #65 by @Koray_Atalag Hi Tom, I’ll try to make a few things clear. I’ll chop off parts of my original message for better readability. ..... However clinical findings, as in our case, essentially require to be depicted as unknown or absent explicitly. We have initially thought we could solve the issue by using flavours of null which is defined by openEHR RM for each ELEMENT data item (caution here it is only for ELEMENT) but the problem is that these findings are represented using CLUSTERs not ELEMENTs in our MST Archetypes. This is because we use ELEMENTs under each CLUSTER to depict properties or attributes of those findings such as size, number extent etc. And we cannot represent Absent with flavours of null either. Koray, I don't get this bit: you are saying you want the effect of flavours of null for whole sub-trees of information? Yes I suggest that we have some means to indicate the presence state of a whole sub-tree with further qualifiers as to why information was not available. I am talking about present (well this is straightforward), absent (there has been an effort to find a certain lesion but it was not there) and unknown/indeterminate (which I think flavours of null can be used to further qualify). I think the absent option can simply be handled by negation of present (as Graeme mentions); but not sure how to do that in openEHR. ..... We think this might best be denoted in the RM; either at CLUSTER or ITEM classes. Something like null flavours but not quite the same. Or perhaps a dedicated new class?? That’s up to the discussions. well moving null flavours to ITEM (meaning CLUSTER and ELEMENT both get it) would not be that hard to do - it has no negative impact on anything. But we have not done any general semantic analysis on this idea... Happy to provide you with more information and help with that if necessary. ..... To depict standalone findings during archetype design setting the cardinality of CLUSTER to 0..* or 0..n can be used. But currently we cannot set cardinality to 0 for CLUSTER: this is not allowed according to AOM (although in openEhrV1 it's possible to have CLUSTER's with 0 ITEM's as long as it isn't validated by the RmValidator, this isn't considered a desirable usage). but you can't record any data in a CLUSTER with no children. If the CLUSTER is named (i.e. has at-code) for 'haemorrhoids' the implication is that something is going to be said about this. The function of this name/code here is as a name, not as a value. Some ways of doing this would be: ELEMENT [haemorrhoids]; value = present This won’t work for us because almost all findings are qualified by attributes and associated by anatomical sites. So it has to be under a cluster as a sub-tree or CLUSTER [haemorrhoids]; CLUSTER -- more complex description of haemorrhoids ELEMENT ELEMENT etc Well close but not exactly. Our modelling approach is: CLUSTER occurrences {0..*} [Tumour] (note that this whole sub-tree can repeat as a whole for defining same finding with a different set of qualifiers) ELEMENT {0..1} [Type] --- values ELEMENT {0..1} [Stage] --- values ELEMENT {0..1} [Extent] --- values ELEMENT {0..*} [Sites] --- values (note that this can be multiple with occurrences set to 0..*) So when we create the ‘value’ instance which is a shadow of the opt we have all parts of the model in place – i.e. all ELEMENTS have null values and obviously CLUSTERS holding them are all instantiated. When use enters data from GUI the widgets are bound to the parts of the instance and values are updated. If a multiple entry has been made then new instances of some subtrees are added to the ‘value’ instance. However when persisting this ‘value’ instance we prune all null sub-trees and then serialise and save. So the point is we never have empty CLUSTERS which we want to store data; but what happens is initially lots of CLUSTERS holding sub-trees are instantiated with all its ELEMENTs with null/default/assumed values. As I explained in order to represent the presence of this sub-tree we insert a special ELEMENT which depicts this presence information to each and every sub-tree. And we then have to hardcode this in our application which makes me uncomfortable. I think it is not good modelling practice to do this manually. Perhaps best way would be not to touch the current data structures but introduce a custom syntax in ADL which will make things easier and more consistent among different implementations. or CLUSTER [features present]; ELEMENT [observed feature]; value = haemorrhoids ELEMENT [observed feature]; value = something else etc Same as first one – won’t work The real issue is a bit more tricky and has to do with core semantics: it doesn’t make sense to depict a finding as absent or unknown when qualified by certain attributes. .... ok, so absence / negation is a common requirement in endoscopy... That is the current requirement for us but I think this applies equally to many other domains in clinical medicine. So it looks like some qualifiers may change the existence of core concepts – so perhaps we need some means to tag them during modelling. It looks like these are ‘physical’ properties and not ‘man-made’ concepts. I think you mean that the possibility of reporting absence (when it can make sense) depends on the morphological feature? Good point – have to dig further into the morphological features and check to see if there are any exceptions though. -koray --- ## Post #66 by @Hugh_Leslie1 Hi Tom, here is our response: We have so far came across two issues which we believe should be handled at the clinical modelling levels (i.e. RM, archetypes and templates). These have to do with the structure and semantics of the clinical information and underpinned by domain knowledge. --- ## Post #67 by @thomas.beale > Hi Koray > > One way that we are handling this kind of issue is with a separate exclusion archetype. So for adverse reactions for instance, if you want to say that this person has no known allergies, you use a separate archetype called an exclusion archetype. For data, this has the advantage of enabling an easy query for "no allergies" rather than pulling up an adverse reaction instance and having to look inside it for "no allergies". This works for many different types of content and means that you don't have to hack archetypes to try to add the negative. So in your use case, you could have a specific "No polyps" exclusion archetype which models the location. > > This is a common clinical pattern and problem. > > regards Hugh I think the problem here is that the need for expressing exclusion is at a fine grain level, i.e. it is not an exclusion of a whole-of-patient condition or sign or symptom, but a sign (I guess that's what polyps etc are) or its absence within a physical examination that looks at all sorts of things. I would have guessed (I know this is naive - Koray has spent years on these models and it is some time since I saw them!) that 'absence', 'indeterminate' etc would be possible values among other sets of values indicating presence. E.g. following your scheme Koray, I would expect to see another ELEMENT: CLUSTER occurrences {0..*} [Tumour] (note that this whole sub-tree can repeat as a whole for defining same finding with a different set of qualifiers) > **ELEMENT {0..1} [Presence] --- DV_ORDINAL : present, absent, ... other values?** > ELEMENT {0..1} [Type] --- values > ELEMENT {0..1} [Stage] --- value > ELEMENT {0..1} [Extent] --- values > ELEMENT {0..*} [Sites] --- values (note that this can be multiple with occurrences set to 0..*) This means that any feature can be recorded as absent within the same structure as the existing data. I imagine you must have thought about this and have a reason for not doing it.... but I don't know what it is at this stage... - thomas --- ## Post #68 by @ian.mcnicoll Hi Hugh, The Exclusion archetype makes sense at a diagnosis or procedure level but does not work well for detailed clinical findings\. In the case of the pathology archetypes it would result in the creation of scores of Exclusion archetypes and umanageable templates\. The problem Koray raises is actually quite complex and difficult\. 1\. There is crossover with the more generic problem of questionnaire type constructs which run counter to Clinical Statement type expressions e\.g\. \(Name\) 'Polyps present" =Y/N \(value\) as opposed to \(Name\) 'Polyp findings' = Polyps present/ polyps absent \(value\) 2\. The handling of indeterminate/equivocal responses which is handled specifically in Snomed and by possibly by Null flavours in HL7/openEHR, though this can be difficult to acheive reliably e\.g Some path models have both indeterminate AND equivocal\. Others have more nuanced values etc\. My policy when constructing the path archetypes was to model 'nulls' explicitly as Koray has done\. This is frustrating and cumbersome but does make Snomed mapping much easier\. 3\. Koray is also identifying a need for a conditional statement which effectively switches on /off mandation for child elements\. I understand Graham's point that this requirement is often pretty apparent from the model but it is an other aspect of domain clinical knowledge which should be captured, even if the condiitonal expression is too complex for a computable formalism and is expressed textually\. 4\. There is a related problem that I have identified from working with detailed findings\. Quite often the initial requirement is just for a simple Present/Absent or Normal/Abnormal element e\.g Polyps Y/N\. However from experience we know that there is a strong possibility that this simple requirement is likely to expand to require a Cluster with far more detail\. We are faced with a dilemma as whether we model as a simple element , which keeps the current expression clean and simple, or whether we immediately use a cluster which adds some \(for now\) unnecessary complexity\. When thinking about this , it struck me that there may be a place for specifically supporting the detailed clinical finding to allow more natural expansion of the content without disturbing subsequent archetype paths\. Furthermore, this seemed also to have relevance to work on aligning with Snomed post\-coordination\. I wish I could have claimed to have solved the problem but so far all that has emerged are pages of scribbled notes\. My suggestion is that the 'Detailed Clinical finding' i\.e\. sub\-Entry is a challenge which perhaps needs some fresh thinking, perhaps in combination with Snomed post\-coordination work and addressing the Questionnaire conundrum\. Ian Dr Ian McNicoll office / fax \+44\(0\)1536 414994 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www\.phcsg\.org --- ## Post #69 by @Koray_Atalag Hi Tom, yes you nailed it...Actually this is exactly what we do at the moment but uncomfortable with this approach. I think it’d be great if the formalism handles this common pattern without such a workaround which is repeating all over. Cheers, -koray --- ## Post #70 by @thomas.beale Hi Tom, yes you nailed it...Actually this is exactly what we do at the moment but uncomfortable with this approach. I think it’d be great if the formalism handles this common pattern without such a workaround which is repeating all over. Cheers, --- ## Post #71 by @Koray_Atalag Hi Tom, I agree that the this is best way how to ‘represent’ data technically. But what I suggest is, since this is a universal and repeating pattern for all clinical findings (and maybe more) can’t we have an extension in ADL such that we ‘tag’ a certain sub-tree and then this node is inserted into ADL source automatically. And the way we write queries and process that would be uniform and convenient. Cheers, -koray --- ## Post #72 by @thomas.beale Hi Tom, I agree that the this is best way how to ‘represent’ data technically. But what I suggest is, since this is a universal and repeating pattern for all clinical findings (and maybe more) can’t we have an extension in ADL such that we ‘tag’ a certain sub-tree and then this node is inserted into ADL source automatically. And the way we write queries and process that would be uniform and convenient. Cheers, --- ## Post #73 by @system Hi Tom, I agree that the this is best way how to ‘represent’ data technically. But what I suggest is, since this is a universal and repeating pattern for all clinical findings (and maybe more) can’t we have an extension in ADL such that we ‘tag’ a certain sub-tree and then this node is inserted into ADL source automatically. And the way we write queries and process that would be uniform and convenient. Cheers, --- ## Post #74 by @thomas.beale > Hi Thomas, > > > ... > > You describe a very big picture and sounds logic, so we'll have: > > - Level 1: archetypes (for model complete data sets about a concept, general and specialized ones) > - Level 2: structural templates (for localized use of archetypes, general and specialized templates) > - Level 3: define the use of the structural templates > - GUI Templates: define directives over a couple of Structural Templates to create a graphic representations of some archetyped data. > > - Message Templates: define directives to structure archetyped data into messages with some syntax (HL7 v2, v3, 13606, CCR, CCD, CDA ...). to do non-openEHR message syntaxes, it requires not just another 'template' (in fact, not much be needed here), but a transformation from the operational template (OPT) form to the target form, e.g. CCR XSD or whatever. > - Report Templates: create reports with aggregated data and graphic representations like charts. Can be used by GUI Templates. > > - Information Aggregation Templates: to define data aggregation rules over a set of archetyped data. Can be used by GUI Templates, Report Templates, etc. > > - Rule Templates: to define rules over a set of archetyped data to check validity, consistency, etc, etc. Can be used by Decision Support Modules, e.g. to check medication reactions. > > - ... I am not sure what some of these would look like, but I suspect they will come into existence one day... > > > If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) > > > > to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section? > > I have a couple ideas that can improve what we've done on the EHR-Gen framework. If you want I can put them in the wiki. please do that - thomas --- ## Post #75 by @ian.mcnicoll Hi Sam/ Thomas, I am tending to Koray's side here\. There is a pattern which starts with a Question and leads to increasing but unpredictable levels of detail\. We can, of course represent any pattern with clusters and elements but I have the feeling that there are some aspects that, if supported within the RM, might make for more consistent and more easily extended archetypes as new use cases emerge\. There is also overlap with the SNOMED findings concept model\. I come across these sort of issues fairly frequently when modelling fairly detailed application\-focused dialogs and I am conscious that the archetypes seem more clumsy and less naturally extensible than should be necessary\. This is probably a dumb, unworkable idea but something like a boolean Y/N element which 'hides' its true semantics as Present/Absent, and can conditionally become a container, would solve several problems and considerably visually simplify a lot of archetypes\. If we can make some progress here we will make it much easier to align with post\-coordinated SNOMED terms \(and make the use of archetypes to define these patterns compelling\. I can see the argument that we can get tools to support these identified patterns but this is tricky unless we can annotate the models as definitely needing the pattern handling to be enabled i\.e\. just because a set of nodes follows a pattern does not necessarily mean that it should be handled in the tool as such\. As an example there is currently the typical 'pizza menu' pattern, where the sensible view in tooling and GUI is to use a multiple checkbox list but this may not always be the case\. i\.e the pattern is accidental\. The only way to control this is to annotate the ADL with some kind of directive, as Koray has done\. Perhaps Koray and I should be funded to go and think this out for 3 months \.\. the Bahamas might be conducive\.;\-\) Ian Dr Ian McNicoll office / fax \+44\(0\)1536 414994 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www\.phcsg\.org --- ## Post #76 by @Koray_Atalag Hi, I don’t mean to be too pushy on this but I think we are not really on the same grounds at the moment. I’ll try to summarise my points: - Re universality I agree with you as you describe but I have indicated that this pattern is unique to certain type of observations; so perhaps I shouldn’t have used the term universal but ‘common’ in many types of clinical findings as a result of some examination. The exclusions you give by examples are very appropriate. - It is perfectly possible, and indeed during the diagnosis of acute appendicitis essential, to denote absence of lump or “lack of rebound reflex” is almost common expression and pathognomonic to the disease. So I don’t agree with you and my gut feeling is that all findings during physical examination may well be reported as absent. - Yes I’d be also very interested to identify and classify if possible which ones – but again my gut feeling is that this may not be possible and that relies on the clinical context and semantics. Therefore instead of identifying these at the outset I think giving the modellers a method to tag these will be the pragmatic solution and enable consistency among modellers and implementations. - Re design patterns and tooling support – I think this should be in place in any case. But as Ian has pointed out there is more to the problem than convenience for modellers. The problem is consistency among modellers and mode critically when these models need to evolve (which is almost guaranteed) then how to avoid changes in paths…i.e. many ELEMENTs will need to be converted to CLUSTERS. Conversely if you anticipate this and design accordingly you might end up having zillion of unnecessary CLUSTERS with single ELEMENTs… Hey Ian! I liked your proposal…Never been to Bahamas Cheers, -koray --- ## Post #77 by @pablo > > > Hi Thomas, > > > > > ... > > > > You describe a very big picture and sounds logic, so we'll have: > > > > - Level 1: archetypes (for model complete data sets about a concept, general and specialized ones) > > - Level 2: structural templates (for localized use of archetypes, general and specialized templates) > > - Level 3: define the use of the structural templates > > - GUI Templates: define directives over a couple of Structural Templates to create a graphic representations of some archetyped data. > > > > - Message Templates: define directives to structure archetyped data into messages with some syntax (HL7 v2, v3, 13606, CCR, CCD, CDA ...). > > to do non-openEHR message syntaxes, it requires not just another 'template' (in fact, not much be needed here), but a transformation from the operational template (OPT) form to the target form, e.g. CCR XSD or whatever. Doing futurology here, we could have these mapping rules defined inside the Message Templates, or may be just referencing wich tranformation to use (the output syntax) will suffice. But I'm not sure what will be the inside of one of these templates. > > - Report Templates: create reports with aggregated data and graphic representations like charts. Can be used by GUI Templates. > > > > - Information Aggregation Templates: to define data aggregation rules over a set of archetyped data. Can be used by GUI Templates, Report Templates, etc. > > > > - Rule Templates: to define rules over a set of archetyped data to check validity, consistency, etc, etc. Can be used by Decision Support Modules, e.g. to check medication reactions. > > > > - ... > > I am not sure what some of these would look like, but I suspect they will come into existence one day... I'm not sure neither, but I'm sure these templates will be part of any openEHR-based EHR. -Pablo. --- ## Post #78 by @thomas.beale > ``` > Hi Sam/ Thomas, > > I am tending to Koray's side here. > > There is a pattern which starts with a Question and leads to > increasing but unpredictable levels of detail. We can, of course > represent any pattern with clusters and elements but I have the > feeling that there are some aspects that, if supported within the RM, > might make for more consistent and more easily extended archetypes as > new use cases emerge. There is also overlap with the SNOMED findings > concept model. I come across these sort of issues fairly frequently > when modelling fairly detailed application-focused dialogs and I am > conscious that the archetypes seem more clumsy and less naturally > extensible than should be necessary. > > This is probably a dumb, unworkable idea but something like a boolean > Y/N element which 'hides' its true semantics as Present/Absent, and > can conditionally become a container, would solve several problems and > considerably visually simplify a lot of archetypes. > > ``` Technically this could be done by a special kind of CLUSTER that also acted as an ELEMENT at the same time, i.e. a CLUSTER with a value & null_flavour, just like an ELEMENT has in today's RM. This would allow it to be treated as an ELEMENT if no children, and as a CLUSTER if there were children. This special node type really would be for this purpose, i.e. where you want to report either absent, and no further detail, or present, with further detail. But I am still pretty sure this is not universal for al Observations, only for some kinds of physical exam and maybe some other specific finding types. The argument against this is that it is putting a subtle new class type into the RM, that only applies to some kinds of data (ok, ..) but now needs special processing in all of the software built on openEHR. If we stick with today's model, we have more generic software, but some tools have to work harder to recognise this (and other) patterns. > ``` > > Perhaps Koray and I should be funded to go and think this out for 3 > months .. the Bahamas might be conducive.;-) > > ``` I am pretty sure you can't work it out without me there ... I'll go pack - thomas --- ## Post #79 by @system I can be iconoclasti here, But it seems to be it has more to do with terminology than structure.... --- ## Post #80 by @Stef_Verlinden1 Hi All, --- ## Post #81 by @system Hi\! >> If the already present annotation mechanism in templates is powerful enough \(Do you think it is, Koray, Pablo and others?\) > > to be clear, do you mean the annotations documented in the ADL 1\.5 draft document? I\.e\. the new annotations section? Yes, I was then thinking of section 9\.8 in http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf When looking closer at this for GUI hint experimentation, perhaps we could instead use a combination of annotations and the assertion/rule mechanisms in ADL/AOM? The already present logic in the assertions mechanism is probably enough to define e\.g\. Boolean trigger variables\. Annotations could then be used to let GUIs know what to do/show/hide based on those triggers\. Discussion examples follow \(with the risk of ADL errors that Tom's brain\-integrated ADL parser :\-\) will catch and he then can correct\) In section 6\.5\.4 of http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf a way of defining variables is specified\. Perhaps a \(preferably Boolean\) variable could be defined as an archetype rule like\.\.\. $smoker:BOOLEAN ::= /data/items\[at0003\.7\]/items\[at0009\.3\]/value/defining\_code matches local::at0013 \.\.\.and an annotation on a tree structure that should be shown in GUIs only when documenting smokers could be\.\.\. annotations = < \["/data/items\[at0003\.7\]/items\[at0010\]"\] = <     items = <       \["GUI\-show\-if"\] = <"$smoker"> \-\- Other annotation name examples: GUI\-hide\-if \.\.\.       \["some other annotation"\] = <"whatever"> \.\.\.or perhaps\.\.\. annotations = < \["/data/items\[at0003\.7\]/items\[at0010\]"\] = <     items = <       \["GUI\-trigger"\] = <"$smoker">       \["GUI\-action"\] = <"show"> \-\- Other annotation value examples: hide, collapse, expand       \["some other annotation"\] = <"whatever"> I guess the mess starts if such annotations are to be overridden in yet a specialization generation of the GUI\-annotated template/archetype\. That would have to be analyzed further, but maybe some refined variant of the examples above could be a useful start in the mean time? Best regards, Erik Sundvall erik\.sundvall@liu\.se http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-286733 >> you have two choices: >> >> A\) mix it in with the languages & architectural layers you already have >> B\) create a dedicated layer or component type, and possibly dedicated formalism if needed > Erik Sundvall wrote: > I believe there is \(as usual\) a context dependent gray\-zone, not a clear breakpoint, regarding what annotations would be most useful to have in which layer\. So, yes I agree layers are good for separation of concerns, but it is not always \(at least not at an early stage\) easy to forsee exactly what best fits into each layer and how many layers there should be\. Thomas Beale wrote: --- ## Post #82 by @thomas.beale > Hi\! > >>> If the already present annotation mechanism in templates is powerful enough \(Do you think it is, Koray, Pablo and others?\) >> >> to be clear, do you mean the annotations documented in the ADL 1\.5 draft document? I\.e\. the new annotations section? > > Yes, I was then thinking of section 9\.8 in > http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf > > When looking closer at this for GUI hint experimentation, perhaps we > could instead use a combination of annotations and the assertion/rule > mechanisms in ADL/AOM? The already present logic in the assertions > mechanism is probably enough to define e\.g\. Boolean trigger variables\. > Annotations could then be used to let GUIs know what to do/show/hide > based on those triggers\. I will have annotations implemented in the next few days, with some test archetypes\. We will put a release up in hopefully < 10 days, and people can play\. BTW: the current draft online is incorrect: it misses a language level in the annotations structure \(i\.e\. annotations are linguistic entities so they need to be defined under a specified language just like terms on the ontology section\)\. The structure I implement will also be put online\. Then all requests for change will be considered ;\-\) I have to beef up the implementation of the invariant \(now called rules\) section; then we can try to implement this example below\.\.\. \- thomas --- ## Post #83 by @pablo Hi Thomas, It's been a while. I've added some thoughs on GUI directives to improve our Open EHR-Gen GUI Templates. It may help to create something more generic than an improvement to our templates. http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates My grain of sand. --- **Canonical:** https://discourse.openehr.org/t/gui-directives-hints-again-was-developing-usable-guis/15029 **Original content:** https://discourse.openehr.org/t/gui-directives-hints-again-was-developing-usable-guis/15029