Problem with url checking for DocumentReference and DiagnosticReport

[neharastogi]

Inferno currently matches the attachment Urls for DocumentReference and DiagnosticReport as part of the test - 4.31.02 But if we are using pre-signed URLs for such attachment, the query params of that url like expires and signature will change every time the url is generated.

There is already an open issue to check if the urls are downloadable but in addition, can inferno either compare the attachment binary or ignore such query params which are bound to change every time.

Your environment

Edition of inferno (Community or Program): Program Version of inferno: v2.2.2

[yunwwang]

Hello @neharastogi

Can you give me an example how the DocumentReference.content.attachment.url looks like when using pre-signed URL?

[neharastogi]

Sure, here is an example - https://<hosted url>?AWSAccessKeyId=<SampleKey>&Expires=1658179738&response-cache-control=no-cache%2C%20no-store%2C%20must-revalidate&response-content-type=text%2Fhtml&x-amz-security-token=<sample-token>&Signature=<sample_signature>

Everytime we generate a url for the same resource, the query parameters - Expires and Signature will change.

[yunwwang]

Thanks. I will bring this back to the team for discussion.

I have a question at this time. Assume I am patient and I get a DocumentReference which contains my x-ray images. I will not be able to access my x-ray images after certain time. Is that true?

[neharastogi]

yeah, that is true. But are we expected to make sure that the link works forever?

[yunwwang]

I am trying to understand this use case.

Another question. "url like expires and signature will change every time the url is generated". This url generated when the resource (DocumentReference or DiagnosticReport) is created. Is that correct? Or say, when a client request same DocumentReference resource several times, does the client get the same url or different url each time?

[neharastogi]

It is the url that is generated when the client requests DocumentReference or DiagnosticReport so it will change with every request.

[arscan]

Hi @neharastogi --

There is language in the US Core IG that specifically states that the URLs need to be the same, which effectively prevents you from generating these URLs dynamically:

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. Exposing the content in this manner guarantees the client will receive all the clinical information available for a patient and can easily identify the duplicate data.

It is true that having the exact same URL makes it easier for apps to determine that they do not need to re-download the same content. The language has been carried through US Core v5 -- if it had been removed then perhaps we could argue that it was a technical correction and should be applied to US Core v3.1.1, but that isn't the case.

I asked the community about the language in US Core, and if they considered that this blocks use of these types of services, but haven't gotten a response back yet. See: https://chat.fhir.org/#narrow/stream/179190-united-states/topic/Clinical.20Notes.20Attachments.20and.20Pre-signed.20.2F.20Capability.20URLs/near/291374815

Also, it isn't clear if pre-signed URLs / capability URLs are allowed for certification in this context, since this isn't using OAuth 2.0 bearer tokens issued via a SMART App Launch conformant authorization. Having said that though, ONC did recently approve use of pre-signed URLs (as an acceptable alternative to using bearer tokens) in the context of Bulk Data attachments, and perhaps they would allow them in this case as well if asked. As stated in the CCG:

Health IT Modules may use access control schemes other than OAuth 2.0 for controlling access to the file server, such as capability URLs. The HL7 FHIR-I Work Group has documented expectations for the use of capability URLs with the Bulk Data Access IG on the HL7 confluence website. For purposes of Certification testing, Health IT Modules will be tested for the ability to share bulk data files either using OAuth 2.0 bearer tokens or via capability URLs accessible without preconditions or additional steps.

Note that this language very clearly scoped to within Backend Services / Bulk Data, and not attachments via the Single Patient API / US Core. Backend Services / Bulk Data specifically says that these types of URLs are ok, which US Core does not.

So I don't think we can change the test unless ONC says its ok to ignore that line from US Core and explicitly allow pre-signed URLs / Capabilty URLs for Single Patient API attachments (and not just Bulk Data files). If you'd like to pursue this could you post a "ONC Health IT Certification" Question to ONC on their feedback portal?

Or if we've misinterpreted the problem, let me know!

[claudia-flatiron]

@arscan, please keep us updated with any additional updates from the zulip chat. Thanks, Claudia

[yunwwang]

@claudia-flatiron

I don't see any new post on the zulip thread during the last two weeks. Have you submitted a feedback to ONC?

[claudia-flatiron]

I think we found a workaround. Thank you, we can close this issue.