In these next two segments, we'll work through the IMDRF QMS guidance. We'll do the first three-quarters of it in this segment and then we'll conclude in the segment after this. As usual, we look at their table of contents here, the documents section, 1-4, are just a preamble. In this figure here on the right shows the organizations of the document. Section 5 talks about quality management principles. A couple of pages, just a high-level picture. Section 6 is this outer circle and talks about the leadership and organizational support will come back to it in more detail later. Section 7 talks about life-cycle support processes and now this a longer section, talks about all the things that accompany does things like planning, documentation, configuration, the git, all the things that are common to many projects. Section 8 is the process that I use for the specific project, things like design development, verification and validation, deployment, maintenance, etc. In this segment, we're going to talk all the way to the end of Section 7 and in the next segment we'll take on Section 8. Throughout this document, you'll hear examples from two fictional companies. A company called Magna, which is a Latin word for large and a company called Parva, which is a Latin word for small. The document uses these two companies to show you how you would implement the guidelines in a large company and in a small company, just to generalize the guidelines here. Let's get started. We're going to start with Section 6 and we're talking about the responsibilities of the management and the leadership and organizational support. This divides into two sections, leadership and accountability and resource and infrastructure management. The leadership of the organization is responsible for establishing and implementing the quality management system. The management must ensure the activities are performed to verify the QMS effective and this means internal audits and sometimes external audits. Unless the management takes a route seriously nobody else will, and then we'll have a QMS in theory but not in practice. To discuss these issues, we have another short clip from an interview Rich Wynkoop from Vision 28 to talk about the importance of the leadership in the companies that she has advised as a quality management consultant. There's a couple of types of clients that you can have, a couple of cultures in companies. For instance, a culture maybe, I'm going to just hire the most inexpensive folks I can to take care of this quality business over here because that's not my business. Then there's the type of folks who say we make medical devices, they help people and it's very important that we do it correctly and within the law and they have very large qualities. The first folks really aren't going to be successful in the medical device field and it's all driven by top management because that's what top management expects. In the company where they're very committed to quality, that comes from top management. The company is top management and that's why 1345 and the FDA regulations have very important sections on management responsibility, management review, and management accountability. Unless the management is committed to this work it won't actually happen. Let's talk about assigning responsibility. We're now moving to Section 6 of the document and here are some quotes both Magna and Parva management have responsibility to ensure that the QMS has been established and that the necessary patient safety considerations have been built into the QMS in management and entering the market. Part of your quality management system is to have procedures for ensuring patient safety. In Magna, they have a chief medical officer who's been identified as being responsible for these aspects. In Parva, the software development management is responsible for patient safety aspects. Now, the exact person is not particularly important here, what I want you to know is the specificity, the person who's responsible for patient safety is explicitly named. It is somebody's job, so if something comes up, it is their responsibility to ensure that this had happened, to report up if there are problems. This is a person, this is where the backstops for this particular task. Let's look at some other comments from the Section 6, the leadership of the organization also responsible for the project resource and infrastructure management and they must ensure that people assigned to each task are properly trained. You cannot be assigned a task for which you don't have training and this is part of the responsibility of the management. The environment in which the works performs is also important, have to have the right computers, the right services, their conditioning potentially desk space, all of that makes for the environment that is necessary to create quality products. Moving on to Section 7, now Section 7 is the second section. This is the processes that support the creation of products, of course, the process for running a company, and here's one example talking about product planning. Both companies carry out product planning to decide which operating systems best suit their application. Magna is a large company builds his application, they work of the top five mobile phone operating systems. Parva develops on the platform that is a market leader because it can only do so much. For both Parva and Magna this planning phase can allow each company take deliberate approaches to the assignment of a resource. Now all of this is finally here, of course, is that this token was only five years old and talks about top five mobile app phone operating systems and they're only really two right now. This guidance in their details go out of date, but the principle applies. Depending on the size of your company, you take stock of your resources and you figure out what you can do appropriately so you don't bite off more than you can chew effectively. The risk management comes up and this in Section 7.2 again, the favorite icon at the top left corner there. Software risk management requires a balance evaluation of both safety and security. Magna, being a large company has a dedicated department to ensure that the risk of the products within acceptable limits includes consideration of patient harm. Parva has more hands-on-deck they have chosen to train their SaMD developers in risk management activities. They collectively ensured the risk of the product who using acceptable limits. Again, it has to be somebody's responsibility and those people must have the appropriate training and this is what this section talks. It is interesting also is common at the top this balance of both safety and security. Remember, safety is harm that comes from the regular use of the software, security is when the system is used hacked. The two standard has a common also that you prioritize safety over security, although both are important. Moving down the list here on the left-hand side, you see the red box going down the list here. Document and record control is another critical aspect of software development, it's important to manage and control documentation throughout the life cycles. Documentation does not mean bureaucracy, rather it's the foundation traceability, repeatability, scalability, reliability, all the things that you want in a piece of software. Magna use an established documentation, process and techniques that include the use of a commercially available requirements management tool. Again, big company, they buy a specialist software. Parva essentially uses their source code management system, perhaps GitHub, to enable the company to manage documentation in a controlled way. Again, the exact details are not important, but you have to do it, you have to have a process for doing it. There's an adage in the software medical device industry, [inaudible] if it was not documented it did not happen. If you don't have a piece of paper that says we did something and describes how we did it, it might as well never have done it and so keep that in mind. If it was not documented, it did not happen. The last couple of parts of Section 7 the first one is measurement analysis and improvement. Customer feedback is an important part of monitoring the performance to improve the product. Magna, again, lush company they have a dedicated department that works with sales marketing and product development to formally service large customer base to get insights. Parva doesn't have that luxury, but they invite some of these earlier adopters and customers internal office to contact their round-table discussion to get to the same kind of feedback. It is important to appreciate that this feedback and self-improvement is a critical component of all quality management systems. You have to talk to your customers, ask how the software is working for them, find out what's wrong, check that information and use it to improve your software. Inter-related aspect, we teach students sometimes when they write papers and get reviewer comments that the reviewer is always right. Now, that doesn't mean that what the reviewer says it's exactly what you should do. But the fact that somebody complains about something, reveals that there's a problem somewhere. Now the appropriate solution to the problem may not be what you should be doing. But the fact where there's smoke there's fire, the way they complain about something that means there's something wrong, you should take it seriously. That's an important part of the self-improvement of a company, to create better and better products. The final section is 7.6 in Section 7, this discussion of outsourcing both Magna and Parva use open-source or other commercial off the shelf code is called COTS in this document. Its critical to both to probably verify and validate integration of open source code or other external code. Both companies are responsible for monitoring and managing the potential for defects in this course, as this defect can contribute to the overall risk of SaMD. It's the actual manufacturers responsible for these defects, not the people who wrote potential of the open-source code. Magna and Parva, and this is a conclusion, are ultimately responsible for the safety and performance of the SaMD. They're the manufacture of records, they're the people who stand behind it, they're the ones who are liable should something go wrong and they end up in court, they have to defend their software. With that, we conclude this discussion of the first half of the quality management guidance from the MDRF. In the next segment, we'll take up the second part of this beginning with Section 8 and the actual processes for the product realization itself. Thank you.
