Standards Development

Scope

NOTE Guidance for this clause can be found in Annex B.

This document defines the life cycle requirements for health software. The set of processes, activities and tasks described in this document establishes a common framework for health software life cycle processes.

NOTE 1 Guidance for this clause can be found in Annex B.

This document applies to the development and maintenance of health software by a manufacturer. Medical device software is a subset of health software. Therefore, this document applies to:

–        software as part of a (physical) medical device;

–        software as part of specific health hardware;

–        software for a software-only medical device (SaMD);

–        software for a software-only product intended to be used specifically for managing, maintaining, or improving health of individuals, or for the delivery of care;

–        health software with artificial intelligence (AI ) including machine learning (ML) algorithms

NOTE 2 Examples of health software include the following:

a)       software as a part of a medical device: software that is an integral part of a device such as an infusion pump or dialysis machine.

b)       software as part of specific health hardware: patient diagnostic wristband, printer software, healthcare scanner software, diagnostic app on specific wearable hardware (i.e. watch, wristband, chestband).

c)       software as a medical device (SaMD): software that is itself a medical device, such as a software application that performs diagnostic image analysis for making treatment decisions. A definition of software as a medical device is provided in [44] 1.

d)       software-only product for other health use: hospital information systems, electronic health records, electronic medical records, mobile diagnostic applications running on devices without physiologic sensors or detectors, clinical software as a service, i.e. software executed in an external environment, providing diagnostic calculation-results that fulfil the definition of a medical device.

Before any type of software can be placed into service, activities are necessary before the software is integrated into the PRODUCT. These PRODUCT-LEVEL activities are not covered by this document (see Figure 1), but can be found in related product standards.

NOTE 3 This document can be used in the development and maintenance of software that either is embedded into a medical device or that is itself a medical device. In both cases, additional development activities are needed at the product-level before this type of software can be placed into service. These product-level activities are not covered by this document, but can be found in standards such as IEC 60601-1 [5] or IEC 82304-1 [6].

In this document, chapters relate to processes, sections relate to activities, and subsections relate to tasks .

This document describes processes that are intended to be applied to software that executes on a processor (including virtualisation and cloud-based environments) or that is executed by other software (for example an interpreter) which executes on a processor (including virtualisation and cloud-based environments).

This document applies regardless of the persistent storage device(s) used to store the software (for example: hard disk, optical disk, permanent or flash memory or cloud storage).

This document applies regardless of the method of delivery of the software (for example: transmission by network or email, cloud storage, optical disk, flash memory or EEPROM). The method of software delivery itself is not considered health software.

This document does not cover the means of validation of the final product, even when the product consists entirely of software. It also does not cover software life cycle steps after release for intended use of the product, including implementation, configuration, integration (with other systems), go-live, clinical use, operations, decommissioning or disposal, other than activities involving maintenance of the software.

This document does not cover the validation of software tools used in the design of medical devices (e.g. computer aided design (CAD) software), software used in medical device quality systems or software for regulated processes (see ISO/TR 80002-2:2017 [7]).

Data quality and validation of emergent characteristics or functionality of artificial intelligence (AI ) health software are not within the scope of this document.

NOTE 4 The 2nd edition of this document recognizes that there is a data life cycle for training data used as an essential input to AI-enabled software items. Users of this document can use other standards and technical sources to supplement this document in addressing the unique performance characteristics of their AI.

NOTE 5 If a product incorporates embedded software intended to be executed on a processor, the requirements of this document apply to the software, including the requirements concerning software of unknown provenance (SOUP) – see 8.1.2)

NOTE 6 Validation and other development activities are needed at the product level before the software and incorporating products can be placed into service. These product-level activities are not covered by this document, but can be found in related product standards (e.g. IEC 60601-1 [5], IEC 82304-1 [6], etc.).

This health software life-cycle document is written in a way that it can be used together with reference standards when developing and maintaining a product that includes health software (see Annex C).

Conformity is determined by inspection of all the documentation required by this document including an assessment of processes, tasks and activities required for the software process rigour level.

Conformity of legacy software may be demonstrated as indicated in Annex G.

NOTE Where any requirement contains “as appropriate" and is not performed, documentation for the justification is necessary for this assessment.