DRAFT - The specification is currently in development and subject to significant change. It is not ready for limited roll-out or production level use.
Messaging Events
MessageDefinitions are referenced within CapabilityStatements within this IG to define the conformance requirements for different systems.
Note: Links to MessageDefinitions are currently provided on pages with an overview of the bundle.
| Event | Payload | Source | Description | Transaction ID |
|---|---|---|---|---|
| add-service-request | MessageBundle - ServiceRequest (CA:eReC) | eReC Requester | Request that a new ServiceRequest be performed on the eReC Performer | eReCm-1 |
| revoke-service-request | MessageBundle - ServiceRequest (CA:eReC) | eReC Requester | To request that a ServiceRequest be terminated and the receiving system should follow all processes around revoking the referral | eReCm-5 |
| notify-add-service-record | MessageBundle - ServiceRequest (CA:eReC) | eReC Informer | Notify eReC Recipient systems that a new Service Record has been created | eReCm-2 |
| notify-update-service-record | MessageBundle - ServiceRequest (CA:eReC) | eReC Informer | Notify eReC Recipient systems that an existing Service Record has been updated | eReCm-11 |
| notify-update-service-request | MessageBundle - ServiceRequest (CA:eReC) | eReC Requester | Notify systems that a ServiceRequest or its status has been updated | eReCm-3 |
| notify-data-correction | MessageBundle - ServiceRequest (CA:eReC) | eReC Performer | Notify systems that the eReC Performer has corrected information in a ServiceRequest or related resource | eReCm-4 |
| notify-add-process-request | MessageBundle - Task (CA:eReC) | eReC Performer | Notify systems that a Process Request Task has been created to perform a ServiceRequest | eReCm-6 |
| notify-update-process-request | MessageBundle - Task (CA:eReC) | eReC Performer | Notify systems that a Process Request Task, its status or related information has changed | eReCm-7 |
| notify-add-appointment | MessageBundle - Appointment (CA:eReC) | eReC Performer | Notify systems that an appointment has been created in response to a ServiceRequest | eReCm-8 |
| send-communication-from-requester | MessageBundle - Communication (CA:eReC) | eReC Requester | To send a question or additional information about a ServiceRequest from eReC Source to eReC Target. | eReCm-9 |
| send-communication-from-provider | MessageBundle - Communication (CA:eReC) | eReC Performer | To send a question or additional information about a ServiceRequest from eReC Target to eReC Source. | eReCm-10 |
MessageBundle - Appointment (CA:eReC)
MessageDefinition
An Appointment SHALL be the focus of messages corresponding to the following events:
| Event | Category | Purpose | Allowed Responses | Response Situation |
|---|---|---|---|---|
| notify-add-appointment | notification | To notify systems that an appointment has been created in response to a ServiceRequest. |
Message Bundle: Appointment
Description
Entries in the message Bundle for these business events will be determined by the content of the ServiceRequest the Appointment is based on which, minimally, SHALL include:
- a MessageHeader
- an Appointment referenced in
MessageHeader.focus - PractitionerRole(s) referenced in
MessageHeader.authorSHALL reference an Organization, Location, and/or Practitioner
The ServiceRequest the Appointment is based on SHALL either be referenced or included in the Bundle. If it is included in the Bundle, then the Bundle SHALL include:
- the Patient who is the subject of the ServiceRequest (
ServiceRequest.subject) - PractitionerRole(s) referenced in
ServiceRequest.requesterand the requestedServiceRequest.performerwhere each SHALL reference an Organization, Location, and/or Practitioner
Note:
To enable conformance testing against the requirements of this IG, the requirements summarized above are formally specified as contraints within Resource Profiles in this IG. Implementers are strongly encouraged to become familiar with these formal specifications and to rely on them as the source of truth.
MessageBundle - Communication (CA:eReC)
MessageDefinition
A Communication resource SHALL be the focus of messages corresponding to the following events:
| Event | Category | Purpose | Allowed Responses | Response Situation |
|---|---|---|---|---|
| send-communication-from-requester | consequence | To send a question or additional information about a ServiceRequest from eReC Requester to eReC Performer. | ||
| send-communication-from-provider | consequence | To send a question or additional information about a ServiceRequest from eReC Performer to eReC Requester. |
Message Bundle: Communication
Description
Entries in the message Bundle for these business events will be determined by the content of the ServiceRequest the Communication is based on which, minimally, SHALL include:
- a MessageHeader
- a Communication referenced in
MessageHeader.focus - PractitionerRole(s) referenced in
MessageHeader.authorSHALL reference an Organization, Location, and/or Practitioner
The ServiceRequest the Appointment is based on SHALL either be referenced or included in the Bundle. If it is included in the Bundle, then the Bundle SHALL include:
- the Patient who is the subject of the ServiceRequest (
ServiceRequest.subject) - PractitionerRole(s) referenced in
ServiceRequest.requesterand the requestedServiceRequest.performerwhere each SHALL reference an Organization, Location, and/or Practitioner
Note:
To enable conformance testing against the requirements of this IG, the requirements summarized above are formally specified as constraints within Resource Profiles in this IG. Implementers are strongly encouraged to become familiar with these formal specifications and to rely on them as the source of truth.
MessageBundle - ServiceRequest (CA:eReC)
This bundle provides instructions on serviceRequests can be sent as part of an eReferral.
MessageDefinition
A ServiceRequest SHALL be the focus of messages corresponding to the following events:
| Event | Category | Purpose | Allowed Responses | Response Situation |
|---|---|---|---|---|
| add-service-request | consequence | To request that a ServiceRequest created on the eReC Requester be performed on an eReC Performer. | notify-add-process-request | When the request is successfully processed, a 'process-request' Task with status SHALL be returned to the requester. |
| notify-add-service-record | notification | To notify eReC Recipient systems that a new Service Record has been created. | ||
| notify-update-service-record | notification | To notify eReC Recipient systems that an existing Service Record has been updated. | ||
| revoke-service-request | consequence | To request that all information related to a ServiceRequest terminated on the eReC Requester be removed. | notify-update-process-request | When the request has been successfully processed, a 'process-request' Task with status 'cancelled' SHOULD be returned to the requester. |
| notify-update-service-request | notification | To notify systems that a ServiceRequest or its status has been updated. | ||
| notify-data-correction | notification | To notify systems that information in a ServiceRequest or related resource has been corrected on the eReC Performer. | notify-update-service-request | When the request is successfully processed, any update to the ServiceRequest or status MAY be sent to the performer. |
Message Bundle: ServiceRequest
Description
Entries in the message Bundle for these business events will be determined by the content of the ServiceRequest which, minimally, SHALL include:
- a MessageHeader
- the ServiceRequest(s) referenced in
MessageHeader.focus - the Patient who is the subject of the ServiceRequest (
ServiceRequest.subject) - PractitionerRole(s) referenced in
MessageHeader.author,ServiceRequest.requester, the requestedServiceRequest.performerwhere, each SHALL reference an Organization, Location, and/or Practitioner - references to other
ServiceRequest.supportingInfowhere needed
ServiceRequest Bundles MAY contain multiple ServiceRequests
Note:
To enable conformance testing against the requirements of this IG, the requirements summarized above are formally specified as constraints within Resource Profiles in this IG. Implementers are strongly encouraged to become familiar with these formal specifications and to rely on them as the source of truth.
MessageBundle - Task (CA:eReC)
MessageDefinition
A Task SHALL be the focus of messages corresponding to the following events:
| Event | Category | Purpose | Allowed Responses | Response Situation |
|---|---|---|---|---|
| notify-add-process-request1 | notification | To notify systems that an eReC Target has created a Task for a user to perform a ServiceRequest. | ||
| notify-update-process-request1,2 | notification | To notify systems that work has been performed in response to a ServiceRequest and that the Task, its status or related information has changed. |
1 'process-request' Tasks are identified with Task.code 'process-request'
2 in cases where discreet events are not defined in this IG, implementers SHOULD use the notify-update-process-request event to share information about actions the Performer has planned or taken in response to the ServiceRequest. In these cases, a message MAY include more than one MessageHeader.focus to convey information about both the 'process-request' Task's status and any additional resource(s) added or updated.
Message Bundle: Task
Description
Entries in the message Bundle for these business events will be determined by the content of the ServiceRequest the Task is based on which, minimally, SHALL include:
- a MessageHeader
- a Task referenced in
MessageHeader.focus - PractitionerRole(s) referenced in
MessageHeader.authorSHALL reference an Organization, Location, and/or Practitioner
The ServiceRequest the Task is based on SHALL either be referenced or included in the Bundle. If it is included in the Bundle, then the Bundle SHALL include:
- the Patient who is the subject of the ServiceRequest (
ServiceRequest.subject) - PractitionerRole(s) referenced in
ServiceRequest.requesterand the requestedServiceRequest.performerwhere each SHALL reference an Organization, Location, and/or Practitioner
Note:
To enable conformance testing against the requirements of this IG, the requirements above are formally specified within the Resource Profiles published in this IG. Implementers are strongly encouraged to become familiar with these formal specifications and rely on them as the source of truth.