EXECUTIVE SUMMARY:
Both provider organizations and medical device vendors have made significant, if slow-going, progress over the last several years to network their digitally-enabled medical devices. Recent strides in both the regulatory and standards arenas have provided renewed impetus on the part of both stakeholder groups to bring more interoperability to disparate medical devices, resulting in better security and quality of patient data.
As healthcare providers continue their steady march toward implementing electronic health records as envisioned in the Health Information Technology for Economic and Clinical Health (HITECH) Act, leading hospital systems are confronting head-on the challenge of integrating the disparate medical devices operating within their walls into EHR data flow. And while tying together those medical devices into a truly seamless network is still beyond reach, stakeholders in the effort can point to some victories that are bringing their goal just a bit closer to reality.
A good deal of the push for device interoperability has come from proponents in provider organizations. And, while medical device interoperability has not yet been explicitly mandated under meaningful use, it has been recommended to the Office of the National Coordinator for Health IT (ONC) for inclusion in Stage 3. In the view of more than one expert interviewed for this article, medical device interoperability is not just about moving data around a network; it means making sure that the health data maintains its integrity, and that it is delivered to the right place securely.
As noted by Jason Joseph, director of technology and information solutions at Spectrum Health, Grand Rapids, Mich., interoperability presupposes the comprehensibility of data, in a standard format. “I can get the data out of most machines and plug it into somewhere else, but does it mean the same thing across the board?” he asks.
A PATIENT SAFETY ISSUE
One of the early advocates of medical device interoperability has been Julian M. Goldman, M.D., medical director of biomedical engineering for the Partners HealthCare system and an anesthesiologist at Massachusetts General Hospital in Boston. In 2004, he founded the Medical Device Plug and Play (MD PnP) Interoperability Program to encourage the adoption of open standards and technology to integrate medical devices.
I CAN GET THE DATA OUT OF MOST MACHINES AND PLUG IT INTO SOMEWHERE ELSE, BUT DOES IT MEAN THE SAME THING ACROSS THE BOARD?-JASON JOSEPH
Goldman says that interoperability is only a means to an end, which is effective and lower cost system integration. Working with clinicians and clinical engineers, his group identified clinical scenarios in which system integration could improve quality of care. One example: patient injuries and deaths that occur when x-rays are taken of patients on a ventilator. “There are cases where people have died because people turn off the ventilator to take an x-ray and forget to turn it back on,” he says. The clincher, he says, is that more than 10 years ago, a research group in Florida demonstrated that if you can interconnect the ventilator with the x-ray machine, they can be synchronized automatically, eliminating the need to turn the ventilator off in the first place.
The team used that example to elucidate potential interface solutions; for example, that the ventilator has a network connection that lets it be paused for 10 seconds and restart automatically. “If you have the right interoperable components that have the right features, when they are assembled into smarter networks for patient care, they will improve safety,” Goldman says. He calls for an “ecosystem” of interoperable medical products that will enable the development of applications that take advantage of the capabilities of medical devices to improve patient safety and quality of care. To that end, Goldman has participated in the creation of an ASTM standard (F2761), “Integrated Clinical Environments,” which creates a common framework in which devices can safely operate to enable decision support at the point of care.
Goldman has seen positive signs that his message is receiving some recognition. In October 2010, the MD PnP program received a $10 million Quantum grant over five years from the NIH/National Institute of Biomedical Imaging and Bioengineering to develop a “prototype healthcare intranet for improved health outcomes.” The grant is an affiliate of the ONC Strategic Health IT Advanced Research Projects (SHARP) program. In his view, the Quantum grant is a sign of the rising awareness of medical device interoperability issues. One of the current tasks under the Quantum funding is to develop a compendium of medical device interface requirements.
CHANGING THE EMBEDDED MINDSET
Tim Gee, principal at Medical Connectivity Consulting, Beaverton, Ore., observes that medical devices historically have been embedded systems-standalone black boxes that were not connected. That has been changing, Gee says, as some device makers have been migrating to the general-purpose IT world with devices that have built-in connectivity.
Making the change from manufacturing standalone devices to networked devices has presented challenges to medical device makers, Gee says. “It affects not just how they design their products, but their entire business delivery system, from regulatory issues to purchasing to manufacturing, installation, service and support, and even how they sell their products,” he emphasizes. He says he has seen a renewed commitment on the part of medical device manufacturers to better understand provider requirements for integrated systems, and to develop products that meet those requirements.
Gee notes that progress is being made on device interoperability, pointing to PACS and clinical laboratory systems as examples. “Those areas have industry standards, and they are almost plug-and-play-although not quite,” he says. That's not the case when it comes to point-of-care systems, which are highly variable. “It's a much more challenging environment from a workflow standpoint,” he says. Coordinating the activities of various departments, such as nursing, IT, and biomedical engineering, is a governance challenge for many hospitals today, he adds.
AS DEVICES ARE BECOMING INCREASINGLY NETWORK-ENABLED AND NETWORKED, WE ARE INCREASING THE RISKS AROUND SECURITY AND SAFETY.-DALE NORDENBERG, M.D.
Dale Nordenberg, M.D., is a founder of the Medical Device Innovation, Safety and Security Consortium, which he describes as a provider-driven group that is focused on mitigating security and safety risks associated with connected medical devices. As medical devices have become increasingly digitally enabled, computerized, and networked, there is a lack of clarity over whether these devices should be treated as medical devices, as computers-or as both, he says. Consequently, the group or person responsible for purchasing, implementing or operating the device, often has shared, or even unclear, lines of responsibility within the provider organization, he says.
IF YOU ARE CONNECTING MEDICAL DEVICES TO AN IT NETWORK, YOU ARE RESPONSIBLE FOR THE SAFETY, EFFICACY, AND SECURITY OF THAT ENVIRONMENT.-YADIN DAVID
In his view, most healthcare organizations have not matured to the point where they can seamlessly manage medical devices across the different departments such as biomedical engineering and IT, he says. “As devices are becoming increasingly network-enabled and networked, we are increasing the risks around security and safety,” he says.
Those issues are compounded by the fact that as regulated devices under the U.S. Food and Drug Administration (FDA), “there is a good deal of concern about modifying the hardware and software associated with a digitally enabled, network-enabled medical device,” he adds. In his view, this is especially a problem with multigenerational medical devices that are running on older operating systems. “An administrative computer is more likely to be patched in a timely manner than a regulated medical device, because there is anxiety over changing its function by updating its operating system,” he says. That area of concern is being addressed by manufacturers, providers, and regulators, he says.
SHARED RESPONSIBILITY SEEN
The question of who bears responsibility for modifying FDA-approved devices in a provider environment has been addressed in the last few months by industry standards and, on the regulatory side, by the FDA.
Rick Hampton, corporate manager for wireless communications at Partners HealthCare, uses the example of wireless cardiac telemetry systems to illustrate a point about shared responsibility. As a standalone system, the device manufacturer took full responsibility that every device it sold was safe and effective, as defined by the FDA. “They were required to verify that the system worked and validate that it worked as it was designed. They owned all of that responsibility,” he says. But when that same device is put on the hospital network, the scope of responsibility should expand to encompass everyone involved.
Last September saw the ratification of a new standard by the International Electrotechnical Commission, IEC 80001, “Application of Risk Management for IT Networks Incorporating Medical Devices,” which is focused on exactly that question. “It basically says that the person who put the system together to connect the medical device to the IT network is the responsible organization,” says Hampton, who worked on the standard. In his example, the provider must work as a team with the device vendor and the networking vendor to make sure that all of the components that comprise the system they are putting together are sufficient to support the medical device so it can continue to be safe and effective.
“The biggest driver in healthcare is informatics, and the fact that we are going to computerize everything,” Hampton says. “And the fundamental question is, if we automate everything, is it still safe and effective?” Hampton asks.
Yadin David is principal at Biomedical Engineering Consultants LLC and prior to that was director of the Biomedical Engineering Department at Texas Children's Hospital, both of which are in Houston; as well as a senior member of the Institute of Electrical and Electronics Engineers. He has co-authored a handbook on the new standard. He calls IEC 80001 a “major breakthrough in trying to clarify the question of who is responsible and why we need to look at the question of responsibility.” He says the standard is the first one to look at medical device risk management issues from a systems perspective.
It says to the healthcare provider, “if you are connecting medical devices to an IT network, you are responsible for the safety, efficacy, and security of that environment,” he says. In addition, it recommends that the provider gets collaborative agreements with the vendors, and understand the risks involved and how to mitigate them, he adds.
On the regulatory side, the FDA in February announced a final rule that classifies certain off-the-shelf or custom hardware and software products used with medical devices as Medical Device Data Systems (MDDS), or class 1 low-risk devices, making them exempt from premarket review, but still subject to quality standards. MDDS products are used alone or in combination to display unaltered medical device data, or transfer, store or convert medical device data for future use in according to a preset specification. Examples include systems that store data from a blood pressure cuff for future use or that transfer thermometer readings to be displayed at a nursing station for future use.
By re-classifying these products as low-risk, the rule says manufacturers must register with the FDA, list their MDDS devices, report adverse events and comply with the FDA's Quality Systems regulation. The rule also levels the playing field for medical device manufacturers, so that IT companies that design, install, or market these systems, as well as the hospitals that develop them in their facilities, are also considered “manufacturers” and must follow the class 1 requirements as well.
So, for example, if a hospital CIO directs his team to create a new software product, or modify someone else's device to function as an MDDS, the hospital is considered an MDDS manufacturer, Hampton explains. In the past the assumption was that “it was just data and we know how to move it around. Now hospitals are being asked to prove that they can move data safely, that the data arrives intact, and that is hasn't been corrupted. And when it absolutely has to get there, it does,” he says.
A HOME-GROWN MDDS
One example of an MDDS-registered device is the Vital Signs Capture (VSC) application, which was developed by Partners HealthCare. Nat Sims, M.D., physician advisor, biomedical engineering, at Massachusetts General Hospital, who heads the team that developed the device, says the VSC is part of an approach called Workflow Aware Connectivity, which he says allows individual sources and recipients of data to communicate at the bedside without the need for expensive IT infrastructure.
The VSC is designed to allow a medical assistant to capture vital signs from various patient devices onto a mobile device, and then send these data directly to the correct cell of the electronic health record. The data is time-stamped and bound to the patient's identity and the caregiver's identity, Sims explains. The caregiver scans a barcode on the vital signs monitor with a handheld computer, which tells a data integration engine that it should communicate with a specific monitor in a specific way. A communication channel is opened. The caregiver scans the barcode on the patient. The vital signs that are captured flow directly into the handheld device and into the EHR.
Partners has conducted more than 200,000 such medical device captures over a two-year period at its Boston-based Brigham and Women's Hospital and Massachusetts General Hospital organizations, and it plans to continue implementing the device, says Sims.
He, for one, welcomes the opportunity to register the device as an MDDS. He sees it as a “thoughtful way for the FDA to have a little bit of regulatory jurisdiction inside the healthcare organization, and to make thoughtful comments about how we are supposed to do things.”
Healthcare Informatics 2011 July;28(7):14-20