82304-1:2016 Health software – Part 1: General requirements for product safety

SoftwareCPR® Tiered Checklist and Assessment Forms

Prepared by Jordan Pate
For training, assessment, or implementation support contact us by leaving a message at www.softwarecpr.com or calling 781-721-2921

1.0 Purpose This document is intended as a job aide to assessments for conformance to IEC 82304-1. It serves as a checklist and provides space to map
the internal process to the standard’s requirements. The information collected can be used as a mapping of the internal process to 82304-1 to
aide 3rd party conformance assessments.

2.0 Usage • This job aide should only be applied by those who are knowledgeable about 82304-1 and its proper
interpretation and have an understanding of software engineering and validation principles. Also, note that the text is not the full or
exact text in the standard.
• A tiered approach to conformance assessment is incorporated into these forms. One can assess at several levels:
o Are all required processes established?
o Are all required tasks and activities performed?
o Are all documentation requirements met?
o Do tasks and deliverables incorporate all required and relevant items (usually by sampling not all in every deliverable)
A group could conform at one or more levels but not be in full conformance. Or a group could completely conform for maintenance or initial
development but not both. These forms are intended to highlight the degree of conformance rather then just provide a straight list of items.

The forms provided can be just used as a checklist with notes taken separately for document and procedure references and comments.

DISCLAIMER: These forms should not be used in place of the standard itself and may have unintended omissions or inaccuracies
as well as paraphrased verbiage.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 1 of 30
Copyright
®
© Copyright 2017 Crisis Prevention and Recovery, LLC. (CPRLLC), all rights reserved. SoftwareCPR is a division of Crisis Prevention and Recovery,
®
LLC and the SoftwareCPR logo is a registered trademark.
®
SoftwareCPR authorizes its clients and SoftwareCPR.com subscribers use of this document for internal review and training. Any other use or
®
dissemination of this document is expressly prohibited unless the document is provided to you directly from SoftwareCPR or you receive the written
®
authorization of SoftwareCPR .

Legal Disclaimer
The training document example that follows should only be applied in the appropriate context with oversight by regulatory and software professionals
with direct knowledge and experience with the topics presented. The document should not be used as a cookbook or taken literally without
knowledgeable evaluation of current interpretations and enforcement.
®
While SoftwareCPR attempts to ensure the accuracy of information presented, no guarantees are made since regulatory interpretations and
enforcement practices are constantly changing, and are not entirely uniform in their application.

Disclaimer of Warranties: The information is provided AS IS, without warranties of any kind. CPRLLC does not represent or warrant that any
information or data provided herein is suitable for a particular purpose. CPRLLC hereby disclaims and negates any and all warranties, whether express
or implied, relating to such information and data, including the warranties of merchantability and fitness for a particular purpose.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 2 of 30
3.0 Identification and Conclusion
Company/Division/Department/Group: ___________________________________________________________________

Project/Product: _____________________________________________________________________________________

Scope/portion of 82304-1 Assessed: (Indicate 82304-1 included or excluded whichever is the shorter list):

_______________________________________________________________________________________________________

_______________________________________________________________________________________________________

Depth of Assessment (Describe which tiers included and the degree of document review and interviewing)

________________________________________________________________________________________________________

________________________________________________________________________________________________________

Performed by: ____________________________________________________________

Analysis and Conclusion: Optional: Normally this would go in a separate report.

State degree of conformance determined using the Tiered method. List:

• Processes Missing
• Tasks and activities omitted (or summarize)
• Documentation requirements omitted (or summarize)
• Required low level tasks and deliverables omitted (or summarize)

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 3 of 30
4. High-level Conformance Evaluation
The Procedure/Plan column is to note where the approach or method for the activity is defined. The deliverable/documents column is to note the output of the activity in
terms of documents and other deliverables that provide objective evidence that the process and activity was performed. One procedure, plan or document could be
referenced multiple times. If all elements of this table are satisfied, one demonstrates conformance with the processes and activities requirements of IEC 82304-1. Note
that IEC 82304-1 also requires specific tasks and these more detailed requirements are not addressed in this table.

The “initially” column indicates whether the initial development was conformant and the “now” column indicates whether the current process is conformant.

Enter NE if the requirement was NOT EVALUATED. Enter NA if it is not applicable. These forms can be just used as a checklist with notes taken
separately for document and procedure references and comments.

