Hi all,
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.
Thoughts?
1 Like
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.
3 Likes
@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
1 Like
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. 
1 Like
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â).
1 Like
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.
1 Like
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.
2 Likes
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.
2 Likes
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.
2 Likes
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.
1 Like
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).
1 Like
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?
2 Likes
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:
https://drive.google.com/file/d/1drg2euhBrVG_UBOgMD0Kc8kwTQgzkmWW/view?usp=sharing
Other mind maps are available!
1 Like
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.
1 Like