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.