How you can fulfill the requirements of ISO 14971, ISO 13485, IEC 62304 and IEC 60601-1 in a process
The most relevant standards for the development of medical devices such as ISO 13485, ISO 14971, IEC 62304, IEC 60601-1, and IEC 62366 have specific requirements for processes.
To meet these requirements, many medical device manufacturers formulate process descriptions (SOPs) separately. This means that staff members, especially the development department, must take many SOPs at the same time into account. Errors and omissions are almost inevitable.
This article aims to show how the risk management, the development activities and the SOPs can be "woven" into each other.
The process of developing a medical device starts before the actual development. One of the first tasks is to define the business expectations and the context in which the future product shall be used (1).
At this stage that, what the IEC 62366 somewhat misleadingly calls the "specification of application", should match the intended use. This precise and extended description of the intended use / intended purpose simultaneously fulfills the requirements of ISO 14971 Section 4.2.
During this early phase, the manufacturer should define the risk policy, respectively the risk acceptance criteria. Additionally, the manufacturer should perform a Preliminary Hazard Analysis PHA as the first part of the risk analysis. The hazards and risks that the product might cause frequently are already obvious by analyzing the product's intended use / purpose.
At the beginning of the development, in the second phase (2), the manufacturer should specify the risk management plan and possibly update the risk policy and the risk acceptance criteria. Thereby the company addresses the requirements according to the ISO 14971 chapter 3.
The third phase (3) covers the system respectively software requirements specification. I.e. in this development phase the manufacturer specifies the product as a black box and thus its behavior at its inputs and outputs.
An input and output analysis would help identify additional hazards and risks. This part of the risk analysis concludes the Preliminary Hazard Analysis and thus the identification and evaluation of major hazards respectively risks.
The risk analysis can be completed at the earliest when the developers have converted the requirements of the second phase in the specification / description of a technical solution - the architecture (3).
The way the product is to be constructed, introduces additional risks or helps to minimize risks. Here for example a FMEA would be used to identify further risks. This means that in phase (3) the risk analysis should be completed in large parts.
At the same time the planning of risk mitigation measures in accordance with ISO 14971 begins at the latest at this stage. In the risk management process, the architecture phase is thus a linchpin between risk assessment and risk control. But that is not to say that the architects should bear the brunt of risk management.
The implementation of the architecture and the proposed risk mitigation measures are in phase (5). The verification of the implementation and effectiveness of these measures during the test in phase (6).
The risk management process may not stop with the development and the development process. After the validation, or at the latest with the release of the product (7), the manufacturer shall submit the final risk-benefit assessment in which they must measure whether the benefits actually outweigh the hazards or risks.
As just indicated, neither the risk management process nor the risk analysis end with the development. As part of the post-production phase, the ISO 14971 demands a continuous re-evaluation of the risk acceptance criteria, an update of the risk assessment (e.g. on the basis of market data) and possibly new measures to mitigate risks.
As summary, we recommend that manufacturers consider the activities that the ISO 14971 requires in the SOP for the development process or link in the development SOP to the respective sections in the risk management SOP.