DPP-gegevens actueel houden: zo werkt het updateproces

Het Digital Product Passport (DPP) is geen statisch document. Maak er een aan en vergeet het, en je loopt het risico op compliance-lacunes — over een zeer lange tijdshorizon: de ESPR-verordening (EU) 2024/1781 vereist dat registervermeldingen beschikbaar en actueel blijven gedurende ten minste 10 jaar nadat een product voor het laatst op de markt is gebracht. Dit artikel legt uit welke gegevenslagen er bestaan, wanneer elke laag moet worden bijgewerkt en hoe je het proces vanuit technisch oogpunt netjes implementeert.

De drie lagen van een DPP — en wie ze onderhoudt

Een volledig DPP bestaat uit ten minste drie logisch gescheiden lagen, elk met een eigen updatecadans.

1. Registervermelding (identifier + resolver)

Het centrale DPP-register — waarvan de Europese Commissie de uitvoeringsverordening op 29 april 2026 in ontwerpvorm publiceerde — slaat uitsluitend het volgende op:

de unieke identifier (UID) van het product — in de praktijk een GS1 GTIN of een ISO/IEC 15459-conforme code,
het resolver-endpoint, oftewel de URL waarop de daadwerkelijke paspoortinhoud kan worden opgehaald,
de bijbehorende goederencode.

Deze laag verandert weinig. Een update is vooral nodig wanneer het resolver-endpoint verandert — bijvoorbeeld omdat een bedrijf van DPP-dienstverlener wisselt of een domein migreert. Aangezien de QR-code op het fysieke product naar deze vermelding verwijst, moet de continuïteit van de resolver zonder onderbreking worden gegarandeerd.

2. Resolver-configuratie (link routing)

De resolver vertaalt een binnenkomende scan naar de juiste bestemmings-URL — afhankelijk van context, taal of gebruikersrol. Organisaties die GS1 Digital Link gebruiken, kunnen via gestructureerde linktypes (bijv. gs1:sustainabilityInfo, gs1:epcis) naar verschillende datasets routeren.

Updates op deze laag zijn nodig wanneer:

er door gedelegeerde handelingen nieuwe verplichte velden worden ingevoerd (bijv. de textiel- en batterijverordeningen die vanaf 2026/2027 worden verwacht),
bestemmings-URL's veranderen,
er nieuwe taalversies of marktregio's worden toegevoegd.

3. Productgegevens (de daadwerkelijke paspoortinhoud)

Hier zit de echte substantie: materiaalsamenstelling, repareerbaarheidsindex, CO2-voetafdruk, declaraties van gevaarlijke stoffen, garantie-informatie. Deze laag heeft de hoogste updatefrequentie omdat ze afhankelijk is van werkelijke gebeurtenissen in de levenscyclus van het product.

Wanneer moeten DPP-gegevens worden bijgewerkt?

De ESPR-verordening schrijft geen vaste update-intervallen voor. In plaats daarvan geldt het principe van gegevensactualiteit: informatie moet de werkelijke toestand van het product weerspiegelen. Daaruit vloeien verschillende praktisch relevante triggers voort:

Regelgevende wijzigingen

Zodra een gedelegeerde handeling nieuwe gegevensverplichtingen invoert, moeten bestaande paspoorten dienovereenkomstig worden bijgewerkt. Dit is geen theoretisch toekomstvraagstuk: de eerste productspecifieke verordeningen voor textiel en batterijen zijn binnen de ESPR-tijdlijn gepland om in 2026 en 2027 van kracht te worden.

Voor batterijfabrikanten betekent dit: vanaf augustus 2026 moeten alle in de EU verkochte batterijen zichtbare QR-codes en labels dragen met informatie over capaciteit, chemie en gevaarlijke stoffen — als voorloper van het volledige batterijpaspoort dat in 2027 verplicht wordt. De EU-batterijverordening is daarmee een van de eerste echte grootschalige tests van het DPP-updateproces.

Productwijzigingen

Wanneer de materiaalsamenstelling van een product verandert — zelfs als de GTIN gelijk blijft — moet het DPP worden bijgewerkt. Hetzelfde geldt voor:

nieuwe reparatie-instructies of bronnen voor reserveonderdelen,
herziene garantievoorwaarden,
bijgewerkte veiligheidsinformatiebladen.

Terugroepacties of veiligheidswaarschuwingen

Veiligheidsrelevante informatie moet onverwijld worden ingevoerd. Het DPP vervangt het RAPEX-snelwaarschuwingssysteem niet, maar vormt een aanvullend kanaal dat zowel door consumenten als door regelgevende autoriteiten kan worden gebruikt.

Technisch updateproces: stap voor stap

Stap 1: identifiers en versiebeheer verduidelijken

