Stucki Dana, Oberreich Damian

Abstract

Critical incidents happen in 2%‒8% of hospitalisations. The number of deaths by preventable adverse events is greater than those of flu, AIDS and traffic accidents combined.

To reduce those preventable adverse events and to increase the patient's safety, it is important to not only react when a preventable adverse event happened but also to be aware of the near misses.

One possible way to detect near misses is to introduce a Critical Incident Reporting System (CIRS). The goal of this project was to develop a CIRS for mobile devices.

Although mobile devices are not suitable for text input, they could possibly close a gap in the recording of critical incidents due to the fact that you can take these mobile
devices with you as easily as a notepad and record your
CI’s where you want (e.g. in a cafeteria). Therefore, the usability was one of the key elements in this project.

To reach this goal the authors created a clickable mock-up, which was used to test the functionality with future end-users. On the basis of the results of the mock-up and the usability tests, the authors developed a final prototype based on the web technology HTML5.

Introduction

Errors can happen – with the best intention and the best healthcare professionals in the world, things can go wrong and mistakes can be made. Serious errors can have tragic consequences for both patients and staff.

The organisation "Patientensicherheit Schweiz" assumes that there are 700-1,700 patients who die in hospitals because of errors every year.

The Chinese philosopher and social thinker Confucius (551-479 BC) once said: "If you make a mistake and do not correct it, this is called a mistake." It is therefore essential to detect such mistakes as soon as possible in order to "correct" them. For hospitals this means to detect critical incidents before worse things happen. In order to become more aware of near misses, hospitals have started to record critical incidents. Whenever an employee experiences or witnesses a critical incident or a mistake, it has to be recorded. A good way to increase the patients' safety and the working process in a hospital is to share the recorded critical incidents, so that all healthcare staff can learn from those incidents.

The reporting and analysing of the critical incidents started on paper, nowadays most of the Swiss hospitals have an electronic Critical Incident Reporting System. Computer and laptops located in hospitals and in the future mobile devices could find their way into daily working life. The integration of mobile devices brings lots of possibilities to support the working process of the employees in a hospital.

Methods

This bachelor thesis was a collaboration with Netcetera AG, a company specialised in tailor-made software. To accomplish the requirements of this project, we applied the following methods.

Mock-up

To get a first idea of how the final prototype should look like, the authors started to draw scribbles on a paper. To have a better look and feel of the ongoing project, a clickable mock-up with Axure was created [1].

Usability tests

To evaluate the clickable mock-up, usability tests were made. For those tests the authors interviewed twenty potential end-users (i.e. doctors and nurses) from hospitals and the educational centre of nursing. This test was divided into three parts. In order to get to know the test takers and their handling of mobile devices and Critical Incident Reporting Systems, the first part was a pre-interview. In the main part, the user had to solve two practical tasks with the tablet PC. In the first task, they had to record a predefined critical incident and in the second one, they had to pause the record. Finally, participants were asked to assess the mock-up, the handling usefulness and usability in their daily work-life.

Implementation

After evaluating the mock-up, the authors developed a first prototype with the programming technologies HTML5, PHP, JavaScript and CSS. For the front-end the framework Bootstrap was used [2]. The project was stored on a virtual machine belonging to "Berner Fachhochschule, Technik und Informatik".

Results

The process of a critical incident reporting system

The process of a critical incident report is shown in figure 1.

As soon as a critical incident is recorded, the Critical Incident Manager (CI-Manager) is sent an information email. His first task is to verify the custom text entry. Indications of patient or staff identity must not be disclosed. Therefore, if there is something written that identifies a patient or an employee, the Critical Incident Manager has to make it anonymous. After that, the CI-Manager has to analyse the critical incident. It is important to find the reason(s) for the incident and to define which actions need to be taken. In small hospitals this is mostly done by the CI-Manager but in bigger hospitals it is done by a CIRS-Circle. A CIRS-Circle ideally consists of multiple people of different professional categories.

fullscreen

After having analysed the report, it has to be shared with other employees. The publication of such reports has positive impacts on the error management culture in a hospital. The user who submitted the critical incident can be certain that the quality management is aware of the report and that suitable action will be taken. Consequentially the submitter is motivated to report more critical incidents in the future and all staff benefit from having a good CIRS. Rather than considering near miss reporting extra work or something to be ashamed of or embarrassing to do, employees should feel proud of being part of an effective critical incident management process.

Prototype

With the web application "CIRS mobile" the hospital has the possibility to record a critical incident on a tablet PC or to link the Critical Incident Reporting System on the intranet.

Record a critical incident

To complete a record of a critical incident, the submitter has to complete three steps.

Firstly, the submitter types in all the necessary information about himself and the patient (shown in fig. 2). The two fields "professional category" and "department" are mandatory and must be filled out. Furthermore, the user can choose whether s/he wants to submit the report anonymously or not.

Secondly, all the information about the event needs to be recorded. There are two custom text fields, which are mandatory. In the first one, the submitter writes what has happened. In the second one, the submitter describes the situation and how s/he handled the event. Additional information may be submitted voluntarily (e.g. patient age group, photographs etc.). In a third custom text field, the submitter can recommend actions that could help prevent a similar incident (optional). There is also the possibility to record a picture with the tablet PC, to include it in the report. In a last step, the user can write down more information about the shift and analyse the factors that led to this incident. Throughout every step, the report can be saved with a personal keyword and a password and finished later (on the tablet PC or laptop).

