SSS-GHX Development of the Prototype Unique Device Identifier Database: Report of a Pilot Test on Usability and Feasibility

November 20, 2009 (Revised, De-identified)

Susan J. Griffey
Andy Martin
Marjorie Odle
MJ Wylie

Table of Contents

• Background
• Methodology
• Results
  • Supplier Experience in Collating and Entering Data Attributes
    • Overall
    • Data Gathering and Data Entry
    • Additional Supplier Feedback
  • User Experience in Using the UDI Database
• Discussion
  • Answering the Supplier Key Questions
  • Feedback Related to the Unique Device Identification System
  • Answering the User Key Questions
• Recommendations
  • General Recommendations
  • Recommendations for Finalizing List of Attributes for the UDI Database
  • Additional Recommendations for Future Phases
• Summary

ACKNOWLEDGEMENTS

The SSS-GHX pilot-test team is very grateful to all the manufacturers and providers at hospital facilities for their efforts and enthusiasm in this pilot test – those who were able to complete the pilot test and those who were unable to participate because of the timing.

We appreciated the willingness of all participants to meet the short-turnaround timelines and to provide detailed feedback in a variety of ways. This greatly enhanced the pilot test and has given the FDA a large amount of information at this early stage of moving forward on the Unique Device Identification System.

Thank you also to Jay Crowley, Senior Advisor for Patient Safety, at the FDA’s Center for Devices and Radiological Health for giving SSS and GHX this opportunity.

SSS-GHX pilot-test team 

Social & Scientific Systems, Inc

• Susan J. Griffey, DrPH, BSN, VP and Dir., Evaluation Ctr
• Marjorie Odle, Senior Systems Analyst

GHX

• MJ Wylie, Director, Global Data Standardization
• Andy Martin, Senior Product Manager

ACRONYMS

AC	Accessory
ANSI X12	Standards body for Electronic Data Exchange standards
CE	Capital equipment
CK	Convenience Kit
CP	Combination Product
DOT	Department of Transportation
DUNS	Dun & Bradstreet Business Number
ECRI	ECRI Institute
FDA	US Food and Drug Administration
FEI	Federal Enterprise Identifier
GDSN	Global Data Synchronization Network
GHTF	Global Harmonization Task Force
GHX	Global Health Exchange
GMDN	Global Medical Device Nomenclature
GTIN	Global Trade Identification Number
HIBCC	Health Industry Business Communications Council Medical Device Safety Network
HL7 SPL	Health Level 7 Structured Product Labeling
MedSun	Medical Device Safety Network
NDC	National Drug Code
PK	Packaging
SDMA	Safe Medical Device Act
SSS	Social & Scientific Systems, Inc
UCUM	Unified Code for Units of Measure
UDI	Unique Device Identifier
UDID	Unique Device Identifier Database
UDIS	Unique Device Identification System
UNII	Unique Ingredient Identifier

Background

On September 27, 2007, the FDA Amendments Act was signed into law. It specifically tasked FDA to develop a Unique Device Identification System, which:

• Requires the label of devices to bear a unique identifier ["Label" is defined as "...a display of written, printed, or graphic matter upon the immediate container of any article."]
• Allows FDA to describe an alternative placement (e.g., on the device itself or its packaging) for a particular device or device type
• Allows FDA to exempt a particular device or type of device from the Unique Device Identifier (UDI) requirements
• Adequately identifies the device through distribution and use
• May include information on the lot or serial number

Through the MedSun contract, SSS has worked with its subcontractor, GHX, in the third phase of a tiered process in which a key aspect of the Unique Device Identification System (UDIS), the prototype UDI database, was developed. The prototype responds to the detailed requirements developed jointly by GHX and FDA through discussions and documentation.¹ The system was specified as a web-based application and includes the pertinent attributes of a unique medical device. This report summarizes the structure and results of the pilot test of the prototype database, its feasibility and usability by both suppliers (manufacturers) and users (providers at health care facilities). The pilot testing was conducted in July-August 2009.²

Methodology

The pilot test was to meet the following objective: To assess the feasibility and usability of the Unique Device Identifier Database (UDID) prototype³ from initial data gathering and upload to the system to user data retrieval and export. Two perspectives were sought: that of suppliers (manufacturers) who would provide the detailed device data and that of the user (consumer) of data.

Included were the following sub-objectives:

• Provide a usable web interface for approximately six suppliers to gather and provide data sets for the FDA UDID, focusing on established device attributes some of which were required.
• Provide a usable web interface with which users of the data (providers/hospitals) can search the database and export query results from those searches.
• Ascertain feasibility of the data-gathering process and effort experienced by the suppliers (manufacturers), based on a structured feedback process.
• Ascertain the usability of and experience in using the prototype database by the users (providers at facilities), based on a structured feedback process.

Key questions to be answered included:

• How readily are data suppliers (manufacturers) able to identify/obtain the data for the required attributes and manipulate them for upload into the database?
• What concerns do suppliers have about sharing of these data?
• What was the suppliers’ interface experience with the data entry process? Was the data entry interface user-friendly and intuitive?
• How readily can users apply the sort and search capabilities within the database to find desired information?
• Are users able to easily locate data that apply to their institutional needs, configure the output via the web-based environment, and export those data to their desktop for their use?

Participant candidates were recommended by the SSS-GHX team, based on criteria developed and outlined in the pilot test plan. Generally, the target group was identified as those known to be interested in patient safety efforts and who would have familiarity with medical device-related efforts at FDA and elsewhere. The SSS team leader for the pilot test contacted all participant candidates individually via a request letter including detailed information about the pilot test. The packet also contained a questionnaire designed to offer information on the extent of expected participation by the supplier and gain acceptance of those terms. Six of 13 suppliers and five of seven user institutions completed the pilot test.

The pilot test was implemented incrementally, beginning with suppliers populating the database. Originally, we had intended to divide suppliers to two different groups – one to provide data in a MicrosoftExcel™spreadsheet for batch loading by GHX and one group to use the UDID application directly for data entry. As suppliers were being identified, the plan was modified to ask all suppliers to provide data in both ways. We felt that would give more information about each supplier’s ability to supply and upload data in two different ways, and with what effort, while ensuring consistency and reducing potential variability among supplier responses.

All suppliers participated in a web-meeting demonstration of the application after being provided with an instructions document and a set of FAQs. They were then asked to gather and enter data into the Excel template file⁴ developed by GHX. The suppliers were given 2 weeks to accomplish this and return the completed spreadsheet to GHX. GHX then uploaded most of the data in each spreadsheet file into the UDID application and the suppliers were asked to review and validate their uploaded data.

At the same time time, GHX indicated to the suppliers which data records in the spreadsheet were "withheld" (i.e., not uploaded) so that suppliers could use them as the records for the manual data-entry part of the pilot test. The suppliers then began the manual data-entry period, after which they were asked again to verify their data. Suppliers also had the opportunity to participate in a demo session prior to starting the manual data-entry exercise.

During the final phase of the supplier data upload process, users received a set of instructions on using the UDID application. The users were oriented to the UDID application in web-meeting demonstrations and then began their part of the pilot test which asked them to conduct two scripted scenarios and a free-form search for data research and retrieval. The users were asked to create their search and presentation parameters based on how they anticipated using this system.

