Reader Rick Schrenker, systems engineering manager at Massachusetts General Hospital Department of Biomedical Engineering, and I corresponded recently about a trend in the embedded systems used in hospital settings. His comments are insightful and should have an impact on the way we build networks of systems. I'll quote extensively from his emails:
“Just over a year ago I presented a talk listing some potential hospital use cases for RF-based wireless technologies at an IEEE 1073 meeting. At the end I went off topic to throw in the following tidbit: of the 30,000+ medical devices currently in use in our operation, about 9,000 had software versions entered in our equipment management database. We have somewhere between 1,000 and 2,000 models of equipment in our system last time I ran a query. The system is complex to manage.
“Twenty years ago, I could go to the service manual of any of device in our inventory and determine what it was supposed to do and how it did it. The key, of course, was the schematic diagram. What made it so useful was its use of standard symbols to represent components. The abstractions were consistent across the industry. A schematic from HP for a patient monitor was as meaningful as a schematic from Tektronix for a patient monitor was as meaningful as a schematic from Siemens for a ventilator was as meaningful as a schematic from Baxter for an infusion pump. Based on the schematic and related information, I could train technicians how to provide service to the device, or clinicians how to use it. I could develop tests to verify operation, and I could validate that the device could do what it was supposed to do, even in concert with other devices.”
Rick then complained that we might have UML or other design documents to guide us during development but none of that information flows to the people in the field doing maintenance. His comment “Not only are there no documentation standards, but apparently there are no standards for anything” closely mirrors my experience in working with developers on all sorts of projects. Working code–more or less working code–no matter how badly structured and hacked together, is all that counts. The quality is invisible to the customer and our boss, and only becomes apparent when bugs surface or maintenance becomes difficult or impossible.
Rick went on to talk about the problem of upgrading software in all of these embedded applications, some of which are truly safety-critical. He wrote: “The vision I described at the IEEE and other forums goes like this: hospitals will have a lab with some number of workstations lying around it, each configured to support the update of one or more types of medical devices. Technicians will bring the devices in, connect them to the workstation, magic will happen, and the technician will return the devices to the floor. Hopefully nothing will go wrong, either to the device or in the context of the system in which they are being returned to be applied. After my IEEE presentation, an engineer from a medical equipment manufacturer came up to me to say he'd never considered what it might be like on the receiving end of one of his upgrades.”
Rick notes that his colleagues who actually perform the upgrades report that they may come only with installation instructions; in other words, the instructions may not include a list of changes that were made or a procedure describing a comprehensive test of the upgraded device. Rick has heard of cases where a call to the manufacturer's help desk reveals that tech support may not have the information, either.
Scary stuff. It's tough for us developers to really understand how our customers use the equipment. I've always advocated sending the engineers to the customers' sites, in uncomfortable support situations, because there's no better way to see what the user really needs.
Rick says the FDA is working to address a myriad of issues related to software-based medical devices but believes its ability to address current problems may be constrained by the scope of its authority. One topic he cites that has been kicking around for about a decade is when does a network become a medical device? As Rick understands it, FDA is limited to regulating medical devices, and a network does not meet the strict definition thereof, although it may be a component of or an accessory to a medical device. Medical devices communicating over networks is nothing new, but generally hospitals have partitioned IS and device networks via the use of cable. The advent of wireless effectively does away with this method of avoiding the issue. While Rick admits to not being sure he groks the breadth of regulatory authority in this area, he is concerned that if the FDA is indeed constrained to regulating devices and not systems, then it will become increasingly difficult for hospitals to evaluate the risks they accept in implementing a system. As more and more devices share spectral space, whose responsibility is it—in other word, who will bear the cost and risk–to ensure that the entire mesh works correctly and safely, both in routine day-to-day operations and when subjected to the rigors of software upgrades?
I find it interesting that a network turns even the simplest device into part of a huge system. Change part of it, via an upgrade, and what effect does that have on a connected device or database perhaps in an entirely different ward?
And user interfaces vary all over the map as well. When a harried doctor or nurse needs to adjust some setting that might help or kill the patient, she has to dig through what might be unfamiliar menus–in a crisis situation–to program the device. The patient is crashing and one unit beeps. Just what does that single beep from that machine mean? Oh, it's the same thing as three beeps from the other unit.
Rick recalls seeing an IV pole with three infusion pumps that were being evaluated for user preference. “Not only did each have a different user interface, but I couldn't intuit any of them. Back when I practiced on the floor that was a key criterion for me. There was only so much time for training, and if a device didn't provide at least some guiding context of itself, I found it relatively more difficult to teach. It's even more of a concern today, given the accelerating rate of change in technology. What strikes me as least defensible in all of this is that throughout my life I have been able to go into any auto showroom and test drive a car within minutes, but licensed practicing clinicians almost always require fundamental user training every time they encounter a new model of types of devices that have been around for 25 years. I'm not talking about training for new features. I'm talking about just learning the user interface.”
Rick cites the Institute of Medicine's 1999 report “To Err is Human,” where it was estimated that as many as 98,000 Americans were dying annually as a result of medical errors. “In the section titled 'Why do Accidents Happen?' the report states 'People . . . . become accustomed to design defects and learn to work around them, so often they are not recognized' and 'Accidents are more likely to happen in certain types of systems. When they do occur, they represent failures in the way systems are designed. The primary objective of systems design ought to be to make it difficult for accidents and errors to occur and minimize damage if they do occur.' While the report's scope was much broader than devices alone, the implications for systems that include devices are clear. And the number of what are argued to be preventable deaths is staggering. At the high end, it's the equivalent of greater than two September 11ths every month. Yet five years after publication, by which time the report targeted that a 50% reduction in the number of deaths should have been achieved, one of its coauthors stated, 'The evidence of improvement is indeed unimpressive.' ('Five Years Later, Medical Errors Still a Leading Killer,' Boston Globe, November 9, 2004). And some of us believe it could be worse if not for the absolutely incredible expertise and dedication of the medical staff who compensates for the many inadequately designed systems within and with which they have to work.”
Rick concluded: “This brings me back to the need for technology standards that extend beyond design into application, including maintenance. Ultimately, in the software engineering domain, only the software engineering profession can fix this. Manufacturers do not have incentive to do so, especially with the money to be made in providing proprietary maintenance systems (manufacturers just love service contracts, or as they now call them 'service support agreements', especially when there is so little information available from which to discern alternatives that essentially there is no choice but to purchase them). I certainly hope that your colleagues will address the problem, but I'm not hopeful, at least in the short term. As much respect as I have gained for software engineers in terms of the nature of the fundamental technical problems they address, I am concerned at how little attention I see them giving to life cycle systems issues. My sense is many if not most are so focused on the technical that they rarely if ever stop to consider the breadth of impact of their products.
“A profession arises from the application of technical expertise in service to social interest. Software engineers may construct good, useful artifacts, but if they want their profession to rise to the level of others, they have to address issues like these.”
I agree. We need to think about much more than the code. We're developing systems of unimaginable complexity. How will our customers use, maintain, and support this equipment?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He's conducting his Better Firmware Faster seminar in Austin and Baltimore in April. Contact him at . His website is .
Right on, as usual. If you want to read an interesting book about the practice of surgery, get “Complications”.
As part of the book, he details a brief history of anesthesiology machines, and one man's quest to find out why so many patients were dying in surgery.
Inconsistent user interfaces on the machines that anesthesiologists use to keep the patient alive during surgery.
– Ralph Hempel
I hear what you, and mr. Schrenker have to say. but software engineers are not going to solve the problem for the simple reason that any solution will cost money.
Money is handled by executives, and they hate spending enough to get working products, let alone enough for the kind of changes that are required. They will only change if they have to in order to sell their products. If the FDA can't set standards, maybe E.U. will. They already force us to provide GUIs in the native language of the countries we sell to.
My point is you and Mr. Schrenker should quit addressing engineers, who don't have the power to make those changes, and start addressing government bodies that do.
– William Ames
Doesn't IEC-61508 address software lifecycle guidelines for safety critical software? OEMs in the auto industry have rigorous procedures for reviewing and releasing safety critical systems (braking, occupant safety, etc.)for production. While the OEMs are not the end users, they perform a gating function that requires products that reach the end users to have common functionalities and features (ref. AUTOSAR October 2nd 2003 embedded.com). Is the same concept feasible in the medical field?
Disclaimer: I work quite closely with Mr. Schrenker and share much in common, especially with his views expressed here.
Mr. Ames points out that software engineers aren't the only factor in finding a solution. While true, they are probably the most important part of the problem addressed here – they write the code that needs to be written correctly the first time. Rick and I both meet with and talk to company executives and government officials on a fairly routine basis. Both groups are just as constrained, in their own unique but different ways, as software engineers. We don't expect any of these groups to solve all the issues by themselves, but we do believe it possible to bring a safer version of their products to market when these groups work together.
The need for Mr. Schrenker's comments to be heard are exemplified by Mr. Ames' comment, “any solution will cost money.” Rick and I both realize this and would gladly pay more money to get a safer product. What we want software engineers, indeed ALL engineers, to understand is that while it cost money to design better products, design errors cost much more than the amount initially saved. And when it comes to medical devices, it isn't just money at stake… it is often the lives of our friends and relatives.
To address Mr. Ames' final point, and Joe's message as well, single point “solutions” such as reliance on government or standards alone has proven to be insufficient to address many problems. Governmental agencies have constraints too, and standards development often lag the market place significantly. My point is that irregardless of other needs, the old excuse, “It isn't my job!” just doesn't cut it here. We are each responsible for our part of the problem to be solved.
– Rick Hampton
Great article, Mr. Jack. Best you've done in months!
Some of us develop more than just software for products. It's important to keep issues like these in mind as whole product line schemes are considered, etc.
– Greg Feneis
Why can't there be an industry – government partnership, like RTCA (Radio Technical Commission for Aeronautics) — Where an industry and government commission comes up with standards for equipment and software, that are then adopted by the FDA as equipment standards, system standards, or development standards. RTCA has come a long way in improving aviation safety in the air transport industry, and could be a model for this type of co-operation in the medical device industry. ARINC also serves as an additional standards body, and I am quite suprised there is not such a body in the medical field — setting standards for common equipment and interfaces. While each of these items would be an expense, it would be offset by lower costs in terms of medical errors, life insurance payouts, etc, and be the responsible thing for the medical industry to do, plus help save Dr's, Nurses, etc from stress related burn out.
– William Murray
Jack, I hear what you, Mr Schrenker, and Mr. Hampton are saying. Mr. Hampton's summary is that “'It isn't my job' just doesn't cut it here.”
But please keep in mind that, unless there is a customer requirement that sales needs to meet, engineers can't start adding design time for quality to the schedules. In today's atmosphere, if we don't meet the unrealistic, quality-free schedule, we won't HAVE our jobs any more. “It has to be ready in time for the trade show” is more important that “it has to work right.”
How do you combat that short of raising the standards for what the customer will accept?
On a slightly different note, there is a broader issue highlighted in our not releasing schematics or source code (the open source community aside). Competition has become so fierce that industries like mine, which used to thrive on basic research published by industrial research labs, now hide our discoveries behind trade secrets and patents, hoping that our “me too” product will stay 15 minutes ahead of the competitor.
Rather than contributing as a community to the laying of a foundation that allows us all to see further, we are busy lobbing bricks at each other and trying not to get buried by the ones falling around us. Battles between different standards and techniques keep us from taking the best practices and improving our entire discipline.
– Greg Nelson
After some checking, it appears as though the IEEE handles some of the standards for medical device development — At least where there is electronics and software. A good first place to start for the issues in the article would be to modify the IEEE standard 730 to call out more explicitly the type of user documentation. Software maintenance documentation, and return to service procedures could also be spelled out more explicitly. This would help every industry that used the standard.
I still feel that there may be a need for an organization that involves all of the stakeholders in the medical device standards process — so far I've only found the MDMA (Medical Device Manufacturers Association) which apparently may not do standards.
This might be a starting place for a spin off that does do standards.
– William Murray
A) IEEE 1073 is the Point of Care Medical Device Communications Standard.
“Doesn't IEC-61508 address software lifecycle guidelines for safety
There is also FAA RTCA/DO-178B, ISO/IEC12207, UL-1998 and many others.
The best introduction to Software Safety comes from the Food and Drug
Administration, in their document “General Principles of Software
Validation; Final Guidance for Industry and FDA Staff”.
You can download the Mining System Safety Evaluation Program
guidelines based on IEC-61508 for free, unlike IEC-61508 and UL-1998,
to learn what is required to design a safe system. [Disclaimer: I am
on the committee writing the Mining documents.]
You can find links to all of the above at my site http://www.softwaresafety.net/ .
The March-10th Risk Digest points out that
“Hospital computers make things wores [SIC]”.
The reports appear in the March 9 issue of the Journal of the American Medical Association.
“Doctors, nurses and office staff were often frustrated, the
Pennsylvania team found, with frequent system crashes and maintenance
shutdowns that could take hours. And computer-based communication
between pharmacies and the hospital was often problematic and helped
lead to inaccurate dosing of patients or improper and potentially
harmful gaps in drug treatment, the study found.”
“In some cases, staffers said they needed to go through up to 20
screens to find a patient's full medication record, according to the
– Bob Paddock