DRAFT - The specification is currently in development and subject to significant change. It is not ready for limited roll-out or production level use.
Technical Background
Conformance Language
This specification uses the conformance verbs SHALL, SHOULD, and MAY as defined in RFC 2119.
- SHALL: indicates requirements that must be met to be conformant with the specification.
- SHOULD: indicates behaviors that are strongly recommended (and which could result in interoperability issues or sub-optimal behavior if not adhered to), but which do not, for this version of the specification, affect the determination of specification conformance.
- MAY: describes optional behaviors that implementers are free to consider but where there is no recommendation for or against adoption.
Must Support Definition
- Sender:
- Elements marked with the "MustSupport" flag SHALL be populated as specified within the profile they belong to if available and appropriate.
- Elements without the "MustSupport" flag SHOULD still be populated, however carry no expectations in the Implementation guide.
- Receiver:
- Receivers SHALL be capable of processing resource instances containing data elements populated with the “MustSupport” flag' without generating an error or causing the application to fail.
- Elements without a “MustSupport” flag in a FHIR response SHOULD still be received without generating an error or causing the application to fail.
- The Receiver SHOULD be capable of displaying “MustSupport” data elements for human use or processing (including, storing them) for multiple events.
Exchanging with Messaging
This implementation SHALL follow synchronous Message Request and Response paradigms. Messages SHALL include only the MessageHeader resource, and any resources directly or indirectly referenced from it.
Exchanging with RESTful API (out-of-scope)
This implementation MAY follow the Single and Multiple Resource exchange framework. Of the CRUD capabilities, the functionality MAY be used to retrieve Patient and Practitioner context information about ServiceRequest being received.
In future iterations of this guide it MAY also be used to retrieve information from a FHIR Server as part of a SMART integration.
Languages supported
JSON (SHALL) and XML (SHOULD).
FHIR Artifacts
This specification makes significant use of FHIR Artifacts to describe the structure and content of the messages to be exchanged as well as the behaviour of the participating systems.
| Artifact Type | Use | Notes |
|---|---|---|
| StructureDefinitions | Specify use case specific constraints and extensions on the FHIR Resources used within messages. | A list of StructureDefinitions can be found on the Artifacts page |
| ValueSets | Specify the appropriate values to use within a given coded element within a FHIR Resource (Profile or Extension). | A list of ValueSets can be found on the Terminology page |
| MessageDefinitions | Specify the message payloads (i.e. the appropriate FHIR Resources) to use to transmit information for a given Event as well as the expected responses. | A list of MessageDefinitions can be found on the Artifacts page |
| CapabilityStatements | Specify the minimum conformance requirements (i.e. Message Definitions and Operations) for the eReC Source and the eReC Target participating in a Direct Messaging integration. | Further refinement/validation of the CapabilityStatements is expected alongside the MessageDefinitions as the use cases and business requirements are finalized. |
Underlying technologies
The integration methods and patterns in this IG are based on the HL7 FHIR standard. As a result, this IG uses terminology, notations and design principles that are specific to FHIR. Readers who are unfamiliar with FHIR are encouraged to read (or at least skim) the following prior to reading the specifications for using the CA:eReC Messaging .
- FHIR overview
- Developer's introduction (or Clinical introduction)
- FHIR messaging
- FHIR data types
- Using codes
- References between resources
- How to read resource & profile definitions
- Base resource
Implementers who are anticipating leveraging the future specifications for using SMART-on-FHIR and FHIR RESTful APIs to exchange eReferral/eConsult content should familiarize themselves with: