Skip to main content
Operational clinical safety process - Dean Mawson

Clinical safety workshop


Summary

1. Prerequisites

The following prerequisites must be completed prior to the first clinical safety workshop taking place. Without any of these a thorough risk assessment and review cannot be conducted:

  1. Delivery of health IT system into the health organisation.
  2. Training – comprising of an overview supported by documentation that allows the key stakeholders to make an informed decision on the functional and technical features of the system and their impact and interaction with the workflow process.
  3. Completion of ‘To Be’ processes in line with the change management requirements for the project which the health IT system will support.
  4. Standard operating procedures in support of the completed ‘To Be’ processes.
     

2. Objectives

The purpose of the clinical safety workshop is to bring together all the relevant parties who represent a broad spectrum of roles across the health organisation. These persons should be able to give an unbiased opinion when risk assessing using their knowledge of the workflow processes.

3. Representation

There should be an initial workshop that includes representation from the health organisation and the supplier’s clinical safety teams including clinical safety officers, workstream leads and clinical/administrative representation from the business with relevant experience.

4. Initial workshop

The workshops are designed to:

  • support the clinical risk assessment process to prevent unintentional bias when risk assessing
  • introduce a broader opinion using a multidisciplinary approach

Appropriate risk assessment tools should be used making sure that all representatives have a chance to be involved in risk rating and form discussion being mindful of limiting the time spent on each issue to a maximum agreed by the chair. In the past external subject matter experts have been invited from other health organisations in an advisory capacity and to help mediate if there are contentious issues - their experience can make all the difference. NHS Digital may want to be invited as well, depending on the project.

5. Subsequent workshops

The number of subsequent workshops required will depend on the:

  • size of the project
  • amount of development
  • number of modules being delivered

These workshops will follow the same format as the initial workshop. A project will always have two workshops as a minimum to risk assess the initial then the residual risk rating, once mitigation has been put into place.

6. Clinical safety process outputs

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

Updated hazard log

Whilst the hazard log is a living document and continues to be updated during the lifecycle of the health IT system, a base-lined version is to be issued with each clinical safety case report.

Each version of the hazard log has to be reviewed and approved by the clinical safety officer to signify that the clinical safety information recorded is accurate and appropriate.

Safety case report

The clinical safety case report is the physical document that summarises all the key elements of the clinical safety case and references all supporting material in a clear, comprehensible and concise format. It serves to communicate the clinical safety case to the end users and top management but also where appropriate to other bodies such as regulators.

As the underlying clinical safety case continues to evolve during the health IT system lifecycle, then there is a need to issue clinical safety case reports in support of key milestones. The issuing of clinical safety case reports will be dictated by the health IT system development lifecycle being followed as defined in the clinical risk management plan.

A safety case report needs to be produced for the first release of software. Any subsequent release should be accompanied by an updated version of the safety case report to reflect:

  • evidence of test results for the release 
  • evidence of a test report for the release 
  • an updated hazard log reflecting the risk assessment completed for the release, if there are no system related risks identified then this needs to be documented 
  • a summary of the risk ratings identified through the risk assessment process for the release represented by a table detailing the risk rating and the relevant modules risk assessed 
  • detailed information regarding those risks with a rating of 3 or higher and the additional controls and actions recorded

It may be the case that any release does not have any safety related incidents or issues that have been identified. Therefore an issued statement to this affect is satisfactory.

Last edited: 20 November 2018 2:58 pm