On December 19, 2008, a group of about 50 people met to to discuss wireless medical devices. The event was organized by Don Witters of the FDA, Elliot Sloane from Villanova (and contributor to HITSP, IHE, ACCE and others), the wireless Czar of Partners Healthcare, Rick Hampton, and ubiquitous industry standards maven, Todd Cooper. The meeting was held in the new nursing school building at Villanova with a live video teleconference connection to Carnegie Mellon University (CMU) in Pittsburgh.
The meeting was billed as a workshop on wireless technology in health care, with an emphasis on what is needed for safe, secure and reliable deployment. (You can download the agenda that was sent out here.) A wide net was cast, and participants represented Wi-Fi infrastructure vendors (Cisco, Trapeze, Aruba, Motorola, InnerWireless, MobileAccess), medical device vendors (Hospira, Philips Research, GE Healthcare, Sigma International, Smiths Medical, Welch Allyn, Draeger), AAMI, ASHE, the Medical Records Institute, Bosch, Verizon, ECRI Institute, NIST, various academics (Drexler and U of OK besides Villanova and CMU). The only provider organizations attending, besides Partners, were Memorial Sloan-Kettering, Kaiser and the VA. GlobeStar Systems was the lone health care software vendor. Due to limited seating, not everyone who wanted to attend was able to be accommodated.
Elliot kicked things off with a welcome and review of the agenda. Don Witters then came up and set the stage from the safety perspective, and Rick Hampton did the same relative to Partners' position as a provider organization. We wrapped the first portion of the agenda by going around the room in both locations introducing ourselves. The rest of the day focused on two sets of break out discussions:
- Group A - identifying stakeholders, benefits, challenges, risks
- Group B - Identifying/categorizing critical wireless medical device/network security dimensions/factors for CIA&S (confidentiality, integrity, availability and safety)
- Group C - CIA&S, performance metrics that could/should be cataloged (e.g., QoS, bandwidth, etc.)
- Group D - System design and life cycle maintenance, verification and validation strategies, and sources to assure CIA&S in future applications
Throughout the day discussions sought to identify wireless problems and get to root causes.
Framing the Issues
Don Witters noted how the physics of radio frequencies (RF) creates a "commons" where RF commingles, and how this can become a no man's land with no clear regulatory responsibility at the industry level, and inadequate implementation and management at the customer level. This was perhaps the most concise statement of the wireless medical device "problem" made during the workshop.
Apparently playing devil's advocate, the question was asked if wireless, and the risks that go along with it, was necessary or even desirable. In light of the way that health care is delivered, and the overwhelming market requirement for mobility, abandoning wireless technology in medical devices was rejected as impractical. Wireless benefits mentioned included the elimination of the infection risk posed by cables (which are almost always reused, rather than disposable), and problems with tripping over or pulling out things like catheters, sensors, power cords and CAT-5 cables. Cable and plug variability across vendors and products also results in cable proliferation and the need to manage and find the right cable for a particular use.
Once it was agreed that wireless is here to stay, the discussion moved to framing the discussion of risks inherent in wireless technologies. Some of the areas mentioned include security, availability, quality of service, coexistence, electromagnetic interference (EMI), and privacy. Regulatory and legal risk were mentioned, although these are consequences rather than actual risks inherent in wireless. More technical risks mentioned were electromagnetic compatibility (where EMI might get modulated and mistaken for actual physiological data), latency, jitter and other risks resulting in data corruption. Many of these risks were more formally described as CIA&S - confidentiality, integrity, availability and safety.
Paul Frisch noted that he has seen users come to equate the data accessed wireless from the medical device with original medical device data, not taking into consideration inherent risks that might result in lost or corrupted data. A similar education issue (assuming the wireless medical device is designed properly) revolves around the potential EMI from other devices like cell phones that may impact the operation of medical devices.
Don Witters described an informal model for framing risk. At the low end there is communications indirectly related to patient care, that may be only somewhat sensitive to timing and time criticality relative to the application. In the middle there's communicating that is directly related to care delivery (coordinating care, wireless medical devices), and at the upper end, direct control of a device wirelessly. These three levels of risk can be deployed anywhere, from acute care to patients on golf courses. This discussion did highlight the need for the evolution of thought and experience in applying risk management to wireless medical device systems - or arguably, to any kind of medical device connectivity.
Chris Lavanchy from the ECRI Institute noted a general bias towards high risk areas when considering wireless medical devices and safety. He suggested that we not exclude general IT wireless requirements that must also be met. This observation highlights the frequent "talking past one another" that occurs between hospital IT and medical device vendors, who sometimes think that their requirements are paramount, to the exclusion of the other guy's requirements. Much like some CIOs think that their choice of enterprise IT standards should be more important than selecting the most effective medical devices, some medical device vendors think they can dictate enterprise IT choices to CIOs regardless of the duplication, complexity or costs imposed on the enterprise.
Later, Paul Sherman with the VA noted that discussions of health care sometimes seem based on an informal goal of perfection, or zero risk. (This seems to be the case when patients accept high risk procedures and then sue when those risks are realized.) No technology, especially wireless, is perfect. Sometimes wireless takes an unfair hit because it is not perfect.
Julian Goldman noted that, "the safest medical device is the one you never take out of the box." Use of any medical device comes with some degree of risk. He explained that the goal is not to completely eliminate risk, but to understand, mitigate and mange the risk. "There are too many things we could be doing that would significantly improve patient care and safety," said Julian, "but are resisted, partly due to an aversion to the perceived risk associated with those new applications." This is a common criticism of even the most basic kinds of medical device interoperability, like safety interlocks. According to Julian, "Even straight forward applications like wireless remote control of medical devices are resisted because of perceived risk. But if the patient is in isolation, or undergoing radiation therapy, the benefits of this remote control - that probably spans several feet at most - could greatly outweigh perceived risk."
Later Julian noted another aspect of risk, how risk can be divided between the operational side and those focused on innovation. Operational risk is focused on the use, fix/repair, maintenance and support of existing products in the field. Here the product is what it is and the focus is on maintaining the risk model that was developed and realized in the product development process. The risk model for innovation is one in which there are many unknowns. The challenge is to develop a solid risk model and then realize both your innovation objectives and a physical manifestation of the risk model as a safety product. These two spheres have the same goal of patient safety, but how you achieve those goals is wildly different.
Scope
The issue of focus or scope came up repeatedly during the day. For example, in reviewing potential stakeholders, the resulting list was so comprehensive as to likely preclude reaching a meaningful consensus on solutions in a reasonable period of time. Focus also became an issue when discussing existing customer issues with currently released products in contrast to solving current and anticipated problems with as yet undeveloped new technologies. More than once, an attendee tried to steer the discussion back to "solving Ricky's problems," (with existing wireless products installed at Partners) rather than exploring greenfield technology development solutions.
The goals of safe and reliable operation, coexistence and interoperability were identified as 3 key objectives. The need is to figuring out a way to get solutions installed in health care provider organizations that are stable. There was a group consensus that we should focus on the acute care setting, rather than smaller or more nascent markets like home-based remote monitoring. The hospital market is feeling the pain of these issues first and foremost.
The group further described a need for broadly understood and adopted approaches to communications availability and failure modes, so that heterogeneous systems can be more robust and reliable. The in-development voluntary end user standard IEC 80001 was mentioned, and the group seemed to agree that this was an important part of the solution - but only a part. The question of how risk is to be assessed in this system of systems is still open. Suggestions were made that there may be a need for simulations and modeling, standardized tools and test plans. Disruptive technology introductions were noted as potential "flies in the ointment" of any grand solution.
Many of the engineers in the group wanted to start right off with use cases. I'm a big fan of use cases and use them frequently in my consulting practice, but they are best suited for product development. The wireless problems that are most acute are those with existing products that are already installed. It is with released product that we have system of systems, coexistence and interoperability problems.
Best Practices
As with connectivity (and life in general), we frequently don't know what we don't know. Don Witters noted that medical device vendors launching their first wireless product rarely know what they're getting themselves in to, and that IT departments also lack the background and experience to understand the requirements for effectively deploying and managing wireless medical device. What is needed here is the development and proliferation of best practices, adopted by both vendors and end user/buyers.
Regarding hospitals, it was also noted that most lack a position responsible for RF spectrum management. This position keeps track of all the intentional RF sources in an enterprise. This catalog of enterprise RF uses, frequently organized by the spectrum and protocols used, is then used to guide an assessment of the external RF environment. Every hospital needs to know all of the licensed RF users in their community that could possibly impact their RF applications. All of the appropriate registrations, licensing and notifications must be completed to ensure the best RF coexistence between the hospital's RF applications and those found in the surrounding community. Continuous vigilance is also needed to monitor the enterprise RF environment for unintentional interference, EMI from faulty equipment, or intentional interference from a source outside the hospital. And finally, all of these responsibilities of the RF coordinator rest upon a foundation of education and awareness that must be inculcated among hospital staff, clinicians and senior management. All this is a tall order, so it's no wonder that hospitals haven't been rushing to create this new position and get it staffed.
There is a related but different set of best practices for medical device vendors with wireless medical devices. A chief need of the industry is a means to develop and spread the adoption of a common set of best practices. There will be multiple sets of best practices, probably developed and endorsed by different organizations. Of course it's critical that all these efforts be complementary and work together to solve some of these problems on an industry wide basis.
COTS - Components Off the Shelf
The suitability of incorporating COTS into medical devices was another common issue. On its face, the use of unregulated COTS in medical devices appears iffy at best, and irresponsible at worst. Steve Baker noted that his use of COTS are all verification tested to the intended use. In fact most electromechanical medical devices - and virtually all medical device systems - make extensive use of COTS. And the FDA's regulatory framework provides considerable support for the safe and effective incorporation of COTS in medical devices.
In an observation related to the issues around COTS, Joe Morrissey with Motorola noted that not all the stakeholders in wireless medical devices want to get wrapped up in these issues. For example, cellular carriers or the WFA (Wi-Fi Alliance) don't want to go so far as to be regulated by the FDA or become subjected to the level of risks that medical device vendors assume. Paul Frisch, from Memorial Sloan-Kettering suggested that if the regulatory and risk burdens for COTS vendors become too high, they'll actively try to limit their exposure by doing things like labeling their products as "not intended for medical use."
Later in the day the question was asked, "Is there too much reliance on off the shelf technologies?" Attendees most interested in developing new greenfield technologies were most responsive to this, implying that the use of COTS was inherently inadequate. This brought discussions to the fore about the evolution of the Medical Implant Communications Service (MICS) and a proposed wireless sensor frequency allocation.
Certainly the exclusion of COTS from medical device systems would eliminate some problems. Such a move, say creating a dedicated technology for wireless medical devices, would pull those devices off the enterprise network and place them firmly back in the control of the medical device vendor. Such a move would still face the current problem of coordinating medical device vendors product efforts so they can safely coexist on the same infrastructure, in this case one dedicated to medical devices. An effort like this would take several years to complete and we would still have to deal with our current problems in the mean time.
Another challenge is that the wireless "commons" that Don Witters mentioned at the beginning of the conference will still remain. A dedicated wireless medical device technology would face the same challenges dealing with interference and coexistence in the RF spectrum.
Assuming that it's possible for a new standard or technology dedicated to medical devices to solve most of the problems discussed at this workshop (I can't think of any, how about you?), the costs to develop and incorporate that technology into medical device systems will significantly add to the cost wireless medical devices. With debates about rationing health care and the inevitable aging population, do we really want to chose to increase the cost of health care, especially if we don't really have to?
Systems of Systems
The creation of unintended (as far as the medical device vendor and FDA are concerned) and accidental "system of systems" really came to the fore in the discussion in break out session B. When considering the challenges inherent in wireless medical device systems, the desired end result (from end user/buyer's perspective) is a system of systems.
Imagine the scenario where a vendor, end user/buyer, or systems integrator takes a regulated medical device and "extends" it by integrating it with other different medical devices, or features based on general purpose IT technology. When end user/buyers do these kinds of things, they either meet the legal definition of a medical device manufacturer (which is based on what you do, not what you call yourself), or use the medical devices "off label," i.e., outside the vendor's specifications or intended use, as approved by the FDA. These resulting systems of systems almost always exceed the medical device vendor's intended use, and by doing so, use the system in ways for which the medical device was never designed or tested.
Think of what GlobeStar Systems or Emergin does for alarm notification. Integrating medical devices into EMRs for documentation or configuring a device based on an order from the CPOE system. Such systems of systems have used in the industry for several years. The quality of these implementations has varied greatly, and the majority of those engaged in these activities have not been submitted for regulatory approval. Not surprisingly, there have been patient injuries and deaths attributed to some of these systems - which is why the FDA has a growing interest in this area.
As the chief instigator of IEC 80001, the FDA is seeking to improve the safe use of networked medical devices (that, as a consequence of systems integration facilitated by networking, become systems of systems). The FDAs proposed rule on Medical Device Data Systems (MDDS) is also intended to address parts of this problem directly (the MDDS), and indirectly by signaling to the market that systems of systems providing remote surveillance and alarm notification will be regulated as preamendment postamendment Class III devices. This meeting is a further effort intended to nudge the industry in the direction of further improvements.
An excellent system of systems conference dealing with many of these issues was held in June of 2007. The co-chairs were Julian Goldman and Insup Lee, from the University of Pennsylvania School of Engineering.
There was also a great discussion about who assumes what risk for systems of systems. Different answers were posited based on who's involved - medical device vendor, COTS vendor, clinician, biomed, IT, regulator, etc. A simple way to look at this is to focus on who's making changes to a regulated medical device. If the medical device vendor does it, they assume the risk. If a third party vendor like a systems integrator or software vendor makes the changes, even simply by adding on to the medical device system, that third party picks up much of the medical device vendor's risk, and also takes on regulatory risk - either the work required to gain approval, or the risk of enforcement actions.
Providers have so far gotten a free pass from the FDA when it comes to effectively becoming a medical device manufacturer by creating systems of systems. A review of comments submitted to the FDA on the proposed MDDS rule shows a number of provider authored responses. Surprisingly, they don't want to be held to the same standard (regulatory approval) that they insist their vendors meet when doing basically the same things. This is understandable when I put myself in their position; as a prospective patient in their hospital their position is untenable.
Measuring Performance
Break out session B, facilitated by Rick Hampton, looked at performance metrics and the role they may play in a solution. Presently, measuring performance of most everything - the RF environment, wired and wireless networks, and medical device systems - is ad hoc and defined on an institution by institution and/or product by product basis.
Most analysis is done at a specific point in time and there is generally insufficient continuous monitoring or real time analysis within the enterprise. This is especially true when one includes medical device systems with networks. This is an obvious issue with wireless; because RF is "invisible" changes that occur must be monitored.
A description of a broader sphere of knowledge and coordination emerged with the description of a number of unmet industry needs. There is presently no mechanism for documenting and disseminating knowledge on existing protocol vulnerabilities. There is no framework for developing a consensus on reasonable failure modes - not to mention a mechanism to coordinate the implementation of common failure modes across medical device and infrastructure vendor's products. Numerous comments about baselines for performance metrics highlighted a need to achieve consensus and propagate best practices that extend from medical device system design and specification, to end user/buyer implementation, management and support.
There is no "one" answer to most - if not all - of these wireless issues. In one of the break out sessions (Group D), Don asked the rhetorical question, "What is the measure of quality of service?" This was an exploration into the question of whether a single standard or specification can be applied across large portions of the industry. Lots of things were suggested: packet loss, latency, jitter, the number of retries. The discussion quickly evolved into segmenting specifications by application, with Steve Baker describing the advantages of basing QoS requirements on the inherent requirements of the application. In his example, wireless voice over IP (VoIP), Steve described a latency threshold of 50 ms because any gaps in a transmission that length or shorter can't be discerned by the brain/ear. Translating that framework to an application like telemetry begs the question asked by Steve, "How many seconds of data can you lose before you miss a diagnostic heart beat or an alarm?" The resulting time frame becomes your QoS specification. It was also noted that the design solution for a particular application can influence specifications based on how a design mitigates certain risks or offers greater performance in some areas.
The straw man of setting specifications for the industry was ultimately rejected by the group. It seems there's no substitute for knowing what you're doing and taking a rigorous and methodical approach to developing medical devices. There was an intriguing question posed near the end of this discussion about whether a single defined strategy or process could be developed that everyone followed for creating specifications for QoS and other important performance metrics. This appears to have potential, but the entity that would develop and promulgate such a process is not clear. The FDA's Quality System regulation already defines a process. How much more proscriptive can we be without limiting innovation?
Elephants in the Room
Discussions about solving complex problems, like ensuring the safety of wireless medical devices, can be thought about at two levels. The actual topics discussed and debated are tangible and easy to grasp issues. But sometimes more interesting than what is stated outright are the implied issues that are not mentioned - not that there's some hidden agenda being pursued by some shadowy cabal. Such figurative elephants come about for many reasons, and were in fact in attendance at this meeting.
The biggest elephant (in a shocking pink, no less) is the transition of medical device systems deployed on private vendor controlled networks to their deployment on hospital controlled enterprise networks. It is this transition that currently results in much of the problems and challenges discussed at this workshop. This transition is also creating many inefficiencies and hidden costs for vendors and providers alike.
By deploying regulated medical device systems on enterprise networks, providers are (often unwittingly) assuming a big part of the responsibility for managing and supporting the medical device. When end user/customers go "off the reservation," i.e., go outside the intended use of the system, they assume liabilities otherwise assumed by the medical device vendor. Examples of going off the reservation include running medical device systems on network infrastructure not supported by the medical device vendor, configuring the network in a way that's not supported by the medical device vendor, or installing network infrastructure upgrades or new products that have not yet been verification tested by the medical device vendor. You can read more about this elephant here.
The current regulatory framework was never directly discussed. Arthur Gasch, with Medical Strategic Planning, suggested that the regulatory framework hasn't kept up with technology. He used WMTS as an example saying that there's really no standard there. It was noted that WMTS was meant to be open and that the manufacturers were supposed to develop a framework for coexistence, management and monitoring tools. Of course, this never happened and WMTS became a band used solely by proprietary solutions. You can read more about WMTS here. I suggested that the current regulatory framework is fine, and it just needs to be enforced on those that are not in compliance. This suggestion was rejected as impractical (although there was no discussion as to why this might be the case).
Another rather large elephant had to do with the commercialization of standards - which is complicated by the fact that we're talking about regulated medical devices. Sadir Matta of Cisco mentioned the WFA as an example where industry standards by themselves were insufficient in providing the desired compatibility between wireless clients and access points. Jim McCoy with InnerWireless noted how the WFA took the 802.11 standards and effectively tightened them up through their test and certification process. Jim suggested that our industry needs a similar mechanism that narrows those configuration options. Kamran Sayrafian with NIST also mentioned the IEEE (standards) and WFA (test and certification) as providing two important pieces of the total solution for the successful operation of Wi-Fi based products in the real world.
Steve Baker from Welch Allyn noted that, "As a patient monitoring vendor, I can make my products work on any wireless network. What I can't do is get my products to work with other vendor's medical devices." Coexistence between different networked medical device systems (both wired and wireless) is problematic because there is no industry "common approach" to minimize network coexistence issues (the product definition end of the problem), nor is there a mechanism for vendors to get together to do coexistence verification testing - without risking antitrust risk exposure or disclosing proprietary product info to competitors (more the product support end of the problem).
Conclusions
The issues addressed in the workshop can be usefully divided a number of ways. Existing products and future, as yet undeveloped products, can serve to segment and coordinate approaches to the problems discussed in the workshop. Market segmentation can also be useful. The acute care market (hospitals, out patient surgery clinics and the like) is by far the biggest market. The remote monitoring market (chronic disease management, health and wellness, elderly age-in-place) is on the horizon, but without a meaningful level of reimbursement remains more potential than real. While there's some overlap, most medical device vendors are either playing in the acute care or ambulatory market. Same goes for much of the technology. Cellular carriers, Bluetooth enabled sensors and gateway devices are creatures of the remote monitoring market, while Ethernet, Wi-Fi and proprietary technologies (WMTS) have been widely adopted in the acute care market. All this slicing and dicing should help formulate solutions that are narrow enough to actually get formulated and implemented, and not hindered by trying to build consensus across a group with interests that are too numerous and divergent to produce more than the most generalized and broad prescriptions.
Existing standards development organizations (SDOs) are already well positioned to work on addressing the problems discussed at the workshop for nacent technologies and products that are yet to be created. SDOs will need to clearly define the market segments they target, so efforts among SDOs can be coordinated and efficient.
Existing products can't be helped by SDOs because the die is already cast, the products are in production or already installed. Imposing new standards would just force providers to replace all the perfectly good equipment they already have - an expensive approach, and one that would take years to implement - leaving us with the current situation.
What's needed is more than standards. Matt Grubis with GE noted that, "We've been talking about 802.11, but there's a lot of new technologies in the pipeline. We need to solve this problem for today and into the future, rather than tailor the solution to a specific technology like 802.11. Later Matt reinforced his observation that we need a framework that's not tied to a specific technology, because that's always changing.
The folks from CMU suggested that we look to some kind of organization like an industry alliance. They noted examples in a number of industries like the electrical utility industry.
Postscript
This post is based on my notes and recollections of the meeting. I am responsible for any errors, omissions or mis-characterizations of what is reported above.
As always, you the reader are encouraged to join the conversation - via the comments below - with observations, opinions, and most certainly, corrections of my faulty memory.
I want to especially encourage the attendees of the workshop to add their observations and conclusions from the workshop. Out of a full day jam packed with substantive discussions, I'm sure there's a lot that didn't get into this post.
And as always, shamelss commercial plugs will be deleted per the comments policy (found here). Commercial plugs that, you know, actually contribute to the conversation are encouraged.
UPDATE: I'm told that there was someone from Emergin at the workshop, thus rendering GlobeStar one of two software vendors. I did see an unclaimed name badge for Emerin at the beginning of the day and didn't hear anyone from Emergin during the introductions. Hence my assumption.
Thanks for the update, Tim, nice summary. Was there any discussion or mention of open source software that might be used to bridge the divide among different vendors?
Tim -thanks for the thorough round-up - very interesting, indeed. To me, the wireless issues are future as I used to deal with the ‘wired’ issues especially network issues at the OSI level 2 and 3 assumptions made by medical device integration vendors, IT, medical device vendors and Biomed. Wireless adds another dimension which thankfully I hadn’t dealt with yet…well, I dealt with it at the routers and wired aspect, I guess. 🙂 (competition for port space by medical device information bound for a CIS and a VOIP device)
Thank you for the comprehensive summary - this is good information for our IT group.
Tim, Thanks for the great re-cap. I was unable to attend this meeting. I agree with many points that the group discussed. In particular a point made by Steve B of Welch Allyn and reinforced by folks from CMU. Steve commented that he can make his products work on any network, but can’t get them to work with other vendors products. The CMU Comments supported this by suggesting an industry alliance. This idea is very similar to why the Wi-Fi Alliance (called WECA at that time) was developed. However we had a similar problem in the WI-Fi org, that Steve mentions. How do you develop such a test program and still protect individual company Intellectual Properties. This has to be done as a team. The Wi-Fi org managed to get past this issue, and the healthcare industry needs to commit to the same type of thing. Without it we will continue to struggle.
Three things not mentioned that may also be important are:
(1) Do all venders really want open compatibility versus you-have-to-buy-all-your-stuff-from-me?
(2)Singular examples of wouldn’t it be good if device A could tell device B this one thing (and device B could understand what it was told and act on it)can be misleading. A telling B x is far different than A, B, C… telling M, N,O…u,v,w,x,y,z, and everything being designed and configured to actually use that information (beyond just recording it in an EMR). The next question is going to be not “can they talk to eachother?” but “do they care what eachother is saying?”
(3) Besides frequencies, what about bandwidth? At some point there is only so much traffic you can support. What is that point? Hotels have discovered this and are busy increasing capacity to meet business, recreation and conference uses. You can’t always keep adding 802 apps.
Hi Tim;
Thanks for the recap, it sure saved me from relying on my meager notes (I was a participant)
The commenters have brought up some good points. As this group moves forward, we’ll welcome input from folks involved. We’re still very early in the process. One feeling I came away with was that many of the pieces are in place to create a medical-grade wireless network for the areas of the hospital that require it. For example, Steve Baker of Welch Allyn published a paper last April showing how it can be done. The next part is to consistently bring those pieces together in such a way that hospitals can easily construct and manage that life-critical system.