NEWFree ROI Calculators — quantify what prior auth and siloed data are costing your organization.Prior Auth ROI Siloed Data ROI
HL7 v2Message11 min read

HL7 VXR Messages: Vaccination Record Response

HL7 VXR messages return a patient's historical immunization record in response to a vaccination query. A VXR message is the answer to a VXQ query — it is sent by an immunization information system (IIS) or registry to the requesting system, carrying every vaccination event on file for the identified patient. This page explains what a VXR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how a VXR immunization record relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What a VXR message represents

A VXR message — VXR stands for Vaccination Record Response — communicates a patient's complete vaccination history held by the responding system. The core of the message is the RXA segment, which carries the administration data for a single immunization event: the vaccine administered, the date it was given, the amount administered, the manufacturer, the lot number, and the completion status. Each vaccination event in the patient's history produces its own RXA, grouped inside a repeating ORDER group.

The sender is the immunization registry or IIS, and the receiver is the requesting clinical or public-health application — typically an EHR, a school health system, or a public-health surveillance platform. The VXR is a query response: it carries only historical records that already exist in the registry. It does not create or update vaccination data on the receiving side on its own; that role belongs to the VXU unsolicited update. Because the registry holds the longitudinal record, the RXA in a VXR is the authoritative source of what vaccines are documented for that patient in the responding system.

When a VXR message is sent

A VXR message is sent when a registry or IIS receives a VXQ^V01 vaccination query and finds a matching patient record. The registry constructs one ORDER group per vaccination event on file and returns the complete history in a single VXR response. If the query returns no match, or returns an ambiguous match requiring human review, the registry responds instead with a VXX^V02 response for multiple matches or an acknowledgement indicating no data found.

Trigger event

The VXR message type carries a single trigger event:

  • VXR^V03 – Vaccination record response.

The trigger code V03 identifies this message as a query response, distinguishing it from the unsolicited vaccination update (VXU^V04) that does not originate from a query. Receivers route on MSH-9 and use the QAK query acknowledgement segment to determine whether the response carries records or signals no-data.

Integration topology

The diagram shows a clinical system querying an immunization registry and receiving the vaccination history in return.

{{diagram: EHR / clinical system → VXQ^V01 query → immunization registry → VXR^V03 response → EHR / clinical system}}

Typical senders: immunization information system (IIS), state or regional immunization registry, public-health authority.

Typical receivers: EHR, ambulatory clinical application, school health system, public-health surveillance platform.

Direction: point-to-point response from the registry to the requesting system, paired with the originating VXQ query.

Segments in a VXR message

The VXR_V03 message is organised into a fixed header block — MSH, MSA, optional errors, and query metadata — followed by patient demographics and one or more repeating ORDER groups, each carrying a single vaccination event. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

SegmentDescription
MSHMessage Header. Opens every VXR message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (VXR^V03), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10.
MSAMessage Acknowledgement. Required in all query responses. Carries the acknowledgement code (AA for accepted, AE for error) in MSA-1 and echoes the message control id of the originating VXQ query in MSA-2, linking the response unambiguously to the request.
[{ERR}]Error. Present when the response carries an error or warning — for example, when the query matched more than one patient or a required query parameter was missing. Optional and repeating to allow multiple error conditions.
QAKQuery Acknowledgement. Summarises the query outcome. Carries the query tag from the originating VXQ in QAK-1, the query response status (OK for data found, NF for no data found, AE for error) in QAK-2, and the query name in QAK-3. Required in every VXR.
QRDOriginal-Style Query Definition. Echoes the query parameters from the originating VXQ — the query date and time, format code, priority, and the who-subject filter that identified the patient. Required; carries the patient identifiers used to locate the record.
PIDPatient Identification. Identifies the patient whose vaccination history follows — the identifier list in PID-3, legal name in PID-5, date of birth in PID-7, and sex in PID-8. Required when a patient match was found; the fields the registry returns are governed by the query parameters and data-sharing agreements in force.
[PD1]Patient Additional Demographic. Supplements PID with the patient's primary-care provider and facility. Optional.
[{NK1}]Next of Kin / Associated Parties. Parent or guardian information — particularly relevant for paediatric immunization records. Optional and repeating to accommodate multiple contacts.
[PV1]Patient Visit. The encounter context for the vaccination, when relevant — patient class and location. Optional.
[PV2]Patient Visit Additional. Companion to PV1 with supplemental visit data when a visit context is present. Optional.
ORCCommon Order. Opens each ORDER group and provides the order control context for the vaccination event. Carries the filler order number that uniquely identifies this immunization event within the registry. Required, and the ORDER group repeats once per vaccination on record.
RXAPharmacy/Treatment Administration. The heart of the VXR and the authoritative record of a single vaccination event. Carries the administered vaccine code in RXA-5 (typically CVX), the administered amount in RXA-6, the administered units in RXA-7, administration notes in RXA-9, the administering provider in RXA-10, the substance lot number in RXA-15, the substance expiration date in RXA-16, the substance manufacturer name in RXA-17, and the completion status in RXA-20. Required in every ORDER group.
[RXR]Pharmacy/Treatment Route. The route of administration (intramuscular, subcutaneous, oral) and anatomical site for the administered vaccine. Optional; when present it refines the clinical record of how the vaccine was given.
[{OBX}]Observation/Result. Observations associated with the vaccination event — Vaccine Information Statement (VIS) document type and presentation date, contraindications, and adverse reactions or other clinical notes. Optional and repeating; each OBX carries a single observation keyed by OBX-3.

[ ] = optional, { } = repeating

The ORDER group from ORC through OBX repeats once per vaccination event in the patient's history, so a single VXR message can carry a complete multi-dose immunization record. The canonical segment pages carry the full field-by-field detail.

Sample VXR message

Note. Constructed for illustration. Patient identifiers, lot numbers, dates, and names are fictional.

MSH|^~&|IMMREG|STATEIIS|EHR|MERCYCLINIC|20260604090000||VXR^V03^VXR_V03|MSG00047|P|2.5.1
MSA|AA|QRY00031
QAK|QRY00031|OK|Z34^Request Immunization History^CDCPHINVS
QRD|20260604090000|R|I|QRY00031|||1^RD|^^^MERCYCLINIC|VXI^Vaccine Information^CDCPHINVS
PID|1||PT98765^^^STATEIIS^SR||SMITH^EMMA^L||20150312|F|||123 OAK ST^^SPRINGFIELD^IL^62701
ORC|RE|VX10001^STATEIIS
RXA|0|1|20150915|20150915|08^Hep B  adolescent or pediatric^CVX|0.5|mL^milliliter^UCUM||00^New immunization record^NIP001|NPI1234567^JONES^CAROL|||||LOT2015A|20161001|MSD^Merck^MVX||||CP
RXR|IM^Intramuscular^HL70162|LT^Left Thigh^HL70163
OBX|1|CE|30956-7^Vaccine type^LN||08^Hep B  adolescent or pediatric^CVX||||||F
OBX|2|TS|29768-9^Date vaccine information statement presented^LN||20150915||||||F
ORC|RE|VX10002^STATEIIS
RXA|0|1|20151115|20151115|116^Rotavirus  pentavalent^CVX|2|mL^milliliter^UCUM||00^New immunization record^NIP001|NPI1234567^JONES^CAROL|||||LOT2015B|20170601|MSD^Merck^MVX||||CP
RXR|PO^Oral^HL70162
OBX|1|CE|30956-7^Vaccine type^LN||116^Rotavirus  pentavalent^CVX||||||F

What this sample shows

The VXR^V03 in MSH-9 marks a vaccination record response. MSA carries AA confirming the query was accepted, and echoes the originating query control id QRY00031. QAK confirms status OK — records were found. QRD echoes the query parameters. PID identifies the patient as PT98765 with date of birth 20150312.

The first ORDER group records a Hepatitis B vaccine: ORC opens the group with order control RE; RXA carries CVX code 08 in RXA-5, 0.5 mL in RXA-6 and RXA-7, lot number LOT2015A in RXA-15, expiration date 20161001 in RXA-16, manufacturer Merck in RXA-17, and completion status CP (complete) in RXA-20. RXR gives the intramuscular route and left-thigh site. The OBX segments carry the vaccine type observation and the VIS presentation date. The second ORDER group records an oral rotavirus dose, following the same pattern.

