Contents PageForeword ...iv Introduction ...v 1 Scope ...1 2 Terms and definitions ...1 3 Abbreviated terms ...6 4 Health software safety ...6 4.1 Health software safety incidents ...6
Health software safety incidents
The National Health Service (NHS) Connecting for Health IT program established a proactive safety incident management process to address software safety in England During the five year period from
Between 2006 and 2010, 708 incidents related to health software were reported and investigated, with around 80% identified as posing risks to patient safety In response, an action plan was implemented to ensure that incidents could be addressed within 24 hours While other countries lack specific data or are still in the early stages of data collection on health software safety incidents, the NHS data highlights the potential harm to patients and the unintended consequences of health software This risk would likely be significantly greater if the NHS had not established a proactive program to manage software safety risks.
Examples of safety related incidents, from the UK and elsewhere, include the following:
— systems either failing to produce appropriate alerts for patients or not maintaining and updating these alerts to reflect new treatment protocols,
— drug name mapping errors and other errors related to clinical terminology, especially where data are integrated from different care settings, information systems, or organizations,
— wrongly computed ages for patients, e.g for pre-natal screening or immunization,
— radiotherapy or drug dose rates that were calculated, presented or communicated incorrectly due to calculation or unit conversion errors,
— clinicians incorrectly interpreting clinical data presented to them through an interface from another system without the full context of the presented data also being provided,
— annotations to a medical image not being displayed in the correct position,
— data missing from patient profiles without clinicians being aware of it, due to source systems or interfaces not being available or maintained correctly,
— images from Picture Archiving and Communication Systems (PACS) not being retrievable by clinicians in a timely manner,
— data migration errors when new systems are put into operation or major systems are upgraded,
— software maintenance errors affecting patient identification, that subsequently cause lab or diagnostic results to go to the wrong clinicians,
— clinical decision support rules not being triggered consistently because some of the source data was recorded in a different context or mapped incorrectly,
— security breaches that compromised system integrity or availability, and
— extended unavailability of system operations.
The systematic reporting of patient safety incidents related to health software is crucial for developing best practices and enhancing safety culture in health informatics, paralleling efforts in clinical practices since 2000 As health software becomes increasingly complex due to component-based approaches, service-oriented architectures, and intricate decision support algorithms, both the benefits and risks are likely to rise Therefore, clear guidance and coherent standards are essential for healthcare organizations, vendors, and stakeholders to collaborate effectively, ensuring safe and sustainable software implementations while fostering a robust health software safety culture.
Health software definitions
Software definitions, including software items, systems, and units, are outlined in various standards such as ISO/IEC 90003:2004, which offers guidelines for applying ISO 9001:2000 to computer software, and IEC 62304:2006, which focuses on medical device software.
The software life cycle processes provide essential definitions that aid in understanding granularity, yet a significant distinction arises when these definitions are applied to healthcare This distinction differentiates between software classified as a medical device and health software that does not fall under this category.
Medical device software is defined as a software system designed to be integrated into a medical device or intended for standalone use as a medical device, as outlined in IEC 80001-1:2010, which modifies IEC 62304:2006.
Health software products are defined as software designed for use in the health sector for health-related purposes, specifically excluding software required for the proper functioning of medical devices (ISO/TS 25238:2007, 2.3).
As seen from the application of medical device regulations globally, the definition of software as a medical device may vary in certain regulations and may change over time.
This Technical Report defines healthcare software as any software that influences patient care, irrespective of its classification as medical device software The European Union’s Coordination Committee of the Radiological, Electromedical and Healthcare IT Industry (COCIR) emphasizes the need for international standardization committees, such as IEC/TC 62 and ISO/TC 215, to create standards and publications with a comprehensive scope.
This Technical Report targets health software with the following characteristics:
Software, in its fundamental definition, encompasses systems, components, and units as outlined in IEC 62304:2006 This includes digitally stored data such as data tables, rule sets, coding systems, content models, inference engines, archetypes, ontologies, and the necessary documentation for the effective use and maintenance of the software.
Software utilized in the health sector encompasses any application that is consumed, employed, or applied throughout its lifecycle to enhance health and healthcare services This broad definition includes both public and private organizations dedicated to individual health, as well as consumer health services such as personal health records and mobile applications.
— software includes that which is commercially and non-commercially available.
Illustrative examples of health software are:
— patient registries and enterprise master patient indices, electronic health records (EHRs) and electronic medical records (EMRs),
— order entry and results reporting systems,
— immunization reporting and tracking systems,
— scheduling systems for patients, clinicians, or clinical resources (e.g for surgeries),
— mental health systems or disease specific systems, and
— population health systems insofar as these focus on individuals (e.g immunizations, alerts, outbreaks, etc.).
As the e-health landscape becomes more interconnected, this report defines health software to encompass patient administrative systems, including appointment scheduling and resource management.
Illustrative examples of software that are not included as health software by way of this Technical Report are:
— financial, human resource, materials management systems,
— population survey and population surveillance systems,
— generic word processing, spreadsheet, or database software systems, and
Towards safer health software
The family of standards identified and assessed in this Technical Report provides the means to reduce risk and strive towards safer health software as these standards are adopted.
Achieving completely safe software for patient interactions is an admirable goal, but it is impossible to eliminate all risks Consequently, a risk management approach is essential to minimize health software risks to acceptable levels This risk-based strategy focuses on reducing risks throughout the entire lifecycle of health software, as outlined in section 4.4, thereby fostering the development, implementation, and operation of safer health software.
Health software lifecycle
A framework is essential for evaluating the relevance and effectiveness of standards in ensuring safety in health software This framework will help identify the applicability of existing standards and highlight any gaps that may exist.
Software lifecycle models serve as essential frameworks for organizing and managing the entire process of software product development, operation, maintenance, and retirement, from inception to termination, as outlined in ISO/IEC 12207:2008 These models facilitate a thorough evaluation of standards, ultimately promoting the development of safer health software.
This Technical Report adopts a pragmatic approach to lifecycle models, facilitating a comprehensive view and assessment It emphasizes the importance of addressing fundamental questions that define the steps in the software life cycle.
— whether there is a change in risk from one step to another,
— whether there is a different risk profile, risk management characteristic or need for mitigation between one step and another, and
— whether there is a propagation of risk from one step to another.
The validity of any of the three points may necessitate the adoption of varying standards, highlighting the importance of addressing these questions during the risk analysis process.
This Technical Report outlines lifecycle steps that are either derived from established standards or represent unique changes in risk management profiles that necessitate the adoption of alternative standards These steps highlight gaps in current standards, emphasizing the need for a more tailored approach to risk management.
The iterative process of defining lifecycle steps utilizes analysis results from a "working software life cycle" to create a final, usable software lifecycle It is essential to identify the minimum number of lifecycle steps necessary for a thorough assessment of standards that ensure safety in health software.
A software lifecycle differs from the software development lifecycle (SDLC), even though the standards of the SDLC influence this Technical Report The steps outlined in the software lifecycle are independent of any specific SDLC.
Also noteworthy for the purposes of this Technical Report, the software lifecycle has both steps and events:
— steps are those components of the software lifecycle with associated work activities, assigned resources and outputs, and
— events are those components that are significant occurrences at a given place and time.
Health software lifecycle steps include a complex array of linear and iterative actions that together compose the continuous management of that software by all parties involved:
— developers are responsible for the design, development, manufacture and maintenance of the health software (also referred to as “manufacturer” or “supplier” in some standards),
— implementers are responsible for the installation and integration of the software in a clinical setting (an implementer may be the developer or the owner),
— owners are the healthcare organizations procuring the software (and/or may be the implementers for a managed service),
— operators are responsible for the provision of the clinical service through the use of health software, and
— users are the persons using the health software in the clinical setting, which may include, for example, consumers in the case of personal health records.
To assess safety standards in health software, it is essential to differentiate the risk profile, characteristics, needs, and assumptions through specific lifecycle steps, as outlined in Annex B.
NOTE 1 These steps do not necessarily imply a linear ordering or time sequence.
NOTE 2 Where available, lifecycle step descriptions are referenced; where not available, lifecycle step descriptions are informative only.
The Concept Document outlines the initial design, aesthetics, and primary functions of the software, focusing on the creative and imaginative aspects In contrast, the Requirements Document defines the needs, expectations, and obligations that are either stated or implied by the organization, its customers, or other stakeholders.
Design Document The phase of software development following analysis, and concerned with how the problem is to be resolved.
[see SKMT – Canada Health Infoway Glossary: 2012]
Document c Design and development is a process (or a set of processes) using resources to transform requirements (inputs) into characteristics or specifications (outputs) for products, pro- cesses and systems d
Production Making available the product for client or user D
Release Distribution A release is a specific version of a configuration item that is made available or released for a particular purpose e [see ISO/IEC 90003:2004]
Procurement Purchasing a commercially available product or engaging an organization for the production of “bespoke or in-house developed” software.
Software conformance testing and certification may also be included in the implementation step, either as a first or pre- installation step.
Go-Live To make some system, which had been under development or operating in a limited test mode, fully active so that its intended users can access it.
Operation Any use of the health software within any non-test setting
It is recognized that for new software there may be a lag between it entering operation and full clinical use.
Clinical Use The practical and full use of the software in a clinical setting
As linked to this Technical Report’s definition of health soft- ware, the software step of clinical use and its “… impact on the health and healthcare of a subject of care.“
Maintenance Software maintenance in software engineering is the modi- fication of a software product after delivery to correct faults, to improve performance or other attributes.
Decommission The system is removed from the operational environments, and system work products and data are archived in the appropriate manner f
Disposal Retiring and ending the existence of a system’s existing soft- ware products or services while preserving the integrity of organizational operations
Not every Standard Lifecycle Step includes a Substep The roles involved in this process are Developer (D), Implementer (I), Owner-Operator (OO), and User (U), with the Developer also referred to as the manufacturer Design and development can be viewed as either distinct stages within a unified process or as separate processes, as outlined in ISO 9000, ISO 9001, or ISO 9004 During this phase, the system and all related products are handed over to the client or user Additionally, data may be migrated from one system to another while ensuring semantic integrity is preserved.
The authors of this Technical Report recognize that the terminology related to the software lifecycle, especially concerning safety in health software, is not static They note that definitions may evolve as new standards are developed, particularly when existing ISO or recognized standards are lacking Additionally, they acknowledge the existence of alternative software models, such as the Generic Component Model (GCM) and its related standards taxonomy Future analyses could further explore and categorize health software safety standards, as outlined in this report, utilizing the GCM taxonomy in subsequent standard developments.
A summarization of the lifecycle into the following five categorizations of the lifecycle steps is useful for purposes of this Technical Report:
1) design: encompassing concept, requirements and design steps
2) development: encompassing development, production and release steps
3) implementation: encompassing installation, configuration, integration and go-live steps
4) operations: encompassing operation, clinical use and maintenance steps
5) decommissioning: encompassing decommissioning and disposal steps
The outlined lifecycle steps, both in detail and summary, provide an acceptable framework for assessing the safety of health software in accordance with established standards.
How standards were selected for assessment
Health software developers, implementers, and users can enhance safety by adhering to various relevant standards This Technical Report compiles a selection of standards for assessment, gathered from diverse sources based on specific criteria.
— the published standards and current work program of ISO/TC 215 Health informatics,
— the published standards and current work program of ISO/TC 210 Quality management and corresponding general aspects for medical devices,
— the published standards and current work program of IEC/TC 62 SC62A Common aspects of electrical equipment used in medical practice,
— the published standards and current work program of ISO/TC 176 Quality management and quality assurance,
— the published standards and current work program of ISO/IEC JTC 1 and its subcommittees and the work of ISO/IEC Technical Advisory Group, Safety, and
— expert reviews of general, IT market and health informatics standards relating to good development practice and product safety.
Several criteria were applied to determine whether a standard should be among those considered by this Technical Report A standard was considered if:
— the standard was developed by an international or multinational standards development organization,
— the standard could be used during one or more steps of the health software lifecycle,
— the standard was used in more than one country (as identified in informal review of standards sources as listed above),
— the standard is applicable to, or references, software or health software as identified or defined within this Technical Report, and
— the standard addresses risk and safety.
All relevant standards, including quality and risk management standards, as well as systems engineering standards (e.g., JTC 1), serve as essential foundations for best practices in software life cycle processes, risk management, and enhanced safety These standards are categorized for convenient reference.
Successful health software design, development, implementation, and operation rely on various applicable standards, including attribute standards These standards identify essential software characteristics and features that are testable and beneficial for health software developers, implementers, and users, ultimately enhancing safety in health software.
Functional and data standards are essential for ensuring the safety of health software throughout its lifecycle Neglecting to implement relevant, purpose-specific attribute standards can pose risks at any stage of health software development.
Safe health software standards are supported by informative guidance that aids in their application Relevant guidance for each assessed standard is detailed in the "relationship" section, as outlined in Clause 5.1.
Standards assessed in this Technical Report
Tables 2 and 3 in this Technical Report outline the assessed standards, detailing each standard's number, title, and the responsible standards development organization, including Technical/Subcommittee identification Table 2 focuses on foundational standards for health software safety, while Table 3 highlights standards relevant to medical devices and specific health software contexts.
Table 2 — Foundational standards relevant to safe health software
Scope Standard(s), Guides and Reports SDO
Quality Management ISO 9000:2005 Quality management systems — Fundamen- tal and vocabulary
ISO 9001:2008 Quality management systems —Require- ments
ISO 10005:2005 Quality management systems — Guidelines for quality plans
ISO 10006:2003 Quality management systems — Guidelines for quality management in projects
ISO 10007:2003 Quality management systems — Guidelines for configuration management
ISO/IEC 90003:2004 Software engineering — Guidelines for the application of ISO 9001:2000 to computer software a
ISO/TC 176 and ISO/IEC JTC 1
SC 7 a ISO/IEC TR 90003, currently under development within ISO/IEC JTC 1/SC 7, is intended to replace ISO/IEC 90003:2004
Scope Standard(s), Guides and Reports SDO
Software and Systems Engi- neering ISO/IEC 12207:2008 Systems and software engineering —
ISO/IEC 20000 Information technology — Service manage- ment (multi-part series)
ISO/IEC 25000 Software Engineering — Software product
Quality Requirements and Evaluation (SQuaRE) – Guide to SquaRE (part of a multi-part series)
ISO/IEC 15026 Systems and software engineering — Systems and software assurance (multi-part series) ISO/IEC 15504 Information technology — Process assess- ment (multi-part series)
Also the ISO/IEC 27000 series known as ‘ISMS Family of Standards’
ISO/IEC JTC 1 SC 7 and SC27
Risk Management ISO 31000:2009 Risk management — Principles and guide- lines
ISO Guide 73:2009 Risk management — Vocabulary
ISO Technical Management Board (TMB)
Ergonomics of human-sys- tem interaction ISO 9241-129:2010 Ergonomics of human-system interaction
— Part 129: Guidance on software individualization
ISO/TR 16982:2002 Ergonomics of human-system interac- tion — Usability methods supporting human-centred design
Safety ISO/IEC Guide 51:1999 Safety aspects — Guidelines for their inclusion in standards Joint ISO/IEC
Technical Advisory Group, Safety a ISO/IEC TR 90003, currently under development within ISO/IEC JTC 1/SC 7, is intended to replace ISO/IEC 90003:2004
Table 3 — Standards for a medical device or specific health software context
ISO 13485:2003 outlines the requirements for quality management systems specifically for medical devices, ensuring compliance with regulatory standards Additionally, IEC 62304:2006 defines the software life cycle processes for medical device software, providing a framework for managing software development and maintenance Together, these standards are essential for ensuring the safety and effectiveness of medical devices in the healthcare industry.
ISO/TC 210 Risk Management ISO 14971:2007 Medical devices — Application of risk man- agement to medical devices ISO/TC 210
Risk Management IEC 80001–1:2010 Application of risk management for IT- networks incorporating medical devices — Part 1: Roles, responsibilities and activities
IEC/TC 62 SC62A ISO/TC 215
ISO 27799:2008 provides guidelines for information security management in health informatics, utilizing the framework of ISO/IEC 27002 Additionally, ISO/TR 27809:2007 outlines measures to ensure patient safety in health software, while ISO/TS 25238:2007 focuses on the classification of safety risks associated with health software These standards collectively enhance the security and safety of health informatics systems.
Usability Engineering IEC 62366:2007 Medical devices — Application of usability engineering to medical devices ISO/TC 210 a Includes references to ISO/IEC 27001, ISO/IEC 27002, and ISO/IEC 27005
Risk management basis
The assessment of safety standards in health software primarily hinges on their effectiveness in mitigating risks throughout various lifecycle stages of the software.
Risk management is the systematic application of management policies, procedures and practices to the tasks of analysing, evaluating and controlling risk In ISO 31000, risk management is defined as
“coordinated activities to direct and control an organization with regard to risk Risk management generally includes risk assessment, risk treatment, risk acceptance and risk communication”.
A generic approach to risk management is defined in the widely recognized ISO 31000 and related standards:
— ISO 31000:2009, Principles and guidelines on implementation,
— IEC 31010:2009, Risk management — Risk assessment techniques, and
— ISO Guide 73:2009, Risk management — Vocabulary
ISO 31000 serves as a foundational framework for developing risk management standards and offers guidance applicable throughout an organization's lifecycle across various activities It is versatile enough to address any type of risk, regardless of its nature or potential outcomes, but it does not specifically focus on safety For guidance on incorporating safety considerations into standards, refer to ISO/IEC Guide 51.
Health-related risk management is outlined in ISO 14971:2007, which focuses on the application of risk management to medical devices, along with IEC/TR 80002-1, providing guidance for medical device software These standards are essential for manufacturers of medical devices and software, including Laboratory Information Systems (LIS) and Picture Archiving and Communication Systems (PACS).
Health-related risk management is outlined in IEC 80001-1:2010, which focuses on the application of risk management for IT networks that include medical devices This standard emphasizes the roles, responsibilities, and activities necessary to address risks during both the implementation and operation of these systems.
For valuable insights on risk management in health software, refer to ISO/TR 27809:2007, which focuses on measures to ensure patient safety, and ISO/TS 25238, which classifies safety risks associated with health software.
Effective risk management is essential for ensuring safety in health software, particularly in addressing risk sharing and residual risk throughout its lifecycle According to ISO Guide 73, risk sharing is defined as a method of risk treatment that involves the agreed distribution of risk among different parties.
When a health software product is released (i.e the release event) to market by a software manufacturer some level of risk to patients remains which is the residual risk.
NOTE From a regulatory standpoint, release of a health software product is also the point at which post- market versus pre-market regulatory and related stipulations may be applied.
Throughout the software life cycle, the responsibility for residual and shared risks shifts When an implementer acquires a commercially available product or develops software in-house, they implicitly or explicitly accept responsibility for known residual risks Despite these risks, the implementer acknowledges that the manufacturer’s health software meets or will meet the specified requirements.
Implementing purchased or in-house developed health software introduces new risks related to configuration, integration, data quality, and clinical use The responsibility for managing these safety risks is shared among multiple parties, including the developer, implementer, owner/operator, healthcare delivery organization, and ultimately the system users.
Effective communication of risks is crucial at each transition between lifecycle steps, especially with the introduction of new parties It is essential to clearly define responsibilities for risk controls and response mechanisms Organizations involved later in the software lifecycle must understand these liabilities and associated risks, along with the strategies they can implement to manage them effectively.
When evaluating health software, it is crucial to assess risk sharing in relation to standards This involves determining whether a standard is applicable at various transition points where risks are distributed among multiple stakeholders It is essential to identify which parties—such as the developer, implementer, owner-operator, or user—are responsible for taking action to manage these risks effectively.
Human factors basis
Human factors is the study of the physical and psychological interactions between people and various products, tools, procedures, and processes The main goal of this discipline is to ensure that technology is designed to operate in a manner that feels intuitive and natural for users.
The increasing complexity of healthcare systems has led to challenges for healthcare professionals, who must navigate multiple systems that often overlook human capabilities This complexity heightens the risk of errors To mitigate these risks and enhance safety in health software, organizations should integrate a human factors approach and adopt a User-Centered Design (UCD) methodology in their system design processes.
The human factors discipline plays a crucial role in health software development by promoting an iterative design process that actively involves end users It also establishes organizational processes aimed at ensuring that health software is effectively tailored to meet the needs of humans and their environments.
ISO 9241 is a multi-part standard providing a comprehensive foundation addressing various elements of the ergonomics of human-computer interaction.
The following two complementary standards outline human factors principles to be followed when designing medical devices:
— IEC 62366:2007, Medical devices — Application of usability engineering to medical devices, which addresses human factors design processes, and
— ANSI/AAMI HE75.2009, Human factors engineering — Design of medical devices, which focuses on human factors design principles.
The principles outlined in medical device standards are equally relevant to health software, emphasizing the importance of user involvement from the design's inception to promote a user-centered design (UCD) approach Designers must integrate user characteristics, capabilities, and preferences into their designs, as highlighted in HE75, which provides essential guidelines for ensuring health software is both efficient and safe Additionally, managing the risk of use error is crucial, with HE75 presenting a risk management process that aligns with human factors frameworks Designers should also adhere to human factor guidelines that encompass design principles, environmental considerations, and accessibility to create systems that are well-suited for users Finally, following usability engineering processes and adopting an iterative design approach allows for continuous testing and validation against end-user feedback, facilitating the mitigation of risks and enhancing safety in health software.
Emerging literature, including works by Vicente and Staggers, highlights frameworks and models that focus on human factors, usability, and enhancing user experience within healthcare organizations.
Granularity
In health software safety standards, granularity refers to the complexity level at which a system is divided into smaller components In software development, it is essential to clearly define the expected behavior of critical parts, allowing for precise code implementation This encompasses everything from individual software elements, like a systolic blood pressure data value, to comprehensive solutions deployed across an entire jurisdiction.
IEC 62304 outlines a structured approach to software granularity during the development phase, categorizing it into three levels: system, item, and unit This Technical Report evaluates the relevance of the standard to safety in health software, incorporating illustrative examples to demonstrate the application of these three levels of granularity.
— Components: the unit level of health software that includes data, objects or other entities configured and usable within or by a computer program,
NOTE 1 This includes item and unit development (see IEC 62304:2006).
— Application: a computer program or series of computer programs that serve an identifiable and specific business purpose In health software, applications serve an identifiable and specific health business purpose, and
NOTE 2 This includes system development (see IEC 62304:2006).
— Enterprise Application: an entity or organization comprising people, processes, information and technology that uses an application or series of applications to support the business of the entire enterprise.
Standards assessment
To evaluate a standard that enhances safety in health software, it is essential to address several key questions: First, does the standard contribute to improving patient safety during the development, implementation, or operation of health software by mitigating risks? Second, what level of detail does the standard pertain to within health software? Lastly, at which stages of the health software lifecycle is the standard applicable?
In answering these questions, the following standards-related information is used:
— the standard’s identification number, publication date (or development status if not yet published) and title,
— risk applicability or acceptability (also noting controls),
— evidence of the standard’s use (if available),
— software lifecycle coverage and software granularity coverage, and
— the relationship of the standard to other standards.
The assessment and mapping of standards are effectively structured using a two-dimensional matrix that incorporates granularity and lifecycle steps This matrix, illustrated in Figure 1, highlights key elements and identifies transition points where risk is collectively managed by various stakeholders.
Design Development Implementation Operation Decommission
Developer Ow ner/Implemente r Ow ner/Implemente r Ow ner/Operator/Use r
Developer / Ow ner/Implementer Ow ner/Operator/User
The health software lifecycle consists of a series of linear steps, as illustrated in the figure, but it also encompasses a complex mix of linear and iterative actions that ensure ongoing software management by all stakeholders Maintenance, for instance, involves iterative processes that highlight shared risks at various stages.
Figure 1 — Risk shared by multiple parties during the health software life cycle
The initial five assessments offer essential guidance on foundation standards, serving as a broad framework for health software standards These foundational standards are crucial for managing health software risk and safety, providing best practices applicable to both general and health-specific software They contribute to a unified perspective on standards that ensure the patient-safe development, implementation, and utilization of health software The subsequent five series are categorized as either "organizational" or "ICT domain wide."
“enterprise risk or safety generic” in scope and their use should be taken from those specific perspectives.
The assessment following the foundation series (see Clause 5.1.6 and on) are specific standards that apply to patient-safe development, implementation and use of health software.
The ISO quality management standards are concerned with quality management systems and are designed to help organizations ensure they meet the needs of their customers Standards include:
— ISO 9000:2005, Quality management systems — Fundamentals and vocabulary,
— ISO 9001:2008, Quality management systems — Requirements,
— ISO 10005:2005, Quality management systems — Guidelines for quality plans,
— ISO 10006:2003, Quality management systems – Guidelines for quality management in projects, and
— ISO 10007:2003, Quality management systems – Guidelines for configuration management.
ISO/IEC TR 90003 is a fundamental standard that provides guidelines for applying ISO 9001:2000 to software life cycle processes Currently under development by JTC 1/SC 7, it aims to replace the existing ISO/IEC 90003:2004 standard, which focuses on software engineering and quality management systems, with a new version expected to be released in early 2013.
ISO 9001 serves as the essential standard for establishing and maintaining a quality management system, even though it is not specifically designed for health software safety By following the quality processes and practices outlined in an organization’s quality management system, businesses can ensure the delivery of products and services that fulfill customer needs and comply with relevant statutory and regulatory requirements.
These standards are widely deployed and used across all industry sectors.
Not applicable to lifecycle of software or granularity of software.
ISO 13485:2003 is the medical device industry’s equivalent of ISO 9001:2008 and was created from
9001 to allow it to be used for regulatory purposes.
5.1.2 Software and systems engineering standards
ISO/IEC JTC 1 Information Technology develops and maintains standards across a broad range of ICT domains, working through 19 fully constituted SCs (each with many respective Working Groups) and
ISO/IEC JTC 1 oversees more than 2,500 published standards through its subcommittees and working groups, including two working groups that report directly to it Among these, JTC 1/SC 7 focuses on software and systems engineering, playing a crucial role in ensuring the safety of health software across various applications.
ISO plays a crucial role in developing standards by coordinating a collaborative process among independent technical experts from various sectors These experts draft standards based on market needs, which are then refined through a consensus-driven voting process The development of an ISO standard typically spans about three years, involving continuous input from stakeholders, including industry representatives and consumer groups Participation in this process allows individuals and businesses to influence standards that impact their sectors, ensuring that the standards meet real-world requirements and contribute to global initiatives like the UN Sustainable Development Goals.
Software safety originates from effectively managing the entire software life cycle within a governance and compliance framework that ensures quality and assurance Key standards from JTC 1 play a crucial role in this process.
5.1.2.2.1 ISO/IEC 12207 Systems and software engineering - Software life cycle processes
The International Standard, along with ISO/IEC 15288 on system life cycle processes, is detailed in the three Technical Reports of ISO/IEC 24748, focusing on systems and software engineering life cycle management.
— Part 1: Guide for life cycle management,
— Part 2: Guide to the application of ISO/IEC 15288 (previously ISO/IEC TR 19760), and
— Part 3: Guide to the application of ISO/IEC 12207 (previously ISO/IEC TR 15271)
Part 4 of ISO/IEC 24748 is currently being developed and will ultimately supersede ISO/IEC 26702:2007, which addresses the application and management of the systems engineering process, with a particular focus on health and safety considerations within the systems engineering framework.
5.1.2.2.2 ISO/IEC 15504 Information technology - Process assessment
Software and systems safety is taken a step further in this multi-part standard which includes International Standards, Technical Specifications and Technical Reports, including the following:
— Part 3: Guidance on performing an assessment,
— Part 4: Guidance on use for process improvement and process capability determination,
— Part 5: An exemplar software life cycle process assessment model,
— Part 6: An exemplar system life cycle process assessment model,
— Part 7: Assessment of organizational maturity,
— Part 8: An exemplar process assessment model for IT service management,
— Part 9: Target process profiles, and
5.1.2.2.3 ISO/IEC 15026 Systems and software engineering - Systems and software assurance
ISO/IEC 15026 outlines approaches to ensure the risk and integrity of software products as engineering artifacts, originating from IEEE and focusing on an assurance case aimed at a "safety case." This standard encompasses essential guidelines for software assurance.
— Part 3: System integrity levels, and
— Part 4: Assurance in the lifecycle
5.1.2.2.4 ISO/IEC 20000 Information technology – Service management
ISO/IEC 20000 addresses the information technology service management domain and provides an organizational equivalent to the ITIL certification It includes the following key parts:
— Part 1: Service management system requirements,
— Part 2: Guidance on the application of service management systems,
— Part 3: Guidance on scope definition and applicability of ISO/IEC 20000-1,
— Part 5: Exemplar implementation plan for ISO/IEC 20000-1,
— Part 7: Application of ISO/IEC 20000-1 to the cloud (In progress),
— Part 10: Concepts and terminology for ISO/IEC 20000-1 (In progress),
— Part 11: Guidance on the relationship between ISO/IEC 20000-1 and related frameworks (In progress)
NOTE ISO/IEC TR 20000-11 gives guidance on the relationship between ISO/IEC 20000-1 and ITIL.
5.1.2.2.5 ISO/IEC 25000 Software engineering – Software product quality requirements and evaluation
ISO/IEC 25000:2005 addresses the “SQuaRE” process Other key standards and specifications that relate to ISO/IEC 25000 include:
— ISO/IEC 25001:2007 Software engineering – Software product quality requirements and evaluation -
— ISO/IEC 25010:2011 Software engineering – Software product quality requirements and evaluation - System and software quality models,
— ISO/IEC 25012:2008 Software engineering – Software product quality requirements and evaluation - Data quality model,
— ISO/IEC 25020:2007 Software engineering – Software product quality requirements and evaluation - Measurement reference model and guide,
— ISO/IEC 25021:2012 Software engineering – Software product quality requirements and evaluation - Quality measure elements,
— ISO/IEC 25040:2011 Software engineering – Software product quality requirements and evaluation - Evaluation process (revision of ISO/IEC 14598-1:2009), and
— ISO/IEC 25045:2010 Software engineering – Software product quality requirements and evaluation - Evaluation module for recoverability
ISO/IEC 25010, which supersedes ISO/IEC 9126, offers a comprehensive framework for assessing and evaluating the quality of software and system products While it provides a generic methodology for quality assessment, it does not directly address risk assessment This standard is applicable to all software products and can help identify risks through defined metrics It is particularly relevant in health software safety, focusing on 'quality in use' measures such as effectiveness, efficiency, satisfaction, safety, and usability ISO/IEC 25010 establishes both broad and specific evaluation parameters, creating a consistent terminology for measuring and evaluating software quality Additionally, it includes a set of quality characteristics that allow for the comparison of stated quality requirements to ensure completeness.
These standards are widely deployed and used across all industry sectors.
The JTC 1/SC 7 standards focus on software, particularly in relation to components and applications, with varying relevance to enterprise applications They provide comprehensive guidance on the design and development phases, while offering variable insights into implementation and operational aspects.
The JTC 1/SC 7 standards mentioned here focus on software within the broader ICT domain, encompassing essential processes, risk management, and safety requirements, even though they do not specifically target health software For additional details on the key JTC 1/SC 7 standards, please refer to ANNEX C.