Now
Initially
(Y, N,
IEC 82304-1 (Y, N, Procedure, Plan Titles Deliverables/documents Comments
NE)
NE)
4 Health Software Product Requirements
4.1 General requirements and initial Risk
Assessment
4.2 Health Software Product use
requirements
4.3 Verification of Health Software Product
use requirements
4.4 Updating Health Software Product use
requirements
4.5 System requirements
4.6 Verification of system requirements
4.7 Updating health software product system
requirements
5 Health Software – Software life cycle processes

6 Health Software Product Validation

6.1 Validation plan
6.2 Performing validation
6.3 Validation report
7 Health Software Product identification and Accompanying Documents
7.1 Identification
7.2 Accompanying Documents
8 Post-market activities for the Health Software Product
8.1 General
Copyright © 2017, Crisis Prevention and Recovery, LLC
(CPRLLC), all rights reserved. Rev 1 Page 4 of 30
8.2 Software Maintenance
8.3 Re-Validation
8.4 Post-market communication on the Heath
Software Product
8.5 Decommissioning and disposal of the
Health Software Product

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 5 of 30
82304-1 Processes Detailed Section by Section Checklist
For items that are outside the scope of the assessment use NE – not evaluated – and be clear about the scope of the assessment in any
summary report or conclusions.

For items that are not relevant use NA – not applicable – and document your rationale.

NOTE: This checklist can be used to evaluate if plans and procedures address all relevant items but for a full assessment results of actual
development and maintenance should be evaluated to determine if in practice all conformance was achieved with all items.

4 Health Software Product requirements

4.1 General requirements and initial Risk Assessment

Y/ N
Procedure, Plan, or Document references
/NE/
IEC 82304-1 Conformity Requirements (If level of detail in section 4 is not considered a sufficient Comments
NA
mapping)
4.1 a – c The manufacturer shall determine and document:

a. the intended use for the Health

Software Product, including the user
profile and the intended operational
environment;
b. the characteristics related to the
safety and/or security of the Health
Software Product, identification of
hazards and estimation of the
associated risk(s).
c. the need for risk control measures
for estimated risks that are
considered unacceptable.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 6 of 30
4.2 Health Software Product use requirements

Y/N/ Procedure, Plan, or Document references

Section Conformity Requirements NE/ (If level of detail in section 4 is not considered a sufficient Comments
NA mapping)
4.2 a – g The manufacturer shall determine and document:

a. requirements that address the

intended use;
b. interface requirements, including
user interface requirements where
applicable;
c. requirements for immunity from or
susceptibility to unintended
influence by other software using
the same hardware resources;
d. privacy and security requirements
addressing areas such as authorized
use, person authentication, health
data integrity and authenticity, and
protection against malicious intent;
e. requirements for accompanying (See 7.2.2)
documents such as instructions for
use;
f. requirements for support:
1. Upgrades from previous
versions, including maintaining
data integrity, and compatibility
with prior versions,
2. rollback to the previous version
after upgrade,
3. timely security patches and
updates,
4. software distribution
mechanism that ensures
integrity of installation,
5. decommisioning, irreversible
deletion, transfer and/or
retentionof data;
Copyright © 2017, Crisis Prevention and Recovery, LLC
(CPRLLC), all rights reserved. Rev 1 Page 7 of 30
 g. requirements derived from
applicable regulation, including
rules for protected information.

4.3 Verification of Health Software Product use requirements

Y/N/ Procedure, Plan, or Document references

Section Conformity Requirements NE/ (If level of detail in section 4 is not considered a sufficient Comments
NA mapping)
4.3 a – b The manufacturer shall verify that the Health Software Product use requirements are:

a. Defined and documented as input

for system requirements;
b. Such that the manufacturer is able to
meet the defined use requirements.
The results of the verification shall be
recorded.

4.4 Updating Health Software Product use requirements

Y/N/
Procedure, Plan, or Document references
Section Conformity Requirements NE/ Comments
(If level of detail in section 4 is not considered a sufficient mapping)
NA
The manufacturer shall ensure that the Health
Software Product use requirements are
updated as appropriate, e.g. as a result of
Health Software Product use requirements
verification or as a result of validation.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 8 of 30
4.5 System requirements

