From Information Silo to Bridge, Part 2: Creating a UDI System


Laura Bix, Robb Clarke

November 1, 2007

21 Min Read
From Information Silo to Bridge, Part 2: Creating a UDI System

Device packages can be tracked using either bar codes or radio-frequency identification. (Photo by Roni Ramos. Products courtesy of Beacon Converters, Becton Dickinson, KCI, and Kendall.)

As discussed in Part 1 of this article (published in October 2007), FDA is looking to break down the silo mentality that plagues the medical device industry supply chain. However, creating a system that stimulates the flow of standardized information between the partners so that all parties can easily, quickly, and effectively have access to information that is accurate, relevant, and timely is no easy task.

A unique device identification (UDI) system is likely to be implemented for many devices in the near future. It would be similar to what is required of drug manufacturers in the form of bar coded national drug code (NDC) numbers. It is likely that when FDA implements UDI, it will exceed NDC requirements by mandating data such as lot and serial numbers. This article discusses required data, data management systems, and data carriers that can help create an effective UDI system for devices.

Creating a UDI System

Considering the complexities involved, it is doubtful that a one-size-fits-all solution will work. A more likely scenario is one in which devices that are directly linked to patient safety would have more-rigorous requirements for information and would have a more-aggressive time frame for implementation.

Regardless of what a device is or how it is used (and possibly reused), there are issues involving both data and data carriers. The following questions must be considered:

  • What will the required data be for this type of device?

  • What data carrier is most efficient in this situation?

Additionally, FDA will need to make critical decisions regarding the infrastructure of the system that will interface with the data carrier. This infrastructure will be responsible for managing data and informing the players that are in need of information.

An auto-ID technology can be used to gain system benefits that surpass manual operations.1 To harness these benefits, the system requires developmental procedures to ensure all trading partners gain value. Chief among these procedures are standardization, interoperability, and serialization.2

The decision to implement UDI technology requires a look at the cost of implementation as well as the projected benefits that such implementation would entail. Specific industry sectors should also be considered, because the costs and benefits would vary for manufacturers, distributors, and storage modes, as well as in-use applications.3

Experts Weigh In on Data Management

At present, no one knows what FDA will mandate as a minimum data requirement for different devices. The agency has not weighed in on how the information will be managed. However, the information shared with CDRH during its October 2006 meeting provides insights into what other departments and agencies that are grappling with similar issues have recommended and opposed.4

Figure 1. (click to enlarge) National healthcare product data utility. Adapted from Garvin, 2006.

A joint study produced by the Department of Defense (DOD) and the Department of Veterans' Affairs (VA) suggests a vision of an information management system suited for use with UDI. The joint project serves as a proof-of-principle pilot study regarding the creation of a product data utility (PDU) for healthcare products (see Figure 1).

Kathleen Garvin, program manager for the DOD's Medical Data Synchronization project, defines a PDU system as “a system that interconnects trading partners across the supply chain to synchronize core product data to standard specifications and distribute standardized product data from manufacturers and distributors to data aggregators and end-users . . . [it] enables participants to synchronize and maintain accurate product and packaging information in near real time.”4

To further the analogy, PDU is the bridge that counteracts silo-style thinking. Garvin goes on to explain that the use of the word utility is purposeful, as it is indicative of “an active process that needs to occur to ensure that everyone's data are the same.” She does not use the term repository for data, because it implies a passive database that merely holds the information. Figure 1 is an adapted graphical representation of how PDU would serve a UDI system. Note that the DOD model does not include the flow of information to payers or fiscal intermediaries that play a role in commercial systems. Information flow to these parties must be required in the development of a UDI system.

The PDU system is controlled and owned by a neutral, nonprofit governing body. This body promotes data standardization for industry and provides security for the information. Its purpose is to reduce data distribution and maintenance costs, thereby improving efficiencies for all players. Garvin emphasizes that the minimum data requirements, or key data, for healthcare products must be decided. Key data can vary for differing products and for the stakeholders involved. She says that the project's technical advisory group received hundreds of “needed fields” during an industry poll. However, similar data are apparent across categories, and these similarities point to the minimum data set to be held in the PDU system. Other data are likely to differ by device type.

Jonathan Sherman of the Defense Medical Logistics Standard Support Program Office has developed and fielded an auto-ID system that is used at 168 DOD sites. Sherman is also a supporter of PDU, saying that it provides “the ability to automatically populate our catalog records, our property records, and our maintenance records, with accurate, clean, and current data.”4

Randy Levin, MD, director for health and regulatory data standards at the Center for Drug Evaluation and Research (CDER), corroborates the importance of PDU, based on CDER's experiences with the NDC. Levin says that

[o]nce you define the rules, you need to have a central authority that will help people follow the rules. We did have rules in our past regulations, but the manufacturers were generating the codes. And some were following the rules or have interpreted the rules in various ways. So there are a lot of inconsistencies on [sic] how people were defining what the drug product was . . . The identifier was not robust because of this lack of a central authority who could reinforce all the rules that you define.4

As a result, CDER has issued a proposed rule that suggests that FDA become the central authority for assigning the NDC.5 Clearly, the center's experiences with the NDC have provided it with hindsight (and foresight) that favors a system analogous to the PDU described by DOD's Garvin.

Data Carriers

An isolated PDU system would be suboptimal; the real benefits cannot be achieved until the standardized, synchronized information is available to, and from, the varying parties of the supply chain. As such, it is likely that PDU will interface with one or more auto-ID systems in order to maximize its potential. Auto-ID is the broad term given to a host of technologies that are used to help machines identify objects or persons.6 The most likely technologies to be incorporated into the UDI system are bar codes and radiofrequency identification (RFID).

Bar Codes

Bar codes are graphic presentations of data that are machine readable. Encoded data, or data standards, may be numeric, alphanumeric, or use the full ASCII character set. A 2004 AdvaMed survey indicates that there is significant use of two standards among medical device manufacturers: UCC/EAN (now GS1) and Health Industry Business Communications Council (HIBCC).7 Both standards support “a primary data structure (manufacturer name, product name, and packaging level), as well as a method of encoding additional information, such as lot batch serial number and expiration date.”6 As such, both are likely to be considered in the development of the UDI.

GS1 versus HIBCC. The debate of GS1 versus HIBCC is a path well traveled. When the drug bar coding rule was proposed March 14, 2003, it dictated the use of a “linear bar code that met UCC/EAN [now GS1] standards.” Proponents of the use of the GS1 codes pointed to their widespread use with drug products, affordability, and well defined structures.8 However, successfully submitted comments encouraged FDA to allow the use of HIBCC standards as well as UCC/EAN. Comments included the prevalence of health industry bar code (HIBC) in healthcare and the fact that a single standards organization would become a monopoly. The American National Standards Institute (ANSI) has recognized the standards of both organizations in its MH10 document, which has also been endorsed by the International Organization for Standardization (ISO). It is likely that one or both of these organizations will be present in the final rule on UDI.

HIBC is an alphanumeric string of characters. A primary HIBC is comprised of the following:

  • A “+” is a reserved character to identify an HIBC Supplier Labeling Standard format.

  • A four-character company prefix, referred to as the labeler identification code, assigned to member companies by HIBCC.

  • A 1–13-character product identifier that is assigned by the member itself.

  • A one-character unit of measure that indicates the packaging level.

  • A one-character check digit.9

Table I. (click to enlarge) Structuring format of varying GTINs from GS1. Source: Kreysa, 2006.

The global trade identification number (GTIN) is the data standard used by GS1. It represents a globally unique number that is up to 14 numbers long, although several data structures can be used (see Table I). A GTIN is composed of the following:

  • A GS1 company prefix assigned by the local GS1 member organization to the registration owner.

  • A sequential code (the item reference) given by the registration owner.

  • A check digit.10

In Table I, zero represents a filler digit, and N represents the position of the individual digits in a given data structure.

Table II. (click to enlarge) Notable application identifiers (AIs) that are used in healthcare. Adapted from Kreysa, 2006.

Concatenation is a process that allows more than one code to be read in a single, linear string, regardless of the data standard being employed (GS1 or HIBCC). To concatenate, an application identifier (AI) is employed when using the GS1 standard, and a data identifier (DI) is used in the HIBCC standard. These characters “identify the meaning and format of the data field that follows.”10Table II provides a list of healthcare-relevant AIs, and Table III lists healthcare-relevant DIs. Commonly strung information for the healthcare industry might include concatenation of the manufacturer's name, product identifier, batch or lot number, serial number, and expiration date (see Figure 2 for a concatenated GS1 128 code). Where space allows, concatenation is a fairly simple way to provide extended information.

