Håll DPP-data aktuella: Vad ESPR faktiskt kräver

Hur ofta måste DPP-data uppdateras? Vad ESPR-förordningen konkret kräver, var praktiken brister – och vilka tekniska mönster som fungerar.

av QR3 Redaktion

Håll DPP-data aktuella: Vad ESPR faktiskt kräver

Frågan låter banal, men är det inte: Hur ofta måste ett digitalt produktpass uppdateras? Den som letar efter ett konkret tal i ESPR-förordningen (EU) 2024/1781 blir besviken. Texten föreskriver endast att DPP måste innehålla ”aktuell och korrekt information” – utan frekvens, utan SLA och utan teknisk specifikation. Vad det innebär i praktiken beror i hög grad på produkttypen, leveranskedjan och de delegerade rättsakter som fortfarande ska utfärdas för varje produktkategori.

Den här artikeln förklarar vilka datakategorier som över huvud taget kan ändras, vilka uppdateringsmönster som fungerar i tidiga implementeringar och var de regulatoriska fallgroparna finns.


Vad som över huvud taget kan ändras i ett DPP

Ett produktpass är ingen statisk PDF. Det består av datapunkter med mycket olika livscykler.

Statiska kontra dynamiska data

I grova drag kan DPP-fält delas in i tre klasser:

Datakategori Typisk ändringsfrekvens Exempel
Grunddata En gång (vid produktlansering) GTIN, materialsammansättning, tillverkare
Parti-/batchdata Per produktionskörning PCF-värde, råvaruursprung, certifikat
Livscykeldata Händelsestyrd Reparationshistorik, återkallelse, avfallshanteringsväg

Datautkastet från JRC för stålprodukter tydliggör denna skillnad särskilt väl: Det produktspecifika CO₂-avtrycket (PCF) anges uttryckligen på partinivå och måste beräknas med ISO 14067-kompatibla metoder. Det innebär att varje ny produktionsbatch kan ha ett annat PCF-värde – passet måste referera korrekt till detta värde, inte till föregående års genomsnitt.

Batteriexemplet som förebild

Det digitala batteripasset, som blir obligatoriskt från och med 18 februari 2027, visar hur dynamiska DPP-data kan vara. Branschrapporter om implementeringen av det digitala batteripasset identifierar datafragmentering och dynamiska datauppdateringar som de två centrala praktiska problemen. Batterier samlar data under hela sin livslängd: State of Health (SoH), laddningscykler och reparationshändelser. Den som arbetar med ett statiskt dataset här uppfyller inte förordningen.


Uppdateringsmönster: Så fungerar implementeringar i dag

Händelsestyrda uppdateringar via webhook

Det mest robusta mönstret i tidiga DPP-system är den händelsestyrda uppdateringen: Ett backend-system skickar en webhook så snart en relevant datapunkt ändras – till exempel när ett nytt testcertifikat utfärdas eller en reparation slutförs.

// Beispiel: Webhook-Handler für DPP-Update
app.post('/webhook/dpp-update', async (req, res) => {
  const { passportId, field, newValue, timestamp } = req.body;

  await dppRepository.patchField(passportId, {
    [field]: newValue,
    lastUpdated: timestamp,
  });

  await auditLog.append(passportId, { field, newValue, timestamp });
  res.status(204).send();
});

Viktigt: ESPR kräver implicit möjlighet till ett revisionsspår. Ändringar måste förbli spårbara – enkel överskrivning utan versionshantering innebär regulatoriska risker.

Batchuppdateringar för partiinformation

När PCF-värden eller certifikat uppdateras för hela produktionsbatcher på en gång lämpar sig ett bulkimportförfarande. Då överförs en lista med passnummer tillsammans med det nya fältvärdet:

# Beispiel: Bulk-PATCH via CLI
curl -X PATCH https://api.example.com/v1/dpp/bulk \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": { "batchId": "BATCH-2026-06-A" },
    "patch": {
      "carbonFootprint": 1.84,
      "carbonFootprintMethod": "ISO 14067:2018",
      "certifiedAt": "2026-06-15"
    }
  }'

