Creating a Successful Healthcare Data Migration
Expert Interview with Ali McGuckin
Healthcare Data Migration projects have to be one of the most critical sectors for data migration practitioners. If you get it wrong, there are potentially life-changing implications for the true stakeholders of the data, the patients and physicians who depend on the data.
I recently took the opportunity to spend some time with one of the most experienced practitioners I've met in the Healthcare Data Migration sector, Ali McGuckin, to learn her practical approach.
Ali has been a long-time expert in the field and has recently set up her own consulting practice so I quizzed her on what it takes to create a successful outcome for all concerned in a Healthcare Data Migration project.
Dylan Jones: What is your background Ali – how did you get started in the profession?
Ali McGuckin: My first career was as a clinical specialist (radiographer) in the NHS. After managing the departmental Radiology Information System I got interested in IT and joined a healthcare IT supplier implementing radiology systems.
After a long and varied career covering all sorts of roles in different market sectors, I ended up working for Stalis as their Operations Director. This was at a time when there was lots of change in healthcare IT due to the start of the National Programme for IT (NPfIT). Stalis was an expert at data management, especially in extracting, manipulating and integrating data from the existing systems, many of them old legacy databases.
During my time at Stalis we developed a proven methodology for data migration and archiving, which included developing tools to help streamline the end to end process. Stalis became expert leaders in this highly specialised area.
Since 2015 I have set up as an independent consultant to offer strategic advice and guidance for data migration projects.
Dylan Jones: How do the typical phases of a Healthcare Data Migration play out? Do you find following a similar process each time is beneficial?
Ali McGuckin: Absolutely.
Data migration is a very low-level subject which is not widely understood by the business (and this is not limited to just healthcare, this is a common issue that applies to any market sector) largely because it is not an activity that happens very regularly.
People tend to think it’s just a question of moving a large amount of data from one system to another without any understanding of the ramifications of doing this.
By applying a strictly defined process it is much easier to ensure a consistent and validated approach throughout the data migration lifecycle.
In addition, by providing tools to help with the process (for example, to validate, measure and audit the quality of the data), it is much easier to track down data issues that inevitably arise through the testing phase.
If the process is clearly defined and can be followed repeatedly by all, it also provides greater transparency and governance to the whole process.
I would definitely recommend that a standardised phased approach is followed regardless of whether the organisation is planning to carry out the data migration in-house or via an outsourced expert data migration partner.
In my experience, the same process mapping can be applied to any sector, not just healthcare.
Dylan Jones: What were these major phases you adopted?
Ali McGuckin: I have been involved in a variety of projects and for what I would call a ‘standard’ project the phases can be very well defined.
The first phase is what I would call the Strategy phase.
The strategy phase includes working with the client to define the Data Migration strategy (ie. what systems the data will be extracted from, what will/won’t be migrated, roles and responsibilities and an archiving strategy), and also Testing, Reporting, Numbering and Interfacing strategies.
The Strategy phase is also an opportunity to get the right resources involved and engaged from the outset.
Next is the Analysis phase.
This is where we analyse the data, assess the data quality of the existing data (including decisions about what to do where the data quality is poor or non-existent) and map the relevant entities and data items from the existing to the new system; this phase often requires transformation rules to be defined and documented and there are a number of tools that can support this process.
Next is the Development phase where the programmes are developed to create the transformed data.
The project then moves into the Trial Load phase which is a series of iterative steps to test the migrated data, my recommendation is that a minimum of three trial lads should be planned into the project and that each trial load has it’s own set of Entry and Exit criteria (which will have been agreed and documented during the Strategy phase). This will also inevitably lead to some redevelopment as data issues are uncovered which require remedial work.
Finally the project moves to Full Dress Rehearsal and Go Live.
From the Analysis phase onwards, all the processes should be underpinned by detailed testing and validation which will be key to the success of the project.
A project I was recently involved with was already in-flight and moving rapidly towards a go live; I was asked to audit the project and provide some recommendations for improvements and then manage to workstream to completion. Whilst I was not able to strictly follow the approach as described above due to the project timelines, I was able to apply the same principles albeit as a cut down version and the client subsequently went live successfully to the agreed plan.
Dylan Jones: You mentioned that data migrations are not widely understood by the ‘business’ side of healthcare. How important is it for the migration team to get the support from clinical staff on the project?
Ali McGuckin: Gaining support and buy in from the clinical team (or in other market sectors, the business users) is absolutely critical to the success of the data migration work stream.
Unfortunately it is often the case that the business sees data migration as an ‘IT’ problem because it is typically the IT department who will be carrying out the mechanics through the development of the Extract, Transform and Load (ETL) process.
What they often fail to understand is that although the developers can easily carry out the ETL development and data processing, they will not have the understanding or knowledge of the context of the data they are migrating nor will they understand what is important to the end users for ‘business as usual’ after go-live.
In some projects I have experienced what is seemingly a perfect migration of data that has only been validated by the IT testers. When the end users try and move the data to the target data store, the system either doesn’t allow things to happen or the data is not fit for operational use.
By gaining the support of the clinical staff at an early stage of the project, they will understand how important it is for them to be fully engaged throughout the process. This can be facilitated by high level strategy workshops at the start of any system replacement project, bringing together a team of resources from all aspects of the business so everyone starts with the same understanding of the resource requirements at every stage of the data migration process.
Dylan Jones: Thinking back to an earlier successful project that you contributed to, how was the team constructed (in terms of roles and skills) and how long did the project take to complete?
Ali McGuckin: Thinking back to previous projects, there are a number of roles that were covered:
A Project Lead with experience of previous data migration projects to manage the resources for the workstream and to ensure that all workshops and activities are documented and signed off by the business, and of course to make sure these activities are aligned with the overall delivery plan.
2 developers who understood the data from the existing systems and could develop the Extract, Transform and Load programs; these were supported by 2 business analysts who had a deep knowledge of the data and how this was being used operationally; these analysts also had input into the new system and how the data needed to be mapped and transformed to meet the business as usual processes.
There were also a number of testing and QA resources who developed and executed the test scripts, taking into account the need to test migrated data which is quite different from testing a newly configured application. The testers came from the business community as all testing needed to be signed off by the business rather than an ‘IT’ sign off.
The initial plan was for a nine month project but in the end the project took around 15 months; due in part to some of the issues that came out of the testing but also as the organisation recognised the impact of the new system in having to develop new ways of working and ensuring that the transition did not disrupt their existing business as usual operational and management reporting.
Dylan Jones: In your role as an independent consultant, how do you structure the relationship with the project manager? How do you help to create a more successful outcome for the client for example?
Ali McGuckin: It is important to work really closely with the project manager and I tend to do this at the outset by really ensuring I understand the key business benefits that the project is aiming to achieve. Throughout the project I normally have weekly meetings with the project manager although generally these tend to be management by exception rather than going into the detail behind the scenes as that is what I am there to support and the project manager generally has enough to do supporting all the other aspects of the project.
I am also good at building good working relationships with all key project resources including those from IT, the reporting workstream and the operational business users. Due to my background, I think one of the key skills I can bring to support a successful project is being able to bridge the gap between technology and business to ensure everyone understands the process and can therefore support a positive delivery. It’s really about translating technical jargon into something simpler that the end users who are not technical can really understand and relate to and always remembering that the end users are the people at the sharp end of operational delivery.
Dylan Jones: You talked earlier about the need for a ‘Full Dress Rehearsal’ stage. Can you give an example of how you delivered this activity for a client and what kind of results you attained?
Ali McGuckin: The Full Dress Rehearsal should in theory be a replica as to what will happen at go live so that there are no surprises during what is always a pretty stressful time.
In one project I worked with, we weren’t able to replicate the the exact live environment for a number of technical reasons so we just had to make sure that we covered as many scenarios as possible. We achieved this by carrying out a number of trial loads covering all datasets, documenting the results and making sure that these could be easily replicated at go live, having a very detailed activity plan over the cutover period that had been validated by all interested parties (both from the organisation and all third party suppliers), applying very strict change control to the development environment and lastly ensuring that the agreed entry and exit criteria were applied to the project sign off process.
The project went live successfully with no unexpected or unknown loss of data.
Dylan Jones: Finally, what is one parting piece of advice you can share with our audience?
Ali McGuckin: It may sound obvious but to me the crucial thing that is critical to the success of the project is to ensure that you have a data migration expert who has done the job before to provide advice and guidance and who can identify issues almost before they arise.
Some of the projects I have been involved in have had excellent project managers running the data migration workstream but they do tend to struggle if they are not experienced in data migration and this can have a significant effect on the overall success of the data migration.
There are numerous articles and features about how to ‘do’ data migration but there is no substitute for actual hands on experience!
And finally, it must be remembered that a poor migration can impact on so many critical areas of the business which in healthcare can impact on patient safety, finance and reputational damage to the organisation; there have been many highly publicised examples of this over the last few years.
About Ali McGuckin
LinkedIn: https://www.linkedin.com/in/alimcguckin/
Ali is an independent IT and healthcare specialist offering a wide range of consultancy services to the NHS and other market sectors including project planning and implementation support, business analysis and process mapping, data migration and testing strategies, data quality and process audits, testing and data validation and archiving and data retention strategies.