At the end of the supplier and user pilot test periods, each group compiled feedback on a feedback form specific for their group. Both suppliers and users also had the option of participating in an individual teleconference feedback session with the SSS-GHX team. All but one supplier and one user requested the teleconference feedback session.

The original expectation was that all feedback would be kept confidential and would not be attributable to any individual. This changed, however, based on a request from two suppliers who specifically wanted FDA to see their feedback. We polled all suppliers and users; they agreed that feedback forms could be shared with FDA and likewise that FDA could attend the teleconference feedback sessions.

Results

The pilot test was conducted over a very short time period and all participants readily completed the requested work within short timelines.

Both types of participants (suppliers and users) who completed the pilot-test are extremely interested in patient safety and are early adopters and thought leaders in that area. All were very happy to have the chance to do this pilot-test for FDA. This was demonstrated repeatedly by their participation in various web-based demos and teleconferences, and in their extensive feedback, both via the written evaluation form and in the teleconference sessions.

Overall, everyone thought that the UDI prototype database application performed well. Both suppliers and users were quickly comfortable with the look and simplicity of the application interface, the location of various options, and the information display. Suppliers showed themselves to be sophisticated web-based application users, quickly noting features they were used to having that would enhance the application. Both suppliers and users quickly focused on those features and functions they were most likely to want and need.

Six of 13 suppliers and five of seven user institutions completed the pilot test. As we describe the results here, it must be remembered that the pilot test participants do not necessarily represent all perspectives in their organizations – and they do not represent all manufacturers of medical devices. The pilot-test participants were generally those involved in work that is closely related to medical devices. We have used direct quotes from both suppliers and users throughout this document in appropriate topical sections. In some cases, the statements don’t provide a full explanation or a question is posed that isn’t answered here. These have been noted and collated for possible further investigation in the next phase. We have endeavored to identify clearly when a comment came from only one source or whether several participants made similar statements. This applies especially to summary tables where feedback may have come from just one participant.

Supplier Experience in Collating and Entering Data Attributes

Overall

In the supplier feedback form, we asked suppliers to list all the people involved with the pilot test. The responses received ranged from 1 to 23 staff members. The list below shows the range of staff titles of participants contributing to the pilot test, combined from the feedback form where respondents identified titles of staff who participated and from the participant list constructed at the beginning of the pilot test.

• Vice President, Government Affairs
• Document Control Manager
• Chief Information Officer
• Global Process Owner, AUTO ID Technology and Data Standards
• Director, E-Commerce
• Manager Corporate Sales Administration
• Manager, Marketing Programs
• Manager, Marketing Programs
• UDI Program Manager
• Vice President for Information Technology
• eCommunications Coordinator and Database Administrator
• VP, Corporate Marketing
• UDI Program Manager
• Regulatory

Table 1 shows the amount of data that each supplier stated they had provided.

Table 1. Amount of Data Provided to the UDI Database by Each Supplier

Supplier	Number of Unique Devices Provided
A	83 records were entered which represented 55 products
B	Data for 236 devices (including multiple packaging levels)
C	131
D	138
E	22
F	11

“We appreciate the FDA’s efforts to align their data requirements with commercially utilized data attributes and systems where possible. Aligning regulatory attributes with supply chain attributes wisely acknowledges how data is stored and shared and increases the probability of success.”

When asked about their overall impressions of the database and the application, suppliers’ feedback was generally positive while also focusing on the array of information that was requested. From their viewpoint, much of it would be difficult for them to provide, for a variety of reasons. (We further describe the challenges of data collection and comments about each of the 47 variables as well.) Suppliers appreciated efforts to align their data requirements with commercially-utilized data attributes and systems as opposed to introducing new ones, as shown in the quote in the text box at the right.

The following statements are direct quotes⁵ from supplier participants in response to a question on their overall comments and impressions about the UDI database.⁶

• "The UDI database addresses the objectives of the UDMS,⁷ however, it significantly expands data content beyond those objectives."
• "For purposes of patient safety, this will be an excellent tool for reporting information out to health care providers; however, the related device information produces unnecessary hardship for these reporting purposes."
• "The design of the UDI database and the selection of attributes contributed to the impression that the UDI database is trying to be all things to all people."
• "Due to the complexity of gearing up to gather, store, maintain and syndicate data, it is best to maintain a reasonable scope for the initial launch of the UDI database."

In a variety of ways from the beginning of the pilot test, suppliers requested additional information that would help them understand the business or regulatory goals for the Unique Device Identifier Database.

Data Gathering and Data Entry

We asked suppliers to numerically rate the ease of the overall process by which they prepared the required data attributes (identifying and entering the data). (Ratings were on a 5-point scale with 1 being very easy and 5 being very difficult.) Ratings varied as shown in the table below. One supplier felt it was relatively easy while two suppliers rated the overall process a "3" (neither easy nor difficult). Two others felt it was somewhat difficult, rating it as "4."

Table 2. Supplier Participant Ratings on the Ease of the Overall Preparation Process

A	4
B	[no answer]
C	4 (for data fields entered). We did not populate all data fields.
D	3
E	2
F	3

Suppliers were asked to comment on the data-gathering process for the products/device information that they uploaded information into the UDI database. The recurrent theme in both written and conversational feedback was the amount of information that is not maintained by suppliers in any centralized systems or not even documented or kept anywhere along with a corollary set of comments about the relevance of a significant number of attributes’ relevance to UDI as shown by o ne supplier’s overall comment on this:

"The majority of the attributes requested would require they be maintained in a central location to easily provide to the FDA. For a majority of the attributes, we do not have a central location and this would require development of procedures and assignment of resources to collect & maintain the data and provide to the FDA. Our current process for this pilot required us to contact multiple areas of expertise within our various divisions, and therefore, would not be a viable solution to continuing to provide data in a timely manner going forward. In addition, there are attributes that are not even maintained currently anywhere in our organization today, which again, would require the development of procedures and assignment of resources."

Our analysis of this issue from the individual attribute feedback shows that there is wide variety across the six suppliers about their ability to provide specific data. There were just three suppliers who found it difficult to supply data for one or more attributes. The one supplier who felt data would be easy to provide was always the same supplier. Other suppliers were silent on this topic. For the required attributes, one or two suppliers felt they could not easily supply data on six of these while one supplier stated that, for two of those attributes, data would be easy to provide. For the non-required attributes, one to three suppliers felt they could not supply data for 20 of the attributes. For two of these attributes, another supplier stated the data would be easy to provide.

Suppliers were asked to rate and comment on the two different methods of data entry. Ratings are shown in the table below. For auto-load (information compiled into the Excel template and uploaded by GHX into the database), ratings were "1" or "2," except for one supplier who rated the process at "4." Therefore most of the suppliers found compiling this data into the spreadsheet easy to do. For the manual data-entry process, there was more variation with 3 suppliers rating it as "2" while others gave it a "3" or "4," showing that, at best, suppliers did not feel manual data entry was easy to do.

Table 3. Supplier Ratings for Auto-Load and Manual Data Entry

