The winter of your discontent.

It was late in November. Not yet the winter of my discontent.

One year ago

It was a Wednesday afternoon. Late November. Fall was still in the air.

I called a lead on a routine follow-up.

We had been going back and forth for a while. Like 2 years.

My contact says — I may have something interesting for you. We’re getting ready to terminate our CRO. It’s the middle of our study and we need to preserve the data. I need to know how quickly we can migrate the data to another EDC system.

I like what I hear. I ask, How soon can you send me a dump of the Rave database?

Contact says — You got it. Gary will send it to you.

Good — I’ll get back to you tomorrow and let you know what we think.

2 hours later, Gary sends us a data extract and a huge Excel with the Rave metadata.

I get our data engineering team on a call. Alina is an ML engineer. Adi is a study builder. Natalie is a project manager and Becca is a software engineer who would later play a key role in writing translate & load code to our EDC. Janna is on QA.

The plan is on a piece of paper.

Take the Rave CRF metadata from the huge Excel and convert it into our internal vendor-neutral JSON-CRF format. Produce a case book and show it to the customer tomorrow morning. Load the CRFs into our EDC. Build the SOE — Schedule of Events and assign forms to events. Translate and load data into the data model. Validate each step with checksums for records in and out. Go live in 21 days.

And we’re off and running.

Alina develops a Python script to programmatically convert the Rave CRF metadata to our vendor-neutral JSON CRF format. She works with Becca and the 2 start iterating quickly, fixing bugs, and doing test runs to load the output JSON into our EDC.

After the usual issues of delimiters and syntax, Alina has a show-stopper. She slacks Alex from our software engineering team. Alex — remember that strict constraint we set to enforce the uniqueness of CDASH variable names in CRFs? Alex — sure. Well — in Rave, the same variable can appear in multiple CRFs. We need to relax the constraint in the JSON-CRF loader. Alex — no problem. Done.

2 hours later

Alina and Becca have a case book, created automatically from the Rave metadata.

24 hours after our phone call

24 hours after our phone call, Thursday am, Eastern time — I call the customer and email him the case book. He asks — what’s this? I say — it’s your casebook on the Flask Data digital CRO platform.

Contact — send me a quote for the conversion, data load, and subscription for Flask EDC and data management platform services. I say — the quote is in your inbox. Contact — how quickly can you bring us to go-live from the CRO Rave system? I say — we’ll show you the first cut on Monday — and within 21 days you will go live after validation.

We get a PO an hour later and a down payment later in the week. The customer says that our speed of response was the clincher. We were faster to a validated system than the new CRO.

Our team is in Israel and the customer is on the US East Coast. We work Sundays and we’re 7 hours ahead. The time shift works to our advantage as we can work while the customer is sleeping.

Sunday — we start. The process is Agile. We adapt and learn.

Days 1–7.

Becca wrote code to load the data. She has to take a couple of personal days off. There is an issue with her code crashing — another team member steps in and fixes the code while Becca is out. Remote debugging by phone rocks. The process of data translation and load has several steps. Each step is automated and needs to be debugged. We’re doing it on the Linux command line, piping data from step to step. Iterating each day until it runs and we can see properly formatted data in the EDC.

Days 8–12.

Natalie and Adi build the SOE — schedule of events. They discover EDC configuration deviations. The SOE in the Rave EDC system that the CRO implemented does not match the protocol. Not all the variables in the metadata appear in the EDC dataset. Consultation with the customer clinical leadership. Decisions are taken. The customer decides to make some improvements to the SOE. This takes a few more days to execute and test. Every day we run an automated build that translates and loads the data. Running into issues with the Rave date-time formats in the Rave data extract not being valid ANSI formats. Writing custom code to normalize the time fields in the data to a standard format.

Days 13–15.

Customer discovers another data extract. We rerun and re-validate the check-sums and go live as planned.

Summary

Project timelines

1. Started conversion Nov 14, 2021, go live Dec 1, 2021 (12 working days)
2. Final validation Dec 13
3. Customer sign-off Dec 24

Algorithmic process flow

1. Build target EDC from source EDC meta-data with code.
2. Automated build flow
3. Checksum controls
4. Vendor-neutral intermediate formats

Highlights

1. Automated flow and vendor-neutral formats worked well
2. Agile project management
3. Daily phone calls with customer
4. Continuous integration and validation using check-sums. No progress without a perfect match of records in/out

Low-lights

1. Significant discrepancies between protocol SOE and the SOE implemented in the EDC by the previous EDC; were resolved by building the SOE in the target EDC from scratch. The SOE on Rave bore little resemblance to the protocol.
2. Data typing issues with Rave data — non-standard date-time formats; missing and partial date-times. This was handled ad-hoc in this project. We now have a better understanding of how Rave allows weak typing. A future version of the system will perform automated normalization of date-time fields.
3. Sparse use of edit checks in the study build was surprising; raised questions about data validity
4. Lack of lab units of measure in the Rave EDC due to the CRO using an external labs system. This was the first time we ever saw a database of measurements without explicit units of measure.

Words of thanks

My heartfelt thanks to the team for executing this and to the customer for believing in us.

If you would like to learn more about how Flask Data can help you get out of a tough situation, send an email to support@flaskdata.io Always looking for new challenges.

Dissatisfied with your CRO?

Flask Data is a Digital CRO specializing in adherence assurance in clinical trials.

We recently migrated a biotech company from a big 3 CRO using a Medidata Rave EDC to the Flask Data Digital CRO platform.

In this article, I’ve described how Flask Data executed the migration in 2.5 weeks sustaining data and GCP integrity.

Why should I care and why are you any better?

CROs often commit to services they cannot deliver. 2 top sources of dissatisfaction are delayed red lights on data and compliance and unmet deadlines.

Flask Data offers migration to a high performance digital platform with guaranteed delivery of 21 days.

When you work with a big CRO, the A team sells and the C team delivers.

We’re much smaller than the big guys. You’ll always deal with the A team — pre-sale and post-sale.