Introduction
In recent times, there has been renewed interest in the UK from Health Care Entities (HCEs) in the purchase and deployment of Anaesthesia Information Management Systems (AIMS). The drivers of this change are a topic for debate, but after the demise of the Connecting for Health programme in NHS England over a decade ago, HCEs have had greater freedom to make purchasing decisions on applications and IT infrastructure that suit their local needs, rather than top-down impositions from a national programme. This has resulted in a more mixed economy of systems than would otherwise have been the case, had the national IT programme been a success.
Other drivers may include the capability of point-of-care devices (PoCDs) to communicate data in a structured format such as HL7-FHIR, an international standard that has a comprehensive implementation guide, and is popular with developers. In the past, medical device communication was often based on rudimentary standards such as RS-232, a generic communications protocol that was adapted for medical devices.
A further boost has come in the form of mature, reliable wireless communication standards suitable for use in clinical environments. Even the revolution in flat screen LED and touchscreen technology has played a role in encouraging the spread of information management systems. The traditional anaesthesia monitoring system, designed to record and display physiological data from the patient in real-time is often accompanied by a separate screen for viewing and recording additional data relevant to the perioperative care episode.
In spite of these developments, there is anecdotal evidence that the increased prevalence of AIMS in the immediate theatre environment isn’t having the desired positive impact on care that would be expected. This document discusses the challenges for implementers of AIMS and makes suggestions for how they can be overcome.
What’s in an AIM?
A good place to begin the discussion of the challenges is to outline the scope of AIMS. In general terms, the broader the scope of an application, the more complex its UI/UX becomes. Another way of saying this is that the more ‘bits’ you add on to an application, the harder it becomes to use it and the more likely your UI will be cluttered and unwieldy. Compare this to (say) a simple application that performs one task well, such as a dose calculator or one-page assessment form.
Considering the scope of an AIMS, the following list describes the main items and data points that are likely to be included:
- Patient Demographics (name, identifier, date of birth, gender/pronouns)
- Surgical specialty, proposed operation, NCEPOD category
- Pre-assessment information
- Medical and Anaesthetic History
- Risks, Alerts, Allergies and Intolerances
- ASA grade
- Medication Summary
- Baseline Vital Signs
- Laboratory investigations
- Transfusion plan
- Equipment plan
- Premedication
- Anaesthetic Plan including shared decision making.
- Actors involved in the care episode, their grade and supervision level
- Administrative data from the Theatre Management System (TMS)
- Pre-op ward or care area
- Intra-op care setting (e.g. Theatre #n)
- Surgical actors – grade and named consultant
- Details of the intraoperative episode
- Preparation and positioning
- Regional and/or Neuraxial Blocks
- Vascular Access
- Specialised procedures (e.g. cardiac output estimation)
- Induction and Maintenance
- Medication – drug names, routes, doses
- Devices used, their metrics and settings
- airway – type, size, procedural details e.g. intubation grade
- breathing system
- assisted ventilation
- TIVA/TCI – devices, regimens
- Physiological Monitoring
- Fluid balance
- Post-anaesthesia care
- Fluid prescription
- Oxygen
- Analgesia
- Other medications e.g. anti-emetic, thromboprophylaxis
- Care destination and level
The benefits of AIMS
- Safety
- time spent on direct care rather than documentation
- decision support
- Economic
- track costs and activity more effectively
- Better data quality and more accurate coding
- Promotes audit and quality improvement
- Legal aspects of improved fidelity, legibility and accuracy of data
The benefits of AIMS can also be explored through typical use cases for the records they produce. It can be helpful to think of the application as being separate from the data it creates. In other words, think of the application as being the ‘front’ of the AIMS, displaying data and interacting with the user through the User Interface (UI), whilst in the background, collecting and storing data from PoCDs. Depending on how the AIMS is configured, there may be a wealth of data points in the record, not all of which are surfaced through the UI.
Use Case 1
A typical care record for an anaesthetic episode where the purpose is to display data from devices in real time, allow the clinician to record events and if necessary, review trends and other data points relevant to this episode. At the end of the case, the clinician checks and attests that the data is accurate before closing the record. The granularity of this ‘live’ record is greater than would be expected in a summary, but still doesn’t include every recorded data point that exists. Some information is hidden for ease of display.
Use Case 2
If, at a later date, another clinician involved in the patient’s care requires the record of a previous episode, this should be possible. Rather than retrieve the entire record, there should be an option for a ‘summary view’ that highlights the key elements, in particular whether there were any adverse events.
Use Case 3
In the situation where an incident or adverse event has occurred, there is likely to be a requirement for the full detailed record to be surfaced via the application. This would include every data point, including its provenance. For example, which device was recording heart rate, what was the result of the pre-use check of the anaesthesia workstation, etc.
Barriers and Dis-benefits
The likeliest barrier to the purchase and implementation of AIMS is cost. Not only is the initial outlay significant, the procurement will likely include implementation and training costs, support agreements, product lifecycle licensing agreements, hardware and networking costs.
HCEs that have AIMS tend to be the larger centres with greater budget flexibility.
Demonstrating value or RoI is challenging, as many aspects of AIMS are replacements for (or extensions to) existing paper processes. Changing to a digital model can bring ‘soft’ benefits that are hard to quantify. For instance, how many adverse incidents are prevented by the automated logging of data by the software, rather than by a clinician, by hand? It can be argued that automation frees the clinician to observe the patient more closely. Equally, it can be argued that making manual recordings focuses the clinician on the patient, at times when their attention may be elsewhere.
AIMS enable many more data points to be collected per case, and the data points may be more structured than a paper record. A greater level of detail is valuable for the analysis of adverse events, especially when a concurrent automated record of the physiological variables is available. Unfortunately the additional data points come at a cost – more time spent logging events and procedures into an application and less time focussing on the patient and the progress of surgery.
There’s a possibility that clinicians may get overloaded by software that presents too many data points, and makes too many requests for data input at key moments in the care episode. Good UI/UX design can overcome some of these challenges but the principles outlined in the much-shared article “Why Doctors Hate Their Computers” are pertinent to this environment too.
Unpicking these arguments in favour of and against AIMS requires carefully designed controlled studies of human factors in the operating theatre.
One AIMS to Rule Them All
Over at SCATA, a small team are working on an implementation guide in HL7-FHIR for a structured anaesthetic care record, focussing initially on the intraoperative phase. If successful, the guide will allow developers to implement AIMS with a standard information model (in FHIR) that will solve many of the issues with current AIMS, especially semantic interoperability i.e. the ability of systems to exchange records seamlessly.
Alongside this work, there is an embryonic demonstrator project that is designed to assist developers in either building a new FHIR-standards-based record, or extending their existing AIMS to support creation and export of a FHIR-based record. Ultimately, the aim (pun intended) is for AIMS to be supported globally by an internationally-agreed standard FHIR-based information model which is open and non-proprietary.