specialty pharmacy migration

Specialty Pharmacy Group Successfully Migrates 3+ Million Patients in Eight Weeks

specialty pharmacy migration
Share on facebook
Share on twitter
Share on linkedin
Share on email

AgileThought Leverages Pharmacy Migration Experience & Automation to Accelerate Project Timelines

Results

The world’s largest specialty pharmacy organization gained over three million new patients after a merger and decided to migrate all patient services to their existing ERP.

The migration was part of a strategic merger. Speed and automation were the most important project success factors; the faster the project was completed, the more money the customer saved by not having to support dual systems. An aggressive eight-week timeline was established to complete the project.

AgileThought, from a project management perspective, prioritized momentum including:

  • Leveraging existing ERP system components to build automation
  • Accelerating performance by assigning migration SMEs to key areas
  • Bringing in Ulises Gaytan, AgileThought’s Vice President of Service Delivery
  • Putting in 20-hour days to stay on schedule (without charging extra for overtime)

 

The Challenge – Migrate Sensitive Patient Information Between Disparate Systems…

…in just eight weeks. The main goal of the project was to migrate all patients from the incoming system to the incumbent system. A single patient can have up to 20,000 records, which included medical data, clinical data, and insurance information.

Ulises Gaytan, AgileThought VP of Service Delivery, was brought in to fast-track the project, which had been previously mismanaged by another team.

He recalled that “failure is not in my vocabulary. I told the customer that if they wanted the project completed on time, to give my team control. I assembled a group that was passionate enough to put in 20-hour days for the eight-week stretch.”

Ulises implemented parallel processes, fluid communication, and sheer hustle to complete the project on time. His team also shortened the migration review process, which took 2 hours and 40 mins instead of the 48-hour process that had been previously used.
 

Not as Simple as Copy and Paste

Although the two systems provide similar services, there were many discrepancies in how they operated. There were services that existed in the incoming subsidiary that needed to be developed within the incumbent ERP system. Data was not treated the same, and fields were not equal.

The team built a solution to conduct an ETL (extract-transform-load) process that would automatically transfer patient information between systems without affecting ongoing operations.
 

Mapping a Solution

System mapping was essential for determining the differences between systems, and ultimately set the stage to develop functionality within the go-forward platform.

The team called upon subject matter experts (SMEs) from both systems to get a complete vision. AgileThought leveraged over a decade of pharmacy business knowledge and reviewed the mapping to propose solutions on how to:

  • Merge fields
  • Add functionality
  • Prevent disruptions on ongoing operations

The heart of the incumbent system was the prescription screen, where patient care advocates maintain and update patient profiles and plans.

It is also one of the most complex pieces of software in the PBM’s ERP system. One wrong change could negatively impact thousands of patients.
 

All patient data was successfully migrated within the eight-week timeframe

AgileThought decided to implement a plan-based measurement scheme organized by population tiers. Patients covered under the same plans had similar data, and their migration could be more clearly managed.

Once mapped, and a migration solution determined, the team began moving patient data. The first tier involved ten thousand patients; a small batch to determine efficacy. The team carefully notated progress and adjusted as the tiers grew to one hundred thousand, six hundred thousand and eventually between three and four million patients were migrated.

Initial tiers enabled around 90% of patient data to be migrated

The remaining ten percent involved special cases that needed to remain in the acquired system for multiple reasons:

  • Treatment plans would otherwise be interrupted
  • Claims center complexities
  • Continued support for patient plans
  • Patients were in the midst of receiving a prescription
  • Patients rolled off their benefit plan (or were changing plans)

The project team anticipated the special cases and had already defined such issues as part of the migration plan. They migrated as many patient groups as possible to drive down dual system maintenance costs, and still made sure all patients were unaffected by the changes. The team ran a report before each migration to see which patients were rolling off the system, further saving time.
 

Leveraging 15+ Years of Specialty Pharmacy Experience

AgileThought created a middle database, called the transformation database, to safely migrate patient data between the two systems. As patient data was entered into the transformation database, the team created objects, adjusted procedures and function triggers, and closed mapping to translate the structure of the data to the incumbent system.

ETL transfer functionality was a major project component. Instead of building an entirely new application, which would cost millions of dollars, the team called on their system experience to create an automated ETL migration tool leveraging existing functionality.

Whenever a pharmacy wanted to move a patient’s prescription to a new city, they would use a specific transfer function. AgileThought extracted the logic from that transfer process, and developed it to automatically function in the backend and simulate pharmacy frontend procedures.
 

Leveraging System Knowledge to Automate ETLs

The AgileThought team extracted logic from a system transfer process to create an automated ETL migration framework, which involved the following:

  1. Split models in both systems
  2. Create a middle database to store patient data in the structure of the incoming system
  3. Within the middle database, translate the structure to the incumbent system, ensuring accuracy
  4. Migrate patient data onto the incumbent platform, creating and modifying objects
  5. Automate the transfer process to accelerate the project timeline

 

Powerful QA Automation

Another key innovation component came from the QA team. The short timeline constrained the team’s ability to validate a large number of patients. Detailed test planning and automation relieved the pressure. Automation was not necessarily used as a regression tool but as a testing accelerator.

QA validated the business logic functionality within the middle database and the incumbent system. They also built another set of packages in the incumbent database called the Pull Process that would ultimately move data to production.

Complexities within the incumbent system meant having to create specific sets of rules without affecting existing patients in production. QA created a transfer process that would automatically pick up prescriptions for transferred patients.
 

Moving Data is Only Half of the Solution

A key critical success factor was that patient data would be usable after being migrated. Patient care advocates needed to work with patient profiles to create subscriptions, set up payments, and manage profiles.

New plans and patient types led to the creation of new functionality in the PBM’s main ERP system.

Patients came first. What began as an M&A data migration, became a revamp of the core specialty pharmacy system. AgileThought simplified and streamlined many of the system’s processes to improve patient care.
 

Download The Success Story!

specialty pharmacy migration


Stay Up-To-Date