The risk assessment determines the categories of software, scope and amount of work to be done, what exactly needs to be completed, and what documentation you’ll produce to show your work. It will eventually replace the 2002 FDA guidance on software validation.ĭo a Risk Assessment of Non-Product Software, Including OTS and QMS Software ![]() This is still a draft guidance, but you should follow its recommendations now as it reflects current FDA thinking on the topic. It highlights the fact that manufacturers should use a risk-based approach to NPS software and contains an excellent appendix with examples of various software assurance cases. In September 2022, FDA published an extensive draft guidance titled, Computer Software Assurance for Production and Quality System Software. You can further separate these into software that is standard OTS versus software that has been customized or developed internally. For instance, you may have one group for all software used in the QMS and another group for software used in equipment. The list can get long, so it’s a good idea to group your software into categories. This can sometimes be challenging because the vendor of a purchased application may not want to provide any details or – in the case of OTS software – little information (or none) may be available. Determine what information is going to be needed to evaluate this software and the sources available. This is a good time to involve your IT department or even purchasing, as they may already have a list. Start by creating a spreadsheet that lists as many NPS applications as you can think of. There’s a methodical way you can go about evaluating this myriad of NPS systems and meet regulatory requirements – you don’t need to be a software engineer to do it! When you start thinking about all the software involved in making or maintaining your medical devices, the prospect of evaluating it all can be daunting. Start by Making a List of All Production, QMS, and Other NPS Software ![]() You’ll notice that off-the-shelf (OTS) software is included in the list above and must be validated to some degree. Hence, you can think of validation as a means of double-checking that the software does what you want it to do. If validation is not performed, we would have no clue that the system is not working correctly and so is not picking up a specific type of defect, thus allowing poor quality through with possibly no further inspections. ![]() Imagine, for example, that a high-speed camera inspection system controlled by a software application is not functioning correctly due to a software error.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |