At some point, all of us are likely to owe our lives–or our quality of life–to a medical device. Yesterday I had the chance to attend the third annual Medical Device Connectivity conference, where manufacturers, doctors, and administrators discussed how to get all these monitors, pumps, and imaging machines to work together for better patient care.
A few days ago I reported on the themes in the conference, and my attendance opened up lots of new insights for me. I’ve been convinced for a long time that the real improvements in our health care system will come, not by adjusting insurance policies, payment systems, or data collection, but by changes right at the point of care. And nothing is closer to the point of care than the sensor attached to your chest or the infusion pump inserted into your vein.
What sorts of innovation can we hope for in medical devices? They include:
- Connectivity
-
Devices already produce (in the form of monitors’ numerical outputs and waveforms) and consume (in the form of infusion pumps’ formularies and settings) data. The next natural step is to send them over networks–hopeful wireless–so they can be viewed remotely. Even better, networking can infuse their data into electronic health records.
One biomedical engineer gestured vigorously as he told me how the collection of device data could be used to answer such questions as “How do some hospitals fare in comparison to others on similar cases?” and “How fast do treatments take effect?” He declared, “I’d like to spend the rest of my life working on this.”
- Cooperation
-
After coaxing devices to share what they know, the industry can work on getting them to signal and control each other. This would remove a major source of error in the system, because the devices would no longer depend on nurses to notice an alert and adjust a pump. “Smart alarms” would combine the results of several sensors to determine more accurately whether something is happening that really requires intervention.
Of course, putting all this intelligence in software calls for iron-clad requirements definitions and heavy testing. Some observers doubt that we can program devices or controllers well enough to handle the complexity of individual patient differences. But here, I think the old complaint, “If we can get men to the moon…” applies. The Apollo program showed that we can create complex systems that work, if enough care and effort are applied. (However, the Challenger explosion shows that we can also fail, when they are not.)
- Smaller and smarter
-
Faster, low-power chips are leading to completely different ways of solving common medical problems. Some recent devices are two orders of magnitude smaller than corresponding devices of the previous generation. This means, among other things, that patients formerly confined to bed can be more ambulatory, which is better for their health. The new devices also tend to be 25% to 30% the cost of older ones.
- Wireless
-
Telemedicine is one of the primary goals of health care reform. Taking care out of clinics and hospitals and letting people care for themselves in their natural environments gives us whole new opportunities for maintaining high-level functioning. But it isn’t good for anybody’s health to trip over cables, so wireless connections of various types are a prerequisite to the wider use of devices.
Ed Cantwell of the West Wireless Health Institute suggested three different tiers of wireless reliability, each appropriate for different devices and functions in a medical institution. The lowest level, consumer-grade, would correspond to the cellular networks we all use now. The next level, enterprise-grade, would have higher capacity and better signal-to-noise ratio. The highest level, medical-grade, would be reserved for life-critical devices and would protect against interference or bandwidth problems by using special frequencies.
- Standards
-
The status of standards and standards bodies in the health care space is complex. Some bodies actually create standards, while others try to provide guidelines (even standards) for using these standards. When you consider that it takes many years just to upgrade from one version of a standard to the next, you can see why the industry is permanently in transition. But these standards do lead to interoperability.
A few of the talks took on a bit of a revival meeting atmosphere–step up and do things the way we tell you! Follow standards, do a risk analysis, get that test plan in place. I think one of the most anticipated standards for device safety, <a href="http://www.iso.org/iso/catalogue_detail.htm?csnumber=44863"ISO/IEC 80001, occupies that category of exhortatory literature. In various ways, I heard the message that following common best practices will essentially conform to such standards and allow one’s device to pass FDA certification.
Communication frameworks
The industry is just in the opening chapter of making devices cooperate, but a key principle seems to be generally accepted: instead of having one device directly contact another, it’s better to have them go through a central supervisor or node. A monitor, for instance, may say, “This patient’s heart rate is falling.” The supervisor would receive this information and check a “scenario” to see whether action should be taken. If so, it tells the pump, “Change the infusion rate as follows.”
Michael Robkin reported about an architecture for an integrated clinical environment (ICE) in a set of safety requirements called ASTM F2761-09. The devices are managed by a network controller, which in turn feeds data back and forth to a supervisor.
I took the term “scenario” from a project by John Hatcliff of Kansas State University, the Medical Device Coordination Framework that seems well suited to the ICE architecture. In addition to providing an API and open-source library for devices to communicate with a supervisor, the project creates a kind of domain-specific language in which clinicians can tell the devices how to react to events.
Communicating devices need regulatory changes too. As I described in my earlier posting, the FDA allows communicating devices only if the exact configuration has been tested by the vendor. Each pair of devices must be proven to work reliably together.
In a world of standards, it should be possible to replace this pair-wise clearance with what Robkin called component-wise clearance. A device would be tested for conformance to a standard protocol, and then would be cleared by the FDA to run with any other device that is also cleared to conform. A volunteer group called the Medical Device Interoperability Safety Working Group has submitted a set of recommendations to the FDA that recommends this change. We know that conformance to written standards does not perfectly guarantee interoperability (have you run into a JavaScript construct that worked differently on different web browsers?), but I suppose this change will not compromise safety because the hospital is always ultimately responsible for testing the configurations of devices it chooses.
The safety working group is also persuading the FDA to take a light hand in regulating consumer devices. Things such as the Fitbit or Zeo that are used for personal fitness should not have to obey the same rigorous regulations as devices used to make diagnostic decisions or deliver treatments.
Open Source
One of the conference organizers is Shahid Shah, a software developer in the medical device space with a strong leaning toward open-source solutions. As in his OSCon presentation, Shah spoke here of the many high-quality components one can get just for the effort of integration and testing. The device manufacturer takes responsibility for the behavior of any third-party software, proprietary or free, that goes into the device. But for at least a decade, devices using free software have been approved by the FDA. Shah also goaded his audience to follow standards wherever possible (such as XMPP for communication), because that will allow third parties to add useful functionality and enhance the marketability of their devices.
Solving old problems in new ways
Tim Gee, program chair, gave an inspiring talk showing several new devices that do their job in radically better ways. Many have incorporated the touch screen interface popularized by the iPhone, and use accelerometers like modern consumer devices to react intelligently to patient movements. For instance, many devices give off false alarms when patients move. The proper interpretation of accelerometers might help suppress these alarms.
In addition to user interface advances and low-power CPUs with more memory and processing power, manufacturers are taking advantage of smaller, better WiFi radios and tools that reduce their time to market. They are also using third party software modules (including open source) and following standards more. Networking allows the device to offload some processing to a PC or network server, thus allowing the device itself to shrink even more in physical size and complexity. Perhaps most welcome to clinicians, manufacturers are adding workflow automation.
Meaningful use and the HITECH act play a role in device advances too. Clinicians are expected to report more and more data, and the easiest way to get and store it is go to the devices where it originates.
Small, pesky problems
One of the biggest barriers to sharing device data is a seemingly trivial question: what patient does the data apply to? The question is actually a major sticking point, because scenarios like the following can happen:
-
A patient moves to a new hospital room. Either her monitor reports a new location, or she gets a new monitor. Manually updating the information to put the new data into the patient’s chart is an error-prone operation.
-
A patient moves out and a device is hooked up to a new patient. This time the staff must be sure to stop reporting data to the old patient’s record and direct it into the new patient’s record.
Several speakers indicated that even the smallest risk of putting data into the wrong person’s record was unacceptable. Hospitals assign IDs to patients, and most monitors report the ID with each data sample, but Luis Melendez of Partners HealthCare says the EHR vendors don’t trust this data (nurses could have entered it incorrectly) so they throw the IDs away and record only the location. Defaults can be changed, but these introduce new problems.
Another one of these frustratingly basic problems is attaching the correct time to data. It seems surprisingly hard to load the correct time on devices and keep them synched to it. I guess medical devices don’t run NTP. They often have timestamps that vary from the correct time by minutes or even months, and EHRs store these without trying to verify them.
Other steps forward
We are only beginning to imagine what we could do with smarter medical devices. For instance, if their output is recorded and run through statistical tests, problem with devices might be revealed earlier in their life cycles. (According to expert Julian Goldman, the FDA and ONC are looking into this.) And I didn’t even hear talk of RFIDs, which could greatly reduce the cost of tracking equipment as well as ensure that each patient is using what she needs. No doubt about it: even if medical device improvements aren’t the actually protagonists of the health care reform drama, they will play a more than supporting role. But few clinical institutions use the capabilities of smart devices yet, and those that do exploit them do so mostly to insert data into patient records. So we’ll probably wait longer than we want for the visions unveiled at this conference to enter our everyday lives.