Stream: Orders and Observation WG
Topic: Mark lab results in observations as 'not reliable'
Alexander Röck (Oct 01 2020 at 11:54):
Hello together,
I have the following usecase and wonder, if anybody else has the same issue and can give an advise.
We receive lab results (measurements) as FHIR observations. Besides the actual value we also receive a reference range and an interpretation code with respect to the reference range.
Now, the legacy lab software had a 'feature' that marked questionable measurements specificyally. I.e. a value with reference range and interpretation was transmitted, but at the same time the lab software wants to say: "dear user, please take care when using this value, due to wrong calibration the value may be false".
My reasoning would be to use Observation.interpretation, extend the current ValueSet by a value let's say "questionable" and let our frontend application mark those values specifically whenever this special interpretation code is present.
Another idea was to use 2 Observation.interpretation codes (field has cardinality 0..*). In my eyes this does not make too much sense, since the value should not be used anyway as long it is "not reliable". So any given reference range (such as normal, above threshold etc) is irrelevant.
I'd be happy to receive your thoughts in this.
Thanks, Alexander
Lloyd McKenzie (Oct 01 2020 at 16:18):
@Eric Haas @Hans Buitendijk
Eric Haas (Oct 01 2020 at 19:01):
extension ? don't think should be part of interpretation codeset @Rob Hausam ??
Grahame Grieve (Oct 01 2020 at 20:35):
I've seen this in 2 different jurisdictions. I think it's awful diagnostic service, but one lab claimed that they had to do it because of the interplay between regulation and billing rules. On the one hand, I think it would be an awful addition to the value set (it's the diagnostic equivalent of a kick me flag) but on other , if you have to do it, it would be really good for everyone to know what it means
Hans Buitendijk (Oct 02 2020 at 13:56):
I'm with Grahame on needing consistency of interpretation. It would be in that context appropriate to add it to the observation interpretation codes. It is extensible, so better we extend it with one interpretation than others create their own flavors for essentially the same. @Rob Hausam ?
Rob Hausam (Oct 02 2020 at 14:58):
Hmm. I think this one deserves some further analysis and thought before we make a decision. My thought at the moment is that adding a "questionable" (or similar) code to observation-interpretation isn't really the best choice. We've spent a lot of time and have harmonized the observation interpretation codes across all of the V2, V3/CDA and FHIR standard families. I think that the notion of interpretation has the underlying assumption that you have data that is considered to be reasonably reliable that you can interpret. That the data itself is unreliable is definitely an exceptional case. There is certainly precedent for including codes for some exceptional cases in value sets, so I don't know that we can or should exclude that possibility entirely. But if we would add a code to the value set for this, I think it might be better to make that code more specific, such as "unable to interpret due to inadequate data quality" (I grant that could be a bit too verbose, but something like that). Or instead, the interpretation code could simply be omitted in this case and the concern about the data quality and the reason for no interpretation would be conveyed in the note (which I think would likely be my preference). I think this needs further discussion in the OO WG (or maybe reconvene the observation interpretation OO subgroup) to consider and propose what we think will be the best solution.
Grahame Grieve (Oct 03 2020 at 00:05):
agree about further discussion and care around defining it
Alexander Röck (Oct 05 2020 at 15:09):
thanks for caring. should I keep following this thread, or how do I otherwise receive updates on your "care plan" for this :-)
Alexander Röck (Oct 05 2020 at 15:18):
btw: the lab team at the customer agreed on my reasoning: it doesn't make too much sense to use those values anyways und thus 2 interpretation codes are not useful. However, an explicit comment in the note field seems reasonable and we would set the interpretation code to an extended value. As soon as you propose a new value for the codeset we could switch to that 'official' value. If a new value would be available early enough (by Feb 2021 approx) we could use it right from the start.
Alexander Röck (Nov 10 2020 at 15:14):
Hello again!
We need to proceed with this in the project. The intended way to go is to extend the value set Observation Interpretation Codes [1] by a certain value. Specifically we would add a value to _ObservationInterpretationExceptions. Given the definition ("Technical exceptions resulting in the inability to provide an interpretation. At most one allowed. Does not imply normality or severity.") it is the code group that fits best our use case.
The code would be e.g. UI - uninterpretable due to technical difficulties
Any comments on that?
[1] http://build.fhir.org/valueset-observation-interpretation.html
Last updated: Apr 12 2022 at 19:14 UTC
