Constructing the informatics and information technology foundations of a medical device evaluation system: a report from the FDA unique device identifier demonstration

Abstract

Objective

The US Food and Drug Administration (FDA) has recognized the need to improve the tracking of medical device safety and performance, with implementation of Unique Device Identifiers (UDIs) in electronic health information as a key strategy. The FDA funded a demonstration by Mercy Health wherein prototype UDIs were incorporated into its electronic information systems. This report describes the demonstration’s informatics architecture.

Methods

Prototype UDIs for coronary stents were created and implemented across a series of information systems, resulting in UDI-associated data flow from manufacture through point of use to long-term follow-up, with barcode scanning linking clinical data with UDI-associated device attributes. A reference database containing device attributes and the UDI Research and Surveillance Database (UDIR) containing the linked clinical and device information were created, enabling longitudinal assessment of device performance. The demonstration included many stakeholders: multiple Mercy departments, manufacturers, health system partners, the FDA, professional societies, the National Cardiovascular Data Registry, and information system vendors.

Results

The resulting system of systems is described in detail, including entities, functions, linkage between the UDIR and proprietary systems using UDIs as the index key, data flow, roles and responsibilities of actors, and the UDIR data model.

Conclusion

The demonstration provided proof of concept that UDIs can be incorporated into provider and enterprise electronic information systems and used as the index key to combine device and clinical data in a database useful for device evaluation. Keys to success and challenges to achieving this goal were identified. Fundamental informatics principles were central to accomplishing the system of systems model.

BACKGROUND AND SIGNIFICANCE

Recognizing the lack of a proactive, systematic approach for tracking medical device safety and performance, in 2012 the US Food and Drug Administration (FDA) published “Strengthening Our National System for Medical Device Postmarket Surveillance,” updating the document in 2013 with an outline of next steps.^1,2 The FDA strategy calls for 4 specific actions: (1) implementing unique device identification in electronic health information, (2) creating device registries for selected products, (3) modernizing adverse event reporting, and (4) developing new methods for generating, synthesizing, and analyzing evidence. This system is envisioned to promote patient safety through earlier detection of safety signals, with greater accuracy in estimating the magnitude of adverse effects. In parallel, the system should return information on real-world performance and patient outcomes that could be used for medical device improvement and innovation.

Unfortunately, multiple components of the envisioned system are misaligned, are not linked, or simply do not exist. While valuable data for evaluating devices reside in supply chain databases, specialized clinical documentation solutions, electronic health records (EHRs), insurance claims databases, and national registries, these information sources exist largely as data islands with only limited connectivity. To be successful, the device evaluation system must address identification and tracking of devices across these data islands.

The Unique Device Identifier (UDI), authorized by the US Congress in the FDA Amendments Act of 2007 and the FDA Safety and Innovation Act of 2012,^3,4 is an alphanumeric code that includes device identifier (eg, model and manufacturer) and production identifier (eg, date of manufacture, lot number, expiration date) information. In 2013, the FDA issued the UDI Final Rule, phasing in the requirement for manufacturers to include a UDI on the package labels of all medical devices, starting with class III devices effective September 24, 2015. In parallel, the FDA developed the Global UDI Database (GUDID)⁵ to house device attributes specific to the device identifier component of the UDI in a referenceable, searchable database. In terms of implementation in electronic health information systems, the Office of the National Coordinator and the Centers for Medicare and Medicaid Services (CMS) have included UDI integration criteria in the certification program for EHRs and are developing the UDI as a component of the common clinical dataset.⁶ Efforts are also under way through the Accredited Standards Committee X12 to have UDI incorporated into insurance claims.

In 2011, the FDA established the Medical Device Epidemiology Network (MDEpiNet) as a collaborative through which the FDA Center for Devices and Radiological Health and external partners can share information and resources to enhance understanding of the postmarket safety and effectiveness of medical devices.⁷ In 2012, the FDA funded a number of MDEpiNet initiatives, including a demonstration project performed by Mercy Health of a system of prototype UDI implementation in the electronic information systems of a single health system to assess device performance. The purpose of this report is to describe the informatics architecture of the Mercy demonstration, including roles and responsibilities of actors, in sufficient detail that other enterprises can model it in order to participate in and contribute to a national medical device evaluation system.

