# Hidden reference model stuff in template **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2007-05-30 09:35 UTC **Views:** 2 **Replies:** 4 **URL:** https://discourse.openehr.org/t/hidden-reference-model-stuff-in-template/14423 --- ## Post #1 by @Stef_Verlinden1 Maybe this question should be asked on the technical mailing list, since there's no reaction on the clinical list:-) Cheers, Stef Begin doorgestuurd bericht: --- ## Post #2 by @Sam Hi Stef > Great. Does this also mean that this 'hidden' reference model stuff will/can be a part of a template? From my point of view I would like to 'control' (view and/or enter) thing as date/time of measurement via a template. This would always be available for data entry. It is not sensible to constrain this in an archetype (fixed for every data instance) > Another question related to that. The way I think to understand it (as a non-technical person:-) ) we can use the XML message's created by the archetype editor to display and post data to and from a UI/website. The XML instances that conform to the archetype - we can use the archetype id and paths to describe layout of instances and as a basis for queries - but all data are an instance of the reference model schema (which conform to one or more archetypes). > But here again, this XML message comprises only the classes that are created in the archetype but not the 'hidden' stuff. No - the hidden attributes are in the data (unless they are optional and not populated) > Is there an 'overhead' XML message in which the 'specific' AT XML message can be embedded/nested so one has access to all available data? The kernel creates the instance according to the reference model - and conforms to the archetype specification. All reference model attributes are available unless constrained out by an archetype (of which I know of no instance so far - we tend to do that in templates). Cheers, Sam --- ## Post #3 by @Thilo_Schuler1 Hi Stef, I have followed the thread and I will try to provide some hopefully useful hints\. I will start with the central idea, the two\-model\-approach, and will try to cover your questions after that: \- Archetypes are a way of constraining and "plug\-and\-playing" \(LEGO principle\) a relatively limited number of generic reference model classes of the reference model, that are expected to stay stable over a long period of time\. In that way the multitude of quickly changing medical concepts \(the medical knowledge\) can be expressed and adapted to the current needs, while the building blocks \(the reference model classes\) stay the same\. One big advantage of this approach is that software can be developed based on the reference model without knowing the archetypes in advance \(future proof systems\)\. \- Analogy: Reference model classes are the LEGO bricks, Archetypes are the LEGO construction plans \- The constraining rules \("grammar"\) of \*all\* archetypes \(or more precisely archetype instances\) are defined in the archetype model\. That is where the name two\-model\-approach came from: firstly the reference model and secondly the archetype model\. \- Every archetype \(e\.g\. for blood pressure\) is an instance of the archetype model\. There could be many notations invented to express this archetype model\. They only have to support the full semantics of the archetype model\. Of all the theoretically possible notations the archetype editor currently supports ADL and can also transform the archetype into an XML version\. \- Every piece of medical information \(the blood pressure values of person X in simple case\) is a "bundle" of several reference class instances with the attributes set to certain values \(to reflect the state of the patient X\)\. The archetype or a combination of archetypes define\(s\) which classes, how many of them and what combination are in the bundle\. Further more it can define things like value ranges for reference class attributes\. Like archetyeps hese bundles could also be expressed in several formats, but today mostly XML is used \(this is meant when Sam talks about data\)\. \- So don't confuse an XML data "bundle" \(validated by the reference model schema\) with an archetype expressed in XML\. \- In a message etc you would send the XML data NOT \(\!\) the XML archetype that the archetype editor can output\. Although there are references to the archetypes \(that where used during creating\) in the data\. So the receiving system of the message can also retrieve the archetypes from an archetype server to add meaning to the data\. \- An archetype can validate \(during creation or after reception\) that a data bundle conforms to the concept that the archetype describes\. So an archetype is a "schema" of a particular medical concept\. Actually the XML schema language was evaluated as a means of expressing archetypes but was found to be not expressive enough\. Therefore ADL has been invented\. \- As it was mentioned before \(and as you correctly named "hidden" reference model stuff\) archetypes only contain the constraints on the reference model which FURTHER constrain what is "automatically" by the reference modle\. So if the a reference model class has an attribute of a date type and the archetype doesn't have a further constraint on it, any valid date could go in there\. In the archetype you could further constrain that only dates from e\.g\. 9\.9\.1999 onwards are valid for that attribute in this context\. \- The template specification is not released yet, so I could be wrong\. But from what I understand templates further constrain and bundle several archetypes to fit a certain organisations data entry needs\. In contrast archetypes are mainly designed for interoperability reasons i\.e\. share common meaning \(So archetypes are purposely designed on a higher level to reflect a sensible "common denominator" of a concept\. A common misunderstanding is that archetypes do what templates are thought for\. E\.g\. if a coded term in an archetype has to interchangeable codes associated with it \- like one SNOMED and one LOINC \- the template could preselect always the LOINC one because organisation has no SNOMED license\. \- Still, if all dates are allowed a template wouldn't constrain \(and therefore wouldn't mention\) a reference model date attribute either\. So a GUI designer would have to know the used archetypes and the referenced reference model classes including attributes to sensibly create the GUI\. Hope this was of any help, Thilo \(openEHR informed medical student\) --- ## Post #4 by @Stef_Verlinden1 Hi Thio, Thanks for this excellent explanation\. Although it remains a steep learning curve for a 'non\-technical' person, it certainly provides a better insight in this 'tough' material\. One last remark to explain my question\. I while ago Thomas Beale demonstrated the OI template builder, which is a really great tool\. From what I understood this template builder also can be used as a GUI designer and that's where my interest lies\. Thing is that templates, as you stated, further constrain and bundle several archetypes to fit a certain organisations data entry needs\. My point is that since the 'hidden classes' aren't present in the originating archetype\(s\), there also aren't present in a GUI constructed with this template builder\. Therefore such a GUI lacks certain 'essential' data entry classes/fields \(for instance 'date and time of measurement\)\. You can also see this in the 'example templates' made for/by the NHS\- UK and which can be found in the dev\-uk\-nhs part of the archetype database\. So if you look for instance at the 'bloodpressure template \(Archetype Id openEHR\-EHR\-OBSERVATION\.blood\_pressure\.v1 Template ID 945c2617\- dc89\-4c28\-94cf\-43ee46c1ecb0\), you'll only see the data classes/fields which where archetyped but none of the 'hidden' data classes/field \(such date/time of measurement but also performer of committer\)\. These are typical examples of data I would like to present in and/or enter via a GUI\. So I guess a template builder isn't suitable for creating GUI's after all \(or I've misunderstood this in the first place\)\. Thanks again, Stef --- ## Post #5 by @Thilo_Schuler1 Hello all, I don't know the OI template editor yet, so I can't make any statement about its capabilities\. I just had a look at the template section in the dev\-uk\-nhs part of the archetype repository\. It shows form\-like html views of templates\. I assume that they have been created to make it easier for clinicians as us to picture the end result of such a template in use\. But as you mentioned, and as acknowledged by Heather, Erik and Thomas, it would be better to display the hidden fields as well in some way\. I am in favorite of Erik's idea of a lean ehr test system\. most conveniently already included in the archetype/template editor\. That would make such issues more clear and would also be advertisement for the IMO brilliant openEHR concept\. Interested \(clinical\) people could fairly easily experience the power of openEHR without having to get into technical details\. Developers could look at the code and would probably quickly get what components are necessary to build an openEHR based system \(the often mentioned "kernel" plays \- as the name suggests \- in central role by implementing both the reference model and the archetype object model and thus allowing things like archetype based object creation\)\. For both the clinicians and the developers this lean but functional ehr system would big a great incentive to use openEHR despite the sometimes admittedly steep learning curve\. Stef, looking at the NHS stuff especially the tabular version provides many examples of what I have written in my last post\. You see that a e\.g\. a composition template contains many archetypes in a nested fashion that can be further constraint if needed\. It also shows what you have been saying: It starts with an element called "other\_context"\. The composition class from the reference model adds context attributes that are fixed \(can't be archetyped\) to fulfill e\.g\. legal requirements\. The "tdl" directory in the NHS part of the archetype directory is empty as there hasn't been a formal specification for templates released yet\. Regarding GUIs templates are not enough to specify the form fields of a GUI but it could be the input into a GUI generator component\. The generator would probably interact with the "kernel" to build an in memory tree reference model object tree by traversing the template and its nested archetypes recursively\. This tree would include all the rules/constraints from the nested archetypes \(sometimes replaced by "stricter" ones from the template\)\. During traversal every time an archetype reference is encountered it has to be retrieved from an archetype server\. Every time an reference model node is encountered this class will be instantiated \(archetype based object creation\)\. If the form\(s\) stay\(s\) always the same the number of templates/archetypes is limited\. In such a case a GUI can also be hardcoded by linking the fields to the leaf nodes in the object tree within the kernel\. The kernel would then validate the input data according to the underlying archetypes\. Obviously the developer of the GUI needs knowledge about the archetype\(s\) and the used reference model classes in order to know what fields to include in the GUI\. Some leaf nodes could also by populated invisibly by the system without any input fields filled in by the user e\.g\. when hitting the send button the committal time stamp would be created automatically by the system and stored in the appropriate context attribute of the composition reference model class\. Still the developer would have to be aware of and implement such things in the code\. At the end of this post I would like to re\-stress the importance of a lean EHR system proposed by Erik\. For the reasons mentioned above, we \- the openEHR community \- should give this goal a high priority\. Through the great and ongoing work by Rong et al \(Java implementation project\) the essential kernel component already exists\. Let's use it to get a simple but functional openEHR system up and running soon\. Cheers, Thilo Stef Verlinden schrieb: --- **Canonical:** https://discourse.openehr.org/t/hidden-reference-model-stuff-in-template/14423 **Original content:** https://discourse.openehr.org/t/hidden-reference-model-stuff-in-template/14423