From the consulting room on EMIS Web

This article first appeared on Microsoft’s NHS Resource Centre on 08 February 2011 (site now defunct; ).

With the focus of healthcare IT now on local solutions rather than big bangs, GP Neil Paul uncovers some potential teething problems with the local implementation of EMIS Web.

“Never be afraid to invest in IT – it always pays in the end” was a piece of advice that I was given by the - alas now deceased - finance director of a large, bluechip plc.

He went on to qualify the statement. IT should always solve a problem you have and make your life easier; not give you more hassles to deal with in the long run.

I was reminded of these wise words this week when several people from local practices contacted me in a mild panic about a rumour they had heard about EMIS Web.

Entered in the list

All the practices in my consortium and the neighbouring one use EMIS. For some time now, we have understood that we will be migrating to the company’s ‘next generation’ system, EMIS Web.

We have attended meetings and conferences and asked questions. “Will it work with ScriptSwitch”, “Will it work with ICE desktop?”, “Will it work with our touchscreens?”, “How resilient is it?”, “Do we need to upgrade the PCs?”

People have watched demos and been moderately impressed, if never amazed. It has allowed us to get our local A&E shared health record project working, and promises more to come.

However, last week, a rumour went round: “it won’t allow local codes”. One of the people who contacted me had put a post on the EMIS List, an online forum where people can share information and experts can help novices, asking this question - and was disturbed by the answers.

Let me just explain what we mean. Most IT folk in healthcare know about Read Codes and SNOMED Codes. and the fact that some codes are used for diagnoses, some are used for history items (eg: ‘smoker’), some are used for investigations and some are used for administrative purposes.

Now, there are lots of problems with Read Codes, but I agree with the majority that if there is a Read Code you should use it rather than making stuff up. One problem is that if you use a home-created code rather than a national code; then when notes transfer across to another practice, things will go crazy. It’s rather like hoping that you can move to another country and somehow keep the same telephone number: it just won’t work.

Read my lips: no new codes

So why create local codes in the first place? Well, because there are plenty of things a practice does administratively that local codes can help with. It’s often useful to be able to put a code into somebody’s notes so you can find patients with that code – or, more often, without it.

As an example, we run a vasectomy service and we create entries like • ‘vasectomy op done by us’ • ‘1st sample received’ • ‘2nd sample received’ • ‘letter to patient re: results sent’ etc. … into the notes as codes.

There are no Read Codes that signify exactly these facts. Borrowing a code that doesn’t mean exactly what you want is going to complicate a patient’s notes when they move to another practice. Yet for us, it is very useful to be able to search for all the patients for whom we have done a vasectomy and haven’t had a 2nd sample by the required time after the procedure.

We also do research work and being able to code the visits, the interventions and some of the other admin work related to it is very useful.

Going back to the EMIS List answers, all the respondents agreed that EMIS Web doesn’t allow home-produced codes. One reply took the view that only Read Codes should ever be used, and that we wouldn’t be having this problem if we only stuck to them.

 I didn’t find this very helpful from a clinical-only point of view, and it seems to follow the line of thought which dictates that we have to adjust the way we work to fit into the way the IT does.

Another respondent came up with the good suggestion of using associate codes. In EMIS LV, these are effectively locally added qualifiers to existing Read codes. It means you follow the edict of only using Read Codes but can add extra information.

Our most commonly used example is referral codes. We use the right national referral code but we add a bundle of additional information to it, covering data such as who did the referral, how urgent it was and so forth. Alas, the next post on the list stated that associate codes aren’t in EMIS Web either.

So: there is now a slight panic here, as well, since this is how my practice has been tracking referral activity with a view to reducing it where possible. If you don’t already know, the only way GP commissioning is going to succeed is by getting a handle on referrals.

Tips, please

If we move to EMIS Web as a practice, my reception team is going to have to learn a completely new system. My patients will have to get used to a different form of online appointment (we use FrontDesk at the moment) and a different touch-screen check-in. And my admin team will have to find a completely new way of working.

Is this sounding like customer-driven IT change?

What do I say to those practices that contacted me who are going to be in the same or similar positions? It might be nice to hear from practices that have gone first: how did you find it?

About the author:

 Dr Neil Paul is a full time partner at Sandbach GPs, a large (21,000 patient) practice in a semi rural Cheshire. Until recently, he was on the PEC of Central and East Cheshire Primary Care Trust, with responsibility for Urgent Care and IT.

He is now on a journey into the unknown. He is on the board of his local consortium, one of many on a pilot leadership programme, and looking at provider opportunities. He recently set up a successful primary care clinical trials unit and is involved in several exciting IT projects.

Tags: dr neil paul, emis web