CLIENTS

Data migration, matters

Bradford Teaching Hospitals NHS Foundation Trust has gone live with a Cerner Millennium electronic patient record in a joint deployment with Calderdale and Huddersfield NHS Foundation Trust. Data migration was a key part of the project, and one that other organisations can learn from, says chief information officer Cindy Fedell.

Data migration is a very important part of an electronic patient record deployment, but it’s easy for people to underestimate the work involved. The temptation is to think that you can push it through in a couple of weeks, but if it goes wrong it can cost you millions to put it right.

Every time it goes wrong, your go-live could be put back by three or four months and that’s all time that you have to pay for, even if your go-live goes well in the end. And we’ve all heard of trusts that are still struggling many months later.

That’s why it’s worth getting a data migration partner like Stalis. They can find out where you are before you start the migration testing cycle, so you are in a better position to begin. Also, you really need to sell this.

Sell might not be quite the right word, but you need to get across the idea that data quality is very important. It matters to patients. It’s not something that can just be left to the ‘back office’ – it needs to be owned by clinical teams.

Pick the right partner – and get ahead
We built data migration into the contract. We knew we needed to migrate data and we knew that our old patient administration system was very flexible, so we were likely to have some data quality issues.

Also, every trust we went to had those data migration horror stories, and we didn’t want to write one ourselves! So, we did our homework. We looked at two suppliers, and then we picked Stalis, who were contracted to Cerner.

When it came to choosing a supplier, we were looking for two things. The first was very robust model that had been used in other Cerner trusts. The second was the team. We wanted a team that was experienced and that could dedicate time to us. We wanted a team to see us through.

In practical terms, though, we didn’t start thinking about data quality until much later. If I was going to do one thing differently now, I would start much earlier.

Once you start the implementation project you are incurring costs every day. We knew we were going to have data quality issues, and if we had addressed some of them earlier, we could have got ahead.

The problem is that’s a hard sell; you are spending money before you start spending money! But if you know you are going to begin your project in three months, and you spend that time doing data analytics and cleansing, you will be in a better state when you begin.

Stats don’t have to be scary
When we did start, Stalis came in and took the data from our existing system and ran it through their predictive tool. It says: ‘you have so many people without a postcode’, or ‘you have so many people for which it does not look as if the pathway is complete’.

That’s the bit that can really bite you: trusts that don’t get this right can do their migration, and then find out that they have lots of patients with incomplete pathways. That means they have no idea who is waiting, or for how long, so they can’t do their RTT [referral to treatment time] reporting.
Armed with the predictive information, you can start cleaning the data. Then you do several trial runs. You push information into the new software, to make sure it does not throw up anything new. That is why we wanted to go with Stalis; they understand Cerner very well.

We did four runs, and every time it went better. By the time we did the fourth run, the stats were really, really nice. But we might have got the number down by doing more work up front.

Go-live can go well
When it comes to go-live, you do a bulk load of data that is older so it isn’t changing because it takes a week or so to load. And then you do a delta load, which takes a couple of days for the more recent data. We started in A&E. We switched off the old system on Friday afternoon, and then we switched on the new system at about 5am on Sunday. Then we did the wards. It was fine. In fact, it was good.

The data statistics were stunning: up above 99% everywhere. We heard Stalis were a bit disappointed they weren’t even better, but the point is that the gap was manageable; because you have to manually enter whatever didn’t automatically migrate. We were very, very happy.

Not a back office project
We only migrated the minimum. We transferred our master patient index, which was 1.1 million records of unique people, and 1.7 million historic appointments and admissions. That’s for a population of 500,000 people.

Bradford Teaching Hospitals NHS Foundation Trust is classed as a large trust, but not as large as others. A lot of trusts are going to have a lot of records to get across. So, if I was going to give people starting on EPR projects some advice, it would be: plan for the worst! And start early.

Also, make sure this is high on everybody’s agenda. In an EPR project, you report on design and build status. You need to add in quality, so everybody understands the importance of it. This is a huge financial risk, but it’s also a huge clinical risk.

When you are dealing with an EPR, you are dealing with clinical information. Getting this wrong has an impact on RTT and outpatient appointments. That is scary. Potentially, it’s a big reputational hit. So, you can’t just think of this as a data migration or even a data quality exercise.

