RSS versus Datamatrix
In response to so many things I have read recently, I am quite dismayed by the misinformation that is being spread regarding Reduced Space Symbology (RSS) versus Datamatrix. I have not decided yet whether this is deliberate misinformation or simple ignorance. I realize that sounds harsh, but the simple reality of alliances between certain organizations and individuals shows that neither sound technical reasoning or installed technology in the pharmaceutical industry is being considered.
Equally troubling is the fact that many drug professionals who have confided in me their preference for Datamatrix are unwilling to submit their position as a group to FDA and the Centers for Disease Control. They fear being perceived as in collusion with one another and have been advised by their legal teams not to work together on this issue.
Several companies have made public commitments to RSS. While these commitments are laudable, their solution is not the best one for all or even most companies. RSS is a very good code, but it is technically inferior to Datamatrix in almost every way.
I previously helped develop a number of current labeling standards and performed the actual testing while working for one of the top 10 pharmaceutical companies for six years, in cooperation with the Pharmaceutical Research and Manufacturers of America. And over the last 11 years, my company has provided many machine vision and bar code solutions to the industry. We were the first company to provide Datamatrix solutions for in-line printing and on-line reading. We have installed Datamatrix systems in this industry since 1994 and probably have the largest installed based of any systems integration company.
Regardless of the symbology FDA chooses for its bar coding rule, we will have solutions to install. Quite frankly, RSS will generate the most business for my firm, both with manufacturers and end-users. But I still believe that RSS is inferior to Datamatrix.
At this point, Datamatrix has many advantages over RSS, but RSS proponents are ignoring them. If high-speed, in-line printing incorporating expiry and lot information is needed (small vials coded at speeds of about 300–450 per minute), there are numerous ways to accomplish this using Datamatrix, and none to accomplish it using RSS with a single printer at the requisite line speeds.
If the National Drug Code (NDC), an expiry date, and a lot number are needed, the most space-efficient RSS code still requires almost three times the space of a Datamatrix code containing the same data. Many small package labels have neither the area nor the label height available for RSS.
If one considers the issues of in-line print quality verification, the capabilities many pharmaceutical customers have with already-installed vision and printing systems allow them to implement the codes almost immediately using Datamatrix at little or no cost.
Datamatrix, Code 128, and RSS codes should all be acceptable. End-users, who have less than a 1% installed base, should buy devices capable of reading all these symbologies. The tail should not wag the dog.
There has been substantial misinformation spread about the installed reader base capable of reading RSS/composite versus Datamatrix. Some argue that existing single-line laser scanners can be modified to read RSS linear codes. (Few end-users could accomplish this task.) Further, some ignore the fact that if expiry dates and lot codes are also encoded as proposed, the existing base of linear readers will be obsolete, since they will not be able to read the composite codes necessary for variable data. And if only the NDC is needed, why move beyond Code 128 and incur any expense at all, since new readers wouldn't be needed and codes could be preprinted?
Due to the development of CMOS imagers using SOC (system on chip) technology, the cost of imagers by this time next year will plunge to about $200. The use of this imager-based technology allows end-users to read all linear symbologies as well as the two-dimensional versions of RSS and Datamatrix. Some of these readers may permit optical character recognition, and current image-capture capabilities could make doctors more accountable when their signatures are captured, eliminating many existing medication dispensing errors at their true source.
This fiasco reminds me of the mid-1980s, when at several meetings, I was one of the people pushing for the adoption of Code 128 and was shouted down by those in favor of Code 39, an inefficient code that should have been replaced.
Shouldn't the Uniform Code Council act as an objective standards organization? Shouldn't it consider the advantages of other symbologies, like Datamatrix? There is no data structure in RSS that cannot be used in Datamatrix and no ASCII character that cannot be encoded in Datamatrix.
Since lives are at stake when errors occur, we should accomplish automatic product identification as quickly as possible, at the most reasonable cost, on as many package forms as possible, and with as much meaningful information. Why not do it now, using the best that each symbology and reading and printing technology will permit? Pushing RSS as the sole solution ensures that we will never reach that goal.
Be flexible and be wise when choosing standards and technologies. Otherwise, we will be revisiting this issue again 10 years from now with even more lives lost. Product identification can be accomplished at minimal cost if done properly, and it can benefit everyone from the manufacturer to the end-user.