In Part 1 of this blog, I described the background and approaches StarFish Medical employed for more modern devices with a comprehensive technical file, giving five top tips. In Part 2, I now describe how we recertified for older devices where the available design documentation was less comprehensive.
For those unfamiliar, all medical devices (i.e., equipment that is intended to diagnose, treat, or monitor a patient; make physical or electrical contact with a patient; transfer energy to or from a patient; and/or detect energy transfer to or from a patient) must be electrical safety tested. I found a common misconception in that many manufacturers/designers do not realize that Class I devices, commonly thought of as low risk and typically not requiring regulatory clearance before being marketed (omitting special cases such as sterile equipment or those with a measuring function), must also comply.
Most users would agree that mandatory electrical safety testing is a good thing before devices are allowed on the market. IEC60601 Medical electrical equipment - Part 1: General requirements for basic safety and essential performance is the name of the Technical Standard that is widely recognized (at least Australia, Brazil, Canada, European Union, Japan, USA, and New Zealand all have more or less equivalent national versions) as the de-facto standard to demonstrate safety of electrical medical devices. The majority of healthcare regulatory bodies now require a manufacturer to demonstrate compliance to the 3rd edition of this standard, which introduces the concept of risk management, and is not purely prescriptive testing.
For legacy (10 year old) devices that have been on the market for many years, things are a little more complicated. We found that, apart from risk management, usability (collateral standard 60601-1-6) and software validation has generally been weakest, with “Essential Performance” requiring particular work due to the expanded requirements in 3rd edition. Essential Performance is often defined in the 60601-2-XX or 60601-3-XX collateral standards for a particular device class, but if not, then the manufacturer must state what the Essential Performance constitutes. As an example, any critical alarm is part of Essential Performance. We also found that, unless a critical issue regarding patient safety or Essential Performance was involved, the risk management file was often infrequently updated with post market surveillance information.
Also, we generally found scarce or less comprehensive input documentation like requirements specification, but good output documents like manufacturing drawings (i.e., the design intent was hard to ascertain). In these cases, we found it was actually more efficient to develop documentation from scratch, rather than attempting to “force” existing documentation.
Finally, sometimes a device may not have been initially designed for use in the home, but ends up being used in the home. IEC60601-1-11 is a collateral standard specifically intended to address medical devices used in the home, regardless of whether they are used by an expert or less skilled operator.
From this, here are my seven top tips for preparing documentation for 3rd edition 60601 testing for legacy products, in addition to the tips presented in Part 1:
- Create a Document Hierarchy Map in your Design or Quality Plan that clearly shows the relationship between design documents. Remembering that “a picture is worth a thousand words,” you are trying to illustrate how the Risk Analysis touches all aspects of the design. This also aids a test house reviewer in understanding the supplied documentation, as putting them in a bad mood is ill-advised. A typical example is below, but software may require more documents depending on device class.
- A detailed review of the post-market surveillance data (e.g., complaints, returns, MAUDE database) helps identify if there are any unaddressed issues (particularly usability) with the device, identifying showstopper that require rework.
- A detailed review of software in line with IEC 62304: “Medical device software – Software life cycle processes” and/or FDA document “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices,” is required to establish the depth of the software documentation required, as different device classes have different requirements. Minor updates to software might be necessary in order to provide appropriate instrumentation required for unit testing. Also, legacy devices sometimes have software doing things that are now frowned upon. In these cases, it is always better to perform a design tweak; however, if the risk is low, we have been successful in demonstrating that historical data shows a particular software failure mode is improbable, hence the risk is acceptable.
- If your device is used in the home, review the design intent and whether the risk analysis properly addresses the hazards and possible foreseeable misuse that may occur in the home environment. It can be that the skilled operator, rather than the less skilled operator, has more misuse cases, because their expectations are based on experiences with other equipment. If your device is a common piece of equipment, then usability variations between different manufacturers should also be considered.
- Review current manufacturing drawings to ensure that appropriate safety factors are in place. Although 60601 is perceived as an electrical standard, it has a lot to say about mechanical and structural integrity, and requires 4x safety factor for brittle parts and 2.5x elsewhere. Again, we have shown that 2.5x safety factor is acceptable for brittle parts where the risk is low and historical data demonstrates no failures.
- Technical specification should only contain measurable/testable items that are critical for Essential Performance or safety. Otherwise, subsequent verification can be unnecessary and time consuming (e.g., the color is blue or the presence of a manufacturer logo). One of the reasons for creating new documentation is that legacy documentation often contains a single input document, which combines usability, business/marketing requirements, and technical specifications, which should be relocated to the appropriate requirements document (i.e. usability, software, technical, etc.), or addressed in the architecture documents for branding, etc.
- Documenting Usability Validation can be achieved by performing literature review of clinical papers, review of FDA Maude database and post-market complaints, and by actors emulating specific-use cases called out by both the usability requirements and software usability. Often, manufacturers have close contact with clinicians, so the minutes from a focus group meeting can also be used as evidence in the validation report.
Finally, this process can reveal issues about the device that may not be welcome by some. However, I view these opportunities for making the device “better”; for example, the safety factors might work at 2.5x, but on the next spin of the device, 4x safety factor should be incorporated into the design. IEC 60601-1 3rd edition was actually first published in 2005 and has already been amended, so it will probably be updated in the future with more strict requirements. A product roadmap taking these and other foreseeable requirement into account is an essential part of continuous improvement.
I would welcome your comments, tips, and experiences in the comments section below.