How to select and help validate the best sterilization method?

1 Comment / Sterilization Validation, Validation / By

The FDA eSTAR includes a list of eight different options for a sterilization method, but how do you select the best method and validate it?

Sterilization Method Selection 1024x576 How to select and help validate the best sterilization method?

What is Sterile Packaging Day?

The Sterilization Packaging Manufacturers Council (SPMC) founded Sterile Packaging Day in 2021 to recognize and thank all of the companies in the supply chain who work together to deliver innovative, safe, and sterilized devices to provide excellence in patient care. Sterile Packaging Day is February 8, 2023, and this year’s celebration theme is “Designed to Protect.” SPMC provides four tips for celebrating Sterile Packaging Day:

  1. Donate blood (use this link for an appointment) on February 8, 2023, at MD&M West in Anaheim
  2. Recognize and thank an esteemed packaging professional with whom you collaborate for success
  3. Support the next generation of packaging engineers (FPA Student Design Challenge)
  4. Tell us in one word what “Designed to Protect” means to you (Rob chose “Lifesaving”)

Thank you to Jan Gates!

How to select the best sterilization method

Several factors determine the best sterilization method to use for your device. The first factor is whether your device will be delivered sterile or will the end user sterilize the device. If the end user is responsible for sterilizing the device, the most common methods used by hospitals are:

  1. steam sterilization
  2. hydrogen peroxide sterilization
  3. EO sterilization

The popularity of the third method is declining due to environmental restrictions on hazardous emissions from the ethylene oxide sterilization process. Hydrogen peroxide is gaining popularity because it can be used for heat-sensitive materials, and hydrogen peroxide vapor reacts with moisture to form a harmless aqueous solution. Steam is the most common sterilization method used by doctors, dentists, and hospitals because steam sterilizers are relatively inexpensive, and no hazardous chemicals are required.

The second factor to consider when selecting a sterilization method is whether there are any heat-sensitive components. Plastics will melt and degrade in dry heat sterilization cycles, and some plastics cannot withstand the temperature of a steam sterilizer. Therefore, if your device is constructed from plastics for cost reduction, weight, magnetic resonance (MR) compatibility, or other reasons, you may need to use a sterilization method with a lower temperature process.

The third factor to consider when selecting a sterilization method is whether any long, narrow tubes require sterilization. These design features are difficult to sterilize for any vapor-based sterilization process, such as steam, hydrogen peroxide, or ethylene oxide. There are a few process control strategies that can be used to sterilize with gas:

  • use of an extreme vacuum to improve penetration of sterilant gas
  • ensuring that the device and packaging materials are dry
  • use of longer cycles with more sterilant gas
  • use of internal biological indicators at the most difficult sterilization location

The fourth factor to consider when selecting a sterilization method is whether the device includes a liquid. A liquid cannot be sterilized with hydrogen peroxide, ethylene oxide, or dry heat. In some cases, the liquid may be a sterilant (i.e., ISO 14160:2021 for liquid chemical sterilizing agents). There are three popular solutions for the sterilization of a device that includes liquid:

  1. steam sterilization–assuming the liquid doesn’t contain components that are heat sensitive (e.g., proteins)
  2. filter sterilization–usually combined with aseptic filling and pre-sterilizing containers)
  3. radiation sterilization with eBeam or Gamma

eBeam and Gamma are also used for sterilizing products where cross-linkage of ultra-high molecular weight polyethylene (UHMWPE) is desired, or it is impossible for a gas sterilant to penetrate all areas of a device.

What are the applicable sterilization validation standards for each sterilization method?

As shown in the FDA eSTAR screen capture above, eight possible sterilization methods can be selected for sterilizing a medical device in a 510k or De Novo submission. Each sterilization method has a different applicable standard that should be used to validate the sterilization process, but in all cases, the sterilization process must result in a sterility assurance level (SAL) of 10-6.

The FDA feels that the Established A (Est A) methods of sterilization have a long history of safe and effective use, while the FDA has not recognized a dedicated consensus standard for the Established B (Est B) sterilization methods. However, there are examples of devices that have received FDA 510k clearance using each of the non-traditional sterilization methods (i.e., Est B methods). Manufacturers will generally adapt existing international standards for sterilization validation to validate the non-traditional methods. There is published information on the development, validation, and routine control for these non-traditional sterilization processes.

Links to each of the recognized standards are provided below:

  1. Steam (Moist Heat) (Est A) – ISO 17665-1:2006, Sterilization of health care products — Moist heat — Part 1: Requirements for the development, validation, and routine control of a sterilization process for medical devices
  2. Ethylene Oxide (EO, EtO) (Est A) – ISO 11135:2014, Sterilization of health care products – Ethylene oxide – Requirements for development, validation and routine control of a sterilization process for medical devices; and ISO 10993-7:2008, Biological evaluation of medical devices – Part 7: Ethylene oxide sterilization residuals
  3. Radiation (Est A) – ISO 11137-1:2006, Sterilization of health care products – Radiation – Part 1: Requirements for development, validation, and routine control of a sterilization process for medical devices; ISO 11137-2:2013, Sterilization of health care products – Radiation – Part 2: Establishing the sterilization dose
  4. Dry Heat (Est A) – ISO 20857:2010, Sterilization of health care products – Dry heat – Requirements for the development, validation and routine control of a sterilization process for medical devices
  5. Hydrogen Peroxide (Est B) – ISO 22441:2022, Sterilization of health care products — Low temperature vaporized hydrogen peroxide — Requirements for the development, validation and routine control of a sterilization process for medical devices (this standard is not recognized by the US FDA)
  6. Ozone (Est B) – this is a new method using Ozone gas, and the method of action is similar to EO and H2O2
  7. Flexible Bag Systems (Est B) – ISO 22441:2022 should be used for validation of flexible bag systems with hydrogen peroxide, but instead of validating the process with three half-cycles that are half the duration of the full-cycle, instead, you use three half-cycles that use half the volume of sterilant of a full-cycle; this method is used by Andersen Scientific for their EO Bag sterilizers.
  8. Novel Methods – ISO 14937:2009, Sterilization of health care products – General requirements for characterization of a sterilizing agent and the development, validation and routine control of a sterilization process for medical devices

When should you use a novel sterilization method?

Novel sterilization methods should only be used when none of the traditional (Est A) and non-traditional (Est B) sterilization methods will not work. For example, aseptic filling combined with filtration of liquids is a common strategy for pre-filled syringes if the liquid is sensitive to radiation sterilization. Sterilization with peracetic acid has been used for a long time, but the sterilization method has not gained widespread popularity. Peracetic acid can also be combined with hydrogen peroxide. There is also a low-temperature steam and formaldehyde validation standard (i.e., ISO 25424:2019). Sterilization with UV light is a process that is sometimes used where materials are sensitive to high temperatures and where all surfaces can be penetrated with UV light. Nitrogen dioxide was developed as a more environmentally friendly sterilant similar to ethylene oxide. X-Ray is a new type of radiation sterilization that is being developed as a high-speed alternative to Gamma and eBeam, but X-Ray sterilization also has the advantage of being able to control a narrower dose range than Gamma and eBeam processes.  

Consensus Standards for Sterilization Validation

