How long do you think it should take to print a prescription? 30 seconds? One minute? Two minutes? How about eight minutes?
To be clear, I’m not talking about from the moment you think about doing it. I’m not talking about a clever way of entering the right drug or right dose. I’m talking about from the moment you press ‘print’ until the piece of paper pops out of your printer.
Well, I’m lucky. For me, that process is measured on seconds. However, a colleague recently mentioned to me that it was taking up to eight minutes in her room – and did I think this was a bit long?
Now let me just put this in context. GP appointments are usually ten minutes long. We do 18 appointments in a surgery. If a prescription is taking eight minutes, that’s a nightmare. Unsurprisingly, my colleague was quite stressed.
Performance measurement
People’s expectations amaze me. Printing a prescription had been taking my colleague this long for a few days.
However, because she is a bit of a technophobe and not very experienced in IT she hadn’t immediately recognised this as a problem or called our local helpdesk (who on the whole are quite good when there is a specific issue) to fix it.
Also, whenever she complained to a partner or colleague about her slow PC, they sympathised and said theirs was slow too. Until the prescription thing gave her a time to focus on, she had no way of comparing her set up with any other.
An interesting parallel was when Choose and Book was first introduced. We were convinced it took longer to start in our surgery than in others we talked to. Yet proving this was ridiculously difficult.
Everybody said they found Choose and Book slow as well; but couldn’t tell us whether that meant it took them 20 seconds or the 1 minute 40 it took us.
So I’ve been thinking about benchmarking. If computers are clever why can’t they tell you and the IT support people when they are performing badly?
Scripting a response
A simple way of doing this might be to write some standard scripts and have a rough idea of how long they take. A helpdesk might try a few out when testing your machine.
However, this is very labour intensive. A more automated way (and forgive me if I’m reinventing the wheel here) is to use logs.
When I taught myself to program the iPhone, one of the tricks I used was at key stages in the code was to write an entry to a central log.
This would help me know where I was up to and which procedure was being called; particularly helpful if there was a bug. Why doesn’t each piece of software write log entries to a common log and time stamp them?
Most of the software we use – apart from Office – is custom built, so it shouldn’t be too hard to introduce this. Program loading, printing, executing a whole range of features might be logged this way; an entry before and after an action would allow the time taken to do it to be calculated from the difference between them.
These log entries don’t even have to be made locally – they could be sent to a server. A clear picture of performance per desktop could be built up.
Early warnings of bugs and computer problems could be auto detected. Imagine a world where the IT department rang you and said we’ve noticed your computer is running a little slow and we would like to fix it. I know it’s not easy, but try!
I can even see a reason why a suppler like EMIS might want to introduce this. They might sell more computers if they tell the individual user on their home page how there performance varies from the mean. We talk about patient power driving healthcare – how about user power driving IT?
Geekbench mark your computer
This might take some time, though. Simple benchmarking tools already exist that measure the raw power of a computer. They all have faults and they don’t necessarily measure real world performance.
However, you can get a raw look. One benchmark I’ve come across is Geekbench. Feel free to post your scores as comments to this article.
I was wondering if eHealth Insider might give a small prize to the owner of the fastest and slowest machines in the NHS [We’ve some beer mats and post-it notes left over from EHI Live 2010: otherwise the glory will have to be enough – Ed].