The challenge
Our client builds clinical data capture software for pharmaceutical and clinical research organisations worldwide. The platform supports the full range of trial outcome measures — patient-reported, clinician-reported, and observer-reported assessments, alongside standardised performance tasks — across Phase 1 to 4 studies globally.
Every clinical trial runs to a unique protocol: a defined schedule of visits, assessments, and task sequences that is agreed with regulators before the study begins and cannot be meaningfully changed once participants are enrolled. The platform therefore needed to be genuinely configurable — capable of expressing any combination of task types, timepoints, conditional branching, and assessment schedules — without requiring bespoke development for each new study. At the same time, the system had to satisfy the stringent data integrity and audit requirements expected of software used in regulated clinical environments. The client holds ISO 27001 and ISO 9001 certification, and the platform operates accordingly.
The engineering challenge was significant: build a system flexible enough to accommodate any trial design, while enforcing the rigidity that regulatory compliance demands once a study is live.
The application
The platform is built in Ruby on Rails, and the core of the engineering work was designing a modular task workflow engine that could serve as the foundation for any study configuration without becoming an unmaintainable tangle of conditionals and special cases.
The modular task system
Each assessment type — questionnaire, cognitive performance task, clinician rating scale, observer checklist — is implemented as a discrete, self-contained module with a defined interface to the workflow engine. The engine itself does not need to understand what a task does; it only needs to know when to schedule it, whether its completion criteria have been met, and what data it produces. Adding a new task type means building a new module to that interface, not modifying the workflow engine.
Task sequences for a given study are defined as configuration rather than code. A study administrator composes a schedule from the available task modules, sets the timepoints relative to participant enrolment, and defines any conditional rules — if a participant's score at Visit 2 exceeds a threshold, include an additional assessment at Visit 4. This configuration is validated at design time, then locked when the study moves to active status. From that point, the task definitions are immutable; the audit trail for every participant interaction traces back to an exact, versioned snapshot of the study protocol.
Conditional branching and scheduling
The conditional logic presented some of the most significant engineering challenges. Rules need to evaluate against prior task data at runtime, branch correctly for each individual participant, and remain legible to study designers who are not developers. The solution was a rules engine embedded in the workflow layer that evaluates conditions against a participant's accumulated response data at each scheduling decision point. Rules are expressed in a structured format that non-technical study configurators can read and validate, while the underlying evaluation is handled entirely in the application.
Scheduling is handled as a separate concern from task execution. Each participant has their own schedule derived from their enrolment date and the study protocol, managed independently of all other participants on the same study. Reminder and alerting logic fires at the correct relative timepoints regardless of when the participant enrolled, and missed or late completions are flagged through the monitoring layer for site staff.
Multilingual data and clinical validity
Several studies require assessments in multiple languages. Clinical questionnaire translations are not simple word-for-word substitutions — they require linguistic validation as part of the regulatory process. The application stores validated translations as distinct, versioned assets tied to their source instrument, ensuring that the exact approved text is what participants see, with a full audit trail linking each response to the specific translated version presented.
The infrastructure
The platform runs on AWS in a high-availability configuration designed around the assumption that any individual component can fail at any time without interrupting a live study.
The Rails application is distributed across multiple EC2 instances behind an Application Load Balancer, managed in an Auto Scaling Group. A failed instance is detected and replaced automatically. At the data tier, Amazon RDS runs in Multi-AZ configuration: the primary database replicates synchronously to a standby in a separate Availability Zone, and failover — should it ever be needed — is automatic and typically completes within 60–120 seconds.
The environment sits within a dedicated VPC with strict security group policies, data encrypted at rest and in transit, and comprehensive audit logging throughout. We manage ongoing OS-level patching, SSL certificate lifecycle, security monitoring, and capacity planning — consistent with the controls the client's ISO 27001 certification requires, and freeing their team to focus on the product.
The outcome
The platform now supports the full range of clinical assessment types across Phase 1 to 4 studies, and the modular architecture has proven its value as the product has grown. New task modules and assessment instruments have been added to the system without changes to the workflow engine. New study configurations are built as data, not code. The platform has scaled to accommodate increased global usage and additional capability without requiring the core architecture to be revisited.
On the infrastructure side, the platform has operated for over 8 years without a single service outage. Studies have run to completion, data has been captured without interruption, and The platform's pharmaceutical clients have been able to rely on the system throughout. For software used in regulated clinical research — where a missed data collection window can have consequences for the integrity of the study — that record is the most meaningful measure of the hosting platform's success.