Medical Device Interoperability: A ‘Wicked Problem’ of Our Time
January/February 2013
Medical Device Interoperability: A ‘Wicked Problem’ of Our Time
A conversation with Julian M. Goldman, MD
| |
 |
| Courtesy of David Arney |
Julian M. Goldman, MD, is medical director of biomedical engineering for Partners HealthCare System, a practicing anesthesiologist in the Massachusetts General Hospital and director of the Program on Medical Device Interoperability at MGH and CIMIT (Center for Integration of Medicine and Innovative Technology). He founded the Medical Device “Plug-and-Play” (MD PnP) Interoperability Program in 2004 to enable innovation in patient safety and clinical care by leading the adoption of patient-centric medical device integration.
Goldman completed anesthesiology residency and fellowship training at the University of Colorado. His research fellowship was in medical device informatics, focusing on simulation and artificial intelligence applications for monitoring and real-time decision support.
Goldman has served on advisory committees for the National Science Foundation and Center for Disease Control and Prevention and as a visiting scholar in the FDA Medical Device Fellowship Program. He is the primary investigator of a $10 million NIH/NIBIB grant to develop a medical device interoperability platform for hosting clinical apps. He holds leadership positions in medical device standards and interoperability organizations such as ISO, ASTM, IEC, and the Continua Health Alliance. Goldman is the recipient of the International Council on Systems Engineering Pioneer Award, American College of Clinical Engineering (ACCE) award for Professional Achievement in Technology, and the AAMI Foundation/Institute for Technology in Health Care Clinical Application Award.
PSQH Editor Susan Carr recently talked with Dr. Goldman about his work at MD PnP and the current state of interoperability.
Carr: Recently—especially with the acceleration of electronic health record implementation—I’ve heard lots of talk about interoperability, but that word seems to mean different things to different people. Is there agreement about what interoperability is and why it’s important?
Goldman: It is gratifying that many people are talking about interoperability, but reaching a common understanding of the definition of, and the implications of interoperability for healthcare for different stakeholders continues to be difficult. I will have the opportunity to explore some of these complexities in my HIMSS presentation, “Medical Device Interoperability: The ‘Wicked HIT Problem’ of Our Generation.” Our years of work on medical device interoperability have led us to see the barriers (including technical, business, liability, standards, and regulatory factors) as “wicked problems,” in which there is little agreement about “the problem,” no agreement on a solution, and problem solving is complex because of external constraints.
As an example of the challenge, I talked recently with a primary care physician who questioned whether medical device clock time accuracy—an important aspect of interoperability, an initiative of ours at MD PnP, and a requirement of Meaningful Use Stage 2—was relevant for his practice. So what if the clock is a minute, hour, or day off? He may not realize that some EMRs are configured to reject data that are outside of a certain time window. We have learned that the root cause of some problems with missing data in EMRs is the inaccurate time stamp of readings.
Someone who thinks about interoperability too narrowly might think these are esoteric details that don’t really affect them or their practice. But if you look at interoperability cohesively, as a fundamental requirement to enable our medical devices to stop functioning in isolation, but rather, to be an integrated part of the healthcare environment, you realize that no one would ever have intentionally designed the system as it has evolved today. As we enable medical devices to be “good citizens” in the healthcare ecosystem, the opportunities for improvement are vast and go beyond the details of any one solution.
The need for interoperability will continue to increase with distributed care, remote care, and other innovative care models. Meanwhile, the scope of interoperability goes beyond medical devices to include health IT and the information needed in clinical workflow. It all has to be integrated to provide sufficiently rich context to interpret data. That’s not easy, and it’s not the end point, but it is essential for innovation.
|
Change Expectations > Change Technology > Change Healthcare The Medical Device “Plug-and-Play” (MD PnP) Interoperability Program is leading the adoption of open standards and technologies for safe integration of medical devices and HIT to improve patient safety and healthcare efficiency.
|
Carr: When you talk about looking at the problem cohesively, are you saying that interoperability is more than a technology problem?
Goldman: Yes. To be sure, there are tough technology problems to be solved, but interoperability is not solely a technology problem. I often hear people say, “My engineering students could solve that by writing a communication driver for thus and such interface…” Even if that were true, the engineers might not be dealing with the larger challenges such as regulatory and safety concerns and feasibility of implementation in clinical practice. History has shown that trying to solve this problem piecemeal, from the bottom up, by creating an interoperable solution that works, let’s say, only between two vendors, is not effective because it won’t be scalable. A narrow technology solution may solve a specific implementation and location, but it will be a limited solution. It may not be reusable to solve anything else for the industry.
The community has been approaching this so haphazardly for so many years that people forget to look at it holistically—as a system.
Carr: Can you describe what it means to look at interoperability holistically?
Goldman: I’m suggesting that we should have a national dialogue about the long-term vision of what we would change in healthcare if we had capabilities like this. In a sense, that vision of a completely different workflow using current sensors, actuators, and communication technologies in new ways, and lowering the barrier to introducing new technologies into the system of care will generate a road map for the future.
Dr. Goldman and MD PnP team show demos to industry visitors.
We need to lay out how we might proceed even if we can’t get there immediately. I sometimes use the early planning of New York City to illustrate this concept. In New York, lower Manhattan was populated first, and a grid pattern for streets was established for future development of the city. The grid went so far north, it seemed as far away as the Dakota Territory. A building that we still admire today was built in the 1880s on the Upper West Side, and some believe it was named The Dakota because it seemed so remote at the time. Today, we are in a position to lay out a grid for our vision of what the future of healthcare might look like. And we can start populating it once we lay out the infrastructure.
Carr: How necessary is it that the busy primary care physician you mentioned earlier buy into this vision for interoperability?
Goldman: It’s not essential, except for early adopters and physicians and executives in leadership positions, especially in EHR-related leadership positions, since device integration is essential for the EHR. Data availability drives future uptake. For example, people didn’t clamor to have USB thumb drives and Bluetooth headsets when they first became available. Nor did they demand streaming web video before they could email photos. The early adopters were key for the market, which depends on them. There was enormous investment in developing each of these technologies—USB, Bluetooth, WiFi, smartphone platforms—that we take for granted today. You don’t need everyone to buy in to make it happen; you need just enough traction, enough investment and vision for people to appreciate that it’s a game changer. Widespread, safe interoperability is a game changer in healthcare because it will affect so many different things, from the mundane and trivial, to sophisticated, advanced practice capabilities. Imagine if we had app stores for medical apps that would use real-time data from medical devices to deliver smart alarms, decision support, and smart checklists. These capabilities are all possible and require effective medical device interoperability.
Carr: What kinds of stakeholders need to be part of the solution for interoperability?
Goldman: To be effective, this work has to consider the needs of a whole range of stakeholders—healthcare delivery organizations, biomedical engineers, medical device manufacturers, federal research and healthcare agencies, academic scientists—because that will yield deliverables that can serve as a foundation for change. Many manufacturers are increasingly aware that they will only be able to deliver these solutions through collaboration with others, including other manufacturers.
This is another way that our approach to interoperability needs to be “holistic”: diverse stakeholders need to collaborate to define the problem, develop standards and certification, and bring products to market.
MD PnP lead engineer, Dave Arney, shows device adapters at Lab Open House in October 2012.
As with WiFi and Bluetooth, alliances are one way to advance interoperability. I work with the Continua Health Alliance, which serves as a good example. A group of manufacturers and the members from healthcare delivery organizations worked collaboratively to identify a range of meaningful use cases that interoperable products could deliver. Then we condensed the use cases after the technical working group evaluated feasibility. Finally, Continua’s membership community voted on the prioritization of the remaining use cases. That’s how the work of the group was decided. Manufacturers were able to deliver those solutions and products to market. I have been learning a lot from my engagement with Continua. It is a good process, based on successful approaches in other industries.
Getting a rigorous, comprehensive, and public analysis of the interoperability challenge and discussion of the implications for stakeholders is one of the most important things that we’re still working on. Patients and their families are among those stakeholders. Effective interoperability will make it much easier for patients to understand the phases of their care and for families to be informed and participate in decision-making. Interoperability will help the care teams, which is increasingly important as we have moved toward shift-related work for physicians, especially with the reduction of work hours and emphasis on continuity of care. Awareness of the importance of teamwork has been elevated. The needs of all stakeholders will affect the technical solutions that are identified for interoperability.
Carr: In what ways will this work improve patient safety?
Goldman: Safety is both a concern and an opportunity in interoperable systems. First, we need to think about the safety of the system itself in such basic terms as reliability, speed, and identification. I can use Bluetooth again as an example. I was talking on my cellphone at home recently, and I kept losing the call. Eventually I realized that I had left the Bluetooth speaker on in my car, which was parked in the driveway. When I approached a wall near the driveway—apparently within range of my car’s Bluetooth network—my phone connected to the car speaker, and my caller couldn’t hear me anymore because my microphone was going to the car instead. That’s an example of a perfectly well-designed system sabotaging my workflow in that moment. Needless to say, in a medical setting, that could have significant safety implications.
System behavior analysis like the one I just described is a big part of the research we’re doing at MD PnP under our various federal grants with a team of expert collaborators (see http://www.mdpnp.org/quantum.html). How do you compose these systems so they’re inherently reliable, robust, and fail-safe (or failure tolerant)? How do you assess the risks from an engineering standpoint? How do you architect the systems so that these problems are handled appropriately? You can’t expect people using these systems to worry about a whole host of “mundane” system safety and communication issues.
Safety is also an opportunity. This is the exciting part, where we believe we can enable revolutionary improvements in patient safety. Interoperable systems will enable manufacturers, researchers, and clinicians to develop and deploy innovations. In the use cases we’re working on at MD PnP, our main goal is not to design all the possible solutions to improve patient safety. That’s beyond any single group’s ability. That’s the job of the healthcare community and should be crowd-sourced as technology enables this approach. At MD PnP, we’re trying to use some of the patient safety improvement solutions as examples to understand what capabilities they and other innovations will need within an interoperable system to be delivered to the bedside. For example, we are developing an open ICE (Integrated Clinical Environment) platform that will enable researchers to run medical device apps. The ICE platform is a key pathway for us to identify the interoperability capabilities necessary to support innovation and deliver use cases to drive technology development and broad community adoption.
This is an important point. Clinicians have many brilliant ideas about how to improve healthcare, which can’t be implemented. The reason for doing our MD PnP work is to enable clinicians and others to implement their ideas to improve care. That’s the real goal. Interoperability is an enabler. Currently, we lack the technological means to fully integrate data, devices, and infrastructure to innovate care. Many research papers, theses, and products that could have improved healthcare, instead collect dust on a bookshelf. The ideas are valid, but it has been too hard to introduce new technologies or algorithms into the care environment. Imagine if you had to buy a new computer, mouse, and monitor, just to benefit from the latest Bluetooth technology.
With programmatic support by CIMIT, DoD, NIST, NSF, and NIH, MD PnP is helping to create an ecosystem that includes clinicians, manufacturers, systems engineers, and others. We also are collaborating with the FDA and universities around the nation to develop an open ICE platform for medical device interoperability and health IT integration that will enable safe and effective marketplace system integration to improve patient safety, and provider effectiveness and efficiency.
Carr: How much interoperability is available in medical devices today?
Goldman: Not very much, but interoperability isn’t “all or nothing at all.” Awareness and interest has expanded greatly in recent years. For example, the IHE Interoperability Showcase at HIMSS has grown quickly, even though the products demonstrated are not necessarily commercially available and tend not to address the “wicked problems” we discussed earlier. I wish more manufacturers would begin by agreeing to fully disclose their current interfaces. What are their devices capable of doing? What clinical and technical information do they send and in what format? We can be successful as a community in our efforts to facilitate device integration even before we have full interoperability by requiring full disclosure of communication interfaces.
Custom-built and off-the-shelf adapters (dongles) used in the MD PnP lab.
Carr: Is interoperability included as a requirement in Meaningful Use? Have you participated in those discussions?
Goldman: We have been involved in discussions about interoperability and Meaningful Use Stage 2 requirements for clock times and time stamping of data elements in the EMR. If interpreted broadly, those requirements will be quite powerful. They were carefully written to say that data should be reference-able to an accurate time based on Network Time Protocol (NTP). Having truly reference-able data—knowing the relationship between the time stamp and the data and the correct time—will help with data accuracy.
There are a number of medical device-related requirements that probably will be proposed for Meaningful Use Stage 3, but they will be part of certification, not part of Meaningful Use requirements for reimbursement. The approach has matured. With Stage 2, we’ve seen that the way to require certain capabilities for interoperable data elements is through ONC certification.
Unique Device Identification (UDI) provides an example of capabilities that should be ensured by certification. UDI implementation has several aspects. The first is the barcode or label that appears on the package of, let’s say, an implantable device, and can be read by an optical scanner. The second thing we clearly need is for the UDI to be readable over a device’s electronic data interface if it is connected to a network. It would be unfortunate, even ironic, to have a population of thousands of medical devices connected to the hospital network and expect clinical engineers to walk around with a barcode scanner to identify each one. Unfortunately, that farcical scenario is quite possible. That’s how it is today. Given that UDI is an implementation of technology under new FDA requirements, I think we’re going to see network readability of the UDI develop, and I expect that will be part of the certification requirement.
Carr: How can interested clinicians and other stakeholders participate in these development efforts?
Goldman: Clinicians can contribute clinical scenarios to ensure that new interoperability standards and technologies will enable meaningful clinical solutions – we are developing a web interface to a scenario repository in order to facilitate the collection and use of such scenarios. Manufacturers can begin sharing information about their device interfaces and making more device data (e.g. alarm limits, filter settings, device serial numbers ) available through those interfaces. They can work directly with our program in our vendor-neutral lab to determine what device data is important to share, both for general safety improvement and for implementation of specific clinical use cases, and on shared interoperability testing. Engineers—both clinical and academic—can analyze clinical use cases to generate functional specifications, assess current standards to perform “gap analyses,” evaluate proposed technologies, and conduct research on safety and security aspects of medical device interoperability.
Work described in this article has been funded by awards from NIH (U01EB012470-03), USAMRMC (W81XWH-09-1-0705, W81XWH-12-C0154, and W81XWH-07-2-0011), NIST (70NANB10H258), and NSF (CNS-1035715, subaward 555729). The opinions expressed are those of the Principal Investigator and not of the funding agencies.