There are many mistakes one can make with the Unique Device Identification (UDI) barcode, but there is one that we see more often than others in the lab at Barcode Test. The simple rule that is violated is clearly stated on Page 219 of the GS1 General Specification (Release 19, Ratified, Jan 2019). It is Rule 3, which states:

“Parentheses SHALL surround AI’s in HRI but are not encoded in the GS1 AIDC data carrier.”

Rule 3 is part of the problem

This clear statement is, of course, part of the problem. Normal people may not know what an AI or an HRI are or what an AIDC data carrier is. Posting it on Page 219 does not help either. Here is the translation:

Prefixes that identify the various types of data in the UDI barcode are enclosed in parentheses. For example, the 01 prefix that starts the barcode must appear as (01) in the string of numbers below the barcode. However, the parentheses are never programmed into the barcode—they are only used in the readable string of numbers below the barcode. All of the prefixes—expiration date, lot number, etc–are treated this same way.

The “…GS1 AIDC data carrier….” referred to in Rule 3 is just the barcode. Simple.

Visually, a correctly encoded barcode looks virtually identical to one where the parentheses have been mistakenly encoded.

You cannot see the problem by just looking at it.

That is another part of the problem and frankly a big one. You do not even know there is a problem until somebody scans the barcode—and even then the specific error is neither obvious nor reported. The barcode simply fails. The mistake was made in printing or label designer—and the barcode looked fine. That is why verification at the point of printing is so important. Only then can you detect and rectify a mistake before it escapes into the supply chain, before it becomes a liability.

Here are a few additional pitfalls to avoid with UDI barcodes.

There is no specified sequence or order for the various data segments with the AI (Application Identifier) prefixes. Some people will tell you that “best practices” dictate they must go in numerical order. That is incorrect. It makes logical sense to group the data segments with fixed lengths at the beginning of the barcode. The variable length data segments should be grouped toward the end of the barcode. Why?

Because fixed length data segments like GTIN and expiration date have a fixed, predictable number of digits, the scanner can easily detect when one data field ends and another begins. Remember, the parentheses are not encoded, and if they were, it would take up a lot of additional space, making the barcode longer than necessary.

Variable length data fields need some way of indicating the field is beginning and ending. A field separator accomplishes that. This rule applies to all variable length data field except the final one in the data string. In that case, the STOP pattern of bars and spaces signals the end of the barcode and, thus, the variable data.

In actual practice, fixed length and variable length data fields may be sequenced at will—it is specifically allowed in the General Specification (Section 3.1 on page 134). For efficiency sake, it is better to keep fixed length segments variable length segments separated. Using potentially fewer field separators makes the barcode physically shorter–that could be important if it is a linear barcode that must fit into a designated space.

The GS1 General Specification is a massive compendium of rules designed to guide and standardize barcode structure. Standards are what make the system work at a global scale. But they can be overwhelming when your actual business is making, not marking medical devices. We can help you avoid UDI mistakes.