AAMI 2008, San Jose, Day One
Clinical Engineering Symposium
The theme of this year’s Clinical Engineering Symposium (and also the title) is: Capturing the Heart and Mind of the Clinician — The Art and Science of Human Factors for Medical Systems.
Ed Israelski, the Human Factor Program Manager at Abbott, talked about the application of human factors to the design of medical devices. He presented a basic framework for incorporating human factors engineering (HFE) into the product development cycle.
He noted that the importance of developing quantified usability objectives, and through testing prototypes (both product models and user interface simulations), to improve usability and safety through design iterations.
The FDA design history file is required to include HFE in the design process, but does not proscribe specific methodologies for implementation. Consequently, most HFE efforts in medical device product development are very limited. You can read more, including a survey on medical device vendor software engineering methods, in this report (scroll down to the sub head, A Survey of…) from last year’s conference Improving Patient Safety through Medical Device Interoperability and High Confidence Software.
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.
Selling Connectivity – Sales Strategy
Selling anything starts getting serious when it comes to qualification. For you non-sales types, qualification is an assessment of the likelihood of making the prospective sale. This assessment includes the following basic questions:
- Is the potential buyer or prospect really going to buy anything – from anybody?
- Will my product be a serious contender for the sale, or am I simply cannon fodder to help justify a sales process with a foregone conclusion?
- And if I am a serious contender, how does my product match up against the competition relative to the specific needs of this prospect?
- Who all is involved in making the decision of what to buy? (More on this in a future post on Selling Connectivity)
A common problem in markets where connectivity is new or dramatically innovative is avoiding prospects who are more interested in being educated than really buying anything. In situations like this, sales reps can get appointments to talk to prospective buyers very easily because they all hope to learn something interesting. The problem is that few of these prospects intend to buy anything, thus taking valuable time away from actually selling stuff.
Sales Strategy
The solution to this problem is an effective sales strategy. A sales strategy is like a cook book recipe that details precise steps that result in a successful sale and satisfied customer. A good sales strategy describes the quickest and most reliable process for starting with a prospect and winning the sale. Effectively selling connectivity and overcoming the qualification challenge requires a good sales strategy.
Medical Devices: To CE, or not to CE?
In my last blog post, I explained that:
- Mobile medical devices must establish and maintain secure Wi-Fi connections in environments that present challenges to wireless connectivity
- Most of the Wi-Fi functionality of a mobile medical device is supplied by the Wi-Fi radio device driver
- Reference drivers from Wi-Fi silicon providers are designed for mainstream devices such as laptops, not for medical devices
- Customizing a Wi-Fi device driver for a medical device requires the skills of an experienced Wi-Fi driver developer who has source code for the driver
- Obtaining driver source code can be difficult, and experienced Wi-Fi driver developers are in short supply
The primary options for a medical device maker are:
- Find a Wi-Fi client radio with a driver that works (well enough) on the medical device
- Hire an employee or contractor, or work with a contract development shop, to customize a driver for the device
The decision on which option to pursue often depends on the operating system that runs on the device.