Question	Supplier
	A	B	C	D	E	F
How easy/intuitive was the upload process using the spreadsheet template from GHX?	2	1	2	1	2	4
How easy/intuitive was the manual data-entry process using the UDI database application?	4	2	3	2	2	N/A

Comments made on the ratings were on specific issues relating to either the data-preparation template or the database application. For example, several suppliers noted that the Excel file columns and manual data-entry fields shown in the interface weren’t in the same order. Many suppliers gave specific feedback on application functions that did not work properly. Some were small software bugs that were easily fixed during the pilot-test. Most suppliers also made suggestions for application improvements as well. Suppliers also requested better information in terms of a User or Implementation Guide including online Help documentation that includes the definitions for the data attributes.

FDA was interested in feedback on whether suppliers had other data/information that could be of use to the FDA and whether they were familiar with HL7 SPL requirements. All but one of the suppliers did not feel they had additional information that would be useful to FDA and easy to send. (One supplier did provide detailed comments on this question, but the comments related to very specific data attributes and are not discussed here.) All but one of the suppliers said that they were not familiar with the HL7 SPL data requirements. This topic also came up in feedback sessions and FDA distributed the relevant FDA URL as reference for them.

We asked suppliers for any other comments or specific topics they wanted to discuss in the follow-up teleconference feedback session. Most of the suppliers focused on wanting further discussion of the attribute definitions, including rules for addressing specific examples and circumstances. Moreover, they wanted to explore the definition for a "unique device," including clarification as to what changes in a device or its attributes would require a new Unique Device Identifier.

Finally, we asked suppliers to rate the ease of acquiring the data for the specific attributes (using the same 5-point scale described above) and to provide comments on the attributes. All six suppliers provided ratings and detailed comments on the 47 attributes.⁸ There was often great supplier variation in perspective about their ability to provide information, with some suppliers giving "difficult" ratings while other suppliers rated the same attribute as "easy."

We summarize here the open-ended feedback on the attributes and also show a synthesis of supplier comments and feedback in the multipage table which begins on the next page (Table 4). As we noted above, comments below are either direct quotes or are a summary of feedback from more than one supplier. Where multiple suppliers had the same comment, we show an "X" in the relevant column on the table.⁹

Generally, most of the fields GHX thought would be difficult to provide were rated as difficult by the suppliers. Suppliers gave very valuable feedback on specific data attributes and for groups of attributes. For example, several s uppliers feel that FDA should request the name of the actual allergen/s that a device contains and that the attribute should collect (via a drop-down list) the set of the known allergens.

Suppliers felt there would be a significant advantage to synchronizing Unique Device Identifier Database and GDSN fields and publication protocol. It should be noted, however, that supporting the Unique Device Identifier Database via GDSN may require the community to lobby with GDSN to modify some of their data attributes.

The use of NDC needs to be clarified. Currently, ten-digit and eleven-digit NDC codes are used to identify a product while eleven-digit NDC codes are used in reimbursement. The decision to include or not to include eleven-digit NDCs needs to be made and clearly promulgated to healthcare providers.

Suppliers were looking to apply a standard to the Unit of Measure attribute. Establishing a standard for this attribute would depend on the business goal for the Unique Device Identifier Database. If the business goals are supply chain-related, the ANSI X12 Standard Units of Measure should be used. If the business goals do not include supply chain, then the unit of measure is strictly informational and a free-text description should suffice.

A further issue for suppliers was on the topic of device or part supplier and location of manufacture since manufacturers can produce the same device with the same UDI in more than one facility, with product traceability provided by differentiating lot numbers and/or serial numbers. The manufacturers wanted assurance that, in these cases, the UDI would not change.

Suppliers noted that the "country of" attributes are defined differently by various regulatory bodies. They felt that the inclusion of these attributes in the UDID database would not yield benefit to the regulators.

There was a suggestion that several attributes could be easier to maintain if they were only published to the organization’s website and the URL was posted to Unique Device Identifier Database rather than the value of the attribute itself. Some suppliers also commented that they would be unable to provide a URL link to a specific product.

Table 4. Synthesis of Supplier Open-Ended Comments about Attributes in the UDI Prototype Database

Attribute or Attribute Group*   * = required variables	Supplier Feedback Highlights (These are quotes or paraphrased directly from 1 or more supplier’s written feedback)	In multiple systems	Relevance to UDI unclear	Need further definition	In FDA system?
Organization Identifier*	Suggestion to use GLN. Suggestion to break down by division
Unique Device Identifier Type / Code*	Kudos for using existing codes vs. creating a new one. Is it possible for a given product to have more than 1 Unique Device Identifier? A product with a current HIBCC could be in the process of having a GTIN assigned. For diabetes and wound management products, an NDC and a 14 digit GTIN that contains the NDC are used. One for reimbursement and one for point of sale. Does a product need to be labeled with the UDI in a human- and machine-readable format in order to be loaded into the UDID? GTINs can be less than 14 digits. NDCs of 11 characters were identified.
Brand Name	Difficult to locate these data because they are not being captured by all companies in their systems10 35 char may not be enough. (expanding length creates challenge in matching GDSN 35 char format)
Product Number*	A single device may have more than one product number for the same Manufacturer.
Unit of Measure*	Suppliers suggested using a Standard (Implementation concern is what Standard?) Strategic question is what is this used for? Is a box of X unique devices really unique? It is unique from a supply-chain standpoint, but is it unique from a patient safety standpoint?
FDA Product Code*	Suggestion that the data is already in FDA system. (Challenge is that the Pro Codes in FDA are not associated to UDIs) If this is a requirement, it should only be for new products approved for distribution after the UDI rule has been promulgated Unique Device can have multiple Pro Codes	X
US Marketing Authorization Type & Code*	Device could have multiple Marketing Authorization Codes One supplier had major concerns over making these data public If this is a requirement, it should only be for new products approved for distribution after the UDI rule has been promulgated More than one supplier considered the device Marketing Authorization to be Pre-Amendment and therefore the drop-down list needs to be expanded As Unique Device Identifier expands globally, capturing the appropriate data will increase in complexity	X			X
Device Control Mechanism*	One supplier reports all items are controlled by lot number. These data are not currently captured or maintained in any central system and is therefore difficult to obtain	X
Status	Supplier interpreted this as Device status to Market vs. Device record status in database. Need to determine if/how market status would be addressed
GMDN Classification & Preferred Terms	Maintenance concerns associated with frequent changes to GMDN coding system Concern that GMDN is not often used in the US Marketplace Not all products have been assigned a GMDN Code GMDN better than UNSPSC Does not include all products at this time There are deviations to GMDN, such as EDMS & AMDN.	X
Country of Origin, Manufacture & Intended Sale	Device can be made of parts manufactured (originating) in multiple countries Suppliers challenge the value of publishing this data Maintenance of this data will present significant challenge Intended Country of Sale is information that should be kept confidential from competitors			X
Unique Device Identifier Description- Abbreviated* & Full	Suppliers would like to include more info in these fields Suppliers suggested that a single description would be sufficient
Labeled with Expiration Date	Using "Labeled" as criteria is beneficial.	X	X
Labeled as Sterile	Using "Labeled" as criteria is beneficial.	X	X
Labeled as Single Use Only	Using "Labeled" as criteria is beneficial. Suggestion to link this to GDSN standard on reusability	X	X
Labeled as containing Known Allergens	Multiple suppliers suggested, for the reason of patient safety, to list the known allergen/s (DEHP, PVC, Nickel, BPA, Latex)			X
Labeled as Hazardous	Are we using the DOT definition of hazardous? Definition is not at all clear
Indicated for Home Use	The definition of home use is unclear. Need to distinguish whether it means use by consumer or by home health care provider or both		X	X
Prescription	Suppliers requested distinction between State and National requirements.11 Suggestion: "Labeled as Rx only" (Y/N)?	X
Requires Electricity & Battery	Should be apparent to the clinician who has the product.	X	X	X
Radioactive Isotope	Suggestion - the field be utilized only for select GMDN categories?	X	X
Implant Type	What about resorbable devices? Suppliers don’t necessarily distinguish between permanent and temporary. Permanent could become temporary and vice versa.	X	X	X
MRI Compatibility Type & Conditional Text	Data does not exist for most medical devices	X	X	X
Has Device been Recalled? Y/N	We did not provide this information since all products supplied are not currently recalled and this would require future maintenance of changing the status of the product in the database if the recall status were to change. What is the intended use of this field? Suggest renaming the field. Perhaps "Is the Device currently being recalled?" Aligned with the intent of UDI, however clarity will be req'd on the timing of toggling this value before/during/after a recall vs. the communication plan that accompanies recalls.	X		X	X12
Material Safety Data Sheet & URL	Supplier has a subscription type service Process is manual	X	X
Product URL	Responses ranged from "easy to provide" to "URLs not supported"
Storage Handling Temperature	Storage and handling data are provided in the product labeling. The product labeling should be the primary source for directions to handle and store product. Inclusion of these attributes in the UDID database would not yield benefit to the user. Labeling requirements are controlled separately Suggestion to include "text" options Current implementation was based on GDSN.	X	X
Storage Handling Humidity	Storage and handling data are provided in the product labeling. The product labeling should be the primary source for directions to handle and store product. Inclusion of these attributes in the UDID database would not yield benefit to the user. Labeling requirements are controlled separately Suggestion to include "text" options Current implementation was based on GDSN.	X	X
Previous Unique Device Identifier Code	Does this represent a different UDI (HIBCC vs. GTIN), if so, then ok. If it represents replacement products, not sure why this would even be needed. The replacement product scenario is not something that we currently maintain, and we would need to implement processes to support.

