Skip to main content
Creating a new NHS England: Health Education England, NHS Digital and NHS England have merged. More about the merger.

Part of Operational clinical safety process - Dean Mawson

Clinical safety process initiation meeting

Current Chapter

Current chapter – Clinical safety process initiation meeting


This meeting is to present the Clinical Safety Management System (CSMS) to the project and to discuss the project specific clinical safety requirements. This will also incorporate a clinical safety presentation which gives an overview of the process and examples of safety incidents and their management. There should be representation from the health organisation and the supplier’s clinical safety teams including clinical safety officers (CSOs), subject matter experts and any other relevant project personnel.

1. Review the supplier's clinical safety management system and sign off

  1. Description of the manufacturer’s clinical risk management system
  2. Identification of key personnel, their roles and responsibilities
  3. Identification of clinical risk management governance structure

This document should be reviewed in detail and there will be agreement that its content will form the basis for the management of clinical safety throughout the lifecycle of the project.

2. Clinical safety presentation – set the scene

This will be given by the operational CSO and should be updated to meet with current standards and include relevant information regarding the current standards and the roles/responsibilities therein.

3. Clinical safety – expectations and activity schedule

As part of the process there should be agreement on the clinical safety activities that will take place, the content of the activities as described in this document and how often they should take place. This should consider the project size including deliverables, resourcing, testing, data migration and development cycle. The expectations from the clinical safety management should be clearly set by both the suppliers and the health organisation so that there is no ambiguity.

4. Clinical safety process outputs

Expected outputs at this stage of the clinical safety process which will be reflected in the risk management file.

Clinical risk management file

The purpose of the clinical risk management file is to provide a physical or logical repository of all records and documents that are produced by the clinical risk management process and required as stated in the suppliers CSMS and DCB0129. If the documents are referenced from the clinical risk management file, then they must be capable of being retrieved.

Hazard log

This is maintained for the functionality that is being delivered to the health organisation. This should include any hazards that have been identified as part of the development cycle and those that have been identified by the customer and are system related in the pre go-live phase. A baseline hazard log is produced at the commencement of the project and is subsequently maintained throughout the project lifecycle. It is the responsibility of the CSO to make sure the hazard log is reviewed and updated as required.

Such on-going revisions will: 

  • incorporate new hazards, when identified 
  • record the mitigation of defined hazards through the implementation of clinical risk control mechanisms whether through design, testing, training or business process change
  • reference supporting evidence where available
  • record the status of actions

Clinical risk management plan

A clinical risk management plan will be produced at the commencement of each project which gives the risk management approach for that project relating to the delivered functionality. This plan must be updated if key personnel or the nature of the project changes during the development or modification of the health IT system. This plan will be maintained throughout the life of the health IT system. 

Safety case

The clinical safety case is a structured argument which is supported by a body of relevant evidence that provides a compelling, comprehensible and valid case that a system is safe for release. The argument provides an explanation of how the supporting evidence can be interpreted as indicating that the health IT system exhibits an adequate degree of safety, such as by demonstrating compliance with requirements or sufficient mitigation of identified hazards. During the initial stages of the project the safety case is not expected to provide mitigation or residual risk rating but will give evidence of existing controls and initial risk ratings.

Last edited: 20 November 2018 2:36 pm