HL7 SUR messages carry an aggregate product-experience report — a summary roll-up of adverse events and other product observations that a manufacturer or facility consolidates for regulatory reporting, rather than the individual case reports carried by PEX. An SUR message reports counts and distribution data across many products and many facilities in a single transmission: how many devices or drug units were in distribution, in which countries, and from which reporting facilities the underlying observations originated. This page explains what an SUR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an SUR summary relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an SUR message represents
An SUR message — SUR stands for Summary Product Experience Report — communicates a consolidated summary of product-experience observations rather than a single case. The core of the message is the PSH segment, which carries the data for one summarised product report: the report type in PSH-1, the report form identifier in PSH-2, the report date in PSH-3, the product information block in PSH-9, and the product status in PSH-10. Each PSH summarises one product's experience over the reporting interval; an SUR can carry many.
SUR is an unsolicited summary report: it is sent on a regulatory or contractual schedule, not in reply to a query. The FAC segment identifies each reporting facility — its identifier, type, address, telecommunication contact, and named contact person — and the PDC segment carries country-level product distribution data: the manufacturer identifier in PDC-1, the country in PDC-2, the brand in PDC-3, the product introduction date in PDC-7, and the number of products in distribution in PDC-12. The sender is typically a manufacturer, post-market surveillance system, or pharmacovigilance aggregator; the receiver is a regulator or a regulatory submission gateway. Because the summary aggregates events that have already been observed, PSH is the heart of the report while FAC and PDC carry the reporting-facility and distribution context that situates the counts.
When an SUR message is sent
An SUR message is sent on a reporting cadence — periodically (for example monthly or quarterly) or when an aggregate threshold is reached — to consolidate the product-experience observations that would otherwise be reported individually as PEX cases. The sender gathers the matching observations across the reporting interval, computes the product- and country-level counts, attaches the reporting facilities, and transmits a single SUR message.
Trigger event
The SUR message type carries a single trigger event:
SUR^P09– Summary product experience report.
Because SUR has one trigger event, the receiver's handling turns on the report type in PSH-1 and the product status in PSH-10 — what kind of summary this is and what state the product is in — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows a manufacturer or pharmacovigilance system consolidating product-experience observations and sending the summary through the integration engine to a regulator.
{{diagram: manufacturer / pharmacovigilance system → SUR summary → integration engine → regulator / submission gateway}}
Typical senders: manufacturer reporting system, post-market surveillance application, pharmacovigilance aggregator.
Typical receivers: regulator, regulatory submission gateway, or downstream safety data warehouse.
Direction: unsolicited, sender-initiated — the SUR travels from the reporting organisation to the regulator on a reporting cadence rather than in reply to a query.
Segments in an SUR message
The SUR_P09 message opens with MSH and then carries one or more FACILITY groups; each facility group opens with FAC and contains one or more PRODUCT groups built around PSH. Within each product group, a FACILITY_DETAIL group repeats the reporting-facility identification as needed, and a PRODUCT_DETAIL group built around PDC carries country-level distribution data. 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 SUR message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (SUR^P09), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10. |
FAC | Facility. Opens each facility group and identifies a reporting facility whose observations contribute to the summary — the facility identifier in FAC-1, the facility type in FAC-2, the address in FAC-3, the telecommunication contact in FAC-4, the named contact person in FAC-5, the contact's title in FAC-6, and the facility ID-FAC in FAC-9. Required, and the facility group repeats once per reporting facility. |
PSH | Product Summary Header. Opens each product group and is the heart of the summary. It declares the report type in PSH-1, the report form identifier in PSH-2, the report date in PSH-3, the product information block in PSH-9, and the product status in PSH-10. Required, and the product group repeats once per summarised product. |
[{FAC}] | Facility (detail). Within the FACILITY_DETAIL group inside the product group, additional reporting-facility identifications tied to this specific product summary. Optional and repeating; present when a product's observations come from facilities beyond the one that opened the facility group. |
PDC | Product Detail Country. Opens the PRODUCT_DETAIL group and carries country-level distribution data for the summarised product — the manufacturer identifier in PDC-1, the country in PDC-2, the brand in PDC-3, the product introduction date in PDC-7, and the number of products in distribution in PDC-12. Required when the product detail group is present. |
[{PSD}] | Product Service Description. Describes a product service or section associated with the summarised product, qualifying the distribution counts that follow. Optional and repeating within the product detail group. |
[{PDC}] | Product Detail Country (additional). Additional country-level distribution records for the same product — one per country in which the product is distributed. Optional and repeating, so a single PSH can be followed by a PDC per country. |
[ ] = optional, { } = repeating
The facility group from FAC onward repeats, and within it the product group from PSH repeats, so a single SUR message can summarise many products reported from many facilities. The canonical segment pages carry the full field-by-field detail.
Sample SUR message
Note. Constructed for illustration. Facility identifiers, manufacturer numbers, dates, and counts are fictional.
MSH|^~&|PV|MERCYGEN|FDA|FDA|202006150930||SUR^P09^SUR_P09|MSG00118|P|2.5.1
FAC|FAC001^MERCYGEN|H|123 MAIN ST^^BOSTON^MA^02118^USA||SMITH^JANE^A|DIRECTOR OF SAFETY||||FAC001
PSH|PR|RPT2026Q2|202006150000|||||| MED-DEV-X^Infusion Pump Model X^MFR | A
PDC|MFR12345^ACME MED|USA|MED-DEV-X^Infusion Pump Model X^MFR||||201801010000||||| 4500
PDC|MFR12345^ACME MED|CAN|MED-DEV-X^Infusion Pump Model X^MFR||||201803010000||||| 850
What this sample shows
The SUR^P09 in MSH-9 marks a summary product experience report. The opening FAC identifies the reporting facility FAC001 at MercyGen — a hospital (FAC-2 = H), at 123 Main St, with Jane Smith as the named safety contact. The PSH opens the product group: report type PR (PSH-1), report form identifier RPT2026Q2 (PSH-2), report date 20200615 (PSH-3), product information for the Infusion Pump Model X (PSH-9), and product status A — active — in PSH-10. The first PDC gives the USA distribution: manufacturer MFR12345 ACME MED (PDC-1), country USA (PDC-2), brand MED-DEV-X (PDC-3), product introduction date 20180101 (PDC-7), and 4500 products in distribution (PDC-12). The second PDC carries the equivalent record for Canada with 850 units in distribution.
Working with SUR messages
Read the summary from PSH, not from individual cases
The product-experience counts and report metadata live in PSH, not in any embedded case report. SUR is a roll-up; it does not carry the individual observations a PEX message would. Reconcile against PSH-1 (report type), PSH-3 (report date), and PSH-10 (product status) rather than expecting case-level fields.
Link counts to context through FAC and PDC
A count without context is unusable. Tie each summarised product to its reporting facilities through the opening FAC and any FACILITY_DETAIL FAC repetitions, and tie its distribution to country through the repeating PDC — a product reported in multiple countries carries one PDC per country, each with its own PDC-12 distribution count.
Product status drives downstream handling
PSH-10 records whether the product is active, withdrawn, suspended, or otherwise constrained. Surface this on the report record rather than treating every summarised product as actively distributed — a withdrawn product's distribution counts mean something different from an active product's.
Reporting cadence and form identifier
PSH-2 carries the report form identifier and PSH-3 the report date. Use these together to deduplicate against prior submissions on the same form — the same form id with the same report date should not be ingested twice as new observations.
Vendor variance. The PRODUCT_DETAIL group built around
PDCis optional, and some senders omit country-level distribution entirely when the summary is intended only as a status report. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A product-experience summary corresponds, conceptually, to a FHIR Bundle of AdverseEvent summaries or to a custom Measure resource that consolidates product-experience counts over a reporting period, with the patient role taken by the affected product rather than an individual.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for SUR_P09, and the PSH, PDC, and FAC segments have no published ConceptMaps. A FHIR representation of an SUR is therefore composed manually, taking the report metadata from PSH, the reporting-facility identification from FAC, and the country-level distribution counts from PDC, and shaping them into a Bundle of AdverseEvent summaries or a Measure resource according to the regulatory destination's expectations.
Common pitfalls
Pitfall. Treating an SUR as a case-level report. SUR carries aggregate counts in
PSHandPDC, not individual observations; expanding each summarised product into one case record inflates the data with phantom events.
Pitfall. Ignoring product status in
PSH-10. Counting distribution for a withdrawn or suspended product as though it were active misrepresents post-market exposure.
Pitfall. Assuming a single country per product. The PRODUCT_DETAIL group repeats
PDConce per country; reading only the firstPDCunderstates total distribution.
How Vorro handles SUR messages
Vorro reads the report metadata from PSH, aggregates the reporting facilities from the opening FAC and any FACILITY_DETAIL repetitions, and walks the repeating PDC records to assemble the country-level distribution counts before routing the summary to every subscribed destination in the format that system expects — the regulatory submission gateway and downstream safety warehouse. Vorro deduplicates on the report form identifier in PSH-2 and the report date in PSH-3, surfaces the product status from PSH-10, and, where a FHIR destination is configured, maps the summary to a Bundle of AdverseEvent summaries or a Measure resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- PEX — the individual product experience report; SUR aggregates what PEX reports case-by-case.
- ORU — the observation result message that carries the underlying observations a product-experience summary may roll up.
- CSU — the unsolicited clinical study data message, another aggregate report used in regulated reporting contexts.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for SUR_P09
- HL7 v2-to-FHIR IG — segment maps index — confirms no published ConceptMaps for PSH, PDC, or FAC
- HL7 Messaging Standard Version 2.5.1 product brief
