Clinical application engineering for trial operations: study systems built, extended and integrated so that a mid-study protocol change is a controlled configuration event rather than a small project with a data integrity problem attached.
Your protocol will be amended. Probably more than once. Every amendment moves forms, edit checks, visit schedules, randomisation, supply and site training, and all of it has to happen while the study is running and without disturbing anything already collected.
A protocol amendment arrives as one approved document and lands as several simultaneous changes across systems that were configured independently.
The hard part is not making each change. It is making them consistently, in the right order, while subjects are mid-study and data already exists under the previous version.
Amendments are handled as projects, not as configuration
So each one costs weeks and introduces its own risk.
Records are not tied to a protocol version
Which makes a mid-study change unanalysable afterwards.
Patient-facing applications were designed for a desk
And they run on an unfamiliar phone in somebody’s kitchen.
Site burden is treated as a usability complaint
When it is a measurable input to data quality.
Protocol deviations are filed as documents
So a systematic cause across sites is invisible.
Inspection readiness is an end-of-study project
Rather than a state the systems maintain continuously.
Legacy clinical applications cannot be changed safely
And they are usually the ones holding study conduct records.
Every study is configured from scratch
Because nothing was built as a reusable, controlled template.
Ask a coordinator at one site to show you their week. Not a survey, a visit. Ask how many sponsor systems they log into, how many times the same data point gets entered, where they keep the paper that feeds the systems, and which of your requirements they find hardest to satisfy on time. The answers are consistent across the industry and almost never collected by the people specifying the applications. Half a day at one site will tell you more about your data quality than a monitoring report will.
The sequence that works assumes change rather than accommodating it later, and decides before go-live where volatility is allowed to live.
Step 1
Assess the study workflows as executed at the site, not as documented
Step 2
Discover what has to remain true across a protocol version change
Step 3
Design for amendment as a normal event
Step 4
Architect with volatility separated from stability
Step 5
Develop with reusable, controlled study templates
Step 6
Integrate to the standards where they help, and map where they do not
Step 7
Validate to intended use, with scope set by your quality function
Step 8
Deploy with site and patient onboarding treated as part of the system
Step 9
Govern configuration and access with named owners
Step 10
Monitor adoption, site burden and deviation patterns alongside uptime
Step 11
Enhance against observed friction, study after study
Take your last amendment and reconstruct what it cost. Pick the most recent substantive protocol amendment and account for it honestly: elapsed time from approval to all systems being consistent, person-days across data management, programming, supply, quality and site management, how many subjects were mid-schedule when it landed, and whether any data collected under the previous version needed rework. Most organizations have never totalled this, and the number is usually several times what anybody assumed. It is also the clearest business case for amendment-ready architecture that exists.
Grouped by what each capability is for. We build, extend, integrate and modernise. Platform selection and the integration patterns behind these sit on our Clinical Systems Integration page.
Study systems
Custom clinical application development where no product fits the workflow
Clinical trial management applications, and extension of existing CTMS environments
Electronic data capture integration and extension, including the amendment path through to analysis datasets
Clinical data management tooling: reconciliation, listings, review workflows and query handling
Legacy clinical application modernisation, recovering the behaviour and preserving the records, because these systems usually hold study conduct history and have no surviving requirements document
Patient and site facing
Electronic patient-reported outcome and electronic clinical outcome assessment applications, engineered for real devices in real homes
Patient engagement applications: scheduling, reminders, education and study communication
Site-facing interfaces designed against measured time per subject rather than against a feature list
Clinical document management and electronic trial master file integration, maintained as a continuous state
Automation and intelligence
Clinical workflow automation for steps that are genuinely deterministic, evidenced as our Trial Workflow Automation page describes
AI-powered clinical applications with provenance, limits and human review built into the workflow
Automated clinical reporting assembled from captured data rather than from re-entry
The third column is the point of the table. Each of these has one failure mode that decides whether it works in a real study, and it is rarely the one the implementation plan is managing.
| Use case | What it delivers | What it lives or dies on |
|---|---|---|
| Trial workflow digitization | Study conduct captured as it happens | Being faster at the site than the paper it replaces |
| Study planning and tracking | Milestones, dependencies and status in one place | Being updated by the work rather than by a person |
| Recruitment and screening | A visible funnel from identification to consent | Honest screen-failure capture, not just successes |
| Participant enrollment | Eligibility, consent and randomisation linked | Version control when criteria change mid-study |
| Site management | Site status, performance and obligations tracked | Not becoming a second place sites must update |
| Clinical data capture | Structured data at source with checks applied | Form and edit check design, on our CTDS page |
| Deviation tracking | Deviations as queryable structured data | Aggregation across sites, not individual filing |
| Patient-reported outcomes | Patient data from the patient directly | Working on the device the patient already owns |
| Monitoring dashboards | Risk signals surfaced for action | Exception delivery, not another page to open |
| Document management and eTMF | Inspection-ready documentation | Completeness maintained continuously, not at the end |
| Automated clinical reporting | Reports assembled from captured data | Nothing in the report being re-entered by hand |
Clinical integration is better served by standards than almost any other domain in Life Sciences, and that genuinely helps. It also leads to an expectation that two standards-compliant systems will simply connect, which is not what the standards promise.
CDISC gives you agreed structures and terminology for submission-oriented data, which removes a large class of argument and does not decide how your study-specific collection maps into them
HL7 FHIR gives you a consistent way to exchange health data, and still leaves the semantics of a specific coded value in a specific source system to be established
Both are versioned, and two systems may implement different versions or different profiles of the same version, which is where an integration that passed testing fails in production
And conformance is a property of a structure, not a guarantee that the clinical meaning survived the mapping
Study systems: electronic data capture, clinical trial management, electronic trial master file, electronic clinical outcome assessment and patient-reported outcomes, interactive response technology
Clinical data management systems and analysis environments
Electronic health record data where appropriately authorised, under the basis your privacy and ethics functions determine
Standards: CDISC data standards, HL7 FHIR for health data exchange
Cloud and application platforms: Microsoft Azure, AWS, APIs and integration services
Analytics and modelling: Microsoft Fabric, AI and machine learning frameworks
Delivery: Power BI alongside purpose-built clinical review interfaces
Test one amendment against your systems on paper. Take a plausible amendment, a changed visit window plus one added assessment, and walk it through every system with the people who would have to make the changes. Write down what each one does, in what order, what happens to subjects mid-schedule, and which of those steps requires a validation activity. The exercise takes a morning, needs no technology, and produces both an accurate cost estimate and a short list of the places your estate is not amendment-ready.
Regulatory applicability, system classification and validation strategy are determined by your qualified quality, regulatory and legal functions. We do not interpret those frameworks and this page does not state which apply to you, how any system of yours is classified, or what validation it requires.
Technology supports a compliance programme. It does not independently establish regulatory compliance, and no software makes an organization compliant.
Records and integrity
- Electronic records and electronic signature capability built to the requirements your quality function specifies
- Audit trails recording what changed, who changed it, when and why, that a user cannot alter or disable
- Protocol and configuration version stamped on every record, which is what makes a mid-study change analysable afterwards
- Contemporaneous capture designed into the site workflow, since a record entered days later is not made contemporaneous by a timestamp field
Validation and change
- Systems engineered to be validatable: requirements traceable, changes controlled, configuration versioned, evidence as a build output
- Validation scope and approach determined by your quality function, with our role being to supply what it asks for
- The boundary between a routine configuration change and one requiring revalidation defined before the first study
- Amendment handling as a controlled, repeatable procedure rather than a bespoke project each time
Privacy and access
- GDPR and other applicable privacy requirements as your privacy function determines, including the basis for any secondary use
- Role-based access resolved per user, per study and per site, with separation of duties where the process requires it
- Blinding preserved in the data model and in access, because an unblinding incident is usually an access design failure
- Participant data minimised and pseudonymised per the approach your privacy function approves
- Backup, recovery and incident monitoring tested rather than configured, since a clinical record lost mid-study cannot be recreated and the study cannot be rerun
AI and oversight
- Defined intended use for every AI capability, with the clinical decision explicitly outside it
- Human review of any AI-assisted clinical activity, recorded as a workflow step with the reviewer and the decision captured
- Provenance on every AI output, traceable to the source records it was derived from
- Model performance and drift monitored, with a defined route to withdraw a capability that degrades
A clinical application that is available, fast and quietly producing poor data will be reported as healthy by every conventional monitoring tool.
| Failure | How it presents |
|---|---|
| Entry has shifted to weekly batches | Timestamps cluster and contemporaneous capture has stopped |
| One site has reverted to paper | Their data arrives late and complete, which looks fine |
| A patient app fails on one device version | Completion drops in a subgroup nobody has segmented |
| An interface failed silently | Reconciliation debt accumulates with no ticket raised |
| Deviations cluster on one assessment | A protocol or form clarity problem reading as site conduct |
| Query rate is high on one form | The form is manufacturing queries, as our CTDS page describes |
| A configuration change went in unversioned | Records cannot be tied to the configuration that produced them |
| eTMF completeness is drifting | Gaps are ageing and getting harder to close |
| An automated step is overridden routinely | The automation does not match the work and costs time |
The outcomes below follow from one design choice: the protocol change treated as a normal, controlled event rather than as a project.
Study workflows accelerated, measured in time per subject at the site rather than in features delivered
Amendment cost and elapsed time reduced, which is the largest recoverable cost in the clinical application estate
Clinical data quality improved at source, because contemporaneous capture is achievable rather than merely required
Study collaboration strengthened across sponsor, sites and partners on a shared record of conduct
Trial visibility improved, with exceptions delivered rather than published to a page
Regulatory readiness supported continuously, with the trial master file maintained rather than reconstructed
Legacy clinical systems modernised with their behaviour understood rather than guessed at
We will take one planned or recent amendment and map it across your estate: what changes, in what order, what happens to subjects mid-schedule, and which steps require validation activity. You get the map whether or not we build anything.
CaliberFocus builds, extends and integrates clinical study applications so that a mid-study protocol change is a controlled configuration event rather than a project. We stamp every record with its protocol and configuration version, design site and patient-facing applications for the people who actually use them, treat deviations as queryable data, and engineer systems to be validatable.
- Amendment-ready architecture that runs two protocol versions at once
- Site-facing interfaces designed against measured time per subject
- Patient applications built for real devices in real homes
- Reusable, controlled study templates instead of rebuilding each study
Security & Compliance
