Medical device manufacturers must systematically record and evaluate stakeholder requirements and prove they have been met. A distinction must be made between different types of stakeholder requirements.
Content
This page gives you a quick overview of the following:
“A requirement that describes what a stakeholder group (legislator, purchasing decision-maker, operator, user) expects a system to provide to satisfy one or more needs.”
Source: adapted from ISO/IEC 15288
Stakeholders are people who have claims or interests in a company, device, or project. These include:
| Requirement type | Description | Example |
| User requirements | Requirements for efficient output with an interactive system (e.g., software) | The user must be able to recognize at the systems all patients who are hepatitis positive. |
| Legal requirements | Requirements from legislators and authorities, e.g., in the form of guidelines, laws, regulations, standards, etc. | Only authorized persons are allowed to see the patient’s laboratory values (data protection). |
| Output requirements | Requirements for the completeness and correctness of a work result | The hepatitis value must be stated in the doctor’s letter precisely to one decimal place. |
| Organizational requirements | Requirements for the conduct of persons or organizational units in the provision of work results | Doctors must document the ward round. |
| Market requirements | Requirements that are decisive or relevant for the purchase decision | The software must run on both Windows and Linux. |
Manufacturers should derive the system requirements from the stakeholder requirements.
The requirement types do not have to be disjoint (non-overlapping). For example, a legal (regulatory, statutory) requirement could be that prescribing medication without inspection of drug interactions and contraindications is prohibited. This means that a legal requirement leads directly to a user requirement, e.g.:
“The user must be able to recognize drug interactions (and their potential effects on the patient) on the system.”
You can find further information in the following articles:
The different types of stakeholder requirements need different methods to assess whether they are fulfilled.
| Requirement type | Methods to verify / validate that the requirements are met |
| User requirements | The inspection includes a usability validation (summative evaluation). |
| Market requirements | Most market requirements correspond to system requirements, which are verified by inspection. |
| Output requirements
(for the work result) |
Depending on the type, these requirements are verified (e.g., by inspection) or/and validated e.g., by clinical evaluation. |
| Organizational requirements | These are not directed at the device but at people and cannot be verified or validated. |
| Legal requirements | Legal / statutory requirements can lead to user requirements (which must, therefore, be validated accordingly) or directly to system requirements, which must be verified. |
| Other requirements, e.g. investor requirements for turnover, number of devices sold, development time | How these figures can be reviewed is obvious but not interesting from a regulatory perspective. |
Read more about the difference between verification and validation.
All standards for quality management (e.g., ISO 9001, ISO 13485, or 21 CFR part 820) require the manufacturer to identify stakeholder requirements.
ISO 13485:2016 distinguishes requirements that customers state from requirements that customers don’t state but are necessary for the device to fulfill its intended purpose.
The authors of the standard seem to be aware that customer requirements cannot be asked for directly.
The regulations mentioned also require manufacturers to meet the stakeholder requirements (in particular, the intended purpose).
IEC 62304 adopts the mapping with the V-model from IEC 60601-1 – including errors: It states that you would validate against the PEMS requirements. But PEMS requirements are system requirements. (The “S” in PEMS stands for system.) System requirements are verified, not validated.
Fig. 1: IEC 60601-1 confuses the different types of requirements..
The standard also claims that the PEMS requirements result from user needs. The term “user need” is not defined. However, system requirements do not result from stakeholder needs but from stakeholder requirements.
Many stakeholder requirements, such as user requirements, cannot be derived by directly asking the stakeholders (in this case, the users). If you ask users about their requirements, you will not receive user requirements but user requests.
You can read more about the difference between user requirements and requests here.
Do you still have questions about the requirements? You can get answers in our free micro-consulting.
Through usability tests in the Johner Institute’s labs, you ensure that the stakeholder requirements in particular user requirements are verified and validated in accordance with the standard and that your devices are successful, thanks to their usability.
Get in touch right here if you would like support. We will be happy to help you collect and verify all relevant requirements quickly, efficiently, and in compliance with the law. This will ensure that your devices are safe and in demand and can be brought to 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