Bar Code vs. RFID Smack Down
Health Data Management has an article on the use of bar codes and RFID for patient identification, meds admin, blood transfusions, collecting lab specimens, etc. Passive RFID performs better than bar codes – easier to read – but the significant price differential between even 2D bar codes and passive RFID tags will stymie RFID adoption for now.
At
this point in the race, RFID's superior functionality-no line of sight
required-is often being trumped by the convenience and lower cost of
bar code systems, experts say.
Passive RFID tags often cost $1 or more each, and the handheld
readers are more expensive than comparable handheld bar code readers.
Bar codes also are already affixed by manufacturers and suppliers to items such as medications and blood bags.
Patient tracking is mentioned as an application for passive RFID. Sure, you could use passive RFID tags with readers positioned at strategic choke-points, like the entrance to labor and delivery. Such a deployment would only be good for things like infant abduction and patient elopement. Passive RFID cannot provide true tracking (as defined in this post).
The issues that have plagued bar codes still exist, but good planning and execution can greatly minimize problems. Use two-dimensional bar codes, and make sure they're oriented for maximum readability. The use of permanent ink in bar code printers, and quality materials on which the bar codes are printed also improve readability. Expect to replace bar codes, especially on patients with a greater than average length of stay.
Some hospitals confuse patient identification workflows (around the applications mentioned above) and active RFID. And then there's this canard:
vendor's Real Time Location System uses tags that emit RF signals that
can be tracked by Wi-Fi networks. A big selling point for the system
was that the hospital didn't have to install RF antennas but could use
its existing Wi-Fi network, also from Symbol.
Regular readers of this blog know better. Pictured right is an Aztec 2D barcode.
UPDATE: HIT veteran Charles Fox adds some pithy observations on RFID versus barcode in the comments below, including this:
two closely positioned patients to be confused. This situation occurs frequently
in venues such as PACU and ED.”
New Verstion of OQO Pocketable Windows Computer
The anticipated new model of the OQO computer, dubbed the 02 in a recent FCC filing appears to be moving closer to release. December 5th, 2006, both Gizmodo and Engadget had posts on the FCC filing. Gizmodo has since taken down their post (you can see the page cached on Google here, scroll down about half way).
In the FCC filing, the OQO 02 “passed on the 5GHz band (which would imply 802.11a), as well as on two
frequencies in 2.4GHz, implying 802.11b/g and Bluetooth –
unfortunately, nothing there listed for cellular frequencies
(which mean that might be left to a Model 02+ or some such thing). Oh,
and the unit will be 3.5 x 5×5-inches (although thickness is still
unknown — compare to the current OQO at 3.4 x 4.9 x 0.9-inches).”
When I talked with my OQO contact, they would not comment on the record about the 02.
Based on the current 01+ version and what we can say about the next version, OQO has embraced a truism that still escapes most medical device vendors – that portable devices must have wireless connectivity to be useful and easy to use. Support for 802.11a/b/g and Bluetooth are minimum requirements. And you can bet that the slightly larger physical size will sport even more wireless connectivity features that the current FCC filings show.
Pictured right is a diagram from the FCC filing. What's your wish list of features for the next OQO? You can see mine in the comments below.
UPDATE: I forgot to mention that at the RSNA I saw the Sony UX ultra mobile PC in the Sony booth. Sony shows their video recording and printing products at RSNA and included the UX as one of a number of consumer electronics with health care potential. The Sony rep said they couldn't keep up with demand for the UX from their OEMs who are allegedly evaluating the unit for resale.
Compared to the OQO the UX is larger, has a smaller screen, and a lousy keyboard (the keys are all flush and hard to type on).
Medical Connectivity: Plug and Pray?
24×7 Magazine published a story of mine on connectivity. Variously described as “automating workflow” and “deciphering medical device connectivity,” the story approaches the topic from a provider’s viewpoint. After a bit of history and description of immediate and longer term reasons to connect (EMR integration and point of care workflow automation), we dive right into the part about “plug and pray.”
Connectivity is really easy if you’re willing to buy all new devices, and buy some new IT infrastructure to boot. Oh, and you have to be willing to replace most or all of it every time you change vendors (or even product lines from the same vendor). Oops, almost forgot, none of the different categories of devices will work together – and forget about any cross vendor compatibility. If this sounds unappealing to you, you’re not alone.
The story addresses legacy devices, proprietary end-to-end systems and some interesting third party connectivity solutions on the market. And you can’t talk about connectivity without mentioning standards:
Medical device connectivity requires a connection between the device and the target information systems. Legacy devices use a serial connection to a terminal server that converts the RS-232 signal to a network connection. Both wired and wireless local-area networks are used to connect devices to information systems. Older device-connectivity systems run on “private†networks that are physically or logically separate from the wider hospital network. The resulting proliferation of these “islands of information†is giving way to integrating devices into the hospital network. Because health care is inherently mobile, with patients moving throughout their stay and highly mobile caregivers, wireless networks offer the most flexible and least obtrusive network connection.
With the exception of diagnostic imaging modalities and some clinical lab equipment, the data that comes out of medical devices is in a proprietary format. Devices with end-to-end connectivity systems aggregate data from devices at a server, which converts the data into a standard—typically Health Level Seven (HL7) or SOAP/XML—and passes it on to another system. Devices that have only an RS-232 output must convert the serial interface to a network connection, where the data from multiple devices is aggregated in a server, which also converts the data into a standard for use by other systems.
Efforts of the Integrating the Healthcare Enterprise patient care device workgroup, standards bodies like the Institute of Electrical and Electronics Engineers Inc 1073 workgroup, and HL7 are working to improve the plug-and-play capabilities of medical devices. Goldman’s MD PnP group is also driving connectivity with use case development and a new verification lab. But it will probably be years before medical devices like those mentioned above achieve the ease of connectivity currently enjoyed in radiology with digital imaging and communications in medicine.
The real question is not about standards but what a provider can do to navigate this confusing mess.
How one finds their way through this bewildering sea of competing choices is a challenge. The interrelated nature of the devices, users, and workflows means that any one connectivity choice will inevitably impact subsequent decisions down the line. “With many connectivity projects you don’t find all the hidden costs until after the project is complete,†says Craig Bakuzonis, director of clinical engineering, Shands Hospital (Gainesville, Fla). “Detailed planning and experience have been our best project-management tools.â€
Perhaps the most important part of connectivity planning and execution is needs assessment. Unlike many projects in health care, connectivity crosses multiple organizational silos in a hospital and must sync up multiple moving targets. These moving targets are changes that occur in care delivery methods, medical device upgrade and purchase plans, and information technology (IT). Any resulting solution must fit today’s environments and support future changes planned across overlapping areas. Even seemingly unrelated projects are interrelated—will nurses want to carry a PDA for spot vital signs capture and another PDA for the Baxter “smart†pump system budgeted for next year? Probably not. Can we run both applications on the same PDA? Good question; probably not.
Good planning for connectivity incorporates requirements from nursing, biomedical engineering, and IT into a series of road maps. Each road map starts with current requirements and captures planned clinical and operational changes into the future. A good time
horizon would be one that equals the operating life your hospital expects from a new medical device. Each milestone on the road map needs an associated project description and list of requirements. If no one in your hospital can plan out as far as the estimated useful life of your medical devices, make sure constraints posed by keeping those devices are understood by all parties.
This is a rapidly evolving area with few established best practices. The classic business term is discontinuity, which certainly applies here. As providers seek to integrate medical devices with information systems, and medical device vendors and HIT vendors eye one another’s markets for future growth, the tradition of adopting vendor’s end-to-end solutions is getting more expensive and delivering less value. Much like the early PACS market, the “DICOMification” of medical devices – the breakdown between the actual device and associated analysis software on general purpose computers – requires buyers to chart their own course.
As medical device connectivity has evolved, administrative applications are giving way to those impacting patient care and safety. Systems have evolved from data gathering and export to alarm management. According to Goldman, the next big connectivity application will entail medical device interoperability. “In the future, connectivity will include medical device control that permits the
integration of distributed medical devices to produce ‘error-resistant’ systems with safety interlocks between devices,†Goldman says. This error resistance will decrease user errors and provide closed-loop systems to regulate the delivery of medications and fluids, improving patient safety and outcomes.
Special thanks to the following folks to provided their time and experience for this story:
Craig Bakuzonis, director of clinical engineering,
Shands Hospital (Gainesville, Fla)Troy Gillette,
director clinical engineering and patient equipment, Robert Wood Johnson
University Hospital (Brunswick, NJ)
Julian Goldman, MD, program leader of the Medical Device Plug-and-Play
(MD PnP) interoperability program, departments of anesthesia and biomedical
engineering at Massachusetts General Hospital (Boston)
Bridget Moorman, clinical systems engineer, biomedical engineering, Kaiser
Permanente (Berkeley, Calif)
Elizabeth Wykpisz, vice president,
Washington Heart and Vascular (Washington, DC)
Eric Yablonka, VP, CIO, University of Chicago Hospitals and
Health System (Chicago)
Leveraging Existing Wireless Networks for Location Tracking
Fellow connectologist, Dave Hoglund, has written an interesting white paper on the physics behind indoor positioning systems (IPS). Before your eyes roll up into your head, you shouldn't miss this opportunity to really understand the reasons behind why different real time location systems (RTLS) work better for some applications than others. As I've said before, there is no “best” RFID system.
As with many new technologies, there is a lot of loose usage of terms that vendors employ to describe their system's capabilities. The following excerpt describes the difference between “tracking” and “locating.” This may seem like splitting hairs, but as you will see, difference in system capabilities is significant. (Emphasis in the original.)
If your end goal is simple asset tracking, then a locating system is sufficient. But if you hope to create what IPS vendor Radianse calls “context sensitive medicine” you must have true tracking capabilities (among other things). One of the biggest mistakes I see with RFID (and wireless LANs) is the selection, design and deployment of technology that only meets the immediate need. As a buyer, if you want to leverage an infrastructure investment over multiple applications, you must assess your needs and develop requirements for each of those applications at the beginning. Otherwise you end up re-selecting, re-designing, and re-deploying the same (or different) technology as you address each application in turn. Also note that it is not necessarily a good thing to put everything on the same infrastructure – whether it's a positioning system or a wireless network – when that infrastructure fails everything on it fails too.
The common WLAN re-work scenario starts with wireless (but static) data communications deployed with a rudimentary site survey and throwing access points (APs) up about every 100 meters. When you add a wireless medical device, say an infusion pump that moves with ambulating patients, another site survey and network re-design is required to fill in coverage gaps and ensure successful roaming across APs and subnets. When wireless voice over IP (VoIP) is adopted the process is repeated again, with a new set of requirements around latency, jitter and quality of service. Finally, adding life critical alarms to your WLAN introduces yet another set of requirements and re-work. If you add an RTLS to this WLAN nightmare scenario you re-work the network 5 times – a considerable hidden cost to leverage a common infrastructure.
Like most new technologies, digging down to the really important requirements are self evident after you've deployed an application the first time. The key is how much re-work (and the associated costs) will be required to get it right the first time. Hoglund goes on to describe some of the important requirements for more advanced positioning applications. (Again, emphasis in the original.)
While this paper was written for Parco Wireless, it is educational in nature. If you want to know the reasons behind tag battery life, positioning accuracy and repeatability, why different systems have different costs and more, be sure to read this white paper.
Pictured right is Parco's ultra wideband tag, which is about the size of a quarter.
