Medical device software · standards architecture · evidence by design
ISO and IEC standards for medical device software
Compliance is not added after the final sprint. It is compiled into every release.
The standards form a connected build system. Quality governs the organisation, risk management explains why controls exist, the software lifecycle makes work traceable, usability addresses use error, cybersecurity protects the product in a hostile world and product requirements turn code into a releasable medical device.
Run the standards build ↓Intended purpose · architecture · code · data · interface
Evidence linked across the lifecycle
The central idea
The standards do not sit beside the code
They define how decisions around the code are made, recorded, tested and revisited.
A compliant release is therefore not just a working binary. It is a working binary with a coherent history and a controlled future.
01
The standards work as a system, not a shopping list #
ISO and IEC standards address different layers of the same product. Their scopes overlap deliberately because a software failure rarely belongs to one discipline. A confusing alert can be a usability problem, a software requirement defect, a risk-control failure and a post-market signal at the same time.
The practical task is not to collect six certificates or six separate folders. It is to decide which standards apply, understand what each one contributes and build traceability across their interfaces.
Quality system, design controls, suppliers, change and CAPA
Hazards, risk estimation, controls, benefit-risk and production data
Development, maintenance, configuration, problem resolution and safety classification
Product-level safety, validation, information and lifecycle responsibilities
Use-related risk and safety-focused usability engineering
Secure development and maintenance activities across the lifecycle
If a risk control changes, can the team identify the affected software requirement, architecture element, verification, usability work, security analysis, release record and post-market monitoring?
02
Before choosing standards, define the product boundary #
Not every health application is medical device software. The intended purpose, medical claims, users, patient population, input data and significance of the output determine whether the software falls under the MDR, the IVDR or another framework.
The same boundary also determines what the software product includes. A mobile application may depend on a cloud service, trained model, database, web portal, third-party library, deployment script and external interface. Excluding one of these from a diagram does not remove it from the safety case.
Medical purpose, claims, applicable regulation and classification rationale
Apps, services, models, data stores, interfaces, platforms and accessories
Manufacturer, suppliers, cloud providers, deployers, users and healthcare organisations
What must be verified, validated, monitored and kept under change control
MDCG guidance on software qualification and classification is important here, but it does not replace a product-specific rationale. The standards architecture should follow the actual product, not the marketing label attached to it.
03
ISO 13485 creates the organisation around the code #
ISO 13485 does not prescribe an architecture, programming language or test framework. It controls the organisation that makes those choices.
Plans, inputs, outputs, reviews, verification, validation and transfer
Cloud, libraries, development tools, external teams and critical services
Impact assessment, approval, implementation, verification and release
Complaints, nonconformities, CAPA, audits and post-market data
For an agile team, the standard does not forbid short iterations or automated delivery. It requires the workflow to preserve approval, traceability, objective evidence and control. A fast pipeline can be compliant; an invisible pipeline cannot.
04
ISO 14971 explains why the software controls exist #
Software does not usually harm a patient by being made of dangerous material. It can contribute to harm through incorrect information, delayed action, lost availability, unintended commands, confusing interaction or compromised data and functions.
ISO 14971 supplies the logic that connects foreseeable sequences of events to hazardous situations and harms, then evaluates risks, selects controls and verifies that those controls work. IEC 62304 supplies the software activities that implement and maintain many of those controls.
Fault, misuse, data problem, dependency failure or attack
Detection, calculation, display, communication or control behaves unexpectedly
A person or environment becomes exposed to a source of harm
Severity and probability inform the risk decision
Design, protective measure, information, monitoring or operational control
A vulnerability is not automatically a patient-safety risk. Once exploitation can affect a medical function, availability, integrity or clinical decision, the security analysis and the ISO 14971 risk file must connect.
05
IEC 62304 is the software lifecycle backbone #
IEC 62304 establishes a common framework for developing and maintaining medical device software, whether the software is itself a medical device or is embedded in or integral to a medical device.
Its strength is disciplined continuity. Requirements lead to architecture and detailed design, implementation leads to verification, releases remain identifiable, problems are investigated and changes return through the same controlled system.
Lifecycle model, activities, responsibilities, deliverables and interfaces
System and software requirements linked to risk controls
Software items, segregation, interfaces and SOUP dependencies
Units, integration and objective verification evidence
Known anomalies, version identity, records and controlled delivery
Feedback, problem resolution, impact analysis and modification
IEC 62304 does not cover final validation and release of the complete medical device, even when the device consists entirely of software. Product-level evidence must close that gap.
06
IEC 62304 safety classes are not MDR risk classes #
The two classification systems answer different questions. Treating them as a conversion table is one of the fastest ways to create a weak software plan.
Classifies the medical device and determines the conformity-assessment route and regulatory scrutiny.
Scales lifecycle rigour according to the possible injury arising from a software-system failure.
The standard requires the least extensive set of lifecycle activities
Additional architecture, design and verification controls apply
The most extensive lifecycle controls and evidence apply
The classification rationale must consider the software system, hazardous situations and external risk controls in accordance with the applicable edition. It should be established early enough to shape planning and architecture, then revisited when risks, interfaces or controls change.
07
IEC 82304-1 helps turn software into a complete health software product #
IEC 82304-1 applies to the safety and security of health software products designed to operate on general computing platforms and placed on the market without dedicated hardware. That scope is more precise than simply saying it applies to all standalone software.
The standard looks beyond development activities to the complete product. It addresses product requirements, validation, identification, accompanying information, installation, maintenance and disposal across the lifecycle.
How the software was developed and maintained
Intended use, system requirements and operating environment
The complete health software product meets its intended use
Identification, instructions, limitations and accompanying documents
Installation, maintenance, updates and decommissioning
For software-only medical devices, IEC 62304 and IEC 82304-1 are therefore complementary. One controls the software lifecycle; the other helps close the product-level argument.
08
IEC 62366-1 treats the interface as part of the safety system #
A screen can pass every functional test and still lead a user toward the wrong action. IEC 62366-1 establishes a usability-engineering process focused on safety-related characteristics of the user interface.
Capabilities, limitations, training, language and use environment
Use scenarios, tasks, errors and safety-related interface characteristics
Formative evaluation improves the interface while it can still change
Summative evaluation tests the final interface in representative use
The goal is not general customer satisfaction. It is to assess and reduce risks related to correct use and use error during normal use. The process can identify abnormal use but does not assess or mitigate its associated risks.
09
IEC 81001-5-1 adds a secure product lifecycle #
IEC 81001-5-1 defines lifecycle activities for developing and maintaining health software securely. It adapts secure-development concepts to the particular balance of safety, effectiveness and security required in health software.
Roles, competencies, planning, policies and development environment
Assets, trust boundaries, attack paths, impact and risk treatment
Controls, architecture, implementation and verification
Residual risk, secure delivery, configuration and documentation
New intelligence, coordinated disclosure and product impact
Assessment, remediation, communication and controlled deployment
A penetration test cannot substitute for this lifecycle. It is one source of evidence inside a much larger system. Likewise, an organisation-level information-security certificate does not by itself demonstrate product cybersecurity.
10
The product context decides what else joins the stack #
The six central standards are not a universal closed list. Hardware, networks, artificial intelligence, data protection, electrical safety and the deployment environment can introduce further standards and guidance.
May govern basic safety, essential performance and collateral requirements when software forms part of medical electrical equipment.
Can inform risk management where medical devices operate within health IT networks and responsibilities are shared.
Can support an information-security management system but does not replace product-specific security engineering.
Provides concepts for balancing safety, effectiveness and security across health software and health IT systems.
A standard belongs in the compliance plan because its scope and the product context make it relevant, not because it appeared in another manufacturer’s checklist.
11
A standard number is not yet a legal compliance claim #
Standards and regulations do different jobs. The MDR and IVDR create legal obligations. Standards provide technical processes and solutions that can help demonstrate conformity.
Defines the binding legal requirements for the product and manufacturer
A cited standard can provide presumption of conformity for the requirements its citation covers
May remain highly valuable even when it is not harmonised or its latest edition is not yet cited
Scope, edition, deviations, evidence and links to legal requirements must be documented
Use of harmonised standards remains voluntary. The benefit depends on the specific European edition, amendment, date and requirements covered by the citation. The latest international edition and the currently harmonised European edition may not be the same document.
Before a major release or submission, verify current editions, amendments, corrigenda, interpretation sheets, harmonisation status and transition arrangements. A standards list copied two years ago is not configuration control.
12
Compile one evidence architecture #
The most efficient implementation reuses evidence without confusing responsibilities. One approved software requirement may satisfy a design input, implement a risk control, support a security requirement and feed a usability-critical task. It should not be copied into four uncontrolled documents.
Regulatory · product · clinical · risk
Are we building and validating the same product?Design control · risk · security · usability
Can every critical requirement be traced to its source and verification?IEC 62304 · security · SOUP · segregation
Are safety and security assumptions visible at the system boundaries?Software · product · usability · clinical
Does the evidence cover code, system behaviour and intended use?Configuration · risk · product · communication
Is the released state identifiable and are unresolved issues acceptable?PMS · maintenance · CAPA · cybersecurity
Can real-world signals change the right controlled records?Build failures that reviewers notice
The manufacturer cannot explain why a standard is used, excluded or only partly applied.
Two different classification questions are treated as if they were interchangeable.
Implemented controls, requirements and verification no longer describe the same release.
Security scenarios with possible clinical consequences do not reach ISO 14971.
Critical tasks and hazardous use scenarios are lost behind general opinions about the interface.
SOUP, inherited modules and previous releases lack an adequate controlled justification.
- Define the intended purpose, regulatory status and complete product boundary
- Create a standards register with scope, editions and applicability rationales
- Map legal requirements to standards, processes and planned evidence
- Align QMS, risk, software, usability and security plans before implementation
- Build shared identifiers and traceability into the development workflow
- Validate the complete product rather than stopping at software verification
- Release a controlled configuration with assessed anomalies and residual risks
- Feed maintenance, PMS, vulnerabilities and changes back into the same system
Official sources
- ISO overview of ISO 13485 for medical-device quality management systems
- ISO 14971 — 2019 edition for medical-device risk management
- IEC 62304 — 2006 edition with Amendment 1 from 2015 for software lifecycle processes
- IEC 82304-1 — 2016 edition for health software product safety
- IEC 62366-1 — 2015 edition with Amendment 1 from 2020 for usability engineering
- IEC 81001-5-1 — 2021 edition for secure health-software lifecycle activities
- European Commission overview of harmonised standards for medical devices
- European Commission collection of MDCG software and cybersecurity guidance
The release decision
The standards should converge on one product truth
ISO 13485 controls the organisation. ISO 14971 controls the risk logic. IEC 62304 controls the software lifecycle. IEC 62366-1 controls safety-related interaction. IEC 81001-5-1 controls the secure lifecycle. IEC 82304-1 helps close the product-level argument.
None of them can rescue a product whose purpose, architecture, evidence and released configuration contradict one another.
The real deliverable is not a shelf of standard-specific files. It is a release whose safety, performance, security and history can be reconstructed without guesswork.
Medical software compliance architecture
Need to turn overlapping standards into one workable development and evidence system?
Discuss your software pathway ↗From the knowledge centre
