DPP actueel houden: Wat de ESPR werkelijk voorschrijft

Sinds de vaststelling van de ESPR-verordening (EU) 2024/1781 is het Digital Product Passport (DPP) bindend EU-recht. Wat veel bedrijven onderschatten: de DPP is geen statisch document dat eenmalig bij marktintroductie wordt aangemaakt. Het moet gedurende de gehele levenscyclus van het product actueel worden gehouden — en de eisen daarvoor worden steeds concreter.

Dit artikel legt uit welke gegevens wanneer moeten worden bijgewerkt, hoe de registerarchitectuur het updatemodel beïnvloedt en welke technische patronen zich in de praktijk bewijzen.

Wat de verordening zegt over de updatecyclus

Statische versus dynamische gegevensvelden

De ESPR zelf noemt geen expliciete updatefrequentie, maar bepaalt wel dat de DPP „actuele en nauwkeurige informatie" moet bevatten. De concretisering vindt plaats op sectorniveau — en hier biedt het JRC-ontwerp voor halffabricaten van ijzer en staal tot nu toe het duidelijkste beeld.

Het ontwerp maakt systematisch onderscheid tussen twee gegevensgranulariteiten:

Niveau	Identifier	Voorbeeldgegevens	Aanleiding voor update
Chargeniveau (Lot)	Lotnummer	Gerecycled materiaal, legeringssamenstelling, PCF volgens ISO 14067	Bij productiewijziging, nieuwe charge
Productniveau (Item)	Serienummer	Afmetingen, certificeringen, conformiteitsverklaringen	Bij hercertificering, terugroepactie, reparatie

Dit onderscheid is cruciaal voor de databasearchitectuur: chargegegevens worden doorgaans eenmaal per productierun geschreven en zijn daarna stabiel — tenzij een herberekening van de CO₂-voetafdruk een gecorrigeerde waarde oplevert. Gegevens op productniveau kunnen daarentegen gedurende de gehele gebruiksduur veranderen, bijvoorbeeld wanneer een apparaat wordt gerepareerd of een certificering wordt vernieuwd.

De batterijverordening (EU) 2023/1542 kent dit onderscheid al impliciet: capaciteitsgegevens die door degradatie veranderen, moeten actueel worden gehouden — een vereiste die zonder duidelijke architectuur nauwelijks uitvoerbaar is.

Het register als directory, niet als gegevensopslag

Een veelvoorkomend misverstand betreft de rol van het centrale DPP-register. Het ontwerp van de uitvoeringsverordening voor het DPP-register maakt duidelijk: het register slaat uitsluitend de unieke identifier, het resolver-endpoint en de goederencode op — niet de eigenlijke paspoortgegevens.

Dit betekent voor het updatemanagement: paspoortinhoud en register zijn afzonderlijke systemen. Wie productgegevens bijwerkt, hoeft doorgaans het register niet aan te passen — tenzij het resolver-endpoint verandert (bijvoorbeeld bij een systeemwissel). Het CIRPASS-2-consortium heeft in zijn standpunt over het registerontwerp expliciet op dit architectuurpatroon gewezen en adviseert om norm EN 18219 als bindende referentie in de uitvoeringsverordening op te nemen — onder andere om interoperabiliteit met het GS1 Digital Link te waarborgen.

Updatescenario's in de praktijk

Scenario 1: Nieuwe CO₂-voetafdruk door leverancierswissel

De productspecifieke CO₂-voetafdruk (PCF) wordt volgens het JRC-staalontwerp op chargeniveau bijgehouden en moet worden berekend met ISO-14067-compatibele methoden. Als een staalproducent van energiedrager of schrootleverancier wisselt, verandert de PCF van de nieuwe charge — maar niet die van al uitgeleverde charges.

Technisch betekent dit: de DPP-dataset van de oude charge blijft ongewijzigd. Voor de nieuwe charge wordt een nieuwe dataset aangemaakt, die hetzelfde resolver-endpoint kan gebruiken, maar een nieuw lotnummer als identifier heeft.

# Beispiel: Neuen Chargen-Datensatz via API anlegen
curl -X POST https://api.example.com/dpp/lots \
  -H "Content-Type: application/json" \
  -d '{
    "lotId": "LOT-2026-0612-A",
    "productId": "GTIN-04012345678901",
    "pcf_kgCO2e_per_kg": 1.84,
    "pcf_method": "ISO-14067:2018",
    "recycled_content_pct": 42,
    "alloy_composition": {"C": 0.18, "Mn": 1.40, "Si": 0.25}
  }'

Scenario 2: Verlopende certificering op productniveau

Conformiteitsverklaringen en certificeringen hebben vervaldatums. Zodra een nieuwe certificering wordt afgegeven, moet de DPP op productniveau worden bijgewerkt. Omdat het resolver-endpoint ongewijzigd blijft, is geen registerupdate nodig — alleen de dataset achter het endpoint verandert.

