# Suggestions re Term binding in Archetype Editor **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2006-12-15 13:35 UTC **Views:** 3 **Replies:** 49 **URL:** https://discourse.openehr.org/t/suggestions-re-term-binding-in-archetype-editor/14597 --- ## Post #1 by @ian.mcnicoll Hi, I am currently working my way slowly through the Scottish Cardiac dataset, converting it to archetypes as proof\-of\-concept, using the OE editor\. Term binding \(to SNOMED\) will be a crucial aspect from our perspective, especially binding local \(interface\) terms to SNOMED concepts\. This would be much easier within the editor if the Term bindings screen displayed the node name as well as the Node ID, as it is easy to forget which local term you are trying to bind by the time you have rummaged around in Snomed for a bit\!\!\. The "Choose Nodes" dialog might also be a little easier if the Node parent name and Node name were included\. When only the node name is visible this can cause confusion if similar local terms are used for different nodes e\.g\. "Not known"\. Finally in the ADL, I think it would be very helpful to be able to include the text of the Bound term text as well as its code\. This would allow much easier checking for errors and documenting I have done this by enclosing the bound term text in \[\] for now\. e\.g\. term\_binding = <     \["SNOMED\-CT"\] = <       items = <         \["at0000"\] = <\[SNOMED\-CT::229819007 \[Tobacco use and Exposure\]\]>         \["at0006"\] = <\[SNOMED\-CT::?Non Tobacco user\]>         \["at0009"\] = <\[SNOMED\-CT::\]>         \["at0011"\] = <\[SNOMED\-CT::\[Ex\-smoker\] 8517006\]>         \["at0012"\] = <\[SNOMED\-CT::\[Current non\-smoker\] 160618006\]> Regards, Ian --- ## Post #2 by @Ruth_Kidd >> This would be much easier within the editor if the Term bindings screen >> displayed the node name as well as the Node ID, as it is easy to forget >> which local term you are trying to bind by the time you have rummaged around >> in Snomed for a bit\!\! I would definitely second this\! --- ## Post #3 by @williamtfgoossen In een bericht met de datum 15-12-2006 14:40:59 West-Europa (standaardtijd), schrijft ian@mcmi.co.uk: > Hi, > > I am currently working my way slowly through the Scottish Cardiac dataset, > converting it to archetypes as proof-of-concept, using the OE editor. > > Term binding (to SNOMED) will be a crucial aspect from our perspective, > especially binding local (interface) terms to SNOMED concepts. > > This would be much easier within the editor if the Term bindings screen > displayed the node name as well as the Node ID, as it is easy to forget > which local term you are trying to bind by the time you have rummaged around > in Snomed for a bit!!. The "Choose Nodes" dialog might also be a little > easier if the Node parent name and Node name were included. When only the > node name is visible this can cause confusion if similar local terms are > used for different nodes e.g. "Not known". > > Finally in the ADL, I think it would be very helpful to be able to include > the text of the Bound term text as well as its code. This would allow much > easier checking for errors and documenting > > I have done this by enclosing the bound term text in [] for now. > > e.g. > term_binding = < > ["SNOMED-CT"] = < > items = < > ["at0000"] = <[SNOMED-CT::229819007 [Tobacco > use and Exposure]]> > ["at0006"] = <[SNOMED-CT::?Non Tobacco > user]> > ["at0009"] = <[SNOMED-CT::]> > ["at0011"] = <[SNOMED-CT::[Ex-smoker] > 8517006]> > ["at0012"] = <[SNOMED-CT::[Current > non-smoker] 160618006]> > > Regards, > > Ian I agree with Ian's requirements, however would like to add. In our experience some clinical materials are that detailed that not all terms can be coded with Snomed CT terms, and waiting for additions is not always possible. In such a case, or if there are requirements to work with other codes (LOINC, ICF) I work with multiple code bindings in the same archetype / template / care information models. This would add the following 2 requirements: 1. identify the code system itself that is used (which Ian alread presents in its listing/naming ["SNOMED-CT"] 2. apply the ISO unique identifier for the coding system used. For snomed CT this would be: 2.16.840.1.113883.6.5 I am not fully familiar with the notations in the archetype, but it could look like this term_binding = < [2.16.840.1.113883.6.5:: Display name is: SNOMED-CT"] = < items = < ["at0000"] = <[SNOMED-CT::229819007 [Tobacco use and Exposure]]> where the number is the identifier and Snomed-CT the name of the terminology system(s) applied. Similarly the ICF binding could then reside in the same archetype. term_binding = < [2.16.840.1.113883.6.*****:: Display name is: ICF"] = < items = < ["at0023"] = <[ICF::d3151 [Understanding general signs and symbols]]> (as far as I know there is no ISO OID for ICF at this stage, or if anyone knows it and can give the source, I would be happy). William Goossen --- ## Post #4 by @ian.mcnicoll Hi William, The ADL 1.4 ontology section already handles multiple terminologies, versioning is mentioned (against each binding) in the source for the archetype editor as being required but I cannot see anything about this in the OpenEHR reference material. The terminologies (and official Name e.g. “SNOMED-CT” are selected from a supplied list so should be unique but I agree that it might be helpful to have this cross-referenced to a code system identifier elsewhere. Example of actual ADL below Regards, Ian PS It appears we are colleagues via Derek Hoy’s Scottish Clinical Templates work. e.g. terminologies_available = <"SNOMED-CT", "LNC205"> term_definitions = < ["en"] = < items = < ["at0000"] = < description = <"Details of non-professional Patient Carer"> text = <"Carer"> ["at0004"] = < description = <"*"> text = <"Carer Name"> > > > > term_binding = < ["SNOMED-CT"] = < items = < ["at0000"] = <[SNOMED-CT::12345]> > > ["LNC205"] = < items = < ["at0004"] = <[LNC205::121457]> --- ## Post #5 by @ian.mcnicoll Hi Sam, I appreciate the "language" difficulty here, given the ontology separation in ADL\. However, in the UK context, the ability to document bindings to Snomed\-CT with clear documentation, thereof, will be crucial to promoting OpenEHR\. The design philosophy for DV\_CODED\_TEXT is that the raw term is never sent without the rubric, and I think somehow this needs to be extended to the binding terms as it is by no means certain that access to a terminology server will be a given in all the environments where ADL is being used as a design / documentation language\. Would it be possible to allow the term bindings to be commented with the term name in the native authored language\(as the current dADL entries are commented with the node name \)? The current editor seems to strip out the any comments from the term bindings\. This would at least let the rubrics be captured and displayed in any documentation\. Ian --- ## Post #6 by @Mattias_Forss1 Hi Ian, Archetypes are designed to be loosely coupled with terminology so that they can be used when there are no terminology resources available. If we have comments of the bindings, we get another problem because if the definition of the binding changes (for example a translated term is redefined in a terminology) the comment will be obsolete. We currently have to rely on the archetypes' local terminology to get the approximate rubrics when there are no terminology resources available. Regards, Mattias 2006/12/18, Ian McNicoll <[ian@gpacc.co.uk](mailto:ian@gpacc.co.uk)>: --- ## Post #7 by @ian.mcnicoll Hi Mattias, I do appreciate these difficulties but if the definition of the binding changes the binding itself may be obsolete. I agree the comment idea is less than satisfactory, it would be better if the term binding contained the rubric as well as the term code for exactly the same reasons that the rubric must always accompany the term code in DV_CODED_TEXT. Managing Snomed-CT is going to be a very tricky exercise. Using archetypes + bindings offers a very powerful way of managing Snomed where semantic precision is very important e.g. decision support. Having tools that will let us design and document these bindings will be a powerful way of persuading those who have yet to understand the value of the archetype approach. Having the term rubrics available is an important part of cross-checking that the correct binding has been applied, both for the original author (where terminology services might well be available) and when the archetype and bindings are reviewed by a wider clinical audience (when such services may not be available). Regards, Ian --- ## Post #8 by @Mattias_Forss1 2006/12/18, Ian McNicoll <[ian@gpacc.co.uk](mailto:ian@gpacc.co.uk)>: > Hi Mattias, > > I do appreciate these difficulties but if the definition of the binding changes the binding itself may be obsolete. If the binding changes so much in the terminology that it may be obsolete in the archetype it would probably lead to a new term that is created in the terminology and the old one is kept... but that doesn't matter in this discussion - just wanted to point it out. > I agree the comment idea is less than satisfactory, it would be better if the term binding contained the rubric as well as the term code for exactly the same reasons that the rubric must always accompany the term code in DV_CODED_TEXT. I don't know why the DV_CODED_TEXT is designed this way. I have thought about it and the only reason why this is done is probably to get a faster access to the rubric and maybe also when there are no translations for the term in a specific language in order to get a 'default' rubric at all times. Maybe you're right, the definitions could be added as comments, but for proprietary terminology like SNOMED CT this will mean that these kind of archetypes can only be distributed to people that have paid the license. Regards, Mattias --- ## Post #9 by @thomas.beale Ian McNicoll wrote: > Hi Sam, > > I appreciate the "language" difficulty here, given the ontology separation > in ADL\. However, in the UK context, the ability to document bindings to > Snomed\-CT with clear documentation, thereof, will be crucial to promoting > OpenEHR\. The design philosophy for DV\_CODED\_TEXT is that the raw term is > never sent without the rubric, and I think somehow this needs to be extended > to the binding terms as it is by no means certain that access to a > terminology server will be a given in all the environments where ADL is > being used as a design / documentation language\. Would it be possible to > allow the term bindings to be commented with the term name in the native > authored language\(as the current dADL entries are commented with the node > name \)? The current editor seems to strip out the any comments from the term > bindings\. This would at least let the rubrics be captured and displayed in > any documentation\. >   This is not an unreasonable request \- it would not be particularly difficult to implement in the specs or the tools, if we know what to implement\. We have to be careful with Snomed licensing issues however when the terminology is snomed\.\.\. \- thomas --- ## Post #10 by @Sam Hi Ian > ``` > I appreciate the "language" difficulty here, given the ontology separation > in ADL. However, in the UK context, the ability to document bindings to > Snomed-CT with clear documentation, thereof, will be crucial to promoting > OpenEHR. The design philosophy for DV_CODED_TEXT is that the raw term is > never sent without the rubric, and I think somehow this needs to be extended > to the binding terms as it is by no means certain that access to a > terminology server will be a given in all the environments where ADL is > being used as a design / documentation language > ``` > ``` > Would it be possible to > allow the term bindings to be commented with the term name in the native > authored language(as the current dADL entries are commented with the node > name )? The current editor seems to strip out the any comments from the term > bindings. This would at least let the rubrics be captured and displayed in > any documentation. > > ``` OK - I take your point but it needs to be language dependent - which has not be catered for in the archetype design. We can enter the text in the language which the author uses and then get the text at run time from the terminology service if it is available? Tom, Hugh? --- ## Post #11 by @williamtfgoossen In een bericht met de datum 18-12-2006 17:28:53 West-Europa (standaardtijd), schrijft ian@gpacc.co.uk: > Hi Mattias, > > I do appreciate these difficulties but if the definition of the binding changes the binding itself may be obsolete. I agree the comment idea is less than satisfactory, it would be better if the term binding contained the rubric as well as the term code for exactly the same reasons that the rubric must always accompany the term code in DV_CODED_TEXT. > > Managing Snomed-CT is going to be a very tricky exercise. Using archetypes + bindings offers a very powerful way of managing Snomed where semantic precision is very important e.g. decision support. Having tools that will let us design and document these bindings will be a powerful way of persuading those who have yet to understand the value of the archetype approach. Having the term rubrics available is an important part of cross-checking that the correct binding has been applied, both for the original author (where terminology services might well be available) and when the archetype and bindings are reviewed by a wider clinical audience (when such services may not be available). > Regards, > > Ian Ian I agree fully with what you say here: there must be a strict binding possible between the information model and the terminology model. It is not only for decision support, but also for confidence that the right base materials are used to develop the archetype and for semantic interoperability. Sometimes terminologies can say the opposite of what the information model expresses. So prevention of errors in interpretation is also important. William Goossen --- ## Post #12 by @williamtfgoossen In een bericht met de datum 18-12-2006 18:00:54 West-Europa (standaardtijd), schrijft mattias.forss@gmail.com: > Maybe you're right, the definitions could be added as comments, but for proprietary terminology like SNOMED CT this will mean that these kind of archetypes can only be distributed to people that have paid the license. Sorry, but Snomed CT cannot be considered a proprietary terminology given the formal international SDO status from January onward. Further, most English speaking countries (Cnd, UK, US, Aus, Nw Zealand) already have a national licence allowing everyone to use it for health purposes. William Goossen --- ## Post #13 by @williamtfgoossen In een bericht met de datum 18-12-2006 20:44:14 West-Europa (standaardtijd), schrijft Thomas.Beale@OceanInformatics.biz: > This is not an unreasonable request - it would not be particularly > difficult to implement in the specs or the tools, if we know what to > implement. We have to be careful with Snomed licensing issues however > when the terminology is snomed... I think there is no reason to be careful if within a realm. Key is to take care where to apply and where not. My earlier comments on binding not only to one terminology but to have mapping tables with synonyms applies here too. William --- ## Post #14 by @Gavin_Brelstaff Williamtfgoossen@cs\.com wrote: > In een bericht met de datum 18\-12\-2006 18:00:54 West\-Europa \(standaardtijd\), > schrijft mattias\.forss@gmail\.com: > >> Maybe you're right, the definitions could be added as comments, but for >> proprietary terminology like SNOMED CT this will mean that these kind of >> archetypes can only be distributed to people that have paid the license\. > > Sorry, but Snomed CT cannot be considered a proprietary terminology given the > formal international SDO status from January onward\. > > Further, most English speaking countries \(Cnd, UK, US, Aus, Nw Zealand\) > already have a national licence allowing everyone to use it for health purposes\. But it is not an \*open\* system \- and this is OpenEHR\.\.\. --- ## Post #15 by @system Williamtfgoossen@cs\.com schreef: > In een bericht met de datum 18\-12\-2006 18:00:54 West\-Europa > \(standaardtijd\), schrijft mattias\.forss@gmail\.com: > >> Maybe you're right, the definitions could be added as comments, but >> for proprietary terminology like SNOMED CT this will mean that these >> kind of archetypes can only be distributed to people that have paid >> the license\. > > Sorry, but Snomed CT cannot be considered a proprietary terminology > given the formal international SDO status from January onward\. > > Further, most English speaking countries \(Cnd, UK, US, Aus, Nw > Zealand\) already have a national licence allowing everyone to use it > for health purposes\. You mean, for free? Paid by the resp\. governments? That, I did not know\. Bert --- ## Post #16 by @system Dear all, A few thoughts about this topic of Terminology Binding and Archetypes. In essence it is the topic of "the Boundary Problem". Archetypes are a solution for this problem. But in order to do so we need agreements on a few things. We mus be extremely clear what we mean when speaking about binding terminologies in archetypes. Are we talking about Archetypes or Templates? (design-time versus almost run-time? Generic structures versus locally agreed structures?) Are we talking about 'Label' or ' Data fields' or ' Archetype slots'? Are we talking about Internal or External coding systems? Are we talking about General External Coding Systems or specially edited sub sets of External Coding Systems, like Oceans Terminology Server and editor provide? (Oceans product creates sub sets of a coding system to be used in a specific context. And acts at as a new refined, restricted, external coding system derived from a feeding general external coding system) What will be rules that govern these things and prevent hazards for patients and healthcare providers? Using the archetype editor we can provide bindings to Generic Basic Archetypes, Specialised Archetypes but also to Templates (Organising Archetypes) and Specialised Templates. Specialisations can be made for specific clinical (sub-)domains or legal jurisdictions. Archetypes define what maximally can be recorded about a clinical concept. Templates define what minimally must be recorded in a specific context, as the agreement between two or more communicating partners. Most (refined) constraints will be applied in Templates. Archetypes need some terminological bindings. Since they are general it can not be fixed fully at design time to what external terminologies they can be bound. Primarily they will use internal codes. In particular controlled circumstances a clinical domain might adopt a specific external coding system to be used in Archetypes designed for that domain. Most codes (internal and external) used in Archetypes will code 'labels' and less data fields. When data fields are bound to a specific external coding systems there will arrise the need for a similar Archetype but bound to an other coding system. This will need an Archetype Ontology where we can create a mechanism that establishes that two archetypes express the same clinical concept but in a different way, using an other (internal or external) coding system. In the world of Templates things are different. This is a space that is much less controlled. Local/regional/national agreements have to be made on the finest detail. Most codes will be used in data fields. A lot of local freedom will be necessary. I have not extended the discussion of binding Archetype Slots to a coding system that is used in connection to 'The Archetype Ontology'. Archetypes and specialised archetypes have to be subjected to quality control in order to prevent hazards, because of errors and non-interoperability. EuroRec (the European Institute for Health records) is executing an Europ[ean project: Q-Rec. Q-Rec will, among others, will realise an Archetype and Template Registry. Its main purpose is to realise: Quality Labeling and Certification of EHR-systems. This will have to include Archetypes. Eurorec will organise quality control of the archetypes and templates to be published. It might be a good idea to involve them. Helpful in this respect is that: - there is an agreement between OceanInformatics and EuroRec, - several players from OpenEHR and CEN/tc251 EN13606 are members of the Q-Rec consortium and EuroRec, - persons active in EuroRec and OpenEHR take part in worldwide developments on Archetypes/templates, Semantic Interoperability, discussions on the deployment of coding systems. Greetings, Gerard -- -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 --- ## Post #17 by @Mattias_Forss1 2006/12/19, [Williamtfgoossen@cs.com](mailto:Williamtfgoossen@cs.com) <[Williamtfgoossen@cs.com](mailto:Williamtfgoossen@cs.com)>: > In een bericht met de datum 18-12-2006 18:00:54 West-Europa (standaardtijd), schrijft [mattias.forss@gmail.com](mailto:mattias.forss@gmail.com): > > > Maybe you're right, the definitions could be added as comments, but for proprietary terminology like SNOMED CT this will mean that these kind of archetypes can only be distributed to people that have paid the license. > > Sorry, but Snomed CT cannot be considered a proprietary terminology given the formal international SDO status from January onward. We'll see about that. Read about the issues with SNOMED and LOINC here [http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_032401.html](http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_032401.html) Mattias --- ## Post #18 by @williamtfgoossen In een bericht met de datum 19-12-2006 10:52:14 West-Europa (standaardtijd), schrijft bert.verhees@rosa.nl: > You mean, for free? Paid by the resp. governments? > > That, I did not know. > > Bert Yes, that is what I mean, and Denmark and the Netherlands have agreed to participate. So anyone willing to apply Snomed CT in the Netherlands and many other countries can do so I think in the 2007 area. Currently I am using it for several projects. (to develop 'archetypes', in HL7 v3 template disguise). William --- ## Post #19 by @williamtfgoossen In een bericht met de datum 19-12-2006 11:28:56 West-Europa (standaardtijd), schrijft mattias.forss@gmail.com: > We'll see about that. Read about the issues with SNOMED and LOINC here > [http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_032401.html ](http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_032401.html) > > Mattias This is exactly what I mean: Snomed CT moving to an international SDO, and securing funding, governance and working together with WHO to sort out the issues. So I think the propretary comments for SNomed CT no longer holds. It is eventually becoming a sister of OPEN ehr. William --- ## Post #20 by @system Williamtfgoossen@cs\.com schreef: > In een bericht met de datum 19\-12\-2006 10:52:14 West\-Europa > \(standaardtijd\), schrijft bert\.verhees@rosa\.nl: > >> You mean, for free? Paid by the resp\. governments? >> >> That, I did not know\. >> >> Bert > > Yes, that is what I mean, and Denmark and the Netherlands have agreed > to participate\. So anyone willing to apply Snomed CT in the > Netherlands and many other countries can do so I think in the 2007 > area\. Currently I am using it for several projects\. \(to develop > 'archetypes', in HL7 v3 template disguise\)\. Stupid I did not know about this\. How do they validate if you come from Country X or Z, or a better question, how can I get access to this materials? Thanks, Bert --- ## Post #21 by @thomas.beale Mattias Forss wrote: > 2006/12/18, Ian McNicoll <[ian@gpacc.co.uk](mailto:ian@gpacc.co.uk)>: > > > Hi Mattias, > > > > I do appreciate these difficulties but if the definition of the binding changes the binding itself may be obsolete. > > If the binding changes so much in the terminology that it may be obsolete in the archetype it would probably lead to a new term that is created in the terminology and the old one is kept... but that doesn't matter in this discussion - just wanted to point it out. this is technically true, and to avoid it we would have to rely on some kind of publish-subscribe update mechanism to cause affected archetypes to be flagged. > > I agree the comment idea is less than satisfactory, it would be better if the term binding contained the rubric as well as the term code for exactly the same reasons that the rubric must always accompany the term code in DV_CODED_TEXT. > > I don't know why the DV_CODED_TEXT is designed this way. I have thought about it and the only reason why this is done is probably to get a faster access to the rubric and maybe also when there are no translations for the term in a specific language in order to get a 'default' rubric at all times. it is to guarantee a readable record / extract by sits not having access to Snomed-ct, or a running copy in their language etc; this has been a long-standing requirement, and I believe a still valid one (just think outside the rich countries). > Maybe you're right, the definitions could be added as comments, but for proprietary terminology like SNOMED CT this will mean that these kind of archetypes can only be distributed to people that have paid the license. yes, the position on this needs to be clear. I would have thought free use of terms with no relationships should be safe... - thomas beale --- ## Post #22 by @Tim_Churches Bert Verhees wrote: > Williamtfgoossen@cs\.com schreef: >> In een bericht met de datum 18\-12\-2006 18:00:54 West\-Europa >> \(standaardtijd\), schrijft mattias\.forss@gmail\.com: >> >>> Maybe you're right, the definitions could be added as comments, but >>> for proprietary terminology like SNOMED CT this will mean that these >>> kind of archetypes can only be distributed to people that have paid >>> the license\. >> >> Sorry, but Snomed CT cannot be considered a proprietary terminology >> given the formal international SDO status from January onward\. Although it is not at all clear that SNOMED CT will be made freely available to everyone on Earth after the establishment of the SDO\. My understanding is that individual states \(countries\) will need to sublicense it from the SDO, in return for a fee, and can then choose to sublicense it \(for free, or for a fee\) to its citizens and residents\. The main role of the SDO is to diversify the ownership of the SNOMED CT intellectual property from the just the College of American Pathologists to an international non\-profit governance body \(the SDO\)\. But "non\-profit" does not necessarily mean "available at no cost to all god's children"\. Thus, it may not be legal to transfer archetype definitions containing parts of SNOMED CT between jurisdictions, even if both the source and the target jurisdiction both provide SNOMED CT for free to their residents, because that free and universal national\-level provision will be under \*different\* sublicences, which almost certainly forbid transfer of SNOMED CT outside the jurisdiction in question \(I am pretty sure the Australian sublicense for SNOMED CT imposes such restrictions\)\. Advice from lawyers who are a\) familiar with SNOMED CT licensing and b\) with open source and related concepts, is essential here\. Much will depend on national copyright laws, I suspect, as some countries have specific "fair use" or "fair dealing" clauses in their copyright laws which may allow small parts of SNOMED CT to be incorporated into archetype definitions regardless of licensing arrangements, but many countries do not have such provisions\. Expert advice is required before proceeding to far with embedding parts of SNOMED CT in archetype definitions, so that the implications and consequent limitations are well understood\. My view is that embedding aspects and/or parts of SNOMED CT in archetypes is unavoidable, but the implications for data interchange between countries needs to be understood\. None of these issues are specific to openEHR \- they relate to any mechanism for embedding or encoding information with SNOMED CT\. It may well be that changes to national SNOMED CT sublicenses are needed to overcome difficulties\. That should not be regarded as impossible \- the SNOMED CT national and international governance bodies are keen for SNOMED CT to be used, not for it to sit on a shelf due to licensing problems\. And no\-one is making huge profits from SNOMED CT, thus greed does not complicate matters\. Tim C --- ## Post #23 by @thomas.beale That would be nice if it were true, but the conditions of use that seem to have been formulated in Australia seem to be very restrictive indeed - I think we need to check on the conditions of use offered by the relevant national agencies... - thomas --- ## Post #24 by @DavidIngram Just to say thank you to Tim C and others for the clear and helpful recent posts concerning SNOMED\-CT and openEHR\. I am in frequent contact with Prof Martin Severs, Chairman of the NHS Clinical Data Standards Board, here in England\. Martin is very busy with the international negotiations towards the new SNOMED SDO and so I have forwarded this and other recent posts about SNOMED\-CT, from the openEHR lists, to him\. David Ingram --- ## Post #25 by @Gavin_Brelstaff http://www.cs.man.ac.uk/~qamarr/papers/Medinfo_Paper_RQamar.pdf Semantic Issues in Integrating Data from Different Models to Achieve Data Interoperability Rahil Qamara, Alan Rector Abstract Matching clinical data to codes in controlled terminologies is the first step towards achieving standardisation of data for safe and accurate data interoperability\. The MoST automated system was used to generate a list of candidate SNOMED CT code mappings\. The paper discusses the semantic issues which arose when generating lexical and semantic matches of terms from the archetype model to relevant SNOMED codes\. It also discusses some of the solutions that were developed to address the issues\. The aim of the paper is to highlight the need to be flexible when integrating data from two separate models\. However, the paper also stresses that the context and semantics of the data in either model should be taken into consideration at all times to increase the chances of true positives and reduce the occurrences of false negatives\. --- ## Post #26 by @Andrew_Patterson An interesting paper\. I'm not sure Rahil or Alan are on this list?? Perhaps they should be cc'ed in on any discussion\. Many of the points about the difficulties of doing archetype binding to snomed are excellent\. I was just wondering about this quote\.\. --- ## Post #27 by @system A few remarks. Binding of items in an archetype to coding systems happens at two places (at least): names of labels and data fields. For both internal and external coding systems (including Snomed) can be used. There are at least two different kinds of Archetypes we must consider: - the General Archetype: one that lists all items that can be recorded and exchanged about a specific topic - the Specialised Archetype: the Template. The Template consists of a Labelled structure filled with Archetypes, that is designed for a specific context and therefor has almost no optionallities left. This what a community has decided to use in their specific context. The General Archetypes in their data fields will have almost no fine grained binding to internal and external code sets. It will have strict bindings to internal or external coding systems. The Template will have strict bindings to internal and external code sets and coding systems. We can expect that these coding systems used in Templates are (internal or external) local ones, perhaps national ones, perhaps international ones. A strict binding to a local service is understandable. I foresee that an EHR-system without access to a local or remote Terminology Server is to inflexible. At the EHR-system level there will be increased separations of concerns: - Persistence layer - Document layer: archetype, template layer - Terminology Layer: coding system layer and some more. 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 #28 by @Rahil Hi and Happy New Year to everyone ! Andrew Patterson wrote: > ``` > > ``` > > > ``` > > [http://www.cs.man.ac.uk/~qamarr/papers/Medinfo_Paper_RQamar.pdf](http://www.cs.man.ac.uk/~qamarr/papers/Medinfo_Paper_RQamar.pdf) > > > > > > ``` > > ``` > > An interesting paper. I'm not sure Rahil or Alan are on this list?? > Perhaps they should be cc'ed in on any discussion. Many of > the points about the difficulties of doing archetype binding > to snomed are excellent. I was just wondering about this > quote.. > > -------- > The intended purpose of archetypes is to empower clinicians > to define the content, semantics and data-entry interfaces of > systems independently from the information systems [1]. > Archetypes were selected because of their feature to separate > the internal model data from terminology. The internal data is > assigned local names which can later be bound or mapped to > external terminology codes. This feature eliminates the risk of > making changes to the model whenever the terminology > changes. > --------- > > In particular, I am referring to the concept of being bound > 'later'. > > This is a point of view on archetypes that I had never really > considered. I had always assumed that the construction of > the archetype definition and the selection of terminology > binding would be part of the same process, either done by > the same person or the same clinical group. The paper discusses > some of the mapping problems that can occur when this > process is split, but surely that would never be the case? > > ``` Infact the paper does not state that problems in the mapping process occur because of this 'split' feature. However, it tries to highlight that one of the problems in finding suitable SNOMED matches arises because the mapping is done at a LATER stage. For instance the evaluation of my MoST system was done by clinicians who were not the original authors of the archetype. This led sometimes to issues of understanding the need for using a particular term in the archetype model and sometimes its semantics. This problem arises mostly when there are different people modeling and mapping the same archetype. However, the aim is to include the mapping feature in Archetype Editors so that the original authors of the archetypes can themselves perform the mapping as well (of course with consensus if and when required). The system at present is performing mappings on pre-modeled archetypes depriving it the luxury of having access to the author. That having said, any model aimed at reuse should be explicit in its use and definitions to keep ambiguity at its minimum! Which is yet another point in case ! > ``` > The intention would be that within some master archetype > repository (be this a local/organisational/national repository), > the archetypes would include a full set of terminology > codes? (I can understand how one might think this because > none of the sample archetypes in the openehr repository have much > terminology data but that will surely that is a temporary situation > and the intention is that a real official repository i.e. one run > by nehta or nhs etc would have the term codes for their realm?) > > Which brings me onto a related point - at the snomed > workshop in Melbourne late last year there was an > (impressive) demonstration of some of the template building > tools written by Ocean. Part of the demonstration involved > creating a complex binding to snomed based on a > small query language (effectively the query was > "select all 'is_a' children of this snomed code up to a maximum > depth of 5"). This query binding was placed into the relevant > archetype as a URL reference to a webservice. Doesn't relying > on a URL in the ADL definition > make archetypes quite brittle. i.e. when the archetype definition > is loaded into the clinical system I either have to consult the > URL straight away and store the resulting codes, or else delay > the binding and risk having the terminology codes for my > ADL disappear in the future? > > ``` I agree that this URL feature sounds a bit complex. Not having complete knowledge of the Ocean methodology and objective makes it rather difficult to comment though. However, 'is_a' trees are only part of the solution to the binding/mapping process. There are a few archetypes that have 'is_a' terms and can be dealt with in a less complex way i.e. without the use of URL's. Though am not sure whether the Ocean team had something else in mind when using URLs. Another aspect is to constrain free text entries in archetype models with the use of more intuitive/processable archetype definitions. A simple case of limiting the list of SNOMED codes that can act as 'legal' archetype entries should spare the clinician of too much and too frequent access to back-end codes and procedures else it'll simply discourage them from using the system! Perhaps someone from the Ocean team might want to throw some more light on this URL feature. It'll be interesting to know their view point. Thanks Regards Rahil --- ## Post #29 by @Hugh_Leslie Hi All The Ocean Archetype Editor allows the designer to map one or more coding systems to a particular term or to map a set of terms from a coding system to a particular element to constrain the values for that element to that term set. The editor actually doesn't dictate how the terms are retrieved in the latter instance. In the demo that I did at the Oz snomed conference in December, I showed how the term set can be defined using the Ocean terminology service, and in this particular instance, it was mapped to a web service running in another state of Australia. This is really just one way of making it work and could just as easily be retrieved from a locally cached query etc. A URL is just a unique way of identifying the query that is being used. The point of the demonstration was that you could make snomed easier for clinicians to use by creating these subsets ie medication route. These subsets to be useful would need to be defined at a jurisdictional level or higher so that everyone can use the same one. This allows for a change in the query to be distributed easily and updates to the coding system to be distributed in the same way. To make this work, it will be necessary to have some centrally controlled repository that the URL or other identifier can match the query to. Analogous to archetype identifiers I guess. It may be possible to include term set queries in the archetype if some universal query language is available. I agree with Gerard and Andrew that using a particular terminology set in a generic archetype probably makes the archetype more brittle and should probably be used in templates in a particular jurisdictional setting where an archetype is constrained further for a specific use case. It will be interesting to see how this all pans out. regards Hugh --- ## Post #30 by @Rahil Hi and Happy New Year to everyone ! Andrew Patterson wrote: > ``` > > ``` > > > ``` > > [http://www.cs.man.ac.uk/~qamarr/papers/Medinfo_Paper_RQamar.pdf](http://www.cs.man.ac.uk/%7Eqamarr/papers/Medinfo_Paper_RQamar.pdf) > > > > > > ``` > > ``` > > An interesting paper. I'm not sure Rahil or Alan are on this list?? > Perhaps they should be cc'ed in on any discussion. Many of > the points about the difficulties of doing archetype binding > to snomed are excellent. I was just wondering about this > quote.. > > -------- > The intended purpose of archetypes is to empower clinicians > to define the content, semantics and data-entry interfaces of > systems independently from the information systems [1]. > Archetypes were selected because of their feature to separate > the internal model data from terminology. The internal data is > assigned local names which can later be bound or mapped to > external terminology codes. This feature eliminates the risk of > making changes to the model whenever the terminology > changes. > --------- > > In particular, I am referring to the concept of being bound > 'later'. > > This is a point of view on archetypes that I had never really > considered. I had always assumed that the construction of > the archetype definition and the selection of terminology > binding would be part of the same process, either done by > the same person or the same clinical group. The paper discusses > some of the mapping problems that can occur when this > process is split, but surely that would never be the case? > > ``` Infact the paper does not state that problems in the mapping process occur because of this 'split' feature. However, it tries to highlight that one of the problems in finding suitable SNOMED matches arises because the mapping is done at a LATER stage. For instance the evaluation of my MoST system was done by clinicians who were not the original authors of the archetype. This led sometimes to issues of understanding the need for using a particular term in the archetype model and sometimes its semantics. This problem arises mostly when there are different people modeling and mapping the same archetype. However, the aim is to include the mapping feature in Archetype Editors so that the original authors of the archetypes can themselves perform the mapping as well (of course with consensus if and when required). The system at present is performing mappings on pre-modeled archetypes depriving it the luxury of having access to the author. That having said, any model aimed at reuse should be explicit in its use and definitions to keep ambiguity at its minimum! Which is yet another point in case ! > ``` > The intention would be that within some master archetype > repository (be this a local/organisational/national repository), > the archetypes would include a full set of terminology > codes? (I can understand how one might think this because > none of the sample archetypes in the openehr repository have much > terminology data but that will surely that is a temporary situation > and the intention is that a real official repository i.e. one run > by nehta or nhs etc would have the term codes for their realm?) > > Which brings me onto a related point - at the snomed > workshop in Melbourne late last year there was an > (impressive) demonstration of some of the template building > tools written by Ocean. Part of the demonstration involved > creating a complex binding to snomed based on a > small query language (effectively the query was > "select all 'is_a' children of this snomed code up to a maximum > depth of 5"). This query binding was placed into the relevant > archetype as a URL reference to a webservice. Doesn't relying > on a URL in the ADL definition > make archetypes quite brittle. i.e. when the archetype definition > is loaded into the clinical system I either have to consult the > URL straight away and store the resulting codes, or else delay > the binding and risk having the terminology codes for my > ADL disappear in the future? > > ``` I agree that this URL feature sounds a bit complex. Not having complete knowledge of the Ocean methodology and objective makes it rather difficult to comment though. However, 'is_a' trees are only part of the solution to the binding/mapping process. There are a few archetypes that have 'is_a' terms and can be dealt with in a less complex way i.e. without the use of URL's. Though am not sure whether the Ocean team had something else in mind when using URLs. Another aspect is to constrain free text entries in archetype models with the use of more intuitive/processable archetype definitions. A simple case of limiting the list of SNOMED codes that can act as 'legal' archetype entries should spare the clinician of too much and too frequent access to back-end codes and procedures else it'll simply discourage them from using the system! Perhaps someone from the Ocean team might want to throw some more light on this URL feature. It'll be interesting to know their view point. Thanks Regards Rahil --- ## Post #31 by @Rahil Thanks for the much clearer explanation Hugh. Is there a power point presentation (pref the Oz Snomed Conf) and/or paper(s) about your work that you can share with us? Thanks Rahil Hugh Leslie wrote: --- ## Post #32 by @Andrew_Patterson > The system at present is performing mappings on pre\-modeled archetypes > depriving it the luxury of having access to the author\. This is what I meant by the 'split' case \- a split between the people/group constructing the archetype, and the people doing the binding \(in this Sam writing the archetype and you guys doing the terminology stuff\)\. It doesn't lessen your points about the difficulties of doing the terminology mapping \- I just wanted to clarify that the plan in the 'best case' is that there wouldn't be so much of a split \(i\.e\. you'd be in communication with the people writing the archetype, or it would all be done within one tool by the same author\) > I agree that this URL feature sounds a bit complex\. Not having complete > knowledge of the Ocean methodology and objective makes it rather difficult > to comment though\. However, 'is\_a' trees are only part of the solution to > the binding/mapping process\. There are a few archetypes that have 'is\_a' > terms and can be dealt with in a less complex way i\.e\. without the use of > URL's\. Other than actually enumerating the term codes in the ADL file, what other mechanism is there other than URLs? > Though am not sure whether the Ocean team had something else in mind > when using URLs\. The URL system is not inherently bad \- it solves the problem in a relatively clean way that allows lots of room for future developments in terminologies without constraining the solutions\. I just worry that with complex terminologies like snomed being used more often it may be useful to have an inbetween solution i\.e\. simplest\)   list of codes typed in '123123', '3242342', '123123' \* moderate \*\)   simple langauge like "limit depth 5 \(is\_a\('102323','arm fracture'\)\)" complex\)    http://www.termserver.com/saved_query?realm=uk&concept_root=1231231 Andrew --- ## Post #33 by @Hugh_Leslie I actually didn't use a powerpoint as the whole demo was done with live software showing the process of building a query, binding it to an archetype, creating a template, dragging an element on to a form, compiling the form into an application and then showing that the element was bound to a particular termset that could be searched and selected from. --- ## Post #34 by @Andrew_Patterson > The point of the demonstration was that you could make snomed easier for > clinicians to use by creating these subsets ie medication route\. These > subsets to be useful would need to be defined at a jurisdictional level or > higher so that everyone can use the same one\. This allows for a change in > the query to be distributed easily and updates to the coding system to be > distributed in the same way\. To make this work, it will be necessary to > have some centrally controlled repository that the URL or other identifier > can match the query to\. Analogous to archetype identifiers I guess\. It may > be possible to include term set queries in the archetype if some universal > query language is available\. Just thinking long term, just say some archetype was defined for some little used data entry\. The archetype \(which includes a URL term binding\) is put into the clinical system\. Some data matching the archetype is entered \- the system checks that the terminology codes for allowed data match those returned in the URL and all is good\. 10 years down the track, someone goes to do the same thing\. Given Australian government departments barely keep their names for more than a few years, what are the chances the URL is still working? If it is a local reference, what are the chances the machines still have the same IP addresses or names? Can the clinical system still rely on the term codes it cached 10 years ago? I think having URL's in the archetype definition mixes the 'configuration' of the system with the definition\. I guess I would like to see some sort of query language in this space so that one could say <"at0004"> = <    <"snomed"> = <all 'route of medication' where refset\('australia'\)>   <"icd\-10"> = <12312\-23> > or something similar in the actual ADL\. Each terminology/classification would probably need its own language and I have no idea how to define any of this, so I guess I'm not really being much help, but I just wanted to see what the general thinking was about this problem\. Andrew --- ## Post #35 by @Hugh_Leslie Archetypes do allow for the possibility of an internal code set \- each internal code can map to one or more terminologies \- analogous to the "list of codes typed in '123123', '3242342', '123123'"\. This solution is probably the best for very small sets such as patient sex or similar\. --- ## Post #36 by @Andrew_Patterson > <"at0004"> = < >    <"snomed"> = <all 'route of medication' where refset\('australia'\)> >   <"icd\-10"> = <12312\-23> > > I should clarify I'm talking about the "constraint\_binding" section of the ADL file here \(section 7\.6\.6 in the ADL spec\) \(and I have completely butchered the syntax here cos I was doing it off the top of my head\) I don't think any query language would probably be necessary for the "term\_binding" section of an archetype \(they could just be enumerated\) \- though as pointed out in Rahil's paper there are still issues in finding the correct codes to put in\. Andrew --- ## Post #37 by @Andrew_Patterson > Archetypes do allow for the possibility of an internal code set \- each > internal code can map to one or more terminologies \- analogous to the "list > of codes typed in '123123', '3242342', '123123'"\. Yes, sorry I should have been clearer \- archetypes already have the simple list form and the more powerful yet complex URL form\. I'm arguing for an \(as yet unspecified\) middle ground to be added\.\. > > simplest\) > > list of codes typed in '123123', '3242342', '123123' > > \* moderate \*\) > > simple langauge like "limit depth 5 \(is\_a\('102323','arm fracture'\)\)" > > complex\) > > http://www.termserver.com/saved_query?realm=uk&concept_root=1231231 Andrew --- ## Post #38 by @Rahil Andrew Patterson wrote: > > The system at present is performing mappings on pre-modeled archetypes > > depriving it the luxury of having access to the author. > > This is what I meant by the 'split' case - a split between the people/group > constructing the archetype, and the people doing the binding (in this > Sam writing the archetype and you guys doing the terminology stuff). It > doesn't lessen your points about the difficulties of doing the terminology > mapping - I just wanted to clarify that the plan in the 'best case' is > that there wouldn't be so much of a split (i.e. you'd be in communication > with the people writing the archetype, or it would all be done within one > tool by the same author) Right thats fine. Atleast there is a consensus in thought here ! > > I agree that this URL feature sounds a bit complex. Not having complete > > knowledge of the Ocean methodology and objective makes it rather difficult > > to comment though. However, 'is_a' trees are only part of the solution to > > the binding/mapping process. There are a few archetypes that have 'is_a' > > terms and can be dealt with in a less complex way i.e. without the use of > > URL's. > > Other than actually enumerating the term codes in the ADL file, what other > mechanism is there other than URLs? I have a question about the context in which the term URL is being used in this discussion. What does the URL lead to - is it some sort of web page with a block of the terminology displayed enabling the user to pick a few relevant codes or is it some sort of metadata for the location of the list of relevant codes? Another form could be to have a Tree Graph of a subset of the entire terminology with access to only those paths (to 5 depth level or more/less) that belong to the set of 'allowable' codes. It could make the task easier and probably more interesting to the user. However, the graph should be able to display the concept definitions and/or annotations to enable an informed decision to be taken when selecting codes for mapping. Rahil --- ## Post #39 by @system Hi, Dear Andrew, > > Just thinking long term, just say some archetype was defined for > > some little used data entry. The archetype (which includes a URL > > term binding) is put into the clinical system. Some data matching > > the archetype is entered - the system checks that the terminology codes > > for allowed data match those returned in the URL and all is good. 10 > > years down the > > track, someone goes to do the same thing. Given Australian government > > departments barely keep their names for more than a few years, what are > > the chances the URL is still working? If it is a local reference, what are the > > chances the machines still have the same IP addresses or names? > > Can the clinical system still rely on the term codes it cached 10 years > > ago? All this is precisely the reason for EuroRec (the European Institute for Health Records) to develop: - an Archetype Repository - an Archetype Inventory - plus a Quality Control Service. We do this in an European project: Q-Rec. Francois Mennerat is leading this task. We could perform this task for others as well. With regards, Gerard Freriks -- -- 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 #40 by @Mattias_Forss1 2007/1/3, Andrew Patterson <[andrewpatto@gmail.com](mailto:andrewpatto@gmail.com)>: > > The system at present is performing mappings on pre-modeled archetypes > > depriving it the luxury of having access to the author. > > This is what I meant by the 'split' case - a split between the people/group > constructing the archetype, and the people doing the binding (in this > Sam writing the archetype and you guys doing the terminology stuff). It > doesn't lessen your points about the difficulties of doing the terminology > mapping - I just wanted to clarify that the plan in the 'best case' is > that there wouldn't be so much of a split (i.e. you'd be in communication > with the people writing the archetype, or it would all be done within one > tool by the same author) > > > I agree that this URL feature sounds a bit complex. Not having complete > > knowledge of the Ocean methodology and objective makes it rather difficult > > to comment though. However, 'is_a' trees are only part of the solution to > > the binding/mapping process. There are a few archetypes that have 'is_a' > > terms and can be dealt with in a less complex way i.e. without the use of > > URL's. > > Other than actually enumerating the term codes in the ADL file, what other > mechanism is there other than URLs? > > > Though am not sure whether the Ocean team had something else in mind > > when using URLs. > > The URL system is not inherently bad - it solves the problem in a > relatively clean way that allows lots of room for future developments > in terminologies without constraining the solutions. I just worry that > with complex terminologies like snomed being used more often > it may be useful to have an inbetween solution i.e. > > simplest) > list of codes typed in '123123', '3242342', '123123' > * moderate *) > simple langauge like "limit depth 5 (is_a('102323','arm fracture'))" > complex) > [http://www.termserver.com/saved_query?realm=uk&concept_root=1231231](http://www.termserver.com/saved_query?realm=uk&concept_root=1231231) Hi, Within our team in Linköping we've discussed the potential of using OWL as a query-language for constraint bindings. It might be something worth looking into. Regards, Mattias --- ## Post #41 by @thomas.beale Andrew Patterson wrote: > ``` > This is a point of view on archetypes that I had never really > considered. I had always assumed that the construction of > the archetype definition and the selection of terminology > binding would be part of the same process, either done by > the same person or the same clinical group. The paper discusses > some of the mapping problems that can occur when this > process is split, but surely that would never be the case? > > ``` the process can easily be split and is likely to be so, e.g. in environments like the NHS where there are separate teams of experts for clinical modelling and archetypes. There are other reasons as well: - an archetype is instantly usable even without terminology binding being figured out; it may be that prototype testing or a non-terminology enabled rollout is required - many things in the 'ontology' section of an archetype come after the main modelling exercise: translation, addition of other term bindings; adjustment of term bindings - an archetype may be published in a 'vanilla' form, with term bindings only being added in local situations (although clearly an internationally agreed binding to internationally use terminologies is preferable). > ``` > The intention would be that within some master archetype > repository (be this a local/organisational/national repository), > the archetypes would include a full set of terminology > codes? > ``` the archetypes would only include some cods that are direct maps for the 'at' coded terms in the archetype. But for attributes where the value (i.e. the answer) is a term value set from a terminology like snomed, the approach is to us an 'ac' code to refer to a query to the terminology service, whose result when run is the subset from which the user is allowed to choose at runtime. This query is stored in a terminology query service, only the id is referenced in the archetype. > ``` > (I can understand how one might think this because > none of the sample archetypes in the openehr repository have much > terminology data but that will surely that is a temporary situation > and the intention is that a real official repository i.e. one run > by nehta or nhs etc would have the term codes for their realm?) > > ``` correct - but not because of the lack of the archetype repository (one is under construction); the reason is that the community has not yet settled on a way of identifying or expressing subsetting queries to a terminology service; good progress is being made here; at Ocean we have developed a simple language to do it, which turns out to be very nearly the same semantics as the OWL-based expressions described by Alan Rector at a recent Semantic Mining meeting in Paris at which we were both present. > ``` > Which brings me onto a related point - at the snomed > workshop in Melbourne late last year there was an > (impressive) demonstration of some of the template building > tools written by Ocean. Part of the demonstration involved > creating a complex binding to snomed based on a > small query language (effectively the query was > "select all 'is_a' children of this snomed code up to a maximum > depth of 5"). > ``` right - this is the language I mention above. > ``` > This query binding was placed into the relevant > archetype as a URL reference to a webservice. Doesn't relying > on a URL in the ADL definition > make archetypes quite brittle. i.e. when the archetype definition > is loaded into the clinical system I either have to consult the > URL straight away and store the resulting codes, or else delay > the binding and risk having the terminology codes for my > ADL disappear in the future? > > ``` why would that happen? This isn't semantic brittleness in the archetype - the meaning doesn't change; it may be that you don't have a reliable deployment environment. This is why we built the Ocean Terminology Server to provide a query cache for any user site. > ``` > It just seems to me that if snomed is indeed the way things > seem to be going, that most terminology references in ADL will > either very simple (this node = 34242343) or need a moderate > level of complexity (all nodes in the 'is_a' 'route of administration' > heirarchy, but not ones with a qualifier 'blah'). Will all these > later style terminology bindings need to be done with URL's? > > ``` URLs won't include the query statement itself (originally we thought they would, but having built a full terminology server and query subsetter has taught us otherwise); the URL will just include an id of the query. Working out an identification system is the next trick.... > ``` > Isn't it going to be hard to keep these URL's alive for the > lifetime of the archetypes? On the other hand, if the URL's > are bound on archetype entry, how will they keep up with > changes to the terminology? > > Should there be a small query language for terminology > built into ADL? > > ``` as I say, that's what I thought we would be doing a year ago; experience has shown that we need to push things apart by one further level, and only allow subset query ids in archetypes (remember - these are what is mapped to the 'ac' codes; you can still put snomed or whatever codes in the 'at' code binding part if you want). None of this is simple and it has taken both us (in the industrial context) and the Manchester group over 5 years from the statement of need to get to a solution - which looks quite simple now we seem to have it (or be close), but I have to admit, we were groping in the dark for a long time.... - thomas beale --- ## Post #42 by @thomas.beale Andrew Patterson wrote: > Given Australian government > departments barely keep their names for more than a few years, what are > the chances the URL is still working? If it is a local reference, what are the > chances the machines still have the same IP addresses or names? >   this points to the need to use safe URLs that will work\. Do we think the URL "http://snomed.org" is safe? Maybe we need "http://terminology.net" or somesuch\. The use of URLs whose meaning will not change over time is not to be taken lightly\.\.\. > Can the clinical system still rely on the term codes it cached 10 years > ago? >   probably not \- just consider if they had cached the answer to the query "types of hepatitis" in 1985 compared to now \- the answer now is a larger set of codes\. > I think having URL's in the archetype definition mixes the 'configuration' of > the system with the definition\. I guess I would like to see some sort of > query language in this space so that one could say > > <"at0004"> = < >    <"snomed"> = <all 'route of medication' where refset\('australia'\)> >   <"icd\-10"> = <12312\-23> >   this is where we were about 1\-2 years ago in the thinking of this problem; now we have reached a point of: \* firstly having realised that the query should not itself go into the archetype, only an id for the query \* secondly we have a basic query language \("subset expression language" would be closer to the mark\); the Manchester group has worked out something like an OWL\-based equivalent from a theoretical perspective \(I don't want people to think we were first here \- they have been working on this a long time as well \- as far as I can work out, we have done it more or less independently over the last 2 years, and the results as at Paris in early December point toward being able to publish a common expression syntax/language for this purpose very soon\)\. I am not sure what we should be doing about ideas like "refset\('australia'\)" though\.\.\.\. \- thomas beale --- ## Post #43 by @Andrew_Patterson > make archetypes quite brittle\. i\.e\. when the archetype definition > is loaded into the clinical system I either have to consult the > URL straight away and store the resulting codes, or else delay > the binding and risk having the terminology codes for my > ADL disappear in the future? > > why would that happen? This isn't semantic brittleness in the archetype \- > the meaning doesn't change; it may be that you don't have a reliable > deployment environment\. This is why we built the Ocean Terminology Server to > provide a query cache for any user site\. So is the URL just a name/ident for the terminology \(ala XML namespaces\) or an actual "I'm a HTTP server URL, send me a GET request for some codes"\.\. I can understand how the first adds no extra brittleness \- but surely you can see how the second adds more than just meaning into the archetype\. Embedded in the 'meaning' is the configuration for your deployment environment\.\. so whether the URL is http://snomed.org/query2323 or http://127.0.0.1:111/query434, the archetype now has embedded within it a commitment to maintain that particular server, at that particular port under that particular name running for the life of the archetype\. If I decide to deploy a new local terminology server 5 years down the track, do I need to get my system administrators to load each archetype in the system and manually change the port number of the server in all the term binding URLs? It just smells a bit funny to me \- I can't put my finger on exactly why or propose a better way, but it just gives me the vibe of something that could come back and bite people on the arse down the track\. > as I say, that's what I thought we would be doing a year ago; experience > has shown that we need to push things apart by one further level, and only > allow subset query ids in archetypes \(remember \- these are what is mapped to > the 'ac' codes; you can still put snomed or whatever codes in the 'at' code > binding part if you want\)\. > > None of this is simple and it has taken both us \(in the industrial context\) > and the Manchester group over 5 years from the statement of need to get to a > solution \- which looks quite simple now we seem to have it \(or be close\), > but I have to admit, we were groping in the dark for a long time\.\.\.\. I admit I am playing catch up here and I accept that your results are from quite a bit of experience on your part \- can you give me a brief background on the reasons for the change in thinking from a year ago with embedded queries in the archetype to the current thinking\. Thanks Andrew --- ## Post #44 by @Colin_Sutton > Thomas Beale wrote > > Andrew Patterson wrote: > > Given Australian government > > departments barely keep their names for more than a few years, what are > > the chances the URL is still working? If it is a local reference, what are the > > chances the machines still have the same IP addresses or names? > > > this points to the need to use safe URLs that will work\. Do we think the > URL "http://snomed.org" is safe? Maybe we need "http://terminology.net" > or somesuch\. The use of URLs whose meaning will not change over time is > not to be taken lightly\.\.\. \[\.\.\.\] A safe URL is needed for each clinical terminology authority\. \(e\.g\. standards are managed by ISO, Standards Australia etc\.; SNOMED UK and SNOMED AUS may have country specific needs\) > > I think having URL's in the archetype definition mixes the 'configuration' of > > the system with the definition\. I guess I would like to see some sort of > > query language in this space so that one could say > > > > <"at0004"> = < > > <"snomed"> = <all 'route of medication' where refset\('australia'\)> > > <"icd\-10"> = <12312\-23> > > Agreed\. > this is where we were about 1\-2 years ago in the thinking of this > problem; now we have reached a point of: > \* firstly having realised that the query should not itself go into the > archetype, only an id for the query \[\.\.\.\] > I am not sure what we should be doing about ideas like > "refset\('australia'\)" though\.\.\.\. > \- thomas beale The query tool needs to manage this, as it should manage the language\. I suggest the user \(or user environment\) should be able to select whether to look at local terminology or that of another country \(the default may be where the patient's record was created, and the patient was travelling at the time or subsequently emigrated\)\. On storing a new event, the term accessed at the time should be stored in the record, not \(just\) the SNOMED code or URL, because the terminology may be updated on the server, and a future access should show the info known at the time of entry\. Colin Sutton \(not an authoritative answer\!\) --- ## Post #45 by @system EuroRec, the European Institute for Health Records, has the intention to become the neutral point of reference for several services needed around the EHR. One of those Services are an Archetype and Template Repository and Inventory. Eurorec intends to do the same for Coding Systems. This will create the stable managed environments EHR-systems and EHR's need. 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 #46 by @thomas.beale Andrew Patterson wrote: >> make archetypes quite brittle\. i\.e\. when the archetype definition >> is loaded into the clinical system I either have to consult the >> URL straight away and store the resulting codes, or else delay >> the binding and risk having the terminology codes for my >> ADL disappear in the future? >> >> why would that happen? This isn't semantic brittleness in the archetype \- >> the meaning doesn't change; it may be that you don't have a reliable >> deployment environment\. This is why we built the Ocean Terminology Server to >> provide a query cache for any user site\. >>     > So is the URL just a name/ident for the terminology \(ala XML namespaces\) > or an actual "I'm a HTTP server URL, send me a GET request for some codes"\.\. >   The exact structure of the URL is the part that is currently not determined\. Its logical meaning is exemplified by: terminology = xxxx subset = a query stored somewhere whose meaning is "any kind of infection that has\-site liver" for example: terminology = xxxx subset = 1234\-5678\-91bc\-def0 Currently we have a way to write such subset expressions \(significantly more complex than this\) and evaluate them\. If the syntax of such an expression were standardised and therefore evaluatable by any terminology service containing an instance of snomed\-ct, then we would probably design the URL to simply indicate the terminology and the query id\. But \- since the id of the query will make sense against multiple terminologies \(i\.e\. "any kind of infection that has\-site liver" could possibly be evaluated against ICD10 or some other disease terminology\) then the namespace of the queries is truly global; if not, then query namespaces are with respect to terminologies\. My guess is that a few hundred will handle most questions on most forms\. There will also be queries that are subsets of existing subsets\. Even with a few hundred, the ids need to be well\-designed \(it may just be Guids as I have implied above, but then there has to be an agreed registry of subset queries, and an agreement of whether they are globally unique or not\)\. The problem is to get some international agreement on how to approach the identification problem\. Technically it is easy either way\. > I can understand how the first adds no extra brittleness \- but surely you > can see how the second adds more than just meaning into the > archetype\. Embedded in the 'meaning' is the configuration for your > deployment environment\.\. so whether the URL is http://snomed.org/query2323 > or http://127.0.0.1:111/query434, the archetype now has embedded within > it a commitment to maintain that particular server, at that particular port > under that particular name running for the life of >   we certainly would not want to do this \- there should be no implication of a server; only of a particular query\. > the archetype\. If I decide to deploy a new local terminology server > 5 years down the track, do I need to get my system administrators > to load each archetype in the system and manually change the > port number of the server in all the term binding URLs? >   which is the reason for not doing that\. URIs properly used should never identify servers \- Berners\-Lee got that right years ago, it's just that almost no\-one realised how important he was, and we live in a world of broken URLs rather than logically sound URIs\. > It just smells a bit funny to me \- I can't put my finger on exactly why > or propose a better way, but it just gives me the vibe of something > that could come back and bite people on the arse down the track\. >   which is why we need to be careful with this\.\.\.same as for codes in terminologies \(see e\.g\. Cimino's desiserata, or rules on good terminology design\)\. > >> None of this is simple and it has taken both us \(in the industrial context\) >> and the Manchester group over 5 years from the statement of need to get to a >> solution \- which looks quite simple now we seem to have it \(or be close\), >> but I have to admit, we were groping in the dark for a long time\.\.\.\. >>     > I admit I am playing catch up here and I accept that your results are > from quite a bit of experience on your part \- can you give me a brief > background on the reasons for the change in thinking from > a year ago with embedded queries in the archetype to the current > thinking\. >   well, one obvious \(to us now\) reason is that the correct formal query for "any problem with site liver" might not be gotten right the first time round\. If we embedded the query in every archetype that had an attribute with that meaning, then you can see the maintenance nightmare and potential for error\. If we instead only have to change it once in an authoritative service \(or the terminology itself, assuming the subset queries could be added to a chapter of the terminology\.\.\.\) then life is a lot simpler\. Also, newer subsetting syntaxes might come along; again the logical meaning of the archetype doesn't change, so we don't want it to have the actual subset query expression in there, just the id of the subset\. \- thomas --- ## Post #47 by @thomas.beale Colin Sutton wrote: > The query tool needs to manage this, as it should manage the language\. I suggest the user \(or user environment\) should be able to select whether to look at local terminology or that of another country \(the default may be where the patient's record was created, and the patient was travelling at the time or subsequently emigrated\)\. >   the main thing that needs to be known is if snomed\-ct\-AUS is a proper superset of snomed\-ct\-INT \(or however these variants will be designated\); i\.e\. that there are no incompatibilities between the two\. > On storing a new event, the term accessed at the time should be stored in the record, not \(just\) the SNOMED code or URL, because the terminology may be updated on the server, and a future access should show the info known at the time of entry\. > well, snomed is designed never to change the meaning of a code, so having the code should be safe\. But in openEHR we always store the code, the rubric \(in the local language\) and the full id of the terminology \(including version if relevant\)\. \- thomas beale --- ## Post #48 by @Sam Andrew I just want to stress that the URLs do not have to be real (as in XML Schema) - but they are IDs for the termset that they define and can be kept in a database somewhere. We could have used anything - but a URL does have the advantage that it might point to something. It doesn't matter if the website closes down - the URL in the archetype will still get the right query from the Terminology server. Cheers, Sam Andrew Patterson wrote: --- ## Post #49 by @Sam Not at all - just see the URL as a Query ID - it is completely separate from the query spec and terminology service. Sam Andrew Patterson wrote: --- ## Post #50 by @Andrew_Patterson > Schema\) \- but they are IDs for the termset that they define and can be kept > in a database somewhere\. We could have used anything \- but a URL does have > the advantage that it might point to something\. It doesn't matter if the > website closes down \- the URL in the archetype will still get the right > query from the Terminology server\. Yep, it all makes sense to me now\. I had just misunderstood them to be purely URL's, rather than URI's\. Perhaps the documentation should have some samples showing a non\-URL forms as well\. like urn:www\-terminology\-org:snomed:1234\-5678\-91bc\-def0 or something\. Andrew --- **Canonical:** https://discourse.openehr.org/t/suggestions-re-term-binding-in-archetype-editor/14597 **Original content:** https://discourse.openehr.org/t/suggestions-re-term-binding-in-archetype-editor/14597