Contents
1 Introduction
This clinical risk management system (CRMS) outlines the processes to be followed to ensure that all healthcare IT used to support care within the organisation is developed, implemented, and used in a safe manner.
This CRMS provides a framework that promotes the effective risk management, by the organisation, of potential health IT hazards and operational incidents.
This CRMS compliments existing risk management processes that should be defined in the organisation’s risk management framework and wherever practical, uses existing procedures, processes and governance arrangements. This CRMS addresses the requirements of DCB0129 (opens in new window) and DCB0160 (opens in new window) and follows best practice as promoted by NHS England.
The trust has also embedded clinical decision support (opens in new window) (CDS) requirements into its CRMS process ensuring CDS is considered and assessed, where appropriate, in the development of clinical safety cases.
This CRMS will be reviewed and maintained in accordance with the organisation’s Digital Transformation Group (DTG).
2 Purpose
The aim of the CRMS is to ensure that all the organisational staff involved with the development, implementation and use of healthcare IT systems are aware of the activities that are required to be undertaken to ensure patient safety is improved rather than compromised from the introduction of healthcare IT systems.
The organisation is required to adhere to national information standards created and monitored via the Data Alliance Partnership board within NHS information standards frameworks.
The mechanisms used are approved process clinical risk management system compliance documents.
This clinical risk management system will be reviewed periodically to ensure that:
- changes in working practices are incorporated
- issues identified though an established internal audit programme are addressed
- the safety approach continues to adhere to the requirements of applicable international standards
- the system continues to protect the safety of patients in a complex and changing environment
3 Scope
This applies to the organisation and to all subsequent updates or upgrades to systems. The policy also applies to any local customisations or specific configurations made to a healthcare IT system by the organisation.
The trust will undertake the initial clinical risk management process for legacy systems at the point of renewal.
If clarification is required of whether any system falls within scope of this CRMS this should be raised with the nominated clinical safety officer (CSO) for clarification. This nominated person provides clinical and organisational leadership on healthcare IT patient safety on behalf of the organisation.
4 Responsibilities, accountabilities and duties
4.1 Clinical risk management system team organisation
The organisation chart provides the overview of resources and personnel involved in clinical risk management for the organisation.
- Director of health informatics.
- Head of information quality (CSO).
- Information quality manager (CSO).
- Information quality support officer.
The following provide a support function to the process with their contributions in line with the descriptions below:
- nursing and facilities
- patient safety
- corporate assurance
- Business Continuity and Emergency Preparedness, Resilience and Response (EPPR) team
4.1.1 Chief Executive or director of health informatics
- Must make available sufficient resources.
- Assign competent personnel from each of the specialist areas that are involved in deploying and subsequently using the health IT system.
- Nominate a clinical safety officer.
- Authorise the deployment of the health IT system (undertaken at information governance) accepting any residual clinical risk on behalf of the organisation.
4.1.2 Nursing and facilities
- Contribute to clinical safety cases where appropriate.
4.1.3 Patient safety
- Contribute to clinical safety cases where appropriate.
- Ensure all clinical safety related incidents are shared with CSO’s.
4.1.4 Business continuity and emergency preparedness, resilience and response (EPPR)
- Contribute to clinical safety cases via hazard workshops.
- Work with services to ensure that any new technology is reflected in business continuity plans where appropriate.
4.1.5 Corporate assurance
- Each clinical safety case which has an active hazard log will be captured in the trust risk register and managed with appropriate controls. Digital clinical safety risks will be reported to the trusts quality committee for oversight.
- Clinical safety cases will be approved at the information governance group.
4.2 Governance
Governance for patient safety within the organisation is provided through the quality committee and clinical leadership executive (CLE) and the appropriate sub committees and groups.
5 Procedure and implementation
5.1 Healthcare IT clinical risk management activities
5.1.1 Hazard identification
The organisation will conduct hazard identification workshops to identify potential hazards associated with the deployment and use of a healthcare IT system. The CSO will be responsible for facilitating such workshops and ensuring attendance from appropriate representatives. Typically, representatives from the following domains will be required:
- operational services
- health informatics (for example, information technology services, information governance, information management and business intelligence)
The workshops will have minutes taken, and a copy stored in the clinical risk management file. If a healthcare IT solution is deemed not to be safety related then this decision will be formally recorded and the CSO will notify the responsible director and programme lead via email.
Where any third party components are used to support the healthcare IT system then they will be considered in the scope of the hazard identification activities and subsequent risk assessment. Where none are used a positive declaration to this effect will be recorded in the minutes.
All identified hazards will be recorded in the hazard log.
5.1.2 Risk assessment
The organisation will conduct healthcare IT system risk assessment in accordance with the risk management framework.
The hazard log will be updated by the CSO to capture the risk assessment.
5.1.3 Risk evaluation
The organisation will conduct healthcare IT system risk evaluation in accordance with the risk management framework.
The hazard log will be updated to capture the risk evaluation.
5.1.4 Risk control
Where the initial risk evaluation is deemed unacceptable, further risk controls will be required. The organisation will manage healthcare IT system risk in accordance with the risk management framework.
All clinical safety cases with identified risks will be added to the corporate risk register. Each risk will be reviewed annually as a minimum.
Details of the risk control measure and evidence of effective implementation will be captured in the hazard log.
5.1.5 Deployment and ongoing maintenance
To support clinical safety activities undertaken during any deployment phases of a project or programme of work the following documentation will be required to form a part of the overall approval process:
- policies
- guides
- project plans
- decision papers
Note, this includes change management and release configuration.
5.1.6 Incident management
Clinical risk management activities within the organisation and the healthcare IT programmes and services offered are completed within the corporate incident management policy.
As such, clinical safety related incidents are dealt with in a similar manner as other incidents within the organisation such as financial, reputational, technical, and other service impacting categories.
5.2 Clinical safety competence and training
5.2.1 Overview
The clinical safety activities described in this clinical risk management system shall be undertaken by competent staff. Suitable training shall be undertaken by staff to maintain and expand their level of competence.
5.2.2 Competency
All staff identified in the organisation chart, shall be sufficiently competent for the roles and task which they are asked to undertake. Where an individual does not have sufficient experience or knowledge then that person shall be monitored, and their work reviewed, by someone who has the necessary competence.
Such supervision shall prevail until it is judged that the individual has amassed the necessary experience to undertake such tasks unsupervised.
In assessing competency, the different functional roles required to fully discharge the obligations of the clinical risk management system, and the necessary skills and knowledge needed for each, shall be considered.
Primary functional roles may include:
- conducting discrete safety analyses (for example, a HAZOP or FFA) or defining the hazard risk indicators for a particular project
- making a valid judgement on the safety tasks, activities and techniques required for a given health software product to justify the comprehensiveness and completeness of the safety assessment and produce the safety argument with supporting evidence
- assurance of safety assessments and healthcare IT software products. Performance of safety techniques and development of the safety argument for a particular healthcare IT software product must be independent to any assurance activities for the same
- improving and refining the overall clinical risk management system, for example, audit, process change, quality
- ownership and leadership, for example, ultimate safety accountability, culture change, influencing and strategic direction
The first test in establishing competency shall be at the interview stage where potential staff shall be assessed against the above representative roles and agreed job descriptions.
Staff should refer to the appointment of staff policy for further guidance.
Thereafter, competence shall be monitored through the organisation’s established appraisal scheme. Any perceived deficiencies identified during the work or at the appraised stage, especially during probation, shall be addressed immediately, for example, through the assignment of a competent supervisor or the provision of suitable training.
All registered CSO’s will, as a minimum, have completed an accredited training course.
5.3 Clinical decision support
Clinical decision support (CDS) systems support digital and clinical leaders to improve clinical safety and design problem-orientated solutions that achieve intended benefits. It suggests key actions that digital and clinical leaders should take as a part of their digital transformation plans, including developing multidisciplinary teams, engaging the workforce and avoiding unintended consequences.
This helps to build the safety case for the product, which needs to be signed off by a clinical safety officer, and a framework for CDS governance.
Some CDS systems may also be classed as medical devices and must satisfy the medical device regulations set out by the medicines and healthcare products regulatory agency (MHRA). These should be considered early, and expert advice sought to navigate this process as necessary.
CDS should be meaningfully embedded within an organisation’s clinical governance system. Clinical governance entails ensuring that recommendations, thresholds, and algorithmic guidance are updated with consideration of performance data, outcome measures and change in evidence base, and are in line with local guidelines and national best practices. Operational governance includes ensuring that the systems, applications, and databases that power the CDS system are updated in accordance with the latest standards. This should be clinically owned, with the involvement of senior stakeholders.
The 5 right’s for a CDS system to effectively support clinical decision-making are:
- right information, evidence or guideline based CDS that incorporates stakeholder inputs and aligns with current improvement initiatives
- right person, CDS must meet the specific needs of everyone in the multidisciplinary clinical team, users should be aware of the purpose and limitations of the CDS, and how to report issues with its advice
- right format, CDS formats must present information to clinicians in a manner that complements workflows; for example, best practice alert, visual dashboard, smart order set, customised referral. Those writing CDS advice should be aware of good practice in risk communication (for example, use 1 in 100 rather than 1% risk) and avoid interrupting clinical tasks unless there is an immediate risk of serious error
- right channel, user experience needs to be considered. CDS should focus on the context of use, to ensure presented information does not disrupt workflows, where possible and appropriate, it should be integrated within the primary EHR system
- right time, CDS must be integrated and seamless within the clinical workflow, CDS should operate across different care settings
Furthermore, effective design and implementation of CDS systems is illustrated by the 6i model.
- intelligent, CDS systems need to be evidence based and address real-world clinical decisions that would benefit from best practice support. Self-generated data can be used to guide iterative improvement
- interpretable, CDS systems need to consider the healthcare professional’s knowledge of the topic, use clear and unambiguous content, and demonstrate validity and reliability of recommendations by linking to relevant explanations or evidence
- integrated, CDS systems need to be designed to complement workflows, integration with clinical systems can increase impact by embedding decision support in clinical workflows
- impactful, CDS systems need to consider the experience of users, improve productivity and outcomes, and be clinically safe with mitigations made to reduce potential risks
- interoperable, CDS systems need to interpret clinical data from systems to minimise manual data entry and present result data within relevant clinical systems by using open application programming interfaces (API) whenever possible. Where a relevant computable knowledge library is available, the CDS system should be configured to import high quality knowledge objects coded using global knowledge standards (Wyatt and Scott, 2020)
- inclusive, CDS systems need to consider a broad range of end users, be based on trusted clinical data that is representative of the target population and help minimise health inequities by standardising care
6 Training implications
As part of the employment process and thereafter through the appraisal scheme, clinical safety personnel will undergo suitable training to develop, maintain or enhance their competency level. All registered clinicians involved in clinical safety roles shall, as a minimum, have completed an accredited training course.
NHS England have developed an eLearning programme with the NHS Digital Clinical Safety team which aims to support a culture of digital clinical safety across NHS organisations. It is recommended that the essentials of digital clinical safety programme (opens in new window) be completed by any colleagues contemplating procuring a healthcare IT product.
As a trust policy, all staff need to be aware of the key points that the policy covers.
Staff can be made aware through:
- all user emails for urgent messages
- one to one meetings and supervision
- continuous professional development sessions
- posters
- daily email (sent Monday to Friday)
- practice development days
- group supervision
- special meetings
- intranet
- team meetings
- local induction
7 Monitoring arrangements
7.1 Internal safety audits
- How: Coordinated by Information Quality team.
- Who by: CSO’s.
- Reported to: Digital transformation group.
- Frequency: Annually.
7.2 Supplier audits
- How: The basis for the audit shall be NHS Digital, DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems (opens in new window).
- Who by: Supplier coordinated by CSO’s.
- Reported to: Digital transformation group.
- Frequency: Annually.
8 Equality impact assessment screening
To access the equality impact assessment for this policy, please email rdash.equalityanddiversity@nhs.net to request the document.
8.1 Privacy, dignity and respect
The NHS constitution states that all patients should feel that their privacy and dignity are respected while they are in hospital. High quality care for all (2008), Lord Darzi’s review of the NHS, identifies the need to organise care around the individual, not just clinically, but in terms of dignity and respect.
As a consequence the trust is required to articulate its intent to deliver care with privacy and dignity that treats all service users with respect. Therefore, all procedural documents will be considered, if relevant, to reflect the requirement to treat everyone with privacy, dignity and respect. When appropriate this should also include how same sex accommodation is provided.
8.2 Mental Capacity Act 2005
Central to any aspect of care delivered to adults and young people aged 16 years or over will be the consideration of the individuals’ capacity to participate in the decision-making process. Consequently, no intervention should be carried out without either the individual’s informed consent, or the powers included in a legal framework, or by order of the court.
Therefore, the trust is required to make sure that all staff working with individuals who use our service are familiar with the provisions within the Mental Capacity Act (2005). For this reason all procedural documents will be considered, if relevant to reflect the provisions of the Mental Capacity Act (2005) to ensure that the rights of individual are protected and they are supported to make their own decisions where possible and that any decisions made on their behalf when they lack capacity are made in their best interests and least restrictive of their rights and freedoms.
9 Links to any associated documents
- Appointment of staff policy
- Clinical audit policy
- Incident management policy
- Risk management framework
10 References
- NHS Digital, DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems (opens in new window).
- NHS Digital, DCB0160: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems (opens in new window).
11 Appendices
11.1 Appendix A Definitions and explanation of terms used
| Term | Definition |
|---|---|
| Clinical safety officer (previously referred to as responsible person) | Person in a manufacturer’s organisation responsible for ensuring the safety of a health IT system in that organisation through the application of clinical risk management |
| Clinical safety officer (previously referred to as responsible person) | Person in a manufacturer’s organisation responsible for ensuring the safety of a health IT system in that organisation through the application of clinical risk management |
| Clinical risk | Combination of the severity of harm to a patient and the likelihood of occurrence of that harm |
| Clinical risk analysis | Systematic use of available information to identify and estimate a risk |
| Clinical risk control | Process in which decisions are made and measures implemented by which clinical risks are reduced to, or maintained within, specified levels |
| Clinical risk estimation | Process used to assign values to the severity of harm to a patient and the likelihood of occurrence of that harm |
| Clinical risk evaluation | Process of comparing a clinical risk against given risk criteria to determine the acceptability of the clinical risk |
| Clinical risk management | Systematic application of management policies, procedures and practices to the tasks of analysing, evaluating and controlling clinical risk |
| Clinical risk management file | Repository of all records and other documents that are produced by the clinical risk management process |
| Clinical risk management plan | A plan which documents how the manufacturer will conduct clinical risk management of a health IT system |
| Clinical risk management process | A set of interrelated or interacting activities, defined by the manufacturer, to meet the requirements of this standard with the objective of ensuring clinical safety in respect to the development and modification of a health IT system |
| Clinical safety | Freedom from unacceptable clinical risk to patients |
| Clinical safety case | Accumulation and organisation of product and business process documentation and supporting evidence, through the lifecycle of a health IT system |
| Clinical safety case report | A report that presents the arguments and supporting evidence that provides a compelling, comprehensible, and valid case that a system is safe for a given application in a given environment at a defined point in a health IT system’s lifecycle |
| Harm | Death, physical injury, psychological trauma and or damage to the health or wellbeing of a patient |
| Hazard, | Potential source of harm to a patient |
| Hazard log, | A mechanism for recording and communicating the ongoing identification and resolution of hazards associated with a health IT system |
| Health organisation | Organisation within which a health IT system is deployed or used for a healthcare purpose |
| Health IT system, | Product used to provide electronic information for health or social care purposes. The product may be hardware, software or a combination |
| Initial clinical risk, | The clinical risk derived during clinical risk estimation taking into consideration any retained risk control measures |
| Intended use, | Use of a product, process, or service in accordance with the specifications, instructions and information provided by the manufacturer to customers |
| Issue | The process associated with the authoring of a document. This process includes, reviewing, approval and configuration control |
| Likelihood | Measure of the occurrence of harm |
| Lifecycle | All phases in the life of a health IT system, from the initial conception to final decommissioning and disposal |
| Manufacturer | Person or organisation with responsibility for the design, manufacture, packaging or labelling of a health IT system, assembling a system, or adapting a health IT system before it is placed on the market and or put into service, regardless of whether these operations are carried out by that person or on that person’s behalf by a third party |
| Patient | A person who is the recipient of healthcare |
| Patient safety | Freedom from harm to the patient |
| Post-deployment | That part of the lifecycle of a health IT system after it has been manufactured, released, deployed and is ready for use by the health organisation |
| Procedure | Specified way to carry out an activity or a process |
| Process | Set of interrelated or interacting activities which transform inputs into outputs |
| Release | A specific configuration of a health IT system delivered to a health organisation by the manufacturer as a result of the introduction of new or modified functionality |
| Residual clinical risk | Clinical risk remaining after the application of risk control measures |
| Safety incident | Any unintended or unexpected incident which could have, or did, lead to harm for one or more patient’s receiving healthcare |
| Safety incident management log | Tool to record the reporting, management and resolution of safety incidents associated with a health IT system |
| Severity | Measure of the possible consequences of a hazard |
| Third party product | A product that is produced by another organisation and not by the health IT system manufacturer. Examples include operating systems, library code, database and application servers and network components |
| Top management | Person or group of people who direct(s) and control(s) an organisation and has overall accountability for a health IT system |
11.1 Appendix B Clinical risk management system (CRMS) annual quality audit
Document control
- Version: 2.
- Unique reference number: 1007.
- Approved by: Corporate policy approval group.
- Date approved: 8 October 2024.
- Originator or author: Information quality manager.
- Responsible individual: Director of health informatics.
- Date issued: 9 October 2024.
- Review date: 31 October 2027.
- Target audience: Trust wide.
Page last reviewed: December 10, 2024
Next review due: December 10, 2025
Problem with this page?
Please tell us about any problems you have found with this web page.
Report a problem