OBJECTIVES

Mercy is a 4-state regional health system headquartered in St Louis, Missouri. It comprises 45 hospitals with a total of 4,148 staffed beds ranging from small, critical-access rural facilities to large, tertiary-care urban medical centers. Mercy’s UDI demonstration project is described in detail elsewhere.^8,9 Briefly, the demonstration had 3 specific aims:

• To implement a prototype UDI for coronary stents across the electronic information systems of a multihospital system;

• To identify obstacles to implementation of the prototype UDI and characterize the effectiveness of interventions to overcome them; and

• To assess the validity and utility of data obtained from an EHR system in postmarket surveillance using the UDI as the index.

The objective of this report is to describe the demonstration’s informatics architecture, including data flow, data model, and roles and responsibilities of actors in the system of systems.

METHODS

In order to execute the demonstration project, it was determined that 2 specific databases would need to be created. In order to have clinically meaningful device attribute data available to the demonstration (since the FDA GUDID data specifications were incomplete at the time of the demonstration project), the first database was a prototype supplemental UDI database (SUDID) to contain device attributes not included in the draft GUDID specification. To help define the content of the SUDID, an expert workgroup was assembled to define use cases for coronary stent device data and the requisite data elements to populate the prototype SUDID to support those use cases.⁸ The expert workgroup was led by a panel of interventional cardiologists and included representation from coronary stent manufacturers, Mercy’s Healthcare Transformation Group (HTG) health system partners (Geisinger, Intermountain Healthcare, Kaiser Permanente, and Mayo Clinic),¹⁰ the National Cardiovascular Data Registry (NCDR), and the FDA. The second system, termed the UDI Research and Surveillance Database (UDIR), was a platform to support postmarket device surveillance analyses. The UDIR was created to aggregate and link clinical data extracted from the Mercy EHR with the UDI-associated attributes of their implanted stents and data from other sources, such as the Social Security Death Master File. Along with these 2 key databases, the following tasks needed to be accomplished to achieve the goals of the demonstration project:

1. Identify a (prototype) UDI at the point of entry of the coronary stent into the supply chain, integrating UDI into supply chain management software, as the FDA had not promulgated the UDI Final Rule at the time of the demonstration.

2. Capture the coronary stent prototype UDIs at the time of stent implantation, integrating UDIs into procedure documentation software and associating them with patients in procedure documentation.

3. Capture key clinical data at the time of stent implantation and at regular intervals during follow-up.

4. Retrieve coronary stent attributes from the GUDID and SUDID using the UDI as the index, and use these attributes to classify stents into logical groupings for analysis.

5. Aggregate and link coronary stent, patient, and follow-up data in the UDIR to support longitudinal analyses for the purpose of safety surveillance and research.

6. Use and link UDI, clinical, and procedural data for other purposes, such as billing, inventory management, and reporting to the American College of Cardiology NCDR.

Developing the system required the efforts of many stakeholders, including multiple departments within Mercy, coronary stent manufacturers, Mercy’s HTG partners, the FDA, professional societies, the American College of Cardiology NCDR, and information system vendors. The project was begun in May 2012, with data flow changes and database design and implementation completed by October 30, 2012, enabling a full year of data collection and completion of preliminary analyses by project end in December 2013.

RESULTS

A system of systems

A “system of systems” was created that is an end-to-end solution incorporating UDIs and UDI-associated data from the point of introduction into the Mercy supply chain through a simulated device surveillance analysis. Figure 1 illustrates the system workflows and Table 1 delineates the functions and deliverables of the stakeholder actors. The system ultimately enabled analysis of data on 2484 percutaneous coronary intervention procedures performed in Mercy’s 5 cardiac catheterization laboratories (cath labs) between November 1, 2012, and October 26, 2013, in a total of 2250 patients.

Figure 1.

