Real-time tracking and documentation in trauma management

Abstract

In trauma resuscitation, an accurate documentation is crucial to improve the quality of trauma care. Hospital emergency departments typically adopt handwritten paper records and flow sheets for acquiring data, which are often inaccurate. In this article, we describe TraumaTracker, a computer-based system for trauma tracking and documentation. Results demonstrate that completeness and accuracy of trauma documentation significantly improved using TraumaTracker, since it enables to add data and information that were not recorded in paper documentation – especially precise times and locations of events.

Introduction

Trauma resuscitation refers to the initial management of a severely injured patient. It usually begins during the transportation of patient to healthcare facilities, and it proceeds inside the hospital emergency department (ED). Adequate and complete tracking and documentation of times, paths, critical events, vital signs, physical examination and test results, during a trauma resuscitation, are crucial for several reasons. ¹ It has been demonstrated that poor quality in documentation is associated with higher patient mortality, ² since processes of decision-making and coordination among healthcare providers are grounded in this documentation.^3,4 Moreover, it is an important source of data impacting at least three levels: (1) organisation and management – statistics on times and paths enable the evaluation of team performance and hospital organisation; (2) clinic – a-posteriori analyses of correlation among procedures and vital sign evolution can provide useful clinical insights; (3) legal medicine – the complete tracking of data may be used, for example, by medical insurances or for legal reasons.

Even though the introduction of information and communication technologies (ICTs) in healthcare systems is strongly impacting medicine, literature evidences show that trauma resuscitation all over the world still can count on minimal ICT support for documentation purposes. ⁵ Nowadays, most of the EDs adopt handwritten records that are often inaccurate since they lack crucial data.^1,6 This problem is particularly evident when Trauma Leader, who is actively involved in trauma care, is in charge of documentation and writes notes by memory only at the end of resuscitation (e.g. in European countries).

However, in the last decade, ICTs witnessed an impressive progress, particularly on mobile and wearable devices, making visions about pervasive computing in hospitals^7–9 more and more a reality. Nowadays, personal digital assistants (PDAs) and tablets are widely deployed in various healthcare contexts. ¹⁰ Modern smartphones are powerful computing devices, featuring a variety of onboard sensors (camera, GPS, NFC reader, etc.), a robust support for pervasive interaction with an ecosystem of Bluetooth-enabled external devices and wireless networking, eventually including Internet and cloud-based services. Besides mobile computing, wearable computing ¹¹ and eyewear computing ¹² are achieving a level of maturity that makes it possible to exploit them out of labs, in real-world professional contexts. Smart-glasses (an example of smart-glass is Vuzix m300, that we exploited in the TraumaTracker project) can be used as basic bricks to realise hands-free or use-on-the-go systems,^13,14 in which users can, for example, asynchronously perceive information and data generated by the application, without the need for changing the focus of their current activity and limiting as much as possible the use of hands to act or interact with the device.

Overall, these technologies make it possible to conceive novel ICT-based systems that effectively support real-time documentation of trauma events and automatic generation of reports. More generally, they can provide a level of assistance in the whole trauma management process. In this article, we describe TraumaTracker, a system designed, developed and evaluated in cooperation with the Trauma Team of the Bufalini Hospital in Cesena, Italy, which hosts one of the major Italian trauma centres. The main functionalities of TraumaTracker include the following: (1) tracking, that is, automating as much as possible the collection of accurate data about events and actions during a trauma, including temporal and other contextual information (where the event occurred, who was the Trauma Leader, etc.); (2) report management, that is, providing functionalities for automatically generating reports and report management (storage, search, statistics, etc.).

It is well known that the development of effective information technologies in healthcare domain is challenging: ¹⁵ socio-technical aspects play a key role, besides the specific functionalities and the level of technologies sophistication. To this purpose, TraumaTracker has been designed using a domain-driven methodological approach, ¹⁶ involving Trauma Team members in the whole engineering process – from requirement collection to the usage of prototypes of increasing complexity, until validation in real-world settings.

