Product developers around the world are being called on to help “flatten the curve” of the Coronavirus (COVID-19) impact, potentially saving millions of lives. Help is needed now, but where will these companies be when the pandemic subsides?
For those who haven’t met the right FDA requirements, the answer doesn’t include a market-viable product.
A partner that can help you mitigate this risk must have experience in maintaining product development pipeline health on a long-term timeline. They must also help you fill in gaps when your staff is distributed or your momentum is being stifled, guiding you through the “development mud” that can push even the best ideas to the wayside.
Companies developing medical devices are required to have an established quality management system that includes design controls. Following proper design control practices helps to ensure the safety and efficacy of a medical device and ultimately improves patient healthcare outcomes. Widely used medical device development standards include:
When College Park approached DornerWorks for engineering guidance prior to launching the Espire Elbow, their design hadn’t yet achieved FDA approval, but the company had a clear goal in mind. They wanted to launch a prosthetic elbow that would make life easier for healthcare practitioners and their patients.
DornerWorks engineers navigated College Park toward a mobile application for tablet usage, which allowed the practitioner ease of movement, and a greater understanding of their patient’s issues. We guided their interface toward a beautiful and simplified new design, streaming live data from the prosthetic device. The hardware team designed the boards to be used in the device, the firmware team wrote the software for the boards, and the web development team wrote the mobile app and website.
During software development for College Park, our engineers worked in line with the IEC 62304 Medical device software standard, a functional safety standard for software in medical devices. There are nine parts to the standard, but only the final five define the software development processes critical to eventual FDA approval:
DornerWorks has guided a number of companies through development aligned to FDA requirements, leaving them better positioned to obtain FDA approval and reach a successful launch. IEC 62304 is not the only standard medical device developers need to follow, but it is one of the most comprehensive when it comes to software development, and further defines requirements of code development documentation and processes for different classes of medical device software.
IEC 62304 identifies three safety classes for medical device software:
Class A – Devices that pose no potential injury or damage to health in case of failure.
Class B – Devices that pose non-serious injury or damage to health in case of failure.
Class C – Devices that could potentially lead to death or serious injury in case of failure.
The following table describes the various clauses of IEC 62304 involved in each class of medical device software.
Software Documentation | Class A | Class B | Class B |
---|---|---|---|
Software development plan | Must contain contents to sections 5.1 IEC 62304:2006. The plan’s content list increases as the class increases, but a plan is required for all classes. | ||
Software requirements specification | Software requirements specification conforming to 5.2 IEC 62304:2006. The content list for the software requirements specification increases as the class increases, but a document is required for all classes. | ||
Software architecture | Not required. | Software architecture to 5.3 IEC 62304:2006. Refined to software unit level for Class C. | |
Software detailed design | Not required. | Document detailed design for software units. (5.4). |
|
Software unit implementation | All units are implemented, documented and source controlled (5.5.1). | ||
Software unit verification | Not required. | Define process, tests and acceptance criteria (5.5.2, 5.5.3). Carry out verification (5.5.5). |
Define additional tests and acceptance criteria (5.5.2, 5.5.3, 5.5.4). Carry out verification (5.5.5). |
Software integration and integration testing | Not required. | Integration testing to 5.6 IEC 62304:2006. | |
Software system testing | Not required. | System testing to 5.7 IEC 62304:2006. | |
Software release | Document the version of the software product that is being released (5.8.4). |
List of remaining software anomalies, annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors. |
Medical device development and eventual FDA approval can be a complex process, and rightfully so. The same products capable of saving lives and relieving pain also run the risk of causing injury and death when they fail. Yet, as healthcare systems face equipment shortages during one of the most harrowing pandemics in more than a generation, the imperative of the FDA’s emergency use authorization is clear: The country needs your help as medical product developers.
With guidance from engineers who have been there before, you can be sure that your development is on track to save lives and eventually achieve the certifications you need to grow your business.
Contact us today and schedule a meeting with our team via teleconference.