Y/N/ Procedure, Plan, or Document references

Section Conformity Requirements NE/ Comments
NA (If level of detail in section 4 is not considered a sufficient mapping)
4.5 a – h The manufacturer shall specify and
document the system requirements for the
Health Software Product. These requirements
shall include the functionality for intended
use and, as applicable:
a. inter-operability;

b. localization and language support;

c. risk Control measure that have to be

implemented in the Health Software
Product at system level, based on
the initial Risk Assessment of 4.1;
d. user interface specification;

e. requirements on the software and

hardware platforms for the Health
Software Product to function as
expected under expected load, and
with required performance levels;
f. features that allow for security
compromises to be detected,
recognized, logged, timed, and acted
upon during normal use;
g. features that protect essential
functions, even when the software
security has been compromised;
h. methods for retention and recovery
of product configuration by an
authenticated privileged user.
The Health Software Product system (See 4.2)
requirements shall meet the Health Software
Product use requirements
Copyright © 2017, Crisis Prevention and Recovery, LLC
(CPRLLC), all rights reserved. Rev 1 Page 9 of 30
4.6 Verification of system requirements

Y/N/
Procedure, Plan, or Document references
Section Conformity Requirements NE/ Comments
(If level of detail in section 4 is not considered a sufficient mapping)
NA
4.6 a – d The manufacturer shall verify that the system requirements:

a. do not contradict each other;

b. are expressed in terms that avoid

ambiguity;
c. are stated in terms that permit the
establishment of test criteria and
performance of tests to determine
that test criteria have been met; and
d. can be uniquely identified.

The results of the verification shall be

recorded.

4.7 Software System Testing

Section Conformity Requirements Y/N/ Procedure, Plan, or Document references Comments

NE/ (If level of detail in section 4 is not considered a sufficient
NA mapping)
The manufacturer shall ensure that the Health
Software Product system requirements are
updated as appropriate, e.g. as a result of
modification on the Health Software Product
use requirements, as a result of system
requirement Verification (see 4.6), or as a
result of applying 5.2 of IEC 62304:2006 and
IEC 62304:2006/AMD1:2015

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 10 of 30
5 Health Software – Software life cycle processes
Section Conformity Requirements Y/N/ Procedure, Plan, or Document references Comments
NE/ (If level of detail in section 4 is not considered a sufficient
NA mapping)
The system requirements for the Health
Software Product established in 4.5 shall be
used as primary design input for the life cycle
process of the Health Software Product.
The requirements in 4.2, 4.3, Clause 5, Clause
6, Clause 7, Clause 8, and Clause 9 of IEC
62304:2006 and IEC 62304:2006/AMD1:2015
shall apply to the Health Software in addition
to the other requirements of this document.
IEC 62304:2006 and IEC 62304:2006 and IEC
62304:2006/AMD1:2015 normatively
references ISO 14971:2007. It is recognized
that the manufacturer might not be able to
follow all the process steps identified in ISO
14971:2007 for each constituent component of
the Health Software, such as proprietary
components, subsystems of non-healthcare
origin, and legacy software. In this case, the
manufacturer shall take account of the residual
risks and implement risk controls around those
found to be unacceptable.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 11 of 30
6 Health Software Product Validation
6.1 Validation Plan

Y/N/ Procedure, Plan, or Document references

Section Conformity Requirements NE/ (If level of detail in section 4 is not considered a sufficient Comments
NA mapping)
The manufacturer shall establish a validation
plan addressing all Health Software Product
use requirements established in 4.2.
In the validation plan, the manufacturer shall:
a. identify the validation scope and the
corresponding validation activities;
b. identify the constraints that
potentially limit the feasibility of
validation activities;
c. select appropriate validation
methods, input information, and
associated acceptance criteria for
successful validation.
d. Identify the enabling systems or
services such as operating
environment(s), including hardware
and software platforms, needed to
support validation;
e. Specify the required qualification of
the validation personnel; where
training is required, this shall be
completed before starting the
validation;
f. Define the appropriate level of
independence of the validation team
from the design team.

6.2 Performing Validation

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 12 of 30
 Y/N Procedure, Plan, or Document references
Section Conformity Requirements /NE (If level of detail in section 4 is not considered a sufficient Comments
/NA mapping)
The manufacturer shall confirm readiness for
validation once:
a. the validation plan has been
established;

