That’s right, I now recommend that you follow GS1’s Human Readable Interpretation (HRI) specification for drug labeling, even when under a serialization regulation. Previously I recommended against it (see “The DSCSA Product Identifier On Drug Packages”, and “The ANVISA Unique Medicine Identifier (IUM) on Drug Packages”). Why have I changed my mind? GS1 modified their specification to accommodate most of the objections I had over it. Let me explain.
The new specification for HRI is in the latest version of the GS1 General Specifications: version 15. That version of the General Specifications was ratified and published early this year but I only became aware that they had made significant changes to the HRI section last week. The updated HRI specification is contained in section 4.14. But to find the rules that you should follow for healthcare items, find section 4.14.1. Also ignore the document that GS1 published in 2011 to explain HRI, called “GS1 Human Readable Interpretation (HRI), Implementation Guide, Issue 1” because it does not have these new healthcare-specific rules in it. Maybe they will produce “Issue 2” at some point, or better yet, a new version just for healthcare items.
What’s so different about this new version? It appears GS1 recognized that healthcare is highly regulated and things like the human readable text next to a barcode is often specified by regulation. That’s why I previously did not recommend people follow the old rules. As a healthcare manufacturer, you need to meet the regulatory requirements first, and GS1 rules second. When they conflict, GS1 has to lose.
It is easiest to show the difference between the non-healthcare human readable and the healthcare human readable in pictures. I took these images from two different GS1 documents. Here are two products. The one on the left follows the non-healthcare HRI rules and the one on the right follows the new healthcare HRI rules:
There are two important differences between the human readable data next to these codes. Notice how the Application Identifier (AI) is the only way data elements are identified in the non-healthcare item on the left. Now notice how it is done in the healthcare item on the right. All data elements are identified using text that most people will understand, including ‘GTIN’, ‘SN’, ‘Lot’ and ‘EXP’. The AI appears in only two data elements, the serial number (AI=21) and the lot number (AI=10).
According to the new specification, the reason the AI for expiration date (AI=17) does not appear next to the label “EXP” is that the regulation mandated a format for the human readable date that is different from the GS1 date encoding. So the human readable text “20 Nov 2014” is not exactly how the expiration date is encoded within the 2D barcode. In fact, the expiration date encoded in the barcode would have to be in the form “YYMMDD” as it appears in the human readable of the non-healthcare item on the left. When the format of the human readable data presented conforms to a regulation and that format deviates from the format of the actual data encoded in the GS1 barcode, the AI should not appear.
I assume the reason the (01) AI is not shown next to the ‘GTIN’ label of the healthcare item on the right is because they have chosen to show the GTIN-13 in the human readable. The DataMatrix barcode is only capable of encoding a GTIN-14 so since the human readable is not identical to the data encoded, the AI is not shown.
Despite all this, GS1 still recommends that you use ONLY the AIs, even for healthcare items, if you are able. That’s where I differ from GS1. In my view, making the AI the preferred label for human readable text next to a barcode is an archaic approach that should be discarded. It is left over from the day when printer and barcode reader developers and solution vendors did not understand GS1 standards and it was important to depict exactly what was encoded in each barcode, in exactly the same format as the encoding. That way when these people were debugging their equipment and software they could confirm that the data the printer encoded, and the barcode reader decoded was identical to the data in the human readable. That is, the purpose of HRI has historically been as a debugging tool. I think we can move on now.
For healthcare items at least, companies should trust that the printers, the barcode readers and the solution software can properly encode/decode the data. The purpose of the human readable text next to a barcode should be to inform the patient and healthcare professionals about important data like the lot number, expiration date, serial number and drug code of the drug. These people should not be expected to know what (10), (17), (21) and (01) mean. So even where there is no regulatory requirement to format these data elements with meaningful and recognizable words in the local language, I still recommend that companies do so. In my view, patient safety trumps GS1 rules.
What do you think?
4 thoughts on “I’ve Changed My Mind, Follow GS1’s HRI Specification”
It is a no brainer for the patient and for patient interest – my only worry is real estate. It doesn’t look like a whole lot, but some of the products on lines I have worked on, the label is already tough to wedge the previous format into, that extra space will cause additional challenges and artwork changes.
Dirk – thanks for your insightful post. My take is that AIs are for the benefit of scanners/software for parsing multiple data elements into the appropriate fields of the screen / application database. If code is not scannable, it’s not realistic to think a person would/could enter 30+ characters easily/accurately. Instead, they would/should enter each individual data element separately into its respective field which would not require entry of the AI. AIs printed as readable text, while well intended as an AIDC tool, will be a source of confusion for patients, providers, and others handling the product — at least for a while.
Thanks for reviewing the updated HRI specifications and evaluating them on their merits. The work group really tried to balance all of the factors that need to be considered for this issue. It is good to see that you see value in the changes. I hope others will have similar reviews, or will help us refine the design.
Yes, the work group did a great job. I congratulate them on a job well done and I am glad to be able to spread the word about that work through RxTrace. As I pointed out in my essay, my only disappointment was that the GenSpecs still recommend the use of AI’s alone when a regulation does not specify text. Even in those cases, I suspect most drug companies will do the right thing and include both the AIs and human understandable text.
Comments are closed.