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.
Once systems allow for regionally specific input and management of data, this will quickly become a new constant. But this constant can — and should — be addressed with adequate software. Complexity can be controlled with automated task dependency management; in other words, a person in one department cannot start something until a person in another department has finished their work. Software needs to enforce this for users as they log in. To effectively reuse data that has already been used within the coalescing database, the ability to find, filter, and act upon record sets for various purposes will be needed. Data access and read/write privileges should be controlled down to the field (column) level.
Having this data reuse happen efficiently will be much easier when all parties, including suppliers, third-party labelers (3PL) independent divisions, and even relabelers and distributors are on a common system. All data for labeling, UDI, trading partner sharing (e.g., GDSN) can be controlled, managed, and shared. Centralized yet commonly accessible data will also smartly tie into localization and destination labeling and, therefore, will play a pivotal role in product design and engineering.
Designing and engineering a generic product for multiple markets, building to stock, and localizing it through regulatory data submissions and product labeling is doable. But doing it right involves yet another license plate. Unlike the earlier license plate, this one is a low-level identity that defines what a product is while it is on the shelf. This license plate concept is the last constant for keeping an eye on UDI. One plate identifies generic product that is built to stock. The other is the UDI number and is applied only when the product’s new home is determined. A regulatory body will then use it to point to information that is associated with that specific item.
Databases belonging to various regulatory bodies around the world are still being designed and set up; therefore, a sophisticated, adaptable database is needed to manage the different requirements. Extended Markup Language (XML) and Health Level 7 (HL7) standards are currently the common denominators of data exchange for the medical device industry. It is essential that a coalescing database have a native ability to convert selected data into XML or HL7 or other standards and negotiate various submissions processes. As global UDI expands, this sort of flexibility will be the key to gaining a competitive advantage.
Taking these constants into account removes the guesswork from identifying the right approach for implementing UDI. Minimizing the potential for labeling and submission errors makes it possible to realize UDI’s goals — improving patient safety, modernizing device postmarket surveillance, and facilitating medical device innovation. And in this context, the rapidly increasing pace of product design breakthroughs plays a critical role in the success of UDI. Technology breakthroughs that enable the creation and delivery of patient-specific solutions will benefit most from flexible systems that can keep up with “LOTs of 1” and submit LOT attribute information in accordance with UDI requirements. While currently available patient-specific products are largely biomedical test kits, therapies, and contact lenses, the next generation of patient-specific products will press the need for fast and adaptive UDI solutions that focus on both primary pursuits — labeling and submissions — concurrently.
This article was written by Ardi Batmanghelidj, President, and Mark Sikorski, Director Sales and Marketing, Software Solutions, of Innovatum, Inc., Sugar Hill, GA. For more information, Click Here .