Dear All,
being from the Swedish SNOMED CT NRC we need to advice our users on how to represent the notion of “other” in coded value sets (mainly because wo do not want to add “other” SNOMED concepts due to semantic volatility etc). I find that openEHR have null_flavor on the ELEMENT level, but there will still be a need to provide e.g. a DV_CODED_TEXT.value even though there is no DV_CODED_TEXT.defining_code. Further, the null flavors available seem to me not to meet the needs of this not too uncommon use case. I’ve likely just missed some important piece of documentation, and will be happy to be adviced on the best openEHR representation of this use case.
Thanks,
Daniel
1 Like
Off the top of my head, “other” usually means “something other than this list, and you can write the exact thing here in this free text field”, or “something other than this list, and we don’t really care which other thing”. In the former case, you store whatever they put in the free text field, and in the latter you store null_flavour “unknown”. I’m not sure why this doesn’t work?
Well don’t forget that the purpose of that (as in HL7) is to indicate that a required data item is not supplied in the data set, for some exceptional reason. It doesn’t perform the function of recording a data item that you would like to code, but can’t find a code for - such a data item is not absent, it’s just not coded, so maybe you just see a DV_TEXT in the data.
Now, dealing with that latter problem is the subject of a long discussions (in fact many over the years, as you know!). The latest version is in the SEC discussions, so you can’t see it, but in summary, we decided to:
- introduce the FHIR-flavoured ‘strength’ idea to
C_TERMINOLOGY_CODEin AOM2. This would enable local value-sets to be classified asrequired | preferred | extensible | example, as in FHIR. - Only
requiredwould be regarded as a true AOM constraint; the rest are just flavours of preferred usage.
This allows the runtime user to introduce codes not in the archetype or template, as long as strength != required. However, when there is no code at all, i.e. you might have to enter text, then you need to have left DV_TEXT open as a possibility in the archetype, which is pretty common.
We are also discussing a further addition to the reference model, which is to add a DV_PLAIN_TEXT child to DV_TEXT. This would address cases where you want to force a text-only (non-coded) response, if no code is available. I don’t 100% understand this use case, but @ian.mcnicoll can explain better.
Hopefully you can visualise the above changes, because we don’t yet have them in UML or the docs!
Here, “unknown” is not right, because it is not unknown, not just on the current list.
1 Like
FHIR does not have a generic notion of null flavors, but there is a recommendation (personally from LM, don’t have any specs to refer to) to add codes from the v3 null flavors to the ValueSet at hand. ISO 21090 has null flavors, particularly OTH, but at the data type level, i.e. a level or so below the ELEMENT level. Don’t know if that is relevant.
There is a separate (and important) question about how to constrain data to allow or not allow exceptions, but that was not my question right now, sorry for being unclear.
Just to make the use case more clear, think of a (mandatory) data entry field for conditions with a value set which contains 10 (or 10 000) things. Every once in a while (depending on the setting where this is used) there will be a patient with condition 11 (or 10 001) (e.g. think of COVID-19 in January) for which there is no code in the given value set. In an archetype to represent this information there would be a DV_CODED_TEXT, how would “condition 11” be represented if there is a requirement to distinguish this case from other reasons for not providing a code?
Thanks,
Daniel
Well if we assume the proposal I described above, then you would be able to set an indicator on any C_TERMINOLOGY_CODE constraint (which is what applies to DV_CODED_TEXT.defining_code) to say extensible, meaning: use one of the codes here if it applies, but you can add your own codes as well.
Now, if you don’t have a code, you are in the position of choosing between a coded term and just entering text. To do that (a common situation in archetypes), you need to have the DV_CODED_TEXT and DV_TEXT constraints both on the data point in question.
1 Like
Classifications like ICD often include such kind of “catch-all” codes as NEC(not elsewhere classified) codes. Terminologies/Ontologies, such as SNOMED CT, don’t like these concepts which meanings are not persistent depending on the other sibling codes.
You will never get a snomed ct code for such a concept.
Maybe it’s a open-vs-closed world issue.
Related Links:
When Is Content Rejected?
https://confluence.ihtsdotools.org/pages/viewpage.action?pageId=71172163
Comparison between a SNOMED CT Problem List and the ICD-10-CM/PCS HIPAA Code Sets
http://library.ahima.org/doc?oid=301254#.XrXwBda-sTk
2 Likes
Whether it’s ontologically/terminologically reasonable, such “catch-all” codes are common. So it would need an explicit solution.
1 Like
It may not be unknown for the person recording the data, but in effect it would be unknown for the record? Or is it necessary to record that it’s not in the provided list? If so, could that be a possible new null_flavour?
This still wouldn’t be a null flavour. If you have a data value, it’s not null, even if you’ve only got text, or a rough numerical estimate instead of a proper value or whatever. Null flavour is for when you have on value at all.
I may have expressed myself badly. What I meant was something like this:
Question:
- Option 1
- Option 2
- Option 3
- Other
In this case, ‘Other’ means something like “Not option 1, 2 or 3, but otherwise unknown”. So the “value” in ‘Other’ would be the fact that it’s none of the other options? To me this feels like a sort of limbo state between null and an actual value?
Agree it is not a null flavor on the ELEMENT level, possibly a “null flavor” on e.g. a DATA_VALUE.value or DV_CODED_TEXT.defining_code. There is a generic notion of the scale and/or data type being insufficient for representing what the reporter wants to express, and this could be lack of an element in a ordinal or nominal scale list, i.e. lack of a code in a value set, or that interval or ratio scale lacks the necessary precision (likely less common) or that a value is outside of the boundary.
Right but if that ‘other’ is the true state of the clinician’s knowledge of the response, then that’s not a lack of data, it’s a value that correctly represents the current understanding.
Example: at the point in time when ‘non-A non-B hepatitis’ was recorded for hepatitis that wasn’t one of the two known types, that was the medically correct answer.
Null flavours are for situations like when a machine is malfunctioning and can’t supply any value to its user e.g. battery runs out in a thermometer and you just can’t take a temperature, or patient is unconscious and can’t tell you anything about his/her allergies or meds.
Well I see this as a bit different (maybe it’s what @siljelb really meant) - if the provided choices are less representative than the true state of knowledge of the HCP, then possibly we do have a new kind of ‘absent value’. This could happen when the technical means of providing values - UI forms, pick-lists etc, are simply missing possibilities that exist in real life. Maybe they have an ‘other’ item, but no box to record ‘details’, or the choices are simply too restrictive. So if I understand correctly, you are saying you would like a way to record ‘value unavailable’. However, it seems to me that if the technical means of input has been built to prevent any proper recording of ‘other’ values, it will also probably not allow you to record the lack of that means of input - i.e. it’s a UI design problem.
Does this more closely describe the situation?
1 Like
Non-A non-B hepatitis is a slightly (but not completely) different case. If in the 80ies only A and B were available in a paper check sheet, the reporter would tick the “other” box. That what was later to become (mostly) hepatitis C was initially called “Non-A non-B hepatitis” (and non-ABC --> D) might be more of a naming issue (the researchers knew they had found a new kind of virus), but highlights in a clear example that healthcare and medicine is constantly evolving. My initial question was not really a semantic one (negation semantics is tricky…), but a technical one.
yes, this is the case I was trying to describe, but not necessarily in relation to any UI. In any constrained list of alternative values, for whatever reasons (novel cases, overly constrained value set, … things happen) the alternatives might not always be sufficient. Some of these issue can be addressed by amending the archetype or the code system, some might not be worth the effort to address, some might need research to evolve, etc. etc. but at any given point in time, there can be a need to say “I could not express what I wanted to say under the current constraints”.
That’s a good summary Thomas but there are 2 quite different scenarios. I agree that other is not really a null flavour’, it is saying that I can answer the question affirmatively buth at the answer I want to give is not in the list you have provided
Hepatitis is a good example
-
Operational. It is usually unhelpful to just record ‘other’ as a codedText and as Silje said earlier, other in this case is usually accompanied by a text box that allows other coded_text or free text to carry the actual response. In this case, ‘other’ can be regarded as a navigational directive and is never actually carried in the data. It is unusual to have ‘other’ coded as an actual response in operational clinical data but it can happen. As an example, I am working with a dataset to be used by paramedics in assessing possible COVID-19 risks and there are a couple of places where ‘Other’ (without further clarification) might be acceptable as-is because these folks are working quickly, with limited information and possibly without the clinical experience to capture more detail authoritatively.
-
Analytics, registries, research. In this situation, the use of ‘other’ as an acceptable final response is common. In this context specific knowledge of what the ‘other’ was, is not of any direct interest to the recipient.
It is the old classification vs. terminology discussion. I agree that we should not be adding ‘other’ to SNOMED CT hierarchies, both in principle, but also because ‘other;’ is purely contextual to the actual alternative responses in the UI.
Why not use 74964007 | Other (qualifier value) | and accept that the true meaning of this can only be inferred from the context of the question and alternative possible responses?
1 Like
I would have thought the standard modelling approach would be to do what you already do - keep the DV_TEXT (or, in future? DV_PLAIN_TEXT) around for precisely the situation where the coded choices are lacking? Or is the problem guessing when this is likely to happen?
That is much like the FHIR solution, but where a code from another code system is used to indicate even stronger that no one should even think of trying infer any meaning from the position in SNOMED CT.
It might be, and often is, helpful to address areas where the value set should be expanded, although the value “other” itself is not clinically useful.