Incident reporting and a culture of safety

Adoption of incident reporting software

Software for incident reporting dates back to the early 1990s, when computer systems for administration in NHS hospitals started to become more widespread. Most hospitals were not fully networked and the systems were typically used by one or two individuals who were responsible for transcribing the paper incident report forms into the computer system. The incident report forms themselves were commonly A3 size, with multiple tick boxes and some space for handwritten free text. Many hospitals adopted a form design called IR1, originally intended for Health and Safety incident reporting but modified for the reporting of clinical incidents.

This largely paper-based method of incident reporting contained a number of flaws. In some hospitals, the incident report forms were kept in a drawer in the ward manager’s office and would be locked away at night. The forms themselves were lengthy and complex to fill in, with questions relevant to patient safety often included as an afterthought. Once the forms had been completed, it could take many months before they were input into the software. I remember visiting one hospital as late as the mid-2000s, where stacks of forms were piled high in the risk management office and the backlog to enter them into the system was six months.

The process of inputting the forms into the software was also cumbersome and prone to transcription errors. All of this resulted in considerable underreporting of incidents and the danger that serious incidents might have gone unreported or, if they were reported, the form may not have made it into the software, let alone subject to any investigation, analysis or recommendations for improvement.

With the advent of hospital-wide networking in the late 1990s, the NHS was able to take advantage of the opportunities this offered to introduce new web browser-based technologies for incident reporting. Now, anyone with access to a computer was able to report an incident. Staff were familiar with using the web for online shopping and booking holidays, so the technology was accessible to them. Incident report forms could be designed so they were less overwhelming than large paper forms and reporters of incidents could be guided through the forms with ease.

Timescales for reporting reduced significantly, as incidents appeared immediately in the system, with management being notified of incidents as they occurred so they could act on them appropriately. Transcription errors were also eliminated. For the most part, organisations that implemented such systems found a significant increase in the numbers of incidents being reported following the introduction of web browser-based reporting.

Today, almost all NHS providers outside of primary care use web browser-based incident forms for the reporting of incidents as part of a larger system for investigating and learning from things that go wrong. Almost all use a commercial, off-the-shelf software package. Over the years, a number of vendors of such software have come and gone and now two vendors supply most of the NHS market.

Incident reporting has not been adopted widely in primary care. There are several reasons for this, but the lack of regulatory drivers and the fragmented nature of the primary care sector in the UK contribute to this. As a result, I do not intend to address incident reporting in primary care in this article.

Barriers to reporting

In spite of the increase in reporting that web browser-based forms have brought about, there is still concern in many organisations that incidents are underreported. The reasons for this are complex but fall into three main areas:

The forms are too complicated;

The first two issues can be addressed relatively easily. The third is a more deep-seated issue to do with organisational culture. It is worth examining each of these in more detail.

Incident form design issues

As mentioned above, incident report forms were originally printed on paper. It was therefore difficult to change the format of the forms and the nature of the questions, particularly in a large organisation. Much of the NHS standardised on a format called IR1, which was originally designed by the vendor of an early Health and Safety incident reporting software package. Although widely used, IR1 was considered unsuitable for patient safety incident reporting and one of the early tasks of the team that set up the National Patient Safety Agency (NPSA) was to make a recommendation for a standard patient safety incident report form. Although a number of discussions were held, it was decided to leave the design of the forms to individual organisations.

One of the advantages of web browser-based forms is that the design of the forms can be changed centrally and the new design is then available immediately to everyone in the organisation. Perhaps as a reaction to the inflexible nature of the IR1 form, there was desire from customers of commercial packages to have complete flexibility over the design of the forms. This has resulted in a lack of standardisation across healthcare organisations in the UK. Forms can differ vastly from one organisation to the next. The temptation is to include tick boxes and dropdowns for every possible piece of information for all types of incidents on the form. Changes to regulatory and legislative requirements can also create new questions that add to the length of the form. The result is that forms can often take twenty minutes or more to complete, which for most healthcare workers is too long.

Allowing individual organisations to design their own incident report forms has also resulted in some poorly designed forms. In some cases, the questions are difficult to answer and it is hard to work out what to choose for certain types of incident. Some reporters may be put off by the phrasing of certain questions.

Flexibility of form design can therefore be a double-edged sword. It is useful to be able to adapt the form quickly to local circumstances, but if not designed carefully and with input from the end users, the user experience suffers. Often, it is the vendors who get blamed for this. Users complain that the software is ‘clunky’ and the forms are too long and complicated to fill in. In reality, it is the organisations themselves who have made the forms too long.

Suppliers of incident reporting software are now doing more to assist organisations to design better forms. Some of the best forms are also the simplest. Those that focus on the narrative, ‘telling the story’, are to be preferred. The forms ask some basic details about the report and then ask them to describe what happened in a free text box. Also asking the reporter for their suggestions on how to prevent similar incidents from occurring can help them feel included in the process of incident reporting and learning as it shows that they are being listened to.

Feeding back to reporters

