FHIR Chat · Resource "Observation Oxygen Saturation" · terminology

Stream: terminology

Topic: Resource "Observation Oxygen Saturation"


view this post on Zulip Heike Dewenter (Jun 19 2018 at 13:52):

While working with the resource "Observation oxygen-saturation ", I believe that there is a wrong annotation. The observation code should be changed to "20564-1 - Oxygen saturation in blood" - representing a vital sign measurement in a more generic way - according to 1.2.276.0.76.10.4031 .

view this post on Zulip Eric Haas (Jun 19 2018 at 15:35):

I think you are talking about this Observation profile. This issue has gone undergone extensive committee discussion both in FHIR and CCDA. The vital sign spO2 is defined by the US Meaningful use 2015 Clinical Common data set and is a method based observation. If you want to represent a laboratory measure then the above LOINC would be appropriate.

view this post on Zulip Lloyd McKenzie (Jun 19 2018 at 18:54):

US meaningful use shouldn't be a primary driver of a profile with universal applicability. The question is what is the appropriately broad LOINC code that encompasses the scope of the vital sign. If that happens to align with the US meaningful use code, great. If not, both can be sent in an instance if need-be.

view this post on Zulip Robert McClure (Jun 20 2018 at 18:17):

Agree with @Lloyd McKenzie here. I was not a participant in the discussions that led to the method-specific code for O2 saturation in the US Core and Argonaut vital sign list. I for one think this and the same for head circumference are a problematic mistake, particularly with the Extensible binding which means you SHALL map a vital sign observation using a different method to this specific method LOINC code. Think how that play out in ICU patients getting regular arterial blood gas observations. I'd be happy to help improve this for the base resource if that is the best solution.

view this post on Zulip Lloyd McKenzie (Jun 20 2018 at 18:59):

Technically, extensible says that "if your concept is covered by one of the concepts inside the value set, you must use it". If the concepts are overly narrow, you have the reverse problem. Someone who wants to send a concept of "Head circumference, ultrasound" or "Head circumference, no method specified" would NOT be expected to use "Head circumference, tapemeasure", which means that rather than getting all head circumferences grouped consistently, you're inviting for non-consistency.

view this post on Zulip Robert McClure (Jun 20 2018 at 20:19):

@Lloyd McKenzie Yes, that is the presumed interpretation of the words "covered by" but for some, that might not be clear. We often find people asking if they are expected to map to a different code that only partially matches - if they even ask. I've added a GForge ticket 17394

view this post on Zulip Eric Haas (Jun 22 2018 at 05:07):

link to this issue on argonaut channel to get implementer feedback: https://chat.fhir.org/#narrow/stream/20-argonaut/subject/US.20Core.20vital.20signs.20code.20for.20SpO2/near/160509

view this post on Zulip Grahame Grieve (Jun 22 2018 at 12:11):

I personally think that the intent of the profile is clear: head circumference by eany method, and o2 sat by any method.

view this post on Zulip Rob Hausam (Jun 22 2018 at 12:24):

I agree. I think we should be consistent and use the methodless ("any method") codes throughout. And that also applies to "Body height" (as "Body length" is actually "Body height --lying") . If the more specific codes also are needed (e.g. in pediatrics) they can be sent as additional translation codes.


Last updated: Apr 12 2022 at 19:14 UTC