Rebuilding a clinical-trial EDC from the foundation up.
Modernizing a rigid, form-centric enterprise EDC platform into a scalable, no-code configuration engine governed by a dynamic, persona-driven RBAC architecture.
EDC: the system every clinical study runs on.
Prelude is an enterprise platform for animal clinical research. At its center is the EDC: the system that defines each study’s structure and captures its data, from first setup through monitoring and compliance.
This is the story of rebuilding that core: what it looked like when it had stopped scaling, and the foundation it became.
A platform that had outgrown itself.
The legacy EDC ran on a form-centric model: the eCRF was the container for everything. Feature logic, system configuration, and the features themselves were hardcoded into the forms, so the structure could not grow without breaking.
The platform couldn’t scale
Settings were trapped inside specific forms, so changing one configuration meant editing the form itself. Nothing scaled horizontally, and no global module could ship without regression bugs.
Severe cognitive load
Because settings were scattered across dozens of individual data-entry screens, users suffered intense context-switching fatigue. A single configuration change meant navigating deep into data-collection flows, leading to high error rates and training overhead.
One interface for every role
RBAC was uniform and rigid. Every role met the same cluttered screens, so technicians, data managers, and veterinarians all worked through fields and options irrelevant to their task, threatening both speed and data integrity.
A deep read of the whole structure.
I started by mapping the entire platform, then separated its features by the task each one actually accomplished.
From there I mapped how each role used the system day to day, the tasks they performed and the paths they took, highlighted the critical points where the structure broke down, and pulled it all into a deep analysis of the whole architecture, the foundation the redesign would build on.
- 01
Separate configuration from data
Keep study configuration outside data collection, so each can evolve without complicating the other.
- 02
Build for growth
Create one flexible foundation that can support new capabilities without restructuring the platform each time.
- 03
Design around roles
Let permissions determine what each user can see and do, keeping complex workflows focused and relevant.
- 04
Code free
Let teams build complex studies through configuration instead of custom development.
- 05
Make everything traceable
Build auditability into every action and configuration change without sacrificing flexibility.
From a redesign to a foundation rebuild
I stripped all administrative variables out of the data-collection workflows and re-architected the application into three dedicated structural pillars:
Data collection engine
Pure eCRFs, built for high-speed, compliant data entry, and nothing else.
Global settings control plane
One consolidated master page where administrators configure global trial settings, parameters, and study rules, away from the forms.
Feature modules
Dedicated, standalone areas for individual features, telemetry ingestion, group-level logs, animal-health tracking, each scaling on its own.
One matrix governs access and experience.
A single set of roles and permissions drives both what each person can reach and what they see. Change a role in one place and every screen it touches updates with it, so access and interface stay in sync by construction.
In a regulated trial, mapping roles to permissions is governed by data-integrity standards, FDA 21 CFR Part 11, ICH E6(R3), and EU Annex 11. Access spans three environments, and where it does not mix matters as much as where it does. Hover a role or system to trace its connections.
Defensive design for regulatory compliance.
By isolating configuration from the entry forms, the new structure prevents users from accidentally altering a study design while conducting routine data entry. I designed explicit modal confirmations and system states that automatically tie every setting change directly to the immutable audit trail. By designing out the ability to make the mistake, protocol deviations drop.
The architecture stays compliant with FDA 21 CFR Part 11 and VICH GL9 audit-trail requirements.
A new scalable foundation.
A side-by-side of what changed across the four core issues holding the platform back.
| Issue area | Legacy structure | Redesigned core |
|---|---|---|
| Architectural paradigm | Monolithic and form-bound; logic, features, and settings lived inside the data forms. | Service-oriented; data collection, configuration, and feature logic fully separated. |
| Settings management | Fragmented; configuration was adjusted individually across dozens of forms. | Centralized; one unified global settings plane, separate from data entry. |
| Feature extensibility | High friction; adding or updating a feature meant altering form schemas. | Modular; features live in dedicated spaces and scale independently. |
| RBAC interface logic | Uniform; rigid data tables forced every role through the same UI. | Persona-driven; dynamic UI rendering tailored to each role. |
What started as a contained project became a broader product shift. It took longer and reached beyond the original scope, but it ultimately reset the roadmap and became the foundation for what followed. The same foundation went on to carry more than 12 features, including ePRO, eConsent, integrated IDEXX and VeDDRA / ATCvet coding, and RTSM.