There are also additional supporting standards that you will need for validation of your sterilization process. The following is a partial list of the standards you might consider:

  • ISO 11737-1:2018, Bioburden Testing for Aerobic Bacteria and Fungi
  • USP<51> Antimicrobial Effectiveness Test
    • Candida albicans (a yeast…yeasts are a form of fungus)
    • Aspergillus brasiliensis (a filamentous mold…also a fungus)
    • Escherichia coli (a bacterium…better known as “E. coli”)
    • Pseudomonas aeruginosa (a bacterium….very problematic industrially)
    • Staphylococcus aureus (a bacterium…better known as “Staph”
  • USP<61> Bioburden or Microbial Limits Test (Total Aerobic Microbial Count = TAMC; Total Yeast and Mold Count = TYMC)
  • USP<62> Objectionable Organisms or Pathogens Tests
  • USP<63> Mycoplasma Tests
  • USP<71> Bacteriostasis/Fungistasis (i.e., B/F) Sterility Tests
  • ISO 11138-1:2017, Sterilization of health care products – Biological Indicators – Part 1: General Requirements
  • ISO 111140-5:2017, Sterilization of health care products – Chemical indicators – Part 5: Class 2 indicators for Bowie and Dick air removal test sheets and packs
  • ISO 17664-1:2021, Processing of health care products – Information to be provided by the medical device manufacturer for the processing of medical devices – Part 1: Critical and semi-critical medical devices

Aging and Shelf-life Testing

The current standard for accelerated aging studies is ASTM F1980:2021 “Standard Guide for Accelerated Aging of Sterile Barrier Systems and Medical Devices has been revised and recently released to include medical devices.” Jan Gates explains that the “and” used to say “for.” The language was updated with more information on product humidity effects to go with the title. Jan was kind enough to write a Shelf-life Testing Protocol for us based on this new version of the standard. The protocol includes requirements for real-time and accelerated age testing of a product. If you need basic training on how to validate the shelf-life of your device, we have a webinar for sale on sterility and shelf-life. We also recorded an updated webinar on January 19, 2023, as part of the FDA eSTAR updates to our 510(k) Course.

Distribution Conditioning Tests & Packaging Performance Tests

There are also standards for distribution conditioning tests (i.e., ASTM D4169-22). Jan Gates was kind enough to write a 20-page Distribution Conditioning Shipping Qualification Protocol for Medical Device Academy based upon the ASTM standard. The protocol is available for purchase at the link above. Jan also wrote an 18-page Packaging Performance Testing Protocol for our customers in accordance with ISO 11607-1 and ISO 11607-2.

Where can you find a procedure for each sterilization method?

ISO 13485:2016, Clause 7.5.7 is specific to the “Particular requirements for validation of processes for sterilization and sterile barrier systems.” This clause includes the requirement to establish procedures for sterilization validation and validation of your sterile barrier systems. Even if your company uses a protocol and procedures established by a contract manufacturer, you still need to establish an internal procedure(s) to meet this requirement if you have sterile products. The following is a list of procedures sold by Medical Device Academy:

What is the process flow for contract sterilization?

Most device manufacturers do not sterilize their devices in-house. Instead, sterilization is outsourced to a contract sterilizer. The process flow diagram below is a hypothetical process flow diagram for a contract sterilization process. The only step not included in this process flow is the incubation of biological indicators because gamma and eBeam sterilization processes use dosimeters instead of biological indicators. The nature of biological indicators is also changing rapidly because manufacturers are developing “rapid test” biological indicators. In 2008 I worked extensively with self-contained biological indicators that eliminated the need to use an aseptic technique to transfer biological indicators into culture media. In addition, I complete an incubation reduction study to validate a shorter 48-hour incubation cycle instead of the typical 7-day sterility test. Terragene is one of the manufacturers developing next-generation technology for biological indicators that allows the results to be read within seconds instead of 48 hours. This next-generation technology also incorporates barcode readers and networked readers to ensure traceability to each biological indicator and reader.

Generic Sterilization Process Flow Diagram 731x1024 How to select and help validate the best sterilization method?

What information should serialized labels include for contract sterilizers?

In the “olden days” (c. 2005), I used to print out labels for each pallet that we shipped to the Isomedix facility in Northboro, MA. The label identified who the product was from and what we wanted Isomedix to do with the product (e.g., gamma sterilize at 25-40 kGy). At the time, we were just beginning to incorporate barcodes into on-demand labeling to facilitate traceability. 18 years later, companies are still stalling the implementation of on-demand barcoded labels. Almost every shipping dock has a barcode reader, and the technology is inexpensive. Therefore, you should consider creating a template for on-demand barcoded labels with all the information listed below. This will reduce the risk of errors by the contract sterilizer and enable you to identify when a mistake was made quickly. Contract sterilizers should also demand this information on product labeling as an added risk control. All biological indicators and dosimeters are labeled with UDI barcodes now. Therefore, contract sterilizers should be able to create robust process controls that ensure traceability between barcodes on your labeled product with barcodes on the biological indicator or dosimeter.

2 Customer Prints Serialized Labels 1024x816 How to select and help validate the best sterilization method?

How to select and help validate the best sterilization method? Read More »

ISO 19011 – Do you need this quality system auditing standard?

5 Comments / Auditing, ISO Auditing, Remote Auditing / By / , ,

Read this article to learn why ISO 19011 standard is a vital guidance for anyone that audits quality systems or manages an audit program.

What is ISO 19011?

ISO 19011 is a seven-part international standard for auditing management systems. The standard defines the eight principles of auditing (e.g., the process approach to auditing), provides guidance on managing audit programs and conducting audits, and includes recommendations for evaluating people for competency. There is also an appendix with details on conducting on-site and remote audits.

If you have ever taken a lead auditor course for ISO 13485, or one of the other quality management system standards, one of the critical handouts for the class should have been ISO 19011. The title is “Guidelines for Auditing Quality Management Systems.” In 2018, ISO 19011 was updated, and the changes were not superficial. If you need to purchase a copy of ISO 19011:2018, the Estonian Center for Standardization and Accreditation is the least expensive source we know.

ISO 19011 covers the topic of quality management system auditing. This Standard provides guidance on managing audit programs, conducting internal and external audits, and determining auditor competency.  One of the most common points of confusion in the lead auditor course is the difference between first, second, and third-party audits. In the first edition of this Standard, the difference between first, second, and third-party audits was just a note at the bottom of page one and the top of page two. The note was also not clear. In the second edition of 19011, in Table 1 (reproduced below), the difference between these three types of auditing is crystal clear. Table 1 was modified further in the 3rd edition to include a bottom row that remains unchanged in the 3rd edition, released in 2018.

Types of Audits Table 1 1024x205 ISO 19011 Do you need this quality system auditing standard?

Figure 1, found in Clause 5.1 of the 2nd edition, was combined with Figure 2, found in Clause 6.1 of the 2nd edition. The combined figure is now Figure 1 in the 3rd edition. The combined scope of Figure 1 is now a “Process flow for the management of an audit program” and a “Process flow for conducting an audit.” The figure categorizes the various stages of audit program management and conducting an audit into the Plan-Do-Check-Act (PDCA) cycle. We highly recommend this style for presenting any process in your internal procedures as an example of best practices in writing an SOP. The flow chart even references each of the clauses in the Standard.

The 2018 version still includes an opening meeting checklist (i.e., Clause 6.4.3) and a closing meeting checklist (i.e., Clause 6.4.10). Figure 3 in the 2nd edition, “Overview of the process of collecting and verifying information,” was a poor example of a flow chart. The committee did not update the figure when the standard was updated for the 3rd edition. Therefore, we updated the figure below to provide additional traceability to the Clauses of the Standard. If you incorporate this figure into your quality auditing procedure, you should substitute references to your procedure’s sections instead of the clauses of the standard.

Figure 2 ISO 19011 2018 1024x702 ISO 19011 Do you need this quality system auditing standard?

Competency Requirements in ISO 19011

Many audit procedures neglect to define the qualifications and methods for determining the competency of the audit program manager. Clause 5.3.2 tells you how. Put it in your own procedure. Most of the procedures we read include qualifications for a “Lead Auditor,” but we seldom see anything regarding competency. Unfortunately, this Standard only explicitly addresses the “Lead Auditor” competency in a two-sentence paragraph—Clause 7.2.5. When we teach people how to be Lead Auditors, we spend more than an hour on this topic alone.

The Standard would be more effective by providing an example of how third-party auditors become qualified as a Lead Auditor. Third-party accreditation requires the auditor to be an “acting lead” for audit preparation, opening meetings, conducting the audit, closing meetings, and final preparation/distribution of the audit report. This must be performed for 15 certification audits (i.e., – Stage 2 certification or re-certification), and another qualified lead auditor must evaluate you and provide feedback.

Appendices in ISO 19011

The appendices were the last significant additions to this Standard in 2011 (i.e., 2nd edition). Annex A provided examples of discipline-specific knowledge and skills of auditors. This section was eliminated from the 3rd edition of ISO 19011:

“Due to the large number of individual management system standards, it would not be practical to include competence requirements for all disciplines.” – Copied from the Foreward

I think providing adding a short Annex to each management system standard that defines recommended discipline-specific knowledge would be helpful. Still, that kind of change would need to be initiated with the next version of ISO 9001.

Appendix B in the 2nd edition is now Appendix A in the 3rd edition of ISO 19011. A table (Table A.1 – Audit Methods) compares conducting on-site and remote audits. We were pleased to see that conducting interviews is a significant part of remote auditing in this table. Section A.17 in the appendix provides suggestions for conducting interviews. Still, if you exhibit all 13 professional behavior traits found in Clause 7.2.2, you don’t need advice on speaking with people. For the rest of us mortals, we could use a five-day course on interviewing alone. To improve your skills in this area, ask an experienced auditor with solid interviewing skills to watch and comment on a recording of a virtual audit you perform. Watching yourself audit is cringe-worthy, but we guarantee you will improve.

What are the primary changes to the 2018 version of the standard?

There are seven main differences between the second edition, published in 2011, and the third edition of ISO 19011, released in 2018:

  1. addition of a seventh principle of auditing in sub-clause 4(g) (i.e., risk-based approach);
  2. more guidance on audit program management in Clause 5, including audit program risk;
  3. expansion of Clause 6 on conducting an audit–especially Clause 6.3 on audit planning;
  4. expansion of auditor competence requirements in Clause 7;
  5. updating of terminology to emphasize processes rather than objects;
  6. removal of an annex containing competence requirements for specific quality management systems;
  7. expansion of Annex A to include guidance on new auditing concepts such as remote audits.

Risk-based auditing is the most significant change in the 2018 version of ISO 19011

One of the main differences between ISO 19011:2018 and the previous 2011 version is the addition of a “risk-based approach” to the principles of auditing. Specifically, clause 4(g) of the guidelines for auditing management systems is, “The risk-based approach should substantively influence the planning, conducting and reporting of audits to ensure that audits are focused on matters that are significant for the audit client, and for achieving the audit program objectives.” A lot of people are unsure of what is meant by a risk-based approach. Still, the key to understanding this is to focus on the definition of risk. From a product perspective, the risk is the “combination of the probability of occurrence of harm and the severity of that harm.” From a process perspective, the risk is the “effect of uncertainty on an expected result” (ISO 9001:2015, clause 3.09). Therefore, auditors should emphasize medical devices with the highest severity of harm and devices with a high probability of hazards or hazardous situations. When an auditor focuses on a process rather than a specific medical device, auditors should emphasize any processes that are not under control and any recent process changes.

animal nature reptile animal world ISO 19011 Do you need this quality system auditing standard?

What is risk-based auditing?

Risk-based auditing considers the risks of failing to achieve audit objectives and the opportunities created by choosing various audit methods and strategies. For example, a desktop audit of procedures might be appropriate if you are conducting your first internal audit for a new quality system. Alternatively, a desktop audit would be a waste of time if you are auditing a mature quality system where very few changes to procedures have been made in the past year. Using the element approach to auditing is unlikely to add much value. Audits are meant to be a sampling. Therefore, you should focus on areas of importance where previous nonconformities were identified, any new products or processes, and anything that changed significantly.

Auditor selection should also be risk-based

Suppose you are conducting a supplier audit as part of your initial supplier qualification for a critical component supplier or contract manufacturer. In that case, you should consider doing a team audit with a multi-disciplinary team. This is a risk-based approach to the supplier qualification process, which ensures that subject matter experts evaluate each process instead of auditors with a general quality assurance background. This approach also forces more of your personnel to introduce themselves to the new supplier, and the audit will develop more reliable communication channels between your two companies. Alternatively, if you are conducting a routine internal audit of a production process, you might select a new lead auditor to conduct the audit. You don’t expect any significant findings in a routine internal audit of an established production process. In your role as an audit program manager, you need to match the new lead auditor to a process that will force them to look at all aspects of the process approach to auditing. Specifically, process validation, calibration, maintenance, and process monitoring may not apply to other administrative process areas, such as purchasing.

Risk-based auditing should influence your auditing schedule

The frequency of auditing suppliers and internal process areas should reflect the associated risks. Therefore, when you create or update your auditing schedule, you should consider the risk level of the products being audited and the process being audited. Production processes with a moderate or high level of non-conforming products may need to be audited more than once yearly. Still, a supplier with an excellent track record of extremely high quality and on-time delivery may be audited in alternating years. If you previously scheduled a remote audit, you may want to alternate to conducting an on-site audit the next time.

The duration of your audits should not always be the same either. Suppose one production process makes one product in low volume, and another production process makes multiple products in high volume. In that case, you should not schedule a two-hour internal audit for both processes every year. The low-volume production process may only need a one-hour audit once per year. In contrast, the high-volume process may require a four-hour internal audit or multiple annual audits.

Risk-based auditing applied to remote supplier auditing

The risk-based auditing approach was added to ISO 19011:2018 as the seventh principle of auditing. This represents the most significant change to that standard, but how does it apply to remote auditing? Despite the opportunities created by remote auditing, there are also risks associated with auditing suppliers remotely. People worry about auditees hiding hazardous situations or unacceptable environmental conditions such as filth or disrepair. However, unacceptable cleanliness and maintenance practices don’t happen overnight. Therefore, you should expect a clean and well-maintained facility to remain that way. One approach is to alternate between remote and on-site audits to verify the overall condition of a supplier’s facility. Therefore, the risk of auditees hiding objective evidence is more an issue of trust than a highly probable occurrence.

The more probable risks associated with remote auditing are related to the potential lack of availability of records. This is especially important for paper-based quality systems. Most people try to address this risk by scanning paper documents and records, but scanning documents have limited value. Scanning paper documents is more efficiently performed in a large batch by an automated or semi-automated process. Also, auditors and inspectors typically focus on the most recent records, and auditors and inspectors rarely sample 100% of the records. Therefore, the best risk controls include the following:

  • Ask a guide to send a digital picture of the record.
  • Use a tripod-mounted HD webcam focused on a music stand or similar surface.
  • Ask the auditee to read the document while you take notes.

In our experience, you will probably rely on all three risk controls, but it is unlikely to delay the audit. However, in response to the limited physical access to medical device facilities and personnel, certification bodies are sending out questionnaires to assess the risk of being unable to achieve audit objectives or cover the required scope of surveillance and recertification audits. As the audit program manager, you can reduce these risks by working with supply chain managers to develop new supplier questionnaires that specifically ask questions about the capability of supporting audits remotely. In particular, it would be essential to obtain facility maps to identify areas with inadequate cellular coverage and identify records that are only available in hardcopy format.

ISO 19011 – Do you need this quality system auditing standard? Read More »

Software security, what is the best time to test cybersecurity?

1 Comment / Cybersecurity, Software Verification and Validation / By

The new US FDA draft cybersecurity guidance requires you to test cybersecurity, but when should you conduct software security testing?

The 2022 draft cybersecurity guidance from the FDA emphasizes the need to design devices to be secure and the need to design devices capable of reducing emerging cybersecurity risks throughout the total product lifecycle. Designing devices for security must be built into your original design plan, or you will need to modify your device for improved security just to obtain initial 510(k) clearance from the FDA. What is not clear from the guidance or standards is when you need to conduct security testing or repeat tests.

Planning Cybersecurity Tests

As with all quality system processes, cybersecurity testing should begin with a plan. There are two models typically used for the design and development process: Waterfall Diagram (typical of hardware development) and V-Diagram (typical of software development).

waterfall fda Software security, what is the best time to test cybersecurity?
Waterfall Diagram

Software Validation and Verification 1 Software security, what is the best time to test cybersecurity?

V-Diagram

How are design plans for SaMD different from other design plans?

Most of the verification testing for software as a medical device (SaMD) is 1) conducted virtually, 2) tests software code in a “sandbox,” and 3) involves internally developed testing protocols. In contrast, verification testing for other types of devices involves 1) physical devices, 2) testing at a 3rd party lab, and 3) involves international standards and testing methods. The biggest differences between SaMD verification testing and other device verification testing are the speed and cost of the testing. SaMD verification is much faster and less expensive. Therefore, if your software design documentation is efficient, you can complete more design iterations. This is why software developers use the V-diagram to model the design and development process instead of the “waterfall” diagram.

