Hybrid / Intermediary Exchange
1.0.0 - STU 1 US

This page is part of the Hybrid / Intermediary Exchange (v1.0.0: STU1) based on FHIR R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Security

Note: This section contains conformance requirements, noted with “SHALL”, “SHOULD” and “MAY”.

Pass-Through Security

The Pass-Through Security approach defines the interaction between the initiator and the destination, with minimal involvement of the intermediary. As described below, it supports this implementation guide’s passive intermediary model. It may also be suitable for other models where the intermediary plays a more active role in serving or modifying the returned content.

  • Note: Additional security models may be defined in future versions of this IG as needed to support expanded intermediary roles

Transport Security

Communication security SHALL conform with the guidelines stated in FHIR Security.

When using TLS:

  • the inbound gateway intermediary SHALL hold the TLS certificate for the destination’s public FHIR service base URL
  • the certificates exchanged by the destination system and any delegated intermediaries SHALL reflect their servers’ private URLs.

Trust Determination

In this exchange model, trust is negotiated or established solely between the originator and destination. The destination SHALL determine whether it trusts the originator or not; any intermediaries involved in the exchange SHALL play a passive, “pass through” role in the process.

Required behavior:

  • security tokens generated by the destination for use by the originator SHALL be forwarded by any intermediaries to the originating client.

Implementers MAY adopt UDAP workflows for client registration, authentication and authorization as described in the HL7 / UDAP Security for Scalable Registration, Authentication, and Authorization FHIR Implementation Guide

Other Security and Privacy Considerations

Implementers of this guide SHOULD follow core FHIR security principles and protect patient privacy as described in the FHIR Security and Privacy Module which:

  • provides guidance related to communication security, authentication, authorization/access control, audit, digital signatures, attachments, labels, narrative, and input validation.
  • describes how to protect a FHIR server through access control and authorization, how to document what permissions a user has granted, and how to keep records about what events have been performed.

The FHIR security specification is available here.