Using SNOMED CT term bindings and missing “substrate” information

Clinical
, , ,
1

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: 3.3. Substrate - Decision Support with SNOMED CT - SNOMED Confluence

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? Binding archetypes to SNOMED as an ontology?

2

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
3 Likes
3

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.

2 Likes
4

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.

5

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 :wink:

1 Like
6

https://chat.fhir.org/#narrow/stream/179166-implementers/topic/.24validate-code.20using.20many.20value.20set.20versions/near/153964786

1 Like
7

Example of mappings against LOCATABLE.name

{
  "@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"
        }
      }
    ]
  }
}
1 Like
8

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.

2 Likes
9

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

1 Like
10

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

1 Like
11

I did a copy and paste error in my previous post. The bullet point below

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.

12

In the current version of ECL, there are also “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.

1 Like
13

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.

4 Likes
14

I think @vigiso and myself can easily provide that potential list

1 Like
15

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

5 Likes
16

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_Board 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.

2 Likes
17

Created all CRs in CKM. By the way, found the correct code for ‘Cranial nerve structure (body structure)’, the correct one is 25238003

2 Likes