Stream: inferno
Topic: DocumentReference content attachment
Lakshmi Bhamidipati (Mar 03 2021 at 22:50):
Hello,
We are using DocumentReference.content.attachment.data (Data inline, base64ed) to display document data. The contentType is "application/pdf" or "text/plain".
However one of the Inferno tests is failing because of this error -
USCDR-13: All must support elements are provided in the DocumentReference resources returned.
Could not find content.attachment.url in any of the resources.
Is it something we must support or is there a way to get around this test?
Thank you!
Yunwei Wang (Mar 03 2021 at 23:16):
You need to have at least one DocumentReference resource with content.url
Lakshmi Bhamidipati (Mar 03 2021 at 23:24):
Thank you @Yunwei Wang . I was almost sure you would say that. I guess it goes with the "must support" requirement. Since our FHIR server is a facade, I don't know how we can specify urls. The data resides in the database. We read it, encode it and display it in the FHIR resource.
Robert Scanlon (Mar 04 2021 at 00:02):
@Yunwei Wang -- Did you open a ticket regarding clarification on must support requirements for DocumentReference.content in US Core? It doesn't mention that element in the must support description. I think we were looking initially at this because it did seem odd to require support for both representations. Did you ask that question as well?
Robert Scanlon (Mar 04 2021 at 00:03):
I would think that either the data or uri elements need to be supported. Requiring both seems strange to me. But maybe there is a reason.
Yunwei Wang (Mar 04 2021 at 01:14):
Yes. I raised a JIRA ticket to US Core that whole content attribute is not mentioned in the must support narrative. FHIR-31364.
There is ticket FHIR-30111 which clarifies that
Systems are not required to support both DocumentReference.content.attachment.url AND DocumentReference.content.attachment.data
Make it clear although both marked MUST SUPPORT, systems may chose to only support one.
This ticket is raised on the ballot version of US Core (3.2.0). Unless US Core backport this ticket to next technical correction (if there is any), we have to stick with current interpretation that both are must supported in 3.1.1.
Yunwei Wang (Mar 04 2021 at 01:22):
@Lakshmi Bhamidipati The US Core state that
If both data and url are provided, the url SHALL point to the same content as the data contains.
Lakshmi Bhamidipati (Mar 04 2021 at 01:44):
Thank you for your reply. I hope US Core specification changes such that systems may chose to support only one.
Robert Scanlon (Mar 04 2021 at 11:31):
Thanks for tracking that down @Yunwei Wang -- is there any real talk of a technical correction or is everything going into v3.2.0? It seems like the industry expectation is that v3.2.0 will be available for certification through the ONC Standards Version Advancement Process, and if that is the case there wouldn't be a need for a TC from a certification perspective.
Yunwei Wang (Mar 04 2021 at 14:27):
I think it depends on how regulator adopts US Core v3.2.0. One possibility is regulator adopts v3.2.0 as a Voluntary certification (v3.1.1 is Mandatory certification). In such case, vendor will have a chance to choose which certification to pass. I am not sure. We have to wait any instructions coming out about future US Core versions.
Lakshmi Bhamidipati (Mar 05 2021 at 14:57):
@Yunwei Wang @Robert Scanlon - Regarding Document Reference, this is what the profile says - "This profile sets minimum expectations for searching and fetching fetching patient documents including Clinical Notes using the DocumentReference resource." Is "Clinical Notes" the only type of document that is expected in the response? The category description says - "The codes SHALL be taken from US Core DocumentReference Category; other codes may be used where these codes are not suitable".
Include all codes defined in http://hl7.org/fhir/us/core/CodeSystem/us-core-documentreference-category. However the code system has only 1 code - "Clinical Note". Thank you.
John Moehrke (Mar 05 2021 at 15:01):
the profile merely indicates to use the clinical note code when looking for clinical notes. It says nothing about other uses (For which there are other implementation guides that do express other uses of DocumentReference and other document categories, types, formats, etc)
Lakshmi Bhamidipati (Mar 05 2021 at 16:10):
Thank you @John Moehrke Since we are working towards implementing the USCDI elements in the US Core Profile, I am assuming we should be displaying at least all the clinical notes in our system by setting the code system to http://hl7.org/fhir/us/core/CodeSystem/us-core-documentreference-category.
Robert Scanlon (Mar 05 2021 at 16:23):
@Lakshmi Bhamidipati -- DocumentReference.category has an extensible binding to US Core Document Reference category (which only has that 1 code: Clinical Note). An extensible binding means you are free to have other codes there, as long as they do not mean the same thing as 'Clinical Note'. So essentially what this is saying is that you are free to use DocumentReference for things other than Clinical Notes, and you can categorize your DocumentReferences however you want, but for anything that is a "Clinical Note" as we define it, you MUST use the "Clinical Note" category. And we then add some more rules around things that are "Clinical Notes" in guidance.
Lakshmi Bhamidipati (Mar 05 2021 at 16:27):
Thank you @Robert Scanlon.
Robert Scanlon (Mar 05 2021 at 16:29):
For the required search without category, you can send things other than clinical notes (but it must also include all of your clinical notes). All resources returned have to conform to the profile, because this is a general 'DocumentReference' profile. For the required search WITH category, if you search by the "Clinical Note" category, you must return all references that are "Clinical Notes" as defined in this guide. But users can search by other category codes, if you have other codes in your system.
Robert Scanlon (Mar 05 2021 at 16:31):
In our 'DocumentReference' profile set of tests, we may end up performing that category search with something other than that clinical note category, if you happen to return a different category code from the first (most general) search. We have a separate test sequence for 'Clinical Notes Guidance' that actually ensures you have clinical notes in your system.
Lakshmi Bhamidipati (Mar 05 2021 at 21:50):
Please pardon me for asking multiple questions on this topic. According to clinical notes guidance tests, the system must implement the US Core DiagnosticReport Profile for Report and Note exchange and to support a minimum of the three report categories - Radiology, Pathology and Cardilogy. My question is - If I represent a clinical note in DocumentReference in the binary format (either as text/plain or application/pdf), am I expected to display the same data in DiagnosticReport resource? Thank you.
Yunwei Wang (Mar 08 2021 at 15:01):
According to the US Core 3.1.1 Clinical Notes Guidance,
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
and
This guide requires servers implement the duplicate reference to allow a client to find a Pathology report, or other Diagnostic Reports, in either Resource.
If the binary format is one of the Diagnostic Reports, then it shall be also attached in DiagnosticReport resource using DiagnosticReport.presentedForm.url.
Lakshmi Bhamidipati (Mar 08 2021 at 16:24):
Thank you @Yunwei Wang
Lakshmi Bhamidipati (Mar 12 2021 at 15:47):
Hello, getting back to DocumentReference :) If I have documents that are NOT clinical notes in the DocumentReference Resource and I don't know how to categorize them, since it is a codeableconcept, if it okay for me to just populate "Text" element? Thank you.
Yunwei Wang (Mar 12 2021 at 18:55):
According to FHIR binding rules, you are free to use either text or your own coding if concept is not covered by extensible binding. The receiving implementation may nor may not such resource with additional coding.
Santosh Pai (Mar 16 2021 at 07:38):
Running inferno locally on docker. Was running fine , but now giving “ internal server error” on launch - any clues how to fix this error ?
Robert Scanlon (Mar 16 2021 at 13:30):
It's off-topic for the thread, but Santosh let us know he was able to get it working again. @Santosh Pai -- feel free to open another thread in the #inferno stream if you continue to have problems, or reach out by email. Thanks for letting us know.
Santosh Pai (Mar 16 2021 at 13:33):
Will do Rob. Thanks for the quick response.
Santosh Pai (Mar 16 2021 at 13:34):
note : we have docker desktop on a WVD ( windows virtual device) just wanted to let you know
Lakshmi Bhamidipati (Mar 17 2021 at 18:01):
Hello @Yunwei Wang @Robert Scanlon - for US Core compliance and certification, is our FHIR server expected to support this section under Clinical Notes - Determining Server Note Type Support Using The Value Set Expansion Operation ($expand) ? Thank you.
Robert Scanlon (Mar 17 2021 at 18:18):
No, that is an optional feature to support for servers, so we do not test it -- see here
A FHIR server claiming support to this guide SHOULD support the $expand operation.
A few sentences before that, the guide states "a client can determine the note and report types support by a server", which I think is misleading because we usually interpret "a client can/may" as "a server shall", but that clearly isn't the case here. What are your thoughts about that "can" there @Yunwei Wang, is that something worth open a ticket to consider rephrasing?
Last updated: Apr 12 2022 at 19:14 UTC