Working with VXR messages

RXA is the authoritative vaccination record

All clinically significant data for a vaccination event lives in RXA. Parse RXA-5 for the vaccine code (CVX is the standard code set for immunization registries in the United States), RXA-15 through RXA-17 for lot, expiration, and manufacturer, and RXA-20 for completion status before looking anywhere else. Treat an RXA-20 value of CP as a completed administration; NA indicates a not-administered event such as a refusal, and PA indicates a partially administered dose.

Idempotency and deduplication

Use MSH-10 as the deduplication key for the message, and treat the combination of the filler order number in ORC and the administration date in RXA-3 as the natural business key for each vaccination event. Registry feeds are replayed during system recovery; treating a repeated filler order number and date pair as a duplicate prevents a replayed history from creating duplicate immunization records in the receiving EHR.

Correlate the response to its query

MSA-2 echoes the message control id of the originating VXQ, and QAK-1 carries the query tag. Both must be matched back to the pending query before the response is processed. A VXR that cannot be correlated to an outstanding query should be held for review rather than applied to a patient record, since the absence of a matching query means the patient context cannot be confirmed.

Handle no-data and error responses

When QAK-2 is NF (no data found), the VXR arrives with the header and query segments intact but no patient or ORDER data. Process the no-data response explicitly — do not treat it as a parse failure. When QAK-2 is AE, inspect the ERR segments for the specific error condition before deciding whether to retry or escalate.

Vendor variance. The set of fields populated in RXA varies by registry. Some registries populate RXA-10 (administering provider) and RXA-9 (administration notes) consistently; others leave them empty and rely on the clinical site's own record. Confirm a registry partner's field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

A vaccination event corresponds to the FHIR Immunization resource, with the patient as a Patient resource and, for a messaging exchange, a MessageHeader at the head of a Bundle.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for VXR_V03. The related unsolicited vaccination update — VXU^V04 — has a published Bundle map in the Implementation Guide, and the RXA segment has a published ConceptMap to the FHIR Immunization resource that can guide field-level translation. A FHIR Immunization produced from a VXR message is therefore mapped manually, taking the vaccine code, administration date, lot number, manufacturer, route, and completion status from RXA and RXR, and referencing the Patient derived from PID.

Common pitfalls

Pitfall. Ignoring RXA-20, the completion status. An RXA-20 of NA indicates the vaccine was not administered — for example, due to patient refusal — and must not be recorded as an administered dose. Treating every RXA as a completed immunization overcounts the patient's vaccination history.

Pitfall. Applying a VXR to the wrong patient. The query-response correlation through MSA-2 and QAK-1 is the only safeguard that the returning history belongs to the patient the requesting system queried. Skipping that correlation step and loading history directly from PID leaves the system exposed to a mis-routed response populating the wrong patient's record.

Pitfall. Assuming a fixed CVX code format. Some registries encode RXA-5 using CVX codes, others use CPT, and some use proprietary local codes. Confirm the code system in the third component of the CWE field (RXA-5.3) before mapping to a canonical vaccine list.

How Vorro handles VXR messages

Vorro receives VXR responses over MLLP, correlates each response to its originating VXQ query using MSA-2 and QAK-1, and routes the vaccination history to every subscribed destination in the format that system expects. Vorro reads each vaccination event from the ORDER groups, extracts the vaccine code, lot, manufacturer, route, and completion status from RXA and RXR, and deduplicates on the filler order number from ORC so that replayed registry feeds do not create duplicate records. Where a FHIR destination is configured, Vorro maps each RXA to a FHIR Immunization resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no message map for VXR_V03 — using the published RXA ConceptMap as a field-level guide.

  • VXQ — the vaccination query that a VXR message responds to.
  • VXU — the unsolicited vaccination update that pushes immunization records without a preceding query.
  • VXX — the response sent when a VXQ query returns multiple candidate matches requiring human disambiguation.

Sources

← Back to HL7 v2 Guide

Ready to Integrate This Into Your Workflow?

Talk to a Vorro expert about implementing HL7 v2 in your specific environment.

Browse HL7 v2 Guides
HL7 VXR Messages: Vaccination Record Response | Vorro Academy | Vorro