Stream: implementers
Topic: Inspired Oxygen
Ludvig Eek Hofmann (Mar 23 2021 at 10:13):
Hi!
I have a question about a design solution for Inspired oxygen.
The use case is that we would like to communicate if a patient has received supplemental oxygen or not. We want to use an observation-profile that is contained within an observation saturation profile.
The inspired oxygen information we want to communicate is if the patient has received oxygen or not aswell as the flow rate of that oxygen if the patient has received oxygen.
As we see it there can be different solutions for sending this information.
Solution 1:
- Add value set in observation.code.coding.code that holds two codes telling that the patient has either received oxygen or not received oxygen.
- Add the flow rate as a ValueQuantity in observation.value.
Comment: We would rather use a Snomed CT code of the type Observable entity. In this solution we would need to send codes of the type finding.
Solution 2:
- Add a code (observable entity) for Inspired oxygen in observation.code.coding code
- Add either a value set or a boolean for saying that the patient has received oxygen or not in observation.component
- Add the flow rate as a valueQuantity in a second observation.component.
Comment: Is this a valid use of the component elements in an observation profile?
Is there anyone else that has implemented or done a profile for inspired oxygen or that have some input if this is a valid use of the components in an observation profile?
Thank you!
Lloyd McKenzie (Mar 23 2021 at 13:20):
If you have a flow rate, why do you need a boolean? Could you ever have a boolean of false and a flow rate > 0? It seems they are both separate observations and the assertion of "has received" would be derived from the flow rate?
Ludvig Eek Hofmann (Mar 23 2021 at 14:39):
Hi, thank you for your answer @Lloyd McKenzie .
We need to support the use case where we do not have a flow rate but only the information if the patient has received oxygen or not. We also want the profile to be as similar to the openEHR archetype as possible, even if we only support flow rate and if the patient has received oxygen or not: https://ckm.openehr.org/ckm/archetypes/1013.1.393/mindmap
Lloyd McKenzie (Mar 23 2021 at 14:51):
It still seems like these are separate statements. Patient is/was on oxygen. Oxygen flow rate was X. They could both be linked as part of a panel, but one isn't a 'qualifier' of the other where it can't make sense on its own.
Eric Haas (Mar 23 2021 at 20:06):
see US Core Pulse Oximetry Profile
Eric Haas (Mar 23 2021 at 20:08):
make em components and call it a day.
Lloyd McKenzie (Mar 23 2021 at 20:16):
That profile is rather different. It's saying "their blood oxygen is at X", but also conveying (and by the way, their getting 2 litres/minute of pure O2 to get their number that high) - which is an essential part of understanding the pulseox value.
What Ludvig is asking for is "is the patient on oxygen?" and "What's the flow rate?" The situation is not the same in terms of dependency and inability to interpret the one value without knowing the other.
Ludvig Eek Hofmann (Mar 24 2021 at 07:46):
Thanks for the discussion @Lloyd McKenzie @Eric Haas ,
To add more information, I also want to add how we handle the information in our system.
When adding oxygen saturation information, you can also add whether the patient has received oxygen or not. If 'Yes', you can also add the flow rate for that oxygen.
Inspired oxygen information cannot stand alone in our system and is connected to the saturation archetype, similar to openEHR. The flow rate cannot be added unless we have already said that the patient is receiving oxygen.
In a post scenario, if the flow rate was communicated from an external system without the response to "is the patient on oxygen?" we either do not listen to it or interpret it as if the patient has received oxygen because we are getting the flow rate.(We want to avoid this).
In a get scenario, we would always communicate the inspired oxygen information "if the patient is receiving oxygen" and if so, there may be additional information about the flow rate if it was documented (not mandatory).
In both scenarios, the inspired oxygen data will be information related to the saturation of the patient because it is stored internally in that archetype. We can only store the inspired oxygen data on our internal OxygenSaturation archetype.
Today we intended to use a contained observation resource in the observationSaturation profile in one of the above formats. But I see and understand your arguments here. May I ask what you would recommend?
Lloyd McKenzie (Mar 24 2021 at 12:49):
If you're sending an O2 sat, then sending "yes, the patient was on oxygen" as a component is completely reasonable (and sending the rate as a separate component). The question is more about sending inspired oxygen on its own. For that, the 'standard' observation would be the flow rate. That's what most systems would expect to be in Observation.code and Observation.value. If you need to send a flag that also says "patient is on oxygen", you could do so as a component, but that would be largely redundant. Sending the flag as your root code and the flow rate as a component wouldn't be terribly interoperable because most systems looking for flow rate wouldn't expect to look for it in a component (except as a component of O2 sat).
Gay Dolin (Mar 24 2021 at 14:40):
Just FYI - premature infants are frequently on nasal cannula liter flow at varying rates delivering "room air". Just the flow helps prevent apnea and bradycardia.
Last updated: Apr 12 2022 at 19:14 UTC
