ISO/TS 25238:2007 — Health Informatics Classification of Safety Risks from Health Software

Patient Safety in the Age of Digital Health

As healthcare becomes increasingly digitized, software failures pose a growing threat to patient safety. From electronic prescribing systems that can cause medication errors to clinical decision support tools whose logic may be flawed, the potential for harm is real and documented. ISO/TS 25238:2007 addresses this challenge by providing a systematic framework for classifying health software products according to the level of risk they present to patients — enabling regulators, manufacturers, and healthcare providers to apply proportionate controls that match the actual danger. The framework is designed to be accessible to non-specialists while remaining rigorous enough for regulatory applications, filling an important gap between general risk management standards and the specific needs of health software.

The standard's core insight is simple but powerful: a hospital appointment scheduling system poses negligible patient risk, while a ventilator-control decision support system could kill. The controls applied to each should be fundamentally different — and ISO/TS 25238 provides the methodology to make that distinction objectively.

The Five-Class Risk Framework

Understanding Consequence and Likelihood

Risk, as defined in the standard, has two dimensions: the severity of potential harm to a patient (consequence) and the probability that such harm will actually occur (likelihood). Five consequence categories range from minor inconvenience (Category E) through temporary injury, permanent impairment, life-threatening situations, to multiple deaths or severe public health impact (Category A). Five likelihood categories range from almost certain (Category 1) to almost impossible (Category 5). These two dimensions are combined in a 5×5 risk matrix to produce five risk classes.

The standard emphasizes that this classification is intended for broad screening of generic product types, not for detailed design risk analysis. The goal is to enable regulators and procurement organizations to quickly determine what level of design and production control is appropriate for a given class of health software. Products falling into higher risk classes warrant more rigorous development processes, independent verification, and possibly regulatory oversight, while lower-risk products can follow streamlined quality assurance procedures.

Risk Class	Example Health Software Products	Implied Control Level
Class I (Lowest)	Staff shift scheduling, generic research databases	Basic software quality assurance
Class II	Hospital patient administration systems	Structured design and testing
Class III	Electronic health records, laboratory information systems	Formal risk management process
Class IV	Clinical decision support, drug interaction alerts	Rigorous verification and validation
Class V (Highest)	Ventilator management, radiotherapy planning systems	Full IEC 61508 or equivalent SIL compliance

The classification is not static: a product’s risk class may change as it evolves, as new use cases emerge, or as clinical evidence reveals previously unrecognized hazards. The standard mandates an iterative review process.

The Analytical Process

Step-by-Step Risk Classification

The standard outlines an eight-step analytical process: (1) identify relevant stakeholders; (2) understand the system and its user environment; (3) identify potential hazards — situations where the software could contribute to patient harm; (4) analyse the consequences of each hazard; (5) estimate the likelihood of harm occurring in reasonably foreseeable circumstances; (6) assign a risk class using the risk matrix; (7) iterate to refine understanding; and (8) document all assumptions, analyses, and conclusions. An incident library should be maintained to capture real-world safety events and feed back into the risk analysis process.

Practical Examples

Annex B of the standard provides detailed worked examples covering four diverse health software products: a patient call/recall system for cancer screening, a hospital clinical laboratory system, a drug prescription support system, and an intensive care unit decision support system. These examples demonstrate how the same structured methodology yields appropriately differentiated risk classifications for very different products — from Class II for the recall system to Class V for the ICU decision support system.

The worked examples are arguably the most valuable part of the standard for practitioners. They bridge the gap between abstract risk theory and practical application, showing exactly how to apply the consequence and likelihood categories to real-world health software.

Relationship to Design and Production Controls

The standard is explicitly positioned as a precursor to design and production controls, not a replacement for them. Once a risk class is assigned, it guides decisions about what level of rigour is appropriate for the software’s development lifecycle — from basic software quality assurance for Class I products to the full functional safety framework of IEC 61508 for Class V products. This risk-proportionate approach prevents both under-engineering (dangerous products) and over-engineering (wasted resources on low-risk products).

The standard specifically excludes software necessary for the proper application or functioning of a medical device, which is already covered by medical device regulations in most jurisdictions. The gap it fills is for the vast and growing category of standalone health software that falls outside traditional medical device frameworks.

Frequently Asked Questions

Q: What types of health software are covered by ISO/TS 25238?
A: The standard covers any health software product used for health-related purposes, including commercial products, open-source software, and custom-built systems for single organizations. It excludes software that is necessary for the proper application or functioning of a medical device.

Q: How many risk classes does the standard define?
A: Five risk classes, ranging from Class I (lowest risk) to Class V (highest risk). The class is determined by combining consequence and likelihood assessments in a structured 5×5 risk matrix.

Q: Is ISO/TS 25238 intended for the detailed risk management of software design?
A: No. The standard is intended for broad screening and assignment of health software to risk classes, which then serves as a precursor for more detailed risk management activities. Detailed risk analysis and mitigation during design should follow established standards such as ISO 14971 or IEC 61508 as appropriate.

Q: Why does the standard use qualitative likelihood instead of quantitative probability?
A: Because for health software products, historical failure statistics and incident data are typically not available. Qualitative judgement by informed stakeholders is the most practical approach, and the standard provides structured categories to make such judgements as consistent and defensible as possible.