Welcome to Week 2 of our introduction to medical software class. Our focus this week is going to be on the regulatory aspects of medical software. How are the regulatory agencies regulating software? What are the procedures one must follow? What is the process that they follow? Some emerging issues when it comes to things like artificial intelligence and machine learning. This is the goals of this week lectures, we'll discuss the history regulation, the history of the Food and Drug Administration in the United States a little bit. We'll review some key regulatory documents, we'll describe the current regulatory process, primarily in the United States. We'll take a little bit of a look at both the process in the European Union and China. Then at the end we'll have a short discussion of emerging issues in artificial intelligence in machine learning. This is the outline, these are the videos we'll have. The first video is the mission and history of the FDA. The next two deal with the old regulations, the quality system regulation, and the general principles of software validation. This will take us to about 2002. Next, we'll take a look at these documents from the International Medical Device Regulatory Forum on software as a medical device. This regulation comes out in the last decade, 2010-2019 or so. In the last two segments, we'll do a quick overview of the regulatory process and we'll talk a little bit about a emerging issues in artificial intelligence machine learning. Again, we'll pick up the thread on those, in Week 11, we'll revisit this topic. As we'll mention every week, in this class we follow the textbook and the material for this week is based on Chapter 2 of the textbook shown here. Our first segment, we're going to talk about the FDA and software. What is the history of the Food and Drug Administration, and how it progressively got interested in software. We start looking at food, then the drugs, then devices, and then eventually software as they understood what the risks to people were from all of those things. If you go back a 120 years ago, there were almost no rules about any of these things, and progressively this area became highly regulated and we have to have rules, we have to follow certain procedures before we can access the market. Before you can enter the market for any of these things, you have to get market clearance or market approval, those are vocabularies. You'll hear words like pre-market; what you have to do before you enter the market, and regulations post-market; the rules you have to follow once you have a device or piece of software that is on the market. Let's look first at the mission of the FDA. This is from the webpage, the Food and Drug Administration; this Paragraph 1 of the mission statement, is responsible for protecting the public health by ensuring the safety, efficacy, and security of human and veterinary drugs, biological products, and medical devices. Those are the three categories, incidentally. Software is a medical device, and by ensuring the safety of our nation's food supply, cosmetics, and products that emit radiation. The three key words, we'll come back to this over and over again, and this triptych of efficacy, safety, and security. Efficacy, the software must be effective in achieving the claims made for its intended use. This is a piece of software that lets you measure tumor volume in MRI, efficacy means it's doing it well. Safety means that use of the software does not expose the patient, or the user to any undue risk from its use. This vocabulary is more from the perspective of a hardware device. When it comes to software, a lot of this comes under the rubrics of usability. That the software is designed in such a way that the user does not make mistakes in using it that lead down the road to issues for both the patient primarily here. The next element is security. Security is that the software is designed in such a way to protect patients and users from unintentional or in malicious misuse. In the software space, the primary consideration here is cybersecurity. We'll talk about this, and anytime we talk about any of these in a design, we'll talk about efficacy, safety, and security. How does our software achieve those three thing? We'll come back to these words over and over again. Again, a reminder that not all software is subject to FDA regulation. This slide we saw in last week's lecture; software for administrative support of a healthcare facility, for maintaining or encouraging healthy lifestyle, to serve electronic patient records, transferring storing, converting or displaying data, and to provide certain limited clinical decision support. It's not a medical device, is not regulated by the FDA right now, although again, the lights may shift so you have to keep an eye on things. The history of the FDA we're following the article from the webpage by JP Swann, to use his citation at the bottom, starts with the Food and Drug Act of 1906, and this is concern about the addition of poisonous food additives in food products and hence the Food and Drug Administration not just a Drug Administration. The next major landmark is the Food Drug and Cosmetic Act of 1938. This was a problem with an antibiotic, Elixir Sulfanilamide, and this used a solvent which was very closely to antifreeze and this result in the deaths of over a 100 people. This legislation expanded the FDA scope to cosmetics and therapeutic devices, and it authorized factory inspections and audits. This is an important part of the FDA's purview. They visit all these facilities unannounced sometimes, as we'll hear in the next video clip, to make sure that they follow appropriate procedure. So here's a clip from Mr. Rich Wynkoop from Vision28, who'll talk about FDA audits in his experience with them. Every three years, by policy, FDA is supposed to inspect every medical device company. Well, there's more companies than there are inspectors, so every three to five years, depending upon risk and your complaint activity with FDA, you can expect a visit from FDA to audit your establishment and products to see if you're in compliance with federal regs. Generally speaking, they will call you up and tell you when they are coming. By law, it has to be during normal business hours. If they say we're going to come on January 31st and you say, "Well, that's not convenient for me.", they will say, "Sorry to hear that, we're coming on January 31st.", because they don't want you to fix any glaring things, but they just keep their schedule. But they don't have to call you. I got a call one day and it said "Rich, there's two FDA inspectors at our front desk.", and I went down and I had an audit. They do not need to give you pre-notice. The next step in the history of the FDA is extension value to drugs officially now, and this happens in 1962, there was something called the Thalidomide disaster. This was a mild sleeping pill that was safe even from pregnant women. This was primarily sold in Europe, it was not on the market United States, and this resulted in tens of thousands of children born with related disability worldwide. The pictures are gruesome, so I will spare you, but if you Google for that, you'll see what I mean here. At this point, Congress required drugs to get approval from the FDA before they get to the market. So this is the pre-market approval for drugs that we had talked about. The next step is now how we get to devices, and you can get to, here see the pattern right, all legislation, all regulation moves from problem to problem. Something goes wrong with a drug, we have drug legislation, something goes wrong with a device, we have device legislation. Something goes wrong with software, we now regulate software. This is the history of law from the beginning of time, you can go back 4000 years. Law is reactive, something goes wrong, you come up with laws and procedures to ensure that it doesn't happen again. If we look at this case, the causal event here was the Dalkon shield this was an intrauterine contraceptives, as you can see a sketch of it up there. It was a long-term contraceptive. By 1974, about 2 1/2 million women used this thing, and use of this device resulted in pelvic inflammatory disease, damage to reproductive organs, sepsis, which is blood poisoning, infertility, sterility, miscarriage, and even death, and this led to Congress passing the Medical Device Amendment which now requires pre-market approval for medical devices, not just drugs now, but medical devices. So far we're talking about hardware. The event that brought software into this picture was the Therac-25 accidents. The Therac-25 accidents, and what you're seeing here is a picture of radiation treatment machine, and the reason we use the radiation treatment device as a picture, you'll see this picture multiple times, is because this is the origin story of medical software regulation. So Therac-25 were radiation treatment machines. Remember, as we talked about last week, these deliver high-energy radiation to treat tumors. Due to bugs in the software that was driving this device, a number of patients, there were six documented cases who received abnormally high doses of radiation resulting in serious injuries and deaths before the problem was identified and corrective actions were taken. This case is the origin story, this is where a lot of the regulations come from that govern medical software. You'll hear echoes over Therac-25 over and over again as we look through these documents. The Therac-25 machine, the best report, the best investigation comes from this paper by Leveson and Turner, in 1993, they performed the initial investigation of these accidents, and then Nancy Leveson, who's now professor at MIT, wrote this book, Safeware System Safety and Computers. In Appendix A of this book, which you can find online from her webpage, she gives a more detailed description of what happens. These are highly recommended and important documents to look through. What else could happen in the Therac-25? Let's look at the design of the Therac-25. The ferric 25 had three modes. You could output electron radiation, X-ray radiation, or field-light position. Electron mode, this is radiation that doesn't penetrate deep into the body, is used for surface tumors. X-ray mode, this is radiation that goes deeper into the body for deep arterioles and fill that position. The system just output visible light and it's used to help place the patients so that the radiation is going to the right place. You can almost think of this as an early virtual form of augmented reality. You put a light on the patient, you move them around so the beam is where you want it to be, and then switch mode and you apply the radiation beam for treatment. The problem here comes at the X-ray mode, uses a 100 times more energy and it's hazardous if you directly expose the patient to X-ray mode. What the device does is that it use a piece of hardware called a flattener to absorb most of this radiation before it go to the body. In a previous version of this [inaudible], they were electromechanical interlocks to ensure that the flattener was there anytime you were in X-ray mode. In the ferric 25, they removed this interlocks and they used software to ensure safety. Problems with the software allowed this X-radiation to go directly to the patient resulting in this injury. If we look at this picture from the original relevance and paper, the radiation comes from above and you see this 10 table here, this rotates here. There are three pieces that can go in front of the radiation, there is the electron focusing mechanism, there is the beam flattener for X-rays, and there's a missal mirror for visible light. If your radiation from above is electrons, you want this part to be in front of the beam, if it's X-rays, you want this part to be in front of the beam, and if is visible light just need a mirror so the light goes through and you can see where it's supposed to go. The problem happens if the rotation of this table is out of sync with the energy that's coming down, and in particular, if you have extras coming down, but this absorption devices shelter flattener is not in front of the beam, then this raw high-energy radiation go straight to the patient and this is where the injuries happen. We'll have a case study presented by one of the students at the end of this class that gets into the history of this in a little bit more detail. What are the factors that led to this disaster? This is from the investigation from [inaudible] the first was over-confidence in the software. There was no defensive design, they were under realistically assessment, software always worked up to now, so we don't have to worry about software. There was complacency. The priors versions of this device were saved. People thought, well, we know what we're doing here, we don't have to worry about it. There was inadequate investigation of follow-up on accident reports. When these people got phone calls from the side saying, well, we had some issue with the device, they never really followed [inaudible] any appropriate way. The other factors, now we get into the more technical issues, there were requirements in the design documentation was written as an afterthought. After the device was create then documentations were written us if there were used? That's a problem. The process was not really followed. There was no quality system in place during the design or the development of the system, and now you can hear why column malfunction was so important. The user interface was confusing to the user and the error message were cryptic you saw things like malfunction 54, but no user was ever taught what malfunction 54 meant, there was just something wrong. There was inadequate software engineering. The design was overly complicated and that's a common problem. Only system level software was tested. There were no unit levels testing. The smaller parts of the software were not really tested and there were errors lucking there, as we'll see when we discuss the general principle software validation document and the importance of all of this testing. Finally, and this is the most surprising of the issues, there was software to use, so they use code from a previous device with minimal testing. But the thing is that the software that was safe in one environment may not be safe in another environment because there may have been late and backs that only manifest themselves in the new environment. The conclusion from the relevance on work in this investigation was that, safety is a really quality of the system in which the software is used, is not a quality of the software itself. Rewriting the entire software in order to get a clean and simple design, may be safer in many cases. In this course, again, the commonly thought view software, you don't really want to have to reimplement, anything that works. In certain mission critical situations, you will be better off starting from scratch, just because stuff that may have worked in one environment does not work in another. This concept of safety being equality of the system, just to give you another illustration, consider two chemicals, each of which is perfectly safe in isolation, but when you mix them, they are no longer safe. The software by itself may be safe, but when running on this particular hardware, maybe something in the hardware that causes you problems. This type of arrangement will also come again into practice. At the end of this course, will talk about machine learning, where we now have machine learning software that you have to treat as unsafe component, that you have to put other safeguards around it to make sure that when it goes wrong, it doesn't cause downstream effects and harm to the patient or the user. This concludes this discussion on the history of the FDA and how the regulations came to be. In the next segment, will look at the actual regulation itself from 1995, the quality system regulation. Thank you.
