# SpO2 scale 2 decision **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2023-02-17 10:20 UTC **Views:** 1039 **Replies:** 33 **URL:** https://discourse.openehr.org/t/spo2-scale-2-decision/3586 --- ## Post #1 by @NeillY Hi [NEWS2 archetype](https://ckm.openehr.org/ckm/archetypes/1013.1.3342) requires a trigger to select SpO2 scale 1 or SpO2 scale 2, the 'default' being the former and the exception being scale 2. The trigger is a clinical decision to put a patient on scale 2, based on an arterial blood gas result indicating the patient has hypercapnic respiratory failure (HCRF) and/or other factors. We have discussed using the [Problem diagnosis archetype](https://ckm.openehr.org/ckm/archetypes/1013.1.169) but this doesn't include a clinical decision datapoint. There are a couple of archetypes that may provide a clinical decision datapoint but they are in predraft. My inclination is to use the Problem diagnosis archetype and create a specific clinical decision cluster comprising three datapoints - 'Scale', 'Reasons for decision' and 'Authorising clinician' At The Christie we are very much neophytes in archetype design and this is my first post to the forum so go easy and keep it simple :slight_smile: . Happy to provide any required information. Thanks for your interest --- ## Post #2 by @ian.mcnicoll I probably agree here - there may well be a supporting problem entry somewhere in the record to inform the scale1/2 decision but fundamentally this is a decision on which scale i.e very contextual. One option might be too create a cluster as you have described. The other (which I think I would favour) might be to use a Recommendation][(https://ckm.openehr.org/ckm/archetypes/1013.1.5755/mindmap) archetype alongside the news score in the template with Topic set to something like 'NEWS 2 SpO2 scale', Recommendation would be Scale1 or Scale 2 and Rational for 'Reasons for decision'. The Authorising clinician could be carried in the RM 'provider' attribute of the Recommendation, or as a participation - these are not visible in AD but you can set them at run-time ??? in the Form designer. --- ## Post #3 by @joostholslag I might prefer to have an element in the protocol section of the OBSERVATION.news archetype. Because it will improve consistent modelling across implementations. And this decision is crucial to (later) interpretation of the score. --- ## Post #4 by @siljelb [quote="joostholslag, post:3, topic:3586"] I might prefer to have an element in the protocol section of the OBSERVATION.news archetype. [/quote] That may be a good idea, but it would only be a reference to the original decision and not the actual recording of the decision. At least the way NEWS2 is used here in Norway, the decision to use scale 1 or 2 is made by a physician, while the whole NEWS2 is almost universally performed and recorded by nurses. --- ## Post #5 by @ian.mcnicoll And , I think both of these perspectives are equally valid. Which brings us back to having a neater way of either reusing fragments of ENTRY archetypes, i.e pseudo-clusters or having much neater ways of documenting expected References in tooling, or actually maybe both depending on the context of use. In Silje's case. she is expecting to have the original decision documented, perhaps in a seperate composition. In Joost's world this is local documentation of a decision made, and the added complexity of hooking up to the original decision (if that is even formally recorded) seems unnecessary and perhaps even brittle (references can be tricky). A third solution is to add the cluster content directly to the NEWS2 archetype, as this does seem an important ,integral part of the background information. A separate Recommendation archetype can then always be used to carry the original decision but could be linked to the NEWS2 entry. BTW this is not an openEHR issue - we can see FHIR colleagues struggling with similar issues - e.g. reference or codableConcept in Medication order. What we probably can do better is to more clearly support the various choices in the tooling and associated advice. --- ## Post #6 by @ian.mcnicoll So for poor @NeillY . There is a decent case for adding a SPO2 Scale decision Cluster archetype, which could be added directly to the NEWS2 archetype extension slot for now. That would document the decision and rationale 'in context'. If you wanted to formally document the decision, I would use EVALUATION. recommendation, as I don't think this is really a Diagnosis as such but probably still carry the CLUSTER.SPO2Scale Decision inside NEWS2. I know this is redundant but .... @joostholslag @Silje - should that new cluster really just be added internally to NEWS2? --- ## Post #7 by @joostholslag Hmm, I think there is some more detail. I agree the rescission to use either scale 1 or 2 is usually a doctors decision. However, the doctors decision is probably generic: “when using news, use scale 2” (makes sense as an evaluation archetype in probably a separate composition, or maybe as part of the instruction to take the news twice daily). The decision to thus for this specific observed news scale use scale 2, to me still makes most sense as an element (cluster?) in the observation recorded by the nurse. Or will you as a nurse ask the doc multiple times a day, what scale to use? --- ## Post #8 by @ian.mcnicoll Good discussion - I feel that all the approaches raised are valid, including even documenting the Scale decision as part of a Service request Instruction, so keeping the details on a CLUSTER archetype gives us the flexibility to use in different ways, according to local decision-making and recording purposes. If the original decision is to be carried separately though, I would not favour using Problem-Diagnosis though - Either Recommendation or as part of service request would be a better fit, I think. --- ## Post #9 by @NeillY Thank you all. I'm back from leave and appreciate your guidance. For context, nurses currently record which doctor made the decision to put the patient on Scale 2 when they record the vital signs that generates the NEWS2 score. We are currently addressing this anomaly and intend to have that decision recorded as part of the medical admission documentation and doctor's inpatient review. The intention is then to surface that decision wherever a NEWS2 score is being derived. The NEWS2 guidance states that the decision to put a patient on Scale 2 should be dependant on an arterial blood gas result confirming HCRF and a future template will probably include a lab result field. However, the clinician ultimately makes the decision and currently we have issues with clinicians making the wrong decision so I believe it would be optimal to have the decision recorded explicitly in the RM. I'll review your posts and hopefully construct a solution for review Thanks again Neill --- ## Post #10 by @NeillY I see the value in using Recommendation, but what is the best way of recording the Recommender (aka clinician) if they weren't submitting the composition. We have to cater for this scenario where staff record on behalf of others. --- ## Post #11 by @thomas.beale Use [Composition/context/participations](https://specifications.openehr.org/releases/UML/latest/index.html#Diagrams___18_1_83e026d_1433773264253_175551_6601) or [Entry/other_participations](https://specifications.openehr.org/releases/UML/latest/index.html#Diagrams___18_1_83e026d_1433773264186_722854_6498) (these are both built into the reference model). --- ## Post #12 by @Leuschner Hi everyone, Is it me, or this discussion is mixing in too many subjects? - SpO2 is a common data structure that reflects a common, well defined clinical entity; defined as such in an archetype; - NEWS is a scale that tries to model (as in simplify) patient severity, that relies on common data points; - the advent of NEWS2 proved to us what most of us knew: secondary uses are less persistent, and thus might as well (or better) be modeled as templates; - The decision to use one or the other is business logic. That, from my understanding of openEHR, should be modeled either in the RM, the DLM, or at work process level (PROC). What do you think? Best regards, Thomas Beale via openEHR <[discourse@openehr.org](mailto:discourse@openehr.org)> escreveu no dia terça, 7/03/2023 à(s) 15:08: --- ## Post #13 by @ian.mcnicoll Hi Pedro, You have slightly misunderstood !! In all cases both NEWS2 AND SPO2 would be used, the problem is that NEWS2 calculation rules differ in the case of patient with COPD. This is known as scale1 vs scale2 - so it is the same SPO2 result but the calculations are made differently depending on where 'scale 1' or 'scale 2' is used. The decision on which scale to use in the calculation for a particular patient, is generally made by a doctor, in advance of the NEWS score being deployed. So the question asked was where and how to capture that at decision. Hope that makes sense!! --- ## Post #14 by @ian.mcnicoll In this case, definitely RM other_participations though I'm not sure that is supported directly by Better Studio without scripting --- ## Post #15 by @NeillY Thanks Thomas I'm aware of Attributes available in the archetypes but have no concept of how to use these to collect data at the user interface. We are using Better Form Builder and I see no surfacing of Attributes in that but perhaps it has to be scripted into a generic field. I feel that my knowledge is particularly weak in this area so if you could direct me to a neophyte resource that would be great (I'm afraid those diagrams you posted links to are beyond my intelligence quotient :slight_smile: ). --- ## Post #16 by @Leuschner Thanks for the clarification, Ian. I think I understood the use case, but was nevertheless trying to decompose the problem. Please correct me if I'm wrong. I'm not acquainted with the depths of the News scales. But BTS and other respiratory authorities have been wisely advocating lower SpO2 targets for COPD patients. As such, it might be unlogical and even dangerous to use news as a severity score. I would risk saying that news2 tried to mitigate that fault by asking clinicians to choose one or the other spo2 cutoffs. Maybe the clinical decision should be represented (and captured!) upstream of any scale, and reflected all along the care pathway. Of more importance to the patient, with respect to the prescribed target Spo2 (primary use). But also for any given scale. I dare to add that a subjective choice is not a good starting point for a scale that aims to objectively stratify risk 😉 Anyways, let's work on improving it's openEHR modeling! A terça, 7/03/2023, 16:43, Ian McNicoll via openEHR <[discourse@openehr.org](mailto:discourse@openehr.org)> escreveu: --- ## Post #17 by @thomas.beale [quote="NeillY, post:15, topic:3586"] I’m aware of Attributes available in the archetypes but have no concept of how to use these to collect data at the user interface. We are using Better Form Builder and I see no surfacing of Attributes in that but perhaps it has to be scripted into a generic field. [/quote] That should be addressed in the tool - those fields are where other software will look for that kind of data. Definitely get Better to look at that - not having access to RM fields on forms is a real problem - the right data will not be created. --- ## Post #18 by @NeillY It's more than likely that I just don't know how to do it. I will ask Better --- ## Post #19 by @ian.mcnicoll @NeillY - on the template view you can click on a button that exposes lower-level RM attributes that can be incorporated in the form. You can see composer, ism_transition attributes , start_time etc. However not participations. They are supported in the Better CDR and I have used scripting in other circumstances to access these sort of attributes that are hidden in the from builder but I agree with Thomas that they really should make them available especially participations and the Entry.provider attribute. ![2023-03-08_11-18-56|251x500](upload://93gWn6dtiAxRW8iEw8bVl12Ybc2.png) --- ## Post #20 by @NeillY @ian.mcnicoll are you able to provide an example of scripting to surface participations? Thanks Neill --- ## Post #21 by @ian.mcnicoll Not off-hand, sorry. I think it is possible but you would need to ask Better for an example. I'd also ask then to support participations and the Entry.provider attribute properly in Studio. --- ## Post #22 by @NeillY Better are planning to incorporate RM attributes in a future release (but they all say that, don't they :grinning:). Assuming the person completing the form is the authorising clinician, then I guess Composer will be sufficient? We'll work it out. Better has some interesting documented advice on scripting, which can be best summarised as 'it can be done, but don't' or 'abandon hope all who follow this path' :laughing:, at least for neophytes like our team. --- ## Post #23 by @siljelb [quote="NeillY, post:22, topic:3586"] Better are planning to incorporate RM attributes in a future release (but they all say that, don’t they :grinning:). [/quote] Yes, they do, and it's somewhat alarming. Published archetypes in the international CKM are created with the explicit expectation that all RM elements are usable when using the archetypes to create software. Creating solutions without having access to them *will* lead to local hacks. --- ## Post #24 by @thomas.beale Yep - not having those RM attributes available to downstream tools is quite a serious problem. Vendors take note please! --- ## Post #25 by @siljelb Picking this discussion up again - have anyone found a way to persist this decision about which SpO2 scale to use when calculating NEWS2? Looking at the [guidance from the RCP](https://www.rcp.ac.uk/media/a4ibkkbf/news2-final-report_0_0.pdf)... > NEWS update: Using the NEWS2 oxygen saturation (SpO2) scoring systems > • The new SpO2 scoring Scale 2 is for patients with a prescribed oxygen saturation requirement of > 88–92% (eg in patients with hypercapnic respiratory failure). This should only be used in patients > confirmed to have hypercapnic respiratory failure on blood gas analysis on either a prior, or their > current, hospital admission. > • The decision to use the new SpO2 scoring Scale 2 should be made by a competent clinical decision-maker and should be recorded in the patient’s clinical notes. > • In all other circumstances, the regular NEWS SpO2 scoring scale (Scale 1) should be used. > • For the avoidance of doubt, the SpO2 scoring scale not being used should be clearly crossed out > across the chart ...it's still clear to me that this decision needs to be recorded separately from each recording of NEWS2, and in a way that can be easily queried regardless of the original recording context. Looking at archetypes such as Problem/diagnosis, Recommendation or Precaution, all of them are dependent on terminology to be able to easily find a specific recorded concept, and I can't find any terms about this in either SNOMED CT, LOINC or any other terminology (UK SNOMED has [some local terms that may be usable](https://termbrowser.nhs.uk/?perspective=full&conceptId1=1104071000000105&edition=uk-edition&release=v20250924&server=https://termbrowser.nhs.uk/sct-browser-api/snomed&langRefset=999001261000000100,999000691000001104), but I'm not at all sure). So then what are we left with? Using presence or absence of a hypercapnic respiratory failure diagnosis (`709109004 |Hypercapnic respiratory failure (disorder)|` / `ICD-10::J96.?1`) as a proxy (against the guidance that the *decision* should be recorded)? Making a specific `EVALUATION.news2_spo2_scale_decision` archetype? Something else? --- ## Post #26 by @ian.mcnicoll This feels like a good fit for a Recommendation using these uk snomed terms. It is not really a diagnosis in my view though obviously closely related. A nice wee demo for our shiny new ontoserver?. Might raise some issues re snomed license but that too is a really nice exemplar for discussion with snomed International? --- ## Post #27 by @siljelb [quote="ian.mcnicoll, post:26, topic:3586"] using these uk snomed terms [/quote] Within the UK that may be viable, but it isn't anywhere else. So if using an archetype like Recommendation we'd need to create a specific openEHR value set for this purpose? --- ## Post #28 by @ian.mcnicoll Or push for the uk codes to be part of the international release , or get something added to loinc and fhirised --- ## Post #29 by @siljelb How do we do those things? :sweat_smile: --- ## Post #30 by @heather.leslie I asked this question of Don Sweete and he reassured me we (openEHR) can request terms to be added to the international release. Not sure how to do it in practice, but if we can’t work it out, we can contact them to find out. We have permission! --- ## Post #31 by @yampeku Ideally the easiest way is that national nodes part of snomed (e.g. Norway, Spain…) put the codes into their national snomed extension, and from there they can escalate to snomed international. We should be doing this already as the sooner we start the sooner we can get codes into the archetypes which definition is exactly the archetype semantics (e.g. rich internal valuesets or even element bindings) --- ## Post #32 by @siljelb I've requested them to be put into the .no extension and for our NRC to request them as international concepts as well. --- ## Post #33 by @ian.mcnicoll Excellent . Do we need to also have a local codesystem, for folks who can’t use SNOMED for licensing reasons? Or is this something to negotiate with SNOMED as a set of free terms? --- ## Post #34 by @damoca It seems that the SNOMED terminology discussion has hijacked this topic, so I have created another one: https://discourse.openehr.org/t/openehr-snomed-ct-extension/11600 --- **Canonical:** https://discourse.openehr.org/t/spo2-scale-2-decision/3586 **Original content:** https://discourse.openehr.org/t/spo2-scale-2-decision/3586