HL7 PES Product Experience Sender
HL7 field reference PES 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 |
|---|---|---|---|---|---|
| PES.1 | Sender Organization Name | No | Yes | XON | |
| PES.2 | Sender Individual Name | No | Yes | XCN | |
| PES.3 | Sender Address | No | Yes | XAD | |
| PES.4 | Sender Telephone | No | Yes | XTN | |
| PES.5 | Sender Event Identifier | No | No | EI | |
| PES.6 | Sender Sequence Number | No | No | NM | |
| PES.7 | Sender Event Description | No | Yes | FT | |
| PES.8 | Sender Comment | No | No | FT | |
| PES.9 | Sender Aware Date/Time | No | No | TS | |
| PES.10 | Event Report Date | Yes | No | TS | |
| PES.11 | Event Report Timing/Type | No | Yes | ID | 0234 |
| PES.12 | Event Report Source | No | No | ID | 0235 |
| PES.13 | Event Reported To | No | Yes | ID | 0236 |
PES identifies the sender and submission context for a product-experience report.
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 PES 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.
PES-1 identifies an organization, clinic, facility, department, or company involved in this product-safety report. Keep the organization identifier and display name separate when the datatype supports it.
Repeats should represent genuinely separate organizations or aliases, not several fragments of the same name.
PES-2 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.
PES-3 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.
PES-4 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.
PES-5 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.
PES-6 identifies the Sender Sequence Number 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.
PES-7 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.
PES-8 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.
PES-9 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.
PES-10 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.
PES-11 qualifies the product-safety report rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0234. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
PES-12 carries Event Report Source 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 0235; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PES-13 carries Event Reported To 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 0236; many real interfaces narrow that list further, so follow the receiver's implementation guide.