// TypeScript-Beispiel: Zertifizierung aktualisieren
interface Certification {
  type: string;
  issuedBy: string;
  validUntil: string; // ISO 8601
  documentUrl: string;
}

async function updateCertification(
  itemId: string,
  cert: Certification
): Promise<void> {
  await dppClient.patch(`/items/${itemId}/certifications`, {
    body: cert,
  });
}

Scenario 3: Resolvermigratie bij systeemwissel

Als een bedrijf van DPP-dienstverlener wisselt, verandert het resolver-endpoint. In dat geval moet het register worden bijgewerkt — en wel voor elke getroffen identifier. Dit is het meest complexe updatetype, omdat hiervoor een register-write nodig is.

Aanbeveling: gebruik een stabiele, eigen resolver (bijv. dpp.ihrunternehmen.de) als tussenlaag, die intern doorstuurt naar de betreffende dienstverlener. Zo blijft het in het register opgenomen endpoint permanent stabiel.

Technische vereisten voor het updatesysteem

Versiebeheer en audittrail

De ESPR vereist geen expliciet versiebeheer, maar de combinatie van productaansprakelijkheid en douanecontrole maakt een audittrail feitelijk onvermijdelijk. Als een douanebeambte in 2030 de DPP van een in 2027 geproduceerde stalen ligger controleert, moet kunnen worden nagegaan welke gegevens op het moment van invoer golden.

Minimaal schema voor een versiebeheerde DPP-tabel:

CREATE TABLE dpp_versions (
  id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  identifier   TEXT NOT NULL,          -- GTIN + Lot/Serial
  valid_from   TIMESTAMPTZ NOT NULL,
  valid_until  TIMESTAMPTZ,            -- NULL = aktuell gültig
  data         JSONB NOT NULL,
  changed_by   TEXT NOT NULL,
  change_reason TEXT
);

CREATE INDEX ON dpp_versions (identifier, valid_from DESC);

GS1 Digital Link als stabiel identifier-anker

De GS1 Digital Link scheidt identifier en resolver netjes: de QR-code op het product codeert een URL zoals https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, die via de GS1-resolver of een eigen resolver verwijst naar de actuele DPP-dataset. Updates van de dataset vereisen geen nieuwe etikettering — de fysieke drager blijft ongewijzigd.

TEKLYNX heeft zijn CODESOFT-software bijgewerkt en ondersteunt nu GS1-„++"-coderingsschema's, waarmee web-URL's rechtstreeks naar RAIN-RFID-taggeheugens kunnen worden geschreven — een vereiste die voortvloeit uit de combinatie van EN 18220 en de GS1 Digital Link-standaard.

Governance: wie mag wat bijwerken?

Naast de technische vraag rijst de governancevraag: welke actoren in de toeleveringsketen mogen welke velden van de DPP schrijven? Het CIRPASS-2-consortium heeft hierbij kritieke punten rond datasoevereiniteit in grensoverschrijdende toeleveringsketens geïdentificeerd.

Een praktisch model onderscheidt drie rollen:

Fabrikant (Creator): schrijft alle velden bij het aanmaken; mag alle velden bijwerken.
Geautoriseerde actor (Editor): mag gedefinieerde velden bijwerken (bijv. reparatiehistorie, nieuwe certificeringen) — gedocumenteerd met een eigen identifier.
Lezer (Reader): kan alle openbare velden lezen, maar heeft geen schrijfrechten.

Ecommerce Europe heeft in zijn position paper over de implementatie van DPP geëist dat ook voor gebruikte producten „partiële DPPs" mogelijk zijn — dus datasets die slechts een deel van de oorspronkelijke velden bijwerken. Dit is technisch nu al uitvoerbaar, maar ontbreekt nog als formele categorie in de uitvoeringsverordeningen.

Conclusie

Het actueel houden van DPP-gegevens is geen eenmalige inspanning, maar een operationeel proces. De belangrijkste inzichten uit de huidige regelgeving:

Scheid charge en product — de identifierstrategie bepaalt welke gegevens wanneer moeten worden bijgewerkt.
Het register is geen gegevensopslag — updates van de paspoortinhoud vereisen doorgaans geen register-write.
Versiebeheer is feitelijk verplicht — ook al schrijft de verordening dit niet expliciet voor.
GS1 Digital Link ontkoppelt fysieke drager en dataset — dat vermindert de inspanning voor gegevensupdates aanzienlijk.
Governancerollen moeten vooraf worden gedefinieerd — wie mag wat schrijven en hoe wordt dat vastgelegd?

De normen worden concreter, de eerste pilots lopen — wie de architectuur nu goed opzet, voorkomt kostbare correcties wanneer de sectorspecifieke uitvoeringsverordeningen in werking treden.