The remainder of the article is organised as follows. First, we provide a background about problems related to the development of documentation in trauma resuscitation, challenges related to its computerisation and existing attempts in section ‘Background and motivation’. Then, we describe the TraumaTracker system – its design, architecture and prototype development, including details about the pervasive technologies we adopted – in section ‘Materials and methods’. In section ‘Results’, we present the first results obtained by adopting the TraumaTracker system in the Bufalini Hospital’s Trauma Center. Finally, we conclude the paper providing an overview of the vision underlying current and future development of TraumaTracker in section ‘Conclusion and future work’.

Background and motivation

An accurate documentation of trauma resuscitation seems to be crucial to improve the quality of trauma care where, according to Civil, ¹⁷ ‘Quality of trauma care can be defined as achieving the best possible outcome for a given set of clinical circumstances’. The best outcome refers first to patient health, and also to trauma system organisation and to Trauma Team performances. This documentation, known in the literature as trauma documentation, should be acquired during the process of trauma resuscitation and should report where and when crucial events occurred, which and when treatments are given and procedures are performed, and finally, it should report repeated vital sign measures. The documentation is primarily used to make the most informed choice for patient medication and management. Moreover, it can be exploited to evaluate the work of team members by producing data and statistics such as time of team activation, primary assessment and arrival time of physicians.

Producing an accurate documentation in the context of trauma resuscitation is a challenging task.^6,18 First, trauma resuscitation is a fast-paced process, and very little time is left for documenting the process. Second, multiple events happen simultaneously: to treat severe injuries, potentially life-threatening, team members perform concurrent tasks and parallel activities. Monitoring all of them is quite complicated. Finally, the person in charge of documenting is often multitasking, his or her resources are not completely dedicated to the documentation task but he or she also performs other activities.

Nowadays, the EDs of most hospitals adopt handwritten paper records and flow sheets for acquiring data.^1,6,19 The process of data acquisition is mainly conducted during trauma resuscitation – or sometimes immediately after by collective memory and verbal communication – by the person in charge, the recorder. As last step, papers are sent to the central bureau where data are manually entered from the sheets into a computerised database. The overall procedure produces incomplete or even wrong documentation for two main reasons: (1) data acquisition is often inaccurate and crucial data are lacking. Valid justifications are as follows: multitasking of the person in charge of acquiring data, parallel activities of the different members of the team, multiple data to be recorded and retrospective documentation from collective memory; (2) manual transfer of data from paper to electronic format can introduce oversights. Furthermore, it is expensive in terms of time spent and workload.

In this article, we present and examine the case of Bufalini Hospital’s Trauma Center hosted in Cesena, Italy. This is the situation of most hospitals in Italy and Europe. The team leader – known as Trauma Leader, usually a senior official – is in charge of producing the documentation paper. However, this is just one of the several functions he or she has. During trauma resuscitation, Trauma Leaders supervise the work of their teams and are actively involved in the actual resuscitation, and only after resuscitation ended, they produce the report. That is, they recall and write down in prose the main facts of the trauma resuscitation process, documenting from memory and not real time.

Therefore, there is a strong need to speed up the process of documentation and to improve its quality. A system based on mobile and wearable technologies for trauma tracking and assistance would improve the accuracy of trauma documentation and significantly reduce the cognitive burden of the Trauma Team – of the Trauma Leader in particular – to create reports.

ICT infrastructures and services provide suitable tools for timely and efficiently supporting real-time trauma documentation, especially with the emergence of wearable and mobile technologies that opened new frontiers in healthcare.^20,21 For instance, they can automatise the vital sign acquisition and registration, without the need for being monitored and entered by hand in the document. They can provide a set of tools for speeding up the documentation of treatments, procedures and events. Furthermore, ICT infrastructures provide all care givers across the hospital departments immediate access to patient data. Finally, they create registries easing the step of data processing.

In the studies of Coffey et al. ²² and Peace et al., ²³ the efficacy of electronic documentation is demonstrated by comparing and analysing the records produced with electronic documentation and with paper documentation. A comparison study conducted by Zikos et al. ²⁴ shows that the introduction of electronic documentation reduces the length of stay in ED.

