1. Veterans Health Administration
HL7 Workgroup Meetings, Montreal, QC, May 2019
Mohammad Jafari, PhD
VHA Security Architecture – Framework Engineering
Book Zurman Incorporated

2. Privacy-Aware FHIR Bulk Data Transfer
FHIR Connectathon –Bulk Data Transfer
Privacy-Aware FHIR Bulk Data Transfer

3. Request accepted; working on it (HTTP 202)
FHIR Connectathon –Bulk Data Transfer
The Bulk Export Use Case
A Client requests bulk-export of a set of resources from a FHIR server.
The FHIR server accepts and starts fulfilling the request.
The Client can check the status of the request.
Once the results are ready the Client follows the links provided in the results to download the output files.
Client
bulk export request
FHIR Server
Bulk API
Request accepted; working on it (HTTP 202)
How about now?
OK, here you go (HTTP 200)
Get file
File

4. FHIR Connectathon –Bulk Data Transfer
Requirements
Bulk export access permission must be explicitly granted to the Client.
e.g. “read” access permission must not be sufficient for bulk export.
Support for granting bulk access to specific resource types.
e.g. the permission to “bulk export of Immunization resources” is different from the permission to “bulk export MedicationRequest”
Bulk access permission can be granular to specific security labels.
e.g. permission to export only the resources with “Normal” confidentiality.

5. High-Level Flow FHIR Connectathon –Bulk Data Transfer Custodian Org 2
Out of Band:
UMA Protection Flow:
UMA Authz. Flow:
Data Access Flow:
Custodian Org
Set up Bulk Access Policy
(Jurisdictional, Organizational, Consent)
Check Policies 2
Authorization Endpoint
Authorization Server
(OAuth)
Introspection Endpoint
Request for Access Token +
Provide Claims 1
Access Token 3
Introspect Token 5
Requesting Org
Client
OAuth Client
Verify scopes.
Apply labeling filters based on granted scopes 6
Authorization
Service
OAuth Client
FHIR Server
Bulk API
Bulk Export Request + Access Token 4
Modified Bulk Export Request 7
Accepted 9
Accepted 8

6. Detailed Example Permitted Client’s Scopes: Client’s Request:
FHIR Connectathon –Bulk Data Transfer
Detailed Example
Permitted
Client’s Scopes:
Permission to bulk export Immunization resources with any labels.
Client’s Request:
Bulk export every Immunization resource created since

7. Detailed Example In Insufficient_Scopes
FHIR Connectathon –Bulk Data Transfer
Detailed Example
Insufficient_Scopes
Client is only permitted to bulk export resources of type Immunization. In
Client’s Scopes:
Permission to bulk export Normal Immunization resources.
Client’s Request:
Bulk export every resource created since

8. Bulk export every resource created since 2019-04-23.
FHIR Connectathon –Bulk Data Transfer
Detailed Example
Client’s Scopes:
Permission to bulk export every resource except resources labeled as Restricted.
Permitted
Add a filter to client’s query to redact Restricted resources:
*?_security:not=R
Client’s Request:
Bulk export every resource created since

9. Discussion JSON Scopes Redact or Reject? Authorization Reverse Proxy
FHIR Connectathon –Bulk Data Transfer
Discussion
JSON Scopes
Redact or Reject?
Authorization Reverse Proxy
Simpler Flows
Bulk API as Reverse Proxy
Wildcard typeFilters
Thoughts on Bulk API

10. FHIR Connectathon –Bulk Data Transfer
JSON Scopes
Using a JSON instead of opaque strings based on a grammar for model scopes.
Semantics:
Flexible.
Support for granular definitions of scopes:
e.g. resource-type, patient, security label.
Experimental support wildcards and denied scopes.
Implementation
Readily supported in most programming frameworks.
Easier and less error-prone to parse and interpret.
Compatible with UMA permissions.

11. FHIR Connectathon –Bulk Data Transfer
Redact or Reject?
Important design decision: When to reject a request and when to accept it but redact the results. Generally:
Reject when coarse-grained permissions mismatch: e.g. resource type.
Redact when fine-grained permissions mismatch: e.g. security labels.
Rejection in the case of fine-grained mismatch would require the Client to provide very specific permissions needed for the request.
Determining precise permissions could be frustrating or impossible for the Client when permissions are very fine-grained.
Observing patterns of rejection could be privacy-leaking by inference.
e.g. when request is rejected based on security labels could be indicative of the existence of sensitive information.
Redaction in the case coarse-grained mismatch leads to confusing and unexpected results. A rejection gives the Client the chance to fix authorization.
e.g. if the Client asks to export all resource types and some resource types are silently excluded.

