Digital Product Passports for Medical Devices: UDI Meets DPP
Medical device manufacturers have been doing something close to "digital product passports" for years. They just didn't call it that.
The EU's Unique Device Identification (UDI) system requires devices reaching the European market to carry a unique identifier, traceable through the supply chain, with structured data held in a central database (EUDAMED). That arrangement shares much of the shape of a Digital Product Passport: a unique ID on the product, manufacturer data in a database, lifecycle information attached to the identifier, and a regulatory authority that can pull the record.
Now the EU is building DPP obligations under the Ecodesign for Sustainable Products Regulation (ESPR). Medical devices are not in the first wave of priority categories. But the machinery being built around them may carry over. And when DPP obligations do arrive for device categories, manufacturers who have already operated UDI systems may find themselves with a head start. The question is whether they recognise it and act on it now, or scramble later.
This article maps where UDI and DPP overlap, where DPP goes beyond UDI, and what an incremental implementation path could look like for device manufacturers who want to be positioned ahead of the curve.
| Element | UDI Requirement | DPP Extends To |
|---|---|---|
| Unique identifier per unit | Yes (DI + PI) | Yes, overlaps closely |
| Data carrier on product | Yes (GS1 DataMatrix/QR) | Yes (QR preferred, GS1 Digital Link) |
| Manufacturer and classification | Yes (EUDAMED) | Yes, reuses similar data |
| Material composition | No | Yes, required for ESPR |
| Carbon footprint | No | Yes, for many categories |
| Repairability/spare parts | Partial | Yes, lifecycle requirement |
| End-of-life/recycling instructions | No | Yes, waste handling protocols |
| Infrastructure reuse potential | n/a | A large share of DPP can build on existing UDI |
Two Regulations, One Product
UDI and DPP begin from different regulatory premises, but they converge on the same object: the individual product unit.
UDI was built for patient safety. The logic is straightforward. A device used in a patient needs to be traceable if something goes wrong. Adverse event reports need to reference a specific product, a specific batch, a specific revision. Recalls need to reach the right patients with the right devices. UDI is intended to give regulators, hospitals, and manufacturers a permanent, unambiguous link between the physical object and its device history.
DPP is built for environmental accountability. The logic is equally straightforward, just pointed at a different problem. A product entering the EU market needs to demonstrate its environmental credentials: what it's made of, how it was manufactured, how long it lasts, how it should be disposed of at end of life. ESPR is intended to give regulators, consumers, and buyers a way to verify those credentials through a record attached to each product.
Different motivations. But the mechanism is similar. You need a unique identifier on every product. You need that identifier to link to a structured data record. You need that record to be accessible to authorised parties throughout the product's life. You need the data to be verifiable, not self-reported without accountability.
The difference is what data lives in that record, and the audience for it.
Where UDI and DPP Overlap
Understanding the overlap is more than an academic exercise. It tells you which parts of your existing UDI infrastructure you may be able to extend, rather than rebuild.
Unique Identifier per Unit
UDI assigns a unique identifier combining the Device Identifier (DI) and the Production Identifier (PI). The DI identifies the version or model. The PI identifies the specific unit: lot number, serial number, manufacture date, expiry date.
DPP requires a unique identifier at the product-unit level, linked to a digital record. For serialised devices, the serialised GTIN can already provide this. The UDI production identifier functions, in practice, as a unique product identifier.
If you're already assigning serial numbers and encoding them in GS1 format, you may already have a workable DPP identifier. You don't necessarily need a new numbering system.
Manufacturer and Product Classification Data
EUDAMED holds structured records about the device: manufacturer name, device name, model, risk class, intended purpose, applicable standards. This is authoritative data about the product type, exactly the kind of information a DPP needs to anchor to.
The overlap here is substantial. A DPP would draw on the same manufacturer identity, the same product classification, the same regulatory status. The data model is different, because ESPR will define its own schema for each product category, but the underlying facts are the same facts.
Data Carrier on the Product
UDI requires a data carrier on the label: a GS1 DataMatrix barcode or, increasingly, a QR code encoded to GS1 Digital Link standards. That physical carrier is the bridge between the object in the world and the digital record.
DPP requires a data carrier on the product linking to the passport. The EU has signalled a preference for QR codes, and GS1 Digital Link is a leading candidate for the encoding standard. The GS1 Digital Link specification allows a single 2D barcode to resolve to multiple digital endpoints, such as a UDI record, a DPP, or a product support page, based on who is scanning and why.
In other words, the carrier on the label that satisfies UDI can, with the right resolver configuration, potentially also serve DPP. One scan. Multiple destinations.
Where DPP Goes Further
Acknowledging the overlap shouldn't obscure where DPP introduces genuinely new requirements: data that UDI doesn't touch and that will require new collection processes and systems.
Material Composition
UDI records don't include material composition. An implant's EUDAMED record may tell you its risk class. It doesn't tell you the alloy specification, the polymer components, the proportion of recycled content, or the presence of restricted substances.
DPP is expected to require this. For categories regulated under ESPR, the passport will likely need to identify materials, flag restricted substances, and, for some categories, declare the proportion of recycled or bio-based content. This data doesn't exist in most manufacturers' customer-facing systems today. It typically lives in engineering BOM systems, supplier declarations, and material safety data sheets. Surfacing it into a product-level digital record is a real data engineering exercise.
Carbon Footprint and Energy Consumption
UDI has no sustainability dimension. DPP is expected to introduce carbon footprint data, likely at the product-category level initially, potentially moving toward unit-level lifecycle assessment data over time. Manufacturing energy consumption, transport emissions, use-phase energy draw for powered devices, and end-of-life treatment assumptions could all become part of the record.
For medical device manufacturers, this is particularly complex. Contract manufacturing across multiple jurisdictions, global supply chains for components, and the energy intensity of sterilisation processes all feed into a lifecycle calculation that most companies have never formally produced at the product level.
Repairability and Spare Parts Availability
ESPR places significant weight on repairability. Some product categories already face requirements to commit to spare parts availability for defined periods and to provide repair information to independent repair services. Analogous requirements may follow for other product categories.
For medical devices, this intersects with safety in complex ways: not all repairs can be performed outside authorised service networks. But DPP may require manufacturers to declare the intended service life of the device, the availability of spare parts, and whether independent repair is authorised or restricted and why.
Manufacturers who are already building serialised product experiences, attaching service history to individual serial numbers, may find this data is already being captured. The exercise becomes one of surfacing it in DPP format.
End-of-Life and Recycling Instructions
UDI records don't contain disposal instructions. DPP is expected to require clear information on how the product should be handled at end of life: which components can be recycled, which must be treated as hazardous waste, which contain materials subject to specific collection requirements.
For medical devices, this is particularly relevant given the volume of single-use devices entering waste streams and the complexity of implant retrieval. DPP creates both an obligation and an opportunity: the obligation to provide disposal data, and the opportunity to deliver it in a format that actually reaches the person making the disposal decision, often a hospital waste management team rather than the end patient.
The Implementation Advantage
Here's the business reality that some device manufacturers may be underestimating: standing up a DPP system from scratch is expensive and slow. Building the identifier infrastructure, the data model, the resolver, the data carrier, the regulatory submission processes, and the audit trail is a substantial programme of work for a company with no prior serialisation experience.
Medical device manufacturers have already done much of that. Consider what may already be in place:
- Serialised or batch-level identifiers on units, depending on device class
- Regulatory-grade data on the product (model, revision, manufacturer, certification status) held in EUDAMED
- GS1-encoded data carriers on labels, already readable by standard scanning equipment
- Regulatory submission workflows for updating product data when specifications change
- Audit trail discipline from MDR/IVDR compliance: versioned records, documented change control, traceability to market placement
Extending this infrastructure to carry DPP data may be more of an incremental problem than a greenfield one. The identifier is already there. The resolver infrastructure can potentially be extended. The data carrier already exists on the label. The challenge is filling in the new data fields (sustainability, materials, end-of-life) and connecting those fields to the existing product record.
A reasonable implementation path might look like this:
- Map your existing UDI data against the DPP data schema for your product category, once published by the European Commission
- Identify the gaps, which are primarily the sustainability data that UDI never required
- Build data collection processes for the gaps: engage suppliers for material declarations, commission lifecycle assessments, document repairability commitments
- Extend your resolver configuration so that scanning the existing label can return both UDI data (to EUDAMED) and DPP data (to your passport endpoint)
- Validate against the ESPR technical specification when finalised
Steps 1, 4, and 5 are largely engineering exercises that leverage infrastructure you may already have built. Steps 2 and 3 are the genuine new work. That can be a better position than starting from zero.
Understanding the full DPP compliance timeline helps prioritise this work. Early movers have time to iterate before obligations become mandatory.
The Timeline Picture
Medical devices are not listed in the European Commission's first priority wave for ESPR regulations. The first ESPR working plan (2025 to 2030) prioritises textiles and apparel, furniture, tyres, and mattresses, plus the intermediate materials steel and aluminium (energy-related products continue to carry over from the earlier Ecodesign regime). Device manufacturers can reasonably expect that mandatory DPP obligations for their specific product categories are still some years away.
That said, several adjacent factors are worth watching.
Procurement pressure can arrive before regulation. It is plausible that some large hospital networks and group purchasing organisations will ask for environmental declarations as part of procurement, ahead of any DPP mandate. Where certifications such as ISO 14001 or scope 3 emissions reporting feature in tender requirements, manufacturers who can respond with structured data may be better placed to compete.
The MDR/IVDR infrastructure is maturing. As EUDAMED and the wider MDR/IVDR framework continue to mature, sustainability data for device categories is a plausible extension to consider rather than a settled requirement today.
Connected product security requirements are tightening. The EU Cyber Resilience Act introduces security obligations for connected products. If your device has a digital endpoint, such as a QR code that resolves to a web experience, that endpoint may fall within scope for security requirements. Building a secure connected product infrastructure is not just about DPP; it can also help address the wider stack of digital product obligations coming into force.
What is a DPP, exactly? If you're still building internal understanding of the concept, the foundational explainer on digital product passports covers the landscape: the regulatory driver, the data structure, and the relationship to existing standards.
The window for proactive preparation is open. It may not stay open indefinitely.
The Practical Upshot
Medical device manufacturers may be better positioned for DPP compliance than many other manufacturing sectors, because they were required to build underlying infrastructure for UDI years ago. Unique identifiers, regulatory data management, GS1 encoding, and audit trails are often already in place.
The gap is the sustainability data layer. Filling that gap requires supplier engagement, lifecycle assessment work, and eventually a resolver configuration that surfaces the DPP alongside existing UDI data. None of that is simple, but much of it can be incremental rather than foundational.
The companies that may struggle are those who treat DPP as a future problem and wait for mandatory obligations before starting. By the time obligations arrive, early movers may have iterated on their data collection, matured their supplier relationships, and turned DPP readiness into a procurement advantage.
The question isn't whether your UDI infrastructure can underpin a DPP. The question is whether you're using that head start.
BrandedMark connects the identifier infrastructure manufacturers already have, such as serialised IDs, GS1 encoding, and regulatory data, to the consumer-facing and compliance-facing experiences that DPP requires. If you're mapping your UDI implementation against emerging DPP obligations, the platform is worth a look.
FAQ
Can we reuse our existing UDI resolver for DPP, or do we need a separate one?
You may be able to extend your existing resolver using GS1 Digital Link's multi-endpoint architecture. A single 2D barcode can be configured to resolve to multiple destinations based on scanning context: to EUDAMED for regulatory audits, to your DPP endpoint for sustainability data, or to your support portal for technician access. You typically need one resolver domain registered with GS1, with multiple data destinations behind it. That can be more cost-effective than operating two parallel resolver systems.
We're a Class I medical device manufacturer, does DPP even apply to us yet?
Not yet. Medical devices are not in the initial ESPR priority wave. However, procurement pressure can arrive before regulation: it is plausible that some large hospital networks and group purchasing organisations will ask for environmental data, such as ISO 14001 certification or scope 3 emissions, ahead of any mandate. As the MDR/IVDR framework and EUDAMED continue to mature, they also create a logical point from which DPP data could later be extended. And the Cyber Resilience Act introduces security obligations for connected products, so any device with a digital endpoint such as a QR code may fall within scope. Building now can put you ahead of regulation and procurement pressure; waiting may leave you behind.
How much new data collection effort does closing the UDI-to-DPP gap actually require?
The gaps are primarily sustainability data that UDI never required: material declarations from suppliers, lifecycle assessments commissioned for your category, repairability commitments documented from your service network, and end-of-life handling worked out with your waste management partners. The effort varies with device complexity. The resolver configuration work is largely technical and is often quicker if your UDI infrastructure is modern.