SNOMED coding of values in compositions

Clinical
1

For a project about SNOMED CT coding of nursing diagnoses I’m creating a template with a set of diagnoses names with corresponding SNOMED codes. For each diagnosis name the user records, a corresponding SNOMED code should be persisted.

I’m aware of different ways of achieving this result. So I’m looking for an assesment of those options.

A common practice, I believe, is to, in the Template, set the SNOMED code as the ‘code’(_string) for a DV_CODED_TEXT, with the value as ‘text’, right? This lets you query on the DV_(CODED_)TEXT.code_string based on the snomed code.

However the Class description states this as misuse, right?

Misuse: If the intention is to represent a term code attached in some way to a fragment of plain text, DV_CODED_TEXT should not be used; instead use a DV_TEXT and a TERM_MAPPING to a CODE_PHRASE.

In addition: this does not allow interaction with the user in selecting the appropriate SNOMED code. So it only works (clinically) safely if the match of DV_CODED_TEXT code and value are a 1:1 match. In my experience this is often the case, but also frequently not.

Now (at least in ADL2/AOM2) there’s a ‘term_binding’ in every archetype and template that allows binding of any local code (e.g. those in a DV_CODED_TEXT.defining_code) to a code in an external terminology e.g. SNOMED.

image
image2816×1697 628 KB

(CKM test showing an ADL2.4 rendering of term_bindings to SNOMED CT (for ELEMENT names, not values)

Now if that code needs to be persisted e.g. in order to query on it based on native SNOMED codes, that term_binding code ‘goes into’ DV(_CODED)_TEXT.TERM_MAPPING. It’s up to the client application to do that. And to interact with the user for confirmation or selection etc.

I think this is the safest pattern to use right now, but I’m unclear on the support for it in ADL1, tooling, and CDRs. But migration re archetypes/templates, persisted compositions, queries and apps seems high impact.

And finally I think we as openEHR are moving towards using FHIR value sets as the preferred way of expressing coding of values in a set. So it would be good to take that into account before changing modelling practice.

Right now I’m looking for verification of my analysis above. And for real world experience around (template) modelling and querying.

1 Like
2

Maybe I’m misunderstanding your use case, but I’ve always interpreted this more like

If the intention is to represent a term code attached in some way to a fragment of free text

But if you have a predetermined set of diagnosis names each with a corresponding SNOMED CT code, I think this should be fine?

Do you want the user to interact directly with SNOMED CT codes?

True, if the SNOMED CT concept doesn’t match the diagnosis name exactly, it shouldn’t be used to represent it as its defining_code/code_string. In those cases, term_mapping would probably be more appropriate.

2 Likes
3

@joostholslag This is a common problem. We had an example recently where we wanted tt use SNOMED terms for ‘Preferred place of death’ e.g ‘Preferred place of death: home’, but the client wanted simpler text in the selection response i.e. ‘Home’.

I still see this as a defining_code in that the user is selecting the SNOMED term directly, though the prompt text is different. I think we should be able to record the text that was actually selected, and carry the original ‘rubric’ of the selected term as CODE_PHRASE.preferred_term.

The spec does not allow this I think it could be usefully revised, as it feels to be in the spirit of the ‘defining_code’

That still does not resolve the issue of how we create the constraint that carries the list of SNOMED terms with associated local text overrides, and I’m not clear if FHIR Valuesets help, other than perhaps with custom properties - worth a question on Zulip?

2 Likes
4

#snomed > Display texts in SNOMED valuesets @ :speech_balloon:

ValueSet.compose.include.concept.display can be something the value set author creates specifically in the context of that value set as noted in the comment on this element “The value set resource allows for an alternative display to be specified for when this concept is used in this particular value set. See notes in the value set narrative about the correct use of this element.” What is critical is this SHALL NOT be used to change the meaning in any way [my personal emphasis here.] So yes, you can use a synonym and no you can not put anything there.

That does solve the problem of how to provide a list of SNOMED terms with local display terms.
also see ValueSet - FHIR v6.0.0-ballot3

{
  "resourceType" : "ValueSet",
  "expansion" : {
    "contains" : [{
      "system" : "http://loinc.org",
      "code" : "55423-8",
      "display" : "Step Count", // Local dissplay text
      "designation" : [{
        "use" : {
          "system" : "http://snomed.info/sct",
          "code" : "900000000000003001" // "Fully-specified name'
        },
        "value" : "Number of steps in unspecified time Pedometer" //Original LOINC Term
      }]
    }]
  }
}

The SNOMED code is confusing here - it is just used to say that the designation.value is a fully-specified name (in the case of a LOINC term)

5

Hmm, I guess I misread, and using snomed codes as the (internal) code for a dv coded text is fine. Thanks for pointing that out. I do think this text should be changed, because I’d prefer a consistent way of coding data with snomed: always term_mapping. This was I guess impossible in adl1.4 because valuesets are local to the definition, while in adl2 they have AT codes, which can get term_bindings.

About user interaction, I’d love no interaction of users with snomed codes. But clinicians do need to bear responsibility for the recoded snomed codes. And the mapping isn’t 1:1 always, and depends on the specific patient (context). So I do feel we frequently need user confirmation. I think this is something that should be solved at the application level. the application should minimise user interaction while maximising safety. And design smart interactions based on the reliability of the expected snomed match. E.g. if it’s highly reliable show snomed code only with a tooltip. If like 95% reliable, show to user explicitly, but accept without confirmation by default, if 70/30 ask the user to confirm explicitly etc. Etc.

I’m thinking scenarios like a nursing care plan. Where the diagnosis name comes from e.g. NANDA or Omaha, where the number of available diagnoses are relatively limited and (consequently) quite broad. While patients actual problem is very specific. So the clinician may want to pick a more specific snomed code than the one that can be mapped to the broad OMAHA diagnosis.

6

I struggle to understand this. I’m looking for a way to define a grouping of snomed terms that is not local to the archetype/template but does constrain the allowed codes in a DV_CODED_TEXT. So a valueset that can be maintained on a terminology server as ‘defining_code’ in a template. I know archetype designer supports external terminologies, is there a guide somewhere on how to use this? And what is the syntax like in adl1.4 archetype and templates?

I did find the option in AD to add external terminology, where I can pick a code system. This shows up as follows in native json:

termBindings":{“SNOMED_CT”:{“ac0.1”:“terminology://fhir.hl7.org/CodeSystem?url=http://snomed.info/sct"}},“terminologyExtracts”:{},"valueSets”:{}}

