This page is part of the Hybrid / Intermediary Exchange (v1.0.0: STU1) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions

IG Home Page

Overview

The healthcare ecosystem is a complex one which includes many diverse types of actors including providers, health plans, government agencies, analytics and research, public health, and many others. This ecosystem historically and currently includes intermediaries, such as clearinghouses and health information exchanges, which broker communication and provide additional value-add services for those actors who choose to use them. Many actors have chosen to use intermediaries for the value-add services such as cloud scalability, technical outsourcing, security services, operational support, performance, resilience and protection from various attack vectors.

The purpose of this IG is not to introduce new intermediaries or mandate their use. Instead, the purpose is to recognize that intermediaries exist in healthcare and that to scale FHIR we need to account for them. This IG provides a unified model that supports both point-to-point interoperability without intermediaries and one in which one or more intermediaries exist. This model does not put any additional burden on the initiating actor to determine if an intermediary is present or not. The initiating actor’s request and standards-based interaction is the same in either scenario. Supporting the hybrid environment is key to the success of scaling FHIR across the ecosystem.

This implementation guide provides guidance for enabling FHIR REST interactions across one or more intermediaries using a passive approach. A passive approach is one in which the intermediary is ‘passing through’ the interaction and the requesting actor is not necessarily aware of the presence of the intermediary. Intermediaries in this context are organizations such as clearinghouses, health information exchanges, and similar entities. We recognize that there are ‘active’ intermediary use cases (TEF QHIN, aggregation services, record locator, etc.) which will be handled in future IGs.

The guide supports exchanges where the client and destination FHIR server interact with the same steps, content and responsibilities as in a direct connection–while enabling the destination to “sit behind” an intermediary that can provide value-add services such as cloud-scale technical infrastructure, support services, denial of service protection, and business/operational onboarding.

This version of the IG uses a pattern similar to that of a reverse proxy, where the intermediary server is positioned in front of one or more destination FHIR web servers, brokering requests from originating systems and forwarding them to the appropriate destinations. Future versions of the IG may expand with additional characteristics beyond that pattern.

• Example actors for the initial IG include organizations such clinics, providers, hospitals, payers, etc. These actors may be originators of a RESTful request or the destination system for the request.
• Example intermediaries for the initial IG include organizations such as clearinghouses (i.e., Change, Availity) and HIEs ( i.e., eHealth Exchange).

Potential applications of this initial IG include use by implementers of payer/provider use cases such as the Da Vinci value-based care use case in which intermediaries may bridge connectivity between actors. Other HL7 accelerators (CARIN, Gravity, etc.) are developing disparate actor use cases in which intermediaries may be involved.

The community recognizes that direct point-to-point RESTful interaction is a primary interaction pattern. However, we also recognize that intermediaries play important roles for some healthcare actors and having a set of best practices so that we don’t put additional burdens on the client actors is key to running FHIR at scale. This is called the ‘hybrid’ model approach and this IG documents a set of best practices to enable connectivity both in point-to-point and intermediary-facilitated exchange without the client actor needing to have knowledge of what model is executing.

Background

As the range of healthcare actors using FHIR has grown, so has the need to route exchanges across intermediaries such as clearinghouses, HIEs, national networks, and others. An example of this scenario is the situation in which a payer uses a clearinghouse intermediary as their ‘gateway’ for receiving FHIR requests.

Stakeholders use intermediaries for technical, operational and business reasons. The intermediary model was adopted by many payer and provider systems with the original X12 transaction set and is expected to continue as FHIR REST API integration evolves. Other networks, including HIEs and national networks, have emerged as brokering intermediaries for document access/exchange, e-prescribing and other purposes, and may also engage in FHIR-based interoperability.

This implementation guide defines conventions for certain classes of FHIR exchanges that involve such intermediaries. It establishes a basic foundation that will be enhanced and built on over time as stakeholders encounter additional needs.

Scope of This Guide

In scope

The implementation guide focuses on exchanges where…

• the originating system may be unaware that its request will be routed through an intermediary to the final destination for processing; from the perspective of the originating system its intended destination is the responding system

  and

• an intermediary accepts the request on the destination’s behalf and then routes it–directly or through another intermediary–to the destination’s system

  and

• the originator and destination have established trust, with participating intermediaries passively conveying resulting tokens or other security artifacts

The guide aims to support all RESTful FHIR interaction types (GET, POST, etc.) within this set of scenarios.

This implementation guide was initially created for US Realm but is certainly open to use anywhere it provides value.

Out of scope of this version of the guide

The guide does not address all intermediary exchange scenarios that exist today, and does not aim to support emerging network needs such as those posed by the Trusted Exchange Framework and Common Agreement (TEFCA). Environments and use cases supported by active intermediaries are recognized as valid, but are not the focus of the initial version of this guide.

Excluded from scope are environments or scenarios where:

• trust is not negotiated between the originating client and the destination. For example, scenarios where the client establishes trust with an intermediary instead of the destination are not supported
• the originating client addresses requests to anything but the destination’s public URL (for example, instead submitting to a different, network-assigned URL representing the destination)
• the destination does not respond using its public FHIR service base URL in elements that reference the destination’s server within returned FHIR resources (for example, populating elements such as fullUrl with a non-public system URL which would require URL rewriting)
• one or more intermediaries rewrite URLs representing the destination server in returned FHIR resources.

In addition, this guide does not provide guidance for the use of FHIR Messaging, which also includes routing features that can be used to exchange message content through intermediaries.

The guide may be expanded to cover additional environments and scenarios in the future.

Solution Features

• Common mechanisms used for many years in healthcare and other industries
• Lightweight
• Works when performing all REST interactions including GET (e.g., for a search or retrieval) ensuring that the intermediary routing can be accomplished even if no FHIR resource is being submitted
• Universally usable, regardless of FHIR content. Resource-type agnostic
• Requires no special handling by the originator; the originating system is unaware that an intermediary will play a role in routing the request

Content and Organization

The guide is organized into the following sections:

• Use Cases and Roles gives an overview of the guide’s goals and participants.
• Exception Handling describes expectations for conveying destination-reported exceptions as well as those detected by an intermediary.
• Security identifies aspects needed to support the IG’s flows and addtional guidance defined elsewhere.
• Specification describes the solution in detail.

Authors

HL7 FHIR Infrastructure Workgroup
ONC FHIR at Scale Taskforce (FAST) - Exchange Tiger Team
Patrick Murta	PatrickMurta@behavr.com
Frank McKinney	frank.mckinney@pocp.com