Safety, Security and IEC 62304 Compliance
Before we begin, let’s define and disambiguate safety and security. Safety is about protecting people and equipment when a device malfunctions (like risk of injury and death). Meanwhile, security is about protecting the device and network from the negative influences of the outside world (like risk of patients’ personal data being leaked).
Despite the distinction, security issues can easily become safety issues. For example, a malicious cyber-attack, designed to disable or subvert safety mechanisms in the device can be disastrous. Likewise, if a safety issue is found, future attacks can trigger a security issue.
In order to define the safety and security requirements, the International Electrotechnical Commission (IEC) implemented a software lifecycle process foundation with the creation of IEC/ISO 62304 as the lead standard that defines the steps from beginning of the software development process through the completion and maintenance.
1. Classify software systems based on the patient impact if they fail
This classification include: • Class A: No injury or damage • Class B: Non-serious injury• Class C: Death or serious injury. However, interdependence between hardware and software makes these categories less rigid. For example, in a Class C device if the software system is not directly involved in treating a patient, and if the data is available through other mechanisms, the software system can be Class A.
2. Define device requirements, covering every possible aspect of operation
There are 12 categories of requirements that run from the obvious (e.g., functional capabilities) to several topics that are rarely considered in other industries, such as alarms, regulatory requirements, in-field maintenance requirements, etc.
The collection of the requirements and the device risk analysis must be in sync, and when one changes, the other must be considered.
3. Define the software architecture and design
The system architecture and software design – segregation, verification, operation, maintenance, installation, and commissioning must all be considered.
Much like the risk analysis and the requirements, the influence between the architecture and design is such that a change to one, triggers the review of the other (and perhaps the risk analysis and requirements as well).
4. Develop the device’s software units and perform unit testing
Once the components have been created, they must be verified at the unit level as stand-alone elements. This allows for a deeper and more complete level of verification for each component before system integration and it increases the likelihood that latent defects will be uncovered. Note that verification at this level does not just mean unit testing, but also includes activities like static code analysis and inspections. IEC 62304 also requires software development to consider fault handling, memory management, data and control flow, etc. as part of the unit verification.
5. Integrate the device components
Once the system’s components have been individually verified, they must then be integrated. Special attention must be given to components that were not developed by internal teams and processes. For life critical systems, you need to use trusted suppliers, with well-defined processes, and preferably with certified/certifiable solutions to support safety requirements.
6. Validate that all safety requirements are fulfilled
At this point the device has come together, and the system requirements have been verified. It is necessary to make certain that all of the original requirements have formal tests associated with them, that they are executed correctly, and that the records are available as part of the regulatory acceptance process.
When it comes to safety and security of medical devices, there is a lot more depth that can be delved into. There are steps beyond this (release, manufacturing, maintenance, etc.), but they are out of the scope of this blog. For now.
Learn more in this recent white paper Building Functionality Safety and Security into Medical Devices
