HL7 SUR_P09 Summary Product Experience Report
SUR_P09 is the summary side of the HL7 v2 product experience reporting family. Instead of describing one patient's initial product experience like PEX_P07, it summarizes product experience information for a reporting period, facility, product, country, or other agreed reporting scope.
This is a specialized message. It tends to appear in older product safety, manufacturer, sponsor, and regulatory integrations rather than mainstream hospital integration work.
A small SUR P09 example
What systems do with it
The sender packages summary product experience information for a receiver that tracks complaint volumes, safety signals, post-market surveillance, or regulatory reports. Receivers usually care about the reporting period, the facility, the product, the country, and the summarized counts or notes.
Because this is summary reporting, reconciliation matters. The same reporting interval should not be counted twice unless the interface contract explicitly says a resend replaces an earlier report.
How to read the structure
MSH identifies the message. FAC identifies the facility. PSH carries the product summary header and report period. PDC describes the product detail and country context. NTE can hold supporting notes.
The local imported v2.5.1 structure also includes an ED item in the summary group. Treat that as an attachment or encoded detail placeholder in local implementations, and confirm the receiver's exact expectation before sending real payloads.
Implementation traps
The trap is making this look like a normal clinical message. SUR_P09 is not patient-centered and it is not meant to deliver one observation result. It is a summary report, so keys such as facility, country, product, report period, and sender case policy are the contract.
Also define whether a repeated report is additive, corrective, or replacement. Product safety systems are unforgiving when the same interval is counted twice.
Reference notes
HL7 v2 lists SUR_P09 as the summary product experience report in the product experience reporting family. This page is intentionally compact because real implementations are usually governed by a receiver-specific safety or regulatory profile.