Stream: implementers
Topic: Updating Observation of permanent traits
Morten Ernebjerg (Mar 01 2021 at 14:48):
We have a system where patients report certain data, including weight and blood type, and are free to update these values at any time. If they update the weight, we would interpret that as meaning that their weight changed & create a new Observation instance However, since the blood type a permanent trait, the natural interpretation of an update is that the previous entry was incorrect. Assuming that to be the case, we could react in different ways data-wise:
- Create a new blood type Observation but leave the previous instance untouched
- Create a new blood type Observation and update the previous instance by setting
status= "entered-in-error" - Update the existing blood type Observation instance, setting
status= "amended" (and changing theissueddate?)
What would be preferred way? I assume that (1) is problematic because it leaves to contradictory observations with the same status. But I am not quite sure under which circumstances one can think of a change as an amendment - (3) - rather than a new observation that may invalidate another one - (1) & (2). For case (3), it is also not clear to me whether the update of issued is required (the documentation of issued talks mainly about observation needing review)
Lloyd McKenzie (Mar 01 2021 at 14:56):
The typical mechanism would be to record a new mechanism. It's a new statement made by a new individual at a different time - possibly using a different method/device to make the determination. Policies around whether to mark the previous one as "entered in error" vary. If the data came from a different source, it's hard to declare it was erroneous. You can use the observation-replaces extension to note that your new value trumps the old one.
Elliot Silver (Mar 01 2021 at 20:16):
Morten Ernebjerg said:
However, since the blood type a permanent trait, the natural interpretation of an update is that the previous entry was incorrect.
Based on my limited understanding, blood type can change due to bone marrow transplant or similar, and sometimes will revert back to the original as well. So a change isn't necessarily an error.
Morten Ernebjerg (Mar 02 2021 at 07:25):
Thanks for the input!
Based on my limited understanding, blood type can change due to bone marrow transplant or similar
Ah, learned something new (again!) - I suspect this might actually be true of many of things we think of as permanent.
Eric Prud'hommeaux (Mar 02 2021 at 09:47):
Lloyd McKenzie said:
You can use the observation-replaces extension to note that your new value trumps the old one.
An argument for (2) would be that you don't want someone to read that Obs and assume that it's the current belief of the "system" (i.e. the folks who control what's in the EHR). To that end, it seems that instead of adding the replaces extension to the 2nd Obs, you'd want to add a modifying replaced-by extension to the first Obs. Such an extension would expand slightly the semantics of modifying to describe a state of belief rather than just the literal interpretation of the resource (we measure X).
That distinction sounds academic but it is pretty practical to want to use FHIR itself to capture belief rather than requiring external data to say "look at this, don't look at that". This could also be an argument for expanding the Obs.status value set.
Lloyd McKenzie (Mar 02 2021 at 14:47):
Typically you don't have access to update the first one. You create the link in the new one (and systems are responsible when looking at the old one to check to see if it's replaced). Also, "replaced-by" wouldn't be modifying. It doesn't change the meaning of the first.
Lloyd McKenzie (Mar 02 2021 at 14:48):
In Observations, in general, the general pattern is query and look at most recent, unless there's a particular reason to look at older stuff. So most of the time "replaces" is implicit if the Observation type is a "last in wins" kind of Observation.
Morten Ernebjerg (Mar 02 2021 at 15:40):
So most of the time "replaces" is implicit if the Observation type is a "last in wins" kind of Observation.
@Lloyd McKenzie For my understanding: by "last in wins" kind of Observation, are you referring to a class of Observation with certain generic characteristic or is it rather a detailed case-by-case classification?
Lloyd McKenzie (Mar 02 2021 at 15:57):
I think it would be case by case and context-specific
Morten Ernebjerg (Mar 02 2021 at 15:58):
OK, thanks!
Last updated: Apr 12 2022 at 19:14 UTC