The feedback on Relationship Type & Associated Unique Device Identifier Codes was extensive so the quotes are shown here:

• "Do not see necessity of providing this information if recalls are reported correctly."
• "Gathering this information places an undue hardship on the supplier."
• "Need better understanding of combination and convenience kits."
• "We did not have sufficient time to populate this field. We believe this field will be very difficult to populate for some products."
• "Clear for AC. What exactly is a CE (just a medical device that has accessories that are listed as medical devices)? Not clear for how to enter sub-components of CP, CK devices. Not clear for when to use PK: when sub-component device or when independent device that has an equivalent sub-component, or both? Recommend working on value proposition for each category, definitions and clarity."
• "The "device relationship" attributes are complex. Relationships exist among medical devices made by several manufacturers. Unless clear rules and examples are provided to industry, the accuracy of this data would be in question. Again, the clinician / user should refer to the product labeling to determine the relationship or interoperability of the medical devices. Currently, manufacturers may change these relationships such as adding an accessory without changing the UDI of the parent device."
• "Device relationships with kits would be especially problematic."
• "The relationships should be provided in the product labeling and the burden of including these relationships in the database outweigh what benefit would be derived."

Additional Supplier Feedback

Suppliers raised additional questions that they believe could have significant impact on their business and implementation processes. Most of these point to the need for clarifying definitions, agreeing on standards that the definitions will be consistent with, and setting standards for the timing of when data would be added to the database. The questions below from three different suppliers show the various nuances surrounding the issue of when a device would get a unique device identifier.

• "When would a device be populated in Unique Device Identifier Database (from a product life cycle standpoint)?"
• "Is a bar code representing a Unique Device Identifier required on the device prior to publishing to the Unique Device Identifier Database?"
• "Legislation states the Unique Device Identifier must be human- and machine-readable, does the device need to meet those constraints prior to being loaded into the Unique Device Identifier Database?"

User Experience in Using the UDI Database

At all of the user sites, except one, there were teams of two or three staff who participated in the pilot test although only one user actually tested the database at each site. The user participants’ titles include:

• System Direct or - Corporate Supply Chain
• Healthcare Risk Management Consultant
• Manager of Clinical Engineering
• Director, Materials Management
• Risk Management & Regulatory Compliance
• Information Analyst, Risk Management
• Clinical Risk Specialist, Risk Management
• Administrative Director, Risk Management, Regulatory Compliance
• Market Risk Officer
• Director, Medical Technology & Safety

The quotes from users in all of the tables below were taken directly from their feedback forms. The o verall user impressions about the UDI database are highly favorable and users were laudatory, as shown by the comments in the table below.

Table 5. User Overall Comments on the UDI Database

Site	Comments
A	"Overall, I found the database was very easy in which to navigate and sort the data as needed. Very user-friendly...anyone with at least intermediate level knowledge about Microsoft Excel and Access should have no problem searching for items."
B	"User friendly with a good quantity of attributes." *Straightforward and enhanced over the 510K db. Easier to use than 501K and ECRI. This is much more data than he would readily have access to.13
C	"Very easy to use with only a brief orientation; could be a useful tool with the expansion of fields; should be able to filter on any field to make lists manageable for any search"14
D	"Plenty of data; some fields are irrelevant to my work, some is very useful The concept of the system is good and potentially quite useful!"
E	"Overall, the UDI database was simple to use. It was very user-friendly and easy to navigate. "

A 5-point scale was used throughout the feedback form for users to rate various aspects, as shown below.

1. Very easy
2. Easy
3. Neither easy nor difficult
4. Difficult
5. Very difficult

Users were asked to rate the ease of the overall process for searching, filtering, and preparing subsets of information and exporting them for further analytic use. All but one site rated the ease of the overall process as a "1" or "2." Only one site found it difficult but attributed that to difficulties exporting information, as discussed further below.

Users then rated the ease of conducting both scripted searches. For script 1, users were asked to find information about a type of product. All users rated this task as easy or very easy to do. The table below shows their ratings as well as their comments.

Table 6. User Ratings and Comments on Script 1, Finding Information about a Type of Product

Site	Rating	Comments
A	2	"A little effort on this first script due to adding column heading"
B	1	[none]
C	1	"I added the device description column to the display and filtered under Nitinol. 2 entries resulted with seemingly identical data except for device ID#. I added all fields to the display to find out the difference – it was UOM with one as EA and the other CA. There should be a way to quickly add all fields to the display like there is for removing all. This would have helped me find the exact number more readily."15
D	2	"This task was straightforward"
E	1	"Applying the filter by typing the word "catheter" in the Device Desc field in the filters pane made it easy. However, if it wasn’t for the note/reminder in the instructions to add "Device Desc" to the display fields, I may not have done so. It may be helpful to have "Device Desc" as a default display field."

