Introduction

Critical care is a highly data intensive environment. It has been estimated that over the course of a 24 hour period nearly 1500 data items may be documented on a typical critical care patient and this volume of data is growing all the time. Historically, a subset of these data would have been transcribed into a paper-based record, which was not always legible, could sometimes go missing and was difficult to analyse. Under these circumstances the emergence of clinical information systems (CIS), computer-based systems that collect, store, manipulate and display clinical data, has been widely identified as offering significant benefits to healthcare delivery in critical care. While there is evidence that CIS can contribute to improvements in patient care, they also pose new challenges. A balanced appreciation of their capabilities and their effects on clinical work practices is therefore necessary.

The Components of a CIS

There is no universal model of a CIS and often the configuration in a specific critical care unit will reflect the particular combination of hardware and software installed locally. On the software side, early CIS in critical care tended to be bespoke developments, but now there is a wide range of commercial systems available, either as specialist modules of general hospital information systems, or standalone products designed specifically for intensive care settings. The former have the advantage of full integration with other specialisms, ensuring that critical care episodes are documented in a way that is consistent with practice elsewhere in the hospital, but may not be optimal for the particular requirements of critical care. The latter are likely to fit better with critical care practices, but may not exchange data seamlessly with other hospital systems. Hospital IT departments may also be reluctant to support more than one system.

Different systems vary too in the degree to which they can be customised to local requirements. Some offer relatively little flexibility and require adopting units to adapt themselves to the ways of working envisaged by the CIS designers. This simplifies CIS implementation and may therefore be attractive to hospital IT departments, but may provoke resistance from critical care staff who are required to adjust their work practices. At the other extreme, systems may be highly customisable, either by the vendor, or by the users. This is likely to make the system more attractive to clinical staff, for example, if displays can be made to appear similar to those of the paper or electronic systems the CIS replaces, but incurs additional costs and creates idiosyncratic systems, the integration of which with other services may be problematic. In practice, moreover, there will be limits to the extent to which systems can be customised and certain aspects of the CIS may be so deeply built into the design that changing them may be impractical. This can sometimes cause problems where CIS developed for one particular health system are imported to another. Nevertheless, even relatively superficial customisation, such as changing screen colours, adding a logo or presenting a familiar screen as the default may be significant in influencing user acceptance.

In terms of hardware, a CIS generally comprises a server, hosting the central database, and client computers, at the bedside or elsewhere, accessing the data over a network. Client computers may be desktops, laptops, tablets or other mobile devices. ‘Thin’ clients, which may run on relatively cheap and low powered devices, simply provide a view of data that are held and processed on the central server, while ‘thick’ clients, which require more powerful computers, carry out processing locally and only exchange data with the server. Thick clients may be more reliable than thin clients as they are not so vulnerable to network or server failures, but are more expensive to purchase and operate (Figure 55.1).

Figure 55.1 (a) Thin and (b) thick clients.

Although, in principle, a CIS integrates all patient data, in practice hardware constraints can mean that some elements of patient data may not always be incorporated. This may be due, for example, to the lack of compatible interfaces to enable critical care equipment to communicate with the CIS, or due to the resolution of screens being insufficient to display X-rays in sufficient detail. While the vision may be of a unified repository of all clinical data, therefore, this may not always be achieved. Nevertheless it is possible to identify a CIS as comprising a number of components that are present to a greater or lesser degree in most systems.

The core component of a CIS is an electronic medical record, a database containing a variety of forms of data about patients. Many of the data fields will be numeric, for example recording blood pressure or heart rate, and therefore readily capable of manipulation and analysis, but others may contain text, for example clinical notes, that are less easily analysed. There is a tendency for CIS to support numeric data entry in preference to free text, and thereby to promote a more systematic and standardised approach to recording clinical care. Textual data may be translated into numbers, for example by offering a pick list of common options to be selected from (option1, option2. … , optionn), while perhaps retaining the possibility of free text entry for non-standard cases. Electronic records also avoid problems of legibility of text entries and identify unambiguously who has written them (as individuals need to log in to the CIS to be able to enter data).

With data transferred directly from medical equipment to the CIS, transcription errors (which may be of the order of 20%) are eliminated and recording is no longer dependent on staff availability (although it may be necessary for them to validate the data occasionally to ensure that erroneous data do not contaminate the record). Numerical calculations, for example of fluid balances, are also automated, thus avoiding another potential source of errors. Once in the database, moreover, the data are permanently stored and immediately retrievable, not just at the location where they were entered. Data should therefore no longer get lost, and may be accessed away from the bedside at any time by any authorised person. With suitable secure networks, this access may potentially be from locations distant from the patient, creating the opportunity for remote supervision and teleconsultation. Remote access may also encourage the use of ‘sitting ward rounds’ in which staff meet in an office to review the patients’ CIS records rather than visit each bedside. Although this may allow for more focused discussion with fewer disruptions, it reduces interaction between clinicians and patients and bedside staff that may be significant for clinical decision making and patient welfare.

While the standardisation and centralisation of data and their easier availability may be a key feature of CIS, further advantages may be gained from functionality that makes use of the data. One area that has received particular attention is that of electronic prescribing (Figure 55.2), where the CIS may provide new functionality such as: presenting pre-filled order sets, for example of the drugs typically administered on postsurgery admission to critical care; restricting prescribed dosages within preset upper and lower bounds; or checking prescriptions against allergies or interactions with other medications. With remote access it is also possible for a pharmacist to review medication without needing to visit the bedside, or even the unit.

Figure 55.2 Electronic prescribing.

It is not just in prescribing that a CIS may support clinical practice. Some systems may include functionality to monitor the patient’s condition and treatment and alert clinicians to potentially significant correlations, or remind them when actions have not been taken. Many also support checklists to guide and improve care. Such clinical decision support is not a necessary feature of a CIS, however, and may be perceived by some clinicians as intruding on their autonomy. Care is also needed to ensure that alerts are relevant and not so frequent that they are ignored.

Another potential contribution of CIS to clinical practice is in the display of data in new ways. Some individuals or professional groups, for example, may prefer to view data graphically, while others may prefer to focus on specific values. A CIS can enable multiple views of the same data, matched to individuals’ preferences. The potential for immediate access to all a patient’s data, not just, as was the case with paper records, those from the past 24 hours, also enables clinical staff both to view trends in particular values over any period and to zoom in on specific data points anywhere in that time series. The CIS thus provides both additional dimensionality and granularity to the data available for clinical decision making. Different CIS vary, however, in the flexibility they offer to users in the ways that data are presented. Some have a relatively limited menu of standard views, while others give users a high degree of control both on how data are presented and on what particular data items are displayed. More advanced CIS may support dynamic views, allowing health professionals to bring together different blocks of data on the same screen as relevant for each individual patient.

Over time, the accumulation of historical data in a CIS database can become a significant resource for care quality improvement, audit and research. The standard tools provided with many CIS, however, do not always make it easy to extract data and this resource is often underused as clinical staff lack the time and expertise to undertake the task. Reuse of data may also be discouraged by time and resources required to ‘clean’ and/or process the data before they can be analysed. Although offering great potential, the contribution of CIS to data led healthcare practice and policy may therefore be less than some current proponents of ‘Big Data’ envisage.