# CCR and openehr **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2007-02-20 03:07 UTC **Views:** 5 **Replies:** 29 **URL:** https://discourse.openehr.org/t/ccr-and-openehr/14625 --- ## Post #1 by @Andrew_Patterson Has anyone looked at making an openehr composition archetype\(s\) corresponding to the ASTM continuity of care record \(CCR\)? I don't have access to the ASTM standard but I was just looking at the HL7 document describing how CCR maps into CDAr2 and was thinking that it would be a good test of the power/generality of the openehr RM to see if similar could be done for it\. \(I realise that CCR has its own specific adhoc XML schema that are incompatible with the openehr RM, but at some higher level it has content sections/actors etc that are captured and it would be interesting to see how close the openehr models can go to capturing that same information\) Andrew --- ## Post #2 by @Brett_Esler I bet you can\.\.\.even better implement one that is compatible with CDAr2 CCR implementation; they have some implementation guides with detail; CDA is supposedly mappable to a composition any way ;\) \(ask Heath Frankel and Dipak Kalra, or Sam\)\.\. Then go sell the idea to the NHS for mega$$ --- ## Post #3 by @Heath_Frankel Andrew, The CCR would not be implemented as a composition archetype but as a template\. Obviously there will be a composition archetype required and several section archetypes but they would not be specifically designed for CCR\. The same archetypes should be able to be used in Australia \(HealthConnect/NEHTA Discharge Summaries\), UK, NZ, etc\. The CCR template will ensure it reflects the requirements of the CCR data model\. Most of these archetypes already exist in some sense but it would certainly be useful piece of work to ensure all the CCR requirements are supported in the various archetypes as the CCR is really not anything different to HealthConnect Event Summaries or UK equivalents\. This might be done as part of the Detailed Clinical Modelling work that is being done in the US\. Even though it would be relatively simple to construct a CCR from these existing archetypes into a single composition, openEHR is designed to be more intelligent in its representation of data that is copied into Discharge Summaries from existing documents such as Lab Reports, Prescriptions, Problem List and Referrals\. By using LINKs from the Discharge Summary composition to these existing items in the EHR, your able to manage the duplication of EHR content which is commonly copied into Discharge Summaries and Referrals\. Using this approach, the Discharge Summary or Referral composition becomes relatively small document containing only actually created at the time of creating the composition such as the letter and LINKs to the existing documents, which is committed and communicated to the intended recipient as an EHR Extract containing the Discharge/Referral composition and the associated compositions that are LINK targets in the Discharge/Referral composition\. Ocean is currently working on the details of this representation using the NEHTA Discharge Summary Template specification which is more detailed than the CCR\. Even though the representation of the Discharge Summary in openEHR is a collection of LINKed content rather than a single document, it is expected to be able to produce a CDAr2 equivalent of the openEHR composition for communication purposes, but of course you lose the advantages provided by openEHR\. Regards Heath Heath Frankel Product Development Manager Ocean Informatics --- ## Post #4 by @Andrew_Patterson > The CCR would not be implemented as a composition archetype but as a > template\. Some of us haven't seen the template spec which makes it hard to see where the line between openehr archetypes and openehr templates lies\. > Obviously there will be a composition archetype required and > several section archetypes but they would not be specifically designed for > CCR\. The same archetypes should be able to be used in Australia > \(HealthConnect/NEHTA Discharge Summaries\), UK, NZ, etc\. The CCR template > will ensure it reflects the requirements of the CCR data model\. I understand how a template introduces further constraints on the allowable data \- but I don't see exactly where it stops being data we would 'archetype' and becomes data that would be 'templated'\. Surely there would be openEHR\-EHR\-COMPOSITION\.ccr\.adl which enumerates the allowable sections \(perhaps these might be a common archetype such as openEHR\-EHR\-SECTION\-findings\), but more likely would be CCR specific sections \(openEHR\-EHR\-SECTION\-ccradvancedirectives\)\. At the lower levels, the CCR sections could refer to shared ENTRY archetypes, or LINK's as suggested in your email\. Where specifically does templating come in? I know the spec isn't published but we could we see a snippet of how a template might work in this case? Can I also make a plea here \- given that the openehr template spec hasn't been released yet, is it too late to rename 'templates'? openEHR has staked out the word 'archetype' pretty well \(enough that even though it is a generic concept it is clearly associated with the openehr approach\) \- now HL7 will be creating a 'template' spec in order to do 'archetyping' \(with a template being at a similar level as an openehr archetype\)\. Simultaneously, openehr will be releasing a 'templating' spec, which is some concept that is distinct from an openehr archetype and yet also distinct from the HL7 artifact of the same name? English is a big language \- can't we find find enough different words for these things to avoid confusion? If they are essentially the same thing, then fine, but we had better be confident that they really are exactly the same concept\.\. Brett, can you get HL7 to rename the templates group? \(actually I just found a document called templates\_and\_archetypes\.pdf on the openehr site written by Sam, Gerard etal which kind of explains it all but I'm not sure everyone is still using the terms in the way that was proposed in that document\.\. all I know is that I'm still confused\! :\-\) \) Andrew --- ## Post #5 by @Heath_Frankel Andrew, I understand the limitation of no specifications for templates\. Archetypes are more than data structures, they are semantic structures\. A CCR is a data structure defined by a particular organisation but has no true semantics in health, where as a discharge or referral is a common concept\. So you have an archetype of discharge \(or referral depending on the semantics of the CCR\)\. If we had archetypes for every data structure developed by an organisation we would have millions of archetypes and no semantic interoperability\. This is how Templates play their role, it allows an organisation like ASTM to use existing archetypes and specify their own data structures with relation to the semantic of those archetypes\. Also, HL7 Templates and openEHR templates are actually conceptually the same, they both aggregate and further constrain existing model artefacts\. In openEHR the model artefacts are the openEHR RM and archetypes and in HL7 they are the RIM and RMIMs\. It is the Archetype term that is confusingly used in the HL7 world because there is no real concept of building new concepts from the RIM as the HL7 methodology is all about constraint\. You never create an archetype in HL7, the archetypes are already defined in the RIM\. So the HL7 Template spec is not for archetyping, it is for templating\. BTW, CCR is relatively limited in structure below the section level, it defines the sections and the kind of entries allowed in each section but not the structure of the entry\. The HL7 CCD have gone one step further and defined some structure to particular entries like Medication and Problems but it is still limited\. This is why the NEHTA Discharge Summary is more detailed even though they are abstract specs and don't yet have an implementation technology specification\. Heath --- ## Post #6 by @ognian.pishev The reason why it is important to distinguish between archetypes and templates is to why we insist on the separation between the design and implementation spaces\. Archetypes as clinical model exist independent of their potential use\. Templates are the visual forms created for particular applications\. Thus it would be possible to create different versions serving the same purpose \- in this case the visual representation of a CCR form\. Ogi Pishev --- ## Post #7 by @Andrew_Patterson > implementation spaces\. Archetypes as clinical model exist independent of > their potential use\. Templates are the visual forms created for particular > applications\. Thus it would be possible to create different versions serving > the same purpose \- in this case the visual representation of a CCR form\. Is this all that templates are though? If the distinction is purely that templates are a method for specifying the user interface aspects of archetyped data \(i\.e\. this should be a combobox pick list etc\) then that is a distinction I can understand\. However, the CCR is not a specification of a particular 'interface' or even 'form'\. Its a clinical model of data that needs to be recorded \- exactly the type of thing I would think would be archetyped first and foremost \(obviously if someone wanted to specify a 'user interface' in some standard they could do that \- but I would think the primary artifacts that would be released by standards bodies, NHS etc would be archetypes \- vendors can work out interfaces on their own can't they?\) Andrew --- ## Post #8 by @system My try. Archetypes: Models about a domain topic. They describe interoperably what can be stored, retrieved, presented and exchanged in general about that domain topic. Templates: The collection of archetypes constrained to that precise degree that it is usable in a specific context. Template: It is the interoperable information part of a contract between two or more communicating actors. Gerard -- -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: [gfrer@luna.nl](mailto:gfrer@luna.nl) Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 --- ## Post #9 by @Heath_Frankel Andrew & Ogi, openEHR Templates are not Forms, they are aggregations of archetypes with further constraints\. The scope of an openEHR template can be compared with a form but define the data structure of that form\. However openEHR Templates can be used to drive the design and generation of forms as is done using the Ocean Template Designer\. The designer has a Template Design panel where archetypes are dragged from a archetype repository view onto the panel building up the template structure and the archetype nodes are constrained as required in the template\. The Form Design panel allows nodes from the Template to be dragged onto the Form and formatted as designed\. This latter step is purely an application customisation step whereas the former template design is a knowledge development step possible used by more than one application\. Heath --- ## Post #10 by @ian.mcnicoll Hi Heath, I am interested in this aspect of archetypes/templates as well\. I am currently working with the Scottish National Clinical Datasets program to see how we might integrate archetypes and templates into their data standards development process i\.e essentially as a design\-time tool rather than a full OpenEHR runtime system \(though this may perhaps follow along in due course\)\. The current process has delivered very good clinical involvement and knowledge acquisition but the output has a number of deficiencies \- poor support for 'complex clinical concepts' i\.e\. archetypes and is not sufficiently tightly defined to be used by system developers without a great deal of further confusion\. I am interested in your comment "the former template design is a knowledge development step possible used by more than one application" because as well as templates being a precursor to form design can they also play a part in 'dataset' definition by capturing the requirements of different clinical workgroups based perhaps on the same archetypes? Is there an inheritance mechanism within templates as there is for archetypes via specialisation? Regards, Ian Dr Ian McNicoll Maclean McNicoll Software www\.gpacc\.co\.uk --- ## Post #11 by @thomas.beale Heath Frankel wrote: > Andrew & Ogi, > openEHR Templates are not Forms, they are aggregations of archetypes with > further constraints\. The scope of an openEHR template can be compared with > a form but define the data structure of that form\. However openEHR > Templates can be used to drive the design and generation of forms as is done > using the Ocean Template Designer\. The designer has a Template Design panel > where archetypes are dragged from a archetype repository view onto the panel > building up the template structure and the archetype nodes are constrained > as required in the template\. The Form Design panel allows nodes from the > Template to be dragged onto the Form and formatted as designed\. This latter > step is purely an application customisation step whereas the former template > design is a knowledge development step possible used by more than one > application\. >   To further clarify: an openEHR template can be used to: \- create a visual form \(as described above by Heath\) \- to create a message definition, i\.e\. an XML\-schema corresponding to the template \- to create a means of displaying data, using XML/Xslt \- create other generated artifacts, e\.g\. code skeletons, wsdl specifications etc Logically, an openEHR template corresponds to a localised specfication for a chunk of content, based on use of archetypes \(which themselves may be very general\)\. \- thomas beale --- ## Post #12 by @thomas.beale Gerard Freriks wrote: > My try\. > > Template: It is the interoperable information part of a contract > between two or more communicating actors\. Gerard, that is a very nice functional definition\. In some cases, the actors are the GUI application user, and other users, whose previously persisted information is served up via a template\-enabled application\. \- thomas --- ## Post #13 by @Brett_Esler I apologise for my rather irreverant previous post\.\.\.\.that was an oops\. Are openEHR template specialisation hierarchies a real possibility? This would be particularly useful in message profiles, and conformance level assertions made by systems\. Btw: would consider the openEHR RM classes archetypes if I was to express them somehow using CEN13606, and HL7 V3 RIM further again specialised archetypes\. The choice is how general is your reference model and the assumed semantic level that comes with that\. HL7 V3 templating is the using the same method whether archetyping or templating in openEHR speak, there are also many aspects of openEHR style templating in HL7 message development itself\. This becomes N level modelling\.\.\. \- openEHR has at least 3, RM, archetype, template \- HL7 V3 at least 4, RIM, DMIM, RMIM, HL7 Template \(CIM \+ CMET\) All of these have some usage description\.\.\.and some 'rules' e\.g must have a single entry point, must be serialisable etc\. Picking your level for expressing a wire protocol is another choice; that would be in some ways be entirely based on your level of generality desired\. Regards, Brett Esler --- ## Post #14 by @Heath_Frankel Hi Ian, > I am interested in your comment "the former template design > is a knowledge development step possible used by more than > one application" because as well as templates being a > precursor to form design can they also play a part in > 'dataset' definition by capturing the requirements of > different clinical workgroups based perhaps on the same archetypes? This is exactly what templates are designed to support\. > Is there an inheritance mechanism within templates as there > is for archetypes via specialisation? Hmm, good question\. Not sure what Tom & Sam have in mind here, would be nice\. However, I do know that the inheritance mechanism in archetypes is being improved and that the Template Model is really just an extension of the Archetype Model so I would guess that it might\. We have not yet implemented this capability in the OceanEHR Tools and Application Components\. Regards Heath Heath Frankel Product Development Manager Ocean Informatics --- ## Post #15 by @Andrew_Patterson > data structure defined by a particular organisation but has no true > semantics in health, where as a discharge or referral is a common concept\. Well, not strictly true \- the CCR has semantics that aren't the same as discharge or referral but they are seemingly clear to the CCR people \- the CCR is a summary record that could be used by an \(unknown at the time of composition\) future health provider to continue the care of this patient\. If it becomes popular it may become a common health concept\. > developed by an organisation we would have millions of archetypes and no > semantic interoperability\. Well, we'd maybe have multiple archetype sets \(as opposed to one set of archetypes\) each defined by different organisations\. ASTM, NHS, NEHTA etc\. I don't think we'd even break into the 1000's if every health standards body defined their own? I thought semantic interoperability was the ability to computationally recognise the similarities in archetyped data between systems using terminologies etc, therefore allowing data to be used across multiple systems\. i\.e\. this is a soap 'plan' because it is in a section marked with the term binding for 'plan', and over here in this other completely different archetype we might have a similar section and therefore we know they have the same meaning\. If semantic interoperability is just that everyone agrees to use the same definitions for everything, then we don't really need a fancy word like semantic interoperability for it\. Its like saying we'd have semantic interoperability if everyone agreed to use the Medical Director database schema \- which is true but pointless \- if everyone agreed in the first place we wouldn't be worried about the semantics when we go to interoperate\. I'm not suggesting that every player in the whole health system would be going around defining archetypes for everything\. But surely we're not suggesting that there would only be ONE set of archetypes for the whole world \(with templates making the constraints for local variations\)? Andrew --- ## Post #16 by @Heath_Frankel Andrew, > > data structure defined by a particular organisation but has no true > > semantics in health, where as a discharge or referral is a > common concept\. > > Well, not strictly true \- the CCR has semantics that aren't > the same as discharge or referral but they are seemingly > clear to the CCR people > \- the CCR is a summary > record that could be used by an \(unknown at the time of > composition\) future health provider to continue the care of > this patient\. If it becomes popular it may become a common > health concept\. I don't see any difference in semantics to the Discharge Summary stored in a HealthConnect Record System\. > Well, we'd maybe have multiple archetype sets \(as opposed to > one set of > archetypes\) each defined by different organisations\. ASTM, > NHS, NEHTA etc\. I don't think we'd even break into the 1000's > if every health standards body defined their own? openEHR does not intended for this to happen\. However, this does not mean that organisations can't have local archetypes but they should not semantically overlap with those archetypes that are globally recognised\. This is the fundamentals of Archetype Governance which is under development by the openEHR Clinical Review Board\. > I thought semantic interoperability was the ability to > computationally recognise the similarities in archetyped data > between systems using terminologies etc, therefore allowing > data to be used across multiple systems\. i\.e\. this is a soap > 'plan' because it is in a section marked with the term > binding for 'plan', and over here in this other completely > different archetype we might have a similar section and > therefore we know they have the same meaning\. If semantic > interoperability is just that everyone agrees to use the same > definitions for everything, then we don't really need a fancy > word like semantic interoperability for it\. Its like saying > we'd have semantic interoperability if everyone agreed to use > the Medical Director database schema \- which is true but > pointless \- if everyone agreed in the first place we wouldn't > be worried about the semantics when we go to interoperate\. Actually sections are purely organisational only, they do not change the semantics of the entries inside them\. What you describe above regarding sematic interoperability is what is attempted by HL7 V3 where the semantics are defined in the RIM\. The problem here is that no one can agree on the semantics of the RIM \(I am not trying to controversial here, this is from experience as the Modelling Facilitator of the Care Provision domain for many years\)\. It has taken > 2 years \(and it continues\) to agree on the RIM structures required to semantically define a Problem List and Allergy\. We do not have this problem in openEHR as the semantics of the concept are declared by the definition of an archetype and all you have to do is specify the data that you need to capture as part of that concept\. What we do is share the concept ID \(the archetype ID\) which is analogous to sharing SNOMED concept IDs and share the data structure along with that\. If you go and define your own data structure and assign your own archetype ID for the same concept then you have just broken your semantic interoperability\. You are absolutely correct, if we can agree then we wouldn't need to worry about mapping semantics to interoperate, that is the premise of archetypes\. > I'm not suggesting that every player in the whole health > system would be going around defining archetypes for > everything\. But surely we're not suggesting that there would > only be ONE set of archetypes for the whole world \(with > templates making the constraints for local variations\)? For agreed concepts, yes\. Local archetypes can exist \(as long as they don't overlap\), including specialisation of global archetypes, and they can get promoted to higher levels of as consensus grows around that archetype\. Regards Heath --- ## Post #17 by @Andrew_Patterson > openEHR does not intended for this to happen\. However, this does not mean > that organisations can't have local archetypes but they should not > semantically overlap with those archetypes that are globally recognised\. > This is the fundamentals of Archetype Governance which is under development > by the openEHR Clinical Review Board\. ok \- I think we actually have almost the same world view\. I agree that if you can construct a globally recognised and agreed upon archetype, that this should be used wherever possible\. I would think that clinical ENTRY archetypes would be the main area where this is possible \- after all we are all human beings and so it should be possible to construct common glucose reading/blood pressure etc archetypes\. > Actually sections are purely organisational only, they do not change the > semantics of the entries inside them\. I guess I disagree about the possibility \(or usefulness\) of defining globally recognised archetypes as you go further up the tree \(towards organising archetypes like encounter, medication list etc\)\. This is why I would see a CCR as a composition archetype, with the specific sections and details as per the CCR spec\. I don't see the possibility \(or value\) of defining the CCR as a template of some generic 'discharge' archetype\. > of the Care Provision domain for many years\)\. It has taken > 2 years \(and > it continues\) to agree on the RIM structures required to semantically define > a Problem List and Allergy\. We do not have this problem in openEHR as the > semantics of the concept are declared by the definition of an archetype and So why do you believe it will be possible to get global agreement on the definition of the Problem List and Allergy archetype? Andrew --- ## Post #18 by @Brett_Esler Heath, I know what you are saying about RIM semantics but aren't the openEHR RM classes, OBSERVATION, INSTRUCTION, EVALUATION, etc\. implying a general weak clinical semantic as a framework for hanging stronger semantic archetyping\. I can imply certain things about a stored openEHR OBSERVATION based on the openEHR RM definition without knowledge of the archetype applied to it, for a start it is considered an observation not an instruction for instance\. As for terminology binding for consistency we would need to ensure that the use of terminology binding in leaf nodes of archetypes was controlled enough to ensure that the granularity of the concept matched the allowed data constraints at the node and also that concept either did not appear in other archetypes or matched exactly in terms of constraints to data\. It is what it is\.\.\.there are no choices here\. We could also ensure that terminology bound child nodes in an archetype definition can be related to the parent terminology binding in a known way; this might be made explicit as a SNOMED\-CT hierarchy\. Parents and child nodes are related through a relationship this is not explicity stated in archetype definitions at this point\. These approaches will show any holes in SNOMED\-CT that need addressing and also extend the concepts to include data definitions where appropriate\. Regards, Brett Esler --- ## Post #19 by @system Hi, > This becomes N level modelling... > > - openEHR has at least 3, RM, archetype, template > > - HL7 V3 at least 4, RIM, DMIM, RMIM, HL7 Template (CIM + CMET) > > All of these have some usage description...and some 'rules' e.g must > > have a single entry point, must be serialisable etc. But with one big difference. In OpenEHR the whole trajectory from level 1 to n via done in a strictly computable way. This is not the case in HL7. Gerard -- -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: [gfrer@luna.nl](mailto:gfrer@luna.nl) Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 --- ## Post #20 by @system The family of Observation, Instruction, Evaluation and Action Archetypes are containers. But they do not change the meaning if archetypes they contain. A blood pressure stays a blood pressure. In effect this specific family of archetypes constitute an extra model in the OpenEHR family of models. This model is about the patient treatment cycle in which constructs like blood pressure, prescription, etc, play a role. Gerard -- -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: [gfrer@luna.nl](mailto:gfrer@luna.nl) Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 --- ## Post #21 by @Heath_Frankel Andrew, > > Actually sections are purely organisational only, they do > not change > > the semantics of the entries inside them\. > > I guess I disagree about the possibility \(or usefulness\) of > defining globally recognised archetypes as you go further up > the tree \(towards organising archetypes like encounter, > medication list etc\)\. This is why I would see a CCR as a > composition archetype, with the specific sections and details > as per the CCR spec\. I don't see the possibility \(or value\) > of defining the CCR as a template of some generic 'discharge' > archetype\. Well, we will have to agree to disagree, but ultimately it is the clinicians that will make the decision, not us techos\. However, from my past experience working on consultancies to develop national discharge summary and referral templates that a flexible modular approach is necessary to cater for the various situations where discharge summaries and referrals are used\. This means there are likely to more than one template for discharge summaries and referrals and that a single "one fits all" CCR like template will not be sufficient\. This is especially the case for the CCR as it is a summary document and experience shows that some circumstances require more detail in certain areas are whole new sections of data\. > > of the Care Provision domain for many years\)\. It has taken > > 2 years > > \(and it continues\) to agree on the RIM structures required to > > semantically define a Problem List and Allergy\. We do not > have this > > problem in openEHR as the semantics of the concept are > declared by the > > definition of an archetype and > > So why do you believe it will be possible to get global > agreement on the definition of the Problem List and Allergy archetype? It is not the set of data elements that need to be collected that has taken so long to determine \(these are usually already well documented in clinical literature\) but the requirement to extend the RIM vocabulary \(through a long and tedious Harmonization process\) and agree on particular combinations of RIM classes and attributes to be used to map its semantics to those data elements\. Heath --- ## Post #22 by @Heath_Frankel Brett, > I know what you are saying about RIM semantics but aren't the > openEHR RM classes, OBSERVATION, INSTRUCTION, EVALUATION, > etc\. implying a general weak clinical semantic as a framework > for hanging stronger semantic archetyping\. I can imply > certain things about a stored openEHR OBSERVATION based on > the openEHR RM definition without knowledge of the archetype > applied to it, for a start it is considered an observation > not an instruction for instance\. As you say, they are very generic concepts and effectively only represent the class of the concept and the pattern for its data compared with a instance of the concept\. This is analogous to the RIM classes on the UML diagram, but this is not where the semantics are carried, the semantics are in the RIM vocabulary\. The equivalent of this RIM vocabulary are archetypes without the more clinically intuitive and extensible data definition capability\. > As for terminology binding for consistency we would need to > ensure that the use of terminology binding in leaf nodes of > archetypes was controlled enough to ensure that the > granularity of the concept matched the allowed data > constraints at the node and also that concept either did not > appear in other archetypes or matched exactly in terms of > constraints to data\. It is what it is\.\.\.there are no choices here\. Exactly what is done in templates\. You can also have Cluster and Data Element Archetypes to support the reuse of lower\-level concepts such as Body Site etc\. > We could also ensure that terminology bound child nodes in an > archetype definition can be related to the parent terminology > binding in a known way; this might be made explicit as a > SNOMED\-CT hierarchy\. Parents and child nodes are related > through a relationship this is not explicitly stated in > archetype definitions at this point\. Not explicitly, but there is a reference to a pre\-defined code set that might be a result of applying a complex query of relationships on a hierarchical terminology such as SNOMED\-CT\. For example, all the Herpes related viruses\. This result set is stored in a Terminology Server such as the Ocean Terminology Server and can be accessed by a system using the archetype using the code set reference\. This a bit like the HL7 V3 Vocabulary domains to external vocabularies but more fine grained and less pre\-coordinated\. For example, the Australian code set of Herpes related viruses may be different to the UK\. Heath --- ## Post #23 by @williamtfgoossen I have to agree to a high degree with Heath here \(exception is on the HL7 harmonisation process\)\. I have been working on developing archetypes since original CEN work for ICNP / Mose / Nursys, and follow up work in templates within HL7 work\. Further several Dutch projects under HL7 v3 umbrella for which I met with Heath\. I believe that the clinical expression of variables, values, datatype, cardinalities, relationships between variables \(e\.g\. in scales\) is the most demanding part of all work\. Using any formalism, \(more HL7 v3 people are looking at the archetype approach for that, so the discussion on ‘best’ can be considered for the past\), is important to bridge clinical to technical worlds\. In this formalism we need to be able to define discrete items \(clinically: one observation or one measure, e\.g\. weight\)\. Then we must be able to have archetypes that combine clinically natural combinations of discrete variables \(blood pressure: systolic, diastolic, cuff size, position\)\. Such examples can be globally standardized, at least to the level where the units are referenced appropriately, e\.g\. kg weight versus Lbs\. The we must have archetype to represent clinical constructs, such as assessment scales / instruments\. These have usually a clinimetric / psychometric research based set of characteristic, assuming a 100% correct technical representation\. This is doable with archetyping, e\.g\. the apgar score and Barthel index examples\. To me this is in specifying clinical content with a formalism is such a way that these small pieces can be selected upon choice to be included in different formats\. Each format can be seen as a template: a logical, clinical grouping or collection of archetypes \(selection of 1, 3, 5 or 5\.000\.000 depending on purpose\) meeting a specific purpose\. Purposes in the real world are: database design, screen design, HER / OpenEHR style, but also a technical artefact is an HL7 v3 message, or given discussion the CCR style of material\. In other words: archetypes will be globally definable, or at least referred to, where the template specifies many different implement able ‘things’ that will vary to purpose\. The flexibility Heath mentions is absolutely required\. E\.\.g\. a discharge summary after delivery will have similar components \(template level\) compared to discharge summary after stroke care, \(e\.g\. blood pressure template, weight\), but also differ \(first has Apgar score archetype, second has Barthel index\)\. The template thus must hold place for 1\-n scales to be includable upon choice of clinicians and depending the actual technical implementation\. For me encounter and medication list are definitely not archetypes: they differ too much in each circumstance, they are templates that will hold several to many archetypes\. The problem list within HL7 has been addressed and is now part of the set of messages useful for referral and discharge\. That set is going for 3 year stable DSTU once ANSI has dealt with the bureaucracy\. The allergy and intolerance is still a problem, not due to R\-MIM modelling, but clinical and national registry etc level discussion on business needs\. So the first step: sorting out the clinical content, is blocking the speedy consensus\. So with respect to Heath comments on this: no agreement, it will work\. --- ## Post #24 by @Andrew_Patterson > Well, we will have to agree to disagree, but ultimately it is the clinicians > that will make the decision, not us techos\. Actually, I'm understanding your point of view more now \- I'm totally in agreement that its not us technical people that makes these decisions\. The CCR may be an absolute abomination as far as clinical forms go \(I really have no experience in this area at all, but I suspect you are right about a one size fits all approach not working\)\. I was just asking from the point of view that, if it say became mandatory \(or even a selling point\) in the US to support CCR, how would you imagine it being supported in an openehr system \(as much as that would be a waste of the features in openehr \- sometimes you've gotta do some things just to get the 'tick box' for certain markets\)? Andrew --- ## Post #25 by @Andrew_Patterson William, > In this formalism we need to be able to define discrete items \(clinically: one observation > or one measure, e\.g\. weight\)\. Then we must be able to have archetypes that combine > clinically natural combinations of discrete variables \(blood pressure: systolic, diastolic, > cuff size, position\)\. Such examples can be globally standardized, at least to the level > where the units are referenced appropriately, e\.g\. kg weight versus Lbs\. No argument from me here\. > The we must have archetype to represent clinical constructs, such as assessment > scales / instruments\. These have usually a clinimetric / psychometric research based set > of characteristic, assuming a 100% correct technical representation\. This is doable with > archetyping, e\.g\. the apgar score and Barthel index examples\. No arguments here either \- some scoring I imagine is different from jurisdiction to jurisdiction \(alcohol usage scoring etc\) but universal ones such as apgar can definately be globally standardised\. > In other words: archetypes will be globally definable, or at least referred to, where the > template specifies many different implement able 'things' that will vary to purpose\. > The flexibility Heath mentions is absolutely required\. E\.\.g\. a discharge summary after > delivery will have similar components \(template level\) compared to discharge summary > after stroke care, \(e\.g\. blood pressure template, weight\), but also differ \(first has Apgar > score archetype, second has Barthel index\)\. The template thus must hold place for 1\-n > scales to be includable upon choice of clinicians and depending the actual technical > implementation\. > For me encounter and medication list are definitely not archetypes: they differ too > much in each circumstance, they are templates that will hold several to many > archetypes\. I don't understand the distinction you make here \- archetypes can hold other archetypes and so I'm not sure why templates are introduced\. For instance, from the openehr sample archetypes openEHR\-EHR\-SECTION\.summary\.v1   SECTION\[at0000\] matches \{ \-\- Summary     items cardinality matches \{0\.\.\*; unordered\} matches \{       allow\_archetype EVALUATION occurrences matches \{0\.\.1\} matches \{         include           domain\_concept matches \{/clinical\_synopsis\\\.v1/\}           domain\_concept matches \{/problem\\\.v1/\}           domain\_concept matches \{/problem\-diagnosis\\\.v1/\}           domain\_concept matches \{/problem\-diagnosis\-histological\\\.v1/\}           domain\_concept matches \{/problem\-genetic\\\.v1/\}           domain\_concept matches \{/risk\\\.v1/\}       \}     \}   \} So this summary defines this section to hold a collection of other specified archetypes\. If this summary was 'included' as the content of a higher level 'discharge' archetype, you would have a flexible definition of a discharge summary\. Where does the template come into it? What everyone seems to be saying is that clinicians need a lot of flexibility in how they put together things such as encounters and referrals\. I 100% agree \- which is why I would think each jurisdiction would have its own compositional archetypes, suited to its own particular use cases \(maybe in a hierarchy of australia discharge summary \-> australia natal discharge summary etc\)\. These compositional archetypes would refer to globally agree 'data items' archetypes wherever possible \(blood pressure etc\)\. Instead my reading of the situation is that everyone wants to just have a single global openEHR\-EHR\-COMPOSITION\.discharge\.v1draft\.adl which seemingly adds no useful constraints at all, and then instead constrain everything with templates \(of which we haven't yet seen a spec?\)\. Andrew --- ## Post #26 by @Sam Hi all It is true to say that there are semantics in every information model - but the core semantics of the openEHR model is containing (hence the proposed key word in the openEHR query language CONTAINS). The effort in openEHR has been to separate the domain semantics from the recording semantics. An OBSERVATION class is there to support recording observations and can apply in science generally as in medicine - separation of method data (protocol), the measured data (data) and the state of the person at the time of the measurement (state) is a well documented pattern. Not separating this data leads to a lot of semantic issues about whether data is comparable or not and the state model for some measurements can become complex and requires the addition of 'assumed value' for utility. The point is that there is no clinical or domain (beyond science) semantics so clinicians can describe archetypes without having to understand too many information constructs. Cheers, Sam Cheers, Sam Brett Esler wrote: --- ## Post #27 by @Sam Ian and Heath The ability to apply a template to any archetype, and then use this 'templated' archetype in another template (which can also be called) is as far as we have got. Templates are compositional as well as constraining - I have not seen the use case for an inheritence model within templates as yet but I am interested. The point would probably be when you want to use a template that is well described but add in another feature that is not available (without going through a length process)......this might be a tooling issue - only time will tell. Cheers, Sam Heath Frankel wrote: --- ## Post #28 by @Heath_Frankel Andrew, > I was just asking from the point of view that, if it say > became mandatory \(or even a selling point\) in the US to > support CCR, how would you imagine it being supported in an > openehr system \(as much as that would be a waste of the > features in openehr \- sometimes you've gotta do some things > just to get the 'tick box' for certain markets\)? So the answer is, Templates using existing Archetypes\. And another template can be developed for Australia's requirements, and another for UK requirements, all using the same existing Archetype\. However, these Archetypes will certainly need work to support the requirements of those nationally endorsed templates and I am sure that the CCR will have much to contribute to this\. Heath --- ## Post #29 by @Heath_Frankel Andrew and William, > > For me encounter and medication list are definitely not archetypes: > > they differ too much in each circumstance, they are templates that > > will hold several to many archetypes\. > > I don't understand the distinction you make here \- archetypes > can hold other archetypes and so I'm not sure why templates > are introduced\. For instance, from the openehr sample archetypes Encounter and Medication List are Compositions in openEHR\. Templates are used to further constrain these into a particular context such as a Diabetes Review Encounter or a Current Medication List\. Again you don't want to specialise the composition archetypes for every possible context in every country otherwise you won't have semantic interoperability between contexts and jurisdictions\. > If this summary was 'included' as the content of a higher > level 'discharge' archetype, you would have a flexible > definition of a discharge summary\. Where does the template > come into it? Clinically a neonatal discharge is not much different to a maternal discharge or a day stay discharge except for the context and the data it contains\. So you don't need different composition archetypes, just a different template to constrain \(or hint towards\) the type of data to be record for each context\. > What everyone seems to be saying is that clinicians need a > lot of flexibility in how they put together things such as > encounters and referrals\. I 100% agree \- which is why I would > think each jurisdiction would have its own compositional > archetypes, suited to its own particular use cases \(maybe in > a hierarchy of australia discharge summary \-> australia natal > discharge summary etc\)\. See above\. But perhaps a specialisation of Discharge composition is not out of the question but not on the basis of jurisdiction except within the archetype governance framework\. > Instead my reading of the situation is that everyone wants to > just have a single global > > openEHR\-EHR\-COMPOSITION\.discharge\.v1draft\.adl > > which seemingly adds no useful constraints at all, and then > instead constrain everything with templates \(of which we > haven't yet seen a spec?\)\. As you noted, these are draft archetypes and need work\. Composition archetypes can specify the sections \(or entries\) that they contain as content but will also specify the category of the composition and the other\_context data that is associated with the composition\. For example you will not find any content constraints in the openEHR\-EHR\-COMPOSITION\.report\.v1 archetype but will find an other\_context item structure\. The discharge archetype is the placeholder for the concept of a discharge composition, it is still to be determined what globally acceptable constraints we can specify on discharge content and what context data is required\. Ocean has identified one data element \(encounter ID\) that is a candidate\. Heath --- ## Post #30 by @Sam Andrew You could start with an integration archetype (using admin entry for the moment) to get the data absolutely in tune with CCR. Then we could do a transform to a properly archetyped environment. Both would be useful. I would be prepared to do the latter - why not have a go at the direct mapping into the openEHR environment yourself. Cheers, Sam Heath Frankel wrote: --- **Canonical:** https://discourse.openehr.org/t/ccr-and-openehr/14625 **Original content:** https://discourse.openehr.org/t/ccr-and-openehr/14625