Yesterday, Draeger announced that they had completed interoperability testing with WiFi infrastructure vendor Trapeze Networks. What they call a “Certification Notice” indicates that they’ve completed formal verification testing (and probably a “letter to file” for regulatory purposes) to ensure that their regulated medical devices, running on a Trapeze wireless LAN, operate within specifications. Aruba announced at HIMSS 08 their certification for use with Draeger’s Infinity patient monitoring system. Also, Aruba and Welch Allyn announced interoperability at HIMSS 07.
Here’s how Draeger describes their certification effort (emphasis mine):
In Drager’s notice of certification, Lars Roth of Drager’s Monitoring Systems and IT group, wrote, “Due to the critical nature of medical devices, Drager Medical tests and verifies network hardware components used for communication between medical system devices. These tests include proper IP Multicast handling, wireless roaming, wireless encryption and load testing. In addition, tests with competing traffic are run in order to understand and detect the proper Quality of Service settings. These are the key parameters that will ensure that in a shared Infinity OneNet installation, the data flow of the Drager patient monitors is being prioritized over non-patient monitor data.”
Most medical device vendors complete validation test for a new product supporting that one WiFi infrastructure vendor at market launch and beyond. Depending on the regulatory strategy of individual vendors’ products, completing the validation with additional wireless LAN vendors can be very time consuming and expensive. Compounding this is the fact that verification test is a common R&D bottleneck for many medical device vendors.Read More
In the first installment on the IEC 80001 standard, I delved into the history of this particular standards effort and the patient safety needs the standard is supposed to address. There are two kinds of products being bought by providers that give rise to serious questions about patient safety:
- Medical device systems – that is medical devices that extend their capabilities by leveraging software running on general purpose computers, and
- IT-networks – the wired and wireless networks – both local and wide area networks – that connect medical devices to their own servers and client applications, in addition to connecting them to other systems of medical devices and/or health care information systems.
Medical device systems used to be deployed on their own private local area networks. This paradigm is breaking down for two reasons:
- Private networks result in “islands of information” that make it difficult to pass information between medical device systems and the greater IT infrastructure within the provider organization, and
- Medical devices that were once relegated to specific locations are becoming enterprise applications in use almost anywhere in the provider’s enterprise.
It’s just not practical to install multiple private networks across ever increasing portions of the enterprise. A mid to large sized hospital can have 50 to more than a hundred private networks supporting medical device systems. It is admittedly pretty easy (if not cost effective) to bridge private networks to move data between medical device systems and applications like ADT and EMRs. The real driver that is tearing down private medical device system networks is the fact that many devices are used across the entire enterprise rather than individual departments and units.Read More
There’s been increasing rumblings in the industry about the soon to be completed standard, IEC 80001. While it is starting to get some discussion, the vast majority of hospitals and vendors have yet to hear about it. This post is an effort to raise awareness and spark some discussion.
In December of 2005, the FDA hosted a study session (more here, here and here) to discuss a new and growing threat to patient safety and possible solutions. The threat is the increasing availability of computer controlled medical devices operating in enterprise network environments. Medical devices systems of this kind include patient monitors and central stations, smart infusion pump systems, and devices connected to information systems that do surveillance and alarm notification (Cardiopulmonary, LiveData, Ascom and others).
There are two levels of threat. The first is when medical device systems are used in broader environments, like enterprise networks, which were not anticipated (at all, or at least not fully) by the manufacturer. Once the regulated medical device system is installed in the customer site, how the network environment is designed, managed and changed over time can impact the safety and effectiveness of the medical device.
A different threat emerges when regulated medical devices are combined to create systems of systems that were not anticipated (at all, or at least not fully) by the manufacturer. The actors in this scenario extend beyond the governmental regulatory agency and individual medical device manufacturers, to include third party IT infrastructure vendors, other regulated medical device vendors, and health care providers. When a provider buys a variety of medical device systems and deploys then on an enterprise IT infrastructure, how that infrastructure and medical device systems are configured and interact introduces new and unanticipated risks.Read More
It seems that something like the existing ISO 14971 risk management standard for medical device manufacturers will be used to address networked medical devices. Several major revisions will be required, not the least of which is the kind of risk. The potential harm that ISO 14971 tries to mitigate is risk of injury to patients. Medical device connectivity entails this risk, as well as others. Another difference is that 14971 applies to the development of new medical devices, and much of connectivity entails the integration of legacy medical devices. And of course, as noted before, the connectivity risk management standard will “pierce the veil of commerce” and apply to users as well as manufacturers.
As a group we reviewed the following concerns; stepping on other’s regulatory toes, the decree of proscriptiveness, getting input and participation from users, scalability of the standard so it works as well for a 50 bed hospital as it does one with 500 beds, the costs that might be incurred by implementing this standard, and how the standard might disrupt care or negatively impact clinical practice. All these topics were discussed and resolved.
We started working on a scope, but didn’t make much progress. One thing that vendors desired was that the standard not apply to vendor “products” that include general purpose computing components (like servers, PCs and network gear) as long as they are isolated and standalone. Any time general purpose computing components are included in a solution, whether it is a “medical device” (a closed vendor supplied system) or integrated onto the hospital’s network and tied to other systems, connectivity problems can arise. This preference will probably remain because more and more hospitals are refusing to buy standalone systems (islands of information), and there’s nothing to prevent buyers from including the risk management process in negotiations for standalone systems – whether required by the standard or not.
So why is this standard being contemplated? The objective is to provide the key stakeholders (regulators, vendors, users, third parties) with a common tool to facilitate communications, coordinate efforts and manage risk when medical devices are integrated into the highly variable general purpose computing environment. I think the resulting standard will be a boon to all stakeholders, and especially users. The standard should provide a framework for detailed information and capabilities to negotiate with vendors at the point of sale, establishing responsibilities and service level agreements (SLAs) for things like component obsolescence, operating system patches and other connectivity issues.
Next steps will be to capture the problems, hazards and risks to be managed by the process, and to write a scope. There are two subsequent meetings planned, one in Frankfurt, Germany in March and another somewhere in the “lowland countries” in September. My next focus will be to tease out problems, hazards and risks. Any suggestions, observations or input is appreciated.Read More
There were about 25 attendees today; mostly regulatory, quality and security experts along with a few representing hospitals, and a connectologist or two. We ran from 11am until almost 7pm. (You can read my run up to this meeting here.)
As security expert and clinical engineer Steve Grimes noted, we are an industry in transition with medical devices and information systems merging into some Borg-like creature to deliver safer and more automated care. Device vendors and biomeds are struggling with the general purpose computing environment; hospital IT is learning the demands of clinical care; while third party vendors (think vendors like Microsoft, Cisco, phone companies) try to meet market requirements of a demanding niche market (health care). The problems that were discussed reflect needed education and improved communications between the various stakeholders.
Manufacturers (of medical devices) want to be able to sell a networked device or medical system with a defined set of features in compliance with regulations to a user who is capable of understanding the accompanying documents and who actually understand the documents. Users want to be in compliance with regulations, and they want devices that will all be compatible with other devices and other equipment â€“ interoperable.
There was lots of talk about the “dead hand of regulation” and “piercing the veil of commerce” (the application of regulations to users after the sale). There was virtually no support for new regulations. The group seemed to favor an advisory or consensus process standard – best practices – that could be used by all stakeholders, including organizations like JCAHO for accreditation purposes. The approach that got the most support was a life cycle risk model that incorporated skill based roles. The result would be a comprehensive process or recipe that would coordinate efforts by vendors, hospitals and any third parties (contractors, systems integrators, consultants) that might be hired to fulfill formal roles defined in the process. The German group SC62A presented a “new work item proposal” on networked PEMS (Programmable Electrical Medical System) that could serve as a template for the broader life cycle scope that was discussed. You can download a pdf file of the document here.
So what of these dire problems that all of this is supposed to solve? Patching the Windows operating system used in various embedded devices and computers was one of the first examples that were discussed. John Murray with the FDA’s enforcement group described how they figured there would be more connectivity-like issues in the future and chose not to use new regulations as a first response. The FDA applied the existing regulatory framework and told industry to get their house in order – which is pretty much what’s happened. Other connectivity problems include protecting medical devices from malicious code. Another biggie was medical devices not fully supporting general purpose computing configurability; surprisingly many of those network and security options are actually used and they are not supported at the risk of lost sales – and of course this becomes apparent when both the buyer and manufacturer make assumptions that blow up at installation. Down time, scheduled and otherwise, is a frequent bone of contention – any device that generates life critical alarms across a network cannot be down, not even when its scheduled for just 2 hours once a month. Finally, what happens when a third part component of a medical device system (like a PC, router or WLAN card) fails 3 years after installation? Give the short life cycle of these types of products, a replacement will not be available.
The industry has an inclination to apply an embedded system business model (limited configurations and parameters) to systems integration. Systems integration happens in a general purpose computing environment and this environment can’t be proscribed because of the variability in ways IT systems have been built up over time and communicate with each other, both intra and inter hospital.
More tomorrow…Read More