UDI for software: how to mark your MDSW with a UDI?

UDI for software: how to mark your MDSW with a UDI? | QbD Group

5:30

We recently published a blog post about Unique Device Identifiers (UDI). While this blog post briefly explains what a UDI is and how to implement it on your medical devices, it may still be unclear how it applies to Medical Device Software (MDSW).

Well, the principle remains the same: each individual medical device must have a Unique Device Identifier with its carrier (barcode or QR code).

However, since it is impossible to print a barcode on software, the question remains how to implement the UDI on MDSW. Since this is a complicated question, the Medical Device Coordination Group has created a document with guidelines on UDI assignment to software (MDCG 2018-5).

Recap: what is a UDI?

A UDI consists of a Basic UDI-DI and a UDI which comprises the UDI-DI (Device Identifier) and the UDI-PI (Product Identifier).

The basic UDI-DI (BUDI-DI) = the primary identifier of a device model. Assigned at the level of the device unit of use. It is the main access key for device-related information in EUDAMED and is referenced in relevant certificates, the EU Declaration of Conformity (EU DoC), Technical Documentation (TD), and Summary of Safety and Clinical Performances (SSCP).

The UDI-DI is a static number, that is required for each individual product and is specific to a version or model of a device. The UDI-PI identifies the production unit and, if applicable, the packaged devices. It provides information on the lot number, serial number, manufacturing date, expiration date, etc.

UDI for software: how to mark your MDSW with a UDI?

Figure 1 – Example of a UDI

A UDI consists of an Automatic Identification and Data Capture (AIDC) part and a Human Readable Interpretation (HRI) part.

The AIDC is a technology used to automatically capture data, including bar codes, smart cards, biometrics, and radio-frequency identification (RFID).
The HRI is a legible interpretation of the data characters encoded in the UDI. Both the AIDC and HRI should contain the complete UDI information.

As explained in our previous blogpost on UDI, there are 4 designating entities that can assign this:

GS1
HIBCC
ICCBBA
IFA

Assigning a UDI to software

Before assigning a UDI to software, check whether your software meets the definition of an MDSW. This is written in Annex VI part C of the Medical Device Regulation and the In-Vitro Diagnostic Regulation.

A UDI is only required for software that is commercially available on its own and software that constitutes a medical device in itself. See also MDCG 2019-11: Guidance on Qualification and Classification of SW in MDR and IVDR.

DI and PI modification

If there is a modification that changes the original performance, the safety or intended use of the software, or the interpretation of the data, a new UDI-DI is needed. Moreover,

any change of the basic UDI-DI
or a change to the
- name or trade name,
- version or model number,
- critical warnings or contra-indications,
- or user interface language

also require a new UDI-DI. This way, the traceability and correct identification of the medical device software are guaranteed.

Minor software revisions require only a new UDI-PI, not a new UDI-DI. Minor software revisions include

bug fixes,
usability enhancements that are not for safety purposes,
security patches
or operating efficiency.

These minor revisions have to be identified by a defined manufacturer-specific form of identification.

How to implement the UDI on the SW?

There are several ways to implement the UDI in the software, depending on how the software is delivered to the customer.

All the details are explained in Annex VI, Part C, point 6.5.4 of the MDR, and Annex VI, Part C, point 6.2.4 of the IVDR. Below is a small overview:

Physical medium

If the software is delivered on a physical medium, for example a CD or DVD, each packaging level shall have the HRI and AIDC of the complete UDI on it. In the EU, the UDI linked to your system level software should be the same as the one to your packaging level. In the US, a different UDI-DI is allowed for the packaging.

Software with User Interface

If there is an interface, the HRI UDI shall be provided on a readily accessible screen for the user in an easily-readable plain-text format. The UDI can for example be placed in an ‘about’ file or in the start-up screen.

Software without User Interface

If the software doesn’t have a user interface, the UDI shall be transmitted through an application programming interface.

Other rules on the application of a UDI on MDSW

There are two extra rules for the application of a UDI on MDSW. Firstly, for electronic displays, only the HRI is required. AIDC is not required, but it is of course optional.

Secondly, the human-readable UDI should also include the Application Identifiers for the standard used by issuing entities. This is done to assist the user in identifying the UDI and determining which standard is being used to create the UDI.

Need help with your UDI for MDSW?

There are several options for putting a UDI on MDSW, depending on whether your software is on a physical medium, and whether or not it has a User Interface. In this blog you learned what those options are, but should you need additional help, please contact the QbD Group.