UDI System Information Flow. DI = Device Identifier; EDI = electronic data interchange; ETL = extract, transform, and load; FDA = US Food and Drug Administration; GHX = Global Healthcare Exchange (Louisville, CO); GUDID = Global Unique Device Identifier Database; PI = production identifier; SUDID = Supplemental UDI Database; UDI = Unique Device Identifier; barcode = UDI barcode scan.

Table 1.

UDI data entities and functions

Entity	Function/Role	Deliverables
Device manufacturers (Boston Scientific, Medtronic, Abbott)	Manufacture devices Provide Global Trade Item Numbers, UDIs, and associated device attribute information and labeling	File in Global Data Synchronisation Network (GDSN, GS1) format containing Global Unique Device Identification Database (GUDID) attributes File in manufacturer format containing Supplemental Unique Device Identification (SUDID) attributes
US Food and Drug Administration	Define rules related to unique device identification, data storage, and communication requirements Partner with the demonstration expert workgroup to establish supplemental device attributes8	UDI rules for electronic handling of medical devices Oversight of device manufacturers re UDI regulatory requirements
Healthcare Transformation Group (includes Geisinger, Intermountain Healthcare, Kaiser Permanente, Mayo Clinic, and Mercy)	Implement GS1 UDI standards and supplemental attribute adoption Evaluate Unique Device Identifier Research Database (UDIR) structure Provide feedback about the breadth, scope, and utility of the SUDID attributes and UDIR	Shared expertise with respect to device usage, implant, and clinical surveillance
Professional societies (American College of Cardiology, Society for Cardiac Angiography and Interventions)	Nominate clinicians to the expert panel to lead the expert workgroup in establishing supplemental device attributes of coronary stents	Clinical expertise with respect to device usage and assessment of device safety and performance Promotion of UDI standards for device tracking and clinical surveillance
Global Healthcare Exchange (GHX, Louisville, CO, USA) GDSN	Define industrywide data standards and item attributes included in the GDSN	Standard, global UDI data attributes and format
GHX	Facilitate exchange of purchasing information and medical devices between product suppliers and device implant providers	Hosting of device catalogs Creation/maintenance of processes and systems used by health care service providers to acquire medical devices
Mercy Integrated Delivery Network	Utilize UDI information for supply chain, clinical, research, and reporting activities	Model to enable use of UDI data by other hospitals and integrated delivery networks
National Cardiovascular Data Registry	Integrate UDI into the CathPCI Registry	UDI tags on devices in the CathPCI Registry
Mercy Resource Optimization and Innovation Purchasing Group	Track device replenishment requests Purchase medical devices	Device acquisition
Mercy performance solutions team	Implement a point-of-use barcode scanning system within the Mercy catheterization laboratories (cath labs) to manage inventory and capture consumption Provide training for cath lab personnel in use of barcode scanning system Optimize inventory by reducing and/or eliminating inventory that is not needed Institute assignment of additional serialized barcode to the stent for tracking purposes	Real-time inventory visibility of the UDI for all coronary stents across Mercy Ability to capture patient-specific consumption for all coronary stents across Mercy as well as the stents’ UDIs
Mercy Resource Optimization and Innovation Consolidated Service Center (CSC)	Distribute medical devices to clinical locations Track medical devices to clinical distribution points	Device distribution Device storage/movement tracking
Mercy catheterization laboratories	Scan into inventory barcodes of cath lab consumables including stents at receipt Scan barcodes of coronary stents at point of use Document clinical data in hemodynamic software (Merge Hemo™, Merge, Chicago, IL, USA)	UDI scanning at point of receipt UDI scanning at point of use CathPCI Registry data documentation in Merge Hemo
Mercy Research Department	Coordinate all activities of demonstration project Ensure achievement of demonstration project goals Identify challenges encountered during UDI pilot Assess UDIR and perform coronary safety and effectiveness analyses using UDIR data Make recommendations concerning UDI implementation feasibility, cost, best practices, and utility	Demonstration project methodology and scope of work Baseline and surveillance clinical UDIR data capture requirements Expert workgroup led by expert panel Analyses of UDIR data completeness and validity Analyses of coronary stent safety and performance Communications to demonstration project participants and FDA regarding project progress and outcomes
Mercy Technology Services (MTS), Mercy’s information technology (IT) group	Design and develop UDIR and SUDID Provide deidentified baseline clinical data for evaluation of utility Provide deidentified surveillance data for evaluation of utility Identify IT issues/challenges encountered during the demonstration Make recommendations concerning UDI capture feasibility, cost, best practices, etc. Support UDI data capture and storage processes Provide technical information needed for UDI demonstration reporting	UDIR and supporting extract, transform, and load processes UDI demonstration project technical documentation Technical architecture oversight of Mercy’s UDI system of systems UDI information extracts from Mercy’s electronic information systems

