Ade Memoire

Recently, there has been a lot of interest in e-prescribing. The reason is obvious: a lot of the Safer Hospitals, Safer Wards: Technology Fund activity has been focussed on this.

It’s generally acknowledged that e-prescribing is not easy, whether you do it as part of an incremental, ‘best of breed’ electronic patient record strategy, or as part of an ‘all in one’ implementation.

But I’d like to raise a couple of issues that IT departments, in particular, need to think about. On the spectrum of IT systems, e-pescribing is much more a clinical system than, say, a pathology ordering system. And the more clinical the IT system, the more critical the support becomes.

Rethinking IT support for 24/7 working

One of the many things those who are thinking of doing e-prescribing will need to take account of is the 24×7 aspect of it. This means having a team available to deal with problems as they arise, backed up by 24 hour supplier contracts.

With a best of breed EPR approach, like the one that University Hospital Southampton NHS Foundation Trust has taken, you will inevitably end up with a number of specialist teams covering different hours in different ways.

We have core IT teams for the network, databases, servers and so on. Then we have a patient administration system, emergency department and electronic patient record team, a digital imaging (picture archiving and communications and radiology information system) team, a pathology system team, and an e-prescribing team.

One benefit of the larger system approach is that, by default, you end up with fewer of these teams from the outset. But a key challenge to the rest of us is to understand when it is right to start bringing certain components together.

This will provide a more robust service whilst also potentially saving money. At Southampton, though, the e-prescribing team is based in pharmacy, and PACS in the radiology department.

Those who work in the systems teams also carry out important functions within those departments, where they utilise their specialist knowledge.

Would creating a central team dilute this too much? Maybe; but we cannot keep growing the number of specialist teams – and next in line for us is a critical care system across multiple units that will cover around 100 beds.

In addition, as we keep hearing, the hospital has to provide the same service over a seven day-a-week period, and IT support is going to have to reflect that.

We cannot carry significantly more real risk in the out-of-hours function. Ultimately, I think we are going to have to improve our analysis of systems risks that surround us at the same time as we improve the level of functionality of the systems themselves.

Like most things we deal with, such as balancing the right type of device with information governance, infection control and usability considerations, we will have to make some uncomfortable compromises for the greater good.

Staff accreditation and training

A particular operational problem is how to deal with temporary staff and locums as they arrive on site to cover a shift.

Naturally, anonymous access to clinical applications cannot be allowed for a number of reasons. Primarily, we need to be sure that whoever is logged as looking at a record is indeed that person.

Users also have to be sure that their interventions have been recognised and that the actions of others have not somehow been registered in their name – for example through accounts being left logged-in or through password sharing.

We also need to know that whoever has access to a system is trained and understands how to operate it. However, a whole suite of clinical applications, including discharge summary, drug and pathology test orders, will take many hours to train fully.

For a locum session, there clearly is not enough time for this. Therefore, we are back in that world of compromise.

Matching one to the other

There is clearly a trade-off between the risk posed by users who are not “fully” trained, and the risk of them not being able to do their job at all because they cannot access a system because they lack the “full” training.

We regard the primary risk as a potential lack of staff on the wards, so we do not believe it is possible to say “you are not allowed to work on there if you are not fully trained in the IT systems.”

Even if we did, it would become inevitable that local needs would push some users into logging-in and leaving their sessions open for others to use, or into sharing their passwords.

The team at Southampton has therefore been considering what level of expertise you really need in a system in order to use it at all, and whether there are associated access permissions for a particular module or level of training.

The learning associated with different modules will, of course, be e-learning and be available on the internet wherever possible.

The trickier issue is the levels of access available in any system, as these do not always present themselves in the ways you would wish to set up users.

For instance, at a very basic level there is an option to ‘view only’ (note this is not a specific reference to the e-prescribing system that we use, which is JAC, but a wider comment on the levels we can grant users of our various systems).

This would enable a user to inform themselves; but in many cases, ‘view only’ access would not be enough to enable them to perform their role.

We do have e-learning modules for e-prescribing, and it has been agreed with our nursing agencies that all agency staff will complete their training – which is available on the internet, outside the trust – prior to starting a shift.

This has worked well. However, the approach has not been so successful with locum doctors. With the best will in the world, we still end up with people arriving to work that we have not seen before.

Therefore, there will always be an element of local training with any system, and we’ve found that locum doctors will tend to need to complete this once they are at the trust.

No easy solutions

Now, it will be easy for those who have never done any of this – or only done it in a small way – to say that we just need to sort ourselves out; we need to recognise the support in the business case, or whatever.

But these are real, practical issues that those who are embarking on e-prescribing and similar projects will have to confront at the grass roots level.

There is no utopian “know all, train all” support available; and even if money were no object this would still be difficult.

When I was a kid, I used to watch Joe 90, and he had a machine that he could sit in it for a minute and come out as a fighter pilot [or a doctor ?].

What we need is one of those, really. But for now, we are going to have to do the usual things – recognise the problem, analyse and scope it, perform risk analysis and options appraisal, and come out with a somewhat imperfect best fit.

Adrian Byrne

Adrian – Ade – Byrne is director of IM&T at University Hospital Southampton NHS Foundation Trust which, he says, has been working on its IT environment for 15 years.

On his LinkedIn profile, he says its aim is to “build an electronic patient record with full decision support, sharing data across disparate, so-called best of breed systems.” The trust is also developing a patient record and services, built on Microsoft HealthVault.