DPP-Hold data opdaterede: Hvad ESPR faktisk foreskriver

Siden vedtagelsen af ESPR-forordningen (EU) 2024/1781 er Digital Product Passport (DPP) bindende EU-ret. Hvad mange virksomheder undervurderer: DPP er ikke et statisk dokument, der oprettes én gang ved markedsføringen. Det skal holdes opdateret gennem hele produktets livscyklus — og kravene hertil bliver stadig mere præcise.

Denne artikel forklarer, hvilke data der skal opdateres hvornår, hvordan registerarkitekturen påvirker opdateringsmodellen, og hvilke tekniske mønstre der fungerer i praksis.

Hvad forordningen siger om opdateringscyklussen

Statiske kontra dynamiske datafelter

ESPR angiver ikke selv en eksplicit opdateringsfrekvens, men fastslår, at DPP skal indeholde „aktuelle og nøjagtige oplysninger". Konkretiseringen sker på sektorniveau — og her giver JRC-udkastet for halvfabrikata af jern og stål det hidtil tydeligste billede.

Udkastet skelner systematisk mellem to datagranulariteter:

Niveau	Identifikator	Eksempeldata	Anledning til opdatering
Batchniveau (Lot)	Lotnummer	Genanvendt andel, legeringssammensætning, PCF efter ISO 14067	Ved produktionsændring, ny batch
Produktniveau (Item)	Serienummer	Mål, certificeringer, overensstemmelseserklæringer	Ved recertificering, tilbagekaldelse, reparation

Denne sondring er afgørende for databasearkitekturen: Batchdata skrives typisk én gang pr. produktionskørsel og er derefter stabile — medmindre en efterberegning af CO₂-aftrykket giver en korrigeret værdi. Data på produktniveau kan derimod ændre sig gennem hele brugsperioden, f.eks. hvis en enhed repareres, eller en certificering fornyes.

Batteriforordningen (EU) 2023/1542 indeholder allerede implicit denne sondring: Kapacitetsdata, der ændres som følge af degradering, skal holdes opdaterede — et krav, der næppe kan opfyldes uden en klar arkitektur.

Registeret som katalog, ikke som datalager

En hyppig misforståelse vedrører rollen for det centrale DPP-register. Udkastet til gennemførelsesforordningen om DPP-registeret gør det klart: Registeret gemmer udelukkende den entydige identifikator, resolver-endpointet og varekoden — ikke selve passets data.

Det betyder for opdateringsstyringen: Passets indhold og registeret er separate systemer. Når produktdata opdateres, er det som regel ikke nødvendigt at ændre registeret — medmindre resolver-endpointet ændres (f.eks. ved et systemskifte). CIRPASS-2-konsortiet har i sin udtalelse om registerudkastet eksplicit peget på dette arkitekturmønster og anbefaler, at standarden EN 18219 optages som bindende reference i gennemførelsesforordningen — blandt andet for at sikre interoperabilitet med GS1 Digital Link.

Opdateringsscenarier i praksis

Scenarie 1: Nyt CO₂-aftryk efter leverandørskifte

Det produktspecifikke CO₂-aftryk (PCF) vedligeholdes på batchniveau i henhold til JRC-udkastet om stål og skal beregnes med ISO 14067-kompatible metoder. Hvis en stålproducent skifter energikilde eller skrotleverandør, ændres PCF'en for den nye batch — men ikke for de allerede leverede batches.

Teknisk betyder det: DPP-datasættet for den gamle batch forbliver uændret. Der oprettes et nyt datasæt for den nye batch, som kan bruge samme resolver-endpoint, men har et nyt lotnummer som identifikator.

# 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}
  }'

Scenarie 2: Udløbende certificering på produktniveau

Overensstemmelseserklæringer og certificeringer har udløbsdatoer. Så snart en ny certificering udstedes, skal DPP opdateres på produktniveau. Da resolver-endpointet forbliver uændret, er ingen registeropdatering nødvendig — kun datasættet bag endpointet ændres.

// 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,
  });
}

Scenarie 3: Resolver-migrering ved systemskifte

Hvis en virksomhed skifter sin DPP-tjenesteudbyder, ændres resolver-endpointet. I så fald skal registeret opdateres — for hver berørt identifikator. Det er den mest krævende opdateringstype, fordi den kræver en skrivning til registeret.

Anbefaling: Brug en stabil, egen resolver (f.eks. dpp.ihrunternehmen.de) som mellemlag, der internt videresender til den pågældende tjenesteudbyder. På den måde forbliver endpointet, der er registreret i registeret, permanent stabilt.

Tekniske krav til opdateringssystemet

Versionering og revisionsspor

ESPR kræver ikke eksplicit versionering, men kombinationen af produktansvar og toldkontrol gør et revisionsspor reelt uundværligt. Hvis en toldembedsmand i 2030 kontrollerer DPP for en stålbjælke produceret i 2027, skal det kunne dokumenteres, hvilke data der var gældende på importtidspunktet.

Minimalt skema for en versioneret 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 som stabil identifikatorforankring

GS1 Digital Link adskiller identifikator og resolver klart: QR-koden på produktet koder en URL som https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, der via GS1-resolveren eller en egen resolver peger på det aktuelle DPP-datasæt. Opdateringer af datasættet kræver ingen ny mærkning — det fysiske medie forbliver uændret.

TEKLYNX har opdateret sin CODESOFT-software og understøtter nu GS1-„++"-kodningsskemaer, som gør det muligt at skrive web-URL'er direkte i RAIN-RFID-taggenes hukommelse — et krav, der følger af kombinationen af EN 18220 og GS1 Digital Link-standarden.

Governance: Hvem må opdatere hvad?

Ud over det tekniske spørgsmål opstår governance-spørgsmålet: Hvilke aktører i forsyningskæden må skrive hvilke felter i DPP? CIRPASS-2-konsortiet har identificeret kritiske spørgsmål om datasuverænitet i grænseoverskridende forsyningskæder.

En praktisk model skelner mellem tre roller:

Producent (Creator): Skriver alle felter ved oprettelsen og må opdatere alle felter.
Autoriseret aktør (Editor): Må opdatere definerede felter (f.eks. reparationshistorik, nye certificeringer) — dokumenteret med egen identifikator.
Læser (Reader): Kan læse alle offentlige felter, men har ingen skriverettigheder.

Ecommerce Europe har i sit holdningspapir om DPP-implementeringen krævet, at der også for brugte produkter skal være mulighed for „delvise DPPs" — altså datasæt, der kun opdaterer en del af de oprindelige felter. Det kan allerede gennemføres teknisk i dag, men mangler stadig som formel kategori i gennemførelsesforordningerne.

Konklusion

Det er ikke en engangsopgave at holde DPP-data opdaterede, men en driftsproces. De vigtigste indsigter fra den aktuelle reguleringsstatus:

Adskil batch og produkt — identifikatorstrategien afgør, hvilke data der skal opdateres hvornår.
Registeret er ikke et datalager — opdateringer af passets indhold kræver som regel ingen skrivning til registeret.
Versionering er reelt obligatorisk — også selv om forordningen ikke udtrykkeligt foreskriver det.
GS1 Digital Link adskiller fysisk medie og datasæt — det reducerer arbejdet med dataopdateringer betydeligt.
Governance-roller skal defineres på forhånd — hvem må skrive hvad, og hvordan logføres det?

Standarderne bliver mere præcise, og de første piloter er i gang — den, der etablerer arkitekturen korrekt nu, undgår dyre korrektioner, når de sektorspecifikke gennemførelsesforordninger træder i kraft.