The other issue is that reporters often complain that they do not hear anything following their report. After going to the trouble of reporting an incident, it can be disheartening when they are not contacted to let them know what is happening as the result of an incident. I have heard stories of junior doctors who have reported potentially serious incidents, only to be told later that no investigation has been made or action taken as no harm came to any patients. This can deter the reporter from reporting again, as the process of incident reporting appears pointless.

Again, the software vendor is often blamed for a lack of action or feedback following an incident report. It is another common complaint that I hear: ‘you don’t get any feedback’. In fact, most commonly used software packages contain some features that can be set up easily to email feedback to the reporter during and after an investigation. But it also depends on the resources available to the organisation to investigate and feed back to the reporter. If the organisation has increased the number of incidents that are reported, it may then be overwhelmed by them and face the problem of working out how to prioritise incidents for investigation. An automated ‘Thanks for reporting’ email is all very well, but the reporter will need to see more than that in the case of a more serious incident.

A number of recent reports have highlighted current deficiencies in the approach to investigating and learning from clinical incidents in the NHS. Ensuring that individual organisations have the appropriate number of investigation staff, with the right experience and training (including Human Factors principles) is essential. Without this, vital learning from incidents being reported can be missed and the lack of feedback following the reporting of an incident can lead to disillusionment and disengagement with improving patient safety for the staff involved. The issue of providing feedback to staff can be resolved but may require additional resources to do so.

Fear of reporting

The third issue, that of fear of the consequences of reporting, is more deep seated and intractable. If reporters feel they are somehow going to be punished for reporting incidents, this is a strong deterrent to reporting and results in problems being driven underground.

From the stories that have been told to me, in many cases this fear is justified. I have heard from nurses who, concerned about the safety of their patients, have reported understaffing in their wards and been subjected to performance management processes by HR as a result. I have also heard from clinicians who have been instructed by their managers not to report incidents as it would make the managers look bad. I have also heard from doctors who have been branded troublemakers for reporting too many incidents. The group Patients First is composed of doctors, nurses and managers who can tell many such stories and is campaigning to try and ensure that those who raise concerns about patient safety are supported to do so instead of being punished.

The issue of staff being treated unfairly for raising concerns about safety is a very real problem. Treating the raising of concerns as an issue to be dealt with by HR means that the concerns will not be investigated and could lead to patients continuing to be harmed. Healthcare providers, as well as social care providers, need to create an environment that actively promotes the raising of concerns and reassures staff that they will be supported if they do so.

A further symptom of a ‘climate of fear’ is that incident reporting is used as a threat. There are many examples where the phrase ‘I’m going to Datix you’ is used as an attempt to intimidate staff (as in ‘if you don’t do this for me, I’m going to Datix you’). ¹ In most cases, this is an empty threat, as it is difficult to conceive of a situation where a person would be subject to an investigation under these circumstances. Most staff would perceive this as such, but those who are more junior and do not yet understand how the incident reporting system works may be more intimidated than others.

In any case, the purpose of an investigation of a patient safety incident should be to identify system issues. Any concerns about the performance of individuals should be kept entirely separate and be the subject of a separate process if necessary.

Investigation methods such as Systematic Systems Analysis (SSA), promoted by the Health Quality Council of Alberta and used in Alberta Health Services in Canada, explicitly recognise this. The guidebook to performing a review using SSA ² states:

The guide is not intended to help you find fault nor to apportion blame. Conducting a review using SSA will help your organization foster a just and trusting culture as part of its overall safety culture. With a focus on the system, the guide is not intended to help you assess individuals. If necessary, your organization or regulatory authorities should use a separate process for assessing an individual’s performance, including human error and non-compliance. In fact some situations may require both an investigation of the system as well as assessment of one or more individuals. Please remember, however, these are separate processes and must be undertaken by different individuals.

Regardless of the outcome

In 2003, The NPSA and the NHS Confederation published a tool called the Incident Decision Tree (IDT). The tool was designed to ensure that staff involved in a patient safety incident were treated fairly. It was designed to be used in conjunction with root cause analysis, which would investigate systems issues. From The incident decision tree: information and advice on use: ⁶

The Incident Decision Tree forms part of a suite of tools the NPSA is developing to promote an open and fair culture in the NHS: a culture in which staff feel able to report patient safety incidents without undue fear of reprimand.

Following the abolition of the NPSA in 2012, its website remains online, but the IDT is no longer accessible. A revised and updated version of the IDT would be a very valuable tool to help in the adoption of the just culture that HSIB is trying to promote.

Ensuring that healthcare professionals who find themselves involved in an incident or mistake are confident that the whole system will treat them fairly if they are open and honest about what happened is a priority. In the 2015 NHS Staff Survey, only 68% of NHS staff said they felt secure in raising concerns, ⁷ which shows how far there is still to go.

To summarise, some of these barriers to reporting can be addressed relatively easily with changes to the platform used for incident reporting. The cultural issues around fear are harder to address, but with real commitment from the leaders of the organisation, a just culture of safety is certainly achievable, helping to protect patients from harm and enabling staff to contribute fully to improving safety.