Stream: Orders and Observation WG
Topic: GF#17531
Eric Haas (Aug 21 2018 at 18:55):
GF#17531: @Christine D Does Observation.meta.lastUpdated work for your use case? If not, why not?
Christine D (Aug 22 2018 at 12:54):
@Angie Romano Do you and Roland have thoughts on this?
Christine D (Aug 22 2018 at 12:58):
Checking with our team to see if that would work. @Angie Romano
Angie Romano (Aug 24 2018 at 12:49):
Isn't Observation.meta.lastUpdated automatically populated when the message is posted or updated on the FHIR server? If so, I'm not sure that's the same thing as populating a local time. if there is ever an update to the result, the lastUpdated timestamp would be changed.
Lloyd McKenzie (Aug 24 2018 at 15:38):
Correct. Observation.lastUpdated is when your server received the data, not when the source of truth was changed. If you receive an Observation that was changed 2 years ago in a document today, your lastUpdated will be today.
Eric Haas (Aug 24 2018 at 16:31):
I think what GF#17531 is addressing is already covered by Provenance which points to the Observation. Would that work?
Lloyd McKenzie (Aug 24 2018 at 16:36):
If anyone actually did Provenance and it was reasonable to have to query Provenance, it would work. But I'm not sure either of those are true.
Eric Haas (Aug 24 2018 at 22:22):
I don't follow Lloyd's logic, this sounds like a Provenance element to me. Are you suggesting we duplicate Provenance in Observation ( and by logical extension to all the other clinical resources because nobody is "doing" Provenance. )?
Lloyd McKenzie (Aug 24 2018 at 22:30):
We frequently duplicate "key" elements from Provenance in resources (who created them, when they were created, etc.) if that's important to common use of the resource. So the question is whether "last updated" should be treated in the same way.
Eric Haas (Aug 24 2018 at 22:40):
And we undermine the adoption of Provenance... Provenance would avoid duplication. I am not convinced this is a good long term strategy.
Lloyd McKenzie (Aug 24 2018 at 22:45):
Provenance is still relevant for history and lots of other things. But key information shouldn't require you to look somewhere else.
Grahame Grieve (Aug 26 2018 at 21:13):
We denormalise some provenance information into resources, when we think that the provenance is inherently relevant to the interpretation, knowing that in most cases, provenance is treated as out of band information. In this case, the element is present in Observation, as issued : instant - so what are we discussing?
Eric Haas (Aug 31 2018 at 06:56):
The ask is for an element to represent "The local date and time of the last modification made to the accession record at the central laboratory. This includes a Universal Time Offset plus/minus hours and minutes." And is certainly captured by Provenance.
Eric Haas (Aug 31 2018 at 06:56):
There are already these extensions:
http://hl7.org/fhir/StructureDefinition/event-eventHistory
Grahame Grieve (Aug 31 2018 at 07:45):
I don't understand how it's different to issued?
Eric Haas (Sep 01 2018 at 04:46):
@Christine D can you clarify how is different?
Christine D (Sep 01 2018 at 21:57):
@Angie Romano thoughts?
Angie Romano (Sep 04 2018 at 19:36):
Trying to investigate the suggested extension. The url is not resolving. I'll keep looking.
Eric Haas (Sep 04 2018 at 19:41):
try this: http://build.fhir.org/extension-event-eventhistory.html
Angie Romano (Sep 07 2018 at 14:38):
Thanks @Eric Haas that link worked and I've added it to our sample data. To address @Lloyd McKenzie's questions/comments above, how do we understand what the use of provenance is out in the real world. Since we are trying to come up with an implementation guide to allow lab data to be retrieved via FHIR for a clinical trial it is important to understand that what we are asking for is realistic. Is there anywhere where specific resource use is tracked?
Eric Haas (Sep 07 2018 at 17:23):
@Lloyd McKenzie ??
Lloyd McKenzie (Sep 07 2018 at 18:04):
We'd love to be able to better track specific resource use, but it's a hard problem. Provenance isn't super widely supported yet - even though it really should be. It's quite important when you're dealing with shared data. However, most lab data comes from v2. So the real question is whether there's an element for this in v2 and then figure out where best to map it. @Eric Haas (tossing it back at you :>)
Eric Haas (Sep 07 2018 at 21:55):
@Riki Merrick ? ( my V2 knowledge is getting rusty)
Riki Merrick (Sep 08 2018 at 01:29):
The way I read the requirement I would think what Angie is looking for is OBR-22; that is the date time of result / update and is used in v2 messages to determine if the sent data is newer than data already in the system per the LRI IG. Now that is at the order level and we all know the term accession is a slippery one - for some it is an individual order (OBR-22 works well for this sceanrio), for more it is a specific sample (that could have more than one order, so woudl have more than one OBR-22) and yet for others it encompasses all the orders and samples from a single encounter (again multiple OBR-22 elements) - in most systems ONLY the updated order will have a new OBR-22, even if all other orders are also sent along with that update message.
The date you are referring to in provenance would map to MSH-7 I think (date/time of message creation / sending)
Lloyd McKenzie (Sep 08 2018 at 02:07):
Right - so that's Observation.issued based on the current mappings
Angie Romano (Sep 10 2018 at 19:59):
@Lloyd McKenzie is it MSH-7 that is mapping to Observation.issued or OBR-22?
If it is MSH-7, do we really need OBR-22?
If OBR-22, then would all of the scenarios Riki mentioned above provide me with the last time a specific lab result was updated? In reading through it multiple times, I think it might.
Lloyd McKenzie (Sep 10 2018 at 20:10):
It's mapped to OBR-22 on the mappings tab
Lloyd McKenzie (Sep 10 2018 at 20:11):
The MSH-7 (and everything in the MSH) is just for transport, not for persistence.
Angie Romano (Sep 12 2018 at 13:00):
Thanks! I'm a little rusty on my HL7 v2 knowledge. @Christine D we need to think about this the best approach for this one. You have Reported Date and Time mapping to Observation.issued and it looks like Last Active Date and Time might land in the same place.
Lloyd McKenzie (Sep 12 2018 at 14:33):
So in the v2 world, if you're going to revise a result, you update the reported date/time. The original reported date is only available as history. The same has been carried over in FHIR.
Eric Haas (Sep 12 2018 at 15:03):
By history Lloyd means you can look at the resource version history or the Provenance resources associated with the resource. ( he may correct me)
Lloyd McKenzie (Sep 12 2018 at 16:13):
Yup, that's what I meant.
Last updated: Apr 12 2022 at 19:14 UTC