b. The validation team has been set up

with the approprriately qualified
personnel; and
c. As appropriate, development life
cycle phases as required by Clause 5
have been completed for those parts
of the Health Software Product
subject to validation.
The validation team shall perform the
validation activities in the intended operational
environment(s) according to the validation
plan of 6.1. Where deviations from the
validation plan are deemed necessary, they
shall be justified in the validation report.
When anomalies are found in the Health
Software Product during validation, these shall
be resolved through a problem resolution
process according to Clause 9 of IEC
62304/AMD1:2015. Where this problem
resolution process results in modification of
the Health Software Product, the affected part
of the Validation shall be repeated, taking into
account the extent of the modification.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 13 of 30
6.3 Validation report

Y/N/ Procedure, Plan, or Document references

Section Conformity Requirements NE/ (If level of detail in section 4 is not considered a sufficient Comments
NA mapping)
The validation team shall develop the
validation report for the Health Software
Product subject to validation.
The validation report shall provide evidence
that:
a. the validation results are traceable to
the Health Software Product use
requirements, taken as input;
b. The Health Software Product meets
the use requirements established in
4.2; and
c. the residual risk of the Health Software
Product remains acceptable.

The validation report shall document the

validation conditions and the results of the
validation activities. If, during validation,
anomalies were identified in the Health
Software Product, these shall be listed in the
validation report.
The validation report shall list the members of
the validation team (name, affiliation,
function).
The validation report shall include a summary
of the validation results, and the conclusion
that the Health Software Product is validated
for the intended use, based on the use
requirements.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 14 of 30
7 Health Software Product identification and accompanying documents
7.1 Identification

Y/N/ Procedure, Plan, or Document references

Section Conformity Requirements NE/ (If level of detail in section 4 is not considered a sufficient Comments
NA mapping)
A Health Software Product shall be identified
with the name or trademark of the
manufacturer, a product name, or type
reference, and a unique version identifier such
as a revision level or date of release/issue.
The identification of the Health Software
Product shall be accessible to the user when
using the Health Software.

7.2 Accompanying Documents

7.2.1 General

Section Conformity Requirements Y/N/ Procedure, Plan, or Document references Comments

NE/ (If level of detail in section 4 is not considered a sufficient
NA mapping)
The manufacturer shall make available
accompanying documents for the Health
Software to allow the user and/or responsible
organization to implement and use the Health
Software Product as intended.
The accompanying documents shall include:
a. The name and contact information,
including the website, of the
manufacturer;

b. the Health Software Product

