Profiles & Operations

Resources are the building blocks of the FHIR standard. These resources convey the content of clinical records, identify patients or providers, or otherwise support information exchange between systems. These resources have been developed by numerous working groups at HL7, based on members' experience and subject expertise. The elements defined within FHIR resources are intended to capture and support those elements that 80% of implementers of a given resource are expected to support. Less frequently implemented elements are supported through FHIR's extensibility mechanisms. The list of all available resources in the FHIR R4 standard can be found here.

Operation Resource(s) HTTP verb
Submit Referral ServiceRequest POST
Update Referral ServiceRequest POST
Revoke Referral ServiceRequest POST

Profiles

Following are the 'Profiles' supported by this implementation guide:

Resource Type Description Sample Messages (JSON)
AllergyIntolerance Allergy information JSON
Appointment The Appointment is used to provide information about a planned meeting that may be in the future/past JSON
Bundle The main resource submitted to the target referral system JSON
Communication Provides additional information about the service outcomes. JSON
Condition Primary Diagnosis for referral JSON
Consent Any consent information collected at source JSON
DocumentReference Any additional PDF forms/documents that have to be included as documents. JSON
Location Location includes both incidental locations (a place which is used for healthcare without prior designation or authorization) and dedicated, formally appointed locations. JSON
MessageHeader Provides details for message execution. Identifies the destination and the other of the referral bundle. It can also provide a general reason for referral in case the included ServiceRequest resources are very specific. JSON
OperationOutcome Operation outcomes are sets of error, warning and information messages that provide detailed information about the outcome of an attempted system operation. JSON
Organization Identifies the recipient HCC (PractitionerRole.organization) in the MessageHeader. Could also appear in other PractitionerRole.organization references. JSON
Patient The subject of the referral request JSON
Practitioner Provides the requester identity (PractitionerRole.practitioner). Also, in case the author is not the requester the author reference in the MessageHeader may refer to a second Practitioner resource. JSON
PractitionerRole Defines the requester. Should reference one Practitioner or one Organization resource. Also referenced in other resources. JSON
QuestionnaireResponse A list of nested Questions and Answers items that complement the Service Request order details JSON
ServiceRequest The main payload resource(s) JSON
Task Provides additional status information about the referral and referral update reasons, in case the referral needs to be updated or cancelled by Source JSON

The eReferral message payload has specific composition according to the direction of the message:

  1. eReferralSourceToTargetBundle – the Bundle that supports message payloads created by Referral Source System (RSS) and sent to an endpoint exposed by Referral Target System (RTS):
    1. add-service-request – represents the EventCode used to indicate the RSS has created a new referral
    2. update-service-request - represents the EventCode used to indicate the RSS has updated an existing referral
    3. revoke-service-request - represents the EventCode used to indicate the RSS has cancelled an existing referral

It's composition is depicted below:



It is mandatory that each Bundle message should contain at least one instance of the following resource types: MessageHeader, ServiceRequest, Patient and PractitionerRole.
The bundle can contain multiple ServiceRequest resources, one for each service offering. The ServiceRequest along with the QuestionnaireResponse resource provide most of the service information required to provision the service in CHRIS. Documents, such PDF documents, can be attached to the bundle, if included by the provider at referral time. In this case the document content will be embedded in one or more DocumentReference resources as a base64 encoded binary payload.

  1. eReferralTargetToSourceBundle – the Bundle that supports message payloads created by Referral Target System (RTS) and sent to an endpoint exposed by Referral System System (RTS):
    1. update-service-status – represents the EventCode used to indicate the RTS has updated the status of an existing referral. The status update includes scenarios in which the end user in RTS requires more information or cancels the requested service with an explanation

It's composition is depicted in the diagram below:

Extensions

Following are the Extensions supported by this implementation guide:

Extension Description Download Link
CommunicationBarrier The extension is required to identify if the patient speaks/understands an offical language (english/french), or if she/he does not an interpretor is required. Download XML/JSON
HCNVersionCode An assigned sequence code, uniquely identifying a Health Card issued (or potentially issued) to a Registered Person Download XML/JSON
RoutingOptions This is an extension required for Referral Source Type identification. Only one referral routing object expected. Download XML/JSON
ReferralSourceType The purpose of this extension is to support multiple locations for a requester for family doc or provider. Download XML/JSON
PatientPresentLocation To specify the present location of the patient. Download XML/JSON