Background

Emergency Medical Services (EMS) teams often arrive at the emergency department with patients whose demographics are incomplete or unknown—no medical record number (MRN), no confirmed name, and sometimes no date of birth. Yet EMS transportation notes still need to land in the correct chart.

To support safe and reliable documentation, EMS agencies, third-party integration services, and hospital integration teams build secure interfaces that exchange identifiers and clinical messages. When those identifiers don’t line up, downstream systems can’t automatically post transport notes—creating avoidable manual work and delaying record completeness. This article outlines how FHIR Patient.Search (R4) can be used to fill the most common demographic gaps and improve automated posting.

The challenge

In many EMS-to-hospital integrations, patients are initially registered under generic or temporary identifiers. Final registration—and any record merge—may not occur until later, sometimes after discharge. Until those updates propagate, the EMS patient identifiers and the Electronic Medical Record (EMR) identifiers can remain out of sync.

When a transport note can’t be posted due to a mismatch, the integration typically generates an error that routes to an EMR work queue for manual review. At EMS volumes, that queue can grow quickly. A common root cause is inbound messages that lack one or more demographic fields required for confident patient matching and chart posting—most often:

• Medical Record Number (MRN)
• Name
• Date of Birth
• Gender

How it works today

Today, missing demographics are supplemented by querying a long-running Microsoft SQL Server database (in service for more than 20 years) that stores an interpreted view of HL7 ADT (Demographics) messages. The integration layer uses JDBC calls to execute stored procedures and retrieve the needed fields.

A FHIR-based approach

A more modern option is to retrieve missing demographics directly from a FHIR repository. Specifically, FHIR Patient.Search (R4) provides a standards-based way to look up MRN, name, date of birth, and gender using whatever partial information is available at the time of transport note posting.

To operationalize this, a dedicated business process wraps the Patient.Search (R4) call and returns a normalized response back to the originating integration workflow.

Workflow Overview

The requesting source submits a PatientSearch.Request (custom message class) to the business process.

From there, the business process performs the following steps:

• Obtains an OAuth access token.
• Transforms the PatientSearch.Request (Custom Message Class) into an HS.FHIRServer.Interop.Request.
• Sends the HS.FHIRServer.Interop.Request to an external FHIR repository.
• Verifies that the FHIR response returns HTTP OK (200).
• Converts the FHIR response from the HTTP stream into a PatientSearch.Response (Custom Message Class).
• Returns PatientSearch.Response (Custom Message Class) to the originating process.

Additional workflow considerations include:

• Ensuring the vendor provides at least one of the following: MRN, name, date of birth, or gender.
• If multiple FHIR Patient responses are returned, the result is forwarded to the EMR as-is, allowing the system to generate an error if the provided fields are insufficient to uniquely identify a patient.