Search the hub

This year I’m seeing many more complaints on Twitter from healthcare professionals about the misuse of incident reporting. The threat “I’m going to Datix you!” is coming up time and time again and people are complaining about being “datixed” inappropriately. One Twitter user recently said: “Datix has been used as a verb so many times on my feed today that my head might explode”. Datix has become associated with fear, retribution and blame. But how has this come about and what can be done to change it? Datix as a company has seen many changes since I stood down as chief executive in 2015. The most noticeable is a change of name to RLDatix, reflecting the acquisition in 2018 of Canadian rival RL Solutions. Some things, however, have not changed. Healthcare professionals still complain about the length and complexity of the Datix forms. They still complain about the lack of action from the incident reports they submit. They still complain about getting into trouble as a result of reporting an incident themselves (particularly reports about staffing levels). And they still complain about the threat of someone else including them in an incident report as a means of coercion: “If you don’t do this, I’m going to Datix you.” All of these factors are also common to incident reporting systems from other suppliers, but because Datix has the lion’s share of the UK market, they have contributed to an overwhelmingly negative sentiment about Datix. The issues The problem with complicated and contradictory forms is that Datix gives local administrators complete freedom to design the forms themselves. This results in forms that get longer and longer over time, as new people need to collect new information. The best forms I’ve seen are very short and contain the date, the time, the reporter’s details and free text boxes for a description of what happened and what action was taken. The very best forms I’ve seen have an additional free text box: “Your safety ideas”, asking the reporter if they can think of any ways that this type of incident could be avoided or mitigated in the future. It’s a good way to encourage people to think about safety; however, it does rely on someone at the other end of the report actually listening and responding. The issue with the lack of feedback is that it relies on someone following up, investigating and then reporting back on the incident. Or if the incident isn’t going to be investigated, the reporter should be sent an explanation. If reporters don’t get any feedback and can’t see any changes made as a result of reporting, they’re going to stop reporting. This is not a problem with the incident reporting software, but an issue of the system within which it is used. The issue of the threat and fear of reporting is more deep-seated and harder to change. It’s partly linked to the other two issues – if incident reporting has no positive outcomes, it’s seen only as a burden and a tool for punishment. It’s also a symptom of a culture of fear, bullying and a lack of resources, where stressed managers want to discourage the reporting of incidents as they don’t have the time or resources to do anything about them. There are constant calls for culture change. But culture change is difficult and it’s hard to know where to start. We can, however, take incremental actions that contribute to a shift in culture. Culture change One example is the former Calgary Health Region in Canada, which had a culture where incident reporting was being used for performance management, with managers reprimanding staff who reported incidents. Recognising this was having a bad effect on staff and patients, Calgary Health Region reconfigured Datix so that the managers couldn’t see information that would identify the reporters. This didn’t change the culture overnight, but it gave staff confidence that they could report incidents in an environment free from punishment. Coupled with the setting up of a separate central department responsible for safety and investigations, this set the organisation on the long road to culture change. An excellent write up of the system that Calgary implemented can be found here. Would that system work here in the NHS? Yes it would help, but it doesn’t go far enough in a system where incident reporting has got such a bad name. We need something much more radical. What if we were to abolish incident reporting completely? Automated incident reporting systems This doesn’t mean we have to remove investigation and learning from the patient safety toolkit. It does mean that we can obtain information about incidents from places other than manually input incident report forms. The technology already exists to do this. We can monitor a hospital’s IT systems in real time to see if an incident had happened or for signs that an incident was about to happen. There would be no need to replace existing incident management systems, just the method of getting the incidents into the systems and a change to the processes around them. Such an automated incident reporting system already exists – again, in Canada – at The Ottawa Hospital. The hospital devised rules, called e-triggers, that automatically create an incident record based on certain criteria in other hospital IT systems. One such trigger might be a return to the emergency department within three days. The creation of the incident record also sends a notification to a clinician to review the record and answer some simple questions to determine if a follow up or investigation is needed. You can read some of the results from the system in this BMJ Quality & Safety paper. Although they haven’t done away with incident forms completely, this is a step in the right direction. I don’t know of anyone who has done anything similar here in the NHS, but I believe this system would go a long way towards the goal of eliminating the threat of “I’m going to Datix you”. A call to action Set up triggers to automatically send potential incidents from other IT systems into existing patient safety reporting systems. Software suppliers should take the lead on this. Simplify current incident report forms so they are as quick as possible to complete. Give clear guidance on what incident reporting should and should not be used for, with assurances that no one will get into trouble for reporting an incident or being included in an incident report. Do you have any ideas on how we can improve incident reporting and prevent the threat of “I’m going to Datix you”? Please join the discussion on the hub.

Get Headspace for free, sponsored by Headspace for NHS Clinical: 1000+ hours of mindfulness and sleep content. Mini exercises for busy schedules.

