Technical Foundations

Pre-requisites for Implementers

Before reading this specification, implementers are encouraged to first familiarize themselves with other key portions of this IG, specifically:

• The Business Context for information about what this IG aims to accomplish including an overview of the business solution and process flow this specification will enable.
• The Technical Background for information about the underlying specifications this IG builds upon including references to sections that implementers should read to establish a necessary foundation to understand the constraints and usage guidance described here.

Technical Background

CA:FeX is a FHIR RESTful exchange specification designed to facilitate interoperability in Canadian healthcare. It supports document and discrete data exchange, as well as extensibility through FHIR Operations, enabling a wide range of data sharing scenarios.

The increasing use of virtual care and digital health tools highlights the urgent need to address barriers to effective digital health, such as information silos, lack of interoperability (including semantic interoperability), constrained value sets, and aging systems. The COVID-19 pandemic has further emphasized the importance of interoperability and secure information sharing.

Canada Health Infoway is facilitating a national effort to improve interoperability in priority areas like secure patient summary and other clinical data sharing. CA:FeX aims to provide early guidance to Canadian implementers, aligning with international standards like IPA and IHE profiles. It addresses the need for modern RESTful API patterns for exchanging documents and patient data, filling the gap for "FHIR-first" implementers who find existing document exchange standards like MHD and XDS challenging. CA:FeX v1.0.0 focused on simple exchange patterns for FHIR Documents, while CA:FeX v2.0.0 DFT expands on this with guidance on search parameters, resource exchange capabilities, and operations.

CA:FeX is positioned to complement existing standards like MHD and XDS, drawing on lessons learned from the pan-Canadian Patient Summary (PS-CA) and international best practices. While CA:FeX can support adaptation for legacy systems, its primary focus is on enabling greenfield RESTful implementations, making it implementation-agnostic and adaptable to various architectural needs.

CA:FeX is a RESTful API Interactions exchange specification designed to facilitate interoperability in Canadian healthcare. It supports:

• Document Exchange: CA:FeX leverages FHIR resources and operations, to enable querying and retrieval of documents from various repositories, including hybrid systems containing both FHIR and non-FHIR documents. This approach allows querying in a single way and returns pointers to document content, wherever it is stored and irrespective of the format (e.g., binary or FHIR-native). FHIR Search Parameters and FHIR Operations have been developed to augment the capabilities of this pattern to more easily get back what was requested and enable the offering of documents in the expected format without having to change the underlying data model / document and lifecycle practices.
• Discrete Data Transactions: CA:FeX supports the exchange of individual FHIR resources. This allows for focused transactions such as retrieving a patient's medication list or allergy information.
• Extensibility through FHIR Operations: CA:FeX utilizes FHIR Operations to abstract complexity and enable multi-step processes through single API calls. This allows implementers to offer streamlined access to functionalities like generating documents on demand.

CA:FeX seeks to harmonize around global interoperability guidance and well-implemented exchange patterns. For this reason, CA:FeX attempts to identify any established international profiles that align to its use cases and requirements, adapting them where necessary to meet Canadian requirements.

Conformance Language

CA:FeX IG makes use of conformance language such as SHALL, SHOULD and MAY to describe the behavior of systems. The meaning of these words shall be interpreted as per the FHIR core specification. Specifically:

• SHALL: An absolute requirement.
• SHOULD: A best practice or recommendation; there may be valid reasons to deviate, but the implications must be understood and carefully weighed.
• MAY: An optional feature or behavior; implementers are free to implement or ignore it.
• SHALL NOT: used to indicate that an element or action is prohibited.

While there are no "Must Support" elements defined in this specification, when CA:FeX states that a system SHALL support a search parameter, operation, or other feature, this means that the system is required to implement the functionality as described in this Implementation Guide.

CA:FeX defines conformance requirements for specific actors and options. See the CA:FeX Actors and Options page for more information on conformance based on the selected actor and options.

Must Support

Since, there are no profiles released in this CA:FeX version, there are no must-support elements guidance or expectations defined in this specification.

Capability Statements

Principles

The following principles are applied when creating the CA:FeX capability statements:

• Start with the capabilities defined in the national health information exchange specifications to:
  • Increase the opportunity for Digital Health / mHealth application reuse across North America
  • Reduce developer / vendor effort to adapt to Canadian requirements
• Identify the commonalities between US Core, IHE QEDm, and IPA, and address the differences in a way to:
  • Avoid any additional constraints not commonly found across similarly scoped guides (unless strictly necessary), and
  • Relax the capabilities wherever appropriate
• Ensure consistency against defined Actors, Options and Transactions

All Capability Statements can be found in Capability Statements.