IEC 62304, the international standard that defines software development life-cycle requirements for medical device software, was developed from the perspective that product testing alone is insufficient to ensure patient safety. It provides a common framework for medical device manufacturers to develop software components. Conformance with this standard demonstrates that there is a software development process in place that fulfills the requirements of the European Union’s Medical Devices Directive 93/42/EEC.
ADVERTISEMENT |
If your medical device has software that regulates its functionality in a way that contributes to basic safety or essential performance, then you’ll need to comply with IEC 62304. This standard requires all aspects of the software development life cycle (SDLC) to be appropriately managed to ensure patient safety, including:
• Development and code reviews
• Risk management
• Configuration management
• Incident and bug resolution
• Validation
• Maintenance
The most common mistake medical device manufacturers make is failing to assess which elements of risk their software mitigates. These are the elements that must be addressed by IEC 62304. For example, what would happen if the creator of a hoist didn’t properly vet the software that signaled the hoist to lower the patient at a certain speed? If a patient were lowered too quickly, or not at all, there would be a risk management nightmare. Since software plays a role in the basic safety functions of the hoist, it must comply with 62304’s requirements.
Common compliance issues
Common software functionality that manufacturers fail to recognize as IEC 62304 compliance issues include:
• Alarms and alerts: Often an essential performance requirement because they are intended to detect abnormalities
• Speed and position sensors: Use of software to limit range of motion, speed, and force, which are basic safety concerns
• Algorithms: Remove the software, and the device is no longer able to operate as intended, which means the algorithms are part of essential performance
It’s critical to have clearly defined processes for your company, and your software development life cycle in particular. IEC 62304 identifies several expectations related to the information that should be included in your SDLC procedures, including:
• Documentation of your process: Document management is essential for meeting compliance goals
• Software of unknown pedigree (SOUP): Manage your SOUP appropriately
• Document development: Make certain you are sufficiently resourced to support document development needs
• Version control and updates: Clearly define software updates and how software will be maintained in a validated state
Medical device manufacturers frequently seek third-party software development assistance, but the manufacturer remains responsible for the safety and compliance of its device. Important areas to consider when contracting out your software development include:
• Supplier management process: Confirm that your software vendor complies with IEC 62304 and their processes are reviewed during vendor audit
• Quality agreement: Confirm that the agreement defines vendor responsibilities and IEC 62304 deliverables; and vendor procedures used for software development will be provided to you and the test lab for review
• Establish your SDLC: At minimum, your process will define acceptance criteria (i.e., IEC 62304 compliance and deliverables) from your vendor
Preparing for compliance to IEC 62304
To start, know that compliance with this standard is defined as implementing all of the processes, activities, and tasks identified in the standard in accordance with the software safety class. IEC 62304 does prescribe a particular organizational structure or specific format for documentation. Compliance is determined by a review of all required documentation, including the risk management file.
IEC 62304 compliance will be reviewed to ensure:
• It contains all required documentation, including a risk management file
• Procedures meet the requirements of the standard
• Each checklist item is satisfied
• A product review is conducted as well as a review of the relevant software segments if it has been decided that the software performs basic safety or essential performance for your device
If you get caught in any of the above-mentioned pitfalls, you’ve probably got a problem. You’ll either not receive a report at all, or you’ll receive a report that says you failed somewhere in IEC 60601-1 or IEC 62304.
Because the standards are voluntary in the United States, you don’t necessarily have to make product changes. However, for each “fail,” you’ll be required to provide justification for each deviation. If you have valid justification, your device should still attain regulatory approval from the FDA, although developing this justification can be a lengthy process in itself. In the end, though, you may find it more efficient to comply with IEC 62304 to begin with.
First published April 30, 2015, on the AssurX blog.
Add new comment