Stream: bulk data
Topic: Bulk Data and Consent
Shamil Nizamov (Feb 14 2021 at 21:56):
How does the Bulk Data retrieval process and patient Consents work together?
I.e., if the server wants to exclude resources with PHI but include observations, conditions and all other resources without PHI, there should be some way to inform the client that resources do exist but excluded for the security reason vs. no such resources and what the client gets is all what the server has. Since the server MAY decide to inform the client about that, where does the OperationOutcome go?
PS. I guess there is a typo in the Section 3.8 Enforcing Authorization:
There are several cases where a client might ask for data that the client cannot or will not return:
John Moehrke (Feb 15 2021 at 12:47):
Bulk Data is an interoperability specification, not a solution design. There are many things that Bulk Data specification does not address. It enables some level of security policy thru the smart specification, but this is not intended to be a full design. Privacy tends to need to be addressed as both front-door permit/deny; but also inspection and filtering of the returned results to address residual consent rules.
In other words the answer to your question is, that this is an exercise left to the implementer.
Dan Gottlieb (Feb 15 2021 at 15:38):
@Shamil Thanks for spotting that typo - I fixed it in PR 100.
Dan Gottlieb (Feb 15 2021 at 15:38):
Regarding your question, a server could choose to pass one or more NDJSON files containing one or more OperationOutcome resources indicating data truncation through the (slightly misnamed) error field in the bulk data output manifest. In the draft v1.5 IG, we clarified that this field may be used for information level OOs in addition to errors.
Shamil Nizamov (Feb 16 2021 at 00:40):
John Moehrke said:
Bulk Data is an interoperability specification, not a solution design. There are many things that Bulk Data specification does not address. It enables some level of security policy thru the smart specification, but this is not intended to be a full design. Privacy tends to need to be addressed as both front-door permit/deny; but also inspection and filtering of the returned results to address residual consent rules.
Thank you. It would be great to include this exact wording to the IG.
Dan Gottlieb (Feb 16 2021 at 14:12):
This language currently in the IG seems pretty close: http://build.fhir.org/ig/HL7/bulk-data/export.html#security-considerations
Dan Gottlieb (Feb 16 2021 at 14:12):
"Data access control obligations can be met with a combination of in-band restrictions such as OAuth scopes, and out-of-band restrictions, where servers limit the data returned to a specific client in accordance with local considerations (e.g. policies or regulations). For example, some clients are authorized to access sensitive mental health information and some aren’t; this authorization is defined out-of-band, but when a client requests a full data set, filtering is automatically applied by the server, restricting the data that the client receives."
Last updated: Apr 12 2022 at 19:14 UTC
