IEEE Completes 802.11r Fast Wi-Fi Roaming Standard
Just what we needed (really), another letter in the alphabet soup of 802.11 standards. This one, 802.11r, is also known as Fast Basic Service Set Transition (more details on the standard here).
The 802.11 standard was originally conceived to operate around individual access points (APs). This is a far cry from the high density AP network designs increasingly being installed in hospitals – and the wireless medical devices and other mobile applications they support.
In a conventional WiFi network it takes about 100 ms to re-associate with a new AP, and several seconds to re-authenticate connections using 802.1x (a common security requirement in many hospitals). This time lag can potentially result in several second gaps in patient monitoring waveforms, missed alarms, and dropped wireless VoIP phone calls. Another problem fixed in 802.11r is that a client radio does not know if the required quality of service (QoS) resources are available in the new AP until after it has associated with the new AP.
FDA MDDS Webinar
As the FDA grinds through the comments submitted in response to their proposed rule for medical device data systems (MDDS), the market awaits the final rule. Regardless of changes between the proposed and final rules, vendors who may be regulated under the new rule will have limited time to prepare.
Awhile back, I was contacted by ComplianceOnline to author a webinar on the FDA’s proposed MDDS rule. After some discussion, we agreed on the following pithy title: The FDA’s proposed Medical Device Data System (MDDS) rule and its implications for currently regulated and unregulated vendors and providers. The key objectives for the webinar are to provide clairification on the proposed rule and explore the consequences for those involved with MDDS – vendors and hospitals.
You can read a description and register for the webinar here. Attendees are encourage to submit questions – which I will answer during and after the webinar.
Alas, the webinar is not free. But compared to what it would cost in my time to lay out the proposed MDDS rule and its implications in detail, the price is a bargin.
If you have any questions about the webinar or MDDS, feel free to contact me (scroll down to the bottom of the page). You can also leave questions on the web page promoting the webinar.
IEC 80001 to Impact Providers
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.
What’s Wrong with the Proposed FDA MDDS Rule
The FDA has proposed to reclassify Medical Device Data Systems (MDDS) from a default class III to class I. (You can read the proposed rule here, and the public comments here.) This is based on the belief that “risks to health from this device would be caused by inadequate software quality. Specifically, the risk to health would be that incorrect medical device data is stored, retrieved, transferred, exchanged, or displayed, resulting in incorrect treatment or diagnosis of the patient.” In my opinion, this is insufficient. Consideration must also be given to the risk of interactions between MDDS and devices.
Until now MDDS has not been a term that was widely used in the medical device or health care information industries. The FDA has proposed a definition that can be summarized as “a device that provides one or more of the following uses: electronic transfer, exchange, storage, retrieval, display or conversion of medical device data without altering the function or parameters of any connected device” (emphasis mine).
First, it is important to point out that even though MDDS’ currently default to class III, the FDA has been operating under their discretionary enforcement policy and has not been enforcing the class III requirements for MDDS. Products that currently meet the MDDS definition have in effect been operating without classification or enforcement; thus the reason for the proposed re-classification. In principle, I agree with the FDA that these types of devices should be regulated, but the question I pose is “why go from class III to class I?” Shouldn’t the classification for MDDS’ be class II?
IEC 80001 – An Introduction
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.
The Problem
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.
Riegel v. Medtronic
On February 20, 2008 the Supreme Court ruled on Riegel v. Medtronic. The patient Charles Riegel and his wife brought the suit after Riegel was injured by a Medtronic balloon catheter during an angioplasty procedure in 1996. The ruling is a clear loss for the tort bar wishing to bring suit for negligent or inadequately labeled PMA devices. More background from the SCOTUS BLOG:
The Riegels’ claims alleged that the catheter had been negligently designed, labeled, and manufactured, that Medtronic was strictly liable for Riegel’s injuries, and that the company had breached express and implied warranties.
Medtronic moved for summary judgment, arguing (inter alia) that the Riegels’ claims were preempted because the Food and Drug Administration (FDA) had approved the catheter pursuant to its premarket approval (PMA) process. The PMA process is codified in the 1976 Medical Device Amendments (MDA), 21 U.S.C. § 360c et seq., to the Federal Food, Drug, and Cosmetic Act (FDCA), 21 U.S.C. § 301 et seq., which substantially broadened the FDA’s authority to regulate medical devices. The specific provision at issue, 21 U.S.C. § 360k(a), provides, with respect to medical devices, that no state may establish any “requirement” that is “different from” or “in addition to” any federal requirement, or “which relates to safety or effectiveness of the device” included in a requirement applicable under the MDA[.]
