In this segment, we're going to conclude our view of this guidance from the and direct discussion of quality management systems as a whole. We are in the last section and this is some realization and use processes. These are process for creating a specific piece of software as opposed to the generic infrastructure of a company for creating products of this type. This follows what is called the standard waterfall cycle. We'll come back to this more next week, but this has sequential process of going through the steps and these alludes strongly towards IEC 62304, which again we'll discuss next week, which is the international standard for medical software lifecycles. QMS and life cycles are closely related, they're both ways to organize how we do things. In fact, the IEC 62304 assumes that you have accumulates in place otherwise, none of those structures make sense. Each section in this section 8 is divided into two halves, patient safety and clinical environment considerations and technology and systems considerations. We are dealing with medical software. So, we're both medical this is this part and software, which is this part. This is the unique world that medical software lifting off to worry about the patient aspects and the technology aspects at the same time. If we look at the IMDRF and lifecycles, this is the steps in the creating of a software packaged requirements management, design, development, verification, validation, deployment, maintenance, and decommissioning. This starts from figuring out what your user needs all the way to the time when the software comes to the end of life. The document has comments about all of these things we're only going to talk about the first part here will pick up the thread with the other components as we discussed them in weeks 5 through 10 of this class. Requirements Management, the definition of mentors of requirements are important, ensuring that the product meets its intended use. Magna has a big company game, cross-functional product team leverage existing document templates, there are many of those, you can find them online and from consulting companies to capture requirements and existing document review process Parva, it is an important point that you screenshots, sketches and rapid prototypes to refine and capture the product corners for the saMD features. In both cases, the requirements are captured in a way that assures that user, patient and regulatory requirements are satisfied and met. Now, this is an important point here. A successful piece of software when validated, meets the needs of the user. So, unless you know what the needs of your users are, we cannot have a successful piece of software. To conclude this discussion about quality management systems have a couple of more comments, type slides. These are beyond now the guidance. The first step, acumen should be a helper, not a hindrance. You should provide structure to what you do. There's enough flexibility within this to do things in different ways as we've seen from magma and Parva. You just have to do things, but you won't have to do them in a specific way so long as you satisfy these requirements. We have a clip here from Dr. Phan Luu from the brain electrophysiology laboratory is going to talk about what QMS is and has some advice for students getting in this area. Sometimes the reaction to a quality system is that it can be owners. It could be too much. It's distraction from your work. It should help you work, it should help you organize, it should help make things visible. If there is a failure, it's more in the management of the system rather than the system itself. Again, because the system is flexible enough to be a adapted for the way that the company works, the culture of the company while still meeting the intention of the quality system. It's a tool that should be used to help you and not be too worried about or shouldn't be seen in a negative light. I would say this as well to the extent that you can pick it up and make it part of your skill set. You're going to be very valuable in the job market for any position you applied for. One of the problems called the management systems and of course the people who implement them and apply them can sometimes be a little bit too rigid and try to follow it to detail and this can snuff out some of the issues. One of the problems we have to deal with often is that we don't know what we should be doing. We need to experiment and experimentation and a column managed system construct be in conflict. We know for example, that for software be of high quality must be cleared with inequality culture called the system and experimentation accumulation are often incompatible sometimes you just need to figure out what might work. Let's try things. When you're just playing around, fooling around you don't just documenting everything to the end level of detail until you know what might be. The correct implementation could have pauses is not obvious when you to experiment and we have to have the ability and the flexibility than a company to be able to do exponentiation outside of the development of a product, outside of a KMS perhaps. Then we take that knowledge, you may have to repeat the process which in this situation, to create specifications. To give you an example, we talked about the requirements phase and the rules for how you do it well, one tool that people use to create requirements, to create prototypes. Another, quick and death do things. Software that doesn't really work is not meant for production use and that gets created quickly by somebody. Often at a very interesting situations late at night and there we don't have formal procedures would just do a quick thing to show customers, so that you can use it to understand what they need. That happens outside a quality management system. Once that tool is used to understand what the customer needs. Now we take that knowledge, we move back into ecosystem and now we'll design the product formally and we will not use a prototype directly as part of the finished product now made, take the code from it, reanalyze it, cleaned up, and bring it in piecemeal into the new software. But the idea is that you can go outside the system occasionally when you need to do some experimentation to figure out what one should be doing. To conclude this whole discussion about Colleen management systems, this is what the best practices is, what the common knowledge of the field is. That unless approach designing, producing a proper organization is unlikely to be of high quality and safe and all of the other good things, the best practices are captured in industry standards and regulatory edges look explicitly for quality management systems. We have rules about that both in the US, in Europe, in China and all other regulatory zones. A good queue message that help, it's not a burden, is just the right way to do things. To conclude this segment, we'll have a short video clip from Tom Renner who took us off our vision 28. Then he'll just summarize the whole topic for us here. Quality systems are just for meeting regulatory requirements. You would be prudent, as we said earlier, to embrace the quality system at all levels, it will make your company more efficient, more streamlined. Reduce your exposure to customer dissatisfaction, to adverse events. Even if you didn't have to for regulatory purposes, you should do things in a repeatable, efficient, documented way. Quality system is our best way of doing that, that we know of today. Yes, it's expensive, but it will pay for it. If you don't think the quality system and for documentation and the extra rigor as necessary evils. But if you think of them as tools that will help you be efficient, moving at a speed of business will then won't be an insult, would be moving at the speed of an assertion business and that's much better. This concludes our discussion of quality management systems. In the next set of segments, we'll take out the other major piece of supporting technology infrastructure and that is risk management. We'll continue with that in the next segment. Thank you.
