Software as a Medical Device
Second Edition
83 Regulatory Affairs Professionals Society
Introduction
This chapter focuses on software development and valida-
tion in medical devices. Although it touches briefly on data
management and governance, security, and usability of health
software, other chapters provide deeper treatment of these
topics. The author uses the term “software” for Software as
a Medical Device (SaMD) and Medical Device Software
(MDSW), including MDSW that is embedded on, drives,
or influences the use of a hardware medical device, software
accessories, and software components. For a discussion as to
how SaMD and MDSW differ, see Chapter 2 on Software as
a Medical Device.
Standards and Guidance
Manufacturers should consider standards and regulatory
guidance when implementing software development pro-
cesses. This section introduces the most important standards
and guidance documents.
The internationally accepted framework for lifecy-
cle processes for medical device software is International
Electrotechnical Commission (IEC) 62304.1,2 This standard
defines the processes, activities, and tasks manufacturers
use to develop and maintain medical device software. This
chapter outlines the sections of IEC 62304 that pertain to
software development.
IEC 62304 defines software development lifecycle activ-
ities, except for design validation of the finished device (i.e.,
the process for confirming software specifications conform to
user needs and intended uses).1 Design validation is covered
by IEC 60601-13,4 for the software part of medical electrical
equipment, or IEC 82304-15 for software-only products.
For software that includes Artificial Intelligence (AI)
or machine learning, additional activities need to be defined,
such as those related to the data lifecycle of the AI model.
In Europe, the AI Act (2024/1689) entered into force on 1
August 2024.6 This horizontal regulation imposes mandatory
development obligations on providers that place on the market
or put into service high-risk AI systems. Multiple harmonized
standards are in development at the time of this writing (e.g.,
in the areas of Quality Management Systems [QMSs], risk
management, governance, and quality of data sets, logging
requirements, transparency and information provision, human
oversight, accuracy, robustness, and cybersecurity).
IEC 62304 defines processes, not development tech-
niques. The sequence of development process steps described
by IEC 62304 appears to suggest that a waterfall model be
used (i.e., a sequence of steps to be followed in a specific
order strategy, often represented in the classical V-model for
sequential development).1,2 Nevertheless, the standard does
not prescribe any specific software development methodology
approach, sequence, principle, or practice. The standard for
QMSs, International Organization for Standardization (ISO)
13485:2016,7 and the US Food and Drug Administration
(FDA) guidance on design controls8 appear to suggest that
the design process be completed in the following sequence:
planning, design input, design output, design review, verifica-
tion, validation, and transfer. However, these documents are
not intended to prescribe a specific chronological order for
these activities.
Historically, (software) development departments felt
burdened by the waterfall approach. When writing plans and
requirements specifications, they had to document to the last
comma and point before starting with the real work: coding.
In contrast, an agile or iterative development approach allows
them to perform system development and delivery in small
increments.
Agile, a software development methodology, provides
useful functions much earlier in the project, generates early
feedback from strategic customers and users, allows devel-
opers to improve the functionality already on the market,
and informs corrections to the original specification. Agile’s
principal purpose is to overcome the problem of discov-
ering, at the end of a (large) development project, that the
developed system does not meet the customers’ real (and
8
Software Development
Coenraad Davidsdochter, MSc
Second Edition
83 Regulatory Affairs Professionals Society
Introduction
This chapter focuses on software development and valida-
tion in medical devices. Although it touches briefly on data
management and governance, security, and usability of health
software, other chapters provide deeper treatment of these
topics. The author uses the term “software” for Software as
a Medical Device (SaMD) and Medical Device Software
(MDSW), including MDSW that is embedded on, drives,
or influences the use of a hardware medical device, software
accessories, and software components. For a discussion as to
how SaMD and MDSW differ, see Chapter 2 on Software as
a Medical Device.
Standards and Guidance
Manufacturers should consider standards and regulatory
guidance when implementing software development pro-
cesses. This section introduces the most important standards
and guidance documents.
The internationally accepted framework for lifecy-
cle processes for medical device software is International
Electrotechnical Commission (IEC) 62304.1,2 This standard
defines the processes, activities, and tasks manufacturers
use to develop and maintain medical device software. This
chapter outlines the sections of IEC 62304 that pertain to
software development.
IEC 62304 defines software development lifecycle activ-
ities, except for design validation of the finished device (i.e.,
the process for confirming software specifications conform to
user needs and intended uses).1 Design validation is covered
by IEC 60601-13,4 for the software part of medical electrical
equipment, or IEC 82304-15 for software-only products.
For software that includes Artificial Intelligence (AI)
or machine learning, additional activities need to be defined,
such as those related to the data lifecycle of the AI model.
In Europe, the AI Act (2024/1689) entered into force on 1
August 2024.6 This horizontal regulation imposes mandatory
development obligations on providers that place on the market
or put into service high-risk AI systems. Multiple harmonized
standards are in development at the time of this writing (e.g.,
in the areas of Quality Management Systems [QMSs], risk
management, governance, and quality of data sets, logging
requirements, transparency and information provision, human
oversight, accuracy, robustness, and cybersecurity).
IEC 62304 defines processes, not development tech-
niques. The sequence of development process steps described
by IEC 62304 appears to suggest that a waterfall model be
used (i.e., a sequence of steps to be followed in a specific
order strategy, often represented in the classical V-model for
sequential development).1,2 Nevertheless, the standard does
not prescribe any specific software development methodology
approach, sequence, principle, or practice. The standard for
QMSs, International Organization for Standardization (ISO)
13485:2016,7 and the US Food and Drug Administration
(FDA) guidance on design controls8 appear to suggest that
the design process be completed in the following sequence:
planning, design input, design output, design review, verifica-
tion, validation, and transfer. However, these documents are
not intended to prescribe a specific chronological order for
these activities.
Historically, (software) development departments felt
burdened by the waterfall approach. When writing plans and
requirements specifications, they had to document to the last
comma and point before starting with the real work: coding.
In contrast, an agile or iterative development approach allows
them to perform system development and delivery in small
increments.
Agile, a software development methodology, provides
useful functions much earlier in the project, generates early
feedback from strategic customers and users, allows devel-
opers to improve the functionality already on the market,
and informs corrections to the original specification. Agile’s
principal purpose is to overcome the problem of discov-
ering, at the end of a (large) development project, that the
developed system does not meet the customers’ real (and
8
Software Development
Coenraad Davidsdochter, MSc