For script 2, users were asked to filter information and then export a set of product information for further use or analysis. All but one user found this process easy. The one who rated this a "5" stated the rating was due to the inability to export data. The export-data function is highly reliant on browser settings and, for most of the sites, institutional IT security settings override data-exporting. (Two users realized this issue was a security-setting issue and didn’t factor this into their rating.)

Table 7. User Ratings and Comments on Script 2: Filtering and Exporting Information

Site	Rating	Comments
A	2	"Again, anyone with knowledge of Excel won’t encounter a problem with this step."
B	2	[none made]
C	2	"Very easy to find and sort. However, there should be a way to highlight several fields and then add or remove with one click. Also, I could not find the exported text file. After hitting export there is just a momentary pop-up that then disappears. Maybe this is just a setting on my PC."
D	5	"5 because I could not complete the export. I clicked on "export" and was unable to go farther. I could not find where the exported file was going to."16
E	1	"Limiting the display fields makes exporting information a lot succinct without having too much information. Exporting the text file was simple to do. Importing it into a spreadsheet may be challenging for other users, especially if they are not comfortable with importing data. A concern of mine is the fact that all fields have to be put in "text" format when importing into the spreadsheet; I’m not sure how this will affect being able to analyze the data and manipulate or make graphs etc. Moreover, when importing the data, symbols like the trade sign TM get imported as &trade."

For the third script, users were asked to conduct a free-form search. In the table below, users describe what they searched for and the comments they had about this process.

Table 8. Script 3: User Free-form Searching: Information Searched for and Comments on the Process

Site	Information searched for	Comments
A	Upon first attempt to search for recalled item after adding column heading found all were labeled as "not supplied", so then filtered on all mesh products and searched by specific size.	"Very easy to navigate and search"
B	Using the needle example and filtering for: Different Organizations Exempt 510K Active Status Pending Status	"Overall is a very easy to use and user friendly."
C	I searched for MRI compatible devices. I sorted the columns on MRI compatibility type There were none in the database	"I would have preferred to filter on this field rather than do a column sort. For example, if a database of 3000 devices has 50 that are MR compatible, the result of my search would be only those 50 if I could filter on that field. Instead, with the column search I still get all 3000 entries with the 50 MR compatible units at the top. I get the info I need, but the exported file is very large. I think you should be able to filter on any field if possible"17
D	Specific suture on which we filed a complaint and MedSun report last year	"Data entry was simple. Not all of this supplier’s items are in the database at this time."
E	Balloon catheter	"This was a simple search by using the "Device Desc". I definitely think this filter field of "Device Desc" will be one of the most commonly used filters. On another note, since this was a pilot test, we weren’t able to search for other companies or devices that we wanted to search for since it was not available. Therefore, searching for a similar device made by another company served as our free-form searching."

FDA was interested in user suggestions, specific to recall and adverse reporting needs, whether there were data fields users would recommend adding to the UDI database. Table 9 below shows their rationale for the suggestion. Many of the suggestions seem to stem from user interest in this database supporting their work in managing recalled products for their facilities.

Table 9. User Suggestions and Rationale for Data Fields to Consider Adding

Site	Suggestions for Data Fields to be Added	Briefly describe why the field would be useful to you
A	Date of Recall	"Determine whether current or dated, which we’ve already handled"
	Type of recall (Voluntary or FDA-mandated)	"Determine level of severity in order to prioritize accordingly"
B	Software version.	"Recall by software version"
	Class I, II, III.	"510k approval process"
	OEM and contact info	"When vendor not responding"
C	Manufacturer contact info (address, phone number, website)	"This is requested on Medwatch reports"
	Previous Organization or manufacturer names	"Manufacturers often change their names. We may know it as one, but may be listed as another. How will this be managed?"
D	Lot #s	"Imperative in managing a recall.I recognize this could be a huge database and the info isn’t static so this may not be possible"
E	Product Issue	"This can help to track and trend and to identify issues that may occur with a device in order to be proactive."
	Recommended Actions	"This will help inform what the recommended actions the manufacturer has advised."
	Lot #s	"This will help with recalls, especially in pulling products off the supply shelves. However, since there are so many lot #s, this may not be feasible to do. If there is a recall issued, possibly can include at that respective time."

Again, related to recalls and adverse reporting, users were asked to rate how useful the database would be to a user’s organization after it is publicly available through FDA. All users found that the database would be very helpful (1) or somewhat helpful (2) and provided comments on how/why this could be of use, as shown in the next table.

Table 10. User Ratings and Comments on Usefulness of the Database when it is Publicly Available

Site	Rating	Comments
A	1	"We already receive the FDA recall notices but this would allow us a secondary method in which to make sure we have handled all as required over time."
B	1	[none]
C	2	"This could be used as a quick tool to identify if there are current alerts on a product you are considering implementing. Also, if the device ID number was tracked with purchases, we could tell quickly if there are potential affected products. However, this would require diligence and coordination in product procurement."
D	1	"Recalls: having a good database is critical"
E	1	"I would rate it as being very helpful. Because manufacturers are inputting device information etc. into the database, the UDI database serves as a great reference for many organizations, device users, etc. In terms of recalls, it can help identify other similar devices that are in the market in the event of changing to a different manufacturer. For adverse reporting or voluntary reporting of medical devices that fail or malfunction, this can help identify the product name, manufacturer, etc. To help standardize information being reported on devices."

We were very interested in user perspectives for the two or three business reasons they thought the database would be useful. Most of the users see this database as advantageous for their work on recalls and on adverse events. They also see the database as a very useful source for them to identify an alternate product and manufacturer when products are recalled. The comments in the table are taken directly from the user feedback forms.

Table 11. Business-Use Cases for which the UDI Database will be Useful

Site	Business Use 1	Business Use 2	Business Use 3
A	Searching for recalled products	Determine country of origin of certain products to confirm statements made by sales representatives at times	Filter and sort by implant type....very needed when trying to determine where the implants is considered ortho vs spine
B	Purchasing new device/ equipment- What is available? Who are the manufacturers?	Recall – need model, lot, serial numbers and software versions. Need an alternative source for replacement.	Adverse events
C	I suggest adding fields for Latex, DEHP, and luer connections. This would be very useful for informed product procurement. The addition of manufacturer contact information would also aid this function.	Adverse incident reporting if manufacturer contact info was added	Recall management when there may be some confusion in reports received from RASMAS
D	Identifying products for potential purchase. Verifying manufacturer catalogue numbers in purchase process	Recalls-helping to verify recall-related info	Identify a related device for a different manufacturer if the end user needs a replacement item . This one-stop shop is very attractive.....
E	Looking for alternate devices in the event of a recall or having to switch to another device from a different manufacturer	Using the database as a reference when completing MedSun/MedWatch reports for devices that fail or malfunction – This can help clarify product #, device name, manufacturer name, etc.18

