We have a need to capture Respirations and Inspired Oxygen, but the Inspired Oxygen observation may be captured independently (apparently!). What is the standard pattern in this case? The neatest solution appears to be replicating the Respirations archetype but nulling the data portion, only capturing Inspired O2 and still making use of the
_other_participation:0|name as per usual.
Hmm interesting, it’s off course physically possible to have person one observe the respiration and person 2 (or computer system) observe the inspired oxygen. But I would say that the inspired oxygen has to be observed by person one for it to be a Observations of the respiration (as scoped by the RM plus use section of the archetypes description). Otherwise it’s just a ‘monkey’ counting breaths/min, not stating an observations about the individuals respiration.
So if you really want to record the people separately I agree with your approach and I would record a link to the inspired oxygen observation in the respiration (frequency) observations.
But I’m really curious for more info from the clinicians:
- Why do different people observe those interrelated values?
- How does it work practically? It’s hard to not see the inspired oxygen when counting the patients breathing frequency.
- Why would you do it with different people this way? Different skills, efficiency reasons, … ?
- How do they look at my statement that the observer of the respiration has to themselves observe the oxygen in order to do a proper observation of the respiration.
- Does it matter which person did which observation, or did they do it together, in that case you could just record both persons as participants in a single observation.
I enjoyed this complex question, I hope I’ve been able to get my views across and that they’re helpful to you.
@johnmeredith Could this be related to requirements 3.2.5.s in Region Östergötlands last pre procurement documents…
“It must be possible to enter a value once in a form in a user interface, and then automatically record that value in more than one place in the template(s) the form is based on.
Example: Enter a value for “Inspired oxygen” in the form once, but record the value in both the “Respiration” and the “Pulse oximetry” observations (in e.g. a vital signs template) when stored.”
Using the OBSERVATION.respiration archetype to only capture inspired oxygen and not respiration sounds like a hack to me. I’m very interested in hearing the answers to Joost’s questions about the context of this requirement.
I have used similar hacks where Respiration (or some other real data) is being collected at the same time but agree not quite right if only inspired )2 is being recorded. I think I would just use some sort of generic Observation container, or maybe we should get on with creating an inspiredO2 Observation ‘wrapper’ for this purpose, or maybe something with broader potential that could be used for mixed gases e.g ICU / anaesthetic settings @johngrant4est - thoughts? I have a feeling we did something for the Better ICU application many years ago where nurses were asked to regularly record ventilator settings, including inspired O2
To me it sounds like this use case would call for an OBSERVATION.ventilator_settings or similar? I think @johngrant4est, @heather.leslie, @varntzen, @nuno.abreu and others worked on archetypes for respirator related stuff last year. Did anything like this come out of that work?
I’m still curious about the details of @johnmeredith’s use case though.
When using a ventilator, or some other closed device, we will know what mix of gases the individual gets, and it is reasonable to record which setting of oxygen it delivers. CLUSTER.inspired_oxygene is for this purpose: “The amount of oxygen being delivered, or to be delivered, to the patient given as a fraction, percentage or indirectly as a flow rate”, and it is assumed that nasal prongs or open masks gives about the same gas mix.
But as I understand the requirement, there is a need to document - from time to time, at how much oxygen the patient “is on”, and not necessarily classify how the patient is actually breathing. I don’t understand why OBSERVATION.respirations is the wrong place to hold that information. Why is it only about the depth, frequency, etc of the respiration? Could the OBS.respiration’s scope be extended?
If not, then there might be a need for an ‘Gas exchange’ OBS where the settings of ventilator (or prongs/mask) related to oxygen delivery is in a SLOT. And also with other signs of how well the patients is breathing/exchanges gas, as skin colour/lip cyanosis, respiratory distress, etc. (This used to be in previous versions of OBS.respiration, but now put into a free text element ‘Clinical description’).
The group worked on it, a bit on and off. For the time being, mostly “off”. I have to revisit the mindmaps and drafts made to be able to give an answer - and also reboot my brain.
I agree with the requirement. However, the way the current OBSERVATION.respiration is modelled, it’s intended to record presence, frequency etc as main data, with information about inspired oxygen only as metadata. This is why the ‘Inspired oxygen’ SLOT is placed in the State section of the archetype, and not under Data. It’s certainly possible to argue that this should be a main data point in itself relating to respiration, and therefore should be placed under the Data section.
The respiration/ventilator group developed a Supplemental oxygen order for use with someone who is spontaneously breathing but needing oxygen supplementation, whether in hospital or at home… It would make sense to develop a matching ACTION that would carry the kind of information about how oxygen is delivered - eg nasal prongs, 4L/minute or x%.
Pulse oximetry OBS would be used to monitor the response.
If on a ventilator there should be a separaate INSTRUCTION for ventilator settings, including oxygen administration, plus a matching ACTION to record how the order was carried out and OBS to record the relevant observations/results. This is extremely complicated but we made good headway until we lost steam towards the end of 2021 . Time to pick it up again.
I have only limited icu experience, but my take would be the recorded oxygen the patient is on is measured to help interpret other breathing related parameters (probably including ventilator settings). So I’d suspect the requirement can be solved by archetypes that support assisted breathing like Heather described.
On the other hand I think it’s fine to only record inspired oxygen as a respirations observation. Since the other respiration data (or other obs) may be implied to be normal enough not to warrant a structured recording. But I’m curious for more details of the clinical requirements by @johnmeredith @ian.mcnicoll and @varntzen
But all clinical scenarios I can come up with it relates to some other measurement.
E.g. gradually phasing out supplemental oxygen. But this should always be done with some feedback parameter imho (SpO2, breathing frequency, patient indicates no breathlessness).
I’d like to retract this suggestion. Both ventilator settings and other oxygen supplementation are active interventions performed, and not biomedical stuff going on in the patients’ bodies that you can only observe. Every time you note that “oxygen on 5 L/min via a plastic cup taped to the pillow”, this is an active intervention, and should be documented via an ACTION archetype.
In the paediatric ICU case, there was actually a need for all 3 INSTRUCTION to request the settings, ACTION to record the settings being made, and OBSERVATION for regular nursing checks that the settings were correct. I think there is a place for an OBSERVATION, perhaps something generic like ‘Respiratory support observations’ that ‘reports’ the status , and could include vent. settings clusters as well as inspired O2 or other gas settings?
The issue in @johnmeredith example is that sometimes the O2 was being recorded in the absence of any other measurements, which was why it seemed odd (hacky!) to use Respirations as a container.
I’m having trouble with this as an OBSERVATION. The oxygen flow doesn’t change unless someone actively changes it, unlike your blood sugar level or pulse rate.
It’d be good to get the full view on John’s use case. In the absence of that, my take on it is that it should be an ACTION, for starting, continuing (or “observing”), or ceasing (oxygen) treatment. ACTION.therapeutic_intervention, or something?
Rethinking this, I agree. Delivery of oxygen doesn’t change of itself, it an active intervention by a human (at least I don’t know of any automatic adjusting, based on readings)- The interventions are either (simplified) “started”, “changed flow”, “still on, no change” or “stopped”. The biomedical readings of the effect of the oxygen delivery should be in OBSERVATION’s and guide the INSTRUCTION and ACTION archetypes. Which OBSERVATION should be further discussed.
Yep, for the observations of how well/not well the patient is considered “Gas exchange”. This should include Pulse oxymetry, lab results (blood gases, pH value in blood, etc).
In the example I encountered, the nurses were asked to observe the vent settings and O2 delivery and record these explicitly, not simply ‘review’ as correct, precisely in case someone had inadvertently changed the settings. So would you use ACTION with some sort of ‘Review’ Careflow_step, for this?
That makes sense to me. If there was a discrepancy between the ordered flow and the actual, I guess that would lead to either correcting it to the ordered level, or an inquiry about why it had been changed?
In the cases where you dynamically adjust O2 flow within an ordered interval to stay at a certain saturation level goal, you’d either record every adjustment, or periodically review and make note of the current level, both as “review” careflow steps?
I think of oxygen prescription, delivery and monitoring (observation) as:
The INSTRUCTION (5L/min, 50% as set on a device such as a venturi mask or ventilator)
The OBSERVATION which in this case is the FiO2 (fraction inspired oxygen) as measured by an oxygen monitor.
Supplemental to this, we have all the OBS related to the patient’s clinical state: respiratory rate and pattern, SpO2 (oxygen saturation as measured by a device), colour etc.
Not sure if it helps but we did a few mind maps on the topic last year:
Other mind maps are available!
Yes, there is a separate requirement for changes to the INSTRUCTION to be documented - what was the change and why. For goal-directed therapy, some indication of the success or otherwise of the change is also useful.