identification (see (7.1)

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 15 of 30
 c. the version identifier(s) of the Health
Software Product(s) such as revision
level(s) or date(s) of release/issue,
necessary to identify the Health
Software Product(s) to which it
applies;
d. the version identifier of the
accompanying documents such as
revision level or date of release/issue;
e. the instructions for use (see 7.2.2);
and

f. the technical description (see 7.2.3).

The accompanying documents may include

software release notes and an indication of
typical installatino environments.
The accompanying documents shall specify
any special skills, training and knowledge
required of the intended user or the
responsible organization, any restrictions on
locations or environments in which the Health
Software Product can be used, and, as
applicable, any system interface, software
platforms and tools, and hardware
requirements or restrictions.
The accompanying documents shall be
provided at a level consistent with the
education, training and nay special needs of
the person(s) for whom they are intended.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 16 of 30
7.2.2 Instructions for use

Section Conformity Requirements Y/N/ Procedure, Plan, or Document references Comments

NE/ (If level of detail in section 4 is not considered a sufficient
NA mapping)
7.2.2.1 General
The instructions for use shall document
all that is necessary for proper operation
of the Health Software Product, including
installation instructions where
appropriate.
If applicable, the instructions for use shall
specify restrictions on an IT-NETWORK
on which the Health Software Product is
intended to be used (see 7.2.3.2).

7.2.2.2 Health Software description

The instructions for use shall contain:
a. the intended use of the Health
Software Product as defined by the
manufacturer;

b. a brief description of the Health

Software Product, including the
essential functions of the Health
Software Product;

c. any operational security options for

the use of the Health Software; and

d. any known technical issues,

limitations, disclaimer, or
contraindication(s) to the use of the
Health Software Product.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 17 of 30
7.2.2.3 Warnings and notices for safety
and/or security
The instructions for use shall list all warnings
and notices for safety and/or security related to
the use of the Health Software Product and
explain or expand them when they are not
self-explanatory.
General warnings and notices for safety and/or
security should be placed in a specifically
identified section of the instructions for use. A
warning or a notice for safety or for security
that applies only to a specific instruction or
action should precede the instruction to which
it applies.
7.2.2.4 Installation
The instructions for use shall contain:
a. a statement whether the installation
can be done by the user or shall be
done by or with the assistance of the
manufacturer, or by an authorized
person;
b. the system requirements for the
software and hardware platforms
intended to execute the Health
Software;
c. operational security options for the
Health Software to be set at
installation time;
d. any critical dependencies on other
applications;

e. the configuration requirements;

f. the system interface requirements

(both required and optional);

g. the details of the supported software

platforms; and

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 18 of 30
 h. the installation instructions or a
reference to where the installation
instructions are to be found.
7.2.2.5 Start-up procedure
The instructions for use shall contain the
necessary information for the user to bring the
Health Software into operation
7.2.2.6 Shutdown procedure
The instructions for use shall contain the
necessary information for the user to safely
shut down the operation of the Health
Software.
7.2.2.7 Operating instructions
The instructions for use shall contain all
information necessary to operate the Health
Software. This shall include explanation of the
function of controls, displays and signals and
the sequence of operation.
The instructions for use shall explain the
meanings of figures, symbols, warning
statements and abbreviations.
7.2.2.8 Messages
The instructions for use shall list all system
messages, error messages and fault messages
that are generated, unless these messages are
self-explanatory.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 19 of 30
The list shall include an explanation of
messages including important causes, and
possible action(s) by the user, if any, that are
necessary to resolve the situation indicated by
the message.
7.2.2.9 Decommissioning and disposal of
Health Software
The instructions for use shall contain all
information necessary for the user or the
responsible organization to safely
decommission and dispose of the Health
Software. This shall include, where
appropriate, safeguarding personal and health-
related data in connection with security and
privacy.
7.2.2.10 Reference to the technical
description
The instructions for use shall contain the
technical description (see 7.2.3) or a reference
to where the technical description can be
found.

7.2.3 Technical description

Section Conformity Requirements Y/N/ Procedure, Plan, or Document references Comments

NE/ (If level of detail in section 4 is not considered a sufficient
NA mapping)
7.2.3.1 General
The technical description shall provide all data
that is essential for safe and secure operation,
transport and storage, and measures or
conditions necessary for installing the Health
Software, and preparing it for use. This shall
include:
a. the system requirements for the
software and hardware platforms
intended to execute the Health
Software;

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 20 of 30
 b. the details of the supported software
platforms;

c. the permissible environmental

conditions for transport and storage
of the media containing the Health
Software.
d. all characteristics of the Health
Software, including range(s),
accuracy, and precision of the
displayed values or an indication
where they can be found;
e. any special installation requirements
or restrictions;

f. any maintenance requirements, such

as log files to be checked and
possibly cleared, database
maintenance, and change of storage
media;
g. any technical security options that
can be configured within the Health
Software Product, and that are
available to the responsible
organization. Such security may
include:
1. configuration options, e.g.
minimum list of network ports
and computer services that are
required.
2. software options, e.g. turn on
encryption settings, change
default login credentials.
3. operational options, e.g. auditing
and logging management
settings.
h. a description of what the software
does when a failure to maintain
security is detected. The description
shall include any impact to patient
care, data, or clinical workflow.
Copyright © 2017, Crisis Prevention and Recovery, LLC
(CPRLLC), all rights reserved. Rev 1 Page 21 of 30
The manufacturer shall provide instructions in
the technical description for the user and/or
the responsible organization on how to deal
with changes of the hardware and software
platforms (e.g., with patches /updates of
antivirus/firewall software, system libraries,
firmware, and others), and how to select
appropriate platform settings to support the
security goals and security capabilities.

7.2.3.2 Health Software intended to be used

in an IT-Network
The scope of the IT-Network may include
supporting IT infrastructure or systems not
explicitly intended to be used in a healthcare
setting. See 3.9.
If the Health Software is intended to be used
in an IT-Network that is outside the control of
the Health Software Manufacturer, the
manufacturer shall provide, as part of the
technical description, instructions necessary
for this use, including but not limited to the
following:
a. the characteristics and configuration
of the IT-Network required for the
Health Software to achieve its
purpose;
b. the technical specifications of the IT-
Network necessary for the Health
Software to achieve its purpose,
including security specifications and
protection against malware (short for
malicious software) or similar;
c. the intended information flow
between the Health Software and
other software or systems using the
IT-Network.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 22 of 30
The manufacturer shall include in the
technical description a list of the hazardous
situations resulting from a failure of the IT-
Network to provide the characteristics and
services required for the purpose of the Health
Software when using that IT-Network.
In the technical description, the manufacturer
shall inform the responsible organization that:

a. execution of the Health Software on a

IT-Network could result in
previously unidentified risks to
patients, users or third parties;
b. the responsible organization is
advised to identify, analyze, evaluate,
and control these risks;
c. subsequent changes to the IT-
Network could introduce new risks
and require additional analysis; and
d. changes to the IT-Network include:
1. changes in IT-Network
configuration;
2. addition of items (hardware
and/or software platforms or
software applications) to the
IT-Network;
3. removal of items from the
IT-Network;
4. update of hardware and/or
software platforms or
software applications on the
IT-Network; and
5. upgrade of hardware and/or
software platforms or
software applications on the
IT-Network.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 23 of 30
8 Post-market activities for the Health Software Product
8.1 General

Y/N/ Procedure, Plan, or Document references

Section Conformity Requirements NE/ (If level of deail in section 4 is not considered a sufficient Comments
NA mapping)
According to clause 1, this document covers
the entire life cycle of health software. Within
its life cycle, health software is likely to
undergo software maintenance and, at the end,
decommissioning and disposal. Subclause 4.2
addresses use requirements to be
implemented and validated prior to making the
product available for use; those requirements
include decommissioning and disposal of a
health software product. When this document
is used for compliance purposes, only the
post-market aspects that relate to product
design and development apply.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 24 of 30
8.2 Software Maintenance

Y/N/ Procedure, Plan, or Document references

Section Conformity Requirements NE/ (If level of deail in section 4 is not considered a sufficient Comments
NA mapping)
Where the manufacturer decides that software
maintenance is relevant or necessary, for
instance, due to detected errors that can have
an impact on safety and/or security, the
manufacturer shall develop the modification of
the Health Software Product in compliance
with this document (see Clause 5).

8.3 Re-validation

Y/N/ Procedure, Plan, or Document references

Section Conformity Requirements NE/ (If level of deail in section 4 is not considered a sufficient Comments
NA mapping)
The manufacturer shall ensure re-validation
takes place of the parts of the health
software product that have been affected by
the software maintenance, taking into
account the extent of the modification. The
manufacturer shall update the validation plan
accordingly.
The manufacturer shall ensure that the
modified version of the health software
functions with any hardware and software
platform that is claimed to be supported.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 25 of 30
8.4 Post-market communication on the Health Software Product

Section Conformity Requirements Y/N/ Procedure, Plan, or Document references Comments

NE/ (If level of deail in section 4 is not considered a sufficient
NA mapping)
The manufacturer shall inform users of the
health software product and impacted
responsible organizations about security
vulnerabilities the manufacturer has become
aware of, and of changes in regulatory
requirements that impact the use of the Health
Software Product.
In the case of software maintenance, the
manufacturer shall make information available
to users and to the responsible organizations of
the availability of the updated version of the
Health Software Product, and provide
information about the following, where
appropriate:

a. new features;

b. corrected errors or faults;

c. any impact on safety and/or security

of the modified software;

d. updates in the Health Software

identification;

e. updates in the accompanying

documents.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 26 of 30
The decision of the user or the responsible
organization whether to install the modified
version of the health software should be based
on safety and/or security impacts of the
modifications. Where the modified health
software product has a positive impact on the
safety and/or security of the health software,
manufacturer may advise the users and
the responsible organizations to replace their
version in the short term.

8.5 Decommissioning and disposal of the Health Software Product

Y/N/ Procedure, Plan, or Document references

Section Conformity Requirements NE/ (If level of deail in section 4 is not considered a sufficient Comments
NA mapping)
The user or the responsible organization shall
be able to safely decommission and dispose
of the health software product at the end of its
useful life, including, where appropriate,
safeguarding personal and health-related data
in connection with security and privacy. The
health software shall provide this function
consistent with the applicable use
requirements as specified in 4.2.

9 Software Problem Resolution Process (all are for all classes)

Section Conformity Requirements Y/N/ Procedure, Plan, or Document references Comments
NE/ (If level of deail in section 4 is not considered a sufficient
NA mapping)
9.1 Problem reports exist for each problem
detected in the software and include a
statement of criticality (effecton performance,
safety or security) as well as other information
that may aid in resolution (for example,
devices affected, supported accessories
affected).
Copyright © 2017, Crisis Prevention and Recovery, LLC
(CPRLLC), all rights reserved. Rev 1 Page 27 of 30
9.2 Problem are investigated
a) to determine the cause,
b) evaluate the problem’s relevance to safety
c) investigation results are documented
d) change requests are created for actions
needing correct or and rationales for taking no
action are documented
9.3 Relevant parties are advised of the
existence of the problem, as appropriate.

