CSCI 8970 – Colloquium Series – Fall 2010 – Sixth Event
Safety, Security, and Reliability in Medical Device Systems
Monday, October 18, 2010
Presenter: Dr. Mats Heimdahl
Dr. Mats Heimdahl lecture dealt with the concept of safety and the difficulties at times of development software that will understand both situations and exceptions to situations. Unfortunately, as a result of human error and at times of poor planning and software/hardware development lives have been lost. It is Dr. Mats Heimdahl to engineer systems that prevent this from happening, as such the University of Minnesota Engineering Center current received a 5 million dollar grant to improve the safety, security and reliability in Medical Device Systems.
Dr. Heimdahl career as a software engineer began with the desire of being part of something cool. In 1984, Graphic interfaces and GUI was the top of the line technology. Yet, overtime he developed an interest in improving software to increase their safety. He mentioned how while at times accidents are the result of negligence (such as being sucked into a jet engine <- the most common cause of death in airports), other times it is the result of poor program design (Therac 25 radiation therapy machine is one of the most commonly cited examples). He gave examples of planes that crashed and exploded despite the software operating properly and the equipment having safety mechanism. Unfortunately, the software did not function properly during a rough winter in Poland and the plane kept going after touching the ground and bursted into flames. In another occasion, a plane “adequately” prevented a pilot from raising the plane after the pilot had entered landing mode by flying close to the runway. The software engineering department works on solving these types of problems primarily with the FAA and and FDA. Currently most of his graduates are hired by the FDA and the medical industry.
At times problems in the medical industry are the result of “widespread ignorance” but another major problem had been the growth of complexity. A company closed down when they were preparing to submit a new [critical device with various real-time constraints] device for certification, but had developed their software using Visual Basic under Windows. They had no clue about the limitations of Visual Basic. Another company built a large medical device controlled by a PC but forgot to place an emergency stop red bottom. Later, instead of putting the red bottom in the machine, they placed in the computer (Red Bottom was in the computer only). Luckily that system turned out to be fairly simple in terms of electric power and the system could be shot down by simply cutting down the power.
Other problems, such as surgical fires are significantly more complex. Over 500 fires with horrific burns are caused every year when surgeons accidently sever the oxygen tube and creating a combustion. Surgical team must remember to reduce O2, but are regularly forgetting. Despite a proposal to fix these problems, the multiple interest from various companies delay the implementation of reforms.
Another problem that could be solved is the communication between the patient condition in relationship to the height of the bed and the blood pressure meter. Hundreds of accidents happen every year, where they think that the blood pressure goes down, when it is only a change of relative high and a question of physics. According to Heimdahl, every physician in the emergency room has made this mistake. Heimdahl also promoted the meet for the pacemakers and the MRI to communicate.
Some hospitals have tried to visualize the future and the integration of equipment by creating pilot and simulation models. Massachusetts General created an Operating Room (OR) of the Future where they are having a large number of problems in increasing the comprehensive integration between clinical and non-clinical devices. Some suggestions to improve OR room of the future include: Workflow support that closes the workflow loop, smart alarms requiring contextual awareness, and safety interlocks that require tight system integration
UMN’s project overview includes building a language to work in a clinical scenario, working on some form of network to monitor what is really going on, control what is really going on to help us out. In addition, apart from trying to solve problems that originate out of human error, the program is also exploring how to prevent individuals from hacking the program and holding it ransom. Someone could kill someone from far away, and blackmail the hospital <– Give us 50 million or we will kill some of your patients.
Other challenges for tomorrow include preparing products for sale by focusing on evidence based certification, which includes identifying the potential failure modes of software which can give rise to, or contribute to, hazards in the system context. It is also important to develop a safety case. Increasing security also encourages the question. How much security is enough? “We can never make it completely security” Because of this large array of questions and the extensiveness of the program, software engineering will be recruiting a large number of students for its projects during the next few years. They currently have a large staff working in this project, but they are looking for more people. Maybe I could help in one way or another. It is definitely and interesting project.
Colloquium Notes
“The goal of an engineer is to retire without having caused (being blamed for) any major catastrophe”. – Dilbert 🙂
Dr. Mats Heimdahl
Professor
Director – University of Minnesota Software Engineering Center
PhD from UC Irvine
University of Minnesota Software Engineering Center [UMSEC]
Anything you want to learn about engineering you can learn from Dilbert
Safety, Security, and reliability in Medical Device Systems. (5 million dollar project)
Program is just ramping up, and they are looking for students to work in the program.
“When I started in CS, I wanted to do something cool” <– 1984 – Graphics, GUI was cool
1984 – first movie to use computer graphics – The last Star Fighter
1977 – Starwars used miniature models.
Most common cause of death in Airports, is being sucked into Jet Engines.
Some reason get hurt because they are stupid.
Therac 25 – A radiation therapy machine
The program radiated cancer patients too much, and some died horrific deaths.
Therac 25 – had poor hardware and software.
The FDA did not do their job – everything was screwed up.
A student wrote a 25 page paper of how everything was messed up – will not ask that problem again
He decided reducing software problems more important… way cooler
We are not that good or that bad, developing software.
When they touch down, they gun the engine. — without those, the air plane cannot stop
Thrust reverser details have various mechanisms to prevent it from closing accidentally
As a result, you have a number of sensors to prevent it from closing erroneously.
It went well until they failed in Poland:
There was too much snow, and the plane did not record that it touched ground, so it kept going, crashed and busted into flames.
We need to understand much much more to get the software right.
Sometimes the programs work well and they contribute to the accident happen.
Software switched from descent mode to landing mode.
The landing mode software prevented the pilot from raising the plane
Yet he hit the override bottom but it was too late and crashed into the trees.
What is safety?? – freedom from accidents and losses.
Software is not dangerous by itself.
It only harms people when it is interacting with the physical world.
He is interested in the cyber-physical systems.
Research group focused on airplanes – regular by the FAA.gov
Also works with the military and the FDA (and medical devices)
Reasons why things do not work…
-Because people are stupid… Widespread ignorance
“We are preparing to submit our new [critical device with various real-time constraints] device for certification. Our software has been developed using Visual Basic under windows, do you have any advice on how to best prepare our certification package?”
-They had no clue about the limitations of Visual Basic
A company did a fairly big medical device controlled by a PC, but they do not have an emergency stop red bottom.
They instead of putting the red bottom in the machine, they placed in the computer (Red Bottom was in the computer only)…
And the system was simply.. All you had to do was cut down the power.
Yet the company did not understand that all they needed was a 5 dollars fix.
Surgical Fires
-Airway Laser Surgery + O2 –> Bad News
O2 in breathing gas supports combustion
If laser hits breathing tube, could produce burns. (surgical laser)
Surgical team must remember to reduce O2
Yet 500 of these fires happen <– they get horrific burns
Yet things could easily be fixed by reducing the O2 level to under 25%
Proposed and published by Goldman in 1999, but it is not commercially available.
Now a political problem, but unfortunately, this is really important.
Intravenous Blood Pressure
Should the bed talk to the blood pressure meter
Hundreds of accidents happen every year, where they think that the blood pressure goes down, when it is only a change of relative high and a question of physics.
Every physician in the emergency room has made this mistake.
Defibrillator and MRI and Pacemaker.
Defibrillator shocks the heart to get the heart back into rhythm.
Pacemaker makes the MRI think that there is something wrong.
They shock the person needlessly.
They also forget to turn the pacemaker on.
Massachusetts General: Operating Room (OR) of the Future
- Build an operation room where everything talks to each other. <– unfortunately, they are having a lot of problems.
Lessons from OR of the Future Project
-Comprehensive integration between clinical and non-clinical devices should provide
-Workflow support that closes the workflow loop
-Smart alarms requiring contextual awareness (for an alarm to know when it is a nuisance and when it is not, it needs to take into account the context)
-Safety interlocks that require tight system integration
-Not limited to the OR
-ICU,ER, home, etc.
Project Overview
Build a language to work in a clinical scenario
Working on some form of network to monitor what is really going on
Control what is really going on to help us out.
You will have a number of devices, so how will you know when they are safe, and how they interact.
There is a lot of stuff, and if pieces are not understood and how they work together, then there will be problems
If this puzzle is solved then the FDA, the Medical Industry, and Doctors will support the initiative.
Some of this is going to have to be done on run time.
You have to worry about people screwing up accidently or hacking the program.
Caregiver –> Supervisor (connected with the data logging) –> Network Controller (also communicating with an external network) –> Devices (1, 2, 3 and adapters) –> Patient
Working together with Penn State University.
It will require some middleware.
Security issues to prevent hacking.
There was no protection for pacemakers – since they wanted the battery to last longer.
Someone could kill someone from far away, and blackmail the hospital <– Give us 50 million or we will kill some of your patients.
Certification – How do you get it ready for sale
Today, process based
-Follow these steps and hope for t he best
Tomorrow, evidence based
-Identify the potential failure modes of software which can give rise to, or contribute to, hazards in the system context.
Develop a Safety case
Certification Challenges
-Need for clinical studies to show it is effective and its safe.
-Shop a panel filled with cronies and hide data to obtain certification.
How much security is enough? – We can never make it completely security
Car Industry – often you do not see computers in there.
None of them are called safety systems – they are called driver assist system
They assist, not help prevent because they would be sued.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>…
Data Intensive Systems
-Doctor and hospital have a prescription, a print out –> the nurse double checks (if it is right, then gives it to the patient)
-The nurse checked, but the technical support office said this is ok, but after they got more glitches, they told everyone to stop
A bug, the database was off by a couple of slots.. – there were no manual records of the database
Nurses had to find the data they had from yesterday (the trash can, papers on desks) — No one got hurt, but it signaled a problem.
Automation can be problematic.
Someone that wanted to cause mayhem could do it.
They have a large staff working in this project, but they are looking for more people.
