Since May 26, 2021, the effective date of Regulation (EU) 2017/745, the world of medical devices already on the market has been divided into two: devices that benefit from the so-called “grace period” (also known as Legacy devices) and devices for which there is no provision for placing on the market in compliance with Directive 93/42/EEC after May 26, 2021. The latter, in order to continue being placed on the market, must be certified according to MDR.

For all new devices certified according to MDR after May 26, 2021 (including devices in the second case mentioned above), it is necessary to generate a complete UDI code, consisting of the UDI code and the Basic UDI-DI code.

More specifically, for devices compliant with the Regulation and for which a conformity assessment procedure by a Notified Body is required, it is necessary to define at least the Basic UDI-DI code before submitting the certification application. The UDI code will need to be defined before placing on the market.
For those devices that do not require a notified body, both the Basic UDI-DI and the UDI code must be defined before placing on the market.

On the other hand, for Legacy devices (i.e., all those devices for which a certificate of conformity to Directive 93/42/EEC has been issued and which can continue to be placed on the market until the expiry of their CE certificate, or class I devices for which, under the Regulation, a certification process through a Notified Body will be required), it is not necessary to define a UDI code or a Basic UDI-DI code.
As we will see later, although not mandatory, it is still possible to define a UDI code for this type of device.

In summary, class I sterile, I with measuring function, IIa, IIb, and III devices certified according to 93/42/EEC do not require UDI until the expiration of the certificate, after which, if they transition to MDR, they must have it. Class I devices and new devices must already comply with the Regulation from May 26, 2021, and consequently require a complete UDI code from that date.

Adding another level of complexity, considering the above, not all devices for which a UDI code is required must already display it on the label today.

The application of the UDI code on the product for class III medical devices is mandatory already from May 26, 2021; for class IIa and IIb from May 26, 2023, and for class I from May 26, 2025.
In case of direct marking on reusable devices, there will be 2 additional years.

Basic UDI-DI, UDI, UDI-DI, and UDI-PI: some clarity

The multitude and similarity of terms used for the unique coding of devices according to Regulation (EU) 2017/745 leaves one, at first, bewildered or at least confused.

Let’s try to bring some order starting with this hierarchical schematization (where n must be greater than or equal to 1):

Basic UDI-DI
- UDI_1 (UDI-DI_1 + UDI-PI_x)
  - UDI-DI_1 + UDI-PI_A
  - UDI-DI_1 + UDI-PI_B
  - UDI-DI_1 + UDI-PI_C
- UDI_n (UDI-DI_2 + UDI-PI_y)
  - UDI-DI_2 + UDI-PI_D
  - UDI-DI_2 + UDI-PI_E
  - UDI-DI_2 + UDI-PI_F

So a Basic UDI-DI is a code that represents a homogeneous grouping of medical devices produced by a certain Manufacturer, a UDI is a code that identifies a specific product (or packaging level) which in turn is composed of two parts: a static one (UDI-DI, Device Identifier) and a dynamic one (UDI-PI, Production Identifier).

What is the Basic UDI-DI Code and how is it Composed

The Basic UDI-DI code is a unique code assigned to a homogeneous group of medical devices produced by the same manufacturer that share risk class, intended use, and essential design and manufacturing characteristics.
The first two aspects are well defined within the technical file, while for the third, it is the manufacturer itself who, as an expert in the field, has the competence to decide whether two products can be grouped together from this point of view.

Let’s look at a practical case.

The manufacturer Acme Corporation produces surgical masks (class I), titanium hip prostheses (class III), and cobalt-chromium hip prostheses (class III).
The manufacturer in question will certainly need to generate at least two Basic UDI-DI codes considering that the risk classes of the produced devices are different.
The titanium and cobalt-chromium hip prostheses share intended use and risk class. It is up to the manufacturer to assess whether it is appropriate to assign each one its own Basic UDI-DI or to group them under the same one.

Assuming that Acme Corporation decides to define a specific Basic UDI-DI for each category of implantable prosthesis, it will need to issue a total of 3 Basic UDI-DI codes:

