Development Approach and Rationale

The development of CA:FeX was driven by the need to modernize health information exchange in Canada and align with global interoperability best practices, while addressing the specific needs of local implementers. Where possible, existing IHE profiles that align with CA:FeX use cases and requirements were adopted directly. In other cases, localization was required where legacy profiles did not fully meet Canadian requirements or needed refinement to better support implementation in the Canadian context.

Assessment of Existing Standards

A review of legacy IHE profiles for document exchange revealed that existing guidance is largely designed for non-FHIR-based infrastructures or supports only limited use of FHIR resources. As the Canadian market moves toward modern, RESTful FHIR exchanges, these legacy profiles do not fully address emerging requirements. The following two IHE profiles were considered during the development of CA:FeX, along with a summary of their limitations:

• Cross-Enterprise Document Sharing (XDS) is an IHE profile that defines a standards-based approach for document sharing within non-FHIR infrastructures. While XDS was considered during the development of CA:FeX, it is not included as an option in the Reference Architecture. This decision reflects the Canadian landscape’s preference for adopting more modern, FHIR-based exchange approaches.

• Mobile Access to Health Documents (MHD): is an IHE profile that uses the FHIR standard to enable document exchange, including optional support for acting as a proxy to XDS-based systems. MHD leverages FHIR resources such as List and DocumentReference to allow clients to locate and retrieve documents in a standardized way. To maintain independence from underlying storage infrastructures, whether based on XDS, FHIR, or other systems, the profile constrains the use of these FHIR resources to ensure consistent behavior. MHD specifies a multi-step retrieval process (query List, then DocumentReference, then retrieve the document), which may not align with all future implementation patterns.

Clinical systems in the U.S. market are generally more familiar with MHD-like patterns for exchanging C-CDAs over FHIR, largely due to the widespread adoption of XDS infrastructure. Many organizations that had previously invested in XDS chose to implement a FHIR façade to enable C-CDA retrieval, using MHD and related IHE profiles as the enabling mechanism. As a result, these systems are now exploring how to extend their existing configurations to support the search and retrieval of other types of documents in a similar fashion.

Systems serving non-U.S. markets, or newly developed solutions built natively on FHIR for document exchange, may lack the historical context that would otherwise prompt investment in supporting advanced search capabilities. Recently, new FHIR operations have been introduced that offer more lightweight alternatives, potentially reducing the effort required to enable richer search functionality. However, these emerging patterns are still evolving, and their applicability within the Canadian market has yet to be fully assessed.

Market Scan and Feedback from Early Implementers

Recognizing the limitations of existing IHE profiles, a market scan was conducted to evaluate patterns used in current RESTful FHIR implementation guides (e.g., US Core, IPA, PACIO, IPS). Insights from this review, combined with feedback from the Canadian implementer community, directly informed the development of the initial release of the Canadian FHIR Exchange (CA:FeX) Specification.

A key motivation behind CA:FeX is to address gaps faced by “FHIR-first” implementers when working with existing document exchange standards such as MHD and XDS. One of the central challenges is finding the right balance between enabling effective, consistent search patterns and minimizing the overhead of generating supplementary metadata (e.g., DocumentReference) required for more targeted discovery.

Feedback from Canadian implementers highlighted the following needs:

• While profiles like MHD provide useful functionality, they introduce additional steps that may not be necessary in all scenarios.
• Simpler patterns for submitting, searching, and retrieving FHIR documents and resources would better support adoption and interoperability.
• Flexibility is essential, as not all systems require the same level of metadata detail or multi-step discovery workflows.