Technical Specifications > Technical Background

Background

This IG uses several different FHIR based integration methods to provide standard, non-proprietary ways for different systems that participate in electronic referrals (eReferral) and consultations (eConsult) to interoperate with one another.

  • FHIR messaging provides a standard way for a software application to transmit information directly to other trusted applications using a backend FHIR API. In this IG, FHIR Messaging is the basis of Direct Messaging integrations that connect RMS systems and referral networks to one another.

  • The SMART App Launch Framework (SMART on FHIR) provides a standard way for a software application to allow a user to securely launch another "app", with context (user and patient), using FHIR, the OAuth2 Authorization Framework, OpenID Connect and a lightweight web browser based user interface (UI) integration. In this IG, SMART on FHIR is the basis of SMART integrations that allow healthcare practitioners and service providers to access RMS Systems, specialized functionality and corresponding referral networks in a user friendly way.

  • RESTful API provides a standard way for servers to enable interactions to be performed on resources using an HTTP request/response. In this IG, RESTful API is the basis of RESTful FHIR API that allows RMS Systems to search and view operations.

Conventions

This implementation guide uses specific terminology to flag statements that have relevance when evaluating a solution's conformance with the guide:

  • 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.

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
CapabilityStatements Specify the minimum conformance requirements (i.e. Message Definitions and Operations) for the RMSSource and the RMSTarget participating in a Direct Messaging integration.
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.
StructureDefinitions
(Profiles and Extensions)		 Specify use case specific constraints and extensions on the FHIR Resources used within messages.
ValueSets Specify the appropriate values to use within a given coded element within a FHIR Resource (Profile or Extension).

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 formal specifications for Direct Messaging and SMART integrations in this implementation guide.