After reading the above guidance document I was struck by how it provides such a good review of the quality system regulation (QSR). If you're not a regulatory person and you want to get a high level view of the QSR, and especially how it might apply to wireless medical devices, check it out (updated link).The overall tenor of the document is to point out all the pesky safety things that "should" be done to ensure the safety and effectiveness of wireless medical devices. The term "should" here is, in most cases a "must." As with other FDA regs, if you can provide a written justification for not doing something and the FDA agrees, you're off the hook. Another nice thing about the guidance is that it provides a pretty good list of exactly what the FDA's looking for in a premarket submission or site inspection. Here's a good example of how the guidance document covers all the bases:
Many RF wireless devices use the industrial, scientific, and medical (ISM) frequency bands such as 2.4GHz, and these can incorporate technology to minimize interference and data errors or corruption (e.g., RF frequency hopping protocols). However, wireless coexistence and data latency remain concerns because the data transfer rate can slow slightly or even dramatically with an increase in the number of similar transmitters in a given location. In many cases it is essential that medical data, including real-time waveforms and critical control signals and alarms, be transmitted and received without error.
They're not saying, "don't use ISM:" they're saying do your homework. The engineering problem of quantifying RF and wireless data performance boundaries around a product is not trivial. But you can't design a product without specifications, and of course you have to verify the resulting design against those same specifications. And the comment about the number of similar transmitters is a great catch.First generation WLANs installed in hospitals were designed around coverage, and it took some iterative fiddling, and not a few unanticipated dollars, to provide good coverage as wireless applications evolved. Second generation WLAN designs took into account latency, jitter and throughput in order to support wireless VoIP - resulting in another set of site surveys and a "redesign" of the WLAN. Third generation WLAN designs will take into account capacity, so that the number of wireless devices (COWs, VoIP phones, PDAs, wireless medical devices) that can come together in an area won't overwhelm the WLAN. Some day every hospital will have a wireless LAN that provides top notch coverage, latency, throughput, and capacity - we're a long way from that even today.To better describe the focus of the guidance, let me set a frame of reference.
- A standalone medical device is a world unto itself - this greatly simplifies meeting regulatory requirements. Vendors only grapple with their device (which they control completely), and interactions with the patient and the user. This is also known as "the good old days."
- Adding connectivity to a medical device extends the boundaries of both the product and the regulatory burden. Connectivity is usually implemented using general purpose computing technology that, unlike the medical device, is not completely controlled by the device vendor. Connectivity that integrates the device with hospital information systems, or creates a system for remote surveillance or alarm notification, causes the resulting medical device to touch the customer's IT environment - a major loss of control on the part of the device vendor, and one they try to limit (frequently to the detriment of their product and user). The most common examples are general purpose PCs, servers and LANs.
- By making connectivity wireless the resulting product is exposed to a much broader environment - a busy wireless LAN, and a host of electromagnetic interactions.
Yes, I know - in my world everything is about connectivity. If you look at operating data on devices like two-way telemetry systems one sees that wireless connectivity can be virtually as safe and effective as a wired solution, even if a wired solution should theoretically be safer and more reliable. Achieving wireless performance that is equivalent with wires, however, is neither easy nor inexpensive.In addition to all the specific issues and risk factors noted in the FDA's guidance document (and there are many), consideration of the environment in which the wireless device is used gets surprisingly little attention. You could read between the lines and say that this is implied, but then why write a guidance document?Device vendors' connectivity solutions started out very proscriptive - requiring private networks and specifying exact models/versions and vendors of hardware and software used. As connectivity has become more prevalent, both in the number of vendors and systems in a hospital, and the broader deployment of systems (across major portions of a hospital rather than just a single department or unit), customers have chaffed at the unnecessary duplication and complexity resulting from device vendors' obsessive need to control things.When you go wireless, vendors' control issues become even more problematic. You can't have a "private" 802.11b/g WLAN if there's already one installed in the hospital. Even if your system runs on a VLAN, you have to configure that on the hospital's infrastructure, not the device vendor's infrastructure.So we finally get to the rub - how much of the customer environment must be accommodated in the development of the medical device? The short answer is a whole heck of a lot - especially if you want your solution to support a broad number of hospitals with different environments. Of course things were easier in the good old days for hospitals too, when devices were just standalone boxes with a power cord and connections to the patient. In the guidance document, the FDA recommends the following issues be included in wireless device labeling:
- data throughput
- latency
- integrity
- security characteristics and associated precautions
- need for spectrum management
- limitations on number, output power, or proximity of other in-band transmitters used in vicinity.
The above issues are examples of what must be documented, quantified, verified and validated and managed throughout the QSR - all the way to your CAPA system..The "need for spectrum management" is another nice touch. Most hospitals still have no formal spectrum management function. Hospitals will have to change along with vendors if they're going to be able to create and manage a safe and effective environment and infrastructure for wireless medical devices. The alternative here is to buy proprietary end to end solutions from vendors (where everything is specified, private, and controlled by the vendor). The resulting price premium and unnecessary duplication in infrastructure, not to mention the "lock-in" vendors will exert, will not serve hospitals needs very well.One final bit of guidance on the last page:
FDA recommends you investigate EMI as a possible explanation for device malfunction when no problem is found in a device received for service, particularly where RF transmitters were located near the malfunctioning device. EMD from outside transmitters may be intermittent, and the electromagnetic environment of the service location can be very different from the location where a device malfunctioned. To aid in proper analysis and investigation, we recommend you identify if RF wireless transmitters or sources of EMD that were in the vicinity of the malfunctioning device.
Hmmm, how are you going to do that after the device is back in the plant? Removing the device from the customer site before determining where the failure occurred is problematic - it is impossible to diagnose EMD or network problems with a device in the factory. Having the right product design will be critical to determining the cause of failures with devices that interoperate deeply with the customer's environment. And for that EMD problem, people are going to need one of these.Pictured right is a new class of wireless device: the portable, battery powered, and wireless CereTom CT from NeuroLogica.
Trackbacks/Pingbacks