The use of phased safety cases in other domains

Both of the emerging Health Informatics standards for Clinical Risk Management, TS 29321 and TR 29322, include the concept of staged safety case reports. Whilst some in the industry may see the production of so many documents as an issue, this doesn't concern me specifically because documentation for successive phases can simply be added as an appendix to previous documentation. However, I do see two areas where additional guidance is necessary:

• no guidance is provided about how each of the stages relate to each other
• in particular what information might flow from one safety case to another.

This additional information would be particularly useful when different contractual parties are involved in the supply chain. Including this information in a future issue of the standard will enable parties to enter into contracts and agreements on the basis of the Standard and they should not have to negotiate these aspects separately unless there are good reasons for doing things in a different way.

The following illustrates the generic approach. I envisage developing this further to meet the specific characteristics of heavily configured COTS as used in health care.

1. Concept / requirements Safety Case Report. Produced when the role and broad functionality of the new system is determined. This document identifies the safety objectives of the system and its applicable system safety requirements which are based on regulatory requirements and the service provider’s internal safety standards as appropriate;
2. Design Safety Case Report. Produced once the system has been designed and developed to meet the specified operational and/or engineering requirements. This document describes the system configuration identified safety requirements for the installation and commissioning and operational phases and describes how the safety objectives and requirements have been met within the evolving design. A full hazard and risk assessment is usually included at this stage;
3. Installation and pre-commissioning Safety Case Report. Produced when the system is undergoing procedural and/or engineering readiness testing against the design specifications, followed by operational trials. At this phase, the risk assessment is tested and validated by actual trials and testing of the installed system, and specific safety related operational, engineering and/or management procedures are developed to obviate or control the identified risks; and
4. Commissioning and routine operations Safety Case Report. Produce prior to release to service. Demonstrates how the safety of the system will continue to be monitored and improved as any hazards are identified as they arise, and how risks are mitigated during actual operations.

ISO/TS 25238 - Health Informatics - Classification of Safety Risks from Health Software

Whilst the controls that are justified for a high level of risk may also be suitable for lower levels of risk, their application for lower levels of risk may not justified when other considerations are taken into account.

ISO/TS 25238 provides a framework for grouping health software products in a set of classes or types according to the risk that they may present. This provides a mechanism for screening individual products to allow different levels of rigour in the application of design and production controls that are broadly matched to risk.

The approach advocated in this TS is in effect a Preliminary Hazard Assessment with the output, effectively a Safety Integrity Level (SIL), linked to a set of recomended controls defined by the organisation undertaking the Assessment. The categorisation of risk is done using a 2 dimensional risk matrix but importantly the likelihood is defined such that it does not take account of the effect of any controls within the product. In essence the approach is as follows:

1. First identify some foreseeable hazards that a health software product might present to a patient if it were to malfunction or to be the cause of an adverse event.
2. Then assign a Consequence category using a predefined table of qualitative categories and descriptions.
3. Then assign a Likelihood category using a predefined table of values. This is estimated based on the likelihood of the occurrence of the identified Consequence without taking account of any mitigation expected from the product itself; however, expected mitigation from the environment should be included.

The output of the risk matrix is a set of classes to which appropriate process and product based controls can be applied.

The Lifecycle of Health Software

I have some observations about the life-cycle of Health Software as modeled in TR29322. Here is Section 4.4 in its entirety. I will comment separately:

The life cycle of a health software system typically comprises:
a) concept development and requirements capture;
b) detailed design;
c) software development;
d) software verification;
e) software release/marketing;
f) system validation and deployment;
g) use;
h) decommissioning.
ISO/TS 29321 applies to all life-cycle stages in which the manufacturer is responsible; typically, these will typically be a) to c) although, depending on the contract, the customer may be involved in concept definition/design. This Technical Report applies to all those life-cycle stages for which the customer/health organization is responsible, which will normally at least include deployment, use and decommissioning, although an out-sourcing contract may place that in the hands of the manufacturer.

However “deployment” can be in the hands of the manufacturer, the health organization or both. The manufacturer is likely, for example, to be heavily involved with the first deployment of a health software product as part of a health organization system. The standard which will apply to deployment will depend primarily on which body is responsible for ensuring patient safety. Where the manufacturer and the health organization work together on deployment and perhaps share responsibility for risk analysis etc., the manufacturer may work to ISO/TS 29321 (and thereby use the experience to build on the manufacturer clinical safety case) and the health organization may work to this Technical Report (using the experience to build the organization's clinical safety case and draw on the manufacturer's deployment clinical safety case report).
Since the hand-over from implementation in the user environment to live use will often involve the manufacturer/supplier and the user, a formal user acceptance protocol should be agreed upon and documented and include:

• a procedural work-through with users;
• and a dress rehearsal.

Whereas defining responsibilities for the purpose of determining which standard applies is important, the fact that the processes in ISO/TS 29321 and this Technical Report are the same makes the boundary less important.

Safety Cases - A historical overview

I have just come across this paper by Peter Wilkinson which provides a review of the historical background to the development of safety cases as a tool to manage and regulate major hazard industries, primarily in the UK. This paper describes a number of applications where Safety Cases have been used and considers some successes and failures in their application.

Safety Standards in Health Informatics - Interest Group

Earlier today I attended the second meeting of an interest group that has been formed under the auspices of Intellect to review two emerging Health Informatics Standards related to Clinical Risk Management ISO/TS 29321 and ISO/TR 29322. Both of these Standards are based on Safety Case principles - a concept that is relatively new in healthcare.

Health IT Risks - Background

Risk management is at the heart of many practices within medicine and healthcare. It is clearly in every patients' interest for clinicians to hold the principles of the Hippocratic Oath so close to their hearts. With the emergence of more and more specialist disciplines and the continual drive for improvements, care is increasingly being delivered by multidisciplinary teams. However, multidisciplinary team working introduces huge challenges for communication and sharing of information.

Information Technology(IT) offers tremendous opportunities for joining up disparate business processes. There is also a perception that the introduction of computer systems will inevitably improve safety in many areas of clinical practice. Information technology certainly has huge potential to improve the consistency of the healthcare experience and the quality of clinical record keeping. However, we need to be careful because the interactions within healthcare are complex and there are numerous ways in which the clinical business processes can fail in ways that could cause harm to patients.

For many the most obvious pitfalls are those relating to Information Governance and privacy in particular. The Health Insurance Portability and Accountability Act (HIPPA) in the US and Data Protection Act(DPA) legislation in Europe has established statutory requirements that need to be met to address these risks. However, this legislation and associated standards do not properly address the risks of harm to patients arising from anomalous behaviour within information system.

Examples of anomalous behaviour that could lead to harm include:

• Incorrect output from clinical decision support functionality
• Failure to record details of an allergy correctly
• Failure to reliably transfer or refer the care of a patient to another provider

Since these scenarios have the potential to increase the risk of harm to patients they are described as Clinical Hazards. The practice of identifying, risk assessing and mitigating Clinical Hazards is termed Clinical Risk Management.

Background

I have implemented of Safety Management Systems and developed Safety Cases in both Aviation and Healthcare. This Blog is a repository of links to published papers that I have found relevant or interesting and a platform from which to share my experience of Clinical Risk Management with others engaged in this area of work.

James Savage Msc BSc RAF (Retd)