FHIR Artifacts > Structure Definition: Communication Profile
Structure Definition: Communication Profile
Canonical URL:http://ehealthontario.ca/fhir/StructureDefinition/ca-on-eReferral-profile-Communication
Simplifier project page: Communication
Derived from: Communication (CA:eReC)
Base FHIR from: Communication(R4)
Formal Views of Profile Content
Description of Profiles, Differentials, Snapshots and how the different presentations work
Differential View
| EReferralCommunication (Communication) | http://fhir.infoway-inforoute.ca/io/CA-eReC/StructureDefinition/CA-eReC-Communication | ||
| meta | S | 1.. | |
| profile | S | 1.. | |
| identifier | S | ||
| system | S | 1.. | |
| value | S | 1.. | |
| instantiatesCanonical | ..1 | ||
| instantiatesUri | ..1 | ||
| basedOn | S | ..1 | Reference(EReferralServiceRequest) |
| reference | S | ||
| partOf | ..1 | ||
| inResponseTo | S | ||
| status | S | ||
| category | S | Binding | |
| coding | Binding | ||
| system | 1.. | ||
| code | 1.. | ||
| display | 1.. | ||
| priority | Binding | ||
| medium | ..1 | ||
| subject | S | Reference(EReferralPatient) | |
| reference | S | ||
| identifier | S | ||
| system | S | ||
| value | S | ||
| topic | |||
| coding | |||
| code | ..0 | ||
| userSelected | ..0 | ||
| about | ..1 | ||
| sent | S | ||
| received | S | ||
| recipient | Reference(HealthcareService | Organization | Patient | Practitioner | PractitionerRole) | ||
| sender | S | Reference(EReferralPractitionerRole | Endpoint) | |
| reference | S | 1.. | |
| identifier | S | ||
| system | S | ||
| value | S | ||
| reasonCode | ..1 | ||
| reasonReference | ..1 | ||
| payload | S | ||
| content[x] | S | ||
| contentAttachment | Attachment | ||
| contentReference | Reference(EReferralDocumentReference) | ||
| contentString | string | ||
| note | |||
| author[x] | |||
| authorString | string |
Hybrid View
| EReferralCommunication (Communication) | http://fhir.infoway-inforoute.ca/io/CA-eReC/StructureDefinition/CA-eReC-Communication | ||
| meta | S | 1.. | |
| profile | S | 1.. | |
| identifier | S | ||
| system | S | 1.. | |
| value | S | 1.. | |
| instantiatesCanonical | ..1 | ||
| instantiatesUri | ..1 | ||
| basedOn | S | ..1 | Reference(EReferralServiceRequest) |
| reference | S | ||
| partOf | ..1 | ||
| inResponseTo | S | ||
| status | S | ||
| category | S | Binding | |
| coding | Binding | ||
| system | 1.. | ||
| code | 1.. | ||
| display | 1.. | ||
| priority | Binding | ||
| medium | ..1 | ||
| subject | S | Reference(EReferralPatient) | |
| reference | S | ||
| identifier | S | ||
| system | S | ||
| value | S | ||
| topic | |||
| coding | |||
| code | ..0 | ||
| userSelected | ..0 | ||
| about | ..1 | ||
| sent | S | ||
| received | S | ||
| recipient | Reference(HealthcareService | Organization | Patient | Practitioner | PractitionerRole) | ||
| sender | S | Reference(EReferralPractitionerRole | Endpoint) | |
| reference | S | 1.. | |
| identifier | S | ||
| system | S | ||
| value | S | ||
| reasonCode | ..1 | ||
| reasonReference | ..1 | ||
| payload | S | ||
| content[x] | S | ||
| contentAttachment | Attachment | ||
| contentReference | Reference(EReferralDocumentReference) | ||
| contentString | string | ||
| note | |||
| author[x] | |||
| authorString | string |
Snapshot View
| EReferralCommunication (Communication) | http://fhir.infoway-inforoute.ca/io/CA-eReC/StructureDefinition/CA-eReC-Communication | ||
| meta | S | 1.. | |
| profile | S | 1.. | |
| identifier | S | ||
| system | S | 1.. | |
| value | S | 1.. | |
| instantiatesCanonical | ..1 | ||
| instantiatesUri | ..1 | ||
| basedOn | S | ..1 | Reference(EReferralServiceRequest) |
| reference | S | ||
| partOf | ..1 | ||
| inResponseTo | S | ||
| status | S | ||
| category | S | Binding | |
| coding | Binding | ||
| system | 1.. | ||
| code | 1.. | ||
| display | 1.. | ||
| priority | Binding | ||
| medium | ..1 | ||
| subject | S | Reference(EReferralPatient) | |
| reference | S | ||
| identifier | S | ||
| system | S | ||
| value | S | ||
| topic | |||
| coding | |||
| code | ..0 | ||
| userSelected | ..0 | ||
| about | ..1 | ||
| sent | S | ||
| received | S | ||
| recipient | Reference(HealthcareService | Organization | Patient | Practitioner | PractitionerRole) | ||
| sender | S | Reference(EReferralPractitionerRole | Endpoint) | |
| reference | S | 1.. | |
| identifier | S | ||
| system | S | ||
| value | S | ||
| reasonCode | ..1 | ||
| reasonReference | ..1 | ||
| payload | S | ||
| content[x] | S | ||
| contentAttachment | Attachment | ||
| contentReference | Reference(EReferralDocumentReference) | ||
| contentString | string | ||
| note | |||
| author[x] | |||
| authorString | string |
Table View
| Communication | .. | |
| Communication.meta | 1.. | |
| Communication.meta.profile | 1.. | |
| Communication.identifier | .. | |
| Communication.identifier.system | 1.. | |
| Communication.identifier.value | 1.. | |
| Communication.instantiatesCanonical | ..1 | |
| Communication.instantiatesUri | ..1 | |
| Communication.basedOn | Reference(EReferralServiceRequest) | ..1 |
| Communication.basedOn.reference | .. | |
| Communication.partOf | ..1 | |
| Communication.inResponseTo | .. | |
| Communication.status | .. | |
| Communication.category | .. | |
| Communication.category.coding | .. | |
| Communication.category.coding.system | 1.. | |
| Communication.category.coding.code | 1.. | |
| Communication.category.coding.display | 1.. | |
| Communication.priority | .. | |
| Communication.medium | ..1 | |
| Communication.subject | Reference(EReferralPatient) | .. |
| Communication.subject.reference | .. | |
| Communication.subject.identifier | .. | |
| Communication.subject.identifier.system | .. | |
| Communication.subject.identifier.value | .. | |
| Communication.topic | .. | |
| Communication.topic.coding | .. | |
| Communication.topic.coding.code | ..0 | |
| Communication.topic.coding.userSelected | ..0 | |
| Communication.about | ..1 | |
| Communication.sent | .. | |
| Communication.received | .. | |
| Communication.recipient | Reference(HealthcareService | Organization | Patient | Practitioner | PractitionerRole) | .. |
| Communication.sender | Reference(EReferralPractitionerRole | Endpoint) | .. |
| Communication.sender.reference | 1.. | |
| Communication.sender.identifier | .. | |
| Communication.sender.identifier.system | .. | |
| Communication.sender.identifier.value | .. | |
| Communication.reasonCode | ..1 | |
| Communication.reasonReference | ..1 | |
| Communication.payload | .. | |
| Communication.payload.content[x] | Attachment | Reference(EReferralDocumentReference) | string | .. |
| Communication.note | .. | |
| Communication.note.author[x] | string | .. |
JSON View
Usage
The Communication Resource is used in this IG to provide bidirectional communication between two systems and their users. The Communication resource can be used to ask questions about a referral, to request information or to provide information. It may also be used by the central systems, such as the PCCG, to convey error information related to the delivery of messages to downstream systems.
Although the Communication resource has the ability to carry attachments as .payload.content, it SHALL NOT be used to attach .supportingInfo to a ServiceRequest. (Use the Document Reference resource for this purpose.)
PCCG use of Communication to Notify of Downstream Delivery Errors In situations where a RMS-S communicates directly with a RMS-T, the RMS-S is immediately aware of any message delivery issues via HTTP responses (e.g., 404 Not Fount, 500 Internal Server Error, etc.). With PCCG integration, this process is asynchronous - the RMS-S receives a HTTP 200 response from the PCCG prior to the PCCG sending the message to the RMS-T. If the RMS-T does not accept the message, then the PCCG must relay that information back to the RMS-S. This is down via the 'send-communication-from-provider' message. An example communication payload with error information can be found here - A(n) Connectivity Issue message.
Using Communication to Indicate a Submitted Referral was Rerouted An example of this is when a the Provincial Care Coordination Gateway (PCCG) redirects a referral to a Central Intake Hub. This could occur when a submitted referral must go through a central intake pathway. Communication could be sent from the PCCG to the RMS Source as follows:
- Communication.topic.text="Service Request Routing Notice"
- Communication.note.text=[text detailing which service request was routed to a Central Intake Hub and why]
Notes
.id
- used to uniquely identify the resource
- if a persistent identity for the resource is not available to use when constructing a message Bundle for transmission via Direct Messaging, a UUID SHOULD be used in this element (with a corresponding value in
Bundle.entry.fullUrl)
.meta.profile
- used to declare conformance to this profile
- populate with a fixed value:
http://ehealthontario.ca/fhir/StructureDefinition/ca-on-eReferral-profile-Communication|1.2.3
.basedOn
- used to associate the Communication with the ServiceRequest
- SHALL be populated with a reference to the ServiceRequest being performed
- if the Communication is being transmitted via messaging, the referenced ServiceRequest resource SHALL be included in the message as a
Bundle.entry - NOTE: this element will reference multiple ServiceRequests in situations where the Communication relates to a requisition vs a single request, see business rules for more information
.inResponseTo
- indicates that the Communication is a response to another Communication and creates an association with the prior
- populate with
Communication.idfrom the Communication being responded to - where a Communication is part of a converstation, implementers SHOULD include both the Communication in
MessageHeader.focusand the one it is.inResponseToas Bundle entries to allow them to be correctly associated with one another on the receiving system (others further up the chain MAY be omitted on the assumption that any necessary associations between Communications have already been made)
.status
- SHOULD be populated with the value "completed" when it is submitted via Direct Messaging
.category
- used to indicate the category of Communication
- use of values
- "gen" when sending general communications
- "plan" when sending plan of care on service completion
.priority
- MAY be used to indicate the priority of the Communication
- typically populated with "routine"
.subject
- used to associate a Communication with the patient is about
- SHOULD NOT be populated for general Communications that are about the ServiceRequest, not the patient
- if populated, it SHALL reference the Patient in
ServiceRequest.subject(e.g.: where theCommunication.categoryis "plan")
.topic.text
- MAY be used to describe the purpose or content of the Communication (coding is not supported)
.sent
- populate with the time when the Communication was sent
.received
- MAY be populated by the receiver with the time the Communication was received
- SHALL NOT be populated in the Communication in
MessageHeader.focuson the "add-communication" event
.recipient
- typically not used (conceptually the ServiceRequest is the recipient)
.sender
- used to identify the person who sent the messaging (e.g.: when rendering a conversation between individuals for display in the receiving system)
- SHALL be populated with a reference to the PractionerRole of the person sending the communication
- if the Communication is being transmitted via messaging, the referenced PractionerRole resource SHALL be included in the message as a
Bundle.entry
.payload.content
the content of the Communication
business rules:
- there SHALL NOT be more than one instance of
.payload.contentStringper Communication instance - there MAY be multiple instances of
.payload.contentAttachmentper Communication instance
- there SHALL NOT be more than one instance of
expected use:
- when sendng JUST a text message, send a single
.payload.contentString - when sendng JUST an attachment, send a single
.payload.contentAttachment - when sending a text message with attachments, send multiple instances of
.payload- one with the message (
.payload.contentString) - one for each attachment (
.payload.contentAttachment)
- one with the message (
For eConsult:
- use the above business rules and expected use for sending communication between referrers and receipients
- for adding notes use
payload.contentAttachment
- when sendng JUST a text message, send a single
NOTE: although sending base64 encoded .payload.contentAttachment.data is supported, implementers of Direct Messaging SHOULD make binary attachments be made available to retrieve from a server using a .payload.contentAttachment.url to reduce message sizes