FHIR Chat · SNOMED CT in Conditions

Stream: implementers

Topic: SNOMED CT in Conditions

Richard Kavanagh (Jul 23 2020 at 09:10):

Looking at Condition.code there is an example VS binding that suggests using codes that are descendants of 404684003 (Clinical finding)

For findings that reside within 413350009 (Finding with explicit context) - would these typically be "Conditions" or "Observations"?

Daniel Karlsson (Jul 23 2020 at 09:12):

Hi Richard,
The SNOMED on FHIR project has done some work on the Condition resource, including a suggestion for binding for Condition.code:
https://confluence.ihtsdotools.org/display/FHIR/Condition+Resource
So, the answer to your question would be Conditions, but there is a discussion about how much of the SNOMED context model to use vs. the corresponding FHIR facilities (and this discussion is not likely to go away soon).

Richard Kavanagh (Jul 23 2020 at 09:17):

Thanks @Daniel Karlsson a very useful starting point. And I agree the semantic clash between FHIR and SNOMED will exist for some time.

Daniel Karlsson (Jul 23 2020 at 09:18):

Yes, like forever would be a good guess :grinning_face_with_smiling_eyes:

Richard Kavanagh (Jul 23 2020 at 09:37):

Looking closer, the proposed ECL looks a bit suspect. Not sure that all SNOMED events are conditions - it's a starting point though.

Daniel Karlsson (Jul 23 2020 at 09:41):

Maybe no events should be Conditions. I think the idea of these bindings were to be very inclusive, and that we might have been over-inclusive here. It is a live piece of work, so suggestions are more than welcome!
Thanks!

Daniel Karlsson (Jul 23 2020 at 09:44):

<< 420134006 |Propensity to adverse reactions| OR << 473010000 |Hypersensitivity condition| also looks suspicious. If I remember correctly (big if...) the discussion was that we would exclude (and not include) things that are kept in other FHIR resources (here AllergyIntolerance).

Daniel Karlsson (Jul 23 2020 at 09:45):

I'll put Condition on the agenda for next SNOMED on FHIR call...

Richard Kavanagh (Jul 23 2020 at 09:50):

I think I need to start joining those calls to learn more. I'll try and persuade one of my clinical colleagues to do the same.

Daniel Karlsson (Jul 23 2020 at 09:51):

:+1:

Jeremy Rogers (Jul 23 2020 at 12:01):

Here's a list of the most popular SNOMED codes used by GPs that are kinds of <<272379006 Event:

217082002 Fall - accidental
214031005 Motor vehicle traffic accident
401270003 E-mail received from patient
418019003 Accidental event
217082002 Accidental fall
217697000 Dog bite
52684005 [X]Assault
419620001 Death
1912002 Fall
82313006 Suicide attempt
52684005 Assault
217701002 Cat bite
418420002 Intentionally harming self
217706007 Insect bites - nonvenomous
444386009 Exposure to Enterobius vermicularis
248110007 Sexual assault

Whilst there's clearly an administrative code in there - and that's a possible source of an interesting digression - the huge majority are clearly highly significant clinical 'Problems' that should appear in the patient Problem List. You can argue all you like that these are codes for the cause of the problem, and not for the pathophysiological true problem itself. But that's clinical record keeping for you. If we filter the content of real patient records through an overly constrained semantic filter, bad stuff will happen. At least, until you also apply that same filter prospectively at the point of primary clinical data capture, and retrospectively over all clinically relevant data already captured but with less constraints over the last 20 years or so.

So... if all phenomena that clinicians identify as a "Problem" on a patient Problem List must be cast only as instances of the CONDITION resource, then it follows that most SNOMED Events should be within the terminology binding for that resource.

Daniel Karlsson (Jul 23 2020 at 12:12):

From the Condition resource page: "This resource is used to record detailed information about a condition, problem, diagnosis, or other event, situation, issue, or clinical concept that has risen to a level of concern."

Jeremy Rogers (Jul 23 2020 at 12:13):

I don't recall the precise rationale around adverse reactions and hypersensitivity states being within the Condition resource binding; I remember much pain over the obvious overlap with the AllergyIntolerance resource.

I think the expectation was that the AllergyIntolerance resource would typically be used only for those entries held specifically in some 'patient allergies or intolerances' table within the information model, rather than in any table but according to the SNOMED taxonomy.

But information model "allergy tables" often hold only a very specific subset of all relevant patient allergies: typically only those specifically relating to prescribed medication.

So where do all the other clinically relevant propensities and hypersensitivities go, such as these:

21719001 Hay fever
300916003 Latex allergy
419271008 Dog allergy
39579001 Anaphylaxis

Daniel Karlsson (Jul 23 2020 at 12:15):

Rob Hausam (Jul 23 2020 at 14:56):

@Jeremy Rogers's comment/question about if all phenomena that clinicians identify as a "Problem" on a patient Problem List must be cast only as instances of the CONDITION resource ... isn't strictly true for FHIR generally, as the original notion of at least many in FHIR was that the problem and allergy (and other) lists would be represented as instances of the List resource (sort of seems to make sense?). The List resource instance would then have entries to reference to whatever resource instances are appropriate to be included as items in that list - which, for the problem list, would probably be Condition resource instances in the majority of cases, but would definitely not be limited to only that. But in US Core that idea was rejected in favor of representing the problem list as the set of (active) Condition resources, which, as I recall, was felt to be a simpler and more understandable solution. So it's being done that way in the US, and also elsewhere as the major EHR vendors (Epic, Cerner, etc.) are mostly (or entirely) following US Core.

And I think Jeremy is correct about the reasons for carving out AllergyIntolerance separately from Condition, to represent the allergy and hypersensitivity items that would be included in the separate "allergy list" (or table) - and that does have features like 'criticality" and the associated adverse reaction that distinguish it from the more general Condition. In the AllergyIntolerance resource and systems that I know of, I would expect 'Latex allergy' to be included, as it's clearly a relevant risk in pretty much any healthcare setting. Also I think that 'Hay fever' and 'Dog allergy' might be included on the allergy list, even though they don't represent a risk in the healthcare setting and instead may be conditions to be managed. And when they are conditions to be managed they would also logically appear on the problem list (and could be in both). And 'Anaphylaxis' represents the adverse reaction itself, so it shouldn't be in the allergy list but it can be represented in the AllergyIntolerance.reaction.manifestation, and if it's being actively managed it certainly should be in the problem list.

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · SNOMED CT in Conditions · implementers