It is clinical information, it is about patients and how they are treated. You need to put resources into doing this, and into making sure that you do it right.

Download case study

Dame Fiona Caldicott’s review of data security, consent and opt-outs, acknowledges the potential for data to transform the way health and care is delivered, but it also clearly identifies concerns – both inside, and outside the NHS – as to how this data is stored, managed and accessed.
It is a truism that a clinician having access to the right information at the right time – without impediment – will make better decisions. In the past, with this firmly in mind, IT systems have been procured and implemented, with varying degrees of success.
In May 2016, at West Suffolk, we pushed the button on a massive transfer of our patient administration system and referral to treatment (RTT) data from our existing legacy system to a new electronic patient record (EPR).
We all understood the risk of getting this wrong. Data supports our hospital staff in managing patients through their care pathways as safely and efficiently as possible. If we can’t track patients through pathways, we might miss them. Our ambition was to improve the quality of this data as we transferred it over. There was an expectation that we would get this right – from board level to the project team.

Define the scope
Moving to a new IT system is a little bit like moving home. You want to ensure that everything great about your old home is kept and transfers to the new one, and is roughly in the same place. Some boxes might be in the wrong rooms, but everything that is important and essential to you moves with you. It’s a simplistic comparison, but it’s apt.
At West Suffolk we were moving much more than a house, we were transferring a huge amount of sensitive data from over 250,000 of our patients seamlessly from our 20-year-old system to a new implementation.
This information needed to be packaged, processed and cleansed before it could be moved. Once moved, it needed to be immediately accessible for our clinicians and administrative staff, whenever and wherever they needed it. And we didn’t need clinicians to tell us that this had to be done with as little downtime or interruption as possible.
Accurate scoping helps to reduce threats. With a clear understanding of the challenge, plans can be drawn up, risks mitigated and fears allayed.

Ask the experts
Moving house is never as straightforward as you hope. You need to package up and protect your belongings, load and transfer them to the new place, unpack them and ensure they’re all there. Like most things, it’s often a lot easier if you use a professional – but in an effort to save money (or face) – many of us choose to go it alone.
The reason is because it’s always difficult – as individuals and as organisations – to recognise gaps in our knowledge and potential areas of weakness. It became clear when scoping the project that our in-house expertise needed to be augmented by that of specialists to boost our capacity and capability.
We worked with Stalis, a specialised data management partner, to complete specific tasks around the migration and cleansing of our data. Working with a partner helped bring structure, specialist tools and techniques as well as knowledge and expertise, all of which helped us to avoid common mistakes that could have dogged our implementation.

A culture of involvement
Central to the success of any change process is convincing those involved and affected by that change that the new system or process will be better than that it replaces. While our existing system may have been almost two decades old, it didn’t mean that staff were ready to change.
Beyond the technical considerations, we needed to persuade staff and clinicians that this wasn’t an IT project by the IT department, but an organisation-wide, clinically-led change project with improved patient care as the focus. We united around the shared belief that the safe transfer of essential data to a new system was going to help us improve patient care.

Central to this is the recognition that high-quality data contributes to high-quality care. The reason is that only by having unimpeded, quick and accurate patient information can we as clinicians truly make the best possible medical decisions on as part of our patient’s care.

The fragmented, ‘best-of-breed’ system approach the trust had previously adopted resulted in organisational information silos. There is no suggestion that this resulted in any issues, but having this all in one place was widely considered to be the way forward for the trust.
While the aspiration for such a system prevailed, the complexity of it, which included managing the data, remained something of a mystery to our clinicians. But they do appreciate that we didn’t screw it up.
In the end, our engagement with clinicians was about focusing on outcomes. We asked what they wanted, and used that as our basis for developing and implementing the system.

Delivering results
Earlier this year we got the keys to the front door and moved in – transferring a substantial amount of data between our systems, going live with the EPR and pulling the plug on the old one. It was a nervous time, but we were confident that our comprehensive data de-cluttering exercise would help to ensure only the necessary information transferred over.
Co-designing the new system allowed us to shoulder the burden from clinicians, reducing the anxieties and reassuring them their requirements would be reflected. Knowing that we understood this means that our clinicians do not need to focus on the system, but can concentrate on patients – which is what we all want and need them to do.

Download case study