Stream: implementers
Topic: PDF instance of Observation
Christoph Graumann (Nov 19 2019 at 16:53):
Hi folks, we provide Observations in our software via FHIR, which represent 12-lead ECG measurements, to be requested by third-party systems. So far so good. However, our customers are fairly used to get these ECG measurements as PDF report, which they can for example access through our user frontend. Now we want to provide them also via the FHIR REST interface. Obviously I looked at DocumentReference which seems to be the perfect way wrapping such a PDF file the “FHIR way”. But I could only find an explicit reference to the Encounter and besides that only DocumentReference.context.related. Would it be best practice to use this for referencing the Observation? At least it is a valid search parameter, but for me it seems quite sloppy to blindly search for DocumentReferences that might coincidently relate to the desired Observation…
On the other hand @Patrick Werner wrote in #implementers > Documents:
So if you have a GET request with a non-fhir mime type as accept, it is fine to directly return the binary
In the end this PDF file is a representation of the Observation itself. So from my understanding it would make sense to react on a request for one single Observation with HTTP-header Accept: application/pdf by directly returning the respective PDF file. Would that be a valid alternative from FHIR perspective?
P.S.: same situation goes for the Encounter which also has a PDF representation – but there the DocumentReference makes at least more sense to me…
Michele Mottini (Nov 19 2019 at 16:56):
No, that would be non-standard
Michele Mottini (Nov 19 2019 at 16:57):
The PDF must be referenced (as binary resource) or contained (base64 endoded) by / in a FHIR resource - either Observation or DiagnosticReport or DocumentReference
Vassil Peytchev (Nov 19 2019 at 17:02):
Observation can have a value of type attachment - the document will be part of the observation. Observation can also be basedOn a Document Reference.
Christoph Graumann (Nov 19 2019 at 17:07):
Ah ok, Attachment would be good. The value itself has quantity 0..1 and is already used for the sampled (ECG) data. Does it make sense to use a component for it with valueAttachment inside the Observation?
Michele Mottini (Nov 19 2019 at 17:39):
I'd go for a DiagnosticReport with the PDF in presentedForm and the observation(s) in result
Michele Mottini (Nov 19 2019 at 17:40):
That's the way lab results that have a textual description and discrete values are usually represented as
Christoph Graumann (Nov 19 2019 at 18:22):
I thought about that either, but don't find a DiagnosticReport to be the right fit according to its description. Neither the PDF nor the Observation itself contain a diagnosis - which is, by definition, to be made by a physician. Our results are pure measurements and maybe containing some signal processing results - but not a diagnosis...
John Moehrke (Nov 19 2019 at 18:23):
in that case then you should publish it as a DocumentReference->Binary; from which an Observation can be basedOn
John Moehrke (Nov 19 2019 at 18:24):
note that the "Document" in DocumentReference is the degraded definition of document from http, not the CDA definition of document
Eric Haas (Nov 19 2019 at 18:40):
if I understand this correctly, the Observation.valueQuantity is valued with some number... that is derived from the ekg , the the best wayis to reference the DocumentReference with the existing Observation element derivedFrom.
Eric Haas (Nov 19 2019 at 18:43):
@John Moehrke I don't agree with making the focus of the measurement the DocumentReference instead of the Observation we already have DiagnosticReport to wrap observations....
Eric Haas (Nov 19 2019 at 18:48):
and that doesn't work for you I'd like to know why
John Moehrke (Nov 19 2019 at 18:52):
I meant derivedFrom. as I understood the document was evidence from which the Observation is derived. right>
Grahame Grieve (Nov 20 2019 at 04:53):
Neither the PDF nor the Observation itself contain a diagnosis - which is, by definition, to be made by a physician. Our results are pure measurements and maybe containing some signal processing results - but not a diagnosis
Grahame Grieve (Nov 20 2019 at 04:55):
The resource is named 'DiagnosticReport' because it's usually provided by a Diagnostic Service to help with diagnosis. I believe you're reading too much into the name there, perhaps due to language issues. It's certainly common that most diagnostic reports do not actually contain a diagnosis.
And what you are dealing with is certainly intended to be a diagnostic report with a PDF (presentedForm) and maybe some supporting structured data in observations from the ECG
Grahame Grieve (Nov 20 2019 at 04:56):
if there's some wording in the definitions beyond the name that make you think DiagnosticReport is not right, what is it?
Christoph Graumann (Nov 20 2019 at 06:43):
Besides the name I also did not really see fit in the Scope and Usage description. It lists laboratory results or imaging as example and "Other diagnostics, e.g. Cardiology" which sounded to me more like findings or medical letters rather than technical results of a medical device. Whereas Observation literally lists EKG data, which is why we have been using only those resources being linked directly to an Encounter and Patient.
However, the way you describe it now I understand we should probably use DiagnosticReport as additional wrapper for each Observation, which contains the PDF as attachment.
Grahame Grieve (Nov 20 2019 at 06:45):
that's our (well, my, at least) expectation. do you want to create a change proposal for us to clarify the EKG/ECG use cases?
Christoph Graumann (Nov 20 2019 at 06:51):
Yes, I think that would be worth doing, since also other ECG vendors usually provide PDF versions of their measurements. So I think this might be a quite common thing to do in that realm.
I didn't have the chance to create a change proposal yet so I'm a newbie :innocent: could you point me in the right direction where to do this?
Christoph Graumann (Nov 20 2019 at 07:05):
I meant derivedFrom. as I understood the document was evidence from which the Observation is derived. right>
To answer to @John Moehrke: no, technically speaking it would even be the other way round. The Observation contains all signals of the ECG measurement as they are coming from the device. The PDF is visualising these together with patient data and some technical information about the measurements. As such it is more a courtesy to the consumers of the FHIR interface, since they don't need to worry about visualising the ECG themselves in the right way. This is why I'd rather understand the Observation and the PDF as two representations of the very same thing.
So thinking about this definition it makes more and more sense to me using DiagnosticReport.presentedForm...
Lloyd McKenzie (Nov 20 2019 at 08:34):
At the bottom of every page in the FHIR spec is a "propose a change" link. You'll need to create an HL7 Jira account first. (Unfortunately there isn't an immediate link on how to do that when you click on "propose a change" - I'll see what we can do about that. In the meantime, the link to create an account is here: fhttps://jira.hl7.org/secure/Dashboard.jspa We just changed to Jira this weekend.) Once your account is approved, you can submit change requests. If you have any issues with the process, post here or send me a PM.
John Moehrke (Nov 20 2019 at 14:15):
I meant derivedFrom. as I understood the document was evidence from which the Observation is derived. right>
To answer to John Moehrke: no, technically speaking it would even be the other way round. The Observation contains all signals of the ECG measurement as they are coming from the device. The PDF is visualising these together with patient data and some technical information about the measurements. As such it is more a courtesy to the consumers of the FHIR interface, since they don't need to worry about visualising the ECG themselves in the right way. This is why I'd rather understand the Observation and the PDF as two representations of the very same thing.
So thinking about this definition it makes more and more sense to me using DiagnosticReport.presentedForm...
Sorry, I misunderstood. So you are you using Observation as the EKG example shows? http://build.fhir.org/observation-example-sample-data.html. Or is there improvements there? I at one point tried to create a EKG specific Resource but it got no interest.
The link to a DocumentReference which is the rendering would be through a pointer from the DocumentReference.context.related to the Observation. Thus to find that DocumentReference for your Observation, you search using DocumentReference with the parameter -related equal to your Observation. This order of linking from DocumentReference to the Observation follows the REST pattern of the object created second points at the object that was created first (in a likely case).
Christoph Graumann (Nov 20 2019 at 15:32):
Yes, our Observations look quite like that example. We did not use any extensions. For transmitting the measurement values and meta data we have good experience using this resource, so I don't think a dedicated ECG resource would be necessary.
Christoph Graumann (Nov 20 2019 at 15:39):
To summarise, there would be two valid options to augment the Observation with a PDF representation:
- DocumentReference with content.attachment for the PDF and context.related for the Observation
- DiagnosticReport with presentedForm for the PDF and result for the Observation
Following Grahame Grieve's statement, the DiagnosticReport would be the expected way to go for such ECG reports.
Besides, we also have a similar situation with the Encounter, where we provide a PDF report containing all relevant information (i.e. multiple ECGs, vital parameters, patient data, measurements, trends, etc...). You could call it a summary report for an entire Encounter. In that situation I feel the DocumentReference to be the resource of choice.
D'accord?
John Moehrke (Nov 20 2019 at 16:30):
well this is why these parts of FHIR are in "Standard for Trial Use"... we all need to try things and see how they work. The hope is that we align quickly, but sometimes it takes a longer time to come to Trial Use feedback inspired decision.
John Moehrke (Nov 20 2019 at 16:32):
My preference given what you have described is DocumentReference. If however you had a FHIR encoding of the report, then DiagnosticReport with the PDF in presentedForm would be more clear winner. The bad part of this is that consuming applications need to look in two places. This was the same struggle we had with "clinical notes"... https://build.fhir.org/ig/HL7/US-Core-R4/clinical-notes-guidance.html
Christoph Graumann (Nov 20 2019 at 17:40):
Thanks for sharing that link! Though I agree this is not a satisfying solution:
In order to enable consistent access to scanned narrative-only clinical reports the Argonaut Clinical Note Server SHALL expose these reports through both DiagnosticReport and DocumentReference by representing the same attachment url using the corresponding elements listed below
This seems just to be a workaround for the unsharp definition of those two resources, instead of clarifying the usecases or maybe even merging them into one single resource type. Apparently, I am not the only one struggling with those definitions...
Furthermore, the guide goes on:
If servers properly categorized scanned reports and used the correct resource per report type (e.g. Pathology scan in DiagnosticReport) this wouldn’t be required.
Funny and somewhat contradictory statement, being in an implementation guide...
Anyhow, this still leads me to the conclusion from my previous post.
Eric Haas (Nov 20 2019 at 17:46):
I think the confusion may stem from the term ""Other diagnostics, e.g. Cardiology" we can possibly list them all but making this clearer that it include results from all kinds of diagnostic procedures such as... might be an improvement..
I don't think the DiagnosticReport.presentedForm should have pdf of "just the tracing" but should be a representation of the entire report. The DiagnosticReport.results would have the sampled data in a structured format and if you are supplying "just the tracing" as a convenience then use DiagnosticReport.media as a key image.
Grahame Grieve (Nov 21 2019 at 05:54):
a workaround for the unsharp definition of those two resources, instead of clarifying the usecases
It results from messy work flow, and a lack of confidence in trading partners, which encourages further lack of confidence
or maybe even merging them into one single resource type
Well, we could do that. But that doesn't serve other use cases. And if we keep doing that merging, we'll end up with one resource called 'Stuff'
Christoph Graumann (Nov 21 2019 at 07:04):
Fair enough. From a vendor's point of view, it is always good to have clear implementation instructions. So if there is no generically better way to have those overlapping resources, the recommendations of the aforementioned guidance might in fact be the only way. And when it comes to standards I'd rather follow rules, even if they don't make entirely sense in my specific use case, instead of having too much freedom leading to unnecessary discussions during development.
That said, I'd vote for a better description of both resources DiagnosticReport and DocumentReference, mentioning the overlap and the boundaries, respectively.
I found two existing Jira issues, so I'll comment on them instead of raising another:
Christoph Graumann (Nov 21 2019 at 07:14):
@Eric Haas I agree. In our case, the PDF does contain more information than just the tracing and is considered a self-explanatory report, which in fact is in many cases the only data that is actually shared between end-consumers (e.g. cardiologists). All traces are in vector format. Though DiagnosticReport.media.link again is a DocumentReference, which might carry a PDF as attachment, I would refrain from using the term "image" for such a report.
However, it brings another thought into the discussion: if following the (unofficial) Clinical Notes Guidance from above, everyone should implement _both_ DiagnosticReport and DocumentReference for one _same_ PDF. If so - shouldn't the resources reference each other?
Grahame Grieve (Nov 21 2019 at 07:21):
I don't think that everyone should do that. I think that EHRs should just tell clients that diagnostic reports will appear as normal diagnostic reports, but some externally/patient provided diagnostic reports may appear in patient documents, since that's how the system works.
But the US vendors didn't believe that would absolve them of risk, so they chose to put them in both. THe obvious flaw to me is that they won't pick up patient provided documents not categorised as diagnostic reports. I don't know if there's good data about the % like that though
John Moehrke (Nov 21 2019 at 13:20):
Fair enough. From a vendor's point of view, it is always good to have clear implementation instructions. So if there is no generically better way to have those overlapping resources, the recommendations of the aforementioned guidance might in fact be the only way. And when it comes to standards I'd rather follow rules, even if they don't make entirely sense in my specific use case, instead of having too much freedom leading to unnecessary discussions during development.
That said, I'd vote for a better description of both resources DiagnosticReport and DocumentReference, mentioning the overlap and the boundaries, respectively.
I found two existing Jira issues, so I'll comment on them instead of raising another:
thanks.
Christoph Graumann (Nov 22 2019 at 07:47):
:info: raised new ticket for the linking question: https://jira.hl7.org/browse/FHIR-25243
Last updated: Apr 12 2022 at 19:14 UTC