Elke wijziging in de paspoortinhoud moet worden voorzien van versiebeheer. Een combinatie van het volgende wordt aanbevolen:

Product-UID (onveranderlijk, bijv. GTIN + serienummer),
paspoortversie (semantisch versienummer of tijdstempel),
reden voor wijziging (regelgevend, productgerelateerd, corrigerend).

{
  "uid": "urn:epc:id:sgtin:4012345.067890.1234567",
  "passVersion": "2.1.0",
  "lastModified": "2026-05-19T10:00:00Z",
  "changeReason": "battery-regulation-aug2026"
}

Stap 2: werk alleen de betrokken gegevenslaag bij

Een veelgemaakte fout is om bij een regelgevende update het volledige paspoortrecord opnieuw te schrijven. Dat verhoogt het risico op fouten en maakt wijzigingen lastiger te traceren. Een betere aanpak: gebruik een modulaire gegevensstructuur waarin afzonderlijke gegevensvelden onafhankelijk kunnen worden bijgewerkt.

Als je via een API werkt, gebruik dan HTTP PATCH in plaats van PUT:

PATCH /api/v1/dpp/{uid}/sections/battery
Content-Type: application/json

{
  "capacityWh": 42.5,
  "chemistry": "LFP",
  "hazardousSubstances": ["Li", "P"],
  "carbonFootprintKgCO2e": 18.3
}

Stap 3: zorg voor beschikbaarheid van de resolver

Een update die de resolver tijdelijk offline haalt, is vanuit compliance-oogpunt kritiek. De 10-jaarsbeschikbaarheidseis van de ESPR laat geen ruimte voor downtime zonder fallback. Aanbevolen praktijken zijn onder meer:

Blue-green deployment voor resolver-updates,
monitoring van het resolver-endpoint met alarmering bij HTTP-foutcodes ≥ 400,
regelmatige verificatie dat het in het register geregistreerde endpoint daadwerkelijk bereikbaar is.

Stap 4: bulkupdates voor grote productportfolio's

Wie honderden of duizenden producten beheert, ontkomt niet aan een gestructureerd bulkimportproces. Het kernprincipe: wijzigingen moeten als differentiële updates (delta-imports) worden verwerkt in plaats van als volledige imports, om foutbronnen te minimaliseren en audittrails te behouden.

Een typisch CSV-formaat voor een delta-update zou er zo uit kunnen zien:

uid,field,newValue,effectiveDate,changeReason
urn:epc:...:001,capacityWh,42.5,2026-08-18,battery-reg-2026
urn:epc:...:002,chemistry,NMC,2026-08-18,battery-reg-2026

Bijzondere overwegingen voor textiel en het fairtradedebat

Voor textielfabrikanten brengt de ESPR-tijdlijn bijzondere uitdagingen met zich mee. De Fair Trade-beweging heeft in haar aanbevelingen over de gedelegeerde handeling voor textiel opgeroepen om de DPP-gegevensarchitectuur ook beheersbaar te maken voor kmo's en kleine boeren in derde landen. Dit heeft directe gevolgen voor het updateproces: wanneer toeleveringsketengegevens afkomstig zijn van actoren zonder directe API-toegang, zijn robuuste handmatige of semi-automatische invoerroutes onmisbaar.

Dit illustreert dat het updateproces niet alleen een technische, maar ook een organisatorische kwestie is: wie is bevoegd om welke gegevens te wijzigen? Wie valideert wijzigingen? Hoe worden leveranciers in het proces geïntegreerd?

GS1 Digital Link als update-enabler

De GS1 General Assembly 2026, in Warschau toegespitst op de wereldwijde overgang naar 2D-barcodes, onderstreept dit punt: GS1 Digital Link is het voorkeursmechanisme om productidentiteiten aan actuele inhoud te koppelen. Het belangrijkste voordeel voor het updateproces: de QR-code op het product blijft ongewijzigd — alleen de inhoud achter de resolver verandert. Juist dat maakt het überhaupt mogelijk om retroactief producten bij te werken die al op de markt zijn verkocht.

Nu de Sunrise 2027-deadline voor 2D-barcodes in de retail nadert, komt het moment dichterbij waarop merken GS1 Digital Link QR-codes niet langer kunnen uitstellen — zowel voor retail-compliance als voor DPP-vereisten.

Conclusie: updatebaarheid is geen feature — het is een vereiste

De ESPR-verordening behandelt het DPP als een levend document. Wie vandaag een implementatie plant, moet updateprocessen vanaf het begin inbouwen: geversioneerde gegevensstructuren, modulaire API's, stabiele resolvers en duidelijke governanceregels voor gegevenswijzigingen. De eerste verplichte deadlines — batterijen vanaf augustus 2026, textiel naar verwachting in 2027 — liggen dicht genoeg in de buurt dat de technische voorbereiding nu zou moeten beginnen.