Hi there ; Marcus has just introduced me to this place, so I’ll open with i) an introduction of myself and ii) a wee blog of the project I brought to NHS Hack Day last September.
I’m Adrian, I’m a 17 year veteran of the healthcare IT scene after a brief tour in the clinical trenches as a junior doctor, I’ve worked for both the private and public sector at ascribe, HSCIC and NantHealth, and my obsessions are mostly to do with making electronic health records “no worse than paper”, and version control systems.
This project was inspired by an excellent lecture by one Professor Thimbleby entitled Designing IT to make healthcare safer which is well worth 40 minutes of your time, although a summary of some of the points it makes are included below.
The Problem With Infusion Pumps
A lot of the talk focuses on how horrible infusion pumps are and how this causes medical errors which in some cases are fatal.
Horrible Maths
Calculating infusion rates isn’t fun, especially when you’re tired. You’re likely to have to deal with more than one physical unit (e.g. calculating how many ml/min you need to give of a mg/litre solution )to achieve a dose of mg/kg in your patient). You’re going to have to cope with decimal points and exponents of 10.
Horrible Labels
This is the first label I found when doing a search for infusion labels.
It seems to have a fairly complex infusion regime, so not only are there at least 15 numbers to choose from on this label, you have 5 opportunities to pick the wrong one to feed into this pump over the course of the infusion (and that includes opportunities to be so busy that you forget to change the rate).
Prof. Thimblby ably illustrates this with a real-world example that had fatal consequences.
Horrible UI
Firstly you might have to deal with a calculator to do the horrible maths above. Calculators, and calculator apps, are rubbish, no matter how much Windows 10 insists that the calculator program is now a “Trusted Windows App Store” app.
Calculator UI is a paragon of consistency and ease-of-use next to the UI on infusion pumps though.
Here’s a search for images of infusion pumps. We have pumps with numbers, no numbers, full colour high res LCD displays, monochrome hi-res displays, 7-segment LED displays, one display, two displays, three displays, dials and buttons ; as few as 6 buttons, as many as 32 buttons ; there are a lot of different UIs.
And they don’t just differ in terms of looks - some of them have completely different behaviour for similar key sequences. Even outwardly similar models can be running vastly different hardware and firmware inside and consequently have different operational quirks.
The Solution?
On the back of this, the project I brought to NHS Hack Day the notion that you could
- Eliminate as much human error as possible by
- Get rid of the need for a human to do maths
- Get rid of the need for a human to read the label
- Get rid of the need for a human to program the pump
Maths
Use a program, preferably the electronic prescribing system being used, to work out that one critical number - how much of a given fluid to squeeze into a patient per minute.
Label & Programming
Reading the label is clearly a source of error, as the human has to translate the information on the label into a mental model of how fast the infusion should go.
Programming the pump should not be done over the network. Why?
- Where possible, I prefer that medical devices that can kill you, not be available to hackers.
- The medicine doesn’t get delivered over the network - ideally the program and the medicine should arrive together to prevent mixups.
How to make the medicine and the program arrive at the same time? Put the program (or at least, it’s inputs) on the label. I’ve been doing healthcare IT a long time, so 15 years ago I was researching whether PDF 147 2-dimensional barcodes were suitable for medication labels. Today, there’s a clear winner in the 2D barcode format department, and that’s QR codes. Not only will a computer not get confused about what the QR code says, it can’t get confused over which buttons to push to represent that state on the pump.
Hardware
For this project I chose…
- A Raspberry Pi Model 2B
- The camera module for the above (with no IR filter)
- A Display-O-Tron HAT
Why Pi?
The Pi provides a small, cheap, powerful computer, that runs Linux and thus permits a wide variety of development to be done on it. It also boasts a lot of interfaces for connecting various hardware devices, including a camera port. It’s more than powerful enough to decode QR.
Camera
The camera is in most respects a normal webcam, but the lack of an IR filter was felt to be a useful feature in a clinical setting, where using visible light to illuminate a label might disturb patients. An infra-red lamp placed on the device would permit labels to be read without waking people up.
Display-O-Tron
While the Pi can support much more capable displays, including full-HD touchscreens, this display was selected because it was more like some of the more basic displays currently in use on existing infusion pumps. In addition to a 3x16 character dot matrix LCD, it sports
- 6 capacitive touch buttons
- A 6 element LED bar graph
- A backlight that you can set to any colour
As well as approximating primitive hardware better, it was also easier to program than developing a full-HD touchscreen app. However, given the very limited screen space on this device, it might be more appropriate to switch to a larger screen.
Software
Label Maker
For the purposes of the prototype, my collaborator Kat Hobdell wrote a basic application in C# that took a restricted set of inputs and wrote a QR code as an image file.
Label Format
For the sake of simplicity, we chose the standard Python config file format for a data format - this would be recognizable to many people as being very similar to an INI file.
The default fields we started with were
- PatientName
- PatientId
- InfusionProduct
- BagVolume
- RatePerMinute
So a basic label looked like this :
[DEFAULT] PatientName: Kat PatientId: 213456 InfusionProduct: Potassium Chloride 0.15% and Sodium Chloride 0.9% Infusion 1000ml BagVolume: 1000 RatePerMinute: 20
And rendered to this QR code
For the Infliximab example earlier, you’d want something a bit more complex. The danger of this is that a QR code expands somewhat the more data you put in it - this might be a use-case for putting the device on the network, and have the QR code a mere link to another system that provides a more complex infusion data packet.
Device Software
The device software was written in Python (hence the use of the ConfigParser format) and uses a basic State Machine pattern :
- Wait
- The program waits for input
- The program waits for input
- Scan
- The program has been told to look for a QR code
- The program has been told to look for a QR code
- Verify
- The program prompts the user to verify that the patient, etc, are correct
- The program prompts the user to verify that the patient, etc, are correct
- Infusion
- The program tells you that it’s infusing and cycles the 6-segment LED bar graph at a speed proportional to the rate
- The program tells you that it’s infusing and cycles the 6-segment LED bar graph at a speed proportional to the rate
In the Infusion state, you can also adjust the rate up and down with the contact buttons beside the display (the ability to do this would obviously depend on the infusion prescription).
You can find the source code on GitHub