XXXXXMASK
XXXXXPROT_TI
XXXXXPROT_CRCO

A further hint to guide us in the choice of grouping multiple codes under the same Basic UDI-DI is given by the use that will be made of this code: it will not appear on the product, but will be used in high-level documents, such as CE certificates, declarations of conformity, and free sale certificates.
Last but not least, in the case of devices for which a Notified Body is required, it will be the Body itself that will accept or not the proposed subdivision during the technical file assessment phase.

The structure of the Basic UDI-DI code, which at the implementation level changes depending on the coding standard being referred to, is nevertheless composed of at least two parts: the first that allows uniquely identifying the manufacturer of the devices that refer to that code (in the previous example, XXXXX uniquely identifies Acme Corporation internationally) and the second that makes each Basic UDI-DI code issued by a single manufacturer unique (in the previous example: MASK, PROT_TI, and PROT_CRCO allow distinguishing the three product groups).

Moreover, the Basic UDI-DI code is the main key information for registrations in the European Eudamed database.

What is the UDI Code and how is it Composed

The UDI code is a unique numeric or alphanumeric code that allows unambiguously identifying the entity being referred to.
A unique UDI is assigned to each device (or its packaging), to each other packaging level provided. Similarly, kits and procedure packs require a dedicated UDI code.
As mentioned earlier, the UDI code is composed of two parts: the UDI-DI and the UDI-PI.

The UDI-DI is the static part of the UDI code and identifies a single device model.

The UDI-DI code is constructed differently depending on the Issuing Agency chosen for its implementation, but in any case, it must contain a part that allows the identification of the manufacturer and one that guarantees its uniqueness compared to all other UDI-DI codes created by the same manufacturer.
Furthermore, the UDI-DI is also used as an access key to the information stored in an Eudamed database.

The UDI-PI is the variable part of the UDI code and collects the information necessary to ensure its traceability.

In particular, if one or more of the following information is contained in the product label, it must be mandatorily included in the UDI-PI code:

Lot number
Serial number
Expiration date
Software identifier

In case only the manufacturing date is present on the label, this must be mandatorily included in the UDI-PI code.
The content of the UDI-PI code can be integrated with other information according to the methods and limits provided by the different coding standards, however, this is not mandatory.
The ways in which the UDI-PI is constructed vary based on the adopted standard.
Considering the information contained in the UDI-PI, it is therefore clear why it is dynamic in nature and that the same device produced at two different time points will have the same UDI-DI but different UDI-PI.

What is the UDI Carrier

The UDI code, unlike the Basic UDI-DI code, must be displayed on the product or its packaging and at all provided packaging levels in its HRI and AIDC forms.

The first (HRI, Human Readable Interpretation) is simply the alphanumeric string that defines the UDI code displayed clearly to be read by the user. The second (AIDC, Automatic Identification and Data Capture) involves the use of technologies for automated data reading. These technologies include barcodes, smart cards, biometrics, and RFID.

Now that we have clarified how the code should be displayed on the label, let’s clarify where.
The UDI code can be contained within the normal marking label or it can have its own label. In both cases, it must be verified that the affixed information remains available and easily readable throughout the useful life of the device and following any cleaning, sanitization, and sterilization activities that may be required.
Generally, the indication of the UDI code (also called code application) on the label requires that the two formats always travel in pairs.

It’s important to remember that the UDI coding in its entirety is a supplementary requirement and does not replace any other marking or labeling requirement provided by the Regulation.

Who Must Obtain the UDI Code

Manufacturers are responsible for generating the UDI coding of their devices using the coding rules provided by one of the four currently recognized standards.

There are some exceptions where other economic operators are required to generate their own UDI coding, in particular:

Systems and procedure packs: before placing a system or procedure pack on the market, the natural or legal person responsible assigns to the system or procedure pack, in accordance with the rules of the issuing entity, a Basic UDI-DI and a UDI code.
Modifications to medical devices already placed on the market: if a distributor, importer, or other natural or legal person should carry out the actions provided for in Article 16 of Regulation (EU) 2017/745, they would assume the obligations provided for the manufacturer, including the obligation to define the UDI coding for the modified product.

