Hospital Pre-Alert: FHIR R4 and REST Notifications for Incoming Patients

Overview#

The Hospital Pre-Alert module sends structured advance notifications to receiving hospitals the moment an emergency unit is dispatched to a patient, giving clinical teams preparation time before the patient arrives. Pre-alerts carry patient demographic information, chief complaint, vital signs using internationally recognised coding standards, estimated time of arrival, unit identifier, trauma level, and incident priority. Hospitals receive this data through their preferred channel, a structured FHIR R4 clinical message for modern electronic health record systems, a generic REST webhook for custom hospital APIs, or an SMS message for facilities that have not yet adopted digital integration. A circuit breaker and retry logic ensure notifications are delivered reliably even when hospital systems are temporarily unavailable.

Key Features#

• FHIR R4 Transaction Bundle: Sends clinical data in HL7 FHIR R4 format as an Encounter resource paired with Observation resources for each recorded vital sign, using LOINC-coded measurements and SNOMED-coded clinical findings for interoperability with any FHIR-compliant hospital system
• LOINC-Coded Vital Signs: Heart rate, blood pressure, oxygen saturation, respiratory rate, temperature, and Glasgow Coma Scale score are transmitted using their standard LOINC codes, ensuring receiving systems can process measurements automatically without custom field mapping
• REST Webhook Fallback: For hospitals that have not deployed a FHIR endpoint, pre-alerts are delivered as a structured JSON payload to a configured webhook URL, supporting custom hospital intake systems with minimal integration effort
• SMS Fallback: When neither FHIR nor REST integration is configured, a plain-language pre-alert is sent to a hospital contact number, ensuring clinical teams always receive advance notice regardless of the facility's technical maturity
• Exponential Backoff Retry: Failed delivery attempts are retried up to three times with increasing delays, handling transient network issues and brief API outages without manual intervention or duplicate alert creation
• Circuit Breaker: After five consecutive delivery failures to a hospital endpoint, the circuit opens and further attempts are paused for sixty seconds before retrying, preventing a failing hospital system from creating a cascade of queued retries that delay other alerts
• Per-Hospital Authentication: Each hospital is configured with its own authentication method, Bearer token or API key, stored in the hospital configuration record rather than in code, allowing credentials to be rotated without a deployment
• Pre-Alert Audit Trail: Every delivery attempt, its response code, and its outcome are recorded in the hospital pre-alerts table with the originating dispatch event, providing a complete delivery history for clinical governance review

Use Cases#

FHIR-Integrated Emergency Department#

An emergency department's clinical information system receives an incoming FHIR R4 bundle as soon as the ambulance crew is dispatched. By the time the unit arrives, nursing staff have reviewed the chief complaint, pulled the patient's previous encounter history, prepared a resuscitation bay based on the trauma level indicator, and alerted the on-call specialist, all before the patient reaches the door.

Cardiac Arrest Pre-Alert#

A crew reports cardiac arrest with a shockable rhythm. The pre-alert bundle includes the chief complaint, current CPR status, GCS of 3, and the crew's ETA. The receiving hospital activates their cardiac arrest protocol, calls the on-call cardiologist, and prepares the catheterisation lab before the patient arrives.

Multi-Trauma Incident#

A road traffic collision generates pre-alerts for three patients to two different hospitals, each carrying the appropriate patient data and trauma level. The system manages all three deliveries independently, retrying any that encounter a temporary API error without affecting the others.

SMS-Only Facility#

A smaller district hospital does not have an API endpoint. The system detects this from the configuration and delivers a formatted SMS to the emergency department's duty phone, providing the essential details in human-readable form while the more capable hospitals in the region receive FHIR bundles.

Delivery Audit Review#

A clinical governance team reviews pre-alert delivery records for a high-profile case. The audit log shows the exact timestamp the pre-alert was sent, the HTTP response received from the hospital's FHIR server, and the retry history, providing a precise record of when and how clinical teams were informed.

How It Works#

Integration#

The Hospital Pre-Alert module is invoked by the Incident Dispatch workflow at the moment a unit is assigned and en route to a patient. Hospital configurations, endpoint URL, preferred channel, authentication credentials, and FHIR capability flag, are managed through the administration console and stored per hospital record scoped to the tenant. The pre-alert identifier is written back to the incident record, allowing dispatchers to see delivery status from the incident panel. Incoming acknowledgement signals from hospital systems (where supported) are recorded against the pre-alert record and surfaced on the dispatcher dashboard.

Open Standards#

• HL7 FHIR R4: Pre-alert clinical data is packaged as a FHIR R4 transaction Bundle containing an Encounter resource and Observation resources for each vital sign, and posted directly to the receiving hospital's FHIR endpoint using the application/fhir+json media type.
• LOINC (Logical Observation Identifiers Names and Codes): Every vital sign Observation is coded with its standard LOINC identifier (heart rate 8867-4, oxygen saturation 59408-5, respiratory rate 9279-1, body temperature 8310-5, Glasgow Coma Scale 9269-2, blood pressure panel 85354-9) so receiving systems can process measurements without custom field mapping.
• SNOMED CT: Encounter type and chief complaint are expressed using SNOMED CT codes (emergency room admission 50849002, chief complaint 371568007), enabling automated clinical decision support at the receiving facility.
• UCUM (Unified Code for Units of Measure): Vital sign quantity values carry UCUM unit codes via the http://unitsofmeasure.org system (mm[Hg] for blood pressure, /min for rates, Cel for temperature) to ensure numeric values are dimensionally unambiguous.
• HL7 v2.4: The hospital feedback path accepts HL7 v2.4 ORU^R01 and ADT messages, parsing MSH, PID, PV1, and OBX segments including PV1-36 discharge disposition codes, so hospitals that respond over HL7 v2 messaging are fully supported.
• EDXL-TEP 1.0 (Emergency Data Exchange Language Tracking of Emergency Patients): The FHIR bridge can serialise the same encounter data as EDXL-TEP 1.0 XML, allowing pre-alert records to be exchanged with EMS tracking and regional coordination systems that implement the OASIS EDXL-TEP standard.
• ICD-10: Hospital disposition feedback payloads accept ICD-10 diagnosis codes alongside SNOMED CT outcome codes, mapping them into the audit record for clinical governance review.

Compliance#

• FHIR R4 format ensures interoperability with hospital electronic health record systems compliant with international clinical data standards
• LOINC and SNOMED coding enables automated clinical decision support at the receiving hospital without requiring custom field interpretation
• All pre-alert delivery attempts are recorded in the audit trail for clinical governance, pre-hospital care audit, and emergency care quality review purposes
• Per-hospital credential configuration prevents credential sharing across facilities and enables individual revocation

Last Reviewed: 2026-04-14 Last Updated: 2026-04-14