Adding Participation to a Cluster - Inspired Oxygen

This is an interesting thread. Sticking my oar in little bit: I would suggest that if there is difficulty in agreeing whether all ‘inspired oxygen’ is the same thing clinically (even if it is in some physics sense), consider what you want to get back when you run a query on that data point; another way of saying this is: make sure the data items are truly comparable.

If you don’t really want to get back inspired O2 in an anaesthetic situation mixed up with PPO or ventilator O2 from a Covid situation, then the ‘inspired oxygens’ are different things - ontologically. Possibly something like ‘inspired oxygen (anaesthetic gas mix)’ versus ‘inspired oxygen (freely breathing)’ versus ‘inspired oxygen (ventilation setting)’. Others here will know the true categories better than I do, but you get the idea.

Using the ‘do I want these things to come back from the same query’ test is quite useful in general…


I think we are ok here, Thomas because Inspired O2 is a CLUSTER so can be used in all of these different contexts, and it is the parent context that will tell us if uses a re comparable. It is more a of a utility pattern, like Device.

The problem being discussed now is what to do when people want record ‘just the inspired O2’ - i.e what parent ENTRY archetype should it sit in, if there is no other information being recorded. In the past I have simply put it into another

My understanding of John’s original problem is a typical nursing vital signs chart but with the option of only recording inspired O2, absent any of other possible typical observations.

@johngrant4est your O2 monitor is interesting - I guess this is measuring the O2 coming from the machine, not in the patient , but perhaps strengthens my argument for having an OBSERVATION container (or not!!)


I’ve done a lot of these charts, typically in writing every clock hour. But did I record what the patient was given or what the patient inhaled? For that sake, if I were extremely sloppy, the patient could be dead in it’s bed, but still the nasal cannula would deliver 3 l/min of O2.

If I at the same time recorded the patient’s saturation of O2 via the Pulse oxymetry (preferrably not 0%), I would do an observation of the gas excange with the amount of oxygen delivered. That makes sense.

But recording the O2 delivery only, is a documentation of the treatment to the patient, not the patient itself. And treatments belong in ACTIONs, is my take.

1 Like

Right - that’s good.

Dumb question: the obvious approach is some kind of ‘breathing’ OBS archetype with all these related data-points, most or all being optional…but I assume this has been discounted in the past?

The concept of “inspired oxygen” as an INSTRUCTION can be either:

  • a fixed concentration, perhaps as a fractional component of an inspired gas mix as you’d have in a typical ICU setup, or from a fixed-concentration device like a 35% venturi mask


  • it’s a flow rate e.g. 5L/min via a variable-flow device like nasal specs, HFNOT or a simple mask where the actual FiO2 is unknown.

Even in a ventilator circuit, there is a performance range, so a breathing system will typically have an O2 sensor in it somewhere, usually at the patient end. This allows us to record inspiratory O2 as either % or flow AND to measure what the device is actually delivering. The use of FiO2 sensors is part of the mandatory minimum monitoring standards in the UK, so they are essentially ubiquitous.


I think the challenge is how to build a ‘breathing’ OBS archetype that can cope with clinical OBS and the complexities of ventilator-patient interaction. FiO2 is both an OBS and an INSTRUCTION, as is Resp Rate, and tidal volume. I’d argue that we need different archetypes for these two different aspects of assisted ventilation.


Despite investigating the respiratory domain modelling in-depth for the past few months, I’m finding this thread quite confusing. I suspect we are all talking slightly at cross purposes here.

A group of us started to map out the components of the whole ecosystem last year and it quickly became apparent how complex it all is. As @johngrant4est notes, we are trying to model breathing, but under a broad and complex range of contexts.

For consideration:

  • Spontaneous breathing also occurs in the context of being on a mechanical ventilator, so we need to revise the OBS.respiration from that POV.
  • We seem to be using the word ‘observation’ somewhat interchangeably in different situations - what we observe, what we measure and the OBSERVATION class.
  • The CLUSTER.inspired_oxygen, although published, may need review as the way to record it for home oxygen therapy or ward supplementation via nasal prongs vs mechanical ventilation requires different documentation, not necessarily a reusable CLUSTER.

@johnmeredith’s original question doesn’t specify recording the inspired oxygen in a ventilated or unventilated setting - I suspect we need different models for each. If it is on the wards, with nasal prongs attached to a wall source for oxygen, then the details are quite different to the FiO2 detected/monitored within a closed breathing system.

As far as the family of archetypes are concerned, we need:

  • Orders (INSTRUCTIONs) for both oxygen supplementation and mechanical ventilation (whether breath generation is spontaneous or not).
  • Each will need matching ACTIONs to record how the order was carried out, what was actually done, including what we set each dial to on the flow meter or ventilator.
  • Monitoring of the actual patient parameters will be via Pulse Oximetry, ABG results, respiration rate/pattern etc - all OBSERVATIONs. In turn, the orders may be continuously adjusted/fine-tuned related to the measured parameters.
  • Another possible OBSERVATION might be a record of the settings/internal monitoring of FiO2 etc as an output from the ventilator device over an interval of time. These may or may not match what we set the ventilator dials to!

When I get lost in the modelling complexity, I look for the patterns, especially those that we have already worked out.

So, if we extrapolate the medication administration example to supplemental oxygen administration, I start to find some clarity.

The INSTRUCTION.supplemental_oxygen_order is intentionally closely aligned with the INSTRUCTION.medication_order. We also need an equivalent INSTRUCTION for a mechanical ventilation order (yet to be built). All are effectively prescriptions for different therapeutic interventions.

IMO we need to explore aligning the ACTION for supplemental oxygen management and another for ventilator management (both yet to be built) as closely can be made relevant to the Medication management (ACTION.medication).
In this way, just as the administration of 500mg amoxicillin may be recorded as 1x500mg of a branded drug or substituted with 2x250mg of a generic in the Meds ACTION, the actual administration of the oxygen should be recorded in the Supplemental oxygen ACTION. The order for 2-4L/min with an oxygen target of 94-98% via device A might result in the actual administration (ie what a nurse records on the chart at the end of the bed on an hourly basis or in an ACTION archetype of an EHR) as:

  • 4L/min via device A, dropping to 2L/min over time as the respiratory condition settles; OR
  • 4L/min via plastic cup taped to the pillow of a distressed toddler until an oxygen tent could be set up.

Same deal, orders more complexity for the Ventilator Management ACTION.

Note that while the nurse ‘observes’ and charts a patient swallowing 2x250mg tablets of medication, we don’t record it using an OBSERVATION class. In the same way, we can record the Flow rate of oxygen or the measured FiO2 from the ventilator in a relevant ACTION archetype. Simultaneous recording of the BP, pulse, temp etc as the measured patient parameters is captured using OBSERVATION class archetypes. If we need to record the flow rate/FiO2 as part of the ‘state’ of an OBSERVATION, this could be linked or copied - implementers need to think about the best approach here.

It is messy. The ACTION records what we did, even if it doesn’t match exactly with the original INSTRUCTION or there is a deviation from the ideal pathway.


Thank you, @heather.leslie for wording what I tried to say above (but didn’t succeed).
When we use the Inspired_oxygen CLUSTER within the Respirations OBSERVATION, it is to give context to the data in OBSERVATION. And using the inspired_oxygen CLUSTER without any data in a OBSERVATION doesn’t make sense. It gives context to … nothing.