IEC 82304 – What the standard requires of “health software”
IEC 82304 is now available. This is a good reason to take a closer look at this standard for “health software products.”
Risk management and risk analysis for software
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!
FDA MAUDE database: Input for risk management
The 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.
PESS: Programmable Electronic Subsystems
IEC 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.
DetailsSoftware architecture documentation
The 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
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…
DetailsRegulatory affairs: Service provider, company, individual – liability for mistakes
Many 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.
FTA: Fault Tree Analysis
Fault 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.
Design History File: Device Master Record, Device History Record
The 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.”
Harm according to ISO 14971
A medical device can cause harm to patients, users, or third parties. The manufacturer must identify this harm to determine the device’s risks and control them. This article provides guidance on how to determine and document harm in accordance with ISO 14971 and how to use the term “harm” correctly.
Details