# Adding Participation to a Cluster - Inspired Oxygen **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2021-12-09 16:19 UTC **Views:** 666 **Replies:** 27 **URL:** https://discourse.openehr.org/t/adding-participation-to-a-cluster-inspired-oxygen/2180 --- ## Post #1 by @johnmeredith 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? --- ## Post #2 by @joostholslag 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. --- ## Post #3 by @erik.sundvall @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." --- ## Post #4 by @siljelb 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. --- ## Post #5 by @ian.mcnicoll 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 --- ## Post #6 by @siljelb [quote="ian.mcnicoll, post:5, topic:2180"] nurses were asked to regularly record ventilator settings, including inspired O2 [/quote] 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. :smiley: --- ## Post #7 by @varntzen [quote="siljelb, post:6, topic:2180"] To me it sounds like this use case would call for an OBSERVATION.ventilator_settings or similar [/quote] 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'). --- ## Post #8 by @varntzen [quote="siljelb, post:6, topic:2180"] 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? [/quote] The group worked on it, a bit on and off. For the time being, mostly "off". :slight_smile: I have to revisit the mindmaps and drafts made to be able to give an answer - and also reboot my brain. --- ## Post #9 by @siljelb [quote="varntzen, post:7, topic:2180"] 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? [/quote] 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. --- ## Post #10 by @heather.leslie [quote="siljelb, post:9, topic:2180"] 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. [/quote] The respiration/ventilator group developed a [Supplemental oxygen order](https://ckm.openehr.org/ckm/archetypes/1013.1.5692) 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 :woozy_face:. Time to pick it up again. --- ## Post #11 by @joostholslag [quote="varntzen, post:7, topic:2180"] 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? [/quote] 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). --- ## Post #12 by @siljelb [quote="siljelb, post:6, topic:2180"] To me it sounds like this use case would call for an OBSERVATION.ventilator_settings or similar? [/quote] 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. --- ## Post #13 by @ian.mcnicoll 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. --- ## Post #14 by @siljelb [quote="ian.mcnicoll, post:13, topic:2180"] I think there is a place for an OBSERVATION, perhaps something generic like ‘Respiratory support observations’ that ‘reports’ the status [/quote] 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. [quote="ian.mcnicoll, post:13, topic:2180"] 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. [/quote] 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? --- ## Post #15 by @varntzen [quote="siljelb, post:14, topic:2180"] it should be an ACTION, for starting, continuing (or “observing”), or ceasing (oxygen) treatment. ACTION.therapeutic_intervention, or something? [/quote] 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. --- ## Post #16 by @varntzen [quote="ian.mcnicoll, post:13, topic:2180"] I think there is a place for an OBSERVATION, perhaps something generic like ‘Respiratory support observations’ [/quote] 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). --- ## Post #17 by @ian.mcnicoll [quote="siljelb, post:14, topic:2180"] 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. [/quote] 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? --- ## Post #18 by @siljelb [quote="ian.mcnicoll, post:17, topic:2180"] 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? [/quote] 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? --- ## Post #19 by @johngrant4est 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](https://drive.google.com/file/d/1drg2euhBrVG_UBOgMD0Kc8kwTQgzkmWW/view?usp=sharing) Other mind maps are available! --- ## Post #20 by @johngrant4est 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. --- ## Post #21 by @thomas.beale 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... --- ## Post #22 by @ian.mcnicoll 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!!) --- ## Post #23 by @varntzen [quote="ian.mcnicoll, post:22, topic:2180"] 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. [/quote] 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. --- ## Post #24 by @thomas.beale [quote="ian.mcnicoll, post:22, topic:2180"] 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 [/quote] Right - that's good. [quote="ian.mcnicoll, post:22, topic:2180"] 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 [/quote] 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? --- ## Post #25 by @johngrant4est 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 OR * 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. --- ## Post #26 by @johngrant4est 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. --- ## Post #27 by @heather.leslie 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](https://ckm.openehr.org/ckm/archetypes/1013.1.5692) is intentionally closely aligned with the [INSTRUCTION.medication_order](https://ckm.openehr.org/ckm/archetypes/1013.1.5946). 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](https://ckm.openehr.org/ckm/archetypes/1013.1.123)). 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. --- ## Post #28 by @varntzen [quote="heather.leslie, post:27, topic:2180"] It is messy. The ACTION records what we did [/quote] 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. --- **Canonical:** https://discourse.openehr.org/t/adding-participation-to-a-cluster-inspired-oxygen/2180 **Original content:** https://discourse.openehr.org/t/adding-participation-to-a-cluster-inspired-oxygen/2180