Welcome to Week 1 of our introduction to medical software class. Here we will set a stage for what will come up for the next 11 weeks or so. This week we'll introduce what medical software is. We'll discuss relevant regulatory issues. Then Dr. Likoli, my colleague will come in and talk to you about opportunities in medical software and digital health. That will be the stage setter. Then over the next few weeks, we'll take each of these topics and go into more detail. We have a number of videos. I have seven segments for you this week. The first three are just an introduction to the class and a guided tour of the medical software in two parts. We'll look at each of the stages of the process. Then we'll introduce a regulatory process. The last few segments will be from Dr. Likoli. First, he'll talk to you about the US health care environment, how it works, why it's so expensive? The last segment, he's going to talk about the promise of the digital transformation of healthcare. This is where medical software's potential to redefine how we use health care, how we run health care right now in the United States and around the world comes in. As I mentioned, in every one of these lectures, and you'll see this slide over and over again, where this class is based on a textbook. You can see the picture of it there. This week's material is present, Chapters 1 and 7 of the textbook. We'll start with segment 1. We're going to give you an introduction to this class and tell you what this class is all about, and what medical software is. If you looked at medical software 20 years ago, you will see medical software living in a device like this. This is a radiation treatment machine. This is a device that shoots high-energy radiation into a patient's body to cure cancer. If you have a tumor there, this device, you would send high-energy x-ray beams or other kind of radiation in focus over many days with the idea of killing the tumor, shrinking the tumor, and providing treatment to the patient. This is a software that's part of a device, and this is medical device software, and this is the traditional setting for medical software. Until about 15 years ago, this is most of what we would have thought of medical software was. The next example is what we call software as a medical device. Here there's no hardware. This is just a piece of software that's running on a standard PC. This is a piece of software called Profuse from a company called Eigen. We'll hear from their director of research and development later in this class. He's one of the guests we interviewed. This is a piece of software which analyzes medical images in preparation for prostate biopsy. There's no hardware attached. This is running on generic computer hardware, and the device is the software itself, and we call it a device because medical software when it's regulated, it falls under the category of medical devices. Is not a drug, it's a device. The software itself is a device. A third application you will see is a mobile application or a web-based application. This is MyChart from Epic. This is an electronic health record. This is the user-facing side of electronic health records within the hospital. This allows a patient to get their own personal health information, make appointments, message their providers. Now you can see that we hid here the names of the physicians and the name of the patient just to promote the privacy of the patient. But that's what these things look like. This is a third category, third example. Now, our objectives for this class. First, we want to understand the regulatory process governing medical software because this drives a lot of how we do things. We are in a regulated process, a regulated environment, so the laws are important. We want to learn about the larger environment which medical software lives, how hospitals operate, where the data privacy regulations, the other part of the legislative and environmental aspect of this process. We want to understand the organization constraints inherent in medical software. You don't write medical software in your garage. You have to accompany the software in a certain way with a quality management system. We'll talk about that. We'll learn about critical technical background material. Here we're talking about material from both computer science and math, statistics, probability, machine learning that will help you understand the fundamentals underlying this process. We'll spend most of our time in number 5. We'll learn about the medical software life cycle in some detail. In fact, we'll spend weeks 5-10 of this class mostly working through the software life cycle. Our target audience, here, primarily, we're thinking about students in computer science and engineering with some programming background. Our goal is not really to teach programming here but to teach you how software is developed in this medical context and, of course, current aspiring junior software engineers in the software medical device industry who have the technical skill but do not understand why things are done the way they're done. We'll have a video in the next slide that illustrates this point. In addition to that, people who might find this class useful may be entrepreneurs who are starting a business in this area who want understand the technical details, at least at a high level, so they know how their business is operating. Or people who are senior managers who manage people who manage medical software, people at the higher level, whether it's in industry, academia, or government, who need to have some sense of what this process is and what the pitfalls are. Things they need to be careful about. We're not really targeting somebody who's in charge of a medical software project here. This class would be a good introduction to the topic, but somebody like that will need to follow up with more training, more studying on their own. Help with consultants who are experts in particular details. These are the audience that we're looking for. This is what we will cover. Just to reiterate, we'll talk about the regulatory background. We'll talk about the clinical and business environment. We'll talk about quality management system. This is how companies like that are organized. We'll spend a lot of time visiting and revisiting risk management, the process of ensuring that we do not cause harm to a patient either through the use of a device or through misuse of the device. We'll spend a fair amount of time, and this is the heart of this class, talking about software life cycle processes, everything from understanding the needs of the user, to developing the software, testing the software, installing it at the user sides, all the way to retirement. Then we'll spend Week 11 reviewing all of those topics within the context of these emerging issues in artificial intelligence and machine learning. This is an area that's extremely hot right now and it's redefining how we develop medical software. If we taught this class five years ago, it'd be a very different class. But these technologies are changing how things are. Then underlying a lot of this is how medical software is different from regular software. If your experience is working in a company that does Internet work or webpages or business software, there are some differences in medical software you have to be aware of. To just illustrate this point, we had a video clip and we'll see a number of these clips from guest experts that we have interviewed. You'll find the whole interviews on YouTube, but we'll have clips accepted from those interviews in the slides to just make the point. So I have a clip here from Dr. Saradwata Sarkar who will talk about his experience starting out in the medical device industry. I joined the company in California and I walked in the first day all ready to impress. I was ready to write as many lines of code as they needed me to write. I was all ready to go, all ready to impress. So imagine my surprise. Instead of getting even one single piece of code to write, what I got was one thick binder full of SOP, standard operating procedures. I opened them up, tried to read them, they were completely esoteric. I didn't understand one single word of what was in them or why we even needed to do this. I failed already. That's my first day at work. Every serious software development that is done in the medical device industry happens under the umbrella of quality management system. There's acuteness to follow their standards, to follow their procedures. It's not about sitting and writing a piece of code in front of the computer. That probably does work out in academia because the scope is different, but that's not how it is definitely in the industry. Definitely, like a lot of the serious work that happens for developing any software program or medical software device, happens even without writing a single piece of code. A lot of it happens behind the scenes trying to understand what the user requirements are. If you remember anything from this video or from this slide, is there's a lot of underlying infrastructure that goes into support the creation of medical software. I always tell students what to code is a lot harder than coding. Figuring out what to code is actually the hard part. The environment in which this happens, the quality management system, the risk management, the lifecycle process are all the supporting infrastructure that will ensure that our code is both of high quality, safe, and it does what it's supposed to do. When we look at the lifecycle process, we'll see a number of steps. This is my list there, you'll see different versions, but we start with the user environment format, use cases, down to implementation. This is where the coding happens, the testing phase, and the deployment and ultimately maintenance retirement. This is a set of steps, and how these are combined, either software lifecycle, there are different ways to organize this, and we'll talk about this more in Week 5. What I want you to see is one illustration here. If we take the downward slope here, we're starting from the user and we have to work out all the way to designing our software. The bottom of this ladder is implementation. This is where we actually code. Now if we arrange these steps in a V-like shape, you see that we're going up the ladder here. We're doing testing, verification, validation, deployment. We'll talk what those words mean. This is the origin of the so-called V-model. This is a slide you'll see many times in this class as we walk through the steps. Here in the V-model, the downward steps and the outward steps are paired. The software design is checked by low-level testing. The system's requirements are checked by a process called verification, that our software is operating as we designed it. The use cases are paired with validation. Our software, even though it's been designed correctly, we also have to check if it meets the needs of the user. If it doesn't, we have a perfectly good but useless piece of software. Then the user environment we'll go back to it and talk about deployment, maintenance, and retirement. This is the essence of it. This is an adopted version from original work from Forsberg and Mooz back in '91. You'll see this picture many times in this class as we walk through the step in the process. The other last parts of this introduction here is that we're going to use a lot of primary sources. These are primarily regulatory elements from the US Food and Drug Administration, the FDA, the international medical device Regulators Forum, the IMDRF. We'll introduce both of those organizations next week, and others, the European Union regulations, Chinese regulations, and some regulations from Singapore and the UK as well. In addition to the regulatory documents, the government documents, we'll also look at documents from industry standards. These are from International Standards Organization, the primary tubing, the International Standards Organization, the ISO, the International Electrotechnical Commission, the IEC. But you'll see others here, ANSI, AAMI, NIST, IEEE, and even the German Institute for Standardization at the bottom of that list. In general, if we can do it, we're going to follow more of the regular documents and the standards. Standards are expensive and often inaccessible to students, whereas the regulatory documents are freely available for download. We'll try to use regulatory documents primarily. Just to give you an example, this is if you want to buy ISO 9001, this is a 40 page PDF that's a primary standard for quality management systems. This will set you back $175 at this point. In general, we'll try to use a regulatory documents instead of standards. If you wanted to read the primary standards involvements field, you're looking at whiteboards over $1,000 to purchase them. This concludes our introduction to this class. In the next segment now, we'll take a more detailed look at the process for doing guided tour of medical software. We'll take a more detailed look at the process step by step. Thank you.
