In this segment we're going to take a little bit of a deeper dive in the FDA quality system regulation. We're going to look at some of the definitions in this document and maybe a little multiplier for some of you, but I think it's important for students to see some of this vocabulary ones just to understand why things are done the way they are done. This is the reason why we do things the way we do because these are the regulations we operate under. This document's a very short document, it's actually seven pages of actual regulations, contains very high-level instructions. You also hear it referred to as CFR 820, Code of Federal Regulations 820, that's where that name comes from. The purpose of this regulation and we're going to quote directly from the document, the quality system regulation inclusive requirements related to the methods used in the facilities and controls used for designing, manufacturing, packaging, labeling, storing, installing, and servicing of medical devices intended for human use. The word I want to highlight here is the word design, the regulation doesn't begin as in the method we talked about last week. Once a thing has been tested, the process begins at the design, and this is an important component of the story. This document consists of 10 short parts. There are seven pages, 10 parts, you can see the list here. We will focus primarily a little bit on the quality system requirements and this process called design controls and is a critical component of the process of developing medical software. The others are also important, and you're welcome to read those on your own. In Subpart B, we have a little bit of a discussion of the requirements for quality system, and we'll explore this topic more in Week 4, when we talk about quality systems in particular. But there are some statements about the responsibility of company management for the overall process, there are procedures for quality audits and personal requirements and training. You can't just have a person go in and code software if they don't have the right training. It's not their fault if something goes wrong, is the fault of the management and so appropriate trainings are recommended, and the organization, and this is the key to the whole thing, needs to take the creation of a quality system seriously and work inside it as opposed to against it. If you think about the [inaudible], they created documentation after the device was designed, thus working against the system. You want to create documentation before the code is written. This is working within the system itself. For our purposes, probably the most important section is Subpart C, this is what's called design controls. The process of design controls is this process of having a system of checks and balances in place, such as when we're designing a device, we following appropriate procedures. Think of the word control as, procedures to check, procedures to ensure. High quality, high risk softwares intended for mission-critical purposes, needs to be designed under, at least in the medical space, design controls. This is what separates research software to some [inaudible] in the university from commercial created software that has FDA clearance to be used for clinical purpose. Was this designed under design control? Did they follow an appropriate process of checks and balances of documentation throughout this process? Let's look at what design controls implies. The manufacturer shall establish and maintain procedures to control the design of the device in order to ensure that the design requirements are met so that what we design actually meets what our requirements are. The manufacturer shall establish and maintain procedures to ensure that formal documented reviews of the design results are planned and contacted at appropriate stages of the device's designed development. Finally, the results of this design review, including identification of the design, the date, and individuals performing the review and approving are documented in something called the design history file, which we'll discuss later. This is the heart of the matter. We have to have procedures for everything, including procedures to review and to document a process. What does the process of design controls look like? The FDA provides us with a schematic. Before we get there, I want to introduce two terms that you'll hear a lot of, the word terms verification and validation. You'll often hear them referred to as V&V, and often interchangeably. Let's just focus on what these towards mean and with those, we'll be ready now to jump into a review of design controls. Verification means that the specified requirements have been fulfilled. It means that our software meets the specification. It does what it's supposed to do. Whereas validation means that the requirements for a specific intended use can be consistently fulfilled. Verification means we design the device correctly, validation means that we designed the correct device, the correct piece of software. With that, you can see this flowchart from one of the FDA guidance documents that cause user needs, design input, design process, design output, medical device, we'll define these terms in the next slide and you'll see that there's a process of review at each of these stages. This is the reviews that we're talking about. Then verification checks the output against the input, so we designed a device correctly, validation checks the device against the needs of the user, we designed the correct device. That's the important difference between those two terms. Now, let's continue this process and look at these terms; design input, design output in a little bit more detail. What is design input? The FDA defines this as the physical and performance requirements of a device that are used as a basis for the device design. IEC 62304 on the [inaudible] help to interpret this as the interpretation of customer needs into formally documented medical device requirements. The customer may tell you, well, I want something that does this. The design input now is your interpretation of this thing into a concrete set of rules that lets you then follow something concrete that you can actually use to design a device. The next step is the word specification. Specification means any requirement which a product, process, service, or other activity must conform. Again, the interpretation from IEC 62304, these are the formerly documented specifications of what the software does to meet the customer needs and the design inputs. The customer needs were able to look at images, the specification says that the software must be able to obtain images from a database and displays it, that kind of thing. Design output is the result of this design at each design phase and at the end of the total design effort. Remember again that this vocabulary is written primarily with hardware in mind. The thing about design output is something that you're going to send to a factory to be manufactured, but for software designer, it's actually often just a software itself. The last slide of this design control vocabulary is we want to look at these words review and history file. Review means a documented, comprehensive, systematic examination looking to all this legal working here of a design to evaluate the adequacy of the design requirements, to evaluate the capability of the design to meet those requirements and to identify problems. These are all legal vocabulary because if something goes wrong, we're going to go back and see what their views were, was this process followed and if not or if bad, who's liable for something went wrong. Finally, there's something called the design history file and this is the compilation of records which describe the designed history of a finished device. This is what would be inspected at the end of the story. To summarize the process of this quality system regulation, the implication here is that in a formal design process, we need formal, signed, dated, and probably archived documents that verify that the process was followed and you'll hear the adage in the medical world, if it wasn't documented, it never happened. This is what we're looking at here. Just as a point of comparison in the last couple of slides of this segment, we'll just switch gears and look at the European regulation. This is the MDR 2017/745. If you remember, the FDA document is seven pages, this runs a 225 pages, a lot more detailed. You can see the sections of the main document. These are the first, let's say half of this 225 pages. It goes from scope and definitions, to placing into market, traceability, something called notified bodies, we'll talk about at the end of this week segment, clean evaluation all the way down. In addition, there are 17 annexes that give details and coverage. The most important are the first two, the general safety and performance requirements and the technical documentation. This gives you a sense of what the regulation is in the European Union, which is the other main regulatory sphere. I mean, we have China, Japan, and other countries as well, but these are the earliest documents in this area. We will return to this concept of quality management systems, quality regulations in Week 4, when we talk about quality management systems in more detail, this is how an organization is organized, is created to create medical software. In the next segment, we'll switch gears, and we'll go from regulation into guidance and we'll look at the early FDA guidance, the general principles of software validation, and we'll catch up to the year 2002. Thank you.
