Discover new articles every week on the topics of regulatory affairs (including international approval and FDA approval), QM systems (e.g., ISO 13485), risk management (ISO 14971), software development (IEC 62304), IT security, clinical evaluation, usability engineering (IEC 62366-1), and systems engineering (including IEC 60601-1, ISO 10993) - also for IVD medical devices.
Please note the pages for managers and beginners or filter by keywords (tags).
IEC 82304 is now available. This is a good reason to take a closer look at this standard for “health software products.” IEC 82304: Why another standard? Closing the IEC 62304 validation gap IEC 62304 was launched with the claim of being applicable to all medical device software – whether standalone or embedded. However, the…
DetailsSoftware 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…
DetailsThe FDA MAUDE database provides information on the “Manufacturer and User Facility Device Experience.” It thus corresponds roughly to the database used by the BfArM to publish manufacturer reports on risks. Content of the FDA MAUDE database The FDA MAUDE database contains information on Regulatory background Obligation to evaluate Manufacturers are obliged to conduct adequate…
DetailsIEC 60601-1 defines a PESS, a Programmable Electronic Subsystem, as a system based on one or more central processing units, including their software and interfaces. The standard does not reveal what it means by system; in this context, it is a medical device component. For this, IEC 60601-1 sets out specific requirements for the PESS.…
DetailsThe software architecture documentation primarily serves these objectives: Fast, effective, and plannable software development will succeed if the task (to develop software that meets the software requirements) is broken down into solvable subtasks, which can be distributed among many developers. The prerequisite for this is a precise (documentation of the) software architecture, which is unfortunately…
DetailsBlack 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…
DetailsMany people ask about the liability of individuals, management, and the company. After all, it is not only the Medical Devices Regulations that impose fines and imprisonment. The question of liability also arises for development service providers. Liability in Germany: Differentiating between criminal and civil law Civil law: Parties involved In civil law, the question…
DetailsFault Tree Analysis is a procedure used to search for unknown causes of known effects (in the case of medical devices, harms or hazards). It, therefore, counts as a top-down procedure in risk analysis. Fault Tree Analysis: Notation The name Fault Tree Analysis already clarifies how it is represented graphically: As a tree. Both mind…
DetailsThe system architecture describes how a (medical) device is composed of components and how the components are related to each other via interfaces. In standalone software system architecture and software architecture fall together. Documentation of the system architecture The documentation should reveal the individual components and their interaction. We recommend that you use standard notations…
DetailsThe FDA requires a Design History File DHF in 21 CFR Part 820 (these are the “Quality System Regulations”). DHF should not be confused with the Device History Record DHR or the Device Master Record DMR. This article explains what the Design History File must contain and how it differs from the other two “files.” Design History File The FDA requires…
Details
Privacy Preference
We need your consent before you can continue on our website. If you are under 16 and wish to give consent to optional services, you must ask your legal guardians for permission. We use cookies and other technologies on our website. Some of them are essential, while others help us to improve this website and your experience. Personal data may be processed (e.g. IP addresses), for example for personalized ads and content or ad and content measurement. You can find more information about the use of your data in our privacy policy. You can revoke or adjust your selection at any time under Settings.
Privacy Preference
If you are under 16 and wish to give consent to optional services, you must ask your legal guardians for permission. We use cookies and other technologies on our website. Some of them are essential, while others help us to improve this website and your experience. Personal data may be processed (e.g. IP addresses), for example for personalized ads and content or ad and content measurement. You can find more information about the use of your data in our privacy policy. Here you will find an overview of all cookies used. You can give your consent to whole categories or display further information and select certain cookies.