Overview

The pan-Canadian FHIR Exchange (CA:FeX) is an implementable, testable interoperability specification based on HL7 FHIR Implementation Guides, that defines building blocks to enable creating, consuming and sharing clinical data via FHIR RESTful exchange patterns.

For details, refer to the pan-Canadian FHIR Exchange Interoperability Specifications (CA:FeX v2.1.0 DRAFT-preBallot).

The following are some examples of the benefits of CA:FeX:

• Supports scenarios of health care provider creating, viewing and updating documents using standardized HL7 FHIR operations such as submission, search and retrieval
• Supports safe provision of care in a scheduled or unscheduled medical situation
• Supports transitions of care or transfers of patients across the continuum of care
• Supports coordination and collaboration of a patient’s care

Actors

The actors defined by CA:FeX are described below.

Actor Options

CA:FeX actor options are organized into four options providing implementers with choices that most suit their context and needs, while minimizing implementation details not relevant to them. Implementers may choose to opt into one or more actor option. The table below summarizes the CA:FeX actor options.

Transaction Naming Convention

CA:FeX transactions aim to follow a consistent numbering convention for specific types of data exchange. The table below summarizes the numbering conventions commonly used for different types of transactions (see details in the next section "Actors and Transactions")

For example, CA:FeX-1A likely involves a Submit Data action and CA:FeX-2B involves a Search Data action.

Actors and Transactions

The following diagram provides an overview of the CA:FeX Actors, Transactions and their interactions.

The tables below list the transactions for each actor directly involved in CA:FeX. To claim compliance with CA:FeX, an actor shall support all required transactions (labeled “R”).

Bundle Option (A)

• Submit FHIR Document [CA:FeX-1A] – This transaction performs a FHIR Create interaction to transfer a FHIR Document, typically Bundle of type Composition.
• Search FHIR Document [CA:FeX-2A] – This transaction performs a FHIR Search interaction to obtain FHIR Documents that satisfies a set of parameters.
• Retrieve FHIR Document [CA:FeX-3A] – This transaction performs a FHIR Read interaction to retrieve a FHIR Document.

Metadata Option (B)

• Generate Metadata [CA:FeX-1B] – This transaction performs a $generate-metadata operation to submit a FHIR Document and provides a DocumentReference associated to the submitted document.
• Fetch DocumentReference [CA:FeX-2B] – This transaction performs $docRef operation to obtain DocumentReferences that contain links to FHIR Document or FHIR Binary resources from the Data Responder. Note that other options that could be possible are not recommended in CA:FeX (e.g. DocumentReference embedded documents).
• Retrieve Document [CA:FeX-3C] – This transaction uses /Bundle or /Binary (recommended) endpoints to retrieve data.

Single Resource Option (C)

• Submit Resource [CA:FeX-1C] – This transaction performs a FHIR Create interaction to submit a single FHIR resource.
• Search Resource [CA:FeX-2C] – This transaction performs a FHIR Search interaction to find FHIR resources matching a set of parameters.
• Retrieve Resource [CA:FeX-3C] – This interaction performs a FHIR Read to retrieve a FHIR resource using a known resource ID.

Summary Option (D)

• Retrieve Patient Summary [CA:FeX-3D] – This transaction uses the $summary operation on the Patient FHIR endpoint to retrieve a Patient Summary document.