As medical technology accelerates at an almost incomprehensible pace, regulations and requirements increase correspondingly. With rapid innovation and the desire to speed time to market comes more rigorous requirements for safety and effectiveness, which drives the establishment of programs such as FDA’s unique device identification (UDI) system. UDI is designed to identify medical devices through their distribution and use in their labeling and to report certain information via publicly accessible databases.
When fully implemented, the label of most medical devices should include a unique device identifier that will be readable by both humans and machines. FDA expects that UDI will improve patient safety, modernize device postmarket surveillance, and facilitate innovation. To date, UDI has only applied to products being introduced into U.S. supply chains. But variants of UDI are quickly being developed across the globe. Device companies can implement UDI in a variety of ways, but they must consider certain constants that dictate the handful of options OEMs have for meeting the objectives of UDI. This article examines those constants and the role they play in determining which approach will work best.
The first constant is that UDI compliance for FDA or other regulatory bodies will always include two primary pursuits: 1) putting the unique identifier on product labeling (a veritable license plate) and 2) submitting that information to the registries of regulatory bodies. It is interesting that, although the unique identifier printed on a label serves as a pointer to its associated regulatory data, most organizations manage their labeling data and regulatory data in two entirely separate systems even though most of the data is shared and should be identical (see Figure 1).
Responsibilities for managing each undertaking (i.e., labeling and submissions) are usually split across two different departments, which often involves different software systems. This separation greatly increases the potential for errors if synchronization efforts across these systems go awry. FDA reports that its Global Unique Device Identification Database (GUDID) already contains an unexpectedly large number of errors. There is a silver lining, though: the right data management can make a bifurcated approach work.
Effectively satisfying the requirements of both the label itself and submission of its error-free data to a regulatory agency calls for a system in which the data is impeccably controlled. Understandably, the extent to which data is controlled varies from company to company. However, there is another critical constant: only three approaches are available for coalescing and harnessing the data required for labeling and submission: on-premises, via the cloud, or a hybrid of the two.
Prior to the advent of UDI, most organizations used on-premises solutions (locally housed and managed hardware and software) to marshal the data that would appear on labels. Labeling systems could pass data from enterprise systems onto labels through connections made between enterprise resource planning (ERP), manufacturing execution systems (MES), and process lifecycle management (PLM) systems. Connections between these systems could be as simple as a label design software program being instructed to obtain data for variable fields from these enterprise systems. Most of the better label design software products could be set up this way. More sophisticated systems were connected and controlled via an intermediary database as implied in Title 21 of the Code of Federal Regulations (21 CFR). These databases are capable of recording history and digital signatures.
Cloud-based management of labeling data is still very new. Due to the nature of the cloud, using this approach will necessarily involve setting up a database or multiple databases to capture and store the required information. Because of the sensitive nature of high-value information in the life sciences, single tenancy in which a single server supports each customer will always be preferred. For the most part, cloud technology has not been tapped for managing regulatory data, and, until recently, use of the cloud has been limited to the submission process. Microsoft Excel and much effort (e-mailing) has predominantly been used to coalesce and massage data before submitting it through a cloud-based, submissions-only solution. Although this has been a good stopgap measure, considerations for ongoing and expanded data maintenance are now coming to light. Submitting data via cloud vendors has been a positive first step, and OEMs are finally exploring the idea of cloud-based regulated data management and submission. Many OEMs are now opting for a hybrid approach using both on-premise systems and the cloud (see Figure 2).
In information technology, connecting disparate systems is known as integration. With a hybrid approach, multiple redundant integrations across several system types will often need to be made to enable access to common data. Typical integrated systems might include an on-premise database of information required for labeling and cloud-based systems such as for GUDID submission and other cloud-based systems such as GS1 GDSN (Global Data Synchronization Network) data pools, or potentially other systems for other regulatory bodies.
A hybrid system, for example, may start by integrating an ERP with a system to obtain a global trade item number (GTIN) for submission to a regulatory database, e.g., GUDID. Next, a company may integrate the labeling system with the very same field in the ERP so that the labeling system can obtain a GTIN for insertion into a variable field on a label. Integrating yet another system to get the GTIN information into a GDSN data pool can complicate things even further. More integration points mean more cost and more integrations that need to be maintained.
The goal is to avoid creating multiple integrations and therefore avoid multiple points for potential failure. Building a “single source of truth” via multiple integrated systems is not the answer. Rather, setting up a single coalescing database is more manageable and less likely to produce errors. Known as master data management, the system serves as a crucible to gather and disseminate data as needed. And it can be either on-premises or can reside in a cloud hosted environment.
As regulatory bodies around the world introduce their variants of U.S. FDA UDI, it will drive the need for structured yet flexible data that can be reused easily and effectively. Device companies will need to implement additional processes to address the complexity of localization and destination labeling as more regionally specific UDI and concomitant regulations are added to the mix.