The system of systems included linkages among various proprietary information systems within Mercy that used prototype UDIs as the index. Global Trade Identification Numbers (GS1, Brussels, Belgium) and health information barcodes (Health Information Business Communications Council, Phoenix, AZ, USA) were selected to be the prototype UDIs. At the time of the demonstration, either a Global Trade Identification Number or health information barcodes had already been assigned to stents by Abbott, Boston Scientific, and Medtronic (the manufacturers of all FDA-approved coronary stents during the time of the demonstration) and included on coronary stent packaging as barcodes and human-readable alphanumeric codes (GS1 and the Health Information Business Communications Council were subsequently identified by the FDA as 2 of the 3 approved issuing agencies for UDIs¹¹).

The manufacturers assigned GUDID and SUDID attributes to each coronary stent DI component of the UDI and supplied the DIs and associated attributes to the FDA and Mercy. Mercy created the SUDID to house the coronary stent DIs and associated supplemental attributes chosen by the project’s expert workgroup.⁸ Mercy then implemented a barcode scanning system in each of its 5 cardiac catheterization laboratories to capture the prototype UDIs as the coronary stent was placed into the laboratory inventory and again at the time of stent implantation, in order to establish a link between a device and the patient in whom it was implanted. This barcode system was utilized for all consumable items used in the cardiac catheterization laboratories⁹ and not limited to stent devices.

Data flow