Where do the requirements to test cybersecurity belong in your design plan?

A design plan documents the design and development process for your device. You must establish, maintain, and update the plan as the project progresses. There is no required format, but auditors and the FDA will audit your Design History File (DHF) for compliance with your plan. You are required to document the following content in your plan:

  • Stages of development
  • Reviews at each design and development stage
  • Verification, validation, and design transfer activities at each stage
  • Responsibilities and authorities for the design project
  • Methods you are using to ensure traceability of user needs, software hazards, software requirements, software design specifications, and software testing reports
  • Human resources needed for your design project, including competency

Software Design Inputs

In the early stages of the software development lifecycle, you must select an appropriate threat model and perform a hazard analysis for software security. These security hazards need to be included as design inputs in your software requirements specification (SRS). The need for updateability and patchability should also be included as design inputs. 

In parallel with your SRS, you will need to create a User Specification. The SRS and User Specification will determine the use cases and call-flow views that require verification testing later in your software development process. After the SRS has been approved, you will need to create a software design specification (SDS). Each item in the SDS should be traceable to an item in the SRS. The SDS items that trace to security hazards are your risk controls. Each risk control will require you to test cybersecurity to verify risk control effectiveness. At this point, you will need to create your testing protocols for security.

System Testing Protocols to Test Cybersecurity

Testing protocols should include a boundary analysis and rationale for boundary assumptions. Testing protocols should also include vulnerability testing. The FDA recommends the following vulnerability testing:

  1. Abuse cases, malformed, and unexpected inputs,
    1. Robustness
    2. Fuzz testing
  2. Attack surface analysis,
  3. Vulnerability chaining,
  4. Closed box testing of known vulnerability scanning,
  5. Software composition analysis of binary executable files, and
  6. Static and dynamic code analysis, including testing for credentials that are “hardcoded,” default, easily guessed, and easily compromised.

Does your development budget include security testing? 

Design control training traditionally emphasizes the importance of “freezing” design outputs before starting verification testing to prevent the need for repeating any of the verification testing. The reason for this is that verification testing is expensive, and it is time-consuming to produce additional verification samples. In contrast, SaMD is guaranteed to be changed multiple times during the verification testing process as software bugs are identified. Therefore, software developers focus on the velocity of developing code and testing that code. One exception to this is penetration testing. Penetration testing is usually conducted once your code is final because it is more expensive than other software verification and validation testing and it would need to be repeated each time the software is updated or patched.

Penetration Testing

Penetration testing is another method used to test cybersecurity that would probably be conducted in parallel with simulated use testing to validate performance and the effectiveness of human factors risk controls. Penetration testing could be at the system level in a sandbox environment, or it can be performed on a sample device in a simulated use environment. Your penetration testing documentation should include the following:

  1. independence and technical expertise
  2. scope of testing
  3. duration of testing
  4. testing employed, and
  5. test results, findings, and observations

Postmarket cybersecurity management

For CE Marked products, there is a requirement for a postmarket surveillance plan (i.e., PMS plan) to be submitted as part of your technical file. The US FDA does not currently have this requirement for Class 1 and Class 2 devices, but Class 3 devices (i.e., PMA) and devices with humanitarian device exemptions (HDE)  are required to submit a PMS plan as part of the premarket submission. The US FDA also requires a postmarket cybersecurity management plan to be submitted for premarket submissions of Class 2 and Class 3 devices. You should create your postmarket cybersecurity management plan during your verification and validation activities, and the final version should be approved at the time of product release.

If you need additional resources or training related to cybersecurity, you may be interested in the following:

Software security, what is the best time to test cybersecurity? Read More »

Effective Management Skills for Managers

1 Comment / ISO Certification / By / ,

This blog revies some practical and effective management skills that all managers should possess.

Sometimes we hear phrases like: “Well, that’s just an ISO requirement.” This apparent lack of support by top management is what frustrates every Management Representative in the world.

Peer Support

For a Quality Manager or any manager, it is vital to gain support from our peers, as failure to do so can lead to challenges. While the Quality Department plays a crucial role in recommending improvements, providing training, and assisting with implementation, it cannot address all problems on its own. Therefore, I strongly believe in assigning corrective actions to the process owner (i.e., the Manager) responsible for the area where the problems originated. This approach creates an opportunity for QA/RA to collaborate with the area manager and work together as a team towards the shared goal of improvement.

Good managers build people up and improve processes, they don’t point fingers or blame individuals. It is the process, not the person.

sKKP5YsxxUbjMPmSNnZr 4 hrptd 300x300 Effective Management Skills for Managers
Example of ‘not-an-effective-manager’

Persuading Skeptics

If you encounter resistance when trying to persuade skeptics, focus on a crucial project for the individual opposing your ideas. Demonstrate how applying Quality principles can effectively resolve their problems, potentially gaining their support. Converting one person often leads to strong support from them. If the resistant individual holds a senior position such as the CEO, take time to understand the CEO’s initiatives (These shouldn’t be hard to identify as they likely talk about them rather constantly). Illustrate how their actions can align with Quality Objectives, using graphs and presenting well-thought-out solutions to their challenges. Utilize the CAPA (Corrective and Preventive Action) process as a framework to show how the management team can collaboratively address issues.

If nothing seems to be working, you can always try reviewing some FDA MedWatch reports too–just to scare your boss.

Here is a list of tips to deal with unsupportive top management in a quality management system using effective management skills:

Clearly communicate the benefits of the quality management system:

Articulate the advantages that a well-implemented quality management system can bring to the organization, such as improved efficiency, reduced costs, and enhanced customer satisfaction. Don’t just leave the conversation at “The QSR/13485 says that we SHALL have one”.

Address specific concerns and show how quality initiatives overcome challenges:

Listen to the concerns of top management and present how quality initiatives directly address those issues, fostering a more positive outlook towards the system. Just like the old saying,

“An ounce of prevention is worth more than a pound of the cure”

Consider how ISO 13485:2016 has separate sub-clauses for Corrective Actions and Preventive Actions. Explain how something like pushing for preventive actions shows compliance with clause 8.5.3. which auditors, and inspectors will be looking for, but also that every Preventive Action represents a dodged 483 letter or recall.

Or how beefing up incoming inspection is likely to save time and money in reworked product and less scrap dispositions because any non-conforming materials are stopped before they can make their way into finished devices.

Demonstrate how quality aligns with overall business objectives:

Connect the quality management system to the organization’s strategic goals, highlighting how it contributes to long-term success and profitability. Reframe the Quality Policy and Quality Objectives as tools to support a successful business. Not just, “We have to have them for compliance….”

Start with small projects and showcase measurable results:

Begin with pilot projects or smaller initiatives that demonstrate tangible improvements, instilling confidence and support from top management.

Create a compelling business case for the quality management system:

Develop a well-researched and data-driven business case that outlines the return on investment and the long-term benefits of implementing the system. Effective management skills will involve encorporating topics like regulatory compliance. Not only how they align with, but are a part of business goals.

Engage top management in the decision-making process. Seeking their input and making them feel invested in shaping the quality management system. It is important that the entire organization be ‘quality focused’ at all times. Not just when an audit or management review is approaching.

Management Review Webinar and Procedure – Free Downloads

Consider the potential consequences of non-compliance with quality standards:

Emphasize the impact of not adhering to quality standards, such as regulatory penalties or reputational damage. This will underscore the necessity of the system’s implementation. This can be validated externally if need be. Auditors or consultants can assess quality processes and provide independent validation of a systems strengths of weaknesses.

7 Steps to writing an FDA 483 response

Effective Management Skills for Managers Read More »

Four easy ways 510k and De Novo content is different

4 Comments / 510(k), De Novo / By

It’s a common misconception that FDA De Novo content is very different from FDA 510k submission content, but is that true?

What do you think the De Novo content differences are?

Most people think the difference between a 510k and a De Novo is time and money. That conclusion is based upon a very important assumption: a 510k will not require clinical data, and a De Novo will require clinical data. That assumption is not always correct. 10-15% of 510k submissions include clinical data to support the performance claims, and last year our team submitted three De Novo submissions that did not include any clinical data. So what are the differences between a 510k and a De Novo content?

We use the same FDA eSTAR template for both types of FDA submissions, and on the first page of the eSTAR template, we identify if the submission is a 510k or De Novo. If we select De Novo, the eSTAR will be pre-populated with six unique De Novo content requirements covering four (4) different areas that are not found in a 510k. The six unique content requirements are:

  1. Recommending a classification, providing a justification for that classification, and explaining what efforts were taken to identify a suitable 510k product code
  2. Description of existing alternative  practices or procedures used in diagnosing, treating, preventing, curing, or mitigating the disease or condition for which the IVD or device is intended
  3. A risk mitigation table must be provided
  4. Providing a written benefit/risk analysis starting with the clinical benefits of your device
  5. Efforts to identify a potential predicate (including identifying alternative practices, procedures, or even drugs)
  6. Recommendations for FDA special controls for your new product code based upon the risks to health and the mitigation measures for each risk

Alternate practices and procedures 1024x547 Four easy ways 510k and De Novo content is different

What alternative practices and procedures are currently available?

The unique De Novo content requirement is to provide a description of alternative practices and procedures for treatment or diagnosis of the same indications that you are proposing for your subject device. This is a subsection of the device description section in the FDA eSTAR template. Your should description should include other 510k-cleared products, drugs, and even products that have similar indications but are not identical. The description of alternative practices and procedures must also be attached as a document in the section for benefits, risks, and mitigation measures. To maintain consistency throughout your submission, you should create the document for attachment first and copy and paste the content into the text box at the end of the device description section.

You need to recommend a classification in your De Novo

The unique De Novo content requirement is found in a section titled “Classification.” There is a shorter classification section included in 510k submissions, but the 510k version only has four cells. The first three are populated by selecting one of the options from a dropdown menu, and the fourth cell is only used if your subject device includes other product classification codes.

Classification 1024x346 Four easy ways 510k and De Novo content is different

The De Novo version of the eSTAR is identical for the first row of the classification section, but then you must select a proposed product classification (i.e., Class 1 or Class 2) in accordance with FDA Classification Procedures (i.e., 21 CFR 860). The third cell is a text box for you to enter your justification for the proposed classification. Next, the FDA requires you to enter a proposed classification name. Finally, at the end of the classification section, the FDA requires that you provide a classification summary or reference to a previous NSE 510k submission.

A benefit-risk analysis is required in the De Novo content

For new devices, the FDA uses a benefit-risk analysis to decide if a device should be authorized for marketing in the USA.  This process includes humanitarian device exemptions, De Novo applications, and Premarket Approval submissions. The FDA has a guidance document that provides guidance for FDA reviewers and the industry. The most important aspect is, to begin with, the benefits of the device and to provide a quantitative comparison of benefits and risks. Many De Novo submissions have been rejected because the submitter did not provide objective evidence of clinical benefits for the subject device.

Benefit Risk Analysis 1024x210 Four easy ways 510k and De Novo content is different

The FDA guidance documents are helpful for creating a benefit-risk analysis, but you can also find information in the ISO/TIR 24971:2020–the guidance for the application of ISO 14971:2019. Our company also includes a template for a benefit/risk analysis as part of our risk management procedure (i.e., SYS-010).

What are your recommended Special Controls?

In FDA De Novo Classification Decision Summaries, there is a table provided that identifies the identified risks to health and the recommended mitigation measures for each risk category. In the FDA eSTAR, you are required to add a similar table for De Novo content. The only difference between the table in summary and the eSTAR is that the eSTAR table has a third column where the FDA wants you to reference the supporting data provided for each mitigation measure–including the document and page within the document. The FDA also provided an example table in the eSTAR, copied below.

Risk Mitigation Table Four easy ways 510k and De Novo content is different

The above table for the risks to health and mitigations needs to be translated into a list of recommended Special Controls for Class II devices. Since most De Novo applications are for Class II devices, you will need to convert each of your mitigations into a corresponding Special Control and type these controls into the text box provided in the FDA eSTAR.

Special Controls Four easy ways 510k and De Novo content is different

What else is different from a 510k?

There are no additional mandatory elements that you need to include in a De Novo application, but there are several elements of a 510k submission that are not included in a De Novo. The most obvious of these sections is the Substantial Equivalence Comparison Table in the section labeled “Predicates and Substantial Equivalence.” Another difference is that you are more likely to need clinical data to support a De Novo application than for a 510k submission. It is also possible that subsequent 510k submissions for the same product code may not need to provide clinical data because the 510k process only requires a demonstration of substantial equivalence rather than clinical benefits outweighing risks to health. The FDA review time for a Traditional 510(k) varied between 190 and 210 days in 2022, while the De Novo review timeline averaged 390 days in  2022. Finally, the FDA user fees for 510k submissions are far less than those for a De Novo application.

Four easy ways 510k and De Novo content is different Read More »

Why modernize 21 CFR 820 to ISO 13485?

Leave a Comment / FDA, Human Factors, ISO 13485:2016, Post-Market Surveillance, Quality Management System, Software Verification and Validation / By

The FDA patches the regulations with guidance documents, but there is a desperate need to modernize 21 CFR 820 to ISO 13485.

FDA Proposed Amendment to 21 CFR 820

On February 23, 2022, the FDA published a proposed rule for medical device quality system regulation amendments. The FDA planned to implement amended regulations within 12 months, but the consensus of the device industry is that a transition of several years would be necessary. In the proposed rule, the FDA justifies the need for amended regulations based on the “redundancy of effort to comply with two substantially similar requirements,” creating inefficiencies. In public presentations, the FDA’s supporting arguments for the proposed quality system rule change rely heavily upon comparing similarities between 21 CFR 820 and ISO 13485. However, the comparison table provided is quite vague (see the table from page 2 of the FDA’s presentation reproduced below). The FDA also provided estimates of projected cost savings resulting from the proposed rule. What is completely absent from the discussion of the proposed rule is any mention of the need to modernize 21 CFR 820.

Overview of Similarities and Differences between QSR and ISO 13485 1006x1024 Why modernize 21 CFR 820 to ISO 13485?

Are the requirements “substantively similar”?

The above table provided by the FDA claims that the requirements of 21 CFR 820 are substantively similar to the requirements of ISO 13485. However, there are some aspects of ISO 13485 that will modernize 21 CFR 820. The areas of impact are 1) software, 2) risk management, 3) human factors or usability engineering, and 4) post-market surveillance. The paragraphs below identify the applicable clauses of ISO 13485 where each of the four areas are covered.

Modernize 21 CFR 820 to include software and software security

Despite the limited proliferation of software in medical devices during the 1990s, 21 CFR 820 includes seven references to software. However, there are some Clauses of ISO 13485 that reference software that are not covered in the QSR. Modernizing 21 CFR 820 to reference ISO 13485 will incorporate these additional areas of applicability. Clause 4.1.6 includes a requirement for the validation of quality system software. Clause 7.6 includes a requirement for the validation of software used to manage calibrated devices used for monitoring and measurement. Clause 7.3 includes a requirement for validation of software embedded in devices, but that requirement was already included in 21 CFR 820.30. The FDA can modernize 21 CFR 820 further by defining Software as a Medical Device (SaMD), referencing IEC 62304 for management of the software development lifecycle, referencing IEC/TR 80002-1 for hazard analysis of software, referencing AAMI TIR57 for cybersecurity, and referencing ISO 27001 for network security. Currently, the FDA strategy is to implement guidance documents for cybersecurity and software validation requirements, but ISO 13485 only references IEC 62304. The only aspect of 21 CFR 820 that appears to be adequate with regard to software is the validation of software used for automation in 21 CFR 820.75. This requirement is similar to Clause 7.5.6 (i.e., validation of processes for production and service provisions).

Does 21 CFR 820 adequately cover risk management?

The FDA already recognizes ISO 14971:2019 as the standard for the risk management of medical devices. However, the risk is only mentioned once in 21 CFR 820. In order to modernize 21 CFR 820, it will be necessary for the FDA to identify how risk should be integrated throughout the quality system requirements. The FDA recently conducted two webinars related to the risk management of medical devices, but implementing a risk-based approach to quality systems is a struggle for companies that already have ISO 13485 certification. Therefore, a guidance document with examples of how to implement a risk-based approach to quality system implementation would be very helpful to the medical device industry. 

Modernize 21 CFR 820 to include Human Factors and Usability Engineering

ISO 13485 references IEC 62366-1 as the applicable standard for usability engineering requirements, but there is no similar requirement found in 21 CFR 820. Therefore, human factors are an area where 21 CFR 820 needs to be modernized. The FDA has released guidance documents for the human factors content to be included in a 510k pre-market notification, but the guidance was released in 2016 and the guidance does not reflect the FDA’s current thoughts on human factors/usability engineering best practices. The FDA recently released a draft guidance for the format and content of human factors testing in a pre-market 510k submission, but that document is not a final guidance document and there is no mention of human factors, usability engineering, or even use errors in 21 CFR 820. Device manufacturers should be creating work instructions for use-related risk analysis (URRA) and fault-tree analysis to estimate the risks associated with use errors as identified in the draft guidance. These work instructions will also need to be linked with the design and development process and the post-market surveillance process.

Modernize 21 CFR 820 to include Post-Market Surveillance

ISO/TR 20416:2020 is a new standard specific to post-market surveillance, but it is not recognized by the FDA. There is also no section of 21 CFR 820 that includes a post-market surveillance requirement. The FDA QSR focuses on reactive elements such as:

  • 21 CFR 820.100 – CAPA
  • 21 CFR 820.198 – Complaint Handling
  • 21 CFR 803 – Medical Device Reporting
  • 21 CFR 820.200 – Servicing
  • 21 CFR 820.250 – Statistical Techniques

The FDA does occasionally require 522 Post-Market Surveillance Studies for devices that demonstrate risks that require post-market safety studies. In addition, most Class 3 devices are required to conduct post-approval studies (PAS). For Class 3 devices, the FDA requires the submitter to provide a plan for a post-market study. Once the study plan is accepted by the FDA, the manufacturer must report on the progress of the study. Upon completion of the study, most manufacturers are not required to continue PMS.

How will the FDA enforce compliance with ISO 13485?

It is not clear how the FDA would enforce compliance with Clause 8.2.1 in ISO 13485 because there is no substantively equivalent requirement in the current 21 CFR 820 regulations. The QSR is 26 years old, and the regulation does not mention cybersecurity, human factors, or post-market surveillance. Risk is only mentioned once by the regulation, and software is only mentioned seven times. The FDA has “patched” the regulations through guidance documents, but there is a desperate need for new regulations that include critical elements. The transition of quality system requirements for the USA from 21 CFR 820 to ISO 13485:2016 will force regulators to establish policies for compliance with all of the quality system elements that are not in 21 CFR 820.

Companies that do not already have ISO 13485 certification should be proactive by 1) updating their quality system to comply with the ISO 13485 standard and 2) adopting the best practices outlined in the following related standards:

  • AAMI/TIR57:2016 – Principles For Medical Device Security – Risk Management
  • IEC 62366-1:2015 – Medical devices — Part 1: Application of usability engineering to medical devices
  • ISO/TR 20416:2020 – Medical devices — Post-market surveillance for manufacturers
  • ISO 14971:2019 – Medical Devices – Application Of Risk Management To Medical Devices
  • IEC 62304:2015 – Medical Device Software – Software Life Cycle Processes
  • ISO/TR 80002-1:2009 – Medical device software — Part 1: Guidance on the application of ISO 14971 to medical device software
  • ISO/TR 80002-2:2017 – Medical device software — Part 2: Validation of software for medical device quality systems

What is the potential impact of the US FDA requiring software, risk management, cybersecurity, human factors, and post-market surveillance as part of a medical device company’s quality system?

Why modernize 21 CFR 820 to ISO 13485? Read More »

Best human factors questions?

1 Comment / 510(k), FDA, Human Factors, Usability / By /

Best human factors questions to ask the FDA during a pre-submission meeting, and what information content do you need in a 510k?

Human factors questions to ask the FDA?

The FDA did not start enforcing the requirement to apply human factors and usability engineering to medical device design until 2017 because the final version of the human factors guidance document was not released until February 3, 2016. Approximately ninety percent of the human factors testing reports submitted to the FDA in 510k pre-market submissions are deficient because the 510k submission content only includes the final summative testing report. The FDA needs a complete usability engineering file, and the human factors information needs to comply with FDA guidelines for the format and content of a 510k pre-market submission–not just IEC 62366-1:2015.

Follow the FDA guidance 1024x180 Best human factors questions?

What human factors information does the FDA want?

For several years, FDA submission deficiency letters indicated that you should not include the frequency of occurrence in your estimation of use-related risks. Still, the FDA never provided this information in a guidance document. On December 9, 2022, the FDA finally released a draft human factors guidance regarding the format and content of a 510k pre-market submission. The new draft guidance includes a use-related risk analysis (URRA) requirement in table 2 (copied below).

Table 2 example of tabular format for the URRA 1024x354 Best human factors questions?

In this new draft FDA guidance, the FDA identifies three different human factors submission categories. For the first category, only a conclusion and high-level summary are needed. For the second category, a user specification is also needed. For the third category, you need a comprehensive human factors engineering report with the following elements described in Section IV of the draft FDA guidance:

Submission Category 1, 2, and 3

  • Conclusion and high-level summary

Submission Category 2 and 3

  • Descriptions of intended device users, uses, use environments and training
  • Description of the device-user interface
  • Summary of known use problems

Submission Category 3 only

  • Summary of preliminary analyses and evaluations
  • Use-related risk analysis to analyze hazards and risks associated with the use of the device
  • Identification and description of critical tasks
  • Details of validation testing of the final design

Before spending tens of thousands or hundreds of thousands of dollars on human factors testing, you want to ensure the FDA agrees with your human factors testing plan. Otherwise, you will pay for the testing twice: once for your initial submission and a second time in your response to the FDA request for additional information to address deficiencies. Testing can cost more than your electrical safety testing. The facility needs the right equipment and space for the testing; you need support personnel to set up the equipment; you need to recruit participants; you need to compensate participants; and you need device samples.

When can you ask the FDA human factors questions?

The FDA cannot provide consulting advice on a submission, and the agency will not review data during pre-submission meetings. The FDA can provide feedback on protocols, specifications, and scientific justifications. Therefore, you should submit questions to the FDA in a pre-submission when you have a draft protocol, a draft specification, or a draft justification for why a task is not critical. Pre-submissions are “non-binding.” You can change your design and approach to human factors. Therefore, don’t wait until your information is 100% finalized. Share your documentation at the draft stage during the development phase and before your design freeze. You need these answers when you are planning a study and obtaining quotes. 

What are the best human factors questions to ask in a pre-sub?

In the FDA guidance for pre-submission meetings, the FDA provides suggested questions to ask:

  • Does the Agency have comments on our proposed human factors engineering process?
  • Is the attached use-related risk analysis plan adequate? Does the Agency agree that we have identified all the critical tasks?
  • Does the Agency agree with our proposed test participant recruitment plan for the human factors validation testing?

The above examples are only suggestions, but the best approach is to provide a brief example of what the human factors information will look like and ask the FDA to comment on the examples. The FDA does not have time to review data during a pre-sub meeting, but the FDA can review a few rows extracted from your URRA and comment on your proposed approach to the human factors process.

Human factors questions that are not appropriate

The FDA pre-submission guidance cautions you only to ask 3-4 questions for each meeting request because the FDA has difficulty answering more questions in a 60-minute teleconference. Therefore, you should not ask questions already answered in the FDA guidance. The new draft guidance includes examples of when a device modification can leverage existing human factors information and when new information is needed to support a premarket submission. Instead of asking a question specific to leveraging existing human factors information, provide your rationale for leveraging existing data and ask if the FDA has any concerns with your overall approach to human factors.

Recommended human factors action items

Create a procedure for your human factors process that includes detailed instructions for creating the information required in a usability engineering report and templates for each document.

Best human factors questions? Read More »

Software validation documentation for a medical device

Leave a Comment / 510(k), FDA, Software Verification and Validation / By / , , , , , , , ,

Learn why you need to start with software validation documentation before you jump into software development.

When do you create software validation documentation for a medical device or IVD?

At least once a week, I speak with the founder of a new MedTech company that developed a new software application as a medical device (SaMD). The founder will ask me to explain the process for obtaining a 510(k), and they want help with software validation documentation. Many people I speak with have never even heard of IEC 62304.

Even though they already have a working application, usually, validation documentation has not even been started. Although you can create all of your software validation documentation after you create a working application, certain tasks are important to perform before you develop software code. Jumping into software development without the foundational documentation will not get your device to market faster. Instead, you will struggle to create documentation retroactively, and the process will be slower. In the end, the result will be a frustrating delay in the launch of your device.

What are the 11 software validation documents required by the FDA?

In 2005 the FDA released a guidance document outlining software validation documentation content required for a premarket submission. There were 11 documents identified in that guidance:

software validation documentation 1024x385 Software validation documentation for a medical device

What the FDA guidance fails to explain is that some of these documents need to be created before software development begins, or your software validation documentation will be missing critical design elements. Therefore, it is important to create a software development plan that schedules activities that result in those documents at the right time. In contrast, four of the eleven documents can wait until your software development is complete.

Which of the software validation documents can wait until the end?

The level of concern only determines what documents the FDA wants to review in a submission rather than what documents are needed for a design history file. In fact, the level of concern (LOC) document is no longer required as a separate document in premarket submissions using the FDA eSTAR template because the template already incorporates the questions that document your LOC. The revision level history document is simply a summary of revisions made to the software during the development process, and that document can be created manually or automatically at the end of the process, or the revision level history can be a living document that is created as changes are made. The traceability matrix can also be a living document created as changes are made, but its only purpose is to act as a tool to provide traceability from hazards to software requirements, to design specifications, and finally to verification and validation reports. Other software tools, such as Application Lifecycle Management (ALM) Software, are designed to ensure the traceability of every hazard and requirement throughout the entire development process. Finally, unresolved anomalies should only be documented at the time of submission. The list may be incomplete until all verification and validation testing is completed, and the list should be the shortest at the time of submission.

What documentation will be created near the end of development?

The software design specification (SDS) is typically a living document until your development process is completed, and you may need to update the SDS after the initial software release to add new features, maintain interoperability with software accessories, or change security controls. The SDS can not begin, however, until you have software requirements and the basic architecture defined. The verification and validation activities are discrete documents created after each revision of the SDS and must therefore be one of the last documents created–especially when provided to the FDA as a summary of the verification and validation efforts.

Which validation documents do you need first?

At the beginning of software development, you need a procedure(s) that defines your software development process. That procedure should have a section that explains the software development environment–including how patches and upgrades will be controlled and released. If you don’t have a quality system procedure that defines your development process, then each developer may document their coding and validation activities differently. That does not mean that you can’t improve or change the procedure once development has begun, but we recommend limiting the implementation of a revised procedure when making major software changes and discussing how revisions will be implemented for any work that remains in progress or has already been completed.

When do the remaining software validation documents get created?

The remaining four software validation documents required for a premarket submission to the FDA are:

  1. Software description
  2. Software hazard analysis
  3. Software requirements specification (SRS)
  4. Architecture design chart

Your development process will be iterative, and therefore, you should be building and refining these four documents iteratively in parallel with your software code. At the beginning of your project, your design plan will need a brief software description. Your initial software description needs to include the indications for use, a list of the software’s functional elements, and the elements of your user specification (i.e., intended patient population, intended users, and user interface). If you are using lean startup methodology, the first version of your device description will be limited to a minimal viable product (MVP). The target performance of the MVP should be documented as an initial software requirements specification (SRS). This initial SRS might only consist of one requirement, but the SRS will expand quickly. Next, you need to perform an initial software hazard analysis to identify the possible hazards. It is important to remember that software hazards are typically hazardous situations and are not limited to direct physical harm. For each potential hazard you identify in your hazard analysis, you will need a software requirement to address each hazard, and each requirement needs to be added to your SRS. As your software becomes more complex by adding software features, your device description needs to be updated. As you add functions and requirements to your software application, your SRS will need updates too. Finally, your development team will need a tool to track data flow and calculations from one software function to the next. That tool is your architecture design chart, and you will want to organize your SRS to match the various software modules identified in your architecture diagram. This phase is iterative and non-linear, you will always have failures, and typically a team of developers will collaborate virtually. Maintaining a current version of the four software documents is critical to keeping your development team on track.

How do you perform a software hazard analysis?

One of the most important pre-requisite tasks for software developers is conducting a hazard analysis. You can develop an algorithm before you write any code, but if you start developing your application to execute an algorithm before you perform a software hazard analysis, you will be missing critical software requirements. Software hazard analysis is different from traditional device hazard analysis because software hazards are unique to software. A traditional device hazard analysis consists of three steps: 1) answering the 37 questions in Annex A of ISO/TR 24971:2020, 2) systematically identifying hazards by using Table C1 in Annex C of ISO 14971:2019, and 3) reviewing the risks associated with previous versions of the device and similar competitor devices. A software hazard analysis will have very few hazards identified from steps 1 and 2 above. Instead, the best resource for software hazard analysis is IEC/TR 80002-1:2009. You should still use the other two standards, especially if you are developing software in a medical device (SiMD) or firmware, but IEC/TR 80002-1 has a wealth of tables that can be used to populate your initial hazards analysis and to update your hazard analysis when you add new features.

How do you document your hazard analysis?

Another key difference between a traditional hazard analysis and a software hazard analysis is how you document the hazards. Most devices use a design FMEA (dFMEA) to document hazards. The dFMEA is a bottom-up method for documenting your risk analysis by starting with device failure modes. Another tool for documenting hazards is a fault tree diagram.

Fault Tree Example from AAMI TIR 80002 1 2009 300x239 Software validation documentation for a medical device
Copied from Section 6.2.1.5 from AAMI / IEC TIR 80002-1:2009

A fault tree is a top-down method for documenting your risk analysis, where you identify all of the potential causes that contribute to a specific failure mode. Fault tree diagrams lend themselves to complaint investigations because complaint investigations begin with the identification of the failure (i.e., complaint) at the top of the diagram. For software, the FDA will not allow you to use the probability of occurrence to estimate risks. Instead, software risk estimation should be limited to the severity of the potential harm. Therefore, a fault tree diagram is generally a better tool for documenting software risk analysis and organizing your list of hazards. You might even consider creating a separate fault tree diagram for each module of your software identified in the architecture diagram. This approach will also help you identify the potential impact of any software hazard by looking at the failure at the top of the fault tree. The higher the potential severity of the software failure, the more resources the software team needs to apply to developing software risk controls and verifying risk control effectiveness for the associated fault tree.

Software validation documentation for a medical device Read More »

Auditing Risk Management Files

3 Comments / Auditing, CE Marking, ISO 14971:2019 (Risk Management), ISO Auditing, Remote Auditing / By / ,

What do you look at and look for when you are auditing risk management files to ISO 14971 and the new Regulation (EU) 2017/745?

Your cart is empty

Next week, November 15th @ Noon EST, you will have the opportunity to watch a live webinar teaching you what to look at and what to look for when you are auditing risk management files to Regulation (EU) 2017/745 and ISO 14971. Risk Management Files are one of the essential requirements of technical documentation required for CE Marking of medical devices. Most quality system auditors are trained on how to audit to ISO 13485:2016 (or an earlier version of that standard), but very few quality system auditors have the training necessary to audit risk management files.

Why you are not qualified to audit risk management files

Being a qualified lead auditor is not enough to audit the risk management process. When you are auditing a risk management file, you need risk management training and lead auditor training. To audit the risk management process, you will also need training on applicable guidance documents (i.e., ISO/TR 24971:2020) and applicable regulations (i.e., Regulation 2017/745 and/or Regulation 2017/746). There may also be device-specific guidance documents that specify known risks and risk controls that are considered state-of-the-art.

Creating an audit agenda

Once you have scheduled an audit of risk management files, and assigned a lead auditor, then the lead auditor needs to create an audit agenda. The audit can be a desktop audit that is performed remotely, or it can be an on-site audit. Regardless of the approach, the audit should include interviewing participants in the risk management process documented in the risk management file. As a rule of thumb, I expect a minimum of 30 minutes to be spent interviewing the process owner and one or more other participants. Then I spend an additional 60 minutes of auditing time reviewing documents and records.

Your audit agenda should specify the following items at a minimum:

  1. the method of auditing to be used,
  2. date(s) of the audit,
  3. the duration of the audit,
  4. the location of the audit, and
  5. the auditing criteria.

The auditor(s) and the auditee participants should be identified in the audit agenda. Finally, you should specify which documents and records are required for audit preparation. These documents will be used to help identify audit checklist questions and to determine a sampling plan for the audit. At a minimum, you will need a copy of the risk management procedure and a list of the risk management files that are available to audit. You may also want to request the audit plan for each of those risk management files.

What did you look at and look for during your risk management audit?

When you audit the risk management process, you could take any of the following approaches or a combination of more than one. You could audit the process according to the risk management procedure. You could audit the process according to the risk management plan(s) for each risk management file. You could audit using the process approach to auditing. Finally, you could audit in accordance with specific requirements in the ISO 14971:2019 standard and applicable regulations (i.e., Regulation 2017/745). Regardless of which approach you take, your audit notes and the audit report should identify which documents and records you sampled and what you looked for in each document. Providing only a list of the documents is not enough detail.

Creating an auditing checklist for risk management files

Auditors with limited experience are taught to create an audit checklist by creating a table that includes each of the requirements of the audit criteria. For a risk management file, this would include a list of each of the requirements in ISO 14971 for a risk management file (i.e., Clause 9???). However, this approach is more like the approach that you should be using for a gap analysis. The better approach for creating an audit checklist for risk management files is to start by creating a turtle diagram. In the “process inputs” section (i.e., step 2 of 7), you would add questions derived from your review of the risk management plan(s). In the “process outputs” section (i.e., step 3 of 7), you would add questions specific to the risk management report and other records required in a risk management file. In the “with whom” section (i.e., step 5 of 7), you would add questions related to training and competency. You might also identify additional people involved in the risk management process, other than the process owner, to interview as a follow-up trail. In the “how done” section (i.e., step 6 of 7), you would add questions specific to the procedure and forms used for the risk management process. Finally, in the “metrics” section (i.e., 7 of 7), you would verify that the company is conducting risk management reviews and updating risk management documentation in accordance with the risk management procedure and individual risk management plan(s).

Audits are just samples

Just because you can generate a lot of questions for an audit checklist does not mean that you are required to address every question. Audits are intended to be a “spot check” to verify the effectiveness of a process. You should allocate your auditing resources based on the importance of a process and the results of previous audits. I recommend approximately three days for a full quality system audit, and approximately 90-minutes should be devoted to a process unless it is the design control process (i.e., Clause 7.3 of ISO 13485) which typically requires three to four hours due to the importance and complexity of the design controls process. Therefore, you should schedule approximately 30 minutes to interview people for the risk management process and approximately 60 minutes should be reserved for reviewing documents and records. With this limited amount of time, you will not be able to review every record or interview everyone that was involved in the risk management process. This is why auditors always remind auditees that an audit is just a sampling.

Which records are required in a risk management file?

The contents of a risk management file is specified in ISO 14971:2019, Clause 4.5. There are only four bullets in that section, but the preceding sentence says, “In addition to the requirements of other clauses of this document.” Therefore, your risk management file should address all of the requirements in ISO 14971:2019. What I recommend is a virtual risk management folder for each risk management file. As the auditor, you should also request a copy of the risk management policy and procedure. An example of what this would look like is provided below. The numbers in front of each subfolder correspond to the sub-clause or clause for that requirement in ISO 14971:2019.

Risk Management File Example Auditing Risk Management FilesWhich records are most valuable when auditing risk management files?

