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.
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.
Better are planning to incorporate RM attributes in a future release (but they all say that, don’t they
).
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’
, at least for neophytes like our team.
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.
Yep - not having those RM attributes available to downstream tools is quite a serious problem. Vendors take note please!
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…
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, 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?
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?
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?
Or push for the uk codes to be part of the international release , or get something added to loinc and fhirised
How do we do those things? ![]()
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!
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)
I’ve requested them to be put into the .no extension and for our NRC to request them as international concepts as well.
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?
It seems that the SNOMED terminology discussion has hijacked this topic, so I have created another one: