The Importance Of Software Validations For Medical Devices
by Eric Hinrichs, senior principal quality engineer (retired), Ethicon, part of the Johnson & Johnson Medical Device Companies
It’s in the best interest of medical device companies to be as rigorous and thorough as possible when testing software that runs their medical products. If a medical device should have a software issue/fault during a procedure, depending on the type and severity of the fault, the patient’s life could be in danger, or they could suffer irreparable damage. As for the company, put simply, their bottom line, reputation, and future growth may be impacted.
There isn’t any procedure that dictates specifically what should be performed during software validation, as it depends on what the software is supposed to do and what potential interactions could occur. It’s up to the project team to interpret software validation requirements by defining and identifying all program steps, all potential interactions, and the input-to-output expectations. In short, software validation is very much dependent on the team’s experience with and knowledge of the software design, the intended use of the product and software, and the anticipated use and misuse of the product.
I’ve known of software validations that took place where the software experts ran the validation and concentrated on only the prescribed functionality. This approach may guarantee a “successful” validation, but it does not really stress the software functionality as intended or unintended. Software testing should avail itself of all available resources.
Consider using consulting surgeons not involved in the project and have them read the instructions for use (IFU) and then simulate using the device. Observe what they do and don’t do. Observe what instructions were misunderstood or unclear that led to them using the device erroneously. Unfortunately, human nature being what it is, a lot of IFUs don’t get read, which is a good reason to make software as intuitive as possible and not rely strictly upon the IFU. If the device being developed is to be used with products from other manufacturers, or it could be, the project team should test the ways all these devices could or would interact with your product’s software.
These types of pre-validation efforts, along with your comprehensive risk documents, would contribute immensely toward developing an error-free software program. Remember, when filling out your risk documents, don’t dismiss misuses as not being possible. Human error, abuse, and misuse are significant categories when it comes to customer complaints. Don’t hesitate to make use of all the tools at your disposal.
A Hypothetical Scenario
Let’s consider a hypothetical example. Company A manufactures a generator for use with their ablation catheters. They decide to test their generator with two other catheters manufactured by companies Y and Z that are popular with surgeons. There are other less popular catheters on the market (Company X), but Company A decides not to test them due to their low popularity. As to the catheters they will test, they fail to look at ways the catheters themselves could be misused; focusing instead upon how the catheters are expected to be used. Company A decides to not to test these potential misuses because they were considered remote possibilities in their risk documents and, besides, it will save time and money not performing these tests.
In the field, Company A’s software runs well with their catheter and the catheter manufactured by company Y, but not as well with the catheter manufactured by company Z. Company Z’s catheter can develop char if used at too high a temperature; this is not the case with company Y’s catheter or their own catheter. This occurs when the surgeon fails to set the generator’s temperature properly. Since Company A did not stress its testing, it failed to see this difference. If it had, it could have potentially designed this drawback out of their product or warned of the issue in the IFU.
Unfortunately, several hospitals using Company A’s generator with catheters from company X run into software complications during several procedures. The hospitals submit product complaints against Company A, while several patients who suffered complications file lawsuits.
If Company A had tested all potential catheters and interactions, it could have possibly avoided the above scenario. That testing, along with testing all scenarios indicated in their risk documents, may have identified potential failure modes so they could look for ways to correct deficiencies. Maybe it would be possible to program the software to automatically detect which catheter is being used or have the surgeon input the catheter information so the software would be able to set a maximum temperature for a given catheter. Approaches such as these could minimize or avoid reliance upon the surgeon and/or the IFU. This approach may also help minimize potential human error, which, in turn, could reduce the potential for complaints.
Partnering To Find Solutions
While this is a hypothetical example, issues like this can and do occur when medical devices made by different manufacturers are used together during procedures. There are ways to address such potential errors. Some may be considered by management or the project leader as too time-consuming or too costly to pursue, but what is the cost of complaints and lost sales? One problem in advocating for such testing is that it’s difficult to show the benefits/cost savings of avoiding complaints.
One option during product development is to consider partnering with companies that make products your product may be used with. Don’t exclude potential third-party product if you are aware they could be used. It would have been beneficial for Company A to consult with other catheter manufacturers to determine if they have any concerns or limitations with their device being used with their generator and its software. This arrangement would also be a benefit when making software upgrades to ensure all potential devices that could be used continue to interact properly. This is a two-way street. Maybe the catheter companies will be making a design change that could negatively impact their catheter’s interface with Company A’s software. In the end, this type of cooperation may help your medical device be more intuitive to use and, consequently, preferred.
Conclusion
When developing software for a medical device, anything can happen when it is used in the field. Make full use of your risk documents and your company’s medical experts, challenge extreme handling and environmental conditions, and conduct simulations with surgical consultants to bulletproof your medical device’s software. Don’t ignore interfaces if your product is used in conjunction with external devices. Often, this is where most complaints arise. Coordinating with external device manufacturers can eliminate potential risks and errors. It’s your responsibility to detect, identify, and eliminate software glitches and instabilities. The more you test, the more you know and the safer and more efficacious your product will be, setting a standard for reliability and performance. Now, that is a nice place to be.
About the Author:
Eric Hinrichs has more than 31 years in the medical device field in research and development on new products and processes, in operations on improving processes, and in quality on leading process and product validations and performing data analysis. He developed and led the implementation of numerous process redesigns while at Ethicon to improve product support execution. He authored an ASTM standard, worked on updates to United States Pharmacopeia (USP) medical standards, and helped develop medical standards for the European Association of the Surgical Suture Industry (EASSI) in Europe. He has co-authored a medical standard for India that is currently under consideration for adoption. He recently released a book on career advice, Perceptions and Expectations.