Finally, users were asked to describe other comments or identify specific topics to discuss in the follow-up phone call. (We have also included questions users raised in the feedback teleconferences which are asterisked below.) The comments cover a range of topics, as shown in the table below.

Table 12. Specific User Topics for the Follow-Up Feedback Teleconference

Site	Comments
A	N/A
B	"I believe this is a needed database that extremely user friendly."
C	"Most of the devices listed are supply-type. Will the scope include durable equipment as well? If so, there could be some benefits to this that would drive more consistent equipment inventories at healthcare facilities."
D	"Nomenclature "organization" is unusual. The more common term "manufacturers" is the term used by materials managers and – I suspect – Risk Managers."*Need a multi-word description because the device organization responsible may not be the manufacturer
E	"Will all device companies be providing information into the UDI database?How can this interface or ease reporting of device failures/malfunction relating to SMDA (mandatory and voluntary reporting)? What do you mean by device type (e.g. HIBCC, NDC, GS1)? Not sure how to use this filter. This doesn’t seem to be a user need." *How will this help us with MedSun reporting? *Can we ensure the use of this as a resource?

Discussion

We identified several key questions of interest for the pilot test to examine (as shown in double-lined, italicized text boxes above each discussion section).¹⁹ We discuss each of these briefly below. Following that section, we describe further issues identified, challenges to be considered as the Unique Device Identification System (UDIS) is further developed, and additional information for FDA to consider. A key consideration for future development revolves around required data attributes and the implication of these requirements on the suppliers.

Answering the Supplier Key Questions

How readily are data suppliers (manufacturers) able to identify/obtain the data for the required attributes and manipulate them for upload into the database?

As described in detail above in the Results section and in various collateral materials (appendices, Excel spreadsheets of all supplier comments), manufacturers did provide data on more devices than we originally expected. All suppliers provided data for most or all of the 11 required attributes for each device.²⁰ Only a couple manufacturers provided much additional information for the other 36 attributes. Whether or not they provided data on all 47 attributes, all suppliers did give us ratings and comments on each of the 47 attributes in terms of their company’s ability to provide that information and any clarifications they felt were needed to the specific attribute.

It is notable that most suppliers volunteered the information that different data elements being requested resided in databases in several different areas of the company.²¹ For the data provided, for example, one supplier answered the first feedback field (Name and title of person(s) participating in this pilot-test) with a list of the 23 different people involved in identifying and providing the data for all the attributes.

"We examined multiple internal systems in order to find sources of the data. There were at least four internal systems required to populate the data that we submitted for the UDID pilot. We made a good faith effort to provide the desired data based on the limited information provided regarding the use of the data." "The database contains a large number of very diverse data fields. As a result, a large group of participants (23 in total) had to access multiple databases (no single person had access to all of the databases) to populate the fields for the 246 products included in this pilot."

In some cases, these suppliers do not have the required data, but the information may be available in a local database in another location (such as another country). In some cases, the supplier does not collect the data at all anywhere within the company, and it would be very burdensome for them to have to add a method for collecting and storing this information to then be able to report it to the FDA.

"(We have) made every effort to centralize information on products that are used globally among all manufacturing systems, and can therefore support reporting this information out to recognized authorities. However, in reference to related devices, some information is appropriately maintained only in local manufacturing systems, in support of operations that are only local. These systems have not been linked to the centralized repository and the effort to do so would be costly."

We know that a significant proportion of suppliers did not provide much more data than that for the 11 required attributes even though our target was that all supplier participants would be able to supply data for about two-thirds of the other 36 variables. Their feedback on many of these non-required attributes was that the data was difficult to collect and provide.

What concerns do suppliers have about sharing of these data?

Two suppliers stated concerns; one felt that "US Marketing Authorization Type & Code" should be confidential while another felt that "Intended Country of Sale" must be kept confidential.

What was the suppliers’ interface experience with the data entry process? Was the data entry interface user-friendly and intuitive?

Suppliers preferred the auto-load option rather than manual data entry option for providing data to the database. This is not surprising since they used the Excel template to identify all product information in the initial phase of the pilot test and then used a segment of the collected data to enter the data manually while GHX did the actual auto-loading for the supplier, using the spreadsheet.

Suppliers felt that the interface was generally user-friendly and intuitive. More than one asked that the full (rather than the abbreviated) "Unique Device Identifier Description" be a default attribute in the opening view of the application. A few functionality issues were raised by the supplier participant to the GHX liaison, and GHX was often able to make changes needed within 24 hours.

Suppliers expressed concern about how and how rapidly they would be expected to provide very large (and, in some cases, huge) amounts of product data to populate the database initially, even if they had the option of supplying it all to GHX by an Excel template for GHX to upload. Thus, we conclude that the data entry process was adequate for the pilot test but would not be sufficient for the initial roll-out of the system for any supplier needing to supply data on more than 100 devices.

Feedback Related to the Unique Device Identification System

Beyond these key questions are several areas of feedback from suppliers that apply to the Unique Device Identification System as a whole and which are important for FDA consideration and clarification as FDA develops the UDIS.

• The Business Case for the UDIS. More than one supplier asked several times for more clarity from FDA on the business reasons for some of the data attributes proposed for the UDIS. As FDA moves along on the process towards unveiling this system, making clear the business case (for both internal FDA use and for external use with whatever the extent of publicly-available information) will help suppliers understand the rationale for the extent of data they will be providing. For example, other FDA databases may be populated with data from the Unique Device Identifier Database. Stating this to suppliers may help change perspectives on why they are being asked for data that appears to them not to be related to patient safety.
• Large Number of Data Attributes in the UDI Database. It would seem that the suppliers assumed that the UDID will respond to the legislative mandate to "adequately identify the device." Further, it would seem that they think the legislation’s purpose is to further patient safety (among other things). Therefore, the extent of the data presently needed in the UDI database is seen as much beyond the mandate (as understood by suppliers) of the UDI database. Suppliers would prefer that FDA narrow the scope of the UDI database for what is truly needed. We note that it is unclear is how suppliers understand the legislation to which FDA is responding. The quotes below illustrate the confusion and point to an education need.

"Based on the attributes FDA will require, FDA can determine how simple or difficult it will be for Suppliers to comply with Unique Device Identifier mandates." "To make data collection efficient and to maintain the accuracy of the data provided, we ask that the data required for the UDI database be limited to the scope of the mandate: unique device identification for patient safety."

• One-time Data Entry or the Large Volume of Effort Needed to Maintain a Reference Database.We described previously the effort it will take some suppliers to comply initially with needing to populate the UDI database because of the large numbers of products these particular manufacturers carry. Suppliers also commented that ongoing support of this database and keeping it up to date will be exponentially more difficult than capturing data in it initially. This seems to be due to the number of items that manufacturers have in their products lines, the number of tracking and management information systems they use for their internal processes, and disparity of business operations as well as to the fact that products are revised and improved over time.

" Significant difference in difficulty between generating pilot information vs. expected difficulty in generating and maintaining live database information (see attached spreadsheet) as part of a regulatory requirement." "Some information in the database will have to be reviewed regularly and updated. The maintenance process in the database is not clear. Will the system track changes and data maintenance? It will take significant manpower to populate and maintain a database that will include thousands of catalog numbers."

