Communications in FHIR supports many common scenarios and can be used in concert with Bots to enable complex communications workflows. The first step is constructing a Communication FHIR resource. Adherence to the spec, referring to other relevant FHIR resources, and tagging the resource with LOINC, SNOMED or CPT codes can be useful here to aid in reporting, analytics and billing.
There are three top level considerations when designing communications:
- Who (groups or individuals) should be the sender and recipient? (Identities)
- Why was this communication initiated? (References)
- What status is this communication in? (Status/workflow)
Who should receive communications
Communication FHIR resources have a
recipient, and a
subject which should be populated appropriately. When multiple parties are involved Group, CareTeam, or Organization are involved, they can be linked as resources to the Communication resource for record keeping purposes.
A well structured Communication resource serves as the basis for automation through subscriptions and bots. For example, there could be a patient facing application with a messaging interface which creates a Communication FHIR resource with a CareTeam as recipient. A subscription on Communication resources then triggers a bot that sends an email to all
CareTeam.participants notifying them that a new message is available.
Similar workflows can be built up to enable patient SMS, email notifications, or third party messaging integrations through subscriptions and bots.
Why was this communication initiated
Keeping records of the topic and origin of communications. Using codeable concepts with common ontologies like LOINC, SNOMED or CPT as
Communication.topic can be beneficial. Similarly
Communication.encounter can be used to refer to other FHIR resources like AppointmentRequest or DiagnosticReport.
There are special resources for distinct communication types like
CommunicationRequest that may be appropriate in specific contexts.
Media resource is often linked to Communication resources as attachments for images, PDF, documents and the like.
What is the status of this communication
Knowing whether a communication needs a response or follow up aids workflow. In this case
Communication.statusReason are the appropriate fields.
- Communications Features and Fixes on Github includes sample data.