Stream: smart
Topic: SMART on FHIR with Document Bundles
Corey Spears (Sep 07 2021 at 21:10):
US Core has a DocumentReference profile which mentions that the server can support content.url which may be a reference to a document Bundle on the server. Using SMART on FHIR, how are server systems connecting a document bundle with a particular patient to make sure an authenticated patient gets access to their and only their Bundle resources?
John Moehrke (Sep 07 2021 at 21:15):
presumably that is a local authorization problem to be handled on the server.. There are mechanisms where the Binary can be found in the DocumentReference, and thus given the same access needs as the DocumentReference. There is also a Binary.securityContext that can explicitly point at the DocumentReference. And there is also the Binary.meta.security tags that could be used.... BUT all that said, it seems this is a problem for the server and the policies the server is expected to enforce to address.
Corey Spears (Sep 07 2021 at 21:26):
OK, So there is not a common means that servers are using to support this? Is this something that should be raised or defined in IGs or should it be left up to the implementations? I am curious how US Core implementers are managing this today.
Thought I would ask here before asking the implementers stream. Any implementers or other here that can share their experience?
Michele Mottini (Sep 07 2021 at 23:25):
Never saw a server returning a FHIR Bundle there - usually is a C-CDA
Corey Spears (Sep 08 2021 at 01:03):
So would that be encoded in the DocumentReference resource in content.attachement.data or a content.attachment.url pointer to a Binary? If the latter, I would also like to know how that is handled as I think it would apply similarly to a document Bundle.
Michele Mottini (Sep 08 2021 at 12:12):
I think I always saw pointer to Binary (our server can do either). We just do a GET with an accept header equal to the declared mime type and then store the result.
Priya Mathew (Sep 08 2021 at 22:09):
We're in the same boat, trying to figure out how we implement documentreference - I'll repeat the original question. Using SMART on FHIR, how are server systems connecting a document bundle with a particular patient to make sure an authenticated patient gets access to their and only their documents?
Josh Mandel (Sep 09 2021 at 01:03):
This is below the abstraction barrier for SMART (how does a server maintain any access controls)?
(If you're using FHIR Binary internally, see http://build.fhir.org/binary-definitions.html#Binary.securityContext)
John Moehrke (Sep 09 2021 at 12:20):
In IHE MHD implementation guide it is defined as using content.attachment.url ONLY, and that points at a Binary.
John Moehrke (Sep 09 2021 at 12:22):
http negotiation is allowed to enable the client to indicate they can handle CDA mime-type and thus they get the CDA xml not enclosed in a Binary. Like specified in the FHIR Binary spec - http://hl7.org/fhir/binary.html#rest
John Moehrke (Sep 09 2021 at 12:23):
Binary.securityContext should not be needed. Yes one can move from Binary to the DocumentReference using this, but one can also do the very same by looking for the DocumentReference with an attachment.url that is the Binary id. Having dual pointers is not recommended.
John Moehrke (Sep 09 2021 at 12:25):
however if your server wants to use Binary.securityContext... it certainly can. My point is that given your use-case, it should not be necessary.
John Moehrke (Sep 09 2021 at 12:26):
also, not uncommon for these documents to be simply served as URL endpoints.. not necessarily FHIR REST.
Josh Mandel (Sep 09 2021 at 12:49):
also, not uncommon for these documents to be simply served as URL endpoints.. not necessarily FHIR REST.
Still with the same authz scheme though (otherwise you need a way to tell clients which seem to follow).
John Moehrke (Sep 09 2021 at 12:50):
yes, covered by the same OAuth service.
Priya Mathew (Sep 09 2021 at 17:08):
Thanks @Josh Mandel . You've helped resolve the binary resource retrieval questions I had. I think our use case is different from Corey's. Let me start a new thread with our workflow.
Nancy Lush (Sep 09 2021 at 17:57):
Staying with Corey's original question, we will rephrase again for clarity: When a smart app is running in patient context, the user access is limited to the patient compartment. In the ADI IG, there is a DocumentReference referencing a Bundle. But the Bundle resource is not included in the patient compartment so the patient does not have access to it. The content of this bundle is FHIR resources, not CDAs as might be the case for a binary.
John Moehrke (Sep 09 2021 at 18:00):
I think that is a manufactured problem through the overly constrained view of the Patient Compartment.
John Moehrke (Sep 09 2021 at 18:01):
which that view of Patient Compartment would never be acceptable in a Privacy Policy as it does not recognize that there are many data that don't explicitly have a .patient/.subject element that are actually patient specific.
John Moehrke (Sep 09 2021 at 18:03):
see http://hl7.org/fhir/compartmentdefinition.html
John Moehrke (Sep 09 2021 at 18:03):
The patient compartment includes any resources where the subject of the resource is the patient, and some other resources that are directly linked to resources in the patient compartment
John Moehrke (Sep 09 2021 at 18:05):
I can offer that this is true not just of Binary and Bundle, but also AuditEvent, Provenance, possibly others.
John Moehrke (Sep 09 2021 at 18:05):
also see http://hl7.org/fhir/security.html#SecPrivConsiderations
Cooper Thompson (Sep 09 2021 at 18:36):
Also, in the generic SMART app, the user may NOT have access to the full patient compartment. If the user is a parent access the chart of their teen daughter, then data in the patient compartment like pregnancy and STD test results, sexual history, etc. should not be available to the user.
Even if the user is the patient accessing their own chart, there might be reasons why content in the patient compartment should not be shown (e.g. a provider has individually reviewed a note or lab result as posing potential for self harm and has flagged it to be withheld).
Last updated: Apr 12 2022 at 19:14 UTC
