SIST EN 18223:2026

SLOVENSKI STANDARD
01-julij-2026
Digitalni potni list izdelka - Interoperabilnost sistema
Digital Product Passport - System interoperability
Digitaler Produktpass - System-Interoperabilität
Passeport numérique des produits - Interopérabilité du système
Ta slovenski standard je istoveten z: EN 18223:2026
ICS:
13.020.20 Okoljska ekonomija. Environmental economics.
Trajnostnost Sustainability
35.240.63 Uporabniške rešitve IT v IT applications in trade
trgovini
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 18223
NORME EUROPÉENNE
EUROPÄISCHE NORM
May 2026
ICS 13.020.20
English version
Digital Product Passport - System interoperability
Passeport numérique des produits - Interopérabilité Digitaler Produktpass - System-Interoperabilität
du système
This European Standard was approved by CEN on 3 May 2026.
This European Standard was corrected and reissued by the CEN-CENELEC Management Centre on 2 June 2026.

CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and United Kingdom.

CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2026 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. EN 18223:2026 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Semantic interoperability . 6
4.1 Semantic model . 6
4.1.1 General . 6
4.1.2 Semantic model of the digital product passport . 6
4.2 Data model requirements to manage DPP changes .12
4.3 Model for repositories for the data dictionaries .12
5 Technical interoperability .13
5.1 General .13
5.2 Serialization syntax .13
5.2.1 General .13
5.2.2 Naming conventions and built-in types .13
5.2.3 JSON built-in types for values .13
5.2.4 Serialization of the DigitalProductPassport class .14
5.2.5 Serialization of a DataElementCollection .14
5.2.6 Serialization of a SingleValuedDataElement .15
5.2.7 Serialization of a MultiValuedDataElement .15
5.2.8 Serialization of a RelatedResource .16
5.2.9 Serialization of a MultiLanguageDataElement .16
Annex A (normative) Expanded full data model serialized in JSON.17
Annex B (normative) Data model compressed serialization in XML .21
Annex ZA (informative) Relationship between this European Standard and the essential
requirements of (EU) Regulation 2024/1781 aimed to be covered .24
Bibliography .25
European foreword
This document (EN 18223:2026) has been prepared by Technical Committee CEN/CLC/JTC 24 “Digital
product passport – Framework and system”, the secretariat of which is held by DIN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by November 2026, and conflicting national standards shall
be withdrawn at the latest by November 2026.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a standardization request addressed to CEN by the European
Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
Member States.
For relationship with EU Legislation, see informative Annex ZA, which is an integral part of this document.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the United
Kingdom.
Introduction
0.1 Background
A digital product passport (DPP) is a key enabling mechanism to make product information traceable and
accessible across value chains - supporting economic operators, manufacturers, distributors, repairers,
recyclers and consumers to make informed decisions and to support a circular economy. The
implementation of digital product passports will be carried out progressively. Sector-specific initiatives
will determine the precise DPP content and requirements for individual product groups.
To support the implementation of DPPs, 8 standards have been developed so far:
— EN 18219:2026 – Digital product passport – Unique identifiers
— EN 18220:2026 – Digital product passport – Data carriers
— EN 18216:2026 – Digital product passport – Data exchange protocols
— EN 18222:2026 – Digital Product Passport – Application Programming Interfaces (APIs) for the
product passport lifecycle management and searchability
— EN 18223:2026 – Digital Product Passport – System interoperability (this document)
— EN 18221:2026 – Digital product passport – data storage, archiving, and data persistence
— EN 18239:— – Digital Product Passport – access rights management, information system security,
and business confidentiality
— EN 18246:— – Digital Product Passport – Data authentication, reliability and integrity
0.2 Organizational interoperability
Organizational interoperability covers the following aspects:
— easy integration into existing technology frameworks;
— human and machine (software) access.
0.3 Semantic interoperability
Semantic interoperability covers the following aspects:
— allow data structuring with standardized or established data schema languages;
— enable the usage and re-usage of known ontologies or context namespaces;
— avoid sector specific ontologies – allow parallel usage of different ontologies issued by the European
Commission in delegated acts with a horizontal layer as general as possible (technology, ontology and
domain agnostic).
0.4 Technical interoperability
Serialization of data with standardized data format.