Who Issues the UDI Code

The Regulation provides a series of requirements to be met regarding product coding, defining more or less precisely the “what” but, as often happens, does not go into the details of the “how”.

As of today, 4 Issuing Entities are authorized by the European Community (following the Commission Implementing Decision (EU) 2019/939 of 6 June 2019):

GS1 AISBL
Health Industry Business Communications Council (HIBCC)
ICCBBA
Information Office for Proprietary Medicinal Products – IFA GmbH

Regardless of the chosen Entity, the manufacturer, after signing a supply contract, will receive:

A unique identification code that will allow the creation of internationally unique codes;
A standard that provides all the necessary information to construct a complete coding (Basic UDI-DI, UDI-DI, and UDI-PI) according to the rules of the specific Entity.

WHICH ISSUING ENTITY TO CHOOSE?
It’s important to note that all entities are equally valid for complying with the Regulation’s requirements regarding UDI coding.

That said, there are differences that might lead a manufacturer to prefer one Entity over another. The main aspects to consider are:

Cost and type of subscription: for example, some require an initial registration fee and an annual renewal, while others only require a one-time registration fee;
Language of customer service: while not always a deciding factor, having a standard and customer service in your own language is certainly convenient;
Complexity of the standard to be applied: some standards are simpler, while others are more complex;
Specificity of the Entity: the four identified Issuing Entities existed and offered their services before the Regulation came into force, and not necessarily only for the medical device field. This means that often the standards are overstructured compared to what is needed to define just the UDI coding. With this in mind, it’s important to consider the general target market of each Entity: for example, some are more specialized in the pharmaceutical field, while others are more specialized for mass consumption and retail.

How to Implement UDI Coding

The first step (and perhaps the most conceptually complex) is to define – with clear objectives of UDI coding in mind – what are the various levels of grouping applicable to your products.

The Regulation stipulates that UDI coding should be implemented considering, in general, the following:

The UDI-DI is a unique numeric or alphanumeric code specific to a device model […] (Annex VI, Part C, Paragraph 1);
A UDI is assigned to the device itself or its packaging. The outer packaging levels have their own UDI (Annex VI, Part C, Paragraph 3.1)
- Packaging levels mean the various levels of device packaging that contain a defined quantity of devices, such as a carton or box (Annex VI, Part C, Paragraph 1)
The UDI-DI is unique at all levels of device packaging (Annex VI, Part C, Paragraph 3.4);
Each component that is considered a device and is separately available on the market is assigned a distinct UDI unless the components are part of a configurable device that bears its own UDI (Annex VI, Part C, Paragraph 3.6);
Systems and procedure packs referred to in Article 22 are assigned their own UDI (Annex VI, Part C, Paragraph 3.7).

For specific types of devices, such as:

Implantable devices
Reusable devices that require cleaning, disinfection, sterilization or refurbishing between uses
Systems and procedure packs
Configurable devices
Software (only those separately available on the market and those that constitute devices in themselves)

it might also be necessary to consider additional aspects reported in Paragraph 6 of Annex VI, Part C.

Regarding the organization of UDI coding, an excellent starting point is certainly to draw up a list of all devices manufactured by your company.
Each model, variant or sales configuration of the listed devices will be considered as a separate device and will, in turn, become part of this list.

Once it’s clear which individual elements require a code, it’s possible to move on to defining it using the logic and rules provided by the standard of the chosen Issuing Agency.

The Process of Applying the UDI Code: from Theory to Practice

Once the UDI codes of the products have been defined, they must, within the timeframes reported in the initial paragraph, be included on the label.
The application will also follow the provisions of the individual reference standards and will involve the creation of labels that display the UDI code (UDI-DI + UDI-PI) in HRI and AIDC formats.

Unless implementing an in-line labeling verification process, the application is a process that needs to be validated, meaning it must be ensured that each label bears the UDI carrier that is compliant and of a quality that can be interpreted both by those handling the product and by any automatic acquisition means.