ECRI’s list of patient safety concerns for 2020: 1. Missed and delayed diagnoses—Diagnostic errors are very common. Missed and delayed diagnoses can result in patient suffering, adverse outcomes, and death. 2. Maternal health across the continuum—Approximately 700 women die from childbirth-related complications each year in the U.S. More than half of these deaths are preventable. 3. Early recognition of behavioural health needs—Stigmatisation, fear, and inadequate resources can lead to negative outcomes when working with behavioural health patients. 4. Responding to and learning from device problems—Incidents involving medical devices or equipment can occur in any setting where they might be found, including ageing services, physician and dental practices, and ambulatory surgery. 5. Device cleaning, disinfection, and sterilisation—Sterile processing failures can lead to surgical site infections, which have a 3% mortality rate and an associated annual cost of $3.3 billion. 6. Standardising safety across the system—Policies and education must align across care settings to ensure patient safety. 7. Patient matching in the EHR—Organisations should consistently use standard patient identifier conventions, attributes, and formats in all patient encounters. 8. Antimicrobial stewardship—Over prescribing of antibiotics throughout all care settings contributes to antimicrobial resistance. 9. Overrides of Automated Dispensing Cabinets (ADC)—Overrides to remove medications before pharmacist review and approval lead to dangerous and deadly consequences for patients. 10. Fragmentation across care settings—Communication breakdowns result in readmissions, missed diagnoses, medication errors, delayed treatment, duplicative testing and procedures, and dissatisfaction.

1. Introduction and scope 2. Guidance 3. Software and data implications

OptiMed-ID is an innovation unique within the UK, which uses robotic technology and logistics software to produce and deliver individual doses of medication within an acute hospital setting. It enables complete control of medicine prescribing, supply and administration, reducing medication errors and cutting waste. Already deployed and delivering significant cost savings in 20 hospitals in Italy, the independent evaluation work – completed December 2015 – has confirmed that the use of “optimisation of medicines with individual dosing” (OptiMed-ID) in an NHS acute hospital setting can deliver drugs cost savings in excess of 25%. Deployed throughout four wards at UHL, this is the first time that an automated individual medicines dosing solution has been brought into operational use in the UK. The evaluation report has informed UHL’s decision to extend the pilot whilst business case and procurement activities for the rollout of the innovation throughout the whole trust are completed. The trust-wide deployment at Leicester is expected to deliver savings to the NHS of around £4m per annum, as well as improving medicines adherence and reducing the risk of medicine errors.

This policy sets out DHSC's priorities: infrastructure digital services innovation skills and culture. Challenges to overcome: legacy technology and commercial arrangements complex organisational and delivery structures a risk-averse culture limited resources to invest a critical need to build and maintain public trust. Describes four guiding principles: user need privacy and security interoperability and openness inclusion.

Internet First means that externally accessible health and social care digital services must be securely accessible over the public internet by default. These guidelines refer to existing and updated policies to ensure that data is safely accessible.

This toolkit was developed to provide nursing homes that have an electronic medical records system with tools to effectively monitor and manage pressure ulcers. Clinical reports provide information about the number and types of pressure ulcers that residents have developed.

and a pioneer in emerging risk.

This special issue focuses on the role of technology and innovation in patient experience and includes editorials, commentaries, personal narratives, research articles and a case study.

We are a team of 14 people, split between Leeds, London and Exeter. We are a mixture of clinicians and engineers with varying backgrounds and experiences. It’s our job to make sure that the risk of harm to patients as a result of health IT is the lowest it can possibly be. We are responsible for the production of two standards, designed to support and guide both the manufacturers of health IT and those organisations who deploy it. By ensuring these standards are in place and supporting people to comply with them, we can keep the risk of patient harm to a minimum. Of the two standards, one (DCB 0129) is relevant to those responsible for the manufacture of health IT and the other (DCB 0160) is related to the organisations that will be deploying and using the IT. Both standards are mandatory under the Health and Social Care Act 2012. When a health IT manufacturer designs a system, they must cdo so with clinical safety at heart. Any system that needs to connect to SPINE must go through an assurance process to make sure it is as safe as it can be to be deployed. Part of this assurance process is clinical safety. The clinical safety stage of assurance involves the assessment of the system for compliance to DCB 0129. DCB 0129 guides the manufacturer in their clinical risk management provision. It outlines their clinical safety responsibilities, such as: They must nominate a person responsible for clinical safety. This person must be a suitably qualified and registered clinician. They must produce a log of all the potential hazards associated with the system that could impact the patient. They must produce a safety case that will detail the risk analysis of each hazard and specify what controls and mitigations have been put in place to ensure as far as possible that these hazards will not occur. The same kind of responsibilities are outlined in DCB 0160 with regards to those taking on and deploying the health IT. They must be sure they have understood all the hazards identified by the system manufacturer and have made their own provisions to reduce the risk as far as possible. This should also be detailed in the same format and standard of documentation that is expected from the manufacturers under DCB 0129. We work closely with both the manufacturers and the organisations to support them with their compliance to these standards. Before a system can be deployed for the first time, it must receive a Certificate of Authority To Release (CATR) from NHS Digital that evidences their compliance to the standard. The approval for this certificate to be given is granted by the Clinical Safety team within our weekly Clinical Safety Group (CSG) meetings once we are happy with the evidence presented. Once the CATR has been granted, the manufacturer is free to deploy the system at the intended organisation within the defined scope of the CATR. In most cases, if they wish to deploy further, or add any additional functionality, they would have to come back to CSG to get the CATR upgraded. Having this process in place ensures that clinical safety is given a respectable amount of thought and consideration. This provides us with a confidence that the risk of harm to patients is kept at a minimum. We are also involved in live service incidents. If something happens with the IT once it has been deployed, we make sure the incident has been properly assessed with regards to risk of harm to the patient.