Under preparation. Stage at the time of publication: prEN 18239:2025.
Under preparation. Stage at the time of publication: prEN 18246:2025.
1 Scope
The scope of this document includes:
— the semantic description of a product, including its properties where relevant and the semantic
aspects to represent the product lifecycle;
— a common information model allowing for the implementation of data dictionary systems;
— metadata models and formats to be used in exchange and representation, allowing for the integration
of dictionaries;
— rules on how to systematically use such metadata models when developing product group specific
data models and dictionaries;
— technical and organizational interoperability.
This document follows the approach of standard interoperability layers and proposes the following
aspects in this regard.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 8601-1:2019, Date and time — Representations for information interchange — Part 1: Basic rules
EN 18219:2026, Digital product passport - Unique identifiers
EN 18221:2026, Digital product passport - data storage, archiving, and data persistence
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at http://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
3.1
interoperability
capability of two or more entities to exchange items in accordance with a set of rules and mechanisms
implemented by an interface in each entity, in order to perform their specified tasks
[SOURCE: ISO 18435-1:2009 [1], 3.12]

As impacted by ISO 8601-1:2019/A1:2022.
3.2
semantic interoperability
ability for data shared by systems to be understood at the level of fully defined domain concepts
[SOURCE: ISO 18308 [2], 3.45]
3.3
technical interoperability
ability that covers the applications and infrastructures linking systems and services
3.4
digital product passport
DPP
digital record of product characteristics throughout its life cycle
Note 1 to entry: Example characteristics include environmental sustainability, environmental impact, and
recyclability.
3.5
digital product passport id
DPP ID
unique identifier of an instance of the digital product passport
4 Semantic interoperability
4.1 Semantic model
4.1.1 General
This document uses UML class diagrams ISO/IEC 19505-2 [3] to illustrate the core concepts of a product
and DPP, their data, properties and their relationships. A JSON representation is provided in Clause 5. If
there are discrepancies between the UML diagrams, text and JSON representations the prose text of
Clause 4, including the tables, is authoritative.
4.1.2 Semantic model of the digital product passport
4.1.2.1 Digital product passport
The model presented below in Figure 1 defines what the entities are that compose a digital product
passport instance and the data points it is required to include.
Figure 1 — UML representation of the entities of the semantic model of the DPP
Figure 1 presents the base semantic model of a digital product passport.
The digital product passport is modelled through the class DigitalProductPassport as a digital container
that contains zero to many DataElements.
The model is structured based on the following principles:
— DataElement is an abstract class. It represents the generic concept of a data point. As an abstract class,
it is the common superclass for all other classes, and it is never used directly in a DPP instance.
— DataElementCollection: A concrete subclass of DataElement (see 4.1.2.3) that acts as a container for a
set of other named DataElements. This allows for creating complex structures with mixed data types,
as it can contain SingleValuedDataElements (see 4.1.2.5), MultiValuedDataElements (see 4.1.2.6),
RelatedResource (see 4.1.2.7), and other nested DataElementCollections (see 4.1.2.4).
— SingleValueDataElement: This is the simplest concrete subclass of DataElement. It represents a single
unit of information (see 4.1.2.5).
— MultiValuedDataElement: A concrete subclass of DataElement that contains an ordered list of other
DataElements, all of which shall be of the same type. For example, it can contain a list of
SingleValueDataElements (like an array of numbers) or a list of DataElementCollections (like an array
of similar objects) (see 4.1.2.4).
— Other Concrete subclasses: MultiLanguageDataElement (see 4.1.2.8) and RelatedResource (see
4.1.2.7) are other specialized subclasses of DataElement, used for representing a value in multiple
languages or linking to an external resource, respectively.
The following data points (see Table 1) shall be published as attributes of a digital product passport
instance:
Table 1 — Attributes of the DigitalProductPassport class
Attribute name Description DataType Cardinality
digitalProductPassportId unique identifier of an String [1]
instance of the digital
product passport
uniqueProductIdentifier unique string of characters String formatted according [1]
for the identification of a to EN 18219:2026
product, that also enables a
web link to the digital
product passport
granularity level of granularity of the Enumeration [1]
uniqueProductIdentifier
according to 4.1.2.2
dppSchemaVersion reference standard the String [1]
DPP instance schema
refers to
dppStatus status of the DPP instance String [1]
as digital resource
lastUpdated date and time of the latest String formatted as [1]
update to the DPP instance Timestamp
UTC- based according to
ISO 8601-1:2019
economicOperatorId unique string of characters String formatted according [1]
for the identification of an to EN 18219:2026
actor involved in a
product’s life cycle
facilityId unique string of characters String formatted according [0.1]
for the identification of to EN 18219:2026
locations or buildings
involved in a product’s
value chain or used by
actors involved in a
product’s life cycle
contentSpecificationIds reference to horizontal or String [0.*]
product-type related
content specifications for
the DPP
{DataElement} data elements of DPP DataElement (abstract) [0.*]
as per 4.1.2.3
EXAMPLE Example values for the “dppStatus” attribute are:
—  active,
—  inactive,
—  archived,
—  invalid
Any further enumeration value provided by relevant legal acts.
The digitalProductPassportId shall be globally unique and should be based on a URI/URL structure.
{DataElement} is a placeholder for additional content or other attributes of the DPP. The notation
{} means that the naming is not fixed. This includes data points mentioned in ESPR [4], Annex III
and not included in Table 1.
4.1.2.2 Enumeration
Some of the attributes required by the DigitalProductPassport class are enumerations whose values are
predetermined.
The values allowed for the “granularity” attribute are:
— model,
— batch,
— item.
4.1.2.3 DataElement
The DataElement is an abstract class which is the base class for its concrete subclasses:
DataElementCollection (4.1.2.4) SingleValuedDataElement (4.1.2.5), MultiValuedDataElement (4.1.2.6),
RelatedResource (4.1.2.7) and MultiLanguageDataElement (4.1.2.8). It specifies the following attributes
(see Table 2).
Table 2 — Definition of DataElement attributes
Attribute Name Description Datatype Cardinality
The relative identifier of the
DataElement shall be unique
within its location (i.e. in the
DPP or in the level of
DataElementCollection or
elementId MultiValuedDataElement) and it String [1]
is recommended to be unique
in the DPP instance. The
corresponding absolute path of
the data element shall be
unique within the DPP instance.
The reference to the unique
[0.1]
identifier of the data point
dictionaryReference String
specification defined in the
repository/data dictionary
4.1.2.4 DataElementCollection
The DataElementCollection is a collection of DataElements included in the digital product passport entity.
It contains at least one DataElement. This class inherits the attributes elementId and dictionaryReference
from the abstract DataElement class.
The DataElementCollection is an object and as such it can contain semantically different objects. A
DataElementCollection shall contain at least one instance of a DataElement's subclasses
(DataElementCollection, SingleValuedDataElement, MultiValuedDataElement or RelatedResource).
4.1.2.5 SingleValuedDataElement
The SingleValuedDataElement represents a single data point with one value. This class inherits the
attributes elementId and dictionaryReference from the abstract DataElement class and adds the following
specific attributes (see Table 3).
Table 3 — Definition of SingleValuedDataElement attributes
Name Description Datatype Cardinality Example
Contains the data < any JSON
of the value datatype > as
value [1]
encapsulated in described in
the DataElement Clause 5
Specifies the data
type of the value String as
valueDataType needed for the described in [0.1] “xsd:integer”
interpretation of 4.1.2.9
the value data
4.1.2.6 MultiValuedDataElement
The MultiValuedDataElement is a list which contains similar objects of the same data type.
It contains at least one or many DataElements. This class inherits the attributes elementId and
dictionaryReference from the abstract DataElement class and adds the following specific attributes (see
Table 4).
Table 4 — Definition of MultiValuedDataElement attributes
Name Description Datatype Cardinality Example
Specifies the data
type of the value String as
valueDataType needed for the described in [0.1] “xsd:integer”
interpretation of 4.1.2.9
the value data
[DataElement] Data elements of DataElement [0.*]
the same type (abstract)
within the multi
as per 4.1.2.3
valued data
element
[DataElement] is a placeholder for additional content or other attributes of the MultiValuedDataElement.
4.1.2.7 RelatedResource
The RelatedResource is the semantic representation of any instance of a document or certificate that can
be required to be included into a digital product passport instance. This class inherits the attributes
elementId and dictionaryReference from the abstract DataElement class and adds the following specific
attributes (see Table 5).
Table 5 — Definition of RelatedResource attributes
Name Description Datatype Cardinality Example
The IANA Media
Type/MIME type
contentType String [1] “application/pdf”

String formatted as
The link to the
url URL according to [1]
resource
RFC 3986 [5]
String formatted as
localized language tag
with: two (2)
characters language
“en-GB”
The language of
code as in
language the resource, if [0.1] “de-DE”
ISO 639:2023 [6] (e.g
applicable
“de-AT”
“en”), and two (2)
characters country
code as in EN
ISO 3166-1:2020 [7]
Human readable
“Maintenance
resourceTitle title of the String [0.1]
manual”
resource
Additionally, it can include other attributes if required by the relevant legal acts.
4.1.2.8 MultiLanguageDataElement
4.1.2.8.1 General
The MultiLanguageDataElement represents a language dependent data point whose value varies with
respect to the language associated with it. It contains at least one or many MultiLanguageValues (see
4.1.2.8.2). This class inherits the attributes elementId and dictionaryReference from the abstract
DataElement class.
4.1.2.8.2 MultiLanguageValue
The MultiLanguageValue represents a language dependant value. It includes the following metadata
attributes (see Table 6).
Table 6 — Attributes of the MultiLanguageValue object
Name Description Datatype Cardinality Example
Contains the data of
“a product
value the value in the String [1]
description”
MultiLanguageValue
Name Description Datatype Cardinality Example
String formatted as
localized language tag
with: two (2)
Specifies the
“en-gb”
characters language
language of the value
language code as in ISO 639:2023 [1] “de-de”
within the
[6] (e.g “en”), and two
“de-at”
MultiLanguageValue
(2) characters country
code as in EN
ISO 3166-1:2020 [7]
4.1.2.9 Value data type
The valueDataType should allow XSD data types conformant to W3C XML Schema [8] and [9] except:
— the XSD data types that represent a list of values within a single whitespace-separated string (i.e.
ENTITIES, IDREFS, and NMTOKENS) shall not be supported.
— XSD string derived built-in types shall not be supported, and
— the following XSD primitive types shall not be supported: NOTATION, QName.
— base64 binary may be supported
4.2 Data model requirements to manage DPP changes
During its lifetime, the digital product passport may undergo changes that impact the data points to be
declared, like for example the environmental performance. These changes could lead to a modification of
the DPP initially published for a product, either through a change of an existing property or document, or
through the addition of information or a property not in the initial instance. To be properly archived,
every digital product passport lifetime event resulting into a change to a DPP should be kept track of.
Data include for example:
— identifier (e.g. digitalProductPassportId, uniqueProductIdentifier);
— timestamp (when the change occurred);
— actor as per EN 18239 [10] (who made the change);
— changed properties (specific properties modified).
Any changes to a DPP shall be logged and archived according to EN 18221:2026 requirements. Delegated
acts can define to what extent.
4.3 Model for repositories for the data dictionaries
To enable cross-sector semantic interoperability for digital product passport, while avoiding constraints
on how DPP information may be defined and ensuring openness to different technologies (or
technological approaches), a decoupled approach shall be applied. In this approach, data points and their
definitions are managed independently.
Each data point should be associated with a machine-readable semantic definition stored in a repository.
The governance of such repository should be regulation-based, but shall allow for the inclusion of
definitions beyond regulatory requirements where appropriate. Each definition shall have a unique
identifier and shall occur only once within a repository to enable unambiguous referencing. This also
allows for mapping between definitions contained in different semantic catalogues (repositories).
This approach con
...