Normative Answer List LL4734-1
Source: American Heart Association
Answer________Code________Answer ID
Class I________I________ LA28404-4
Class II________II________ LA28405-1
Class III________ III________LA28406-9
Class IV________IV________ LA28407-7
Source: American Heart Association
Answer________Code________Answer ID
No objective evidence of cardiovascular disease________A________LA28408-5
Objective evidence of minimal cardiovascular disease________B________LA28409-3
Objective evidence of moderately severe cardiovascular disease________C________LA28410-1
Objective evidence of severe cardiovascular disease________D________LA28411-9
Interesting. the LOINC definition of ordinal therefore goes beyond a coded_text ‘symbol’ plus related numeric ‘value’ in openEHR to allow other string-based ‘values’ . I am not sure I trust that approach or see the particular added value.
Our problem comes exactly because we are forced to squeeze the scores and scales into Text and Ordinal data types. While it is possible to use either data type for most scores/scales, there are always outliers.
Ordinal is not truly intended to support scoring, but rather ordering.
So when we get scoring that is sequential or unique whole numbers it works fine. But if we get duplicates we had trouble, at least until recently. And if we have scores that have 2, 2.5 and 3 we have no possible solution except to try to represent the numerical scores associated with each value/selection.
Ultimately we need a technical datatype solution that separates out the score from the ordering, so that developers know when the score is applicable for the archetype - at the moment it can be derived from the hierarchy of a DV_ORDINAL or in the name or description of a CODED_TEXT.
There is no consistency because it is not possible to be consistent when we are often forced to adapt data types for purposes they are not intended for.
We need a data type that allows:
data element names for all
descriptions for some, but not all
ordering for some, but not all and not always sequential or unique
scores associated with some, but not all
It is not just about modelling patterns…
That is coming - new datatype called DV_SCALE basically identical to DV_ORDINAL but allows real numbers as well as integers . There was no simple way of extending/adapting DV_ORDINAL without causing breaking changes, so the decision was that very largely, DV_SCALE would be used for new archetypes, leaving DV_ORDINAL as deprecated unless tere is some IMO very weird) requirement that the numeric be an integer.
Do you mean within a specific scale? some coded_texts have numbers , some don’t?
I don’t think there is anything in the RM/AOM which forces us to have descriptions - just custom and practice/ tooling behaviour.
From an UI perspective it doesn’t really matter if we use DV_CODED_TEXT or DV_ORDINAL. It matters though if we have to share the data with some obscure messaging format. They typically tend to use the number shown on screen. It saves a few keystrokes if we use an ordinal then.
If the score is a continum or not integers it still doesn’t matter (IMHO) - but the preferred solution would be to wait for the new DV_SCALE. We’ve implemented it in our software (backend/libraries), but I assume it takes some time before the tooling chain is ready for it.
It is coming? How advanced is this discussion? As clinical modellers it would be good to know, so that we can confirm it meets all our modelling requirement before it becomes part of specifications…
The original trigger for this discussion was a question about whether we should use DV_ORDINAL or DV_CODED_TEXT for the Clinical Frailty Scale archetype, which is about to be published. This was originally modelled using DV_ORDINAL, but feedback from reviewers that the combination of the numeral and the description text string was confusing (see image below), led us to change it into a DV_CODED_TEXT. In retrospect, this is really a problem with the visualisation in the CKM and not really with the model as such.
I think this visualisation would be more useful if it was modified so that it’s clearer that the numeral (the bit before the colon) and the text description are two separate things.
If we got that fixed, a good modelling guidance could be something like “If a scale is displayed as a numbered list, use DV_ORDINAL”?
DV_SCALE is identical to DV_ORDINAL other than allowing real numbers rather than just integers. The only reason it exists is that it would have been too disruptive to try to change DV_ORDINAL whicj would have been a breaking change in the RM.
As for current DV_ORDINAL the unique number rules is relaxed. Are there any other changes needed? I think I’d be pretty reluctant to relax the requirement for the numeric value to be mandatory or allow things like ‘infinity’ (one of the Berg scales).
“If a scale is displayed as a numbered list, use DV_ORDINAL”? would still work but I’d be saying in future “If a scale is displayed as a numbered list, use DV_SCALE”? which is just that little bit more flexible.
Although TBH I 'm not too bothered by the visualisation. It is really an artefact of the original score author putting the numeric in the text and requiring people to stick to the text but here is an example where that is not the case an NHS sponsored app). So I think there is an argument that where the numeric is carried in the text, and we also carry it in the ordinal value, that we can relax the requirement to also carry it in the text - I don;t think we are subverting the spirit of what wa intended or the clinical safety.
We have had to make many other ‘tweaks’ to be published scales, because quite simply they cannot be implemented otherwise.
So on balance I think we should be more relaxed about rigidly including the numeric in the text idf this is (in our world) quite reasonably split into a separate field which can be easily reconstituted in a UI, if that seems appropriate. If needs be offer guidance in the metadata.
The way it is displayed in the CKM is confusing. Modellers will know, but a lot of our reviewers doesn’t understand why the numbers are displayed twice. Any help here in the CKM will help. I prefer [1] 1. Very fit… Or something brilliant that @sebastian.garde can come up with?
I’m arguing that there is no need for us to include the numerics in the text (as it is in the original) as we are faithfully capturing that, albeit in a slightly modified way. This is the price of turning a paper artefact into something computable. Of course, we should not mangle meaning or compromise safety but, I would defend dropping the numeric from the text, in that regard.
I’ve reread the terms of use, and I can’t find the phrase about faithful reproduction of the text that I thought I’d seen before. So maybe this is okay, from a representation POV. Would removing the numbers from the description impact ease of implementation for you, @bna?
The numbers doesn’t really matter from a technical viewpoint. We have features to add the number from the code to the user if that’s needed/wanted. Depends on the use case.
My personal view is to remove the number in description since it is a duplicate and possible error cause if the number/ordinal where to be changed.
Great! Then I suggest the following modelling guideline: “If a scale is displayed as a numbered list, use DV_ORDINAL [to be changed to DV_SCALE once this is available in major tools]. Do not replicate numbers in the description.”
1 Like
siljelb
(Silje Ljosland Bakke)
Split this topic
26
Hi @siljelb,
Sorry for the late reply, I have been quite busy lately.
From my perspective and usage from the both classes you mentioned I prefer to use the DV_ORDINAL for scales instead of DV_CODED_TEXT/DV_TEXT. The current tools I use allows to make immediate calculations of total scores if using ordinal for each element, plus the option the show or hide the ordinal number on the front end. Otherwise if using the coded_text/text it takes an additional parsing and I don’t believe to be that user/developer friendly in the final. I also try to avoid as much to have the case you mention with “1:1. Very fit” from the ordinal+ (number)description, it’s redundant in my opinion. Maybe only ordinal+description “1: Very fit” would be enough.
