Enter the CCG: on a real p souper

The work of the clinical informatician isn’t just about computers: anyone who tries to limit their work in this way will simply minimise its impact.

My function is much wider; integrating the work of the clinician with the five ‘p’s: the patient, the program, the people, the processes and the paper.

eDSM

Consider a recent project that I have been involved in; my clinical commissioning group’s introduction of SystmOne’s new method of sharing medical information — the Enhanced Data Sharing Model or eDSM – across its patch.  

We had to implement this: the Health and Social Care Information Centre had instructed TPP to deploy it instead of the previous point-to-point sharing model. It’s a better system; and it neatly lays the foundations for our CCG’s ‘SystmOne neighbourhood.’

eDSM itself is a neat, uncomplicated process which is switched on area by area. If a patient hasn’t yet made a consenting decision, a window automatically pops up so the practice can record his or her choices.

At each provider, the patient is then asked whether he or she wants to give that provider access to her pool of shared information; and whether they want that provider to share its notes on them with their pool.

Dead easy, you may think – but implementing it can go seriously wrong, as a number of practices and CCGs had previously discovered.

The difficulty with eDSM isn’t the software; or the counselling; or the recording of consent: the problem is doing all of them together, thoroughly, quickly and efficiently without interfering with the normal running of a practice.

The problem

Last spring, a group of practice managers emailed me, extremely worried about the impending switch-on of eDSM. They feared the time needed to explain and record patients’ consent would bring their practices to a shuddering halt.

Indeed, some practices in other areas had already experienced this. In desperation, some had even turned off the consenting mechanism altogether in order to restore their stability – although, inevitably, this had severely limited the sharing of patient information.

What were we to do?

Diagnosis comes before treatment

In IT, as with medicine, diagnosis comes before treatment. There were actually four separate problems or questions to work through.

What counselling do practices need to give? Must it be given by a clinician? How should the patient’s choice be recorded — is a signature needed? How could the practice perform complex counselling and consenting without interrupting its normal working?

The more I asked, the less certain I was of what the law actually required: there seemed as many different opinions as the number of people I consulted. Eventually – and in desperation – I asked our chief operating officer for permission to obtain a formal legal opinion.

Though entailing added expense, this request was probably the single best decision I’ve made as clinical lead: once we’d received the lawyer’s advice, everything fell neatly into place.

For commercial reasons, it’s not appropriate to share that opinion in detail outside the CCG, but simply having it meant we could now with confidence advise our practices over what they had to do (and, perhaps more importantly, what they didn’t need to worry about).

Teaching is central

Based on this advice, we wrote a simple SystmOne ‘Protocol’ to ask two additional questions and quickly record the answers.

From then on, practices wouldn’t need to go through the cumbersome mechanism of collecting signatures and scanning them in.

Next, we devised several alternative ways of carrying out the practical side of counselling and consenting.

Finally, we wrote comprehensive plans to teach practices what options they had, and how to fit it all together.

 Our plans included instruction manuals for practice staff; counselling materials for practices, either to use directly or to amend to suit their own needs; and technical guides about setting up and using the various available software options.

In particular, we showed practices how to disable the automatic popping-up of consent screens both when clinicians saw patients, and for practice staff not in direct contact with patients, while still making these screens available for those staff that needed them.

Then we set up workshops to teach these principles to all the practices in the CCG. I cleared my diary for the two days around switch-on, and we also had a local IT team on standby.

e-day

On the day of switch-on, everything went remarkably smoothly. There were just a handful of teething troubles, largely due to idiosyncrasies or omissions in individual practices’ existing IT configuration.

There were also a couple of unexpected behaviours in the software. (Rather logically, we couldn’t check this beforehand, simply because, with eDSM not switched on, the related screens were not active.)  We quickly devised workarounds, which we communicated to all practices.  

In the process we learned the importance of having a CCG-wide on-line forum for all practices’ IT problems, where anyone could raise a problem and receive advice in double-quick time. This proved invaluable.

Later problems

Even then the project wasn’t over. Consent under eDSM is at least a two-site affair: although the patient may have consented at the practice, if he or she hasn’t yet consented anywhere else (for instance with the community nurses or at casualty) then there is still no practical sharing of patient information.

We quickly discovered how easy it is for the inappropriate use of the consent mechanism at other providers to interfere with the overall process of information sharing.

So, I started liaising with these other providers to explain what eDSM was, how the patient would benefit from using it, and – crucially – how these organisations also needed to institute their own protocols for actively recording consent so their staff didn’t unintentionally interfere with sharing.

The post-mortem

Bearing in mind some of the problems we’d heard about from other areas, I’m convinced that the way we implemented the switch-on of eDSM resulted in minimal fuss and maximum benefit.

But note – hardly any of this work was related to the software itself: that aspect could be taught in ten minutes flat. The really important part was getting all the ‘p’s in place – the program, the patient, the paperwork, the practice, and the processes.

Indeed, a holistic approach to software deployment can make all the difference between success and failure.