If I pick a valueset from the external terminology it looks like this:

IMG_0340

It seems like a mix between adl1 and 2. (There is an AC code) but no at/id code node identifier.

Now if I look at the (AOM2) specs, I find:

IMG_0341

So apparently the syntax for defining an external valueset is anything that’s a URI. So how does a client app know how to interpret this URI? Should we specify a schema for that URI? E.g. standardise on the FHIR value set way of defining the URI (does FHIR define this?).

7

See - Archetype Query Language (AQL)

and Jira

The discussion does get a bit confusing but it does appear that both Better and Vitagroup support this format in .opt (as generated by AD), which is based on the AQL definition above.

terminology://fhir.hl7.org/ValueSet/$expand?url=http://hl7.org/fhir/ValueSet/surface

terminology:// just signifies that the following text follows the formal referenceUri pattern
fhir.hl7.org/ designates that we are using a FHIR terminology service
ValueSet/$expand?url=http://hl7.org/fhir/ValueSet/surface - the call to be sent to the FHIR TS service

terminology: is also supported for legacy reasons.
terminology:Snomed?subset=ABO%20Blood%20Groups&language=en-GB

and although the AQL TERMINOLOGY() is now well-documented, it does appear that the reference_uri format is not - we should fix that!

8

Thanks. That’s really helpful. Now how to document this in a more understandable way?

And what is reference_uri

9

Agree that we should document this more clearly but CKM also supports the same syntax and resolves the value set when connected to a TS

10

Today I was looking at some ‘random’ concept map @dkapitan . DiagnoseThesaurus naar SNOMED - JSON Representation - PLUGIN v0.0.2-ci

I realised openEHR term_binding (and potentially) term_mapping seem (at first look) equivelant to FHIR concept map.

Would we (technically) be able to use FHIR concept map instead of term binding?

I would (very much, or should we drop that idea?) like the archetypes/templates to stay a single artefact, so we would need to inline concept maps in adl files. Other than serialisation (ODIN, possibly migrating to yaml) vs JSON, that should be possible right?

11

I did raise that idea briefly on a SEC call ansd I think it is defintely worth considering but it does not really apply (directly) to openEHR term_mapping as I understand.

openEHR binding and FHIR ConceptMaps have an equivalent purpose, in defining the rules by which one term can be asserted as being related to another, normally equivalent. It is part of the design-time infrastructure but does not automatically add anything to the patient record

openEHR term_mapping is a run-time construct which dos allow one or more alternative terms to be carried alongside a piece of text, or the defining_code, and is equivalent to the CodeableConcept codes where userSelected = false

So ConceptMap could be used to define the rules to populate the openEHR term_mappings but it is not a direct equivalent.

Since archetype local codes are essentially a CodeSystem in FHIR terms, and the coded values on elements are Valuesets on that CodeSystem, I think some kind of FHIR TS supporting facade, on top of ADL, to include ConceptMap, might be an interesting idea. This would allow an archetype to function as a Codesystem in a FHIR ecosystem.

1 Like