Inter-Hospital Transfer Coordination for Critical Care Retrieval

Overview#

A consultant requesting a critical-care retrieval needs to match patient acuity to the right level of vehicle, confirm receiving-hospital ICU availability, and schedule the retrieval team in one workflow, with the transfer running as a child of the original incident on the canonical timeline.

The Inter-Hospital Transfer Coordination module brings critical care retrieval (CCRS, MICAS, IHTS, paediatric retrieval, HEMS dispatch) into a single coordinated pathway. It pairs requesting and receiving clinicians, the transport service, and dispatch through one shared incident object so that vehicle capability, bed availability, and clinical context all line up before the team rolls.

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

Key Features#

• Acuity-to-Capability Matching: Match patient acuity to the required level of transport so that level 1, level 2, level 3, ICU-capable, and ECMO-capable resources are requested and assigned correctly.

• Receiving ICU Bed Confirmation: Confirm that the receiving hospital has an appropriate critical care bed available before the retrieval team commits to the transfer.

• Retrieval Team Scheduling: Schedule the critical care retrieval team in the same workflow that captures the clinical request, removing back-and-forth between requesting clinician, transport service, and receiving unit.

• Child Incident Linking: Run the transfer as a child incident linked to the parent admission so the canonical timeline shows the original event and every onward movement of the patient.

• Inherited Clinical Context: The retrieving team's ePCR encounter inherits the parent's clinical context so handovers do not have to be re-elicited from scratch.

• Closed-Loop Disposition Feedback: Receiving ICU disposition feedback returns to the originating incident, closing the loop for both the requesting hospital and the transport service.

• Multi-Modal Retrieval Pathways: Support road CCRS / MICAS, paediatric retrieval, and HEMS dispatch through the same coordinated pathway rather than parallel processes.

• Imaging That Travels With the Patient: Cross-enterprise document sharing for imaging means scans referenced in the request are available to the receiving team on arrival.

Use Cases#

• Adult Critical Care Retrieval (CCRS / MICAS): An ICU consultant at a regional hospital requests retrieval of a ventilated patient and receives a confirmed vehicle, team, and accepting bed in one workflow.

• Paediatric Retrieval: A paediatric retrieval team is matched to the acuity of a critically ill child, with appropriate vehicle capability and receiving paediatric ICU bed confirmed before tasking.

• ECMO-Capable Transfer: A patient requiring extracorporeal support is matched only to ECMO-capable transport, with the receiving ECMO centre acceptance recorded against the request.

• HEMS Dispatch for Time-Critical Transfer: A time-critical inter-hospital transfer is escalated to HEMS, scheduled against the same parent incident as the original presentation.

• Major Trauma Onward Transfer: A patient initially received at a trauma unit is transferred onward to a major trauma centre with the original incident remaining the canonical parent record.

• Cardiac PPCI Transfer: A patient meeting PPCI criteria is transferred to a cardiac centre with the receiving cath lab availability confirmed before mobilisation.

Integration#

• HSE NAS Scheduling: The retrieval booking integrates with HSE National Ambulance Service scheduling so the right resource is dispatched against the right pathway.

• MICAS Scheduling Adapter: A dedicated integration with the Mobile Intensive Care Ambulance Service handles tasking, status, and team availability for adult critical care retrieval.

• Hospital Capability Roster: The receiving-side check uses a live capability roster covering ICU and ECMO bed availability across participating hospitals.

• Specialist Transport Service Routing: Requests are routed through the specialist transport service so the right pathway (CCRS, paediatric, HEMS) is activated automatically.

• PSAP Protocol Engine Pathway Cards: Pathway cards for CCRS transfer and HEMS retrieval drive the structured booking flow and capture the clinical justification.

• PSAP Booking Form: A dedicated IHT booking form on the PSAP console gathers the clinical and logistical details required to schedule the retrieval team.

• Responder Mobile Conveyance: A mobile badge on the responder conveyance screen surfaces the inherited parent context to the retrieving crew during the transfer leg.

• ePCR Encounter Inheritance: The transfer ePCR inherits clinical context from the parent admission encounter rather than starting from a blank record.

• Receiving Hospital Disposition Channel: Disposition feedback from the receiving ICU returns through the hospital disposition feedback channel so the originating incident and transport service both see the outcome.

Open Standards#

• HL7 FHIR R4 ServiceRequest: the inter-hospital transfer request itself is represented as a ServiceRequest resource so it can move between hospital, transport, and receiving systems using a shared clinical request model.

• HL7 FHIR R4 Appointment: the scheduled retrieval slot is captured as an Appointment, giving requesting clinician, transport service, and receiving hospital a common view of timing.

• HL7 FHIR R4 Coverage: payor and cost-center information for the transfer is expressed as a Coverage resource so financial responsibility travels with the request.

• HL7 FHIR R4 Encounter: both the originating admission and the transfer leg are modelled as Encounter resources, preserving the clinical container expected by hospital systems.

• IHE XDS-I: cross-enterprise document sharing for imaging allows scans referenced in the transfer request to follow the patient to the receiving hospital.

• IHE PCC ED Referral: the IHE Patient Care Coordination ED Referral profile is reused for the structured clinical referral content that accompanies the transfer.

• SNOMED CT: service-request codes and capability codes (vehicle capability, retrieval pathway, receiving service) are expressed using SNOMED CT terminology.

• CloudEvents 1.0: lifecycle events for the transfer are emitted as CloudEvents (argus.iht.requested, argus.iht.scheduled, argus.iht.completed) so downstream systems can subscribe using a portable event envelope.