Most standardised scores and scales would be modelled as separate OBSERVATION archetypes, I think.
1 Like
Agree they are their own entities with their own very specific definitions
So for generic “severity” there are currently are 3 semantically-progressive texts that align with SCT codes, and also refer externally to “activity.” That is low resolution.
Likert scales are most often 5-point, ranging from 2 to 10 - so resolution is to 1 decimal. The downside of hi resolution is to magnify inter-user variation, whereas lo resolution forces choices that may be wrong.
% is suggested, and @ian.mcnicoll wrote “we have come across a few places where 0 to 100 is the range used.” Did these use this generic archetype but ideally would have a separate OBSERVATION archetype?
As others have suggested SCT has 2 further terms, for Trivial 162466003 , and for Very Severe 162471005.
So adding these would give a 5-point text scale at 1-decimal resolution.
As these extend the current range, data already recorded would be compatible?
Suggest to define Trivial as “The intensity … is not present during normal activity”
For Very Severe “The intensity … prevents any activity”
(In Severe, the def seems to have a typo: “The intensity … causes prevents normal activity.” but “causes” is redundant)
2 Likes
Hi Ian,
Can you share those examples? I’m curious to understand the requirement better.
If we are recording the result of asking a patient to describe the severity of a symptom they are experiencing, I don’t understand how they can differentiate between 70 and 71 out of 100 with any precision.
Thanks
Heather
THi Heather,
This cam from the Dutch ZIB models
https://zibs.nl/wiki/PainScore-v4.0(2020EN)
The score is a general measurement of pain experience, not a description of specific, localized pain.
Depending on the measuring method used, it indicates the level of pain experienced by the patient on a scale of 0 to 10: 0 = no pain and 10 = the worst pain imaginable. No descriptions are used for the intermediate values, so that the value is displayed as a number and not as a code.
Sometimes a value range of 0-100 is used instead of 0-10."
and digging a little further
For what it’s worth I share your clinical view that 71 vs 72 is pretty meaningless, nevertheless 0…100 does seem to be fairly established. Tom’s suggestion of using Proportion initially seemed counter-intuitive but I can see how it does solve the problem, though I would question whether comparing different VAS scores with different ranges is going to be a real-world requirement. A lot will depend on the content of the question, not just the response.
1 Like
Thanks. Very helpful
The archetype has constraints of 0-10 to support the Numerical Pain Rating Scale (NPRS) exactly as described in the BPS document.
The range of 0-100 requirements seem to come into play with the VAS - measuring a mark made by the patient somewhere along a 10 cm scale. Interestingly it’s not described as a 100mm scale.
From memory, we did discuss this at the time of archetype review and publication but decided that it was measuring the same thing but in a slightly different way. In response, we changed the data type from a DV_COUNT (which is all the NPRS requires) to DV_QUANTITY (using a Qualified real property allowing a single decimal point) so that a point that was recorded at 7.1 cm along the 10cm scale could be recorded as ‘7.1’ rather than ‘71’. In this way, both rating scales could utilise the same data element.
We clearly haven’t captured this adequately in the archetype to explain that logic. Rather than changing anything is it possible to cater for the ZIBS/VAS requirement in this way? It makes more sense to me to record the actual ‘7.1’ rather than recording ‘71’. The level of accuracy of where a patient makes that mark on the 10cm scale will never be significant to the millimetre but the clinical intent is really to achieve the same outcome.
My less favoured alternative would be to extend the existing data element constraints to 100.
I don’t see any reason to go down the Proportion path.
While I doubt that we would ever query this directly, there may be situations where we want to graph pain levels eg an NPRS scale in a patient app followed by a VAS while in hospital. Keeping constraints at 0-10 means we could graph these measurements without transformation.
My 10c worth…
BTW
It might be worth letting the ZIBS people know that the link references a specialised archetype for pain that no longer exists 
1 Like
Hi Colin,
This data element is intended to carry the patient’s estimate of the severity for a single symptom, usually as part of ad hoc history-taking in a consultation or perhaps the context of a screening questionnaire for any symptoms.
I agree that many of the thousands of indexes and scores have different ways of doing things related to recording symptom severity including text categories and specific timeframes or contexts eg ‘rate the severity of x during the past 3 nights’. We have example archetypes faithfully representing the exact content of many scores and scales as standalone OBSERVATIONs. I’d suggest that the MMPI should be best represented as it’s own archetype or family of archetypes that carefully represents all of the questionnaire, including the validated value options, rather than trying to reuse this CLUSTER for that purpose.
Regards
Heather
1 Like
The challenge is zibs are data exchange models. So every implementer would have to support processing a received zib to fit the archetype. So every implementer would have to build the logic to transform 71 to 7,1. Currently with 2-3 vendors that’s manageable. But I’m not sure it’s desirable from a safety perspective. Especially since the zib is usually already transformed by another vendor with a (non openehr) datamodel.
Unifying for graphing is interesting but also has its risks. The data is probably not comparable enough to present as first order data with the care organisations own data.
A lot of their ckm references are way outdated. I’m sad to think they lost interest in openEHR some time ago. (And even sadder they don’t just use the openEHR stuff)
We’re looking for concrete examples of where 0-100 (or other ranges) are used. Can you help us? 
Okay, reading the British Pain Society document, I can find the numerical representation of VAS (p 9), where the distance between the “no pain” end of the line and the patient’s mark is measured in mm, leading to a total of 100 mm. Do we have any others?
I see 0-20 referenced a lot regarding NRS (although not in this document), but I haven’t found any actual examples of use.
Regarding the combined use of Symptom/sign and Symptom/sign screening questionnaire could it be a good idea to encourage reusing exactly the same content (use the same text or coded text) in the symptom name fields when the two archetypes are used together? (See images below.)
If so an AQL query for any of those fields in an EHR would give a hit. In a GUI/form the good thing to do would then be to hide one of the fields from the user and automatically “under the hood” fill it with a copy of the content from the other.
Perhaps such advice is best placed as a comment in the Symptom/sign screening questionnaire archetype (by the “Symptom or sign name” field).
and
1 Like
Definitely. Could you add change requests about this?
Would this work?
(Edit: Disregard the comment, it needs an update after the addition of the 1-100 mm unit)
That’s cunning!! Yup it would work for the Zibs example. TBH I’m not all that bothered about proportion for now - if someone does come up with a 0 … 95.6 range then it can be added later!!
2 Likes
The trouble is if someone tries to use the 0…100 mm Quantity, which is intended for a 100 mm visual analog scale, for a 0…20 numerical rating scale. I’ve read about the 0…20 NRS in several places, but I haven’t seen an actual use case presented.
1 Like
The element description reads “numeric rating scale”.
The zib has 3 potential valuesets for the equivalent element
0-10 (integers I assume) NRS
0-10 (cm I assume) VAS
0-100 (mm I assume) VAS
So the concepts don’t match currently. I’m also unsure about the effect of having 0-10 without units and 0-100 with mm units. What are your thoughts here?
I’m leaning towards making the element unconstrained. And make specialised archetypes/templates for pain score.
That would indeed break computability across observations. But I think the concept of symptom severity is currently too broad to allow for that anyways. But maybe I’m missing the usefulness of that computability?
My idea was to allow the 0-10 without units for “normal” NRS recording, but on second thought I guess that would be better as a DV_COUNT. I’d be happy to make it a choice of
- DV_COUNT 0…10 (for NRS)
- DV_QUANTITY 0.0…10.0 cm and 0…100 mm (for VAS)
- DV_PROPORTION (unconstrained) for any other NRS scales, such as 0…20 or 42…111 or whatever.
1 Like