Challenges and Emerging Practices for UDI Regulation

A major challenge of UDI compliance is the organization, transformation, validation and maintenance of the data that needs to be submitted to the FDA’s Global Unique Device Identification Database (GUDID).

Here’s a few challenges that I would like to outline below:

Data Management: As per the GUDID guidance document (www.fda.gov/udi), the medical device manufacturer is required to submit 55 data fields for every product to the FDA GUDID database. For a medical device manufacturer, it is very difficult to locate and manage required data since it is scattered across multiple systems. In many cases some portion of it does not even exist electronically or as a discrete data element. For example, some of the data resides in a labeling system (e.g. latex, storage conditions), some is likely in regulatory files/database(510(k)/PMA, listing number), and the rest most likely lives in a product specification document (brand name, size).

GUDID Submission: Since it is a new regulation, it will be the first time that manufacturers have to organize this type of data electronically. The good news is that FDA has exposed the web interface to submit DI records to the GUDID database. The bad news is that it does not support bulk submission. The alternate approach may be to use third party ESG services or even write a custom program that can submit bulk records through ESG gateway using HL7 standard. The FDA has published detailed guidance on the ESG gateway submission.

FDA Rule Validation: There is higher probability of human errors while validating the data against the FDA rules.

On-going Compliance Process: There is a need for a UDI compliance management process that can ensure accurate data submission for new and updated devices on an ongoing basis.

Future Support for UDI regulations for European Union or IMDRF: The European Union and IMDRF are also coming up with similar UDI regulations that may add/remove region specific fields or may have different validation rules. It will be important to create a flexible solution so that future needs can be adjusted to the existing design.

I’ve also outlined some notes regarding emerging practices for minimizing the challenges mentioned above:

Since the data required by GUDID resides in multiple systems, the first step is to identify the source systems where all the data is located. It is highly recommended to go over and understand the FDA’s GUDID guidance document that provides a detailed explanation of the data elements, their descriptions, the edit rules, the data type and length, the list of values and whether it is a new DI trigger.

If some data elements do not exist today (gaps) then identify the software system where the data can be electronically created and stored. For example, one of the requirements of UDI regulation is to maintain and submit Device Identifier (issued by FDA accredited agency) and its related fields. These are new fields and do not exist today in any system. Since a device identifier is static and it is directly related to the product revision and configuration, my recommendation is create these data elements within a Product Life Cycle Management software (such as Oracle Agile PLM) so that it is directly tied to the product record.

Use this list of data elements to develop your own data extraction tool from the source system. It is recommended to use Integration middleware technology that can help extract, transform and submit data.

Create a UDI Data Management team which is comprised of individuals/user groups who own the specific data elements, the standard operating procedures for managing and changing the element and how the data is validated.

The data captured from multiple systems then needs to be transformed and normalized into the GUDID database format. This can be achieved by using an integration middleware technology which automates the extraction, transformation and submission process.

Create a business process (workflow) for data capturing, validation/review and submission to FDA. This will make sure that the data is validated and reviewed by necessary personals before submission. The workflow should support the data submission for both new and updated devices.

It is the responsibility of your IT team to understand their company requirements and then analyze their capabilities and gaps. For bulk submission, you could either create/ use third party submitters’ ESG services. In addition, you could even create an in-house capability by creating a custom program to submit bulk records through ESG gateway using the HL7 standard.

In the future it is likely that other regulators such as the European Union and IMDRF also develop their own UDI systems. This may add local or regional fields. Therefore, the processes and systems put in place for GUDID need to be extensible and adaptable as future needs dictate.

The design for implementing FDA rules should be configurable so that the future changes can be adjusted quickly.