Stream: terminology
Topic: Expressing Uncertain as a codableConcept
Linn Brandt (Mar 22 2021 at 14:05):
We're building profiles to support reporting to a clinical health registry (colonoscopy). In some cases there are questions where the range of allowed answers is a valueSet that includes "None", "Other", "Unknown" and "Not applicable", where we use the HL/ code systems list-empty-reason (nilknown), nullFlavor (OTH) and data-absent-reason (unknown and not-applicable) . But then we some value sets where we need the option of "Uncertain". Which I can find nowhere in any of these or related code systems. It feels like it should be there, as it is related, but I cannot find it.
My question is: Does it exist, and I just cannot find it? Or do I need to use another, local (self-invented) code system? Anyone encountered this issue and solved it elegantly without having to use a local (self-invented) code?
[example of such a Question: "Is the lesion endoscopically complete removed": Yes, No, Uncertain]
Lin Zhang (Mar 22 2021 at 14:21):
Missing codes is a quite common issue. A locally inclusive vocabulary might mitigate it.
Linn Brandt (Mar 22 2021 at 21:07):
Lin Zhang said:
Missing codes is a quite common issue. A locally inclusive vocabulary might mitigate it.
Yes, there are of course a lot of codes we have to use from local code systems. But in the case of "Uncertain", it just feels like it should have been there, since all these other related ones: no, other, unknown, n/a exist. But, if it's not there, we'll use a local code.
Robert McClure (Mar 23 2021 at 22:30):
How about ActUncertainty or StatisticCertaintyRating
Linn Brandt (Mar 24 2021 at 16:02):
Robert McClure said:
How about ActUncertainty or StatisticCertaintyRating
Thanks for the tips, much appriciated:
- ActUncertainty [stated with uncertainty] doesn't seem right, as there are no value that is recorded that the clinician is uncertain about. It a more general "I'm uncertain what to record"
- StatisticCertaintyRating isn't right either as that is about certainty of statistical values (EBMonFHIR), categories of how certain you are that the statistics reflect the true values in the population (or thing) you are looking at.
Lin Zhang (Mar 24 2021 at 16:25):
Some LOINC answer list(s) might include a code for 'Uncertain'. But it's just a guess.
Lin Zhang (Mar 24 2021 at 16:30):
For example, Normative LOINC Answer List LL4540-2
https://loinc.org/LL4540-2
Lin Zhang (Mar 24 2021 at 16:34):
And SNOMED CT might be another potential source terminology.
Lin Zhang (Mar 24 2021 at 16:37):
For example, SNOMED CT 64957009 |Uncertain (qualifier value)|
Lin Zhang (Mar 24 2021 at 16:38):
https://browser.ihtsdotools.org
Lin Zhang (Mar 24 2021 at 17:02):
Or, even you can also create a ValueSet using codes from more than one CodeSystem.
Robert McClure (Mar 24 2021 at 18:41):
DO not use LOINC answer values independent of LOINC observations and even then be careful. If you are just looking for coded concepts that fit the bill and have universal access, have you looked in SNOMED if it's open for use in your jurisiction?
Linn Brandt (Mar 25 2021 at 15:18):
Robert McClure said:
DO not use LOINC answer values independent of LOINC observations and even then be careful. If you are just looking for coded concepts that fit the bill and have universal access, have you looked in SNOMED if it's open for use in your jurisiction?
In SNOMED there is a qualifier value concept , under "Qualifier for certainty of diagnosis (qualifier value)" and "General adjectival modifier (qualifier value)" that lexically fits [Uncertain (qualifier value) 64957009], although the uncertainty is not just about diagnosis. But we're not building expressions (where qualifiers would be useful). We use SNOMED for clinical concepts only, not as a just words. To me, it would fit much better together with the other HL7 code systems where we find: "None", "Other", "Unknown" and "Not applicable" (systems list-empty-reason, nullFlavor or data-absent-reason. I could probably suggest Uncertain as an extention/addition to one of those. I'll see who to contact about that
Robert McClure (Mar 25 2021 at 18:40):
The only place I know this sort of need was discussed and addressed was for allergy intolerance. See AllergyIntoleranceCertainty That is obviously specific to allergy but perhaps this needs to be generalized? Perhaps you can talk to Patient Care about that?
Lin Zhang (Mar 25 2021 at 23:51):
Need an ability to discover ValueSet(s) by searching the content.
Linn Brandt (Mar 26 2021 at 09:55):
Robert McClure said:
The only place I know this sort of need was discussed and addressed was for allergy intolerance. See AllergyIntoleranceCertainty That is obviously specific to allergy but perhaps this needs to be generalized? Perhaps you can talk to Patient Care about that?
Thank you. I was thinking I would ask HL7 terminology authority. I'm just waiting for my Jira access. I'll write the result of my quest for uncertainty once I get somewhere:)
Lloyd McKenzie (Mar 26 2021 at 13:19):
I expedited your request. You should be good to go.
Robert McClure (Mar 26 2021 at 20:43):
The HTA is only focused on external terminology issues so they are not going to help you with this. I'd go to Patient Care, which was involved with the allergy work, and see if they can help generalize the allergy-specific value set/ code system created. @Russell Leftwich
Russell Leftwich (Mar 26 2021 at 23:07):
I recall preliminary discussions and discussions in openEHR about the certainty issue around allergy. I had not reviewed the value set referenced in AllergyIntoeranceCertainty. There appears to be some ambiguity and to me a poorly constructed value set. Likely and unlikely is a clinical judgement which could overlap considerably between observers. And the observer is often the patient. The existence of testing for pharmaceuticals, biologics is vanishingly rare. Less than 1% of substances. Rechallenge is the gold standard, but rarely undertaken except by accident. The definition of AllergyIntoleranceCertainty does not align with the definitions of the values in the value set. The former refers to "the manifestation in a reaction", the latter to the reaction. This also does not align well with VerificationStatus in the AllergyIntolerance Resource.
Linn Brandt (Apr 06 2021 at 09:44):
@Russell Leftwich and @Robert McClure Any suggestion on who to contact in the Patient care WG? I see very little about terminology/vocabulary on their pages, https://www.hl7.org/Special/committees/patientcare/overview.cfm, but there is a "Facilitator - Vocabulary": Susan Matney, listed there.
Lloyd McKenzie (Apr 06 2021 at 16:26):
Simplest is to submit a change request against the resource - it will then be discussed by the full work group.
Rob Hausam (Apr 06 2021 at 17:03):
I'll ping @Michelle (Moseman) Miller, and we can consider having further discussion on a Patient Care WG FHIR (Thursday) call? I think we'll want to be careful about where we might go with this.
Russell Leftwich (Apr 06 2021 at 18:34):
I think @Lloyd McKenzie suggestion of entering a change request is best approach. There is a 90% override rate for drug-allergy alerts which would suggest to me that there is room for improvement in the way the resource exists. I think uncertainty is not the only issue, but it is an issue.
Rob Hausam (Apr 06 2021 at 19:11):
Agree a change request will be needed.
Linn Brandt (Apr 07 2021 at 15:47):
My original suggestion was to expand the HL/ code system nullFlavor (that has the value OTH-Other) OR data-absent-reason (that has the values unknown and not-applicable) to add in the value of "Uncertain." That way we could use it in a range of different value sets. Is that in the lines of your thinking? [Link to the issue I placed with HTA (as we talked about earlier in this thread, this was maybe not the right place to add the request: https://jira.hl7.org/browse/HTA-38]
Rob Hausam (Apr 07 2021 at 19:16):
I'll just say that I'm a bit uncertain about adding a code for 'Uncertain' across the board. :) It certainly warrants some discussion to determine if that, or something else, is the way we want to address this need (certainly acknowledging that the need to deal with uncertainty is very real).
Linn Brandt (Apr 12 2021 at 09:08):
Rob Hausam said:
I'll just say that I'm a bit uncertain about adding a code for 'Uncertain' across the board. :) It certainly warrants some discussion to determine if that, or something else, is the way we want to address this need (certainly acknowledging that the need to deal with uncertainty is very real).
How is a general "Uncertain" different from a general "Unknown" og general "Other"?
Linn Brandt (Apr 29 2021 at 21:01):
Thank you @Rob Hausam @Robert McClure @Ted Klein for the discussion today.
My arguments for including Uncertain into NullFlavor is that:
a) although you would usually have some data, it is not enough to appropriatley make a choice of the other available values presented in the value set. So it's not null data, but it is a flavor of Null, which is "not enough".
b) There are other values on the list that is not strictly No data: TRC -trace [The content is greater than zero, but too small to be quantified.] and SQ-Sufficient Quantity
c) Seeing as I was confused by the different code systems with overlapping values, I would be reluctant to create a new code system with "nullFlavor-related-stuff", just for the sake of keeping nullFlavor clean of things with absolutely no data (except from the 2 examples in b). Making the code systems user friendly and easy to find could be a part of the general harmonization. Less likehood of someone choosing the wrong option or making their own stuff because they cannot find what they are looking for.
d) Uncertain, although not as common as Unknown, is a pretty common value in registry value sets. And registry data capture, transfer and harmoniszation is a superb use case for FHIR (in my view at least). And so, not having it in any of the HL7 code systems, makes implementers create their own local value - which doesn't help interoperability or standardization.
[e) To throw in another suggestion: To unify, maybe nil-known should also be in the NullFlavor list?]
Suggestion for definition:
UNCERT - Uncertain: There is some data, but not enough to appropriately make a choice of the other available values presented in the value set. It should not be used in the cases where data is unknown, or the actual value is not a member of the set of permitted data values in which UNK or OTH should be used.
Rob Hausam (Apr 29 2021 at 21:15):
I can certainly see those arguments - but I think that there might (and I am uncertain about this) be a better way and a better place to do it. I also would like to know if this use of terminology is related to any use of an HL7 information model (e.g., FHIR or CDA), or if it's entirely independent of any particular information model standard (e.g. HL7, openEHR, etc.). And, if we do this (or something similar), I would also like to give further consideration as to whether it should be based on the v3 NullFlavor code system/value set or the FHIR data-absent-reason (with the addition of 'uncertain', and any other concepts that are deemed to be "missing", to either of them). I don't think the deciding factor for choosing which one should be only or primarily whether the NullFlavor code system at the present time has more of the needed concepts (for Linn's use case) than data-absent-reason does. And, finally, I think there still could be some consideration of whether SNOMED CT is or could be appropriate (even though they have tended to want to stay mostly away from this space in the past).
Linn Brandt (Apr 29 2021 at 22:12):
We would use it in FHIR profiling. Since some of the vendors that will be exporting data using these FHIR profiles are based on openEHR, I raised the issue with them, and it turns out they have had the discussion of (and how to) using the NullFlavor code system and the issue of uncertain (see links above). Which for us, where hospitals covering 85% of the population are using an openEHR based EHR, is quite important for standarization.
Rob Hausam (Apr 29 2021 at 22:49):
Is there a way to look at any of the openEHR-related discussion on this?
Linn Brandt (Apr 29 2021 at 22:52):
yes, I posted the link and included it in the email I sent you: "We have several EHRs that use openEHR, and I’ve been following their discussion around this topic too, as it is similar and also revolves around the use of HL7 code systems: https://openehr.atlassian.net/wiki/spaces/spec/pages/4915211/Null+Flavours+and+Boolean+data+in+openEHR and https://discourse.openehr.org/t/uncertain-unknown-and-no-information/1473/3"
Rob Hausam (Apr 29 2021 at 22:53):
Thanks. I'll look at it.
Jay Lyle (Apr 30 2021 at 12:52):
Is this a Jira yet?
Whether "uncertain" is a null flavor or an assertion of a confidence level depends on the element. In the example given ("Is the lesion endoscopically complete removed": Yes, No, Uncertain]) it looks like a null flavor, but it seems to mean "unknown," which we already have. If there were two questions (Y/N and certainty level) then it would be a proper value. (Though certainty level could also be Y/N, or percentile, etc.) (You could also precoordinate 'certainly, pretty sure, probably not, absolutely not' - would "uncertain" mean the second one or the third?) We need to distinguish between "I'm so uncertain I'm not answering" and "I'm answering but hedging." And if the ask is for the first one, I'd want to understand how it differs from 'unknown.'
Linn Brandt (Apr 30 2021 at 12:58):
I've tried to define it above, but can probably be refined: UNCERT - Uncertain: There is some data, but not enough to appropriately make a choice of the other available values presented in the value set. It should not be used in the cases where data is unknown, or the actual value is not a member of the set of permitted data values in which UNK or OTH should be used.
It's an unanswered Jira request from me, I'm not sure if I put it in correctly though. https://jira.hl7.org/browse/HTA-38
I haven't updated it after our conversations, after refining the suggestion I should update it,
Jay Lyle (Apr 30 2021 at 16:12):
OK; you may need to redirect that to -- I saw Patient Care mentioned but if this is for Observation that would be O&O.
And it's still a little fuzzy to me. "Not enough data to choose among the options" sounds like unknown, unless there is enough data to specify some other value, in which case it sounds to me like "other." But the lesion example sounded like unk.
Linn Brandt (May 01 2021 at 13:06):
In our specific use case, Uncertain is used 2 times in extentions in the Procedure profile, and once in an Observation profile.
Regarding Uncertain and Unknown: It might theoretically/statistically seem like they overlap, or that Unknown can cover for Uncertain, but when clinical personnel register what they do, it is a difference between Unknown and Uncertain (re. mentally and emotionally). The clinical groups collecting data to registries needs to be able to have these two options to use in their questions, to better reflect the mental process of what has been evaluated and support what clinicians would like to describe. I've seen it in almost all clinical registries I've worked with. Much less common than Unknown, but for some cases Uncertain is/seems more appropriate, especially for the one doing the registration. If you are trying to remove a polyp, you either have removed it, or you didn't, and in some cases you tried, but have a feeling there might be something left you didn't remove, and would like to capture that (both for the purpose of the registry and for the clinical note itself). It kind-of is unknown, and I agree it could be very subtle differences, but still, it feels different to have e.g 2 choices and you are unsure what is correct (or if what you think might be the case is really right, which I guess would be most of the cases. Usually you lean towards one, but you are not sure enough)) vs. you have no clue. Uncertainty can also come from conflicting available data.
I do agree that Uncertain should not be used when Unknown is appropriate, and uncertain-choices should be kept to the minimum. But that is more an implementation-strategy, and a strategy that should be followed by questionnaire and registry-admins. For the few cases where Uncertain is appropriate, we somehow need to be able to capture it.
Rob Hausam (May 01 2021 at 21:17):
@Linn Brandt In my reading, the results of the openEHR discussions in the links that you posted above (at least at this point) don't seem to add support for adding "uncertain" as a "null flavor" (in the HL7 v3 or FHIR code systems or otherwise). I think I agree with Jay's analysis of it, as well. As Jay said, a lot depends on the data element in question.
The v3 NullFlavor and FHIR data-absent-reason code systems are both sets of codes that describe the reason why the requested or otherwise normally expected data for a particular element is absent. I think what you are asking for is a code that means something like "the requested or expected data is not provided because it is uncertain what is an appropriate code to choose" (I don't know if that's the best wording, but it seems reasonably close). Do you agree that is the (general) idea?
In the questionnaire type example of "Is the lesion endoscopically complete removed", where you are provided a limited set of possible responses and are asked to choose one, if you are uncertain whether the lesion has been completely removed endoscopically, then you are saying "I don't know if the lesion was endoscopically completely removed", and "Unknown" would be an appropriate choice to represent that. If, instead, you were dealing with a question or data element with the notion of something like "What is the diagnosis?", where you would be expected to choose a code from a much larger value set (most likely with an extensible binding) and you were not able to find a code from that value set that appropriately captured the meaning of the diagnosis that you were trying to represent (note that there is a diagnosis that you have in mind, even if you can't find a code to represent it), then in that case you would choose the code for "Other", assuming that was available, and then you would describe the diagnosis that you actually have in mind in the data element text (CodeableConcept.text in FHIR, or an equivalent in openEHR or another model), or possibly an extension. In the case where there was an extensible binding (in the FHIR context) of the data element to the value set, you might also be able to choose a code from different value set (and potentially a different code system) that better represents your intended meaning and use that as the code for the data element.
Rob Hausam (May 01 2021 at 21:32):
In regard to https://jira.hl7.org/browse/HTA-38, I agree that the HTA space isn't the right place for this (HTA deals with code systems that are external to HL7). So for the v3 NullFlavor code system this should be a UTG change proposal (project "UTG Change Proposals" - in the 'UP' space). And if you wanted to suggest a change to the FHIR data-absent-reason code system, that would be a FHIR change request (project "FHIR Specification Feedback" and issue type "Change Request"). But definitely all of this can be rather confusing.
Last updated: Apr 12 2022 at 19:14 UTC
