A recent discussion between colleagues from the anaesthetic community in the UK centred on what can best be described as the granularity of an anaesthetic record. Put simply, is there a need to include every possible detail of every drug, procedure, device and event in the record, or is it sufficient to use some time-honoured abbreviations and shorthand, as alluded to by the title of this blog?
Can information be omitted because its inclusion is inferred, in some instances? For example, when performing a neuraxial block, a clinician may record the following in relation to infiltration of the skin with a local anaesthetic agent:
Nothing – the skin infiltration procedure is inferred
LA to skin
Lidocaine to skin
1% lidocaine to skin
2ml of 1% lidocaine to skin
2ml of 1% lidocaine to skin, 23g needle
We can see a step-wise increase in the amount of detail recorded for this brief and very simple procedure.
[For the non-clinicians, the procedure is used to provide analgesia (pain relief) at the skin entry point, prior to the insertion of a larger gauge needle.]
How much detail is sufficient and under what circumstances would more detail be warranted? Should the batch numbers of both the drug and the needle be recorded? Arguments in favour of the ‘maximum detail’ approach may point toward patient safety, drug and equipment inventories, cost control and the medico-legal aspects of care, should there be an adverse event.
Most of us could probably agree that maximal detail is desirable, but it has to be balanced with what is practical in the care setting. Time spent jotting down the minutiae is time that could (or should) be spent observing the patient.
A possible compromise is to use technology to assist with the record keeping. Two options present themselves:
Assistive features for data input in a digital care record system or AIMS
A speech interface for data input to same
Looking at option 1 in more detail, ideally the UI would present a touch-screen interface where the user can select a pre-defined procedure (such as a neuraxial block). The application should have the ability to create, store and switch rapidly between user profiles, so that the UI recognises and adapts to the clinician interacting with it. If a clinician has previously set up a template for a neuraxial block, then in theory, a record containing the maximum detail could be created in just one or two button touches on the screen.
The option to edit the template is essential, for those days when the 23g needle supply has run dry, and a 25g is used instead.
Next to the screen there may be a QR code (or barcode) scanner that can scan and identify the local anaesthetic agent and the needle. One touch to confirm each, and both drug and device are recorded.
Option 2 is just as flexible, and with modern speech and command-based interfaces, a UI could (also in theory) accept voice commands. For example:
[Command Word] Record the administration of 2ml 1% lidocaine to the skin using a 25 gauge needle
This option is being explored in a discussion paper, with a view to building a prototype for proof-of-concept. A subtle adaptation would be for the command-word to identify the clinician, so that they don’t have to announce themselves each time to attest a new record entry.
Scaling Up The Detail
I chose a very short, minor procedure to illustrate the point about potential benefits of novel interfaces to digital records. Taken at scale, the time and effort required to record larger, more complex procedures could be reduced drastically, with many secondary benefits to safety and quality improvement.
If you’re interested in helping to build a PoC prototype, or to join the group over at SCATA looking at speech interfaces to AIMS, please get in touch.
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)
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
figure 1 UK National Anaesthesia Record Project Summary Schematic
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.
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.