9.4 Change requests are approved observing

the requirements of the change control
process. NOTE: a special process may exist
for emergencies and their appropriateness and
overuse checked. If none exists consider if the
company is prepared to handle an emergency
related to the risk of the device.

9.5 Records of problem reports and their

resolution and verification are kept. The Risk
Management file is updated as appropriate.
9.6 Problem reports are analyzed for trends
not just individually

9.7 Resolutions of problems are verified to

determine whether:
a) problems are resolved and the problem
report closed
b) adverse trends have been reversed
c) change requests have been implemented in
all relevant software items and associated
documents
d) additional problems have been introduced
by the changes.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 28 of 30
9.8 Testing and regression testing
documentation following a fix, includes:
a. Test results
b. Anomalies found
c. Software version tested
d. Relevant hardware and software test
configurations
e. Relevant test tools
f. Date tested
g. Identification of the tester.

END OF CHECKLIST
REMEMBER TO REFER TO THE STANDARD ITSELF, AS THIS CHECKLIST IS NOT INTENDED TO BE USED IN ISOLATION
FROM THE STANDARD OR KNOWLEDGE AND TRAINING IN PROPER INTERPRETATION OF THE STANDARD.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 29 of 30
SoftwareCPR® provides a full range of regulatory and compliance related services. Many services
involve application and use of this standard and many other international standards and TIRs for
safety. A complete list of services is provided on our website
www.softwarecpr.com/companyinfoframepage.htm.
A few services of interest are listed below.
1. IEC 62304 and IEC 82304-1 training, assessments, audits, and hands-on development of tailored
software development processes, including various lifecycles (e.g., spiral, Agile, etc.).
2. ISO 14971 Medical Device and Software Risk Analysis training, assessments, audits, and hands-
on support for both system level and software risk analysis (in concert with IEC/TR 80002-1).
3. FDA Human Factors evaluations, formative and summative, to support regulatory submissions.
IEC 62366 training, assessments, audits, and hands-on support for formative evaluations,
summative studies, and Use Error risk analysis.
4. FDA QSR and ISO 13485 Quality System mock-audits, assessments and assistance with
inspections and audits.
5. Cybersecurity training, assessments, penetration testing, and process evaluation.
6. Wireless Coexistence test planning, protocol development, and hands-on “day of” testing support.
7. Regulatory submission preparation with particular expertise with software, cybersecurity, and
usability documentation.
§ Articulation in FDA Terminology
§ Planning and reviewing
§ FDA interaction and negotiation – inspections, submissions, injunctions, and consent decrees
§ Deciding when to submit a new 510(k)
§ MDR evaluations, Field Corrections and Recalls
8. Full range of V&V services including test planning and protocol development for both manual
and automated test assets. We can jump-start entry into automated test assets providing training,
test asset development, and coaching.
Website information service and knowledgebase
A subscription to our website provides access to complied FDA software related warning letters and
recalls, SoftwareCPR® checklists and example training documents, and ensures you and your staff
are kept up to date on software related regulatory news, guidance, and standards.

Copyright © 2017, Crisis Prevention and Recovery, LLC

(CPRLLC), all rights reserved. Rev 1 Page 30 of 30