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.