How a behavioral health EHR platform cut provider migrations from two weeks to ten hours with Rocketlane's migration agent

Two weeks → ten hours

Time to migrate a provider

100–120

Implementations a year the process supports

1,200 patients and 19 GB

First full migration, live without issues

Region

US

Industry
‍

Healthcare Tech

Use case

Data migration, Customer onboarding, Implementation

Before

  • Time to migrate a provider: Two weeks
  • Taking on more implementations: More implementers
  • Future appointments and treatment plans: Hard to extract, often rebuilt by hand
  • Where a migration starts: Templates the provider filled in
  • Transformation: Excel, a different template per implementer
  • Documents: A separate piece of work
  • Where the know-how lives: With the people who ran past migrations
  • Legacy system logins: Handled by the platform's team

‍

After

  • Time to migrate a provider: Ten hours
  • Taking on more implementations: More agent runs, same team
  • Future appointments and treatment plans: Extracted in the same run
  • Where a migration starts: Data pulled directly from the source system
  • Transformation: Plain-English rules, captured once and reused
  • Documents: Extracted alongside the records
  • Where the know-how lives: In an agent that improves with every run
  • Legacy system logins: Entered by the provider, never held by the platform

About the customer

A modern behavioral health EHR platform running 100 to 120 implementations a year. For an EHR platform, a signed provider isn't a live one. Patient records, billing, appointments, authorizations, future calendar events, treatment plans and clinical documents, some kept for seven years, all have to move first. At 100 to 120 implementations a year, migration sat on the critical path of almost every one.

‍

The Challenge

Tools for parts of the job, but nothing for the whole of it

The platform had tools for parts of the job, but nothing for the whole of it. A load tool handled CSV uploads. An extraction vendor pulled some data out, but still needed manual review and setup for every legacy system. Everything in between lived in Excel, with each implementer keeping their own templates. As one of their leaders put it, they had been picking tools by whose gaps were least glaring, not by what they actually needed.

Getting the data out

Some legacy systems export fixed reports, some produce one PDF per patient, and the data that matters most on day one, future appointments and treatment plans, often can't be exported at all.

Making it fit

Around twenty date formats, payer IDs to match, secondary insurance to split into its own record, fields that exist in one system and not the other. These decisions were worked through with each provider, every time.

Making it clean

Names, dates of birth and payer details had to match exactly across around ten import files. A badly formatted ZIP code or a missing member ID meant a failed upload.

Handling logins to someone else's software

Underneath all of it sat a risk: extracting data from a legacy system means handling logins to someone else's software. The platform wanted to stay out of that chain entirely.

‍

The Solution

One agent per legacy system, taught once

The platform started with the legacy system its providers leave most often and showed the Migration Agent how a migration is done, once. That meant which screens hold which data, how each field maps to the import files, which fields are required and what to do when something is missing. The rules are written in plain English, not scripts.

The whole extract, transform and load, run by the agent

The agent now runs the whole extract, transform and load. It connects to the source system using credentials the provider enters themselves, so the platform never holds them. Records and documents come out together, already mapped, validated and organized into the files the import expects: demographics, payers, authorizations, appointments, billing and documents. When a value is wrong, the team fixes it in place with a prompt instead of a spreadsheet.

Nothing loads until it's reviewed

Nothing loads until the team and the provider have reviewed the files. With patient data, that review step is the point, not a delay.

A handful of agents covers most of the pipeline

Each legacy system gets its own agent, which is reused for every provider coming from that system. Around five legacy systems account for most of the platform's switchers, so a handful of agents covers most of its pipeline.

Built for sensitive data

Patient data needs the highest level of care, and every migration is built around that. Rocketlane is HIPAA, SOC 2 and ISO 42001 compliant, and every migration runs under a signed BAA with the platform. The same security controls protect the data from extraction to load. Providers enter their own legacy system credentials, so the platform never holds them. Once the migration is complete, the data is destroyed and nothing is retained.

‍

The Impact

Providers go live sooner, with their whole history

A migration that took two weeks now runs in ten hours. The first full migration moved 1,200 patients along with their schedules, treatment plans and 19 GB of records and documents, and the provider went live without issues. Providers now start on day one with future appointments already on the calendar and treatment plans in place, which is the data that used to be hardest to bring across.

Implementation capacity grows without the team growing

The platform runs 100 to 120 implementations a year. Each new provider from a covered system now means another agent run, not another implementer. The team spends its time reviewing finished packages and working with providers, not rebuilding spreadsheets.

Every migration makes the next one faster

Mapping rules, clean-up steps and exceptions now live in the agent instead of in each implementer's own templates. The next provider from the same system starts from a template that already works, and every run adds to it. The template built on the most common legacy system now runs for the next provider without being rebuilt. A single full-volume run on that system moved 2,700 patient records, 100,000 appointment and billing rows and 7,000 documents.

Switching carries less risk

Providers enter their own credentials, the agent works under a signed BAA, and the data is destroyed once the migration is complete. The platform can bring providers across from incumbent systems without taking on the exposure of holding their logins.

The platform moved its migration program onto the agent

After its first migrations, the platform replaced its previous extraction vendor and committed its next 100 migrations to the Migration Agent.

‍

What this means for you

If your customers can't go live until their data does, migration is your time to value. The Migration Agent learns how your team migrates, handles extraction, transformation and loading, and gets better with every customer you bring across. Your implementation capacity grows with agent runs, not headcount.

‍

Want the full story?

If we can do it for them, we can do it for you. For the full case study, get in touch at care@rocketlane.com.

‍