Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

Where Medical Devices Fall Short: Can More Testing Help? (Part 2 of 2)

Posted on April 6, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

As we saw in the previous article, networks of medical devices suffer from many problems intrinsic to the use of wireless technology. But testimony at the joint workshop held by the FCC and FDA on March 31 revealed that problems with the devices themselves run deep. One speaker reported uncovering departures from the standards for transmitting information, which led to incompatibilities and failures. Another speaker found repeated violations of security standards. As a trivial example, many still use the insecure and long-deprecated WEP authentication instead of WPA.

Most devices incorporate generic radio transmitters from third parties, just as refrigerators use replaceable compressors and lawnmowers depend on engines from just a few manufacturers. When markets become commoditized in this way, one would expect reliability. Whatever problems radio transmitters may have, though, are compounded by the software layered on top. Each device needs unique software that can affect the transmissions.

The WiFi Alliance is a consortium of manufacturers that tests devices for reliability and interoperability. But because it doesn’t contain users or government representatives, some panelists thought it was too lenient toward manufacturers. The test plan itself is a trade secret (although it was described at a high level in the workshop by Mick Conley). Several speakers testified that devices could be certified by the Alliance and still perhaps fail to connect.

To my mind, testing is a weak response to design problems. It happens after the fact, and can punish a poor engineering process but not fix it. You can test-drive a car and note that the steering is a bit sluggish, but can you identify the software or the part that is causing the problem? And can you explain it to the salesman, presumably to be conveyed back to the engineers?

Cars tend to be reliable first because of widespread competition that extends internationally, and partly because lawsuits keep the managers of the automobile companies alert to engineering problems. It would be a shame to need lawsuits to correct technical problems with medical devices, but refusing to buy them might do the trick. Test beds do provide warnings that can aid purchase decisions.

Unfortunately, the forum produced no real progress on the leading question of the day, whether a national test bed would be a good idea. It was recognized generally that test beds have to reflect the particular conditions at different institutions, and that multiple test beds would be needed to cover a useful range of settings. Without further clarification of what a test bed would look like, or who would build it, a couple panelists called for the creation of national test beds. More usefully, in my opinion, one speaker suggested a public repository of tests, which are currently the proprietary sects of vendors or academic researchers.

So none of the questions about test beds received answers at the workshop, and no practical recommendations emerged. One would expect that gathering the leading experts in medical devices for seven and a half hours would allow them to come up with actionable next steps or at least a framework for proceeding, but much of the workshop was given over to rhetoric about the importance of medical devices, the need for them to interoperate, and other standard rallying cries of health care reform. I sometimes felt that I was in hearing a pitch for impressionable financial backers. And of course, there was always time taken up by vendors, providers, and regulators trying to point the finger at someone else for the problems.

Device and networking expert David Höglund has written up how the workshop fell short. I would like someone to add up all the doctors, all the senior engineers, all the leading policy makers in the room, calculate how much they are paid per minute, and add up the money wasted every time a speaker extols patient engagement, interoperability, or some other thesis that is already well known to everybody in the room. (Or perhaps they aren’t well-known–another challenge to the medical field.)

Personally, I would write off most of the day as a drain on the US economy. But I have tried to synthesize the points we need to look at going forward, so that I hope you feel the time you devoted to reading the article was well-spent.

Where Medical Devices Fall Short: Can More Testing Help? (Part 1 of 2)

Posted on April 3, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

Clinically, medical devices do amazing things–they monitor vital signs (which, as the term indicates, can have life-or-death implications), deliver care, and measure health in the form of fitness devices. But technologically, medical devices fall way short–particularly in areas of interference, interoperability, and security.

The weaknesses of devices, their networks, and the settings where they reside came up over and over again in a joint workshop held by the FCC and FDA on March 31. I had a chance to hear most of it via live broadcast, a modern miracle of networking in itself.

Officially, the topic of the gathering was test beds for medical devices. Test beds are physical centers set up to mimic real-life environments in which devices are used, hosting large numbers of devices from different manufacturers running the popular software and protocols that they would employ out in the field. The workshop may have been an outgrowth of a 2012 report from an FCC mHealth Task Force which recommended “FCC should encourage and lend its expertise for the creation and implementation of wireless test beds.” (Goal 4.4, page 13) I thought the workshop had little new to offer on test beds, however, as the panelists concentrated on gaps between clinical needs and the current crop of devices and networks.

Medical settings are notoriously difficult places to employ technology. One panelist even referred to them as “hostile environments,” which I think is going a bit far. After all, other industries employ devices outdoors where temperatures drop below zero or rise precariously, or underwater, or even on battlefields (which actually are also medical settings).

I don’t dispute that medical networks present their own particular challenges. Hospitals crowd many devices into small spaces (one picture displayed at the workshop showed 15 wireless devices in a hospital room). Some last for decades, churning away while networks, environments, and requirements change around them. Walls and equipment may contain lead, blocking signals. Meanwhile, patient safety requires correct operation, resilience, and iron-clad security. Meanwhile, patients and their families expect access to a WiFi networks just like they get in the cafe down the street.

And yet Shawn Jackman, Director of Strategic Planning at Kaiser Permanente IT, said that problems are usually not in the infrastructure but in the devices. Let’s look at the main issue, interference (on which the panelists spent much more time than interoperability or security) and then at the ideas emerging from the workshop.

