I checked and I was wrong. the Description attribute on a term is mandatory.
ordering for some, but not all and not always sequential or unique
We have that now with DV_ORDINAL and the same will apply to DV_SCALE
So we are left with 2 issues, I think.
Mandatory descriptions- I suspect will not be possible to make descriptions optional for ordinal terms but mandatory for others. Is there an appetite for making Description optional - in a sense we already do that by adding a dummy ââ . We could then use tooling to add 'â as it does now to most terms but not in the context of Ordinals/scales. That makes me a little bit uncomfortable but only a little!!
Not having numerics associated with every item in the ordinal/scale. I know there are use cases but they make me really uneasy. If there is no numeric, what is supposed to be used for e.g âinfiniteâ, or what is the point of the numeric? I think I would prefer to separate any text/coded_text options as perhaps a choice against the Ordinal. Do you have any examples that we can chew over?
Correction - Description is only mandatory in AOM/ADL2 - do we think that should be relaxed? I would probably vote yes and leave it to good practice/tooling to âhelp usâ to add Descriptions in most cases!!
Iâm no longer absolutely sure exactly which âdescriptionâ we are talking about. But agree in principle that they shouldnât be mandatory and good modelling will result in descriptions where it is appropriate.
I think descriptions for DV_CODED_TEXT and maybe even the main text for DV_ORDINAL/DV_SCALE value set items should be optional, but for data elements they should be mandatory. We often have scores/scales with no descriptions for value set items, and sometimes just a numerical value with no text at all.
Descriptions wherever possible is good modelling policy, in fact the semantics are often very unclear/unsafe without them. However mandation of descriptions implies you canât save an archetype without a description - not going to happenâŚ
So just to be clear what we are talking about - here is an example from an older version of the Frailty archetype where the description was plit between Descripton and comment.
["at0005"] = <
text = <"Very Fit">
description = <"People who are robust, energetic and motivated. These people commonly exercise regularly.">
comment = <"They are among the fittest for their age.">
>
The text is carried through into patient data, along with the associated code and value (for an ordinal). It is always mandatory.
description and comment are only carried in the archetype and are useful in tooling and sometimes helpful in UI generation but do not end up in the patient data.
An AOM 1.4 they are optional, in fact are not formally defined, but the ADL1.4 document implies that description is mandatory.
I sense consensus that description and comment should be optional but âencouragedâ - other than perhaps in Ordinals? Iâm not sure if that can be enforced in the specs but there is no reason why it could not just be implemented in tooling e.g when a dv_ordinal valuuset is created the usual dummy description is left blank.
Do we have some consensus here?
Make description optional?
What about optional numeric values in DV_SCALE ? I would say no
What about optionalâ textâ as per the BORG examples above - again I would say no.
I agree. We use the descriptionas tooltip in the UI. To let the user read more carefully why to choose the specific item. Description might be overriden by the application/UI to give more specific description in the specific use-case.
We also see use-cases where the users asks for overriding og the text attribute. This kind of makes sense to be more specific about the intention in the use-case. The problem is that this is also stored in the data. This is why we, so far, didnât implement such a feature.
I donât agree. I think the archetype modelling is great since we have this great possibility to put more information to the end-user about the archetype terms. The comment field should be used to contain information for the archetype modellers, but the description should be written in a way that might be read by the end user.
Currently on Better we show by default the âdescriptionâ from the archetype as a tool-tip to the user on the front end and in many cases itâs very useful. It can be overwritten by other text to be shown on frontend, but this does not go to ehr server when creating a composition.
On the commentâs section of the archetype, I only see it on modelling tools and I agree with @bna that this should be considered as an advice content to the modeller and not shown by default to the end user.
To try and sum up the discussion from my own understanding:
All value set items, whether in DV_ORDINAL/DV_SCALE or DV_CODED_TEXT data types, should have the possibility of adding text, description and comment text fields to them.
text should be mandatory for DV_CODED_TEXT, but optional (though strongly recommended) for DV_ORDINAL/DV_SCALE. The reason why it should be optional for the latter two is to accommodate scales like Borg Scale, which has some items with a numerical value but no text.
description should always be optional. A lot of scales only have a short text label for each item, and no description. The alternative is to leave the description empty, which makes less sense.
comment should always be optional, and would probably only be used where the value set items contain examples.
This is the only one that makes me uncomfortable., otherwise agree. I think I would prefer to fill the gaps, where it makes sense or model as DV_COUNT where as in one of the scales it is only 0 and 10 that have text labels. I know we want to replicate the scales as they were designed as far as possible but very often they do not take account of transfer to IT systems, or the data being visualised outside the context of the full form.
I can empathise with the unease, but I donât see how we can reasonably fill the gaps. For example for the Borg CR10 scale, which text would you assign to the numeric value â8â? âMore severe than âvery severeâ, but less severe than âvery, very severe (almost maximal)ââ?
Modelling things like the pain intensity scale of the PROMIS-29 as a DV_COUNT would IMO lead to loss of even more context.
For me this is a âjunk scoreâ it is a typical VAS that happens to have the normal guidance '0 means no pain vs. 10 = the worst you can imagine. It is not a scale at all in my book and there is nothing in here that is PROMIS-29 specific.
