Håll DPP-data aktuellt: så fungerar uppdateringsprocessen

Det digitala produktpasset (DPP) är inget statiskt dokument. Skapar du ett och glömmer bort det riskerar du efterlevnadsluckor — över en mycket lång tidshorisont: ESPR-förordningen (EU) 2024/1781 kräver att registerposter förblir tillgängliga och aktuella i minst 10 år efter att en produkt senast släpptes ut på marknaden. Den här artikeln förklarar vilka datalager som finns, när var och ett behöver uppdateras och hur du implementerar processen rent ur ett tekniskt perspektiv.

De tre lagren i ett DPP — och vem som underhåller dem

Ett komplett DPP består av minst tre logiskt separata lager, vart och ett med sin egen uppdateringskadens.

1. Registerpost (identifierare + resolver)

Det centrala DPP-registret — vars genomförandeförordning Europeiska kommissionen publicerade i utkastform den 29 april 2026 — lagrar uteslutande:

produktens unika identifierare (UID) — i praktiken en GS1 GTIN eller en ISO/IEC 15459-kompatibel kod,
resolverns slutpunkt, dvs. den URL där det faktiska passinnehållet kan hämtas,
den tillhörande varukoden.

Det här lagret ändras sällan. En uppdatering behövs framför allt när resolverns slutpunkt ändras — till exempel för att ett företag byter DPP-tjänsteleverantör eller migrerar en domän. Eftersom QR-koden på den fysiska produkten pekar till den här posten måste resolverns kontinuitet garanteras utan avbrott.

2. Resolverkonfiguration (länkdirigering)

Resolvern översätter en inkommande skanning till rätt destinations-URL — beroende på kontext, språk eller användarroll. Organisationer som använder GS1 Digital Link kan dirigera till olika dataset via strukturerade länktyper (t.ex. gs1:sustainabilityInfo, gs1:epcis).

Uppdateringar i det här lagret behövs när:

nya obligatoriska fält införs genom delegerade akter (t.ex. förordningarna för textil och batterier som väntas från och med 2026/2027),
destinations-URL:er ändras,
nya språkversioner eller marknadsregioner läggs till.

3. Produktdata (det faktiska passinnehållet)

Det är här den verkliga substansen finns: materialsammansättning, reparerbarhetsindex, koldioxidavtryck, deklarationer av farliga ämnen, garantiinformation. Det här lagret har den högsta uppdateringsfrekvensen eftersom det beror på verkliga händelser i produktens livscykel.

När behöver DPP-data uppdateras?

ESPR-förordningen anger inga fasta uppdateringsintervall. I stället gäller principen om dataaktualitet: informationen måste återspegla produktens faktiska tillstånd. Detta ger upphov till flera praktiskt relevanta utlösande faktorer:

Regulatoriska ändringar

Så snart en delegerad akt inför nya datakrav måste befintliga pass uppdateras därefter. Detta är ingen teoretisk framtidsfråga: ett batteripass enligt den separata batteriförordningen tillämpas från 18 februari 2027, och för textil är antagandet av den delegerade akten under ESPR preliminärt planerat till 2027.

För batteritillverkare innebär detta: från och med augusti 2026 måste alla batterier som säljs i EU bära märkning som omfattar kapacitet, kemi och farliga ämnen, och från och med den 18 februari 2027 en QR-kod — samtidigt som batteripass blir obligatoriskt för batterier för lätta transportmedel, industribatterier med en kapacitet på mer än 2 kWh och elfordonsbatterier. EU:s batteriförordning är därför ett av de första verkliga storskaliga testerna av DPP-uppdateringsprocessen.

Produktändringar

Om en produkts materialsammansättning ändras — även när GTIN förblir densamma — måste DPP uppdateras. Detsamma gäller för:

nya reparationsanvisningar eller reservdelskällor,
reviderade garantivillkor,
uppdaterade säkerhetsdatablad.

Återkallelser eller säkerhetsvarningar

Säkerhetsrelevant information måste registreras utan dröjsmål. DPP är inte en ersättning för RAPEX-systemet för snabb varning, men det är en kompletterande kanal som kan användas av både konsumenter och tillsynsmyndigheter.