Figure 2. (click to enlarge) GS1 data standard in varying symbologies (both with and without concatenation) for healthcare products. Data matrix codes have significantly less space requirements for identical data. Bar codes are included for illustration purposes only.

Which Symbologies? Three bar code symbology forms (see Figures 2, 3, 4) typically serve to encode the data. These data include linear codes (e.g., code 128, DataBar, and code 39), two-dimensional codes (e.g., data matrix and PDF417), and composite codes (e.g., stacked reduced space symbology (RSS) codes and DataBar stacked OmniDirectional Code, which is a combination of codes). Most symbologies can be used to encode data from either standards organization.

Table III. (click to enlarge) Notable data identifiers (DIs) that are used in healthcare. Source: HIBCC, November 5, 2006.

Although CDER required a linear, or one-dimensional, bar code for encoding the NDC in 2004, it is likely that two-dimensional or composite codes will play a role in the UDI system because they can encode more information in smaller spaces. Such codes are well suited for small devices and packages that require direct encoding. The industry is already beginning to respond to the need for tracking the processing of small devices that are repeatedly decontaminated and sterilized. The RSS codes are either etched into or marked on the surface of the device so that the processing history and patient interactions can be tracked.

Radio-Frequency Identification

Another auto-ID technology that will likely serve a data carrier function for at least some devices in the UDI system is RFID. RFID is an automatic data collection technology that uses radio-frequency waves to transfer data between a reader and a movable item to identify, categorize, locate, track, and trace. RFID is fast, fairly reliable, and, unlike bar codes, may not require a physical line of sight or contact between the reader and the tagged item. Data management for a passive, read-only RFID system works very much like that for bar codes. The automatically collected information in or on the tag is pulled together to form a database.

There is little prescriptive guidance on how to effectively implement and use this technology even though there is clear pressure and incentive to adopt RFID. History demonstrates that new technologies go through a dynamic period of development, fallout, and improvement. It is likely that the use of RFID in the medical device supply chain will follow a similar pattern, given that the following two assumptions are met:

  • That costs decrease substantially.

  • That the technology and read rates for tags prove to be reliable.11

RFID, as an auto-ID technology, is a carrier of information and other functionality. However, its use may be cost- prohibitive for many items. Its use will, at least in the foreseeable future, require visual backup. It may require human-readable linear bar codes, or repeated information such as 2-D bar codes encoding unique object identifiers.2

Comparing Bar Codes and RFID. From a healthcare provider perspective, RFID and bar code technologies can be used for many of the same applications, but they may serve different roles in those applications. For example, bar code labels applied at the unit-of-use level may be more cost-effective than applying RFID tags because bar code labels are currently less than 1 cent per label, based on quantity purchased. Basic passive RFID tags (the type of tag commonly used for this purpose) cost about 13 cents each.12,13

The ability of bar codes and RFID tags to withstand various environmental conditions differs. Reportedly, RFID tags are less susceptible to damage from exposure to ice, snow, and dirt than bar codes.13 However, with RFID, there may be problems related to sterilization, as certain sterilization methods (gamma radiation) may cause damage to RFID tags. In addition, RFID technology may be susceptible to interference from metals or liquids that can affect the accuracy and reliability of RFID if the application is not well planned.11,12 Although ongoing research and work continues to overcome these factors, one must remember that not all global supply-chain partners will be able to implement the newest and, likely, more expensive, system.

Figure 3. (click to enlarge) HIBC examples of code 39 and code 128. Bar codes are included for illustration purposes only.

Figure 4. (click to enlarge) Stacked code and matrix code examples.

Operating Frequencies. Probably the number one concern in considering RFID for a PDU system is that of frequency. The two main operating systems in healthcare are high frequency (HF) at 13.56 MHz and ultrahigh frequency (UHF) at 915 MHz. These two frequencies work on different physical principles. HF works on inductive coupling, whereas UHF works on passive backscatter. The former operates in the near-field zone, while the latter works in the far-field zone. This is relevant because near-field applications are not subject to interference as a result of metal or moisture in the read field, while far-field applications can experience interference. Far-field systems, however, do have a significant advantage in read-field length when no signal disruption is present.

Until recently, choosing the optimal system meant compromising between case of reading (to use 13.56 MHz) and having an extended read length (using 915 MHz). Now, the concept of having a single UHF tag work in both the near field and the far field is being researched. System development is progressing, but there are not many systems available yet.

Because RFID can work without a line of sight, the possible applications for medical devices are numerous. However, due to technical and legal issues in hospitals, RFID is still behind projected applications in placement, use, and success. Although several hospitals use RFID systems, many of them are using 13.56 MHz or 2.4 GHz as the frequency of choice.2

FDA and RFID. The following issues have been noted as areas that need addressing before RFID can move forward in the healthcare and device market.14

Standardization. In order for any auto-ID technology to work on a global, or even a national, scale, the information has to be organized and stored in some standard data format. Regardless of whether the auto-ID technology is bar code or RFID based, data formatting must be standardized for a system to operate flawlessly.

Electronic Pedigrees. An electronic pedigree is very important to keep accurate records, but it is also vital to protect against counterfeiting and theft. FDA considers electronic pedigrees to be a type of electronic safety net.15 In a public meeting held October 25, 2006, the following item was noted in the meeting minutes.

Asked to make the case for a medical device pedigree, FDA pointed to better use-error reporting and enforcement, to equipment calibration and maintenance, and to more-accurate assessment of the scope of device associated infections.16

Once again, understanding how pedigree has developed for pharmaceuticals enables OEMs to predict (and avoid) pitfalls for devices. State and federal laws have been enacted to address the increasing threat to public health posed by, among other issues, counterfeit drugs.17 In the United States, FDA implemented e-pedigree pilot programs in 2004. It did not mandate the program, but advised the pharmaceutical industry to adopt this practice. To date, the practice has not yet been widely adopted. The delay is the result of up-front costs, concerns over consumer privacy, the lack of harmonized standards, and confusion over state versus federal law.18

With respect to GS1, the EPCglobal Healthcare and Life Sciences (HLS) Industry Action Group has begun work to define the requirements to develop a full track-and-trace system based on the EPC Information Services standard, which is expected in the first quarter of 2007. A track-and-trace approach enables pedigree information to be shared upstream or downstream, as opposed to simply passing it in a unidirectional fashion. Track-and-trace has significant value for protecting the integrity of the supply chain and is seen as a universal approach that can be applied globally and across multiple industries.19

Tracking and tracing are actually two separate processes, although many discussions indicate that people assume they are identical. Tracking examines where a device is destined and focuses on movement down the supply chain. Tracing examines where a device has been up to that point in time, or focuses on locations further up the supply chain.

The concept of tracking involves controlling the shipping and receiving process for medical devices, as well as managing assets and inventories within healthcare facilities.2 Tracing for the healthcare industry relates to building a history—in reality an audit trail—of manufacturing, shipping, and receiving of medical devices and supplies, as well as the use of those devices and supplies in patient care.6 This principle is the basis for interest in electronic tracking via e-pedigrees. Tracking and tracing of objects using a unique identification carrier, such as a bar code or an RFID tag, may be the best method available for medical devices.


Clearly, a one-size-fits-all approach to UDI will not work throughout the medical device industry. It is likely that minimum data requirements will vary for different devices. A device that fails and significantly affects patient safety should have a greater minimum data requirement (i.e., serialization) than less critical devices. However, based on a review of the collected comments regarding a UDI system and on feedback from CDER regarding the path that it has traveled, it is quite likely that minimum data requirements will go beyond the bar coded NDC by including information to the lot-code level. Along the same vein, it is unlikely that the system will mandate a single data carrier type or single symbology. Given the intricacies of the multitude of products of this industry, a multitiered approach is likely.

Other questions remain such as those regarding how to manage the data collected by the data carriers. Will CDRH employ a path similar to the one taken by CDER in implementing the bar code regulation, allowing the manufacturers to number their products? Or will the center take a different approach and use a centralized database, a PDU system?

The answers will likely shape the data standards that are included in the final rule. For bar coding requirements, the decision was made to allow either HIBCC or GS1 codes, but CDER also employed a system for the NDC that enables manufacturers to assign numbers for their products. Does it make sense to have a central database employing two data standards for bar codes? If FDA employs a centralized database paradigm, how will it assign the governing body: a newly created entity, an established standards organization, the government itself, or some other model?

Stay tuned: the answers to all of these questions will shape the system and likely have significant effect on your business practices.


The substance, recommendations, and views set forth in this presentation are not intended as specific advice or direction to medical device manufacturers and packagers, but rather are for discussion purposes only. Medical device manufacturers and packagers should address any questions to their own packaging experts and have an independent obligation to ascertain and ensure their own compliance with all applicable laws, regulations, industry standards and requirements, as well as their own internal requirements.


The authors would like to thank Ulrike Kreysa and the GS1 organization for providing funding to examine the many issues associated with global data standards for healthcare, and for providing the GS1 bar codes that were used in the creation of many of the graphics presented here. The authors also wish to acknowledge the contributions of Jay Crowley, senior adviser at CDRH, and Ed Dzwill, manager of packaging technology at J&J, for their review of an early version of this document.

Full Disclosure

The authors have been working on a funded project with the GS1 organization to investigate the business case for global standardization for healthcare products.

Laura Bix is an assistant professor at Michigan State University 's School of Packaging . She can be contacted at [email protected]. Robb Clarke is an associate professor at Michigan State University . He can be contacted at [email protected].


1. “Bar Code Technology” [online] (Warrendale, PA: Association for Automatic Identification and Mobility [cited 20 August 2007]): available from Internet:

2. Laura Bix et al., “Global Data Standards in the Healthcare Supply Chain: The Business Case” (Brussels: GS1 Healthcare Users' Group, 2007).

3. “Adopting EPC in Healthcare: Cost & Benefits” (Reston, VA: Healthcare Distribution Management Association (HDMA) Healthcare Foundation, 2004.

4. Kathleen Garvin et al., “The Development, Maintenance, and Use of a Repository” from transcripts of Center for Devices and Radiological Health Public Meeting on Unique Device Identification [online] 25 October 2006 [cited 20 August 2007]; available from Internet:

5. Federal Register, 71 FR:51296, August 29, 2006.

6. “Automatic Identification of Medical Devices: Final Version,” white paper prepared for the Food and Drug Administration [online] 17 August 2005 [cited 20 August 2007]; available from Internet:

7. AdvaMed, “Automatic Identification in the Medical Device Supply Chain: A Survey Report” [online] 2004 [cited 20 August, 2007]; available from Internet:

8. Federal Register, 69 FR:9120, February 26, 2004.

9. Health Industry Business Communications Council, “Response to Request for Comments on the Benefits and Feasibility of Implementing a Unique Device Identification System (UDI) for Medical Devices” [online] 5 November 2006 [cited 20 August 2007]; available from Internet:

10. Ulrike Kreysa, “Bar Coding of Medical Devices,” Journal of Medical Device Regulation [online] February 2006 [cited 8 October 2007]; available from Internet:

11. R Clarke et al., “RFID in the Supply Chain: Separating Fact from Fiction,” Supply Chain Strategy, a newsletter from Harvard Business School Publishing (February 2006): 9–10.

12. “Radiofrequency Identification Devices,” Health Devices 34, no. 5 (May 2005): 149–159.

13. Robert Clarke and Jonathan Falls, “Methods and Apparatus for RFID Hotspot Testing,” Journal of Applied Packaging Research 1, no. 2 (2006): 55–90.

14. Paul Rudolph (former senior adviser for medical and healthcare policy at FDA), personal correspondence with Robert Clarke, June 2004.

15. “Radiofrequency Identification Technology: Protecting the Drug Supply,” FDA Consumer 39, no. 2, (March–April 2005).

16. FDA Public Meeting on Unique Device Identification [online] 25 October 2006 [cited 19 August, 2007]; available from Internet: DOCKETS/06n0292/06n-0292-mm00001-Summary.pdf.

17. “RFID and UHF: A Prescription for RFID Success in the Pharmaceutical Industry” [online; cited 19 September 2007]; available from Internet:

18. Ronald E Quirk, “RFID: Deployment Continues Amid Regulatory Challenges” [online] Venable, 19 March 2007 [cited 19 September 2007]); available from Internet: C2E986F%7D&VNETCOOKIE=NO.

19. GS1, “EPCglobal Inc. Ratifies Electronic Pedigree Standard: Provides Platform for Compliance for Pedigree Laws Requiring a Document-Based Approach” [online] 11 January 2007 [cited 18 August 2007]; available from Internet:

Copyright ©2007 Medical Device & Diagnostic Industry

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

You May Also Like