HL7 PSH Product Summary Header
HL7 field reference PSH 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 |
|---|---|---|---|---|---|
| PSH.1 | Report Type | Yes | No | ST | |
| PSH.2 | Report Form Identifier | No | No | ST | |
| PSH.3 | Report Date | Yes | No | TS | |
| PSH.4 | Report Interval Start Date | No | No | TS | |
| PSH.5 | Report Interval End Date | No | No | TS | |
| PSH.6 | Quantity Manufactured | No | No | CQ | |
| PSH.7 | Quantity Distributed | No | No | CQ | |
| PSH.8 | Quantity Distributed Method | No | No | ID | 0329 |
| PSH.9 | Quantity Distributed Comment | No | No | FT | |
| PSH.10 | Quantity in Use | No | No | CQ | |
| PSH.11 | Quantity in Use Method | No | No | ID | 0329 |
| PSH.12 | Quantity in Use Comment | No | No | FT | |
| PSH.13 | Number of Product Experience Reports Filed by Facility | No | Yes | NM | |
| PSH.14 | Number of Product Experience Reports Filed by Distributor | No | Yes | NM |
PSH is the product summary header for product safety or regulatory product reporting.
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 PSH in SUR_P09 - SUR - Summary 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.
PSH-1 qualifies the product-safety report rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
PSH-2 identifies the Report Form Identifier 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.
PSH-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.
PSH-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.
For effective and end dates, make the boundary rule explicit. Receivers need to know whether the value is inclusive, exclusive, planned, actual, or merely informational.
PSH-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.
For effective and end dates, make the boundary rule explicit. Receivers need to know whether the value is inclusive, exclusive, planned, actual, or merely informational.
PSH-6 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
PSH-7 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
PSH-8 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 0329. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
PSH-9 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.
PSH-10 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
PSH-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 0329. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
PSH-12 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.
PSH-13 is a count or total for this product-safety report. Make the counting rule explicit before using it for reconciliation, billing, or workflow limits.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
PSH-14 is a count or total for this product-safety report. Make the counting rule explicit before using it for reconciliation, billing, or workflow limits.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.