Critical Incident Manager

This section offers the possibility to look at the submitted records (for authorised personnel only). The view is designed in the same way as the "record a critical incident" page. The CI-Manager can read all the information submitted and has the option to edit the custom text fields if there are some identification features of a patient or an employee. At the very bottom, there are two mandatory fields, a custom text field for the title of this critical incident and a multi-select dropdown to choose which action to take. Moreover, the CI-Manager has the possibility to further analyse the report, i.e. priority, event frequency and event context can be selected.

fullscreen

To complete the critical incident reporting, the CI-Manager decides whether to give final approval to the report and hence grant access to employees or whether the report should not be shared and/or passed on to the quality management for further investigation.

Sharing critical incidents reports

As soon as the Critical Incident Manager grants access to the critical incident report, the employees have the possibility to read the reviewed critical incident on the screen "publicise critical incidents".

Reporting

The quality manager also has the possibility to evaluate the submitted critical incidents. Required information can be filtered and displayed in different charts.

Evaluation of usability tests

For the usability test twenty interviews with potential end-users were conducted (test takers are shown in
table 1). The self-benchmarking about the utilisation of mobile devices was rated medium – very good. 60% of the participants use a tablet PC at home. However, at work none of them have ever used a tablet.

Most of the interviewees (90%) knew the definition of a CIRS. 55% had already recorded a critical incident. In relation to the improvement of the security in a hospital, the test takers rated the influence of a CIRS medium – high (95%).

80% of the interviewees have witnessed a critical incident but did not record it due to lack of time, neglect, fear of confrontation, protection of a colleague, or because it was not considered significant enough.

Table 2 shows that the anonymity of a Critical Incident Reporting System plays an important role. However, there were some statements about the appreciation of not reporting a critical incident anonymously.

Table 1.Evaluation professional category
Test takers	Percentage
Nursing service	55%
Medical service	35%
Administration	5%
Others	5%

The graphical user interface is understandable and easy to use

Practical tasks showed that most participants had difficulty neither with the navigation nor with the text input on a tablet PC. Only two people reported difficulty with the text input and would consequently not want to use the tablet PC to report critical incidents.

The option of being able to pause the reporting process at any time and the fact that photographs can be taken were appreciated by 95% of the test takers.

Overall, the usability tests showed that most participants would record a critical incident with a tablet PC if the hospital offered it (shown in fig. 3).

Table 2. Evaluation: The graphical user interface is understandable and easy to use.
Answer Option	Percentage
Strongly agree	75%
Agree	25%
Disagree	0%
Strongly disagree	0%

Would you use a tablet to record a critical incident?

Benefits of our solution

An overview of all benefits of our solution is shown in table 3.

fullscreen

Table 3.Benefits of our product
Feature	Description
Easy to use	The form only includes the most important input fields and can be submitted quickly.
Taking or uploading pictures	Pictures can be taken with the tablet PC or uploaded from your PC/laptop. A picture may help to clarify the event (e.g. look-alike medication).
Complete your report anytime	At any time, the report can be saved with a personal keyword and a password and completed later (on the tablet PC or laptop).
Device and platform independent	Thanks to the web technology HTML5 you can run our product on all devices (PCs/laptops, tablet PCs) and platforms (iOS, windows, android).

Discussion

A Critical Incident Reporting System is one possible way to increase patient safety and working processes in hospitals. For us it was important to create a web application potential end-users like. Therefore, our main aim was to allow simple and intuitive navigation. Furthermore, employees should be able to report incidents efficiently in as short a time period as possible. When the authors first started their project, the main problem they encountered was the text input on the tablet. Thus, it was surprising that most of the users had no problem with typing in their report and that no one mentioned it in the discussion of critical points.

Although today's standard is to record anonymously, it was a surprising outcome that there were some potential end-users who wished to have the option of not having to submit a critical incident anonymously. This change could improve the quality of a CIRS, since the Critical Incident Manager would have the possibility to confer with the submitter and to discuss ambiguous matters.

It is very important to have good communication and a trustful environment relating to a CIRS; in this way, gaps in reporting can be minimised. Employees who witness or experience a critical incident should report it. Fear of confrontation, accusation or protecting a colleague are not reasons to not report critical incidents. They should feel proud of having and being part of an effective critical incident management system. Furthermore, it is important for employees to know that all critical incidents are significant enough to be reported. Patients as well as employees can only benefit from a CIRS if every critical incident is investigated.

With the implementation of taking and uploading photographs, the authors touch upon a sensitive issue. When adding such a function to a CIRS, the hospital has to make sure that the employees' as well as the patients' personal data is being handled responsibly and securely.

The introduced prototype is a basic framework, so it is essential to customise it according to a hospital's needs. Every hospital's quality management has its own vision of what a Critical Incident Reporting System is and how it is used.

In conclusion, the project showed that most interviewees are open-minded towards new ideas and technological changes and most participants reported that they can imagine working with a tablet PC / CIRS one day.

Correspondence

Correspondence:

Dana Stucki

Berner Fachhochschule

Medizininformatik

Quellgasse 21

CH-2501 Biel

danastucki[at]gmail.com

References

1 http://www.axure.com

2 http://www.getbootstrap.com

Copyright

Published under the copyright license
“Attribution – Non-Commercial – NoDerivatives 4.0”.
No commercial reuse without permission.
See: emh.ch/en/emh/rights-and-licences/