Manufacturers must realize that the new FDA medical device database makes data its own product.

March 26, 2015

6 Min Read
Tips for Device Makers Facing the UDI System

Manufacturers must realize that the new FDA medical device database makes data its own product.

Rajesh Misra and William Poetker

FDA rules require medical device labelers to submit data to the Global Unique Device Identification Database (GUDID) for the highest-risk medical devices and will soon expand to moderate risk (Class II) devices in September 2016. Collection of this data poses a set of issues for device makers, including where the data resides, how it is reviewed, and its eventual dissemination to stakeholders.

The accuracy of the submitted data is an important to the success of the Unique Device Identification (UDI) system, which aims to reduce medical errors and improve the effectiveness of product recalls. The collection and validation of the GUDID attribute data is bringing to light some of the data attributes that were never systematically collected or stored in any systems.

The UDI ruling links physical product identity to important product attributes. Manufacturers will be required to upload the device data into FDA’s GUDID database in addition to marking the products with the UDI, which is made up of the device identifier and the production identifier. The new rule sends a message to the medical device industry: product attribute data which is expected to serve as a fundamental source for handling, storage, transaction management, and regulatory reporting, is an important and valuable extension of the product itself. The sophistication of the medical device industry, driven by rapid innovation, requires a “like-for-like” approach to managing product data.

Some device attributes may not have been recorded previously in a system and therefore, that data must be identified, collected, cleansed, controlled, and submitted to the regulatory database. In other cases, the necessary data is found to exist across multiple systems, sometimes with an attribute appearing in multiple systems but with different values. Another possibility is that the existing data is inaccurate, requiring significant efforts to update it before it can be submitted to FDA. Here are a few pointers on how to deal with each of these situations:  

Required Data Not Held in a System

FDA’s UDI program has created a need to capture and submit certain product attributes that may not have been recorded in a system previously. For example, these attributes may relate to the information contained on a product’s packaging, such as whether a product is marked with expiration and manufacturing dates, batch/lot numbers, and individual serial numbers. A product manager would be able to provide this information, but it may not have been recorded previously, and it is unlikely that it was submitted to regulators. Collecting this data tends to be a one-time manual process. It is important to create these fields in existing systems and develop quality procedures to keep this data current in the future, because the same or similar data attributes will likely be required by other regulatory bodies or initiatives.

Segregated Data Troubles

Another major challenge faced by many device makers is the notion of “segregated data” spread across many systems, allowing for multiple “sources of truth” for an attribute. This commonly occurs when departments manage their own data and there is a lack of an overall data governance procedure.

As an example, regulatory data attributes required for GUDID submission, like the FDA listing number, are most likely held in a regulatory affairs system managed by the company’s staff. However, data regarding a product sterilized at the manufacturer or sterilized prior to use might be housed in a separate manufacturing or packaging system.

All of this data needs to be connected for GUDID submission, but worse still, this fragmented, departmentalized data opens the door for the same attribute to appear in two systems, potentially with a different value for the same product. The key with such discrepancies is to establish a single “source of truth” per attribute, choosing the most accurate system for a particular attribute, and implementing the necessary processes to maintain the data in a controlled state.

Several medical device makers have utilized a staging tool or system to house the superset of GUDID data, both as a point for review, and as a single point of communication with FDA. A data governance plan that is integrated with existing processes and quality procedures will ensure that the newly required data will stay current. In the long term, automated data synchronization between systems should be pursued to ensure all the systems are working with the same data.

A New Way to Look at Data Governance

In instances where a company has a low degree of confidence in the existing data, managers may choose to manually collect data and sample test the existing data. Data inaccuracy typically results from the lack of a governance strategy and proper data management. Companies will often separate the data generation and maintenance from existing operational processes, typically resulting in a group that collects, maintains, and ensures the accuracy of the data.

Industry leading practice has shown that by integrating data generation and maintenance into existing processes, such as new product introduction (NPI), change control (CC) procedures, and quality control (QC) systems, the data will reflect product changes, leading to higher quality information. Integrating data generation will ensure that the appropriate data owner is responsible for the accuracy of the data.

Now, this is not to say that a master data group is not required as a function. There needs to be a group that drives the workflows created by the additional data generation and maintenance procedures. Therein lies the key: the master data group is a process-driven group, not a data-driven group. The group should be responsible for involving the correct stakeholders and driving accuracy through process improvement. Input must come from the true owner of the data for its most accurate form.

Device Maker Solutions

Several of these shifts in the way companies think about and handle UDI data are medium- to long-term solutions. However, device makers can take several immediate actions to address current issues:

  • For GUDID submission, create fields in existing systems for the newly required UDI attributes and integrate the generation of the data into NPI, CC, and QC procedures.

  • Use a staging tool or system to collect the data in one location to review the data before submission.

  • Initiate data synchronization discussions within your organization to identify areas where synchronization is most needed.

  • Create data governance procedures to be applied at a corporate level, to ensure that the same quality standards are applied across all systems.

  • Most importantly, recognize that data is becoming increasingly valuable in the supply chain. Treat data as if it is a product and encourage others within your organization to do the same.

Device makers must understand that they are no longer solely a product manufacturer, but also a data manufacturer.

Stay on top of the latest trends in medtech by attending the MD&M East Conference, June 9–11, 2015, in New York City.

Rajesh Misra is a Managing Director in KPMG’s Life Sciences Advisory practice and leads the Serialization and Unique Device Identification (UDI) related services. He specializes in developing technology-enabled solutions for business transformation and compliance related initiatives within Life Sciences industry. William Poetker is a senior associate in the Life Sciences Advisory practice and specializes in providing functional and technical support to clients in the pharmaceutical and medical device industries.

[Image courtesty of DIGITALART/FREEDIGITALPHOTOS.NET]

Sign up for the QMED & MD+DI Daily newsletter.

You May Also Like