HL7 ERP_R09 Event Replay Response

A legacy response for replaying previously transmitted events.
HL7 message structure ERP_R09 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

SegmentNameRequiredRepeatable
MSH
 Message Header Yes No
SFT
 Software Segment No Yes
MSA
 Message Acknowledgment Yes No
ERR
 Error No No
QAK
 Query Acknowledgment Yes No
ERQ
 ERQ Yes No
DSC
 Continuation Pointer No No

ERP_R09 is the response side of the old event replay query pattern. A requester asks for previous events, and the responder acknowledges the query and reports replay status, usually with continuation when the result set is large.

Modern systems often solve replay with interface-engine queues, audit stores, FHIR bulk access, or receiver-specific APIs. ERP_R09 still matters when an old HL7 v2 query contract says this is how replay is done.

A small ERP R09 example

MSH|^~\&|ADTARCHIVE|CITYHOSP|ENGINE|CITYHOSP|20260718153500||ERP^R09^ERP_R09|ERPR090001|P|2.5.1 MSA|AA|RQQQ090001 QAK|QREPLAY001|OK|Q09^Replay admit events^HL7nnn|1 ERQ|QREPLAY001|ADT^A01^ADT_A01|WARD2^20260701000000^20260717235959 DSC|REPLAY-NEXT-001|I

What systems do with it

The responder confirms whether the replay request was accepted and gives enough query context for the requester to keep the replay conversation straight. If the responder cannot send everything at once, DSC points to the next increment.

In many real implementations, the replayed events themselves travel as their original messages on the normal feed, while ERP_R09 is used to manage or acknowledge the query conversation. Confirm the receiver's profile before assuming the payload style.

How to read the structure

MSH identifies ERP^R09^ERP_R09. MSA acknowledges the original event replay query. Optional ERR reports problems. QAK reports query status. ERQ echoes or identifies the replay request. DSC handles continuation.

Implementation traps

Do not let replay create duplicate downstream state. Receivers need idempotency based on original message control IDs, event times, business identifiers, or a replay-specific duplicate policy.

Also define the replay window precisely. Date ranges, event types, facilities, and patient filters should be audited because replay traffic can be large and clinically sensitive.

Reference notes

HL7 v2.3.1 Chapter 2 includes ERP as an event replay response and related RQQ query behavior. See the HL7 v2.3.1 control/query chapter.