As an auditor, I typically focus on three types of targets when auditing any process. First, I will sample any corrective actions implemented in response to previous audit findings. Second, will sample documents and records associated with any changes made to the process. Changes would also include any changes that were made to individual risk management files or the creation of a new risk management file. Finally, my third target for audit sampling is any item that I feel is at risk for safety or performance failures. The severity of the safety or performance failure is also considered when prioritizing audit sampling. In the context of a risk management file, I always verify that production and post-production activities are being conducted as planned. I try to verify that risk analysis documentation was reviewed for the need to update the documentation in response to complaints and adverse events.

More auditor training on risk management files

We are recording a live webinar intended to teach internal auditors and consultants how to perform a thorough audit of risk management files against the requirements of the new European Regulation (EU) 2017/745 and ISO 14971.

PXL 20221101 183748328 Auditing Risk Management Files
Auditing Risk Management Files
In this new webinar, you will learn how to conduct a process audit of risk management files. You will learn what to look at and what to look for in order to verify compliance with Regulation (EU) 2017/745 and ISO 14971:2019. The webinar will be approximately one hour in duration. Attendees will be invited to participate in the live webinar and receive a copy of the native slide deck. Anyone purchasing after the live event will receive a link to download the recording of the live event and the native slide deck.
Price: $64.50

In addition to this webinar on auditing risk management files, we also have other risk management training webinars available. The webinar on auditing risk management files will be hosted live on November 15, 2022 @ Noon EST (incorrect in the live video announcement).

Auditing Risk Management Files Read More »

What is the De Novo review timeline?

4 Comments / De Novo / By

The new FDA goal is to reduce the De Novo review timeline to 150 days for 70% of De Novo submissions, but how long does it take now?

What is an FDA De Novo submission?

An FDA De Novo submission is an application submitted to the FDA for creating a new device product classification. There are three classifications of devices by the FDA: Class 1, Class 2, and Class 3. Class 1 devices are the lowest-risk devices, and they only require general controls. Class 2 devices are moderate-risk devices that require “Special Controls,” and Class 3 are high-risk devices that require Pre-Market Approval (i.e., PMA). De Novo applications can only be submitted for Class 1 and Class 2 devices, and most of the De Novo submissions require clinical data to demonstrate that the clinical benefits of the new device classification outweigh the risks of the device to patients and users. It’s the need for clinical data that is partly responsible for the longer De Novo review timeline.

What is the De Novo review timeline?

Initially, the FDA required that Class 2 devices must be first submitted as a 510k submission. If the device did not meet the criteria for a 510k, then the company could re-submit a De Novo Classification Request to the FDA. On July 9, 2012, the regulations were revised to allow companies to submit De Novo Classification Requests directly. This makes sense because some devices have novel indications for use, and submission of a 510k would be a complete waste of time in money. For example, the first SARS-COV-2 test had to be submitted as a De Novo by Biofire to obtain permanent approval for the test instead of emergency use authorization (EUA). This change in 2012 dramatically reduced the De Novo review timeline.

On October 4, 2021, the FDA published a final rule for De Novo Classification Requests. This new regulation identified the De Novo review timeline as 120 calendar days. Even though 120 days is 30 days longer than the FDA review clock for a 510k, the actual timeline to review De Novo submissions was much longer.

Every five years, when Congress reauthorizes user fee funding of the FDA, new MDUFA goals are established. The draft MDUFA performance goals (which impact FDA funding) were published recently. The specific performance goal to review De Novo submissions is:

FDA will issue a MDUFA decision within 150 FDA Days for 70% of De Novo requests.

There are two problems with this goal. First, the term “FDA Days” is based on calendar days minus the number of days the submission was placed on hold, and we don’t have any visibility into the number of days submissions are placed on hold. In the past, submissions could be placed on hold multiple times during the Refusal to Accept (RTA) screening process, and the “FDA Days” is reset to zero days each time the company receives an RTA hold letter. In addition, even after the submission is finally accepted, the FDA places the submission on hold when they request additional information (i.e., AI Hold). RTA and AI Hold periods can last up to 180 days, and during the Covid-19 pandemic, companies were allowed to extend this up to 360 days.

The second problem with the MDUFA goal is that we only have visibility into the outcome of De Novo submissions that were granted. More than 60 De Novo submissions are submitted each year, but the number of De Novo Classification Requests granted ranged between 21 and 30 over the past three years. Therefore, the 50%+ of De Novo applications denied could skew the % of submissions that meet the MDUFA goal for the De Novo review timeline.

What is the FDA track record in reviewing a De Novo?

Every CEO I speak with asks the same question: “How long does the FDA review take?” In preparation for a webinar I taught about De Novo Classification Requests in 2019, I researched the latest De Novo review timelines. I expected the review timelines to be close to 150 calendar days because the FDA decision goal was 150 FDA days. The 150-day goal was set in 2018 when Congress approved MDUFA IV. The 2019 data held two surprises:

  1. only 21 De Novo requests were granted in 2019, and
  2. the average review timeline was 307 calendar days (i.e., the range was 108 days to 619 days).

FDA days are not the same as calendar days. Only 23.8% of De Novo submissions were reviewed within 150 calendar days. The FDA doesn’t calculate the number of FDA days as calendar days, but there is no way to know how much time each De Novo spent on hold publicly. Upon seeing the announcement of a new decision goal for MDUFA V on October 5, 2022, I decided to revisit my previous analysis.

De Novo review timeline What is the De Novo review timeline?

*Only 9+ months of data for 2022, because data was collected on October 17, 2022.

We can blame the Covid-19 pandemic for the slower De Novo review timeline during the past few years, but you would expect a longer average duration in 2020 if that was the root cause of the FDA’s failure to achieve the MDUFA IV target of 150 calendar days. You would also expect 2021 to have the longest review timelines. Instead, the review timelines are the slowest for 2022. The number of De Novo submissions remains small, and therefore it is hard to be conclusive regarding the root cause of the failure to reach the 150-day decision goal. In addition, the percentage of De Novo applications granted within 150 calendar days was lowest in 2021, as you would expect if the reason for delays is primarily due to the Covid-19 pandemic.

Is there any good news?

The FDA is allowing the new eSTAR templates to be used for De Novo Classification Requests. These new electronic submission templates standardize the format of all 510k and De Novo submissions for FDA reviewers. The eSTAR also forces companies to answer all questions in the FDA reviewer’s checklist to ensure the submission is complete and accurate before the new submission is submitted to the FDA.

The new eSTAR templates were first used in 2021, and our firm has observed shorter overall review timelines and fewer deficiencies identified by FDA reviewers when they submit an “Additional Information Hold” (AI Hold) to companies.

How can the FDA improve De Novo timelines?

The FDA, industry, and Congress seem to be taking the same approach pursued five years ago to improve the review timeline for De Novo submission. MDUFA V authorized additional user fees for De Novo submissions (i.e., 17.8% increase), and the FDA will be authorized to hire additional employees each year during MDUFA V if the performance goals are met. However, there are three other options that the FDA and industry should have seriously considered during the FDA-industry negotiations.

The first option that should have been considered is to allow third-party reviewers to review the elements of a De Novo that are identical to a 510k submission:

  1. sterilization validation
  2. shelf-life testing
  3. biocompatibility testing
  4. software validation
  5. electrical safety testing
  6. EMC testing
  7. wireless testing
  8. interoperability testing
  9. benchtop performance testing
  10. animal performance testing
  11. human factors engineering

The above approach would require blended pricing where the FDA charges a smaller user fee than a Standard De Novo user fee, and the third-party reviewer charges a smaller fee than a 510k. The combined cost would be higher than the FDA Review of a De Novo, but this would reduce the number of hours the FDA needs to complete their review of a De Novo, and it would allow for pricing that is much lower than the De Novo standard user fee for qualified small businesses.

A second approach would be to pilot a modular review approach. A modular review would be similar to modular reviews for PMA submissions. In a modular review, the FDA can review most submission sections and provide feedback before the human clinical performance data is available. This would not help the few De Novo submissions that do not include human clinical performance data, but this would have a profound positive impact on most De Novo projects. First, the FDA would be able to complete the review of all sections in the submission except the human clinical performance data without delaying the final De Novo decision. Second, a successful review of non-clinical data by the FDA would give investors more confidence to fund pivotal clinical studies required to complete the De Novo submission.

A third approach would be for the FDA to force manufacturers to submit testing plans and protocols as pre-submissions to the FDA. This approach would give the FDA more familiarity with each device and the testing plan before reviewing the data. This approach would also reduce the hours FDA reviewers spend reviewing data that doesn’t meet the requirements and writing deficiencies. This approach would also give investors more confidence to fund De Novo projects for all V&V testing.

What is the De Novo review timeline? Read More »

Scroll to Top