To validate the process, it will be necessary to define all the “actors” that participate in the creation of a complete label, namely:

The software used for creating the UDI code and/or retrieving product data to be included within it (e.g., the batch number);
The software used to “translate” the UDI alphanumeric string into a graphic vector such as a barcode or datamatrix;
The printer used to print the labels;
The types of physical media on which the labels will be printed.

Validating the application process, in summary, involves verifying and keeping the above under control in order to limit the variability of the output so that it can reasonably be assumed that what is printed on the label meets the standards of the Issuing Agency used.

To verify that the graphic vector applied to the label meets the standards of the Issuing Agency, verifiers are generally used, which are certified optical readers that, under defined environmental conditions, can verify the quality of the vector against reference ISOs, such as ISO/IEC 15415 or ISO/IEC 15416. This activity is typically carried out by specialized laboratories.

Impact on the Quality System

The implementation of UDI coding certainly has an impact at multiple levels on the company’s quality system, considering that the correct management and implementation of activities affected by the assignment, management, and maintenance of coding involve various processes transversally.

Identifying macro-areas of impact, we will have:

MANAGEMENT OF EXTERNAL ORIGIN DOCUMENTATION
The implementation of coding will be carried out following the standards provided by the chosen Issuing Agency. This documentation must therefore be appropriately incorporated, possibly integrated with internal procedures, and its update status must be kept under control.

TRACEABILITY MANAGEMENT
One of the main purposes of UDI coding is to make product traceability more effective and efficient. Adequate system procedures must be drawn up to clearly and unambiguously define the assignment logic of the coding broken down into its various levels (Basic UDI-DI, UDI-DI, UDI-PI). Pre-existing system documentation must be updated to allow a link between UDI codes and production documents.

The manufacturer has the responsibility to ensure the uniqueness of the code assignment, consequently the methods adopted to meet this requirement must be clearly explained and a list of all UDI codes (UDI-DI + UDI-PI) produced must be drawn up and kept updated.

VALIDATION OF THE APPLICATION PROCESS
System documentation must be updated to outline the methods by which the application process will be verified and validated, i.e., the ways in which UDI information is intended to be reported on the product and on the various levels of packaging provided.

In particular, the equipment identified to obtain an adequate level of quality of the code representation on the label must be managed in a way that allows for prompt re-evaluation of the process in case of failures or updates. The minimum characteristics identified for the means that contribute to the application process (printers, printing media) must be documented and made available to the processes responsible for their procurement.

Similarly, the software involved in the application activities (for example, the software that generates the graphic vector from the UDI code in its alphanumeric format) must be verified and kept under control in case of automatic or periodic updates.

In case of integration of processes with a company ERP (Enterprise Resource Planning), the interactions between ERP and the processes of collecting metadata for UDI code generation, generation and printing of graphic vectors, and any M2M (Machine to Machine) connectivity processes for database registration must be appropriately documented and validated.

MANAGEMENT OF THE MEDICAL DEVICE REGISTRATION PROCESS
The organization must provide for an update of the procedures relating to the registration of devices in the appropriate databases, providing for the introduction of the new Eudamed database, defining the responsibilities and methods by which the registration of devices will be carried out through UDI coding and the responsibilities and methods by which this database will be kept updated.

DESIGN AND DEVELOPMENT
Already during the product design and development phases, it will be appropriate to take into account the requirements set in terms of UDI coding, evaluating any specific prescriptions for the type of devices produced.

The product documentation must clearly indicate the methods by which the graphic vector will be reported on the product or label in its two forms (HRI and AIDC) and any rationales supporting the implementation choices made.

VIGILANCE AND SURVEILLANCE
Pursuant to Article 27, paragraph 5, of the Regulation, the UDI must be used for reporting serious incidents and field safety corrective actions.
Consequently, it will be necessary to update the internal procedures relating to product vigilance.

The system documentation useful for collecting feedback from the market, complaints, feedback, and service and assistance reports must be updated to allow and/or facilitate the link between the product concerned and its related UDI code.