Many regulatory requirements demand that manufacturers define processes and procedures. Such requirements include, for example, EU regulations (MDR and IVDR), standards such as ISO 13485, IEC 62304, and ISO 14971, and the FDA.
Content
On this page, you will find references to articles on processes and procedures:
- Articles on processes and procedures in general
- Articles on individual processes and procedures
- Information on support for processes and procedures
1. Articles on processes and procedures in general
a) Differentiation between process instructions and standard operating procedures
The description of processes and procedures differs in their level of granularity. Processes describe WHAT is done. Standard operating procedures describe HOW something is done.
However, regulatory requirements do not always distinguish precisely between the two.
All instructions must ultimately determine
- who does what, when, in what order, and how
- and which input is converted into which output.
b) Articles
The processes and procedures are part of quality management. This overview page provides a helpful introduction to the topic of quality management.
The article on creating process and standard operating procedures is helpful. This should only be the task of the QM representative for selected processes.
Once the processes have been defined, they must be subjected to process validation.
Manufacturers should note the difference between process orientation and process management.
2. Articles on individual processes and procedures
a) Development
All manufacturers must define a development process. They should understand the boundaries and interactions between the development plan and process to do this.
Many manufacturers use agile development models for software development. On the other hand, documentation should follow a model more akin to the V-model.
Part of development involves risk management or the risk management process. Here, manufacturers must also analyze the risks posed by inadequate processes, for example, with a process FMEA (pFMEA).
b) Post-production phase
The processes must cover the entire life-cycle of the devices:
3. Support
The Johner Institute helps manufacturers of medical devices to establish lean and standard-compliant processes and procedures.
This enables you to develop and launch your devices quickly and safely in the planned time and at the scheduled cost.
Contact us so that we can draw up a plan together on how you can establish these processes and procedures in a short time and at minimal cost.
IVD medical device validation confirms the device’s medical purpose. IVD medical device verification, on the other hand, proves whether the IVD works as intended. In this article, we provide a five-step guide on how to carry out the verification and validation of your IVD medical devices in a targeted manner and without unnecessary effort. We…
Details
The same legal requirements apply to the clinical evaluation of software as to the clinical evaluation of all medical devices. This means that as a Medical Device Software (MDSW) manufacturer, you must prepare a clinical evaluation for your product just like any other manufacturer. A performance evaluation must be carried out for software that is an in vitro diagnostic…
Details
Process validation is the verification that a process meets the requirements imposed on its process results. Learn when you must validate which processes (in the context of software) and how to ace validation. Furthermore, find out what process validation has to do with PQ, IQ, and OQ. Process validation: What is it exactly? a) Definition…
Details
Software risk analysis depends on the following: Software itself cannot cause harm. It always happens via hardware or people. However, this does not mean there is no need for risk analysis in software. The opposite is the case! What distinguishes risk analysis for software from other medical devices In the case of (standalone) software, harm…
Details
Black box testing is when test cases are derived solely from the specification of the object to be tested (product, component). White box testing, on the other hand, derives the test cases from the internal structure of the object, e.g., from its source code or software architecture. Unfortunately, many medical device manufacturers neither specify the test…
Details