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:

Derived from: Communication(R4)

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work

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.

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 DocumentReference resource for this purpose.)

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.0.0'

.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.id from the Communication being responded to
• where a Communication is part of a converstation, implementers SHOULD include both the Communication in MessageHeader.focus and the one it is .inResponseTo as 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
  • "rfi" when sending via Direct Messaging "add-rfi" event

.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 the Communication.category is "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.focus on 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.contentString per Communication instance
  • there MAY be multiple instances of .payload.contentAttachment per Communication instance

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

• 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