12. Authorization Reverse Proxy
FHIR Connectathon –Bulk Data Transfer
Authorization Reverse Proxy
Isolate all FHIR authorization logic in a reverse proxy which monitors requests/responses to/from the FHIR server.
Pros: less coupling, more flexibility, and independence from from specific FHIR servers.
Cons: potential performance overhead.
Introspect token, check scopes.
Can reject the request or modify it to narrow down the results. 2
Authorization
Reverse Proxy
FHIR Server
Client
Client’s Query 1
Modified Client’s Query 3
Modified Server Response 6
Server Response 4
Inspect response.
Can reject the request or modify the response based on scopes. 5

13. Simpler Flows Structured Signed Access Tokens (JWT)
FHIR Connectathon –Bulk Data Transfer
Simpler Flows
Structured Signed Access Tokens (JWT)
No need for introspection.
Potentially encrypted to keep details of granted scopes private from the client.
Pros: simpler flow, less moving pieces, improved performance.
Cons: difficulty of revocation, larger access tokens.

14. Simpler Flows Dedicated Bulk Clients
FHIR Connectathon –Bulk Data Transfer
Simpler Flows
Dedicated Bulk Clients
Locked-Down Scopes at the time of OAuth Client registration.
Issue a fixed long-lasting JWT access token after registration.
No need to request for a new access token regularly.
Pros: much simpler flow, improved performance.
Cons: long-lasting tokens with difficulty of revocation.

15. Convert to FHIR Search queries Aggregate and prepare results
FHIR Connectathon –Bulk Data Transfer
Bulk API as Reverse Proxy
Provide Bulk API support for existing FHIR servers without interfering with the FHIR server.
Pros: less coupling, more flexibility, support for multiple backends.
Cons: performance overhead.
Convert to FHIR Search queries 2
FHIR Server
Bulk API
Reverse Proxy
FHIR Server
Client
Bulk Query 1
Search Queries 3
FHIR Server
Bulk Response 6
Server Responses 4
Aggregate and prepare results 5

16. MedicationRequest?status=active
FHIR Connectathon –Bulk Data Transfer
Wildcard typeFilters
The Bulk API currently supports _typeFilters which further narrow down the type of resources to be exported with type-specific filters, e.g.:
MedicationRequest?status=active
Wildcard typeFilters enable specifying a filter for all the exported resources:
*?_security=N
Facilitates enforcing blanket filters over all the export results.

17. Why not use the existing FHIR concepts and API?
FHIR Connectathon –Bulk Data Transfer
Thoughts on the Bulk Access API
The current specifications define:
A completely new API loosely related to the existing FHIR REST API.
Implementation requires its own data model and backend for keeping track of export requests.
FHIR already defines a comprehensive data model and query API.
Why not use the existing FHIR concepts and API?

18. Thoughts on the Bulk Access API
FHIR Connectathon –Bulk Data Transfer
Thoughts on the Bulk Access API
Define a new FHIR resource, e.g. BulkJob.
Create, Read, Update, Delete using existing FHIR REST API.
Creating a BulkJob can trigger an export or import. The sever can update the resource (e.g. status) once the results are ready.
Use existing FHIR API and backend (e.g. persistence model) for handling these resources.
Other existing FHIR facilities can be used with this resource:
Versioning, Search, Audit, Provenance,
Subscription (i.e. callbacks and webhooks) to help with the async nature of the operation,
even Bulk export!
Less cognitive overhead for implementers.

19. FHIR Connectathon –Bulk Data Transfer
Questions

20. High-Level Flow: JWT Access Token
FHIR Connectathon –Bulk Data Transfer
High-Level Flow: JWT Access Token
Custodian Org
Set up Bulk Access Policy
(Jurisdictional, Organizational, Consent)
Check Policies 2
Authorization Endpoint
Authz Server
(OAuth)
Request for Access Token +
Provide Claims 1
Access Token 3
Requesting Org
Client
OAuth Client
Apply labeling filters based on granted scopes 5
Authorization
Service
FHIR Server
Bulk API
Bulk Export Request + Access Token 4
Modified Bulk Export Request 6
Accepted 8
Accepted 7

21. High-Level Flow: Locked Down Client
FHIR Connectathon –Bulk Data Transfer
High-Level Flow: Locked Down Client
Requesting Org
Custodian Org
Apply labeling filters based on granted scopes 2
Client
Authorization
Service
FHIR Server
Bulk API
Bulk Export Request + Access Token 1
Modified Bulk Export Request 3
Accepted 5
Accepted 4