• Additional Clarification Needed About Purpose of UDIS and Public Access to Data.Some suppliers are concerned over the intended purpose of the data, and potential access to and the possible uses of public information.

"We would also like to discuss the overall intent of UDID and the intended uses of the database. This will help us identify the most critical data elements so that we can ensure that we populate those fields accurately and in a timely fashion."

• Data already collected by FDA.Many raised the issue of being asked to provide information (e.g., recall-related information) that is already reported to the FDA through a separate mechanism/system. This causes burden on manufacturers and risks data accuracy if information is recorded in two different locations.
• GDSN and Device Organization’s Attributes.There were questions and feedback about the GDSN and Device Organizations attributes, both of which were out of scope for Phase 3. (See Recommendations section.)

Answering the User Key Questions

How readily can users apply the sort and search capabilities within the database to find desired information? Are users able to easily locate data that apply to their institutional needs, configure the output via the web-based environment, and export those data to their desktop for their use?

Users had a very positive reaction to this application. They were readily able to use the prototype database in both scripted and free-form searches, both filtering and exporting data.

Users liked the fact that the database offered a one-stop location for the kinds of situations they deal with regularly, even when they have other sources for some of the same data. Users generally identified similar business cases for the UDI database:

• Finding more information for recall-related needs
• Identifying alternate products/manufacturers for recalled products.

Recommendations

The pilot test shows many aspects of the Unique Device Identification System which form a basis for FDA to continue identifying system requirements, especially from the UDI prototype database.

General Recommendations

Clearly stating the business uses for the UDIS. Suppliers need more clarification on the business use(s) for the UDIS and users need to clearly understand the extent of and limits to the UDIS.

Recommendation: Clearly explaining the business use(s) for the UDIS will help manage supplier and user expectations for the information that it will contain. Including scenarios that would demonstrate how having a unique device identifier would be used to meet FDA requirements and address patient safety issues would be very useful. Process issues such as clearly identifying the rules for assigning a new UDI are also needed as the system is further defined.

Dealing with technical issues for system design and implementation. All government-sponsored systems must conform to a variety of technical "best practices" and regulations.

Recommendation: Requirements for a production version of the UDIS would include dealing with technical issues such as alternate browser compatibility, Section 508 accessibility compliance, hosting and maintenance parameters, scalability, etc.

Recommendations for Finalizing List of Attributes for the UDI Database

Maximizing supplier ability to comply with the data requirements.Our experience with the suppliers who provided data to the UDI prototype database is that device manufacturers/suppliers will only provide/publish the data fields required by the FDA. If a set of attributes is difficult/costly for suppliers to provide to the system, the perceived benefit (to public safety) needs to outweigh the costs. In addition, suppliers have identified where clarification of definitions or standardized lists would be needed to help them be able to comply.

Recommendation:We have identified below changes or enhancements that FDA should consider making to attributes. As FDA reviews the detailed feedback on each attribute and has the opportunity for additional informal feedback, FDA may better be able to clarify the attributes some suppliers feel would be problematic information for them to supply. FDA’s collaboration on global harmonization efforts especially the Global Harmonization Task Force (GHTF) will also assist FDA in finalizing the list of attributes.

There are two tables below which summarize the enhancements and changes we have identified from this pilot test for FDA to consider. The first table, Table 13, lists those changes to one or more attributes while Table 14 prioritizes changes for improved application functionality.

In both tables, enhancements and changes are categorized in one of three ways:

• Critical to change:These are urgent to be addressed in the next phase as they will have an immediate and positive impact on suppliers’ data collection efforts and thus increase data accuracy and improve supplier compliance with providing data.²²
• Important to Change:These enhancements will increase and extend the functionality of the system, adding important value to the application.
• Could be Changed:These enhancements may increase user-friendliness and would add value to the application but are not critical to its functions nor have much impact on data collection and data provision.

Table 13. Recommended Changes for Specific Attributes²³

Item	Changes/Enhancement(s)
Critical to Change
UDI Type/Code*	Allow Multiple Unique Device Identifiers for a single device (or create a cross reference to another Unique Device Identifier relationship to single Unique Device Identifier)24
	Ability to change / edit a Unique Device Identifier Code once it is entered
	Ability to accommodate various GTIN Field Lengths
	Ability to support NDC Codes of 10 & 11 characters
Product Number*	Ability to enter multiple Manufacturer Product Codes for one Unique Device Identifier
FDA Product Code*	Ability to enter multiple FDA Product Codes for one Unique Device Identifier
Status*	Pending items viewable to Organization (owner) only
Country of Origin, Manufacture & Intended Sale	Ability to enter multiple countries
US Marketing Authorization Type/Code*	Ability to enter multiple Marketing Authorization Codes
Important to Change
US Marketing Authorization Type/Code*	Create additional Marketing Authorization Type of "Pre Amendment"
	Expand 510K Marketing Authorization data type to be 7 character Alpha/Numeric
Brand Name	Expand field length of Brand Name (to remain in sync with GDSN) Note: a Change Request to expand field length of Brand Name should be submitted to GDSN Identify how to match Brand Name to information in FDA’s Device Registration and Listing
GMDN & Preferred Terms	Preferred Terms are derived from GMDN code (as FDA Product Code Description is referenced from FDA Product Code)
Unique Device Identifier Description- Abbreviated* & Full	Extend field lengths
Labeled as containing Known Allergens	Develop standardized list for devices from Unique Ingredient Identifier (UNII) list of potential allergens25
Storage Handling Temperature	Include text options (i.e. Room Temperature)
Storage Handling Humidity	Include text options (i.e. Store in a Cool and Dry Place)
Unit of Measure*	Apply a standard UOM list and associated validation. (This was discussed during Phase-2 requirements-gathering. The role of UOM is dependent on the goal of the UDID. If goal is supply chain-related, standard UOMs would be valuable. May need to consider Unified Code for Units of Measure (UCUM) which is the standard for unit of measure in applications related to electronic health records from the Office of the National Coordinator for Health Information Technology.)
Could be Changed
Storage Handling Temperature	Change Temperature UOM to C vs CE and F vs FA (GDSN supports CE & FA)
US Marketing Authorization Type & Code*	FDA may want to explore in the next phase how a device with multiple Marketing Authorization Codes would be handled

The following table shows prioritized changes for improved application functionality.

Table 14. Recommended Application Function Enhancements for the Unique Device Identification System

Item	Enhancement(s)
Critical to Change
Add/Edit Device	Ability to copy and paste data into all fields. Field length and data type would still be validated. Allow ability to cut and paste across multiple lines, including CR/LF.
Expanded Filtering	Ability to filter based on "AND" & "OR" statements Solution would apply to any filter and across filters
Help Documentation	Solution should include Help including online codebook of Attribute definitions
MRI Compatibility Filter	Filter on MRI Compatibility Attribute returns no data.
Implant Type Filter	Filter on Implant Type Attribute returns no data.
Control Mechanism Filter	Filter on Control Mechanism Attribute returns no data
Organization User Profile	Ability for User to Edit and save their Filters, Column Ordering and Sort Orders in a Profile.
Important to Change
Device Relationships	Ability to cross-reference devices that are the same, yet have different UDIs (e.g., same product has a GTIN and a HIBCC code)
Organization Profile	Ability to define and assign default values to all instances of particular attributes
	Ability to customize Device Organization view to Unique Device Identifier Database (attribute display, attribute order)