All the devices we associate with everyday network use (the IEEE 802.11 devices called WiFi) are all squeezed into two bands of the radio spectrum at 2.4 Gigahertz and 5 Gigahertz. When the inventors of WiFi told the world’s regulators that they had a new technology requiring a bandwidth in which to operate, freeing up existing bandwidth was hard to do, and the inventors were mere engineers, not powerful institutions such as the military or television broadcasters. So they resigned themselves to the use of the 2.4 and 5 Gigahertz bands, which were known as “junk spectrum” because all sorts of other equipment were allowed to emit radio-frequency noise in those bands.

Thus, because the bands are relatively narrow and are crowded with all sorts of radio emissions, interference is hard to avoid. But you don’t want to enter a patient’s room and find her comatose while a key monitor was unable to send out its signal.

Ironically, at the request of health IT companies, the FCC set aside two sets of spectrum for medical use, the Medical Device Radiocommunications Service (MedRadio) established in 1999 and the Wireless Medical Telemetry Service (WMTS) established in 2002. But these are almost completely ignored.

According to Shahid Shah, a medical device and software development expert, technologies that are dedicated to narrow markets such as health are crippled from the outset. They can’t benefit from the economies of scale enjoyed by mass market technologies, so they tend to be expensive, poorly designed, and locked in to their vendors. Just witness the market for electronic health records. So the medical profession found devices designed for the medical bands unsatisfactory and turned to devices that used the WiFi spectrum.

In 2010, by the way, the FCC relaxed its rules and permitted new devices to enter the little-used spectrum at the edges of television channels, known as white spaces, but commercial exploitation of the new spectrum is still in its infancy.

Furthermore, the FCC has freed up the enormous bandwidth used for decades to broadcast TV networks, by kicking off the stubborn users (known with respect as the “last grandmas”) who didn’t want to pay more for cable. An enormous stretch of deliciously long-range spectrum is theoretically available for public use–but the FCC won’t release it that way. Instead, they will sell it to other large corporations.

Networks are unreliable across the field. How often do you notice the wireless Internet go down at a conference? (It happened to me at a conference I attended the next day after the FCC/FDA workshop. At one conference, somebody even stole the hubs!) Further problems include network equipment of different ages that use slightly different protocols, which prove particularly troublesome when devices have to change location. (Think of wheeling a patient down the hall.) And you can’t just make sure everything is working the first time a device is deployed. Changes in the environment and surrounding equipment can lead to a communications failure that never turned up before, or that turned up and you thought you had fixed.

Medical device and wireless expert David Höglund claims that WLAN can work in a healthcare environment for medical devices. He lays out three overarching tasks that administrators must do for success:

  • They have to understand how each application works and its communications patterns: real-time delivery of small packets, batch delivery of large volumes of data, etc.

  • They have to provide the coverage required for each device or application. Is it used in the hallways, the patient rooms, the labs? How about the elevators on which patients are transported?

  • They need to obey the application’s quality service requirements. For instance, how long is a failure tolerable? For a device monitoring a patient’s heart in the ICU, a five-second interruption may be too long.

Medical devices and hospital networks need to be more robust and more secure than the average WiFi network. This calls for redundant equipment, separate networks for different purposes, and lots of testing. Hence the need for test beds, which many hospitals and conglomerates set up for themselves. Should the FCC create a national test bed? We’ll look at that in the next installment of this article.

The Future of Health Involves Human-Agent Collectives (Part 1 of 2)

Posted on February 2, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

Everyone understands that isolated interventions in the doctor’s office will not solve the chronic health conditions that plague developed nations and inflate health care costs. So as the health field shyly tries on new collaborative styles–including coordinated care, patient-centered medical homes, and accountable care organizations–participants are learning that the supporting technologies must also enable collaboration in ways vastly more sophisticated than current EHRs and devices.
Read more..

Integrating Medical Device Data With EMRs Likely To Be Slow

Posted on April 6, 2011 I Written By

Katherine Rourke is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

While most healthcare organizations have their hands full integrating their various clinical databases, that leaves another set of problems untouched.  As things stand, EMR implementation efforts don’t generally involve connections to key medical devices.

Medical connectivity consultant Tim Gee sums it up nicely in a recent blog entry:

Medical device manufacturers in markets that have managed to resist creating connectivity solutions are facing increased pressure from providers adopting EMRs. I mean, what’s the use of automating the EMR if users have to write down numbers read from medical device displays and then manually type them into the EMR? That’s certainly not “automation.”

Gee then goes into a discussion underscoring just how big a challenge it will be for device manufacturers to close this gap. Broadly speaking, he says, devicemakers have to meet three criteria:

  • Be able to export data in a digital form.
  • Work with a centralized computer or server that aggregates data from your medical devices.
  • Offer HL7 interface that takes your device data, in your proprietary protocol, converts it to HL7 and sends it on to the EMR.

While these criteria may not sound too intimidating, there’s actually many, many unresolved issues as to how these solutions will play out for the medical device industry, he notes.  Device vendors will either have to do a great deal of custom work to meet standards or invest heavily in outsourced development.

Why do I bring all of this up?  Well, from the looks of Gee’s analysis, I’m guessing it will be quite some time before medical device makers universally offer plug-and-play data feeds into EMRs.

Though they may be under great pressure to integrate, devicemakers aren’t going to be able to do it overnight, particularly given that the EMR market itself continues to evolve rapidly.

While this isn’t great news, we might as well be realistic.  For the time being, I’d plan for manual data export from devices and hope for the best.