Despite this, ICTs have not been widely adopted so far in the context of trauma resuscitation. They are still perceived – in many cases – more as an obstacle for health professional activities than a concrete benefit, requiring a cognitive effort given by the navigation and interaction with data fields on a screen, which is less familiar than the layout of a paper flow sheet. In the following section, a discussion of works presenting the first attempts to introduce electronic documentation and mobile technologies in the context of trauma documentation is provided.

Related works

During the last decade, some attempts have been made to introduce electronic documentation and mobile technologies in the context of trauma documentation.

One of the best examples is the American Heart Association’s tablet application Full Code Pro (FCP 3.0) (http://cpr.heart.org/AHAECC/CPRAndECC/Training/HealthcareProfessional/FullCodePro/UCM_476262_Full-Code-Pro.jsp). FCP 3.0 is specifically designed for quickly documenting critical interventions during cardiac arrest resuscitation events. The app is available and free to download in the App Store. It includes simple notifications such as the change of label colour if interventions last more than defined thresholds.

An electronic trauma documentation system is developed by Zikos et al. ²⁴ to evaluate how its adoption may impact the length of stay in ED. It integrates the Advanced Trauma Life Support (ATLS) guidelines, ²⁵ that is, the standard of care for trauma. The system was primarily designed to be used by the recorder, who is not involved in treatments and who could monitor each event of trauma resuscitation, using electronic checklists, automated case-specific guidance and other diagnostic assistance tools. However, other details of the application are not published, and it is neither available nor deeply documented anywhere. In the studies of Grundgeiger et al. ²⁶ and Reinhardt et al., ²⁷ a tablet-based application for real-time documentation of in-hospital resuscitations is evaluated. It is devised to address in particular documentation of cardiopulmonary resuscitations. Within the application, a set of dedicated buttons are designed to record critical interventions and parameter characteristics of cardiopulmonary resuscitation. This system simplifies the documentation task by ‘pressing dedicated buttons’, thus enabling the recorder to actively participate in resuscitation actions.

However, none of the applications already developed are sufficiently general purpose for hospital EDs, where different types of traumatic injuries must be treated. The majority of existing applications are indeed devoted to managing cardiac arrest scenarios. Moreover, to the best of our knowledge, none of them allows to automatically retrieve and store patient vital signs.

Materials and methods

In this section, we introduce the TraumaTracker system. We describe the TraumaTracker architecture, functionalities and relevant aspects of prototype implementation.

Main parts

The TraumaTracker system is composed of three main subsystems (see Figure 1):

• A mobile/wearable part, based on a tablet and smart-glasses running the Trauma Leader Assistant Agent, referred as TLAAgent, to be used by a Trauma Leader during a trauma.

• A front-end part, called TraumaTracker Dashboard (referred as TTDashboard), a web app providing functionalities to access, manage, analyse and print reports.

• A back-end part, based on a set of services hosted by a server on the hospital Intranet, used by the TLAAgent and the TTDashboard. The services include the TraumaTracker Report Service (TTReportService), collecting and managing the reports; the TraumaTracker Location Service (TTLocationService), providing real-time information about the current location (room) of an ongoing trauma; and the TraumaTracker Gateway Service (TTGatewayService), acting as a gateway to interact with existing facilities and services of the hospital. The main one is about vital parameters, that is, getting real-time data about the vital parameters of a patient of an ongoing trauma.

Figure 1.

TraumaTracker system architecture and prototype technologies.

Functionalities

The TLAAgent subsystem assists Trauma Leaders first in tracking the main events and information about an ongoing trauma, thus automating the construction and delivery of the digital report to the TTReportService.

A key aspect of this subsystem is the user interface (UI), which has been carefully designed through a close cooperation between the two teams – computer science researchers on one side and physicians on the other. The goal was to enable Trauma Leaders to track effortlessly the main information and events, thus reducing the burden of technology and improving user experience. Since the context requires rapidity and effectiveness, particular attention has been devoted to developing an easy-to-understand and easy-to-use UI. Functionalities of the resulting UI are discussed below. Screenshots are shown in Figure 2.

Figure 2.

TraumaTracker App Screenshots for drugs administration, vital signs and blood tests recording. (A) The Drugs item proposes the different categories of drugs from the most commonly used and using a different colour for each category. (B) The Drugs Infusion item shows which drugs are continuously administered, specifying when administration started, time elapsed and dosage (rate). (C) Details of the arterial blood gas (ABG) test diagnostic parameters dialog. (D) Changes in patient status can be specified here. (E) A report overview with vital sign values together with date and location of acquisition.

UI buttons are properly organised by categories in different views, using a specific colour for each category (see Figure 2(A)). Only one click is needed in most cases to insert an event, whereas longer notes can be added in free text fields. Before beginning the trauma resuscitation, patient’s demographics and information on pre-hospital care are gathered. Pre-hospital information are manually introduced by Trauma Leaders, in the PRE-H form of UI, during a quick conversation with the rescuer who has managed the patient at accident place. Trauma Leader can also fill manually the PATIENT INFORMATION form, where patient’s personal data and his or her anamnesis are stored. As an alternative, since – at the ED entrance – a unique code is associated to each patient on a barcode-based wristband, TraumaTracker provides a functionality to automatically read the barcode. However, in this case, only patients’ ID is recorded, without their personal information. At the emergency room entrance then – before the trauma resuscitation starts – the TLAAgent provides an easy-to-use form to annotate patient’s clinical status: for example, whether heart rate is normal rather than bradycardic or tachycardic, whether patient is breathing spontaneously or not, whether external bleeding is present, the three scores of the Glasgow Coma Scale (GCS) ²⁸ – eye opening response, verbal response and motor response – as well as the total GCS score and many others.

During the session, the TLAAgent supports the following functionalities.

Drugs – recording the administration of a particular drug. Drugs are organised into five different categories, namely, infusions (e.g. the millilitres of crystalloids or hypertonic solution administered), blood products (pools of cryoprecipitates, doses of fibrinogen, platelets, etc.), generic drugs (e.g. adrenaline, atropine and tranexamic acid), ALS drugs and antibiotic prophylaxis – a portion of this item is shown in Figure 2(A), scroll-down is necessary to visualise all drugs.

Continuous Infusions Drugs – recording the infusion of those drugs for which a continuous administration is necessary, such as adrenaline, noradrenaline and dopamine. Here it is possible to specify and register when the administration begins, its rate, when it ends and possibly, in between, if the rate changes – as shown in Figure 2(B).

Procedures – recording the execution of specific procedures (e.g. endotracheal intubation, thoracic drainage and application of a tourniquet).

Diagnostics – recording which diagnostic tests are executed. Tests are classified into two categories: (1) instrumental diagnostics, such as echography, angiography and radiologic tests and (2) laboratory diagnostics, mostly related to blood tests such as arterial blood gas (ABG) test or rotational thromboelastometry (ROTEM). Blood test results can be inserted manually, such as pH, pCO₂, pO₂, SatO₂, Na⁺, K⁺, Cl⁻, ${\mathrm{Ca}}_2^{+}$ , haemoglobin – acquired by ABG – as well as haemostasis information – Figure 2(C) shows how to specify ABG data.

Changes in Patient Status – specifying whether and how the initial picture of the patient is changed, to annotate important variations to the patient vital signs, airways and breathing characteristics, and neurological examination (i.e. a patient who was hypoxic has returned to have a normal oxygen saturation) – Figure 2(D) shows a portion of this tab, scroll-down is required for all the parameters to be specified.

Notes – taking note, both written and multimedia such as audio messages, videos and camera snapshots.

Each event or note is tracked automatically including the information about when and where: this means the documentation reports, for each event or note; the exact time; and room or place it occurred. Note that, for detecting information about the place, the interaction with TTLocationService subsystem is exploited. The TTLocationService exploits a beacon infrastructure – based on Bluetooth Low Energy (BLE) technology. Each room of the trauma path (shock room, Computerised Tomography Scan (TAC) room, angiography room and operating room) has been equipped with a beacon gateway, connected to the hospital Intranet. The functionality of the beacon gateway is to continuously monitor the tags (beacon) detected inside the room, making this information available to the TTLocationService. A beacon tag is worn by the Trauma Leader during a trauma, defining the current location of an ongoing trauma.

Other data are tracked automatically by TraumaTracker. TLAAgent interacts with the TTGatewayService that acts as a bridge enabling retrieval of patient vital signs (arterial pressure, heart rate, temperature, etc.) from the monitoring system that is connected to patient through sensors. This service has been designed to allow communication with the third-party gateway monitoring system (a Drager Infinity® Gateway) using the HL7 protocol (http://www.hl7.org/implement/standards/index.cfm?ref=nav) to receive real-time values for patient vital signs. The gateway offers two functional modalities: (1) request–response mode to retrieve current values and (2) push mode to periodically receive and store vital sign values. Using TraumaTracker, vital signs are retrieved and annotated periodically. Period can vary depending on patient location (i.e. the period of vital sign monitoring could be different if the patient is currently in shock room rather than in TAC room). They are automatically saved in the report, but they can also be visualised real time on the tablet (see Figure 2(E)).

When trauma resuscitation ends, the final destination of patient is annotated (i.e. emergency room observation area and intensive care unit) and the full report is automatically sent to the TTReportService. If network is not available, the report is stored on the device (tablet), until transfer is successful.

By interacting with the TTReportService, the TTDashboard web app provides functionalities to access and manage reports (search, print and export) and do simple statistics from a web browser.

Currently, the use of smart-glasses is limited to display selected information about ongoing tracking, for example, patient’s vital signs, to take snapshots using the onboard camera and to perform a simple form of video streaming, eventually enabling the Trauma Leader to share the ongoing situation with remote colleagues.

Implementation details

The first prototype of the TraumaTracker system has been developed and deployed as a proof of concept, following the logical architecture explained in the previous section. From the technological point of view, the TraumaTracker main subsystem has been developed as a mobile application running on an Android-based device. The TLAAgent has been implemented using the custom version of JaCaMo ²⁹ – a multiagent-oriented programming platform – running on mobile and wearable devices based on JaCa-Android. ³⁰ In particular, this platform introduces an agent-oriented programming model to design, develop and run agent-based applications on top of the Google Android platform, allowing a more effective design of reactive and proactive software components. For the prototype of the wearable part of the system, we used the Vuzix m300 (https://www.vuzix.com/Products/m300-smart-glasses) smart-glasses, communicating with the mobile system through a dedicated Bluetooth TCP channel. The device acts as an auxiliary external display to receive notifications from the TraumaTracker system in a complete hands-free mode. The smart-glasses are equipped with a camera which is utilised in this case to take photos and videos to be included in the report. The TraumaTracker Dashboard has been developed as a web-based application, using several technologies. Services offered by the infrastructure, instead, have been developed as HTTP-based RESTful services, implemented in Java using the Vert.x framework. Also, a MongoDB (https://www.mongodb.com/) NoSQL database has been used to store data and reports as documents. These choices make the system ready to scale, eventually exploiting either public or private cloud services. The beacon infrastructure is based on BlueUp technology (https://www.blueupbeacons.com) – in particular, one BlueBeacon Gateway for each room and a set of wearable BlueBeacon Tags.

More implementation details about the TraumaTracker system are available in the study of Croatti et al. ³¹

Results

The evaluation is devoted to stress the efficacy of TraumaTracker in terms of both user satisfaction (time to produce the trauma documentation, user experience and usability) and completeness and accuracy of the data acquired against the paper documentation. The goal is to demonstrate that electronic documentation records the same data found in paper documentation, but provides a number of new features such as (1) documenting locations and times of each event, (2) improving data accuracy by real-time measures and (3) building an electronic data set that can be easily and quickly accessed for further evaluation.

Methods

A field test has been conducted with real users. The TraumaTracker prototype is being regularly used by all members of the Bufalini Hospital’s Trauma Center (the experimentation started in April 2018), with the objective of both improving the prototype and evaluating the completeness and accuracy of the electronic documentation produced. A total of eight physicians participated in the study. They all are anaesthesia and intensive care physicians, trauma intensive care unit doctors, in-hospital emergency team doctors and ED consultants, except for one who is the in-hospital emergency system chief and trauma intensive care unit chief doctor. They all have the ATLS and ETC (European Trauma Course) certifications. They have 10 years of experience on average, with the youngest having 5 years and the oldest 25 years of experience.

The evaluation of the TraumaTracker system lies on two main pillars.

Phase 1

The focus of this phase has been UI usability and system responsiveness. Comments were gathered from users to evaluate their satisfaction and improve system design. During this phase, we carried out in-depth interviews and administered questionnaires to Trauma Team members.

Phase 2

The focus of this phase has been completeness and accuracy of trauma documentation. A total of 20 paper documentations and 20 electronic records were compared, measuring the amount and completeness of data collected. Moreover, physicians were asked to comment on data accuracy.

Phase 1 results

The two evaluation criteria used in this phase are time to produce the documentation and user experience. Interviews and responses from questionnaire gave us insights into the user-perceived ease-of-use in the fast-paced scenario of trauma resuscitation (the full questionnaire is included in Appendix 1). Feedback results were used as guidelines for adding features and improving the TraumaTracker user experience. Figure 3 depicts the scores before and after the extensions and improvements implemented to manage the feedbacks we gathered.

Figure 3.

User experience of TraumaTracker system on a scale of 1 (very cumbersome) to 10 (extremely easy) before and after the extensions and improvements implemented according to feedbacks received by physicians.

During interviews, physicians remarked that ‘the fast-paced scenario prevents the user to select and verify all events’, ‘in the heat of resuscitation, a single recorder cannot trace everything real time with the only support of the tablet’ and ‘there are too many data to be recorded’. Therefore, in version 1.0 of the TraumaTracker prototype, the most critical issues identified were strongly related with the fast-paced scenario that sometimes does not leave time even for a click on the tablet. Events may thus be recorded after the time they really occur.

These feedbacks lead to refine the prototype (version 1.1) to improve – in particular – the user experience towards simplicity and effectiveness. Simplicity means the information on the UI should be found easily and rapidly. Effectiveness means the system proposes only the minimum set needed and helpful information. Therefore, some improvements were devoted to make the use simpler: for instance, events have been ordered proposing on top the most common ones. Moreover, they have been classified into different categories using a different colour for each (see Figure 2(A)). Others to make the use more effective. First, TraumaTracker 1.1 UI provides a comprehensive list of trauma procedures and drugs – together with the recommended dose in an adult patient. This way, it reminds physicians all rescue operations, even in situations where personal concentration can be compromised. Second, we added features such as the time-sheet section – by which the list of past events is shown – that provide to physicians all the information for monitoring the trauma resuscitation progress. Some screenshots of revised TraumaTracker UI are shown in Figures 2.

Phase 2 results

The main evaluation criteria used in this phase is completeness and accuracy of trauma reports.

From interviews and questionnaire, all physicians agree that TraumaTracker prevents a retrospective inaccurate reconstruction, while enabling precise recording of numerous events, administration of medicines and procedures, together with the exact time they occur.

Paper records are indeed prose documents narrating – often firsthand – the main facts of trauma resuscitation (I went, I called, I observed, etc.), whereas electronic records appear as a precise list of consecutive events labelled with time and place. Each row of the paper documentation follows the same pattern

Date     Hour   Place     Event

2017-05-08  09:49  Shock Room  Midazolam 5mg

…

2017-05-09  10:10  Radiology   Pelvic Binder

Therefore, the main fundamental difference is the complete lack, in paper documentation, of time and location associated with medicines or procedures.

About completeness, in questionnaires, we have asked physicians how much the amount of data documented is improved switching to electronic documentation. With respect to an average number of 50 information recorded in paper documentation, 17 per cent of them claims to record 10 information and more, 33 per cent agrees for 15 and 50 per cent states for 30. Completeness of collected data is particularly improved in the picture describing patient state at arrival in ED. The average number of information describing the patient’s clinical status before Trauma Team activation is 6.75 in paper documentation, while in electronic documentation is 18.

About accuracy, Figure 4 shows how physicians evaluate the documentation accuracy. Vital signs and blood tests are more often and precisely tracked in electronic documentation: we measured that 30 per cent of paper records lack numerical values, and, in some cases, values are recorded with an ‘about’ before, meaning that, since they are recorded from memory, they are not as accurate as they should be. Finally, also time to produce the documentation changed: 50 per cent of physicians claim to save 15 min, while the other 50 per cent, 30 min.

Figure 4.

Accuracy of the electronic documentation on a scale of 1 (insufficient) to 5 (excellent).

Discussion

From the evaluation results, we can assert that all physicians agree with the unquestionable importance and utility of the TraumaTracker system. Phase 2 demonstrates that several information and data can be recorded in electronic documentation but not before. A full list of events paired with times and places is the main improvement we observed. According to feedbacks received from healthcare practitioners, this is crucial for a complete tracking of trauma and for at least three reasons: (1) first, it enables an a-posteriori analysis of Trauma Team performance and several statistics, such as time spent in each room, average duration of each resuscitation and time each Trauma Team requires for performing different actions; (2) second, from the list of past events – made available by TraumaTracker real time during resuscitation – physicians may define any further actions: the awareness of past events, how long a procedure has been going on and how long the patient is in the shock room, all are crucial information on top of which make decisions; and (3) finally, several events – such as ALS, application of a tourniquet and continuous infusion – are time-dependent: if physicians know their exact duration, and possibly receive warning if they last more than enough, they can avoid mistakes.

This is why we expect the TraumaTracker system to bring a number of benefits to trauma centres and ED organisation and quality of service by (1) identifying the most critical processes, (2) optimising and speeding up actions during the acute phase of the trauma and (3) understanding some pathophysiologic mechanisms that emerge during the process of trauma resuscitation.

Finally, the evaluation allowed us to identify the main limit of the current version, which is about the hand-based usage of the tablet by the Trauma Leader to track events. This can be problematic if or when the Trauma Leader is himself or herself directly involved in hands-full procedures. To overcome this limit, a natural solution is to exploit speech recognition, towards the design and development of a full-fledged hands-free system. From an architectural point of view, the TLAAgent – by virtue of its modularity – can be easily extended with a speech-recognition module, exploiting the facilities provided by the mobile platform (Android in this case). Nevertheless, the engineering of an effective speech-recognition module is challenging, given the specific characteristics of the context – in particular, the level of noise of the environment and the level of responsiveness and accuracy required in recognising the speech-based commands.

Conclusion and future work

In this article, we presented the problem of real-time tracking and documentation of trauma resuscitation. We discussed motivations and expected advantages of introducing proper information technologies to support trauma documentation. We then described TraumaTracker, a system based on modern pervasive computing technologies^7–9 that has been designed for this purpose.

The evaluation of TraumaTracker has been carried out in a real-world environment – the Trauma Center of the Bufalini Hospital, in Cesena (Italy). It allowed to assess the effectiveness of the tool in (1) improving accuracy and completeness of trauma documentation and (2) reducing the cognitive and practical burden of physicians by automating many steps of the documentation process. In particular, collecting accurate data about trauma resuscitation events, with temporal and contextual information (i.e. when something happened, where and by whom), has been recognised as the main benefit. This will be useful for performance analysis and statistics compilation, on top of which possibly introducing organisational changes mainly devoted to reducing healthcare costs and improving patient care.

As future work, we plan to improve user experience and usability by exploiting speech recognition. This will call to define a speech-based vocabulary of commands and sentences which would be, on the one hand, natural and flexible enough to suite with the context and, on the other hand, effective for task recognition, maximising accuracy and responsiveness.

A further direction is about smart assistance, that is, extending TraumaTracker, in particular, the TLAAgent, with assisting functionalities for the Trauma Team during trauma management. A kind of assistance which we plan to investigate is about the automatic generation of warnings that are displayed on smart-glasses. They are alerts about circumstances that the Trauma Leader may want to be notified, without necessarily interrupting her or his activity flow. This will be the first step towards framing TraumaTracker with a kind of intelligent personal medical digital assistant (PMDA) which accompanies Trauma Leader and team in their activities, providing an augmentation of their skills and abilities, enhancing their memory, attention and eventually their capability to decide and act.

Finally, future work will be devoted to extending trauma tracking including also the pre-H stage, making it possible to track information about a trauma since the first stages carried on by emergency rescuers outside the hospital.