Attribute Change Control	Function to track changes to attributes and allow manufacturers/administrators (maybe others?) to see the history of an attribute
Could be Changed
Windows User Interface	Ability to size windows including default filter window
Submit a Device to Database via data entry	Ability to preview entire device on one screen prior to submission to the database

Additional Recommendations for Future Phases

We have included here, for FDA, a summary of the major requirements that were deemed out of scope for Phase 3. (Additional information can be found in the Unique Device Identifier Database Phase 2 Requirements documentation.) We recognize that some are still beyond the immediate scope of the UDIS, but further development of the UDI database may need to be kept in sync with these larger efforts.

Streamlined Access for Device Organizations. A Device Organization is the entity that is responsible for entering data into the Unique Device Identifier Database. The Phase 2 requirements state the following:

• The Device Organization needs to be recognized by the FDA.
• The Device Organization must have a current FEI (or DUNS) number registered with the FDA in order to participate in the Unique Device Identifier Database.

Machine-to-Machine Loading of Data into the Unique Device Identifier Database. It was clear from supplier feedback that their ability to comply with uploading data to the UDI database would be affected by the options they would have for data entry. They prefer the process to be as automated as possible.

Recommendation:Developing an automated process for data upload should be a priority enhancement to maximize supplier ability to provide the needed data on a multitude of products presently in their catalogues.

Unique Device Identifier Database feeds to FDA Databases. The ability of the UDI database to feed other relevant FDA databases will maximize the UDIS’ success for ensuring supplier compliance with data provision and will also streamline FDA and supplier efforts. This would also protect data accuracy because suppliers would only need to enter data once in one location.

Recommendation: Also supporting the business value of a single data-feed from a supplier’s information system, FDA should consider the future UDI database development and enhancements and functions that will make this data feed possible, when it is closer to pilot-testing.

Expanded Database Functionality. Additional features that would be desirable for suppliers include:

• Notifications.Users could sign up for email notifications such as Product adds, Item Changes, Change to recall flag, Organization adds, Change in Device Organization.
• User permissions

Recommendation: FDA should consider whether these functionalities will be added.

Data Feed from GDSN. Suppliers who participate in the GDSN data pool could publish to the data pool which would route data to the Unique Device Identifier Database (as shown in the diagram in Appendix 1). The value of this is that the Supplier would have a single place (vs. multiple places) to publish data.

Comment: The importance of this was mentioned by suppliers but this could require lobbying with GDSN to modify some of their data constraints, if indeed that is possible. FDA should examine this issue and decide if it is something that should be pursued.

Global Solution. A set of globally-harmonized attributes that are supported by regulators in other countries would decrease Supplier’s cost to comply and drive adoption. Locally defined User Interface field labels and the ability to capture descriptions and other data as repeating values will allow the Unique Device Identifier Database to adapt to global needs.

Comment:FDA may want to have additional discussions on this subject to determine what would be in FDA’s manageable interests at this time.

Summary

The UDI prototype database development and pilot test was accomplished over a relatively short period of time, and the pilot-test results are derived from a web-based application that has been well examined and used all along the value chain - from data identification, collection, aggregation, loading and verifying data in the database to users accessing, filtering, and exporting the data for various business uses.

All participants in this pilot test – both suppliers and users – are known champions for patient safety and are early adopters and thought leaders in their communities for public safety efforts. Thus, the pilot test benefitted from having motivated participants who truly participated beyond expectations, providing feedback over and above what was expected, and for whom the results of this pilot test are of vital interest. They want to continue to ensure ways to assist FDA and their organizations in improving patient safety.

SSS and GHX have identified the key results and linked these findings to recommendations for the future. We have categorized and prioritized them for FDA consideration as it continues to develop the Unique Device Identification System.

---

¹ These and other relevant documents are on file at FDA and SSS.

² This pilot-test plan document along with a detailed list of all documents (plan, instructions, FAQs, and data collection instruments) developed for the pilot test are on file at FDA and SSS. These documents provide specific information on the implementation schedule, participant selection criteria, and feedback mechanisms and relevant data collection forms and instructions.

³ This may not be the final product or platform for the UDIS.

⁴ The detailed list of 47 attributes (variables) included 11 required and 36 optional attributes. The list, shown in the pilot-test plan document, includes definitions and other details.

⁵ We have used a different font for readers to be able to readily distinguish participant quotes from explanatory and synthesis text.

⁶ The UDI database is a separate and distinct entity from Registration and Listing at FDA although there is future movement towards linking the two.

⁷ Unique Device Manager System

⁸ We have provided FDA with the following Excel file which summarizes the ratings and comments for all 47 attributes, by individual manufacturer: UDI db supplier feedback on all variables 21Sep 09.xls

⁹ Columns: In multiple systems, Relevance to UDI unclear, Need further definition, In FDA system?

¹⁰ There is variance in Brand Name data availability among manufacturers. In some cases, products can have multiple brand names and multiple trademarks, brand name data can be stored in multiple information systems, and/or brand name changes are made in different business processes.

¹¹ This identifies a supplier-education need because a device is either prescribed or available over the counter. States define who can prescribe different devices.

¹² "This information is already reported to the FDA through another mechanism/system. Therefore, we question the information being reported separately in the UDID when the FDA already has the information. This would result in dual entry by suppliers."

¹³ In these and subsequent tables, starred (*) comments are from teleconference feedback sessions.

¹⁴ We note that this is a user education issue as the function exists.

¹⁵ We note that this is a user education issue as the function exists via Column Selection and Ordering.

¹⁶ We note that this is a documentation and configuration issue to be addressed.

¹⁷ We note that functionality to filter on all attributes exists; this comment highlights a user education need.

¹⁸ FDA is moving towards the future where the UDI could be entered on adverse event reports and users would not need to fill out other fields.

¹⁹ To distinguish participant feedback quotes, we have enclosed them in indented text boxes with a different font.

²⁰ Required attributes:

• Organization Identifier
• Unique Device Identifier Type
• Unique Device Identifier Type Code
• Product Number
• Unit of Measure
• FDA Product Code
• US Marketing Authorization Type
• US Marketing Authorization Code
• Device Control Mechanism
• Status
• Unique Device Identifier Description- Abbreviated

²¹ The suppliers in the pilot test were all large multi-national manufacturers.

²² In table 14, these are changes that are critical to the success of the application. Some are fixes to functions that do not work as expected. Others are enhancements that all participants (suppliers and users) suggested to some degree.

²³ Attributes marked with an asterisk (*) are those presently required in the UDI prototype database.

²⁴ This refers to the same device (not a kit) that is, for example, identified with both a HIBCC code and a GTIN. This would be treated as a relationship, but there is no parent.

²⁵ http://www.fda.gov/ForIndustry/DataStandards/StructuredProductLabeling/ucm162523.htm