As shown in Figure 2 and Table 2, UDI data flow started with the manufacturer and the FDA GUDID, progressed through Mercy’s various electronic systems (enterprise resource planning [ERP] software [Infor Lawson, New York, NY, USA], OptiFlex^™ CL inventory management system [Omnicell, Mountain View, CA, USA], and cath lab hemodynamic software [Merge Hemo, Merge, Chicago IL, USA], and ultimately populated the UDIR, which had been created utilizing Mercy’s data warehousing functionality (the integrated patient data mart). Following the initial stent procedure, the UDIR received weekly patient-specific data feeds from Mercy’s EpicCare EHR (Epic, Verona, WI, USA) through Epic Clarity (the Epic data warehousing utility) and supplemental mortality data from the Social Security Death Master File.

Figure 2.

Data flow to the Unique Device Identifier Research Database.

Table 2.

UDI data flow details

Seqa	Initiating Entity	Product/Information	Action Description	Recipient
1	Mercy Resource Optimization and Innovation (ROi) purchasing group	Purchase order	Send purchase orders for electronic data interchange (EDI)	Enterprise resource planning system (ERP)
2	Mercy ROi purchasing group	Replenishment request	Enter data manually into ERP, triggering automated data transfer to the OptiFlex inventory management system	ERP
3	ERP	EDI purchase order	Submit electronic purchase order to GHX via EDI transmission	GHX
4	GHX	Purchase order	Satisfy purchase orders through coordination of sales transactions between ROi and suppliers	Coronary stent manufacturer
5	Coronary stent manufacturer	Coronary stent UDI and attributes	Provide text data files containing Global Unique Device Identification Database (GUDID) attribute valuesb	FDA (Mercy data management)
6	Coronary stent manufacturers	Supplemental device attributes	Provide text data files containing Supplemental UDI Database (SUDID) attribute values	Mercy data management
7	FDA	Coronary stent GUDID attributes	Pass on the GUDID information provided by manufacturers for inclusion in the Unique Device Identifier Research Database (UDIR)b	Mercy Data Management
8	Coronary stent manufacturer	Coronary stent with UDI	Send to Mercy ROi Consolidated Supply Center (CSC), where UDI is received via barcode scan into the warehouse tracking/distribution system	Mercy ROi CSC
9	Coronary stent manufacturer	Coronary stent with UDI	Send to hospital catheterization laboratory (cath lab) via drop shipment, where UDI is received via barcode scan into OptiFlex CL inventory management system	Mercy Hospital cath lab receiving
10	Mercy ROi CSC	Bulk shipment including coronary stents with UDIs	Include coronary stents as part of multiple-item bulk shipment of cath lab supplies	Mercy ROi distribution
11	Mercy ROi distribution	Bulk shipment including coronary stents with UDIs	Send to hospital cath lab receiving	Mercy Hospital cath lab receiving
12	Mercy Hospital cath lab receiving	Coronary stents with UDIs	Collate bulk shipment and place stents into inventory. UDI received via barcode scan into OptiFlex CL inventory management system, resulting in periodic automated replenishment location update	Mercy cath lab supply
13	Mercy cath lab supply	Coronary stent	Send stent from inventory to cath lab during procedure	Cath lab staff
14	Cath lab staff	Coronary stent implant procedure scheduling information	Enter data manually into the EpicCare EHR system, enabling transfer of data from patient’s clinical record to the UDIR	Mercy clinical team and data management
15	Cath lab staff	Coronary stent UDI	Scan UDI barcode, identifying stent as selected and removed from inventory in the OptiFlex CL inventory management system, enabling transfer of patient and stent data from inventory management system to the UDIR	Mercy clinical team and data management
16	Cath lab staff	Coronary stent UDI	Scan UDI barcode into Merge Hemo clinical system, establishing association with patient’s Merge clinical record (due to limitations of Merge Hemo, only a truncated version of the UDI is captured in the system)	Mercy clinical team
17	Cardiologist	Clinical data related to coronary stent implant procedure	Enter data into patient’s Merge Hemo clinical procedure record, generate procedure note, and close procedure case log	Mercy clinical team
18	Cath lab staff	Case log reconciliation	Close out clinical record for encounter in Merge Hemo and EpicCare and transmit Merge Hemo case file to UDIR	Mercy clinical team/billing/data management
19	Mercy data management	Patient demographic and baseline and longitudinal clinical information	Execute custom extract, transform, and load (ETL) interface from EpicCare into the UDIR	Mercy research
20	Mercy data management	Patient demographic and clinical information related to medical device implant procedure	Execute custom ETL interface from Merge Hemo clinical system into the UDIR	Mercy research
21	Mercy data management	Coronary stent inventory and usage information	Execute custom ETL interface from OptiFlex CL into the UDIR	Mercy research
22	Mercy data management	Coronary stent item master and purchasing information	Execute custom database interface from ERP into the UDIR	Mercy research
23	Mercy data management	GUDlD and supplemental UDI coronary stent attributes	Execute custom ETL interfaces from GUDID file and SUDID into the UDIR	Mercy research
24	Mercy research	Medical device performance evaluation	Produce reports and publications of safety and effectiveness analyses	FDA and medical device stakeholder community

^aSequence numbers corresponding to numbers in Figure 1.

^bSince the GUDID was not fully functional during the demonstration, its attributes were sent directly from the coronary stent manufacturers to Mercy data management.

The UDI Research and Surveillance Database

Data feeds into the UDIR included selected baseline and longitudinal (weekly) patient data extracted from Epic Clarity, clinical data from Merge Hemo, and coronary stent attributes from the GUDID and SUDID. The baseline patient characteristics were derived from those required for coronary stenting procedures by the CathPCI Registry^®.¹² The longitudinal follow-up data extracted weekly into the UDIR were the same characteristics for which a value had been entered in the clinical record during the implant procedure or in the interval since the prior data extract. These data were limited to those characteristics that could be automatically extracted from the warehouse and did not require manual data entry.

Details regarding the methodology of characteristic capture can be found in the online Supplementary Appendix, which is reproduced from the demonstration report to the FDA.¹³ In brief, information from Merge Hemo included patient demographic identifiers, vital signs, implanted device information, and information specific to the implant procedure. Data obtained from Clarity included patient demographic information not available in Merge Hemo such as race, ethnicity, marital status, medical history at baseline, implant encounter diagnosis, medications, and laboratory values. Also obtained from Clarity were targeted major adverse cardiac events: mortality, ST elevation myocardial infarction, total coronary artery revascularization, and stent thrombosis.

The supply chain information in the UDIR was taken from various Mercy systems, including the ERP, OptiFlex CL, and warehouse distribution (TECSYS, Montreal, Quebec, Canada). Device attributes from the GUDID were supplied in a spreadsheet by the FDA, because the GUDID reference database was not yet online during the time frame of the demonstration. Supplemental coronary stent attributes were extracted from the SUDID. Finally, the supplemental mortality data were downloaded into the UDIR from the Social Security Death Master File.

Figure 3 presents a high-level summary of the UDIR data model. It depicts the database’s 4 major tables, 2 representing catheterization laboratory management (Hemodynamics Master and Study) and 2 representing inventory management (Inventory Master and Medical Device Master). The remaining tables are combined into 3 subject areas: Patient Clinical Data, GUDID and SUDID Device Attributes, and Hemodynamic Implant Data. Data integrity is assured by comparing data from OptiFlex CL to data from Merge Hemo. Custom algorithms ensure a match on patient identifier, stent quantity, and procedure date. Patient identifier and procedure date can then be used to link to a host of tables in the UDIR or Epic Clarity that contain patient clinical data over time, as well as tables that contain cath lab–specific data (eg, procedure logs, stents scanned at the point of care). OptiFlex CL tables capture the full UDI and link stents to unique master DI components of the UDI, which in turn link to the GUDID and SUDID, the repositories of stent attributes. Detailed information, including the data model and data dictionary, is available in Mercy’s final report on the demonstration to the FDA and in the online Supplementary Appendix.

Figure 3.

Unique Device Identifier Research Database (UDIR) high level data model. Key: Boxes represent specific tables while circles represent subject areas comprised of multiple tables. Note that the full UDI is not currently captured in Merge (a technical gap that will be rectified in the future) so the matching algorithm between OptiFlex™ CL and Merge Hemo™ is primarily by patient identifier and date.

Roles and responsibilities

Implementation and operation of the device tracking and evaluation system at Mercy were accomplished by a team with members from a number of departments (cardiac cath lab, research, information technology, supply chain, and operational optimization) and depended heavily on senior executive leadership and advocacy. Table 3 lists the specific roles and responsibilities of Mercy team members.

Table 3.

Mercy roles and responsibilities

Role	Organization	Responsibility	Intellectual Property
Principal investigator (director of outcomes research)	Mercy research	Project oversight, research methodology	Cardiology, clinical, organizational, and methodological expertise
Project sponsor	Mercy operations executive	Project funding and senior leadership support	Project organizational sustainability
Inventory/supply-chain executive	Resource Optimization and Innovation (ROi) (Mercy’s supply chain company)	Point-of-use system oversight, item master management	Supply chain and ERP software integration into the demonstration, coronary stent availability in cath labs, and identification of package UDI barcodes
Information technology (IT) executive	Mercy Technology Service (MTS)	IT oversight, enterprise architecture	Enterprise architecture, EHR, research database design
IT lead	MTS	System architecture, data flow design, data content and specifications	Supply chain data flows, enterprise architecture, system capture of item barcodes
Senior IT data architect/modeler	MTS	Database design, data analysis	Clinical data, EHR data, research database design
IT project manager	Mercy project management office	Workload, project auditing, milestone checkpoints	Technical projects, project management guidance
Program manager	Mercy research	Cross-team project auditing, collaboration	Clinical projects
Senior inventory/point-of-use analyst	ROi	Cath lab implementation of point-of-use barcode scanning	Medical supply data, item master, package barcodes
Senior extract, transform, and load (ETL) developer	MTS	Multisource data integration	Integrated database
Senior structured query language analyst	MTS	Multisource data integration	EHR data, integrated database
Senior supply-chain analyst	MTS	Point-of-use supply scanning and item master	Real-time supply data in ERP supply chain, item master
IT business liaison	MTS	Cross-team collaboration and facilitation	Supply chain team building and coordination
Nurse cath lab user-acceptance tester	Mercy cath labs	UDI-related clinical workflow and data validation	UDI-related clinical processes and procedures
Quality assurance testing analyst	MTS	Integrated testing and results validation	Integration of EHR, ERP, and clinical data; research database design
Cath lab directors	Mercy cath labs	UDI-related inventory workflow changes and analysis	Integration of UDI into cath lab processes and procedures

DISCUSSION

Challenges

The Mercy team encountered a number of obstacles in designing and implementing the coronary stent tracking system that resulted in unanticipated effort and resource consumption. These workflow implementation challenges have been previously reported in detail.⁹ In brief, the first obstacle was that coronary stents are not serialized by device manufacturers, but are instead tracked at the lot level. This required generation of unique serial numbers that were affixed to device packages upon receipt, because the OptiFlex CL system requires serialization of individual devices. Additionally, clinical software vendors’ slow adaptation of the proposed UDI rule necessitated changing the original solution architecture, which was based on near-real-time messaging, to a batch-oriented daily integration of data. It was also discovered that Merge Hemo modified the prototype UDIs by replacing the “check-sum” digit with an arbitrary value of X. This negated the original design that called for utilizing the hemodynamic software as a reliable source of UDIs and led to the use of OptiFlex CL for this purpose.

Another challenge was device classification. The majority of data sources associated a location-specific, nonstandard device description with the device. In order to have standard descriptions across all locations, Mercy decided to utilize those provided by the Global Medical Device Nomenclature (GMDN) Agency.¹⁴ Since GMDN descriptions were not yet utilized by the FDA GUDID, a decision was made to include all existing Mercy device descriptions in the research database until the GMDN system could be employed.

A final potential challenge was that Mercy uses GS1¹⁵ as a “master” data source for all medical supplies, including the GS1 Global Location Number¹⁶ facility identifier, while the FDA employs Dun and Bradstreet numbers (D-U-N-S^®)¹⁷ as location identifiers. This situation would generally require development of a Global Location Number for the D-U-N-S cross-walk database. However, since the GUDID attributes were supplied directly to Mercy by the FDA, the cross-walk database was not necessary for the demonstration, but it will be required in the future, when the attributes are obtained directly from the GUDID.

Implications

Implications of the Mercy UDI demonstration for other health systems wishing to replicate the system of systems model for tracking and evaluating medical device safety and performance include addressing key issues up front, such as organizational leadership and resourcing, data management and governance, and the technical build itself. Finding the necessary funding to support the cost of systems development can be challenging, and establishing the business case was critical in this regard in order to ensure that building the system was financially feasible and that the system would be sustainable over time.

The demonstration reinforced the central role of fundamental informatics principles in accomplishing the system of systems model. A key aspect is the need to use well-defined and delineated common data elements and standards of data transport to achieve semantic data interoperability. While the UDI is reasonably well defined, the lack of consistent clinical data limited analyses to association of specific device types with transactional health care events (specifically bare-metal stents vs drug-eluting stents and subsequent repeat coronary intervention, myocardial infarction, and death). What was successfully demonstrated is the potential of the UDI to be used as the key index that binds data across platforms and across instances of care, facilitating the reuse of information collected through routine clinical care processes. At a minimum, this can predict that essentially all electronic clinical information systems, not just those subject to the certification requirements of the CMS EHR Incentive Program, will need to manage and exchange UDI data. Standards for handling the UDI are currently under development by Health Level Seven, and the application programming interface for access to the UDI attributes is likewise being tested by the National Library of Medicine.¹⁸

Our demonstration uncovered specific intersystem architecture gaps that need to be closed if the benefits of the system of systems are to be realized. The primary gaps relate to the inability of various software systems to capture UDIs and UDI-associated attributes. In our experience, the Mercy catheterization laboratory hemodynamic software (Merge Hemo) and inventory management solution (OptiFlex CL) both lacked the ability to accept UDIs, necessitating the development of workarounds. Another major challenge was the lack of connectivity between clinical systems. In Mercy’s case, the Merge Hemo system did not readily communicate with other clinical systems, and a manual export facility had to be purchased from the vendor in order to transmit data from the case record to the research database. Finally, as is the case with most EHRs, EpicCare was not configured at the time of the demonstration to accept UDIs and UDI-associated device attributes, precluding a zero-effort inclusion of specific device data in patients’ clinical records.

CONCLUSIONS

We feel that we achieved the primary purpose of the Mercy demonstration from an informatics perspective: to provide proof of concept that UDIs could be captured in key supply chain and provider information systems; that clinically meaningful, UDI-associated data could be combined with patient-specific clinical data at the point of care; and that the combined device and clinical data could be used for multiple purposes, including the creation of a database for use in longitudinal patient and device tracking to support both device surveillance and research. Achieving these goals required the development of custom interfaces, data extraction processes, and a data warehouse by the Mercy team. Additionally, we documented the necessity to create workarounds to achieve our goals due to a lack of true interoperability among clinical systems and limitations in our vendor-provided software systems. Systematically, these gaps must be addressed by clinical system vendors, as any other approach will not scale or be sustainable, particularly the issues encountered with our inventory management and clinical systems that required double scanning of barcodes in order to capture UDIs at the point of care.⁹ Finally, we demonstrated the need for data standards to support connectivity among various systems that go beyond interoperability among EHRs. Ideally, the desired state would be “plug and play.” The demonstration also pointed to the need for EHR and other system vendors to adopt UDI standards. The Office of the National Coordinator and CMS requirements for UDIs in Meaningful Use Stage 3 will be most helpful in this regard.

FUTURE WORK

We propose that the next step in establishing a system for use of clinical data in a medical device evaluation system is to establish a distributed data network among multiple health systems utilizing databases modeled on the Mercy UDIR that are connected to a coordinated registry network as envisioned by MDEpiNet’s Medical Device Registry Task Force.¹⁹ A demonstration of this proposal is specified as the Extension of UDI Implementation Pilot in the Building UDI Into Longitudinal Data for Surveillance and Research (BUILD) initiative,²⁰ which consolidates 3 of 6 pilot projects proposed by an MDEpiNet think tank²¹ and has received partial funding from the FDA (grant number 1U01FD005476‐01 revised, Center for Device and Radiological Health, US FDA). The Extension pilot involves building a distributed data network composed of 3 HTG health systems (Geisinger, Intermountain Healthcare, and Mercy) utilizing the NCDR CathPCI Registry as the hub. This model will be built to be extensible to an infinite number of health system participants, generalizable to all implanted medical devices where registries exist, and modifiable to function in situations where registries are not available.

Our experience during the Mercy UDI demonstration indicates that the BUILD initiative and the future development of such a medical device evaluation system will require the ongoing commitment of manufacturers, professional societies, national registries, health systems, and the FDA and will therefore need to demonstrate value for each of these stakeholders while addressing key issues such as data governance, system operations, and the handling of protected health information and intellectual property.⁸ Ultimately, we are moving toward the national medical device evaluation system called for by the FDA²² and further described by the National Medical Device Surveillance System Planning Board (now the National Evaluation System for Health Technology Planning Board)^23–25 and the Medical Device Registries Task Force,¹⁹ but to achieve our goal, we must learn how to integrate multiple data sources using UDI as the index while advancing the information technology infrastructure based on foundational informatics principles.

FUNDING

This work is supported by contract DHHS/FDA-22320172C from the Center for Devices and Radiological Health, US Food and Drug Administration.

COMPETING INTEREST

All co-authors declare that they have no competing interests.

CONTRIBUTORS

All co-authors declare that they meet the International Committee of Medical Journal Editors criteria for authorship:

• Substantial contributions to the conception or design of the work or the acquisition, analysis, or interpretation of data for the work, and

• Drafting the work or revising it critically for important intellectual content, and

• Final approval of the version to be published, and

• Agreement to be accountable for all aspects of the work in ensuring that questions related to the accuracy or integrity of any part of the work are appropriately investigated and resolved.

SUPPLEMENTARY MATERIAL

Supplementary material is available at Journal of the American Medical Informatics Association online.