Stream: terminology
Topic: SNOMED ConceptId & DescriptionId
Richard Kavanagh (Oct 26 2016 at 14:22):
Due to local interoperability challenges we have a requirements to carry SNOMED ConceptIds (as is the norm) in our FHIR resources, but also SNOMED DescriptionIds (not the norm).
We are still working on the exact requirements but for now assume we will need to carry both for certain coded data items.
It looks to me that we have two options in implementing this:
1) Add extensions to the CodeableConcept making provision for the SNOMED CT DescriptionId and associated Description
2) add a second coding within the CodeableConcept with a different codesystem and include the SNOMED CT DescriptionId and associated Description within that.
Any thoughts on what the cleanest way to proceed might be?
Lloyd McKenzie (Oct 26 2016 at 17:25):
I would lean towards an extension. It more cleanly ties the two ids together (if you've got 10 codings of which 3 are SNOMED description ids and 3 are concept ids interspersed among other codings, figuinr out which goes with which would be a challenge). As well, it means you're not inventing a second code system for something that's really one code system. Third, it'll be less likely the "codes" that aren't really codes will get propagated and used elsewhere. Fourth, it should be easier to tweak the validator to check for alignment and will be more efficient if the description ids are extensions (if they're codings, the validator will try to look them up each time, if they're an extension, then the look-up happens on the concept id and you just add a bit of code to make sure the description id is legal for the concept)
Grahame Grieve (Oct 26 2016 at 19:53):
agree with Lloyd- should we add an extension for this to core? Singapore also have the same need
Lloyd McKenzie (Oct 27 2016 at 00:10):
Happy to have a core extension. Is it specific to SNOMED or is this something that could theoretically be relevant to other code sytsems?
Grahame Grieve (Oct 27 2016 at 10:51):
It's specific to SCT as far as I know
Rob Hausam (Oct 28 2016 at 18:21):
I agree with Lloyd and Grahame - a core extension makes sense
I don't know of anything similar that applies to any other code system (although theoretically it could be possible, for sure) - I think keeping it SNOMED CT specific for now, unless and until another need arises, makes sense
Grahame Grieve (Oct 28 2016 at 20:34):
Richard Kavanagh (Dec 05 2016 at 15:53):
Great. I've see the extension in the devt version (http://build.fhir.org/extension-coding-sctdescid.html ). I assume technically this might change, should we use this in a DSTU2 solution?
Grahame Grieve (Dec 05 2016 at 19:17):
anything might change, but there's no intent to change, and it would be you guys who are most likely to use it and drive any changes to it
Jeremy Rogers (Dec 11 2017 at 11:07):
SNOMED CT is, I think, unique in having term identifiers (descriptionId) from which the corresponding concept identifier (conceptId) can always reliably be recovered - as would pragmatically be required to support most data reporting use cases whenever only the descriptionId was sent. It is therefore technically possible to permit sending only the SNOMED CT descriptionId without permanently degrading the data, but it does impose a lookup obligation on all possible receiving systems that they may not always be practically able to support (e.g. mobile apps on low storage or low memory devices).
IMHO it would generally be clinically much safer and pragmatically far more useful to send both ConceptId and DescriptionId, if you have them, and I've yet to see a convincing argument why you you would not or need not. Engineering elegance is NOT a convincing argument because (a) it relies upon a misplaced faith in the robustness of all terminology products - including SNOMED CT- in respect of their practical ability to forever exclude all possibility for non-synonymous synonymy, and (b) it is dismissive of real clinical safety concerns in respect of the safety risks that this inconvenient truth inevitably creates.
Several other legacy terminologies also have term identifiers, such that the exact machine readable meaning of what was coded is not reliably recoverable if only the concept identifier is passed and not also the Term identifier. In the UK, both READ2 and CTV3 have this behaviour, and internationally SNOMED RT obviously does/did. Older legacy versions of SNOMED (II, 3,3.5) - still globally in ubiquitous use within histopathology labs - also sort of had hints of it via their ECLASS property. LOINC, ICD, ICD-O and ICPC do not.
In some cases, passing only the concept identifier plus the original term string itself (but not the term identifier) is also not sufficient, because the 'official' term string may lexically change over time without also changing the term identifier (e.g. to correct minor typos) and so old legal data may not validate against the latest official terminology release data. I've also seen many instances where lexical changes to 'official' term strings that should otherwise be validated against are made globally by the system implementor, or even on an ad hoc and per-coded item basis by the individual recording clinician. Common system-wide term alterations have included different capitalisation, removal of stray commas and quotes or other punctuation marks, and suppression of wild card characters like * or % from the 'official' terms.
Whilst SNOMED CTs technical design now deliberately prohibits such representational 'flexibility', much of the still clinically highly relevant historical EPR - at least in the UK - is still coded using these less constrained legacy technologies. A messaging specification is therefore required that can cope with the sins of the past as well as the ideals of the future. This all has particular significance when designing mapping tables - or communicating the result of applying them - where the clinically safe and assured mapping to e.g. SNOMED will be different depending on exactly which term and/or term identifier was selected in the legacy coding system.
Since SNOMED CT is very extensively the genetic technical and content ancestor of READ2 and CTV3, UK thoughts and experiences on this topic may not be mere specialist and parochial concerns: they stem from our experience dealing with these closely related terminology products and the clinician-facing EPRs based upon them. My personal assessment is that relatively little of the necessarily cautious interoperability rules the UK uses to enable safe messaging of its legacy terminology data and the mappings between them can be jettisoned even in some future state, a decade or two from now, where all its clinically still relevant data is natively SNOMED CT coded.
The UK will likely therefore require an extension that permits messaging of the quartet of:
1. concept identifier
2. term identifier
3. current official display string encoded for by the conceptId+termId pair
4. original term text actually entered by the clinician (especially if different from the current official string)
Dion McMurtrie (Dec 11 2017 at 11:32):
That's an interesting topic @Jeremy Rogers, I had a conversation at a connectathon last week that intersects with the issues you discuss, I'll explain that and then add my inevitable opinion ;-)
The situation was someone receiving content from a number of other systems and mapping that to SNOMED CT to then perform some analytics. The incoming data was a mixture of other code systems and free text, and where the free text was present they would condense that to unique instances of free text and map it appropriately (given context) to SNOMED CT.
The issue is when getting a code, they get the code and text, where the text is what the clinician "saw". In this case the system in question allows the clinician to select a code which sets the text to that code's term (and here's the painful part) allows the clinician to add to or edit the text. The result of the conversation was that effectively they cannot treat the record as coded to the specified code if the text they receive with it isn't the display text for that code. If the text has been tampered with, it may or may not mean the same thing as the code originally did (probably doesn't otherwise what was the purpose to editing it).
I think we've got the same sort of issue for the interoperability you mention. If a SNOMED CT code is received and the display text that comes with it isn't one of the current or known descriptions for that code...what does it mean? It could be one of meany things
- the receiving system may have an older version of SNOMED CT and the description term has changed or been retired and replaced by a new one
- the receiving system has a different edition of SNOMED CT and the "preferred term" from one system doesn't match the terms the other one has - e.g. UK and AU preferred terms may exist in our extensions
- the clinician had access to a system that let them edit the display term (bad idea but it happens)
Whether in searching for the display term you'd go to the effort of looking at inactive descriptions or limit it to only active ones is another concern too.
Your suggestion of also identifying the description identifier would help disambiguate the situation, as would knowing the code system version the sending system was using. But as you point out the description identifier only works for a limited set of code systems like SNOMED CT, what do you do with the others.
But the problem remains, to what lengths does the receiving system need to go to validate the content being sent to it when a code is being asserted. What is the responsibility of the sending system versus the receiving system and what is practical to do?
Thinking of code systems generically, not SNOMED CT specifically, all I can think to do is
- tell sending systems to not assert a code if a clinician has fiddled with the display text - at that point you are doing free text not coding
- tell receiving systems to validate that the received display term matches one of the known past or present display terms of the code, and if it doesn't treat the code very suspiciously and be prepared to update that level of suspicion when you update to new code system versions (possibly revalidate these at that point). The exact nature and degree of this suspicion and whether the validation is even necessary at all will depend on the context of use of the receiving system.
Of course there's also the case where a code can be sent without an accompanying display term at all!
Jeremy Rogers (Dec 11 2017 at 11:47):
Exactly: the posterboy UK example of this 'direct editing by clinician of the official code string' phenomenon is the READ code for M297. Tattoo (from the Skin disorders chapter) which some clinicians were famously in the habit of editing to TATT, meaning 'tired all the time'. Most if not all current Primary Care systems no longer permit this - though some still allow clinicians to add their own 'synonym' terms to particular codes if they don't like the official central set.
Jeremy Rogers (Dec 11 2017 at 11:54):
The general principle is: if the supposedly tight binding between conceptId, descriptionId, term string and what the clinician actually meant to say can got wrong, it will and already has.
Jeremy Rogers (Dec 11 2017 at 12:00):
There is therefore a continuing requirement to support medicolegally safe forensic reconstruction and validation of the semantics of coded data, a task which is greatly enabled by ensuring that ALL the data originally available is messaged.
Dion McMurtrie (Dec 11 2017 at 12:59):
Yes, the direct editing of terms or even setting locally preferred (or individually preferred!) synonyms creates all sorts of slippery problems. I think it is better to either select the code and its associated text or own up to the fact you are using free text. The middle ground of the code plus my manual edit is a land mine infested no man's land.
I think with SNOMED CT you can meet your stated aims, but unfortunately not all the code systems will support the term identifier, as you point out. I guess the question though is what validation is the receiving system supposed to do with those fields and what do they do when it doesn't all match? I suppose the second question depends very much on the setting they are using the data in, which in turn may influence how much validation they do in the first place. That accuracy isn't actually necessary in all settings...
However assuming it is important that the correct semantics are understood (which I think is most if not all direct clinical use of the data), I think it would be necessary to specify the various edge cases when the validation would fail and how the receiving system should detect/interpret them. Do you have that sort of guidance or rules from your existing V3 or CDA implementation guidance?
Grahame Grieve (Dec 11 2017 at 19:35):
so I don't understand something in this thread, which is what the description id brings other than a denormalization of the look up of the text. Above, this was referred to as 'enginering elegance' - ok, that's fine. That's what the extension is for. I didn't follow any other medico-legal reason. But this:
The UK will likely therefore require an extension that permits messaging of the quartet of:
1. concept identifier
2. term identifier
3. current official display string encoded for by the conceptId+termId pair
4. original term text actually entered by the clinician (especially if different from the current official string)
That's what the aforementioned extension is for - to provide all these things
Grahame Grieve (Dec 11 2017 at 19:36):
As for the text variations raised by @Dion McMurtrie: there are lots of variations of text handling; we can't handle all these things (we can barely get a stable definition of original text out the committee process at all). So extensions / audit trail is your only hope...
Peter Jordan (Dec 11 2017 at 22:09):
The practical advice provided by @Dion McMurtrie is very timely for NZ, as we consider the implications of switching from Read Coding to SNOMED CT concept selection in primary care HIE, particularly GP2GP. It brings home to me the importance of recommending that receiving systems should validate combinations of code, code system and description, possibly treating any failures as original text. It will be interesting to review the participating vendors' responses to that.
Dion McMurtrie (Dec 11 2017 at 23:27):
@Grahame Grieve I think adding the description id helps by narrowing the validation problem to a specific description rather than all the descriptions for the concept, some of which may be in other editions you don't have.
But realistically it only helps a little. You can still have circumstances where the text doesn't match because you've got an older version of the terminology for example. In this case even if you have the description id you can't programmatically know whether it is because of terminology version, or because someone has tinkered with the description.
I guess my point is you can provide more and more information which will help determine when the description text doesn't match why that is (or why it may be), but it doesn't really change that the content can't be safely treated as coded at that point, depending on the context of use...and it doesn't change that coding something and supplying text that doesn't match the code's text creates this problem and is no better (probably worse) than just providing text with no code.
Grahame Grieve (Dec 12 2017 at 00:17):
so it doesn't really make any difference... either the description is right, or it's not, and a description id doesn't tell me why it's different. And anything I can do to use the description id will give the description anyway
Grahame Grieve (Dec 12 2017 at 00:18):
and anything I can do with the description id I can do with the text... unless I specifically accept only the description id
Michael Lawley (Dec 12 2017 at 01:00):
I can really only see one small value-add for providing a description id as well - it suggests that the associated text (if different from known synonyms) has been through an editorial process. That is, it is a real/valid interface terminology variant (recalling that for SNOMED, any extension can legitimately provide additional descriptions).
Having said that, I still maintain that a UI should rarely allow selection of anything other than the "preferred term" for a code. The main reason for this is that many of the other descriptions in SNOMED are not synonyms and it is easy to find closely related groups of codes where the preferred term for code A is also a synonym for code B and vice-versa.
Dion McMurtrie (Dec 12 2017 at 04:43):
Having said that, I still maintain that a UI should rarely allow selection of anything other than the "preferred term" for a code. The main reason for this is that many of the other descriptions in SNOMED are not synonyms and it is easy to find closely related groups of codes where the preferred term for code A is also a synonym for code B and vice-versa.
+1 @Michael Lawley the preferred term should be used, other synonyms are great for searching and allow different realms to pick different spellings etc for preferred terms. But some of those synonyms have far from an equivalent meaning and shouldn't be rendered or used for a clinician to pick.
Jeremy Rogers (Dec 12 2017 at 12:27):
If the sole purpose of synonyms was to support indexing of the solitary preferred term, then it might have made more sense for SNOMED to release only the canonical token index that is derived from the synonyms, not the entire list of 'synonyms'.
And, of course, there isn't only one preferred term per concept: realms can override the default PT selection with their own, and change their PT selections over time. In theory, if you know the conceptId and the realm and the time and day on which the item was selected you could work out which synonym officially prevailed as the PT at that time and location...but you'd be medicolegally crazy to do this and no clinical safety bod would sign that approach off.
Whether clinicians should be restricted to only selecting the PT is an interesting question on which, in my personal experience, clinicians themselves are strongly divided. Historically, they have been able to and have done so in huge numbers.
There are some UI challenges if only the PT is displayed and selectable: for some clinicians searching for some clinical notions, none of the search matches returned for display will match any of the search tokens they actually entered.
Whilst its true that not all 'synonyms' in SNOMED are truly semantically equivalent to the PT or each other, the clinical response is likely to be: you should sort that out by fixing SNOMED's content, not by virtually deleting it. SNOMED ultimately still needs to remove 'non-synonymous synonmy' but, if it ever managed to , Michael would need a different 'main reason'.
Michael Lawley (Dec 13 2017 at 00:55):
My team & I keep hearing the 'clinicians want the choice' claim, but we've been strong advocates for starting them with UIs that don't offer the choice. So far we've had no trouble with this. Occasionally there are complaints about a specific term, but these have all be resolvable by fixing the SNOMED CT-AU content itself. I'd also observe that many (most) clinicians don't understand the potential secondary effects associated with supporting 'non-synonymous synonymy' :)
Jeremy Rogers (Jan 10 2018 at 11:58):
One of the editorial policy rules of SNOMED CT term construction has always been that the preferred term should (almost) never include abbreviations or, if they do contain an abbreviation, then this should always be followed by its full expansion within the PT. The exception to that rule - at least in our own UK realm - is a very small number of NRC-approved abbreviations that are believed to be entirely unambiguously and universally understood within the realm, like 'NHS'.
A policy of restricting clinicians to only ever persisting and re-displaying the SNOMED CT preferred term therefore has the consequence that some clinical terms that are normally almost ubiquitously represented in part using unexpanded TLAs become instead rather more wordy. For example:
FEV1/FVC ratio after bronchodilator -> Forced expiratory volume 1 (FEV1)/ forced vital capacity (FVC) ratio after bronchodilator
Lumbar spine DXA scan -> Dual energy X-ray photon absorptiometry scan of lumbar spine
There are also cases where the PT is a rather more wordy exposition of fairly ubiquitous clinical jargon or metonymy:
Breast milk jaundice -> Neonatal jaundice due to delayed conjugation from breast milk inhibitor
White coat hypertension -> Labile hypertension due to being in a clinical environment
Number of abortions -> Number of miscarriages or induced terminations of pregnancy
Generalised osteoarthritis -> Degenerative joint disease involving multiple joints
Pompholyx -> Vesicular eczema of hands and/or feet
Scabies -> Infestation by Sarcoptes scabiei var hominis
Pompholyx -> Vesicular eczema of hands and/or feet
I would guess that these two classes of term re-display phenomenon might be the cause of a significant fraction of the complaints that you get; presumably you're handling these by promoting a clinically more friendly synonym to being the PT within some Australian Realm Description Refset? I would suspect that clinicians in many other countries will complain about exactly the same preferred terms, and so there may be a case for some international sharing of information here rather than re-invention of the same wheel by multiple NRCs in parallel...
Rob Hausam (Jan 10 2018 at 13:15):
These are great examples, Jeremy. I'm not speaking for an NRC, but as a clinician for any practical use of SNOMED CT in the user interface for data entry this must be addressed. And I agree that the need (in English) is likely to be nearly universal, so it doesn't really make sense for each NRC to have to craft a solution for it on their own.
Dion McMurtrie (Jan 11 2018 at 00:15):
@Jeremy Rogers there's a good case there for studying the difference between the GB, US and AU language reference sets for variation in their preferred term - that could be done right now.
Grahame Grieve (Jan 11 2018 at 05:06):
does that mean that the preferred term is actually the un-preferred term?
Jeremy Rogers (Jan 11 2018 at 14:15):
No, it simply confirms the usual age-old problem that Beauty is in the eye of the Beholder. 'Preference' is use-case specific, not universal. SNOMED provides a default definition of 'preferred' as: most likely to be universally and unambiguously understood. Most clinician's definition is considerably more local and personal, and in recognition of that reality SNOMED provides a mechanism to declare any number of alternate preferred terms, according to the local use case and scope of use. There is no single universally definable preferred term that will be acceptable across ALL possible clinical contexts. Never was; never will be.
Michael Lawley (Jan 15 2018 at 21:19):
The flip side, is that it often doesn't matter that preferred terms are slightly longer or a little more cumbersome. As long as you can enter the terms you're thinking about and quickly select the one you want.
While a blanket ban on abbreviations/acronyms is clearly too strong, I'm not sure what the UK or US is like, but in AU there are a very large number of non native-English speaking clinicians, and "universally understood within the realm" is far less universal than one may think ("White coat hypertension").
Also, I note that "Number of abortions" is significantly different to "Number of miscarriages or terminations of pregnancy", at least to a lay person; clinicians are not the only people who read clinical records.
Last updated: Apr 12 2022 at 19:14 UTC
