What is Software as a Medical Device?
Software is playing an increasingly important role in modern healthcare. Not every health app is a medical device. A calorie tracker isn’t. A step counter isn’t either. But that means to support diagnosis, monitor patients, analyse medical information, assist healthcare professionals in clinical decision-making, and control or influence medical devices. The deciding factor is the intended purpose, not the underlying technology stack.
Building the Software
IEC 62304 is the core lifecycle standard. It requires a software development plan, then structures development into defined processes: requirements analysis, architectural design, detailed design, unit implementation and verification, integration and integration testing, and system testing. The rigor applied at each step scales with the software safety classification (A, B, or C), which is anchored in the risk analysis rather than an independent probability judgment.
IEC 62304 also governs configuration management and problem resolution processes that continue through the rest of the lifecycle, and it explicitly requires controls around SOUP (Software Of Unknown Provenance), pre-existing components such as operating systems, drivers, or third-party libraries that were not developed under the same process rigor. Configuration management establishes and maintains the ability to identify exactly which version of the software is deployed, what components it consists of, and what has changed between releases.
Risk Management Applied to Software
Risk management should be integrated with software development rather than performed independently. IEC/TR 80002-1 provides guidance on applying ISO 14971 specifically to software. It addresses how software failure modes, use errors, and foreseeable misuse should be analyzed when the “harm” pathway is mediated by information rather than a direct physical mechanism.
Keeping It Secure
New vulnerabilities get discovered years later, so security has to be built in from the start and maintained throughout the software’s life, not treated as a one-time check before release. Cybersecurity has become an important consideration for medical-device software.
Cybersecurity considerations may include:
- Authentication
- Access control
- Data protection
- Secure communication
- Vulnerability management
- Security testing
- Security updates
- Protection against unauthorized modification
Software Verification and Testing
Verification activities are performed to determine whether the developed software meets its specified requirements.
Depending on the software, verification activities may include:
- Unit testing
- Integration testing
- Functional testing
- Interface testing
- Performance testing
- Regression testing
- System testing
Testing should provide documented evidence that the software functions as specified.
Clinical Evaluation
Technical testing alone does not necessarily establish the clinical suitability of medical-device software. Verification and validation demonstrate that the software performs as designed. They don’t independently demonstrate clinical benefit. Before and during market placement, the manufacturer must demonstrate that the software achieves its intended clinical purpose.
Clinical evaluation structure the evidence requirement into three components:
- Valid clinical association :- Is there a valid clinical association between your SaMD output and your SaMD’s targeted clinical condition?
- Analytical validation:- Does your SaMD correctly process input data to generate accurate, reliable, and precise output data?
- Clinical validation:- Does use of your SaMD’s accurate, reliable, and precise output data achieve your intended purpose in your target population in the context of clinical care?
Release and Post-Market Surveillance
Once placed on the market, the lifecycle does not end. The software lifecycle continues after the device has been placed on the market. IEC 62304 maintenance and problem resolution processes, combined with MDR/IVDR post-market surveillance obligations, keep the software under continuous oversight.
Security vulnerabilities discovered post-release are evaluated against the software’s safety classification and its security lifecycle activities , then addressed through the maintenance process. Any modification, a bug fix, a new feature, a security patch re-triggers the relevant parts of the development and risk management processes, scaled to the significance of the change.
Manufacturers are expected to actively collect field performance data, track incidents and complaints, and identify patterns that pre-release testing couldn’t have surfaced given the scale of real-world use.
Findings from post-market surveillance feed directly back into maintenance, risk management, and cybersecurity review, keeping the lifecycle active rather than closed at launch.
Conclusion
The lifecycle of Software as a Medical Device involves much more than software coding and testing. It begins with establishing the intended purpose and determining whether the software qualifies as a medical device , while IEC 62304 provides a structured framework for medical-device software lifecycle processes. Throughout development, manufacturers need to consider software requirements, architecture, implementation, verification, risk management, clinical evaluation, technical documentation, cybersecurity, and regulatory requirements. After market release, the lifecycle continues through maintenance, software updates, change control and post-market surveillance. Therefore, successful medical-device software development requires both a controlled software engineering process and a regulatory framework that remains focused on safety, performance and the intended medical purpose throughout the software’s life.
References
IEC 62304:2006
