Medical device manufacturers must determine the requirements for their devices and prove that these are met. This often leads to regulatory problems, partly because there are misunderstandings about the different types of requirements.
Content
This page provides a quick overview of:
There are links to further articles on all topics.
During the various development phases, the different types of requirements must be identified and fulfilled (see Fig. 1).
Fig. 1: The V-model shows the phases in which the requirements are collected. Stakeholder requirements (green); technical requirements (blue)
The stakeholder and technical requirements are subdivided into further types (see Fig. 2).
Fig. 2: The stakeholder requirements (green) and the technical requirements (blue) each have subtypes.
These articles present the different requirement types with the respective methods for elicitation and verification as well as the regulatory requirements in detail:
There are regulatory requirements for the requirements, specifically for the elicitation, tracking and verification of the requirements.
The regulatory requirements for medical devices oblige manufacturers to collect and provide evidence of these requirements.
Examples
The laws and standards also demand that manufacturers trace the requirements. Manufacturers should distinguish between two types of traceability:
Fig. 3: A distinction is made between horizontal traceability (dotted lines) and vertical traceability (dashed lines).
Traceability requires that the individual requirements are clearly identified, for example, with an ID.
The laws and standards oblige manufacturers to prove that the devices meet all the requirements placed on them. Many manufacturers equate requirements with acceptance criteria. Even though this often works in practice, the two terms are not synonymous.
Acceptance criteria describe how you decide whether you consider a requirement to be fulfilled.
If there is a requirement that a software unit should calculate the square of a number, then the acceptance criteria can be formulated as the test cases that are used to check this. But the test cases are not the requirement.
The Johner Institute recommends that the system requirements specify how a system behaves as a black box.
There are acceptance criteria that do not(!) affect this black box. These include, for example, compliance with coding guidelines for a software unit. This compliance would not be a requirement for the software unit itself but for its development.
The fact that the acceptance criteria are met is necessary but not sufficient to prove that the requirements are also met. In practice, however, proof of fulfilled acceptance criteria is usually enough as “objective evidence.”
Do you have questions about the requirements? You will receive answers via our free micro-consulting.
Contact us if you would like support. We will happily help you quickly, conveniently, and in compliance with the law to collect and verify all relevant requirements. This will ensure that your devices are safe and in demand and can be launched on the market quickly.
IEC 62366-1 uses the concept of (hazard-related) use scenario. The FDA uses the concept of critical (user) tasks. In development, one works with use cases and user stories. This diversity of terms makes a common understanding difficult. However, this is necessary to create consistent and legally compliant usability files and to avoid regulatory problems. This…
Details