Stream: implementers
Topic: Linking ofBinary resource created from lab/Radiology report
Ashish Anand (Apr 13 2017 at 06:30):
Hi,I am creating a binary resource from a Lab/Radiology report coming from a hospital but how that will be referenced in Observation or Diagnostic report resource,i dont see any reference for binary resource in it.
Lloyd McKenzie (Apr 13 2017 at 14:07):
You should submit a change request asking for that to be added to Observation.related.target and possibly also DiagnosticReport.result. You do have the ability to send a Binary as the result of an Observation using valueAttachment.
Eric Haas (Apr 13 2017 at 15:13):
Also DiagnosticReport has .imagestudy and .image so you should look at those first before submitting a change request. "You do have the ability to send a Binary as the result of an Observation using valueAttachment." Will be the response so will need to provide a pretty good use case reason why some other way is better or why can't use valueAttachment. if you submit a tracker.
Ashish Anand (Apr 13 2017 at 19:48):
Thank you
Lloyd McKenzie (Apr 13 2017 at 21:28):
My use-case for adding it to "related" is I can easily see on Observation being based on another that happens to have no metadata - it's just a PDF.
Eric Haas (Apr 13 2017 at 23:08):
There is DiagnosticReport.presentedForm for that. and valueAttachment still works or Media. It doesn't seem like a step toward interoperablity to create more ways to do this.
Elliot Silver (Apr 14 2017 at 00:23):
Lloyd, isn't your use case handled by Provenance? This observation is derived/extracted from that one (or from that binary document)?
Eric, we can reference an Observation from a DiagnosticReport ("the report calls out certain observations"), but not the other way ("these observations came from this printed report").
Without more clarity on the use case, I'd lean towards Provenance as the answer.
Lloyd McKenzie (Apr 14 2017 at 00:27):
By those grounds, we don't need "derivedFrom" on Observation at all.
Lloyd McKenzie (Apr 14 2017 at 00:27):
(It can handle relationships to any resource)
Lloyd McKenzie (Apr 14 2017 at 00:28):
I think Provenance is for secondary traceability, not primary business use.
John Moehrke (Apr 14 2017 at 12:34):
secondary vs primary is not a good explination. We have recognized, shown in the W5 report, that there are times when elements of Provenance are brought into our other resources, because that element is critical to the functioning of that resource. This enables these other resources to function even when Provenance is not enabled/used/required. I would not call this primary vs secondary, as from a "provenance" perspective the Provenance record is always primary. That is to say when an organization wants Provenance, they will demand use of Provenance and they will get uniform "provenance". The deviations from relying on Provenance is recognition that not all organisations need or want Provenance; they might be tracking provenance another way...
John Moehrke (Apr 14 2017 at 13:54):
Note, as the co-chair of security who own Provenance.... We would of course, love to have Provenance be necessary everywhere, thus removing all W5 from resources... but this would not be keeping with the FHIR principles... So judicious duplication where critical is the compromise.
Eric Haas (Apr 15 2017 at 21:13):
My vote is for a)Provenance or b) related Observation with valueAttachment. or c) extension. .related is intended to group observations and not a general catchall for other related resources. Looking back I think allowing QR as resources may be a mistake since Provenance might be a better fit for that too.
Last updated: Apr 12 2022 at 19:14 UTC
