Speaking of Barcodes: Part 3 of 3 (the future)

In this somewhat long Part 3, we will be very far afield of GS1 labeling in healthcare. What we’ll be talking about is just now becoming visible on the barcode horizon. (Contrary to the media predictions, the future of the barcode is not RFID tagged labels. We’ll be examining a barcode future that has orders of magnitude more capacity than any RFID and the same basic cost structure as today’s barcode.)

Before we gaze out, however, I think it’s important that we note that when it comes to automating the management of patient data, everyone assumes “healthcare automation = computers wired end-to-end.” That’s a bias we have, a feature of the observer, and it is not inherent to the observed problem of intelligent, informed, efficacious healthcare delivery at the patient bedside. Computers, like GS1 labeling standards, like RFID, like web services, heck, even a patient’s clipboard, are simply enabling technologies.

The long-term future of barcodes — after the up-coming adoption of global GS1 labeling and the steady increase in the use of the 2D barcode – is the newly invented, but evolving rapidly, color barcode or so-called “3D” barcode (color being the “3rd dimension”). And what a stunning difference color makes . . .

All of the first color barcodes coming out, most just this year, are proprietary. As a result, few of these, if any, will be widely adopted, except by the company that invented them. Like previous generations of the barcode, it is not until a barcode symbology is released by the inventing company, free of licensing and out into the wilds, that it flourishes (editor note: is the barcode the original open source code?). Unlike any barcode generation that has come before, however, these early generation color barcodes can encode and represent what I would call stunning amounts of information.

On the very low end of the color barcode innovation scale, you have a patented, licensable Microsoft symbology called  the “high capacity color barcode” or HCCB.  It can store about 3,500 characters — numbers and letters — per square inch. 3KB is not quite what I  would call “high capacity” but, hey, Microsoft throwing its hat into the ring probably lends big business legitimacy to color barcodes.

Now onto the colorized CL barcodes (warning: link to PDF download) which can reportedly hold up to a very respectable 73KB of data in a square barcode. That’s probably enough storage for a patient’s H&P and relevant data. It is certainly enough storage to capture something contextually and medically meaningful.

The truly impressive ones, however, are ones such as the brand new PM Code. PM Code stands for Paper Memory. All of these radically great symbologies are coming right now from the folks at just one place: Content Idea of Asia Co., Ltd. How radical? According to this write-up, the Normal PM Code with data memory capability uses 8-24 colors. Memory ranges from about 0.6MB~1.8MB (4,083,264 figures).

The big dog of barcode storage, however, is the IP-Based PM Code that uses 256 colors. Memory ranges up to about 1,236GB (2,854,408,421,376 figures).

Yes, that’s over 1.2 gigs of representative storage capacity . . . in . . . a . . . barcode.

Please, feel free to reread the previous sentence.

This is only the beginning, folks. When innovative minds start applying themselves to the problem, just like with 2D barcodes, which evolved and improved, we will see some amazingly capacious sybmologies. There’s no telling where this can lead.

Okay, here we are today already with this powerful new symbology. Let’s stop for a moment and think about the 256 PM Code barcode storing over a gig. What could we try doing with that in healthcare? Let’s be just plain geeky about it and consider the possibilities.

Well, you could try storing a patient’s longitudinal care record in there.

You could try putting in a DICOM representation for a diagnostic quality x-ray.

You could try storing an entire maternal-fetal strip (or, heck, how about a wards-worth of them).

You could easily do things like store a dashboard snapshot of the entire floor of patients and maladies and treatments for use by physicians prior to patient rounds. You could even iterate it for workflow states with timestamps.

You could do lots of things but one thing you can’t do now, I hope, after this, is to say “the barcode” doesn’t have a bright and interesting future in healthcare.

You just have to know your barcodes.

3 Responses

  1. I’m having a hard time reconciling those capacity claims with the figures on the CIA website. They have a “normal PM Code” which looks like a colorful QR code. I estimated about 500 individual pixels of data, subtracting the square patterns etc. If we have 500 pixels and multiply that by 24 colors, we get 12,000 bits that can be encoded. If we used UTF-8, estimate that we have to divide by 8 to get bytes (which they call figures, I assume they mean Kanji or other character). That puts it at 1,500 character, which is a lot, but nowhere near the 4 MILLION in the caption.

    The “IP-based PM Code” uses 256 colors. I estimated over 2,500 pixels, so we’ll use 2,500. Multiply that by the number of bits per pixel (2500×256) = 640,000 bits or about 80,000 eight-bit characters. That’s also assuming no error correction. which would reduce these figures.

    That’s about 78K of data. How they pull a TERABYTE from aht is beyond me, unless the IP component is a URL that will suck a gig of data from the internet.

    Using colors instead of black and white might make sense for some applications, but I fail to see how the printing process could reliably reproduce those colors for scanning by a cell phone. How would printing registration affect this? Lots of questions about the real-world applicability and capacity of these codes.

    Color me skeptical. (<– joke!)

    Darryl Zurn

  2. Here’s the PDF I read that I tried to analyze above:

    http://ci-a.co.jp/pm/pm_eng_01.pdf

    Even if the code is equivalent to layering 24 same-size QR codes atop each other, it’s still orders of magnitude lower. There’s just not enough bits of data that I can see that corresponds to these claims.

    A regular 57×57 QR code can encode a maximum of 650+ numbers or 167 Kanji. Multiply that by 24 and you only get 15,600 numbers or 4,000 Kanji. A lot, but not enough for the claims.

    Darryl

  3. For a really quick, well-written summary of this 3 part series — our most popular posts in this blog by far, ever — check out the point of care forum:

    http://pointofcareforum.com/toolbox/ive_been_thinking_about_old_glory_cuba_rfid_chips_and_bar_codes_entering_the_third_dimension

Leave a Reply