FHIR Payer Alerts Profile

Patient event alerts are effective when you want to ensure that primary care physicians are aware that their patients have received care from a different provider. Depending on the implementation, information included with these alerts can range from conveying the patient’s name and basic demographic information to a richer set of clinical data on the patient. By notifying the physician, the care manager, or the care management team, these alerts help improve post-discharge transitions and reduce the chance of a patient facing complications from improper follow-up care.

The participants of the notification exchange can have the following roles:

  • Sender - the system responsible for sending the notifications, typically the facility or the organization where the encounter occurred or the Payer.
  • Recipient - the system responsible for receiving the generated notifications from Senders, typically the Primary Care Provider.

For each notification, the object that is exchanged is an Alert Message Bundle that consists of:

  1. The Message Header - the first resource in the bundle that contains the message event code that identifies the nature of the notification, the message source application, and references to the event's focus resources that are bundled in the message.
  2. The other resources in the bundle (encounters, conditions, and observations) depending on the type of notification.

Alert Message FHIR Bundle Structure

The profile walks you through a scenario where a Payer notifies a Provider about an event, such as hospital admission or discharge. On the Web Portal, the Payer selects the resources (encounters, conditions, and observations) for a specific patient from the FHIR Server, the profile puts together an Alert Message Bundle from the selected data, and then sends the alert to the Provider through XES Module for FHIR. The Provider receives the alert with the patient's data through an EMR system and schedules an appointment to communicate a long-term treatment plan to the patient based on the data received.

The profile contains the following routes:

1 Create And Send To Provider Route

This route receives an alert request from the Payer's Portal to gather specific patient information (encounters, conditions, coverages, observations) into an Alert Message Bundle and to send the data to the Provider.

1a Load resources from Payer Route

This subroute extracts the required resources from the FHIR Server and sends the data for further processing to the parent route.

1b Generate and save to local FHIR Server Route

This subroute transforms the patient's data into an Alert Message Bundle, returns the bundle to the parent route, and submits the data to the Payer's FHIR Server. The route also creates a DocumentReference with metadata on the bundle and submits the resource to the Payer's FHIR Server.

1с Parse provider response Route

This route parses the Provider's response to see if the response contains any error messages, and based on the results, generates an HTTP response.

2 Send Bundle To Provider Route

This route receives a request to extract an existing Alert Message Bundle from the Payer's FHIR server and to send the data to the Provider.