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 Foundation
Prerequisites
Before reading this formal 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 page 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
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 (Conformant systems SHALL be able to show that they can obtain and send all fields that are marked as "MustSupport").
- Elements without the "MustSupport" flag SHOULD still be populated, however carry no expectations in the Implementation guide.
- Receiver:
- Receivers SHALL be capable of receiving 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.
Notes:
To maximize interoperability, this Implementation Guide uses the "MustSupport" flag to identify elements that implementers must understand in order to properly submit, process, and/or view electronic referrals. Fields that are important for clinical use and clinical safety will also be marked as Must Support.
For Message Support, In Focus Resources, and Supporting Information, these essential elements will be the ones that provide the key information for all use cases.
For Administrative Resources, these essential elements will be the ones that allow systems to uniquely identify the people and organizations involved in the request.
Use Case Specific Guidance on MustSupport
- Elements that are needed for all use cases are marked as "MustSupport".
- Elements that are conditionally "MustSupport" for specific use cases have been marked as "Use Case Support"
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 Resource Profiles 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 Messaging Events 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 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: