HL7 PEO Product Experience Observation
HL7 field reference PEO fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| PEO.1 | Event Identifiers Used | No | Yes | CE | |
| PEO.2 | Event Symptom/Diagnosis Code | No | Yes | CE | |
| PEO.3 | Event Onset Date/Time | Yes | No | TS | |
| PEO.4 | Event Exacerbation Date/Time | No | No | TS | |
| PEO.5 | Event Improved Date/Time | No | No | TS | |
| PEO.6 | Event Ended Data/Time | No | No | TS | |
| PEO.7 | Event Location Occurred Address | No | Yes | XAD | |
| PEO.8 | Event Qualification | No | Yes | ID | 0237 |
| PEO.9 | Event Serious | No | No | ID | 0238 |
| PEO.10 | Event Expected | No | No | ID | 0239 |
| PEO.11 | Event Outcome | No | Yes | ID | 0240 |
| PEO.12 | Patient Outcome | No | No | ID | 0241 |
| PEO.13 | Event Description From Others | No | Yes | FT | |
| PEO.14 | Event From Original Reporter | No | Yes | FT | |
| PEO.15 | Event Description From Patient | No | Yes | FT | |
| PEO.16 | Event Description From Practitioner | No | Yes | FT | |
| PEO.17 | Event Description From Autopsy | No | Yes | FT | |
| PEO.18 | Cause Of Death | No | Yes | CE | |
| PEO.19 | Primary Observer Name | No | Yes | XPN | |
| PEO.20 | Primary Observer Address | No | Yes | XAD | |
| PEO.21 | Primary Observer Telephone | No | Yes | XTN | |
| PEO.22 | Primary Observer's Qualification | No | No | ID | 0242 |
| PEO.23 | Confirmation Provided By | No | No | ID | 0242 |
| PEO.24 | Primary Observer Aware Date/Time | No | No | TS | |
| PEO.25 | Primary Observer's identity May Be Divulged | No | No | ID | 0243 |
PEO records product experience observations, including event, exposure, and outcome details.
The standard describes PEO this way: Details related to a particular clinical experience or event are embodied in the PEO segment. This segment can be used to characterize an event which might be attributed to a product to which the patient was exposed. Products with a possible causal relationship to the observed experience are described in the following PCR (possible causal relationship) segments. The message format was designed to be robust and includes many optional elements which may not be required for a particular regulatory purpose but allow a complete representation of the drug experience if needed. A PEX message can contain multiple PEO segments if the patient experienced more than one event but must contain at least one PEO segment.
Product experience segments support adverse-event, product-quality, exposure, and regulatory-style reporting. They connect the product, sender, observation, possible causal relationship, and summary details.
The goal is traceability. Dates, product identifiers, manufacturer details, event descriptions, seriousness, and relationship assessments need to remain tied together so reviewers can understand the chain.
The v2.5.1 structures show PEO in PEX_P07 - PEX - Unsolicited initial individual product experience report. That tells you where it can appear, but the implementation guide still decides which optional fields are meaningful.
For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.
PEO-1 names the query, event, stored procedure, virtual table, or profile being invoked. This is the semantic switch for the query, so both sides need to agree on the allowed names and their parameter rules.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
PEO-2 identifies the Event Symptom/Diagnosis Code for this product-safety report. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
PEO-3 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PEO-4 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PEO-5 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PEO-6 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PEO-7 carries contact details. Use the datatype components for use code, equipment type, address type, country, and other qualifiers rather than squeezing everything into one formatted string.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
PEO-8 carries Event Qualification for this product-safety report. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0237; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PEO-9 carries Event Serious for this product-safety report. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0238; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PEO-10 carries Event Expected for this product-safety report. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0239; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PEO-11 carries Event Outcome for this product-safety report. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0240; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PEO-12 carries Patient Outcome for this product-safety report. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0241; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PEO-13 is human-readable context. Keep it useful for display and troubleshooting, but do not hide required workflow logic here unless the implementation guide explicitly says the receiver parses it.
Because the field can repeat, separate distinct statements into separate repetitions instead of creating one long hard-to-parse block.
PEO-14 carries Event From Original Reporter for this product-safety report. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
PEO-15 is human-readable context. Keep it useful for display and troubleshooting, but do not hide required workflow logic here unless the implementation guide explicitly says the receiver parses it.
Because the field can repeat, separate distinct statements into separate repetitions instead of creating one long hard-to-parse block.
PEO-16 is human-readable context. Keep it useful for display and troubleshooting, but do not hide required workflow logic here unless the implementation guide explicitly says the receiver parses it.
Because the field can repeat, separate distinct statements into separate repetitions instead of creating one long hard-to-parse block.
PEO-17 is human-readable context. Keep it useful for display and troubleshooting, but do not hide required workflow logic here unless the implementation guide explicitly says the receiver parses it.
Because the field can repeat, separate distinct statements into separate repetitions instead of creating one long hard-to-parse block.
PEO-18 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
PEO-19 identifies a person, provider, staff member, or contact involved in this product-safety report. Use the structured name or provider datatype instead of flattening everything into display text.
When more than one person is sent, repeats should carry role or identifier context so the receiver can tell who did what.
PEO-20 carries contact details. Use the datatype components for use code, equipment type, address type, country, and other qualifiers rather than squeezing everything into one formatted string.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
PEO-21 carries contact details. Use the datatype components for use code, equipment type, address type, country, and other qualifiers rather than squeezing everything into one formatted string.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
PEO-22 carries Primary Observer's Qualification for this product-safety report. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0242; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PEO-23 carries Confirmation Provided By for this product-safety report. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0242; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PEO-24 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PEO-25 carries Primary Observer's identity May Be Divulged for this product-safety report. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0243; many real interfaces narrow that list further, so follow the receiver's implementation guide.