Julian Goldman, M.D., attending anesthesiologist at Massachusetts General Hospital and medical director of Partners HealthCare System Biomedical Engineering in Boston, has a vision for the next generation of medical devices working in clinical environments: those devices will interconnect freely with other medical devices and readily integrate with medical systems. The result, he says, will greatly improve patient care and reduce medical accidents.
That vision is a far cry from today’s clinical environments, but the industry has reached a critical threshold for connectivity, says Goldman, who is also director of Medical Device Plug and Play (MD PnP), a group that was formed 10 years ago to promote medical device interoperability. He says technology is moving toward smarter sensors and actuators, but believes the real driver will be connectivity technology, which will open up new categories of devices.
Goldman notes that hospitals are not in the business of building these devices and filing with the FDA (Food and Drug Administration) for approval, but they do have an interest in better data acquisition. At a time when many hospitals are still adopting and expanding their use of electronic health records (EHRs), those efforts are shining a light on the inadequacies of medical device interfaces, he says.
Presently, it’s possible to start a transfusion on a patient knowing that the patient could have a transfusion reaction, but the best it can do is monitor the patient, says Goldman. “We still don’t have a way to stop the infusion pump using additional data,” he says. Stage 3 meaningful use talks about knowing which devices are on the patient, which means that it will be necessary to read the device ID through the network.
Goldman has taken a systems engineering approach to device interoperability, encompassing the acquisition of the data, where it is being transmitted, and existing barriers to its deployment and implementation. Much of his work as focused on focus medical body area networks (MBANs), which are low-power wide area networks that consist of multiple sensors, worn on the body that transmit data to controllers.
The technology has been gaining momentum since the Federal Communications Commission allocated a spectrum for MBANs in May 2012. Among the vendors that have been developing MBAN-based technology are GE Healthcare and Phillips Healthcare, according to Goldman.
Julian Goldman, M.D.
Goldman considers MBAN technology an enabler of miniature smart devices. Localized devices can, for example, provide better bed detection for the patient who gets out of bed and starts wandering. “We will have better sensors that enable patients to get up soon after an injury or surgery, and see if they are ambulating safely. We can do some of those things today; it’s just that those devices are more cumbersome and more limited,” he says.”
Mainstream devices such as activity sensors connect to platforms—smartphones or laptop computers—that have been designed from the ground up to accept them. That can serve as a model for their clinical counterparts, which don’t yet exist but are under development, he says.
Goldman says that progress has been made in laying the foundation for an ecosystem for interoperable medical products. The FDA has issued mobile medical application regulatory guidance, which he sees as a pathway to implement medical applications on standard off-the-shelf computing hardware. He notes that there is a demand among hospitals to drive open interfaces as a means for them to swap equipment.
He adds: “We are starting to see some convergence, and we are no longer hear large companies say, ‘our hospitals, our customers, don’t want this.’ Two years ago, that’s what I heard. That’s progress.”
Vendors Advance Toward Smart Devices
Tim Gee, principal at Medical Device Connectivity, Beaverton, Ore., says there a strong market demand for workflow automation and integration of medical devices. He defines a smart device as one that knows the patient it is associated with, and is able, in the device itself, to handle some of the basic workflow functions.
According to Gee, the next big milestone in Stage 3 meaningful use from a connectivity standpoint in interoperability of infusion pumps. “One of the problems of a drug error reduction system is supposed to solve is that you misconfigure the pump because you are doing it manually,” he says. Yet automating complex workflows has proven to be very difficult.
Tim Gee
Historically, third-party vendors have been quicker to respond to market demands than traditional medical device manufacturers, many of which view connectivity and workflow beyond the direct use of their products to be outside their comfort zone Gee says. Yet medical device manufacturers that have done so have distinguished themselves and helped transform their segment of the market. One example is Alaris, a brand of San Diego-based CareFusion Corp., which developed the first drug-error reduction system for infusion pumps.
Other areas where Gee has observed a lot of development activity include alarm notification systems, devices that monitor for routine tasks performed at the bedside, and ventilator systems. He notes that major ventilator companies are introducing new products this year and next year, and he suspects that those products will have more connectivity on them.
Is Technology Outpacing Patient Safety?
Mac McMillan, co-chair of the HIMSS Policy and Security Policy Task Force and CEO of Austin, Texas-based CynergisTek, Inc., is concerned that technology has leapt ahead of the controls that need to be in place to what they do in a safe manner. This is especially a problem with medical devices that interconnect or support a patient’s health directly, he says. Medical devices weren’t networked or able to be remotely controlled until 2006, and by 2014, 98 percent of the devices can be networked or communicated with, he says.
McMillan says there is a large number of devices were never designed to communicate within a network, but are doing it now. “They are not engineered securely and often are not implemented securely,” he says. He sees two basic issues: one is the integrity of the device itself and the platform it runs on; and the other is the communication link between the device and the middleware or the device and the back end. There are no regulations that say the medical device operating system has to be supportable or upgradable, he says.
The problem has engulfed three groups, which McMillan says have yet to arrive at a consensus on how to address the issue: provider organizations, device manufacturers and the FDA.
McMillan sees three possibilities to fix the problem. First, manufacturers decide on their own to establish standards for building devices that are compliant with privacy and security requirements. Second, hospitals influence the market with their buying decisions. Third, and most likely in McMillan’s view, the FDA, which has the authority to implement a rule, does so.
So far, the agency has been reluctant to do that, but that may be changing, McMillan says. Last year the FDA issued two sets of guidance: One concerned things that should be considered in pre-market development and post-market implementation of the device. The other lists things to consider from a radio-frequency perspective. Both are guidelines only, not enforceable as law.
“The bottom line is that the FDA could take that guidance and turn them into rules, and the medical device vendors would no choice but to follow them,” McMillan says, which he believes is a possibility. “If we all know it’s a problem that we can’t agree to do something about, if the providers aren’t capable and the vendors aren’t willing, Uncle Sam, that’s when you get involved,” he says.