Teknisk uppdateringsprocess: steg för steg

Steg 1: Tydliggör identifierare och versionshantering

Varje ändring av passinnehåll bör versionshanteras. En kombination av följande rekommenderas:

Produkt-UID (oföränderlig, t.ex. GTIN + serienummer),
Passversion (semantiskt versionsnummer eller tidsstämpel),
Orsak till ändring (regulatorisk, produktrelaterad, korrigerande).

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

Steg 2: Uppdatera endast det berörda datalagret

Ett vanligt misstag är att skriva om hela passposten när en regulatorisk uppdatering inträffar. Detta ökar risken för fel och gör ändringar svårare att spåra. Ett bättre tillvägagångssätt: använd en modulär datastruktur där enskilda datafält kan uppdateras oberoende av varandra.

Om du arbetar via ett API, använd HTTP PATCH i stället för PUT:

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

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

Steg 3: Säkerställ resolverns tillgänglighet

En uppdatering som tillfälligt tar resolvern offline är kritisk ur ett efterlevnadsperspektiv. ESPR:s krav på 10 års tillgänglighet lämnar inget utrymme för driftstopp utan en reservlösning. Rekommenderade metoder inkluderar:

Blue-green-deployment för resolveruppdateringar,
övervakning av resolverns slutpunkt med larm vid HTTP-felkoder ≥ 400,
regelbunden verifiering av att den slutpunkt som registrerats i registret faktiskt är nåbar.

Steg 4: Massuppdateringar för stora produktportföljer

Den som hanterar hundratals eller tusentals produkter kommer inte undan en strukturerad massimport-process. Den centrala principen: ändringar bör behandlas som differentiella uppdateringar (deltaimporter) snarare än fullständiga importer, för att minimera felkällor och bevara spårbarhet.

Ett typiskt CSV-format för en deltauppdatering kan se ut så här:

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

Särskilda överväganden för textil och debatten om rättvis handel

För textiltillverkare medför ESPR-tidslinjen särskilda utmaningar. Fair Trade-rörelsen har i sina rekommendationer om den delegerade akten för textil efterlyst att DPP:ets dataarkitektur ska vara hanterbar även för små och medelstora företag och småbrukare i tredjeländer. Detta har direkta konsekvenser för uppdateringsprocessen: när data från leveranskedjan kommer från aktörer som inte har direkt API-åtkomst är robusta manuella eller halvautomatiska dataregistreringsvägar avgörande.

Detta visar att uppdateringsprocessen inte bara är en teknisk fråga utan också en organisatorisk: Vem är behörig att ändra vilka data? Vem validerar ändringar? Hur integreras leverantörer i processen?

GS1 Digital Link som möjliggörare av uppdateringar

GS1:s generalförsamling 2026, som i Warszawa fokuserade på den globala övergången till 2D-streckkoder, understryker denna poäng: GS1 Digital Link är den föredragna mekanismen för att koppla produktidentiteter till aktuellt innehåll. Den centrala fördelen för uppdateringsprocessen: QR-koden på produkten förblir oförändrad — bara innehållet bakom resolvern ändras. Det är just detta som överhuvudtaget gör retroaktiva uppdateringar av produkter som redan sålts på marknaden möjliga.

I takt med att Sunrise 2027-deadlinen för 2D-streckkoder inom detaljhandeln närmar sig, närmar sig också den punkt då varumärken inte längre kan skjuta upp GS1 Digital Link-QR-koder — både för efterlevnad inom detaljhandeln och för DPP-krav.

Slutsats: uppdateringsförmåga är ingen funktion — det är ett krav

ESPR-förordningen behandlar DPP:et som ett levande dokument. Den som planerar en implementering idag måste bygga in uppdateringsprocesser från start: versionshanterade datastrukturer, modulära API:er, stabila resolvrar och tydliga styrningsregler för dataändringar. De första datumen — batteripass från den 18 februari 2027 och det planerade antagandet av den delegerade akten under ESPR för textilier under 2027 — ligger tillräckligt nära att den tekniska förberedelsen bör inledas nu.