Stream: implementers
Topic: Observation Status values
Craig Newman (Jul 16 2019 at 17:19):
We’re trying to map a v2 OBX segment to the Observation resource. We are thinking that OBX-11 (Observation Result Status) will map to Observation.status. However, we’re having trouble mapping individual status codes as the v2 table (HL70085) is larger than the FHIR value set (which is required and not extensible). Ammended, Correction, Final and Preliminary are easy to map. Deleted and Originally Posted as Wrong probably map to entered-in-error. Status Changed to Final Without Retransmission, In Process and Partial may map to final, registered and preliminary respectively. But several codes don’t have a clear FHIR value (Appended, Verified). Other codes may not make sense in the context of an observation (Not Asked, Order Detail, Cannot Be Obtained). Any suggestions how we account for these unmapped codes in R4? We’re not sure if an extension for v2 observation status is warranted, but we’re struggling with the Required binding. Thanks.
Eric Haas (Jul 16 2019 at 18:14):
@Rob Hausam and I have done this when we worked on these statuses for obs and dr. I will look at my notes and see if I can dig it up
Eric Haas (Jul 16 2019 at 20:11):
Eric Haas (Jul 16 2019 at 20:11):
no mappings to v2 but maybe is helpful
Chris Grenz (Jul 25 2019 at 14:58):
@Eric Haas @Rob Hausam What status would you recommend for an Observation that was rejected by a verifier (with no correction)? It never went "final", so "entered-in-error" isn't appropriate. I guess "cancelled"? Seems a little off as well since the observation was completed, but a later individual rejected it.
Eric Haas (Jul 25 2019 at 15:03):
it as if it was never done? @Riki Merrick ?
Riki Merrick (Jul 25 2019 at 15:43):
I don't think we have a status for that in v2 either ... unless you consider X = results could not be obtained for that (because it implies you strated the testing, but didn't finish for whatever reason) compared to N = not asked, meaning you never started testing, even if the order implied you would) in that case I would use cancelled
Lloyd McKenzie (Jul 25 2019 at 17:32):
Cancelled means that it got stopped before it was 'final' - and that's what happened here. That would be true even if preliminary results had already been shared
John Silva (Jul 25 2019 at 17:36):
And imagine the impact on a user interface that already showed (or continues to show) that value. An even more problematic situation is what to do about that observation if it was used in a calculation that is also displayed on a UI.
Rob Hausam (Jul 25 2019 at 18:39):
I think I agree that cancelled is the best fit. It seems that once it is cancelled, then John's issues could be addressed - presumably at that point the value would no longer be displayed (but you could still see it with the "preliminary" status if you looked at the history). And in the second (less common) case presumably the calculated value (derived observation) would also need to have its status set to "cancelled" assuming that the calculation could not be performed without the original value that it had been based on.
John Silva (Jul 25 2019 at 19:40):
@Rob Hausam -- I guess this is a good reason to use the R4 dependsOn (or STU3 related) property to keep track of the dependencies of the calculated value on the original values that contributed to the calculated value.
Last updated: Apr 12 2022 at 19:14 UTC
