HL7 PDC Product Detail Country
HL7 field reference PDC 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 |
|---|---|---|---|---|---|
| PDC.1 | Manufacturer/Distributor | Yes | Yes | XON | |
| PDC.2 | Country | Yes | No | CE | |
| PDC.3 | Brand Name | Yes | No | ST | |
| PDC.4 | Device Family Name | No | No | ST | |
| PDC.5 | Generic Name | No | No | CE | |
| PDC.6 | Model Identifier | No | Yes | ST | |
| PDC.7 | Catalogue Identifier | No | No | ST | |
| PDC.8 | Other Identifier | No | Yes | ST | |
| PDC.9 | Product Code | No | No | CE | |
| PDC.10 | Marketing Basis | No | No | ID | 0330 |
| PDC.11 | Marketing Approval ID | No | No | ST | |
| PDC.12 | Labeled Shelf Life | No | No | CQ | |
| PDC.13 | Expected Shelf Life | No | No | CQ | |
| PDC.14 | Date First Marketed | No | No | TS | |
| PDC.15 | Date Last Marketed | No | No | TS |
PDC carries country-specific product detail, especially for product safety and regulatory 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 PDC 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.
PDC-1 helps identify the product, software, device, or equipment involved. It is particularly useful when support needs to trace behaviour back to a specific build, lot, instrument, or manufacturer.
If more than one identifier is sent, each repetition should stay attached to the product or device context it belongs to.
PDC-2 is used for reconciliation. The receiver may compare it with the segments, batches, messages, rows, or items actually received, so do not populate it from a stale estimate.
PDC-3 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.
PDC-4 helps identify the product, software, device, or equipment involved. It is particularly useful when support needs to trace behaviour back to a specific build, lot, instrument, or manufacturer.
PDC-5 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.
PDC-6 identifies the Model 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.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
PDC-7 identifies the Catalogue 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.
PDC-8 identifies the Other 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.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
PDC-9 identifies the Product 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.
PDC-10 carries Marketing Basis 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 0330; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PDC-11 identifies the Marketing Approval ID 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.
PDC-12 carries Labeled Shelf Life 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.
PDC-13 carries Expected Shelf Life 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.
PDC-14 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.
PDC-15 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.