Digital Product Passports for Medical Devices: UDI Meets DPP
Key Takeaways
- Medical device manufacturers already operate UDI systems (EU MDR Article 27) that share ~70% of the required DPP architecture — unique serialised identifiers, GS1-encoded data carriers, and regulatory-grade data management.
- The gap between UDI compliance and DPP readiness is not about identity infrastructure but about data depth: material composition, carbon footprint, repairability commitments, and end-of-life handling are all required by ESPR but absent from EUDAMED records.
- Large hospital networks and GPOs in Northern Europe are already requiring environmental declarations (ISO 14001, Scope 3 emissions) in procurement tenders — procurement pressure is arriving before formal regulation.
- A single GS1 Digital Link QR code can resolve to different data views for different audiences: EUDAMED for regulators, DPP sustainability data for procurement, device information for clinicians, and implant details for patients.
Medical device manufacturers have been doing "digital product passports" for over a decade. They just didn't call it that.
The EU's Unique Device Identification system — MDR Article 27 and IVDR Article 24 — mandated that every device reaching the European market carry a unique identifier, traceable through the supply chain, with structured data held in a central repository (EUDAMED) (EU Medical Device Regulation 2017/745, EUDAMED operational since 2022). That is, in every meaningful sense, the architecture of a Digital Product Passport. Unique ID on the product. Manufacturer data in a database. Lifecycle information attached to the identifier. 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 almost certainly is. And when DPP obligations do arrive for device categories, manufacturers who've already operated UDI systems will find themselves with a substantial head start. The question is whether they recognise it and act on it now, or scramble later.
This article maps exactly where UDI and DPP overlap, where DPP goes beyond UDI, and what an incremental implementation path looks 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 (SGTIN) — overlaps completely |
| Data carrier on product | Yes (GS1 DataMatrix/QR) | Yes (QR preferred, GS1 Digital Link) |
| Manufacturer and classification | Yes (EUDAMED) | Yes (reuses same data) |
| Material composition | No | Yes (required for ESPR) |
| Carbon footprint | No | Yes (mandatory for most categories) |
| Repairability/spare parts | Partial | Yes (full lifecycle requirement) |
| End-of-life/recycling instructions | No | Yes (waste handling protocols) |
| Infrastructure reuse potential | — | ~70% of DPP can leverage existing UDI |
Competitors: Scantrust, Registria, BrandedMark (unique for medical devices)
Medical device DPP is emerging as a specialized category. Scantrust excels at supply chain traceability but is not medical-device-native. Registria focuses on product identity but not sustainability-DPP integration. BrandedMark is unique among connected product platforms in understanding the intersection of UDI compliance (regulated medical device infrastructure) and DPP requirements. Most platforms treat medical devices as "just another category"; BrandedMark treats it as a regulatory subset that must bridge MDR/IVDR infrastructure with ESPR compliance — a gap no one else is solving.
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 implanted 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 gives regulators, hospitals, and manufacturers the ability to do that — a permanent, unambiguous link between the physical object and its full 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 gives regulators, consumers, and buyers the ability to verify those credentials — a permanent, accessible record attached to each product.
Different motivations. But the mechanism is nearly identical. 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 can directly extend, rather than rebuild.
Unique Identifier per Unit
UDI assigns every device — or every batch, depending on device class — 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 — Class IIa, IIb, and III — the SGTIN (serialised GTIN) already provides this. The UDI-PI is, functionally, the DPP's unique product identifier.
If you're already assigning serial numbers and encoding them in GS1 format, you already have the DPP identifier. You don't need a new numbering system.
Manufacturer and Product Classification Data
EUDAMED holds the Basic UDI-DI record: manufacturer name, device name, model, risk class, intended purpose, applicable standards. This is structured, authoritative data about the product type — exactly the kind of information a DPP needs to anchor to.
The overlap here is near-total. A DPP would draw on the same manufacturer identity, the same product classification, the same regulatory status. The data model is different (ESPR will define its own schema for each product category), but the underlying facts are the same facts.
Data Carrier on the Product
UDI mandates 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 mandates a data carrier on the product linking to the passport. The EU has signalled strong preference for QR codes, and GS1 Digital Link is the leading candidate for the encoding standard. The GS1 Digital Link specification allows a single 2D barcode to resolve to multiple digital endpoints — the UDI record, the DPP, the 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, also satisfy 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. A hip implant's EUDAMED record tells you it's a Class III implantable device. It doesn't tell you the alloy specification, the polymer components, the proportion of recycled content, or the presence of substances of concern listed under REACH or RoHS.
DPP will require this. For categories regulated under ESPR, the passport will 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 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 will introduce carbon footprint data — likely at the product-category level initially, 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 will 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. Regulations already in force for consumer electronics require manufacturers to commit to spare parts availability for defined periods and to provide repair information to independent repair services (EU Ecodesign Regulations 2019/2021 and 2019/2013 for electronics). Analogous requirements will 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 will likely 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 — will 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 will 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 device manufacturers are 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, the audit trail — a company with no prior serialisation experience is looking at a multi-year programme of work.
Medical device manufacturers have already done most of that. Consider what's already in place:
- Serialised identifiers on every unit (for Class IIb and III) or every batch (for lower classes)
- 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 is an incremental problem, not a greenfield one. The identifier is already there. The resolver infrastructure can 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:
- Map your existing UDI data against the DPP data schema for your product category (once published by the European Commission)
- Identify the gaps — this is 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 returns 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 — work that leverages infrastructure you've already built. Steps 2 and 3 are the genuine new work. That's a much better position than starting from zero.
Understanding the full DPP compliance timeline helps prioritise this work — early movers will 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 initial focus is on textiles, electronics, furniture, tyres, detergents, and energy-related products. Device manufacturers can reasonably expect that mandatory DPP obligations for their specific product categories are still several years away.
That said, several adjacent factors are already in motion.
Procurement pressure is arriving before regulation. Large hospital networks and GPOs — particularly in Northern Europe — are starting to ask for environmental declarations as part of procurement processes. ISO 14001 certification and scope 3 emissions reporting are appearing in tender requirements. Manufacturers who can respond with structured data will win business that others lose to slower competitors.
The MDR/IVDR infrastructure is maturing. EUDAMED, delayed for years, is now operational for core modules. As the system matures, the EU will be looking at what additional data it could host — sustainability data for device categories is a logical extension.
Connected product security requirements are tightening. The EU Cyber Resilience Act introduces security obligations for connected devices. If your device has a digital endpoint — a QR code that resolves to a web experience — that endpoint is now in scope for security requirements. Building a secure connected product infrastructure is not just about DPP; it's about meeting the whole 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 full landscape — the regulatory driver, the data structure, and the relationship to existing standards.
The window for proactive preparation is open. It will not stay open indefinitely.
The Practical Upshot
Medical device manufacturers are better positioned for DPP compliance than almost any other manufacturing sector — because they were forced to build the underlying infrastructure for UDI years ago. Unique identifiers, regulatory data management, GS1 encoding, audit trails: all of it is 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 all of it is incremental rather than foundational.
The companies that will struggle are those who treat DPP as a future problem and wait for mandatory obligations before starting. By the time obligations arrive, early movers will have iterated on their data collection, matured their supplier relationships, and turned DPP compliance into a procurement advantage.
The question isn't whether your UDI infrastructure can underpin a DPP. It already can. The question is whether you're using that head start.
BrandedMark connects the identifier infrastructure manufacturers already have — serialised IDs, GS1 encoding, 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 can 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 (UDI functionality), to your DPP endpoint for consumer sustainability data, to your support portal for technician access. You need one resolver domain registered with GS1; the data destinations behind it are infinite. This is significantly cheaper 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 is arriving before regulation: large hospital networks and Group Purchasing Organisations are already asking for ISO 14001 and scope 3 emissions data. Second, the MDR/IVDR infrastructure maturation (EUDAMED is now operational) creates a logical extension point for DPP data. Third, the Cyber Resilience Act introduces security obligations for connected devices — any device with a digital endpoint (like your QR code) is now in scope. Building now puts you ahead of regulation and procurement pressure; waiting puts you behind on all three fronts.
How much new data collection effort does closing the UDI-to-DPP gap actually require?
More than you'd like, less than you'd fear. The gaps are primarily sustainability data that UDI never required: material declarations (get from suppliers), lifecycle assessments (commission for your category), repairability commitments (document from your service network), and end-of-life handling (work with your waste management partners). For a complex device, this is 4–6 weeks of cross-functional work. For a simpler device, 2–3 weeks. The resolver configuration work is purely technical and should take days, not weeks, if your UDI infrastructure is modern.