SpO2 scale 2 decision


NEWS2 archetype 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 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


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][(Clinical Knowledge Manager) 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.


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.

1 Like

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.


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.


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?


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?

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.


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


1 Like

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.

Use Composition/context/participations or Entry/other_participations (these are both built into the reference model).

1 Like

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> escreveu no dia terça, 7/03/2023 à(s) 15:08:

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!!

In this case, definitely RM other_participations though I’m not sure that is supported directly by Better Studio without scripting

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: ).

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 :wink:

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> escreveu:

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.

1 Like

It’s more than likely that I just don’t know how to do it. I will ask Better

@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.

1 Like