HL7 PEX messages carry adverse-event and product-experience reports — the structured records submitted to regulatory bodies and manufacturers when a product is suspected of causing or contributing to a patient experience. A PEX message organises everything relevant to a single report: who submitted it, what the patient experienced, which product is the suspected cause, and the clinical context surrounding the event. This page explains what a PEX message represents, the two trigger events that carry it, every segment the message can contain and what each one holds, and how a PEX report conceptually relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What a PEX message represents
A PEX message — PEX stands for Product Experience — communicates a product-experience report to a regulatory body, a manufacturer, or an internal pharmacovigilance system. The message is structured around three nested concepts: the sender of the report, the experience or adverse event the patient had, and the causal relationship between a specific product and that experience. These map respectively to the PES, PEO, and PCR segments at the core of every PEX message.
The sender is often a healthcare facility, a manufacturer's drug-safety department, or a regulatory liaison — not the treating clinician directly, though clinician-reported data is collected within the message. The receiver is typically a regulatory agency such as the FDA MedWatch system, or a manufacturer's pharmacovigilance platform. A PEX message is one of the few HL7 v2 message types designed primarily for regulatory rather than clinical workflow, and its segment structure reflects that purpose: it captures causal assessment, seriousness criteria, and product lot information rather than the transactional data that drives clinical care.
When a PEX message is sent
A PEX message is sent when an organisation submits or updates an individual product-experience report. The initial submission opens a case; the update carries corrections, additional clinical findings, or a revised causal assessment as the investigation progresses. Both trigger events carry the same segment structure, so the processing logic is identical — the trigger code in MSH-9 tells the receiver whether to open a new case or update an existing one.
Trigger events
The PEX message type carries two trigger events:
PEX^P07— Unsolicited initial individual product experience report. Sent when the reporting organisation submits a product-experience case for the first time.PEX^P08— Unsolicited update individual product experience report. Sent when the reporting organisation amends, supplements, or closes an existing case.
Integration topology
The diagram shows the reporting organisation's pharmacovigilance system emitting a product-experience event through the integration engine to the regulatory and manufacturer destinations.
{{diagram: pharmacovigilance system → PEX message → integration engine → regulatory agency / manufacturer safety database / internal case management}}
Typical senders: pharmacovigilance system, hospital drug-safety department, manufacturer's safety reporting platform, clinical trial data-management system.
Typical receivers: regulatory agency (e.g., FDA MedWatch, EMA EudraVigilance), manufacturer's safety database, internal adverse-event case management.
Direction: unidirectional notification from the reporting organisation to the regulatory or safety destination.
Segments in a PEX message
The PEX_P07 and PEX_P08 messages share a single structure. The outer envelope carries the patient and visit context; a repeating EXPERIENCE group then contains one PES (Product Experience Sender) segment followed by one or more PEO (Product Experience Observation) segments, and within each PEO a repeating PCR (Possible Causal Relationship) group links a specific product to the event and carries the supporting clinical detail. 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.
| Segment | Description |
|---|---|
MSH | Message Header. Opens every PEX message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (PEX^P07 or PEX^P08), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 to distinguish a new case from an update, and deduplicate on MSH-10. |
EVN | Event Type. Records the event code and the date and time the event was recorded. For PEX messages the event type echoes the trigger code and the recorded-date anchors the report to the point in time the reporting organisation captured it. |
PID | Patient Identification. Identifies the patient who had the product experience — the identifier list in PID-3, the name in PID-5, and the date of birth and sex that regulatory submissions require. Required. |
[PD1] | Patient Additional Demographic. Supplements PID with data such as the patient's primary-care facility and living arrangement. Optional. |
[{NK1}] | Next of Kin / Associated Parties. Contacts for the patient at the message level — next of kin, guardian, or other associated party. Optional and repeating. |
[PV1] | Patient Visit. The encounter during which the product experience occurred — patient class, assigned location, and the attending and consulting providers. Optional. |
[PV2] | Patient Visit Additional. Companion to PV1 with admit reason, expected discharge date, and visit description when a visit is present. |
{PES} | Product Experience Sender. Opens each EXPERIENCE group and identifies the organisation or individual submitting the product-experience report. It carries the sender's organisation name, contact details, and the report's event-date range — the window during which the adverse experience took place. Required and repeating; the EXPERIENCE group repeats once per sender when a report is submitted jointly. |
[{PEO}] | Product Experience Observation. Describes the adverse experience itself — what the patient experienced, when the experience began and ended, the seriousness criteria (death, life-threatening, hospitalisation, disability, congenital anomaly, or required intervention), and the outcome. One PEO segment represents one discrete adverse event. Optional and repeating within each EXPERIENCE group, so a single report can describe multiple distinct experiences. |
[{NK1}] | Next of Kin / Associated Parties (PCR group). Associated parties relevant to a specific product-causal relationship within the PCR group — for example, the prescribing clinician or the pharmacist who dispensed the suspect product. Optional and repeating within the PCR group. |
[RXE] | Pharmacy/Treatment Encoded Order. The encoded order for the suspect product as it was prescribed — dose, frequency, route, and start date. Provides the regulatory reviewer with the prescription context against which the adverse event occurred. Optional within the PCR group. |
[{RXR}] | Pharmacy/Treatment Route. The route of administration for the suspect product — oral, IV, subcutaneous. Optional and repeating within the PCR group, one per route when multiple routes apply. |
[{RXC}] | Pharmacy/Treatment Component. The components of a compound product implicated in the experience — each base and additive with its amount. Optional and repeating within the PCR group. |
[{NTE}] | Notes and Comments. Free-text narrative relevant to the causal relationship — the reporter's clinical commentary or regulatory case notes. Optional and repeating within the PCR group. |
[{PRB}] | Problem Detail. Structured problem data associated with the adverse experience — problem code, onset date, and severity. Optional and repeating within the PCR group; supplements the event description in PEO with coded problem entries from the patient's problem list. |
[{OBX}] | Observation/Result. Clinical observations supporting the causal assessment — laboratory values, vital signs, or diagnostic results obtained before, during, or after the adverse event. Optional and repeating within the PCR group. |
[ ] = optional, { } = repeating
The EXPERIENCE group from PES through the final OBX repeats once per reporting sender; the PEO repeats once per adverse event within a sender's report; and the PCR group repeats once per suspect product within each event. The canonical segment pages carry the full field-by-field detail.
Sample PEX message
Note. Constructed for illustration. Patient identifiers, case numbers, dates, and names are fictional.
MSH|^~&|PVSYS|MERCYGEN|FDAMW|FDA|20260604083000||PEX^P07^PEX_P07|MSG00041|P|2.5.1
EVN|P07|20260604083000
PID|1||PT98765^^^MERCYGEN^MR||SMITH^JANE^M||19720315|F
PV1|1|I|3W^301^A^MERCYGEN||||DR456^JONES^RICHARD^^^MD
PES|1|MERCYGEN SAFETY DEPT^^^^^MERCYGEN|20260601|20260604|01^Initial report^HL70234
PEO|1|787048^Nausea^SCT~271807003^Rash^SCT|20260601120000|20260604|N|Y|Y|N|N|N|Recovering
PCR|1|NDC00071015523^Atorvastatin 20 MG Tablet^NDC|20260201|||||Possible
RXE|1^QD^^20260201|NDC00071015523^Atorvastatin 20 MG Tablet^NDC|20||MG|TAB
RXR|PO^Oral^HL70162
NTE|1||Patient reported onset of nausea and diffuse rash approximately 4 months after initiating therapy. No prior history of statin intolerance.
OBX|1|NM|1742-6^ALT^LN||78|U/L|7-56||||F|||20260602
OBX|2|NM|2345-7^Glucose^LN||95|mg/dL|70-99||||F|||20260602
What this sample shows
The PEX^P07 in MSH-9 marks an initial product-experience report. EVN records the event type and capture time. PID identifies the patient by medical record number PT98765, and PV1 places her in an inpatient encounter on ward 3W under Dr Jones. The PES segment opens the EXPERIENCE group and identifies the reporting organisation as MERCYGEN SAFETY DEPT, with the experience window running from 1 June to 4 June 2026. The PEO segment describes two concurrent adverse events — nausea and rash — beginning 1 June, with seriousness flags indicating non-fatal but requiring intervention. The PCR segment names Atorvastatin 20 MG Tablet as the suspect product with a causal assessment of Possible. The RXE echoes the encoded order — once daily, started 1 February 2026 — and RXR confirms the oral route. The NTE carries the reporter's narrative. The two OBX segments supply ALT and glucose values from a supporting lab draw.
Working with PEX messages
Distinguish initial from update reports using MSH-9
PEX^P07 opens a new case; PEX^P08 updates an existing one. Route on MSH-9 before any other processing. An update message without a pre-existing case should be held or rejected, not silently accepted, because a missing initial report leaves the case history incomplete for regulatory purposes.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key. Pharmacovigilance feeds are replayed after outages and regulatory submissions are sometimes retransmitted to confirm receipt. Treating a repeated control id as a duplicate prevents a resubmission from opening a second case or writing a duplicate update.
Preserve the full EXPERIENCE group structure
The nested structure — EXPERIENCE group containing PES, then repeating PEO, then repeating PCR — is essential for multi-product, multi-event reports. Flattening the structure to a single record loses the mapping between which product is implicated in which event. Maintain the group hierarchy in storage so that a case with three events and two suspect products per event can be reconstructed exactly.
Capture seriousness criteria as coded flags
PEO carries seriousness as a series of Y/N flags — death, life-threatening, hospitalisation required, disability, congenital anomaly, and required other intervention. These flags drive regulatory submission timelines: a death or life-threatening event typically triggers an expedited 7-day or 15-day report. Parse each flag independently rather than summarising to a single severity level.
Vendor variance. The PCR group's clinical detail segments —
RXE,RXR,OBX— are all optional, and senders vary considerably in how much clinical context they include. Some pharmacovigilance systems send only the mandatory PES and PEO with a bare PCR; others include a full drug history and supporting lab work. Confirm a partner's field population against their interface specification rather than assuming the base standard.
FHIR equivalent
A product-experience report conceptually corresponds to the FHIR AdverseEvent resource, with the patient as a Patient resource, the suspect product referenced as a Medication 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 PEX_P07 or PEX_P08 and no ConceptMap for the PES, PEO, or PCR segments. A FHIR AdverseEvent produced from a PEX message is therefore mapped manually, taking the event description and seriousness criteria from PEO, the suspect product and causal assessment from PCR, and the supporting observations from OBX.
Common pitfalls
Pitfall. Routing solely on the message type and ignoring the trigger event in
MSH-9.PEX^P07andPEX^P08carry identical segment structures but opposite case-management semantics — processing an update as an initial submission opens a duplicate case, and processing an initial submission as an update silently discards it.
Pitfall. Discarding seriousness flags from
PEOwhen they are all N. An all-N seriousness profile is itself meaningful for a regulatory submission — it indicates a non-serious event and determines the reporting timeline. Store every flag explicitly rather than omitting seriousness data when no flag is set to Y.
Pitfall. Assuming a single product per report. The PCR group repeats within each PEO, so a single adverse event can implicate multiple suspect products — a combination therapy, for example. Processing only the first PCR segment silently loses all but the first suspect product.
How Vorro handles PEX messages
Vorro ingests the PEX feed over MLLP or another transport, deduplicates on MSH-10, and routes on MSH-9 to open a new case for PEX^P07 or update an existing one for PEX^P08. Vorro preserves the full EXPERIENCE group hierarchy — mapping PES to the reporting organisation, each PEO to a discrete adverse event, and each PCR to a suspect product with its causal assessment — so multi-event, multi-product reports round-trip without loss. Seriousness flags from PEO are stored individually and surfaced to the regulatory timeline logic. Where a FHIR destination is configured, Vorro maps the report to an AdverseEvent resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- ADT — the admit/discharge/transfer messages that establish the patient and encounter context a PEX report references.
- ORU — the observation result message that carries the laboratory and clinical findings supporting a causal assessment.
- BAR — the add/change billing account message that may be relevant when a reportable adverse event generates a billing or claim event.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for PEX_P07 or PEX_P08
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for PES, PEO, or PCR
- HL7 Messaging Standard Version 2.5.1 product brief