Plattformar som qr3.app med bulkimport stöder detta mönster, så att varje batch inte behöver uppdateras manuellt.

En ofta underskattad aspekt: QR-koden på produkten får inte ändras – den är fysiskt tryckt. Det som måste ändras är innehållet som den pekar på. Det är precis här som GS1 Digital Link utgör det avgörande abstraktionslagret. QR-koden kodar en stabil URI (t.ex. https://id.example.com/01/04012345678901/21/SN-00042), och resolverfunktionen vidarebefordrar till den aktuella datakällan.

Driscoll's demonstrerade på GS1 Connect 2026 hur denna princip fungerar i stor skala: Över en miljard Berry-clamshells försågs med unika identiteter och migreras nu till helt GS1 Digital Link-kompatibla QR-koder. Koden på förpackningen förblir oförändrad; det som ändras är datasetet bakom resolverfunktionen.

Ny teknik, som partnerskapet mellan Polytag och DataLase, visar att GS1-kompatibla QR-koder numera kan appliceras även på svåra förpackningssubstrat i produktionslinjens hastighet – det fysiska hindret minskar, medan resolverlogiken bakom förblir densamma.


Regulatoriska fallgropar

EmpCo-direktivet som ytterligare påtryckning

Den som tror att det räcker att bevaka ESPR underskattar helheten. Europeiska kommissionen inledde i juni 2026 överträdelseförfaranden mot 20 medlemsstater på grund av bristande genomförande av EmpCo-direktivet (EU) 2024/825. Direktivet förbjuder greenwashing och kräver tydlig information om hållbarhet och reparerbarhet – information som ska integreras direkt i DPP. Föråldrade reparerbarhetsindex eller ogiltiga hållbarhetsmärkningar i passet kan därmed inte bara utgöra en ESPR-överträdelse, utan även en överträdelse av EmpCo.

Ingen uttrycklig uppdateringsfrist – men underförstådda skyldigheter

Att ESPR saknar en frekvensangivelse är ingen frisedel. Av formuleringen ”aktuell och korrekt information” kan flera underförstådda skyldigheter härledas:

  • Händelsebunden aktualitet: Så snart en återkallelse, reparation eller certifikatändring inträffar måste passet uppdateras – utan dröjsmål.
  • Partibunden aktualitet: PCF-värden och råvarudokumentation får inte överföras från en gammal batch till en ny om värdena skiljer sig åt.
  • Överensstämmelse med marknadskontrollen: Myndigheter måste kunna hämta passet under produktens hela livscykel. Ett pass som aldrig uppdateras efter försäljningen är värdelöst för reparations- och avfallsinformation.

Ecommerce Europe rekommenderar uttryckligen i sitt policydokument ett stegvis införande och flexibel datagranularitet – vilket indirekt innebär att uppdateringsprocesser kan byggas iterativt så länge kärnkraven uppfylls.


Praktiska rekommendationer

Planera in en revisionslogg från början

Varje ändring i ett DPP-dataset bör loggas med tidsstämpel, upphovsperson och ändringsorsak. Detta är i dag inget uttryckligt ESPR-krav, men förväntas i de delegerade rättsakterna och är i praktiken nödvändigt för marknadskontrollen.

Resolverarkitektur före dataarkitektur

Den som först fastställer datastrukturen och sedan funderar på hur QR-koden ska peka på den bygger i fel ordning. Rätt ordning är: definiera resolver-URI:n (GS1 Digital Link), därefter dat schema och sedan uppdateringsprocesser. Det digitala produktpasset på qr3.app följer denna princip: QR-koden är stabil, datasetet bakom är versionshanterat och kan patchas.

Använd parti-ID:n konsekvent

Den som hanterar PCF-värden eller certifikat på produktnivå i stället för på partinivå får senast vid den första marknadskontrollen problem. Batch-ID:t bör vara ett obligatoriskt fält i varje DPP-dataset – inte ett valfritt metadatafält.

Den regulatoriska situationen är komplex, men de tekniska mönstren går att hantera. Det avgörande är att inte behandla uppdateringsbarhet som en funktion i efterhand, utan som en arkitekturprincip från dag ett.

Källor