IEC 62304 changes how software work is controlled
When software forms part of a medical device, demonstrating that it works is not enough. The organisation must be able to explain how requirements were defined, how risks were considered, how changes were controlled and how evidence was maintained throughout the software life cycle.
IEC 62304 provides a framework for those software life-cycle processes. It affects planning, architecture, implementation, verification, release, maintenance and problem resolution.
The standard is about process evidence
IEC 62304 does not prescribe one programming language or development method. It requires a controlled process appropriate to the software’s safety classification and intended use.
The work must produce evidence that links decisions and outputs across the life cycle, rather than relying on undocumented knowledge held by individuals.
Software safety classification
The classification of the software influences the level of control and evidence required. The organisation needs to consider what harm could result if the software fails or contributes to a hazardous situation.
This classification should be established with appropriate regulatory and risk-management input. It is not a label a development team should assign casually.
Planning the software life cycle
A software development plan normally establishes the activities, responsibilities, methods, tools and deliverables that will govern the work.
- requirements management;
- architecture and detailed design;
- implementation and verification;
- configuration and change control;
- problem resolution;
- release and maintenance;
- documentation and traceability.
Requirements and traceability
Requirements need to be clear enough to design and verify. Traceability helps show how a requirement is implemented, which tests provide evidence and how risk controls are represented in the software.
A disconnected set of spreadsheets and documents can make this difficult to maintain. The project should define how identifiers, versions, approvals and relationships will be controlled.
Architecture and segregation
Software architecture is particularly important where risk controls depend on separation between components or where third-party software is used. The design should make interfaces, responsibilities and failure behaviour explicit.
Architecture decisions should be documented in a way that supports later maintenance and assessment, not only the initial build.
Verification needs objective evidence
Verification should demonstrate that outputs meet their defined inputs. This may include reviews, analysis and testing at several levels.
Test evidence should identify what was tested, under which version and with what result. Informal confirmation that “it worked on the developer’s machine” is not sufficient.
Configuration and change control
Medical device software continues to change after initial release. Defects, security issues, platform updates and new requirements all need a controlled route.
The organisation should be able to identify the released configuration, assess the effect of a proposed change, verify the updated software and preserve the evidence behind the decision.
Software maintenance is part of the life cycle
IEC 62304 includes maintenance and problem-resolution expectations because the risks do not end at launch. Reports need to be evaluated, problems investigated and changes controlled according to their potential effect.
IEC 62304 does not stand alone
Medical device software development usually sits within a wider quality and regulatory framework, including risk management, usability, security and market-specific obligations. Specialist regulatory advice may be required to determine the applicable requirements.
The development approach should therefore be agreed with the organisation’s quality and regulatory responsibilities rather than treated as a normal software project with extra documents added at the end.
Assess the project before selecting the delivery model
A regulated software project needs clear ownership, evidence expectations and boundaries from the beginning. The next step is to determine the intended use, software role, risk context, integrations and existing quality processes before deciding whether the project is a suitable fit.