Hidden reference model stuff in template
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: 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
Hidden reference model stuff in template
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070530/6545ab25/attachment.html
Hidden reference model stuff in template
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)
Hidden reference model stuff in template
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 ID945c2617- 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 Op 31-mei-2007, om 1:50 heeft Thilo Schuler het volgende geschreven: 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
Hidden reference model stuff in template
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: Van: Stef Verlinden stef at vivici.nl Datum: 24 mei 2007 12:00:43 GMT+02:00 Aan: For openEHR clinical discussions openehr-clinical at openehr.org Onderwerp: Antw.: Point in time 2 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. 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. But here again, this XML message comprises only the classes that are created in the archetype but not the 'hidden' stuff. 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? Cheers, Stef Op 23-mei-2007, om 7:01 heeft Thomas Beale het volgende geschreven: Erik Sundvall wrote: Hi! On 5/22/07, Heather Leslie heather.leslie at oceaninformatics.biz wrote: Perhaps the apparently 'hidden' reference model stuff should perhaps even be displayed, in an uneditable format, in the Archetype Editor and Template Designer - to make this design process more transparent and help bridge the clinical/technical divide just a little. This very much matches my point of view. Ideally archetype editors etc should be delivered with a built in mini-EHR system for simple testing purposes (security, scalability etc would not be in focus then). I think such a solution will come from somewhere eventually. I'd love provide something like that in the LiU Archetype Editor. I wish we had enough time and resources to implement that, currently we have to focus on other more urgent things. We do have engineering students doing master thesis work around openEHR-based GUIs though and with some luck that might provide some parts of the suggested solution. I agree that we need this kind of functionality; it will be implemented fairly soon in the ADL workbench and Archetype Editor. - thomas ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070530/1b36b5e5/attachment.html
