# Using SNOMED CT term bindings and missing “substrate” information **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2024-08-12 10:18 UTC **Views:** 203 **Replies:** 16 **URL:** https://discourse.openehr.org/t/using-snomed-ct-term-bindings-and-missing-substrate-information/5563 --- ## Post #1 by @borut.jures I hope that the licensing limitations for using SNOMED CT term bindings are resolved and more archetypes will be coded with SNOMED CT in the future. While reading SNOMED CT documentation, I’ve come upon the “Substrate” section: https://confluence.ihtsdotools.org/display/DOCCDS/3.3.+Substrate This got me thinking that archetypes are missing the “substrate” information for used SNOMED CT codes (to simplify they are missing SNOMED CT “edition” and “release date”). This could be added at the archetype level or even at the term_bindings level (in case clinical modelers expect to use different releases in the same archetype). The “substrate” information should also be stored in data instances. > Note: The above paragraph reflects the RM model where there is a Locatable.code (of type Terminology_term). openEHR RM 1.1.0 doesn’t have such an attribute but it would be useful. Maybe even Locatable.codes for a list of codes to enable storing multiple codes found in term_bindings into the data. @thomas.beale has an RM with Locatable.code and one advantage of it is that tools can use SNOMED CT (and LOINC,...) codes directly instead of at-codes and can even skip paths for querying/processing data. It also helps when mapping data to/from openEHR. External value sets which use SNOMED CT codes should also specify “substrate” information for their codes. In my understanding the “substrate” of a chosen SNOMED CT code from an external value set could be different from the one specified for the template. Making sure that the correct “substrate” information is used and recorded in archetypes/data is a major undertaking for clinical modelers but it is important for data quality (in my layperson understanding). ​​Please correct me if I misunderstood this (so that I can stop worrying about it :blush:). p.s. Useful discussion: Binding archetypes to SNOMED as an ontology? https://discourse.openehr.org/t/binding-archetypes-to-snomed-as-an-ontology/364/ --- ## Post #2 by @yampeku I think the safest way to express the substrate would be with snomed standard URIs https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard Taking an example of that website The concept "404684003 **|**Clinical finding**|** in the 20160731 international release ``` http://snomed.info/id/900000000000207008/version/20160731/id/404684003 ``` --- ## Post #3 by @ian.mcnicoll The TERMINOLOGY_ID class in openEHR does already carry a .version_id string, so is identical to FHIR in that regard This can be expressed in the SNOMED binding or at run-time as e.g. SNOMED-CT(134567). I guess release date could be added to that string However keeping track of this and indeed the release date to every bind point is a really complex overhead to maintain at archetype level. With regards to LOCATABLE.code, whislt I donlt disagree with this, we can actually simulate that quite readily via the .mappings attribute on DV_TEXT/CODED_TEXT. So 'code' equates to a mapping value with e.g a SNOMED code or LOINC code. This is what Better have done with their AQL extension. --- ## Post #4 by @borut.jures [quote="ian.mcnicoll, post:3, topic:5563"] the .mappings attribute on DV_TEXT/CODED_TEXT [/quote] This solves storing the codes for DATA_VALUEs, however CLUSTER/ELEMENT can also have their own SNOMED CT code (this is where something like `LOCATABLE.mappings` would come handy) :thinking: Example is `ELEMENT[at0004]` in the [Blood pressure archetype](https://ckm.openehr.org/ckm/archetypes/1013.1.3574). --- ## Post #5 by @ian.mcnicoll Mappings are also available on LOCATABLE.name BTW - I have reread the SNOMED cdocument and this IMO is a great example of why it is generally a bad to use ECL to trigger decision support against a SNOMED hierarchy, especially in a high-risk CDS context. I would nearly always hand-construct/ control an extensional Valueset. @mikael - what are your thoughts on this? As well as concepts being removed/ altered, new concepts may be added that interfere with the CDS. 'Lock em Down' to coin a phrase ;) --- ## Post #6 by @ian.mcnicoll https://chat.fhir.org/#narrow/stream/179166-implementers/topic/.24validate-code.20using.20many.20value.20set.20versions/near/153964786 --- ## Post #7 by @ian.mcnicoll Example of mappings against LOCATABLE.name ```JSON { "@class": "ELEMENT", "name": { "@class": "DV_TEXT", "value": "Systolic", "mappings": [ { "@class": "TERM_MAPPING", "match": "=", "target": { "@class": "CODE_PHRASE", "terminology_id": { "@class": "TERMINOLOGY_ID", "value": "SNOMED-CT" }, "code_string": "271649006" } } ] } } ``` --- ## Post #8 by @mikael [quote="ian.mcnicoll, post:5, topic:5563"] BTW - I have reread the SNOMED cdocument and this IMO is a great example of why it is generally a bad to use ECL to trigger decision support against a SNOMED hierarchy, especially in a high-risk CDS context. I would nearly always hand-construct/ control an extensional Valueset. @mikael - what are your thoughts on this? [/quote] My general thought is that you need to test run all high-risk CDS rules after any kinds of updates, so this problem is not unique for SNOMED CT. The same apply that for AQL queries after archetype updates. The use of hand-constructed value sets also have their drawbacks. A simple example; * Assume an archetype using a value set including the concept `74400008 |Appendicitis (disorder)|` to record a problem in the EHR. * Also assume an AQL qurey used to trigger a CDS rule if any of the concepts in a value set, including the concept `74400008 |Appendicitis (disorder)|`, is entered using the archetype in the EHR. * It might then be the case that the archetype's value set is seen to be too unspecific, so the concept `74400008 |Appendicitis (disorder)|` is replaced by the concepts `85189001 |Acute appendicitis (disorder)|` and `58997001 |Chronic appendicitis (disorder)|`. * This will break the AQL qurey used to trigger the CDS rule (at least if the concepts `85189001 |Acute appendicitis (disorder)|` and `58997001 |Chronic appendicitis (disorder)|` were not already included in the AQL query's value set (for some strange reason.)) * If the AQL query had used an ECL statement, like `<< 74400008 |Appendicitis (disorder)|`, instead of the AQL query's value set, the query would still have worked. Both hand-constructed value sets and ECL statements therefore have their benefits and drawbacks. My view is that it is more possible to create software that can help test run and debug CDS rules using ECL statements than hand-constructed value sets. I therefore see ECL statements as a better alternative than hand-constructed value sets. --- ## Post #9 by @yampeku [quote="mikael, post:8, topic:5563"] I therefore see ECL statements as a better alternative than hand-constructed value sets. [/quote] 100% agree. Terminology also changes with time, so new codes will also appear. Having the valueset expressed in ECL also eases the valueset evolution and validation of new codes --- ## Post #10 by @ian.mcnicoll I guess the challenge, in either approach is understanding 'exactly' what the Valueset would return via ECL now vs. any deployed version. So I can definitely see an argument for using carefully constructed ECL to construct a proposed Valueset but I would want to make that extensiional/explicit before deployment. Are there tools that can diff a current explicit Valueset vs what would be generated 'now' against the deployed version of SNOMED? That feels to me much more practically useful than having 'substrate' information --- ## Post #11 by @mikael I did a copy and paste error in my previous post. The bullet point below [quote="mikael, post:8, topic:5563"] * If the AQL query had used an ECL statement, like `<< 58997001 |Chronic appendicitis (disorder)|`, instead of the AQL query’s value set, the query would still have worked. [/quote] should have been * If the AQL query had used an ECL statement, like `<< 74400008 |Appendicitis (disorder)|`, instead of the AQL query’s value set, the query would still have worked. I have updated my original post. --- ## Post #12 by @mikael [quote="ian.mcnicoll, post:10, topic:5563"] Are there tools that can diff a current explicit Valueset vs what would be generated ‘now’ against the deployed version of SNOMED? [/quote] In the current version of ECL, there are also "[History Supplements](https://confluence.ihtsdotools.org/display/DOCECL/6.11+History+Supplements)" that do kind of what you are asking for. However, I don't know how many of the tools that have implemented that part of the specification yet. It is also easy to implement the functionality you are asking for in most tools due to that all required information is included in SNOMED CTs full release format. --- ## Post #13 by @wouterzanen It might be a better approach to run an automated script on all archetypes in CKM to check for deprecated SNOMED codes putting a deprecated statement on those codes no longer valid. That way you can have the whole CKM in line with a latest SNOMED release. Afourse the deprecated items need to be solved manualy (or at least reviewed if SNOMED offers an alternative code), perhaps creating CR on the affected archetypes. --- ## Post #14 by @yampeku [quote="wouterzanen, post:13, topic:5563"] t might be a better approach to run an automated script on all archetypes in CKM to check for deprecated SNOMED codes putting a deprecated statement on those codes no longer valid. [/quote] I think @vigiso and myself can easily provide that potential list --- ## Post #15 by @yampeku Here comes the summary of needed CRs, will create them later on |archetype | inactiveConceptId | inactiveConceptFsn | inactivationReason | associationName | associatedConceptId | associatedConceptFsn| |--- | --- | --- | --- | --- | --- | ---| |openEHR-EHR-CLUSTER.exam-eye.v0 | 8966001 | Left eye structure (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 1290031003 | Structure of left eye proper (body structure)| |openEHR-EHR-CLUSTER.exam-eye.v0 | 18944008 | Right eye structure (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 726680007 | Structure of right eye region (body structure)| |openEHR-EHR-OBSERVATION.pregnancy_finding.v0 | 102874004 | Possible pregnancy (finding) | Erroneous | REPLACED BY | 146799005 | Possible pregnancy (situation)| |openEHR-EHR-CLUSTER.exam-abdomen.v0 | 113345001 | Abdominopelvic structure (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 818981001 | Structure of abdominal cross-sectional segment of trunk (body structure)| |openEHR-EHR-CLUSTER.exam-abdomen.v0 | 113345001 | Abdominopelvic structure (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 818984009 | Structure of abdominopelvic cavity and/or intra-abdominopelvic content and/or anterior abdominal wall excluding intra-pelvic structure of true pelvis (body structure)| |openEHR-EHR-CLUSTER.exam-abdomen.v0 | 113345001 | Abdominopelvic structure (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 818985005 | Structure of abdominopelvic segment excluding true pelvic segment of trunk (body structure)| |openEHR-EHR-CLUSTER.exam-abdomen.v0 | 113345001 | Abdominopelvic structure (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 818982008 | Structure of abdominopelvic cross-sectional segment of trunk (body structure)| |openEHR-EHR-CLUSTER.exam-abdomen.v0 | 113345001 | Abdominopelvic structure (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 63337009 | Structure of abdominopelvic segment of trunk (body structure)| |openEHR-EHR-CLUSTER.exam-abdomen.v0 | 113345001 | Abdominopelvic structure (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 818983003 | Structure of abdominopelvic cavity and/or content of abdominopelvic cavity and/or anterior abdominal wall (body structure)| |openEHR-EHR-CLUSTER.exam-auscultation-bowel_sounds.v0 | 113345001 | Abdominopelvic structure (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 818981001 | Structure of abdominal cross-sectional segment of trunk (body structure)| |openEHR-EHR-CLUSTER.exam-auscultation-bowel_sounds.v0 | 113345001 | Abdominopelvic structure (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 818984009 | Structure of abdominopelvic cavity and/or intra-abdominopelvic content and/or anterior abdominal wall excluding intra-pelvic structure of true pelvis (body structure)| |openEHR-EHR-CLUSTER.exam-auscultation-bowel_sounds.v0 | 113345001 | Abdominopelvic structure (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 818985005 | Structure of abdominopelvic segment excluding true pelvic segment of trunk (body structure)| |openEHR-EHR-CLUSTER.exam-auscultation-bowel_sounds.v0 | 113345001 | Abdominopelvic structure (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 818982008 | Structure of abdominopelvic cross-sectional segment of trunk (body structure)| |openEHR-EHR-CLUSTER.exam-auscultation-bowel_sounds.v0 | 113345001 | Abdominopelvic structure (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 63337009 | Structure of abdominopelvic segment of trunk (body structure)| |openEHR-EHR-CLUSTER.exam-auscultation-bowel_sounds.v0 | 113345001 | Abdominopelvic structure (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 818983003 | Structure of abdominopelvic cavity and/or content of abdominopelvic cavity and/or anterior abdominal wall (body structure)| |openEHR-EHR-OBSERVATION.fundoscopic_examination.v0 | 362502000 | Entire right eye (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 1290043002 | Entire right eye proper (body structure)| |openEHR-EHR-OBSERVATION.fundoscopic_examination.v0 | 362503005 | Entire left eye (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 1290041000 | Entire left eye proper (body structure)| |openEHR-EHR-OBSERVATION.visual_acuity.v0 | 362502000 | Entire right eye (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 1290043002 | Entire right eye proper (body structure)| |openEHR-EHR-OBSERVATION.visual_acuity.v0 | 362503005 | Entire left eye (body structure) | Ambiguous | POSSIBLY EQUIVALENT TO | 1290041000 | Entire left eye proper (body structure)| |openEHR-EHR-OBSERVATION.braden_scale.v1 | 413139004 | Braden assessment scale (assessment scale) | Duplicate | SAME AS | 781128005 | Braden Scale (assessment scale)| We also found out that two snomed concepts (5238003 used in openEHR-EHR-CLUSTER.exam-cranial_nerves.v0 and 26563001 used in openEHR-EHR-CLUSTER.exam-tympanic_membrane.v0) do not exist in SNOMED at all. Second one in fact seems to be a copy paste error as the correct code for Right tympanic membrane is 726563001 --- ## Post #16 by @wouterzanen [quote="yampeku, post:15, topic:5563"] 13139004 Braden assessment scale (assessment scale) Duplicate SAME AS 781128005 Braden Scale (assessment scale) [/quote] This is great, funny that the first two are both also a problem in the dutch zibs right now. So if we fix those I could propose a sollution. Let me bring this to the attention of the @CPB so we can put this on the agenda for a next meeting to decide how to move forward and how to make this a regular (3 month?) excersise. --- ## Post #17 by @yampeku Created all CRs in CKM. By the way, found the correct code for 'Cranial nerve structure (body structure)', the correct one is 25238003 --- **Canonical:** https://discourse.openehr.org/t/using-snomed-ct-term-bindings-and-missing-substrate-information/5563 **Original content:** https://discourse.openehr.org/t/using-snomed-ct-term-bindings-and-missing-substrate-information/5563