Visit the HL7 website
Visit the FHIR website

Pan-Canadian FHIR Exchange (CA:FeX) IGuide CI Build

CIBuild   Canada flag
  • Index
  • Home
  • Business Context
    • Scope
    • Development Approach and Rationale
    • Relationship to Other Specifications
    • Use Cases
  • Technical Context
    • Overview
    • FHIR Exchange Paradigms
    • Document Exchange
    • RESTful API Interactions
    • Sequence Diagrams
    • Actor Mapping to Interoperability Specification
    • Security
  • Actor and Conformance Options
    • Technical Actors
    • Actor Options
    • Conformance Requirements
  • FHIR Artifacts
    • Profiles and Extensions
    • Search Parameters
    • Operations
    • Capability Statements
    • Capability Statements - Server
  • Change Log
    • Change Log
    1. Index
    2. Business Context
    3. Relationship to Other Specifications

CI Build - This specification is a draft continuous integration build and is subject to change. It is not ready for limited roll-out or production level use. For a full list of available versions, see the Directory of published versions

Relationship to Other Specifications

CA:FeX defines how FHIR documents are submitted, discovered and retrieved. It does not define clinical content. CA:FeX does not define any profiles, extensions or terminologies of its own. The content being exchanged is defined by other specifications, such as PS-CA.

Pan-Canadian Specifications that Reference CA:FeX

Specification Relationship CA:FeX components used
Pan-Canadian Patient Summary (PS-CA) Exchange pattern for submitting, searching and retrieving a Patient Summary document Option A , Option D ($summary), Option B ($docref)
Pan-Canadian Core FHIR Profile Set (CA Core+) Holds resource-level RESTful exchange (former Option C) from CA:FeX None

Rules for Referencing Specifications

  • Constraints: A referencing specification may require specific options, restrict document types, make optional items required, or select a security mechanism. It shall not relax CA:FeX SHALL requirements or change the meaning of CA:FeX transactions. The referencing specification documents its own constraints.
  • Prerequisite: CA:FeX conformance is not a general prerequisite. It applies only when a referencing specification names CA:FeX as its exchange mechanism and the implementer chooses it. Conformance is per option.
  • Profiles and extensions: CA:FeX defines how documents are exchanged, not what they contain. Profiles and extensions from the referencing specification (for example, PS-CA) define the document content and do not change how CA:FeX transactions work. Standard FHIR rules apply to extensions. If a referencing specification adds its own search parameters or operations, they are part of that specification, not CA:FeX.

Cross-Profile Consideration

Internet User Authorization (IUA) Grouping

The IUA profile provides support for user authentication, app authentication, and authorization decisions. To allow for these features, CA:FeX actors can be grouped with IUA actors.

For the specific Canadian implementation guidance for the IUA profile, refer to the RA v0.2.2 DFT, section IUA - Canadian Implementation Guidance.

If the grouping is in place, an actor from CA:FeX shall implement the required transactions and/or content modules in CA:FeX in addition to all the transactions required for the grouped actor (Column 2).

CA:FeX Actor Actor(s) to be grouped with
Data Source IUA / Authorization Client
Data Recipient IUA / Resource Server
Data Consumer IUA / Authorization Client
Data Responder IUA / Resource Server

The CA:FeX Data Source and Data Consumer actors, when grouped with IUA Authorization Client, shall use Get Access Token [ITI-71] to request the corresponding scope from the IUA Authorization Server.

This enables the CA:FeX actor to submit the corresponding CA:FeX transaction with the combined transaction Incorporate Access Token [ITI-72].

The CA:FeX Data Recipient and Data Responder actors, when grouped with IUA Resource Server, shall require Incorporate Access Token [ITI-72] in all CA:FeX transaction requests, shall enforce the authorization decision in the token, and may further enforce policies beyond those made by the Authorization Server such as consent or business rules.

There are additional security and privacy functionalities enabled by this grouping.

  • Transactions are combined with IUA transactions requiring access tokens
  • There are additional requirements and functionality enabled through scope definitions that are transaction specific.
Actors Transactions IUA/OIDC Scopes
Data Source Submit Data [CA:FeX-1] CAFEX-1
Data Recipient Submit Data [CA:FeX-1] CAFEX-1
Data Consumer Search Data [CA:FeX-2]
Retrieve Data [CA:FeX-3]
CAFEX-2
CAFEX-3
Data Responder Search Data [CA:FeX-2]
Retrieve Data [CA:FeX-3]
CAFEX-2
CAFEX-3

Each scope authorizes the full CA:FeX transaction. This scope implicitly allows for patient-specific CRUD/S operations in line with and supported by the corresponding CA:FeX transaction.

Further scope refinement is allowed in realm or project-specific situations; these scopes would be in addition to the scopes defined here.

IG © based on FHIR R4 | Package project:CA-FeX-Canadian-FHIR-Exchange
Copyright © 2026 Canada Health Infoway. All rights reserved. Terms of Use & License Agreements. Privacy Policy.
HL7® and FHIR® are the registered trademarks of Health Level Seven International