Medical devices
Development of medical devices, device software and systems, from concept to approval
Medical devices combine mechanics, electronics and software, from an infusion device and a diagnostic system to software that is itself a medical device. Development takes place under special conditions: faults can endanger patients and users, and the manufacturer has to control the product across its entire life cycle.
Fixed requirements apply. ISO 14971 governs risk management, IEC 62304 the software life cycle, ISO 13485 the quality management system and IEC 62366 usability. Together they form the basis for approval under the Medical Device Regulation (MDR).
Which requirements apply in medical technology
Standards and regulations to be met for medical devices and their software.
Risk management
ISO 14971 requires hazards of a product to be identified, risks to be assessed, measures to be defined and their effect to be shown. The risk management file accompanies the product throughout its life.
More on functional safety →Software
IEC 62304 divides software into safety classes A, B and C. With the class, the scope and depth of requirements, architecture, testing and documentation grow.
More on functional safety →Quality and usability
ISO 13485 requires a quality management system for development and production, IEC 62366 the evaluation of usability. Both feed into the technical documentation for the MDR.
More on process maturity and interfaces →Cybersecurity
Connected medical devices must be protected against attacks. The MDR and the guidance MDCG 2019-16 require cybersecurity to be considered in the development process.
More on cybersecurity →When support makes sense
Typical triggers in medical technology.
Approval under the MDR
A product is to be approved under the MDR, and the technical documentation on risk, software and testing is incomplete.
Software class open
The classification of the software under IEC 62304 is open or disputed, and it determines how deep development and documentation have to go.
Audit announced
An audit by the notified body or a customer is coming up, and development records and actual practice do not match.
Product is changed
An existing product is changed or extended by software, and the consequences for the risk analysis and approval have not been assessed.
What we take on in medical technology
Three service areas that can be combined as the task requires.
Engineering
Product requirements and system architecture for medical devices, plus the risk management plan and risk analysis to ISO 14971 and a feasibility assessment before the decision.
More →Management
Project and quality management with a view to ISO 13485, development planning and coordination with regulatory affairs and suppliers.
More →Development and testing
Software development to IEC 62304, verification and validation, usability testing and the development documentation for the technical file.
More →Approach and work products
The work follows four steps.
Define product and intended purpose
Intended purpose, product class and applicable requirements are defined, as is the role as manufacturer or supplier.
Assess risks
Hazards are identified, risks assessed and the software safety class under IEC 62304 justified.
Derive requirements and architecture
The risk analysis leads to requirements, architecture and risk control measures that are traced through to testing.
Show the evidence
Verification, validation and technical documentation are prepared so that auditors and the notified body can follow them.
This produces, among other things, the risk management plan, the risk analysis, the software development plan with classification, the software requirements and architecture, traceability through to testing, and verification and validation reports. The approval itself, the assessment by the notified body and the role of the person responsible for regulatory compliance under the MDR are not part of it.
Frequently asked questions
What is the difference between ISO 14971 and IEC 62304?
ISO 14971 governs risk management for the whole product, IEC 62304 the life cycle of the software. IEC 62304 presupposes the risk analysis to ISO 14971 and adds software-specific risks.
What do the software safety classes A, B and C mean?
The class depends on the possible severity of harm: in class A no injury is possible, in class B no serious injury, in class C death or serious injury is possible. The effort for architecture, testing and documentation rises with the class.
When is software a medical device?
If, according to its intended purpose, it fulfils a medical purpose itself, for example in diagnosis or therapy, it is a medical device or part of one. The manufacturer's intended purpose is decisive.
Do I need ISO 13485?
The MDR requires manufacturers to have a quality management system, and ISO 13485 is the usual basis for it. For suppliers, the customers decide what they require.
Does IEC 62304 also apply to suppliers?
The standard is addressed to the manufacturer. Suppliers that develop software for medical devices have to meet it in practice, because the manufacturer passes the requirements on.
What role does cybersecurity play for medical devices?
Connected products must be protected against attacks. The MDR requires the risks of a product to be controlled, which includes IT security, and the guidance MDCG 2019-16 describes the expectations.
Clarify your project in a call
In the call we clarify the trigger, which standard applies and which deadline has to be met.