Specialist Pathway Routing for Stroke, STEMI, Trauma, Paeds, and Sepsis

Overview#

Match every time-critical patient to the nearest hospital with the live capability to treat them, even when that means bypassing a closer but less capable emergency department.

When a patient presents with a condition such as stroke, ST-elevation MI, major trauma, paediatric major illness, or severe sepsis, reaching the geographically closest emergency department is not always the right outcome. Specialist Pathway Routing evaluates the presenting condition against a real-time hospital capability roster and selects the destination that maximises the patient's chance of receiving definitive care within clinically meaningful time windows. The pathway decision is recorded on the incident, propagated into the hospital pre-alert, and shown to the attending crew before transport begins. A dispatcher handling a STEMI call sees an automatic recommendation for the nearest 24/7 PPCI-capable centre rather than the closest general ED, with the bypass rationale visible and a one-click audited override available.

Key Features#

• Condition-to-Capability Matching: Bind a coded clinical presentation to the nearest hospital that can actually treat it right now, not just the geographically closest emergency department.

• Live Hospital Capability Roster: Track on-call PPCI teams, thrombectomy-capable stroke centres, paediatric intensivist availability, and trauma team activation status as a real-time roster rather than a static directory.

• Bypass Rationale on the Incident: Record why a closer hospital was passed over so the decision is auditable and visible to the receiving clinician at handover.

• Pathway Code on the Canonical Incident: Stamp the chosen pathway onto the authoritative incident record so every downstream consumer, the hospital pre-alert, the electronic patient care record, the command view, and the responder mobile, sees the same selection.

• Crew-Visible Pathway Badge: Surface the destination decision and the clinical reason on the responder mobile so the attending crew knows where they are going and why before transport begins.

• One-Click Audited Override: Allow the dispatcher or supervising clinician to override the system recommendation with a structured justification that lands in the same audit trail as the original suggestion.

• Hospital Disposition Feedback: Close the loop so the receiving hospital's disposition outcome flows back into the routing service, refining future pathway suggestions and surfacing capability drift over time.

• Pathway Card Library: Drive selection from declarative protocol cards covering stroke, STEMI, major trauma, paediatric critical illness, and sepsis so clinical governance can update bypass criteria without a platform release.

Use Cases#

Emergency Cardiology#

A clinical pre-alert flags ST-elevation on the 12-lead ECG. The platform recommends the nearest 24/7 PPCI-capable centre rather than the closest general ED, and the dispatcher sees both the destination and the rationale in one view.

Stroke Routing#

A FAST-positive caller within the thrombectomy time window is routed to a hub centre with neuro-interventional capability rather than a primary stroke unit, in line with hub-and-spoke pathway guidance.

Paediatric Critical Illness#

A critically unwell child is matched to a hospital with a paediatric intensivist on duty. The responder mobile displays the destination and the clinical reason so the crew can prepare the receiving team during transport.

Major Trauma Activation#

The live roster confirms that a trauma team is activated and accepting. The canonical incident is stamped with the trauma pathway and the receiving hospital pre-alert is dispatched with the structured handover payload.

Sepsis Bundle Routing#

A patient meeting national sepsis recognition criteria is routed to a centre with the bundle capability flagged, with the pathway visible to the crew so the pre-alert primes the receiving team before arrival.

Documented Clinical Override#

A senior clinician overrides a system suggestion, for example, to honour a family preference or because a deteriorating airway favours the nearest available ED, with a structured reason that travels with the incident throughout the care episode.

Integration#

Specialist Pathway Routing is available to developers and system integrators through the following surfaces.

• REST and GraphQL API: Query the live hospital capability roster, retrieve the active pathway for any incident, and submit override decisions via the platform's standard authenticated API. All requests use OAuth 2.0 bearer tokens scoped to your tenant.

• Clinical Pre-Alert Signals: The routing engine listens for incoming clinical signals (12-lead telemetry annotations, triage assessments, voice triage classifications) and automatically evaluates pathway candidates when a time-critical condition is detected.

• Hospital Capability Feed: Hospitals update their on-call roster through a structured feed exposed as an HL7 FHIR R4 endpoint. The platform normalises incoming capability events into the live roster regardless of the sending system's local format.

• Hospital Pre-Alert Payload: When a pathway is confirmed, the platform assembles an HL7 FHIR R4 transaction Bundle containing the encounter, the pathway code, the destination rationale, and current vital signs, and delivers it to the receiving hospital's FHIR endpoint.

• Responder Mobile: The pathway badge and override control are available via the mobile SDK so any authorised application on the crew's device can surface the destination decision without custom integration.

• CAD and Dispatch Systems: Pathway decisions are pushed to connected Computer-Aided Dispatch systems via the NENA EIDO connector or the EENA NG112 connector, depending on the jurisdiction, so the choice of destination is reflected in the CAD record without manual transcription.

• Event Webhooks: A structured event is published for every pathway selection, recording the chosen hospital, the alternatives evaluated, and the rationale. Subscribers can consume these events using the standard CloudEvents 1.0 envelope via webhook or message queue.

• Normalised Data Model: All pathway records use a consistent model regardless of the source signal or the receiving hospital's local system, so analytics, audit, and retrospective clinical review work across every incident without schema translation.

Open Standards#

• HL7 FHIR R4 ServiceRequest: the destination request to the receiving hospital is expressed as a FHIR R4 ServiceRequest resource so it slots into existing clinical receiving workflows.

• HL7 FHIR R4 Encounter: the pathway selection binds to the episode of care using the FHIR R4 Encounter resource so downstream record-keeping stays joined up from pre-hospital through hospital admission.

• HL7 FHIR R4 Composition: structured pre-alert handover documents are assembled as FHIR R4 Composition bundles, enabling standards-based ingestion by any FHIR-capable hospital system.

• SMART on FHIR 2.1: third-party hospital applications can launch directly from the handover context using the SMART on FHIR 2.1 profile, giving clinical staff single-click access to the pre-alert record.

• SNOMED CT (Pathway Reference Set): presenting conditions and pathway labels are coded against SNOMED CT so they exchange cleanly with hospital and national clinical systems.

• IHE PCC PIV (Pre-hospital Information Visualisation): pre-hospital information sent to the receiving clinician aligns with the IHE Patient Care Coordination PIV profile so the structured pre-alert renders correctly in conformant hospital viewing applications.

• ESC STEMI Guidelines: the bypass criteria for ST-elevation MI follow the European Society of Cardiology STEMI guidance as the clinical reference for PPCI routing decisions.

• ESO Stroke 2024 Guidelines: thrombectomy-capable centre routing follows the European Stroke Organisation 2024 guidance for hub-and-spoke stroke pathway design.

• NCEC National Clinical Guideline 11 (Sepsis): sepsis routing aligns with the Irish National Clinical Effectiveness Committee National Clinical Guideline 11 for sepsis recognition and management.

• NENA EIDO: pathway and unit status updates are delivered to NENA EIDO-compliant CAD systems using the standard incident data object format, preserving interoperability with existing public-safety dispatch infrastructure.

• EENA NG112: pathway decisions are propagated to EENA NG112-compliant dispatch systems for European jurisdictions, using the same connector abstraction as NENA EIDO to ensure consistent behaviour across borders.

• CloudEvents 1.0: every pathway selection is published as a structured event using the CloudEvents 1.0 envelope, enabling any subscriber to consume decisions using standard event-broker tooling.

• IEEE 11073 (Medical Device Communication): vital-sign observations streamed from on-scene medical devices over Bluetooth LE are normalised using the IEEE 11073 numeric-to-symbolic mapping before being included in the pathway record and the FHIR handover bundle.

Security and Compliance#

All pathway decisions and override justifications are written to the platform's immutable audit log. Every record carries a timestamp, the identity of the acting user or system, and the tenant context, satisfying clinical governance requirements for accountability and traceability in pre-hospital care.

Multi-tenant isolation ensures that hospital capability rosters, pathway decisions, and patient data are strictly scoped to the originating organisation. Cross-tenant queries are rejected at the API layer before any data is accessed.

Access to pathway read and write operations is controlled through role-based permissions within the standard OAuth 2.0 / OIDC authentication model. Override actions require an elevated permission scope, and the justification field is mandatory, ensuring that every departure from the system recommendation is documented.

Last Reviewed: 2026-05-05 / Last Updated: 2026-05-05