Ordinal values without descriptions

Hi everyone,

We’re working on an archetype for the Montgomery-Åsberg Depression Rating Scale (MADRS). This scale contains several ordinal values where there is no description, and some where there is no text at all. This doesn’t work very well in archetypes, and particularly when uploading to a CKM, because there’s an expectation that every field should be filled in, and the CKM will replace empty fields with * or sometimes *([language code]). Is there any way to get around this?

See here for what the MADRS looks like: http://www.psy-world.com/madrs.htm

Kind regards,
Silje Ljosland Bakke

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
National ICT Norway

Tel. +47 40203298

Web: http://arketyper.no / Twitter: @arketyper_no

Hi Silje,

If I read http://www.openehr.org/releases/RM/Release-1.0.3/docs/data_types/data_types.html#_dv_ordinal_class correctly, it seems to imply that the minimum you do is to give the text the same value as the ordinal value: “…which may be strings made from + symbols, or other enumerations of terms such as mild , moderate , severe , or even the same number series as the values, e.g. 1 , 2 , 3”

I personally think this is reasonable for cases like yours for the ‘text’

Where it gets trickier is the corresponding ‘description’.

While it seems to be the common convention that there is some sort of a description for each term in the ontology, but I don’t think it is a requirement from the specs (is it?)

In cases like yours it seems reasonable to me to not have a description at all.

Currently, in CKM I believe you can only upload it with an empty description, but not completely without it.

If you have an empty description this would be displayed in square brackets without any content, which is technically correct, but a bit awkward:

I am not aware that CKM is adding * with or without a language code on a simple upload.

But when you start translating an archetype inside CKM, it would add this as a marker to all non-translated bits and pieces once you save.

Here it may be reasonable to assume that if something is empty in the original language that then the translation doesn’t need to be filled either and therefore CKM should not add the *(en) marker to it.

For CKM, I would suggest:

  1. Enable ARCHETYPE_TERMs completely without a description.

  2. Finetune the translation functionality in CKM to not add a *(en) marker or similar in the translation, if it is empty in the original language as well.

(but avoid empty texts in archetype terms, using the ordinal value as a minimum)

Regards

Sebastian

If you give someone a ‘3’ on the Apparent Sadness scale, what does it mean? Apparently it’s between ‘Looks dispirited but does brighten up without difficulty’ and ‘Appears sad and unhappy most of the time’…

So now imagine that this ‘3’ appears for me in my record - just that value. The scale doesn’t tell you what it means. It probably should have a value like ‘Appears sad quite often’ or similar. Instead, I would see nothing at all, and maybe I would know to go online and try to understand what 3 means by looking at the values for 2 and 4. Even in a paper record, the problem is the same.

At a technical level, the RM will does require a DV_CODED_TEXT. So one question is: considering that the set of texts for an ordinal is actually a set of terms, what does the term set look like? It must be value set with only 4 members instead of 7.

Personally I think that scale is not ready for use in paper or electronic health record…

  • thomas

Technically speaking it is in fact possible to create an alternative
of two different data types in a given attribute (say for example in
your use case, DV_ORDINAL (1,low) , DV_COUNT (2), DV_ORDINAL
(3,medium), DV_COUNT (4), DV_ORDINAL (5,high)).
In any case I agree with Thomas that this scale probably isn't ready
to be used yet in a EHR

I will not discuss about the readiness of that particular scale. But un general words, we are very accustomed to scales where you have to answer “From 1 to 10, score your satisfaction with the service provided, with 1 meaning ‘not satisfied at all’ and 10 meaning ‘completely satisfied’”. I guess that these kind of scales could also be used for recording some information in the EHR. In that case, the problem is that the DV_ORDINAL is not designed for those cases, but to assign a comparable value to descriptive texts. Maybe in your case, it is not a DV_ORDINAL but a Integer what you need to represent, and the texts are just hints about the sense of the score.

I would tend to agree with the suggestion to model this as a DV_COUNT rather than a DV_ORDINAL.

Ian

I think that is probably the best interpretation of this particular scale - a number from 1-10 (or a percentage), with an associated partial code set...

- thomas

Following Thomas, I think for the missing descriptions you might need to put “between x and y” if x and y are available descriptions.

Thanks for your replies everyone! As the scale does have descriptions for scores of 0,2, 4 and 6, I don’t think representing this as only a count would work. Perhaps Pablo’s suggestion is the best, even though it does mean changing the wording of the scale (arguably for the better).

Regards,
Silje