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
Scope
CA:FeX defines FHIR document submission, discovery and retrieval patterns for Canadian implementations. Its document-exchange guidance can be used with existing infrastructure or FHIR servers and supports the retained Bundle (A), Metadata (B) and Summary (D) options.
Document exchange
- Bundle Option (A): submit a FHIR document Bundle, search for document Bundles and retrieve a known document Bundle.
- Metadata Option (B): submit a document using
$generate-metadata, fetch DocumentReferences using$docrefand retrieve document content. - Summary Option (D): retrieve a patient summary using
$summary, with PS-CA providing the Canadian patient-summary context.
See Document Exchange for transactions and Capability Statements for the requirements of each actor and option. Reading a Bundle, DocumentReference or Binary instance is part of document exchange; it does not introduce a general requirement to expose the clinical resources contained in a document at separate endpoints.
Out of scope
- Resource-level RESTful exchange (formerly Option C) has moved from CA:FeX to CA Core+. See CA Core+ for the status of that guidance.
- Secure Messaging remains broader architectural context and a possible future area of guidance; it adds no conformance requirements to the current document-exchange options.
The scope may evolve with the interoperability roadmap, Canadian implementation needs and international FHIR developments. Messaging and other exchange paradigms provide broader architectural context and may inform future CA:FeX guidance. They do not add requirements to the current document-exchange options. See FHIR Exchange Paradigms.
Relationship to use cases
CA:FeX provides reusable document-exchange patterns rather than constraining every clinical use case. Specifications such as PS-CA can apply these patterns and add the content and workflow constraints needed for their use cases. The retained A/B/D identifiers, required interactions and operation contracts are unchanged by this realignment.