Clinical Trial Data Solutions
Most of Your Queries Were Created by Your CRF,
Not by Your Sites.
Query volume is treated as a measure of data quality when it is mostly a measure of design. A field that invites ambiguity, an edit check with a range too tight, a required entry that does not apply to half the population, a derivation the site has to do by hand: each of those generates queries indefinitely, at every site, for the life of the study. Resolving them faster is a worthwhile improvement. Not creating them is a larger one, and it is available earlier.
We work on the data layer of clinical development: EDC and operational system integration, external vendor data reconciliation, standards mapping towards SDTM and analysis-ready structures, traceability from a reported value back to source, and the reporting that tells a study team where a lock is actually at risk. The work is engineering and integration in support of your clinical data management, biostatistics and medical functions, who own the data and the decisions about it.
The challenge
The data is not usually dirty. The collection and the reconciliation are where it goes wrong
The standard account of clinical data problems puts sites at the centre: incomplete entry, late entry, errors requiring queries. Sites do generate real issues and they are rarely the dominant cost. On most studies the dominant cost is a collection instrument that asks for things in a way that produces discrepancies, an edit check configuration that fires on normal variation, and a set of external data streams arriving from vendors that were never designed to reconcile with each other. All three are decided before the first patient is enrolled, by people who will not be the ones living with the consequences.
The second structural problem is that lock readiness is treated as a phase rather than a state. A lock date is set, and the work that determines whether it is achievable sits months earlier in query closure, external data completeness, coding completion, reconciliation status and the resolution of discrepancies nobody has triaged. By the time a study team is working to a lock timeline, the information needed to know whether that timeline is real is distributed across several systems and several vendors, and assembling it takes long enough that the answer arrives after the point where anything could have been done about it.
Query volume is read as data quality
When most of it was manufactured by the form and the edit check configuration.
External vendor data arrives on its own terms
Different formats, different identifiers, different schedules, and reconciliation is somebody’s evening.
Lock readiness is unknown until it is urgent
Because the inputs live in five systems and nobody assembles them continuously.
Standards mapping starts too late
So the gaps in collection are discovered when there is no way to collect anything more.
Reconciliation is manual and therefore sampled
Which means the discrepancies that matter are found by whoever happens to look.
Blinding is protected for the study team but not for data staff
And the people cleaning laboratory data can become unblinded by the values themselves.
Mid-study amendments arrive as a surprise to the data flow
New forms and changed definitions land on mappings and checks nobody revisited.
Group last study’s queries by the field that caused them. Take a completed or late-stage study, pull the full query history, and group it by the form, the field and the edit check that generated each one. Then read the top twenty. The common experience is recognising most of them, because the study team complained about exactly these fields for two years, and discovering that nobody carried the finding into the design of the next study. This analysis costs days, needs no new systems, and is the single highest-return piece of work available to a clinical data function that has a programme of studies ahead of it rather than one study behind it.
Our approach
Assess, integrate, standardize, transform, validate, reconcile, govern, monitor
Two things in this sequence are deliberately early. Standards mapping is designed while collection can still be changed, because a gap found later cannot be filled. And reconciliation is built as a running process from the first external data transfer rather than assembled before lock, because that is the choice that determines whether a lock date is real.
Step 1
Assess the study data landscape
Step 2
Design the mapping while collection can still change
Step 3
Integrate EDC, operational and external sources
Step 4
Standardize towards submission and analysis structures
Step 5
Validate against the specification and against reality
Step 6
Reconcile continuously, at value level
Step 7
Govern access, blinding and change
Step 8
Monitor completeness, queries and lock readiness
Step 9
Feed findings back into the next study design
Make lock readiness a live view, not a status report. The inputs to lock readiness are known: open queries by age and criticality, external data expected versus received versus reconciled, coding completion, outstanding discrepancies by owner, protocol deviations pending review, and signature status. Each of those lives in a system somebody can read. Assembling them into a single continuously refreshed view is ordinary engineering work and it changes the conversation from a monthly status meeting to a standing fact. The value is not the dashboard. It is that a lock date becomes defensible or indefensible eight weeks before anybody has committed to it externally.
What we build
The data layer under your clinical data management function
We build and operate the integration, transformation, reconciliation and reporting layer. Your clinical data management, biostatistics, medical and pharmacovigilance functions own the data, the clinical decisions and the regulatory positions, and nothing here substitutes for them.
Collect and connect
EDC integration, including incremental extraction and mid-study build changes
CTMS, IRT, eCOA and ePRO integration for operational and patient-reported data
Central laboratory, ECG, imaging and biomarker vendor data onboarding and transfer handling
LIMS and EHR integration where the study design and permissions support it
Transfer specification support, so vendor files arrive in a form that can be reconciled
Standardize and transform
Mapping towards CDISC SDTM, with the source form retained alongside
Analysis-ready derivation supporting the statistical reporting, documented and traceable
Controlled terminology alignment with the version recorded against every coded value
MedDRA and WHO Drug coded data integration, with coded and verbatim terms both preserved
Dictionary version tracking and coding status reporting across the study
Unit and measurement harmonisation with method and specimen context carried through
Validate and reconcile
Edit check design review aimed at reducing unnecessary query generation
Transformation validation against specification and against worked examples
Value-level reconciliation on every external transfer, with discrepancies classified
EDC to central laboratory and EDC to safety database reconciliation as standing processes
Subject, visit and sample identity resolution across systems and vendors
Query management reporting by cause, not only by age and site
See and submit
Clinical analytics for enrolment, site performance, data flow and completeness
Risk-based monitoring data support, including the signals the central team actually uses
Continuous database lock readiness reporting across all its inputs
Traceability from any reported value back to the source record it came from
Submission support: the datasets, Define-XML preparation, transformation documentation and the audit record
Where this gets used
The data problem changes shape with the phase
A first-in-human study and a large multi-region programme have almost nothing in common operationally, and a data approach built for one is wrong for the other. Volume, timing, site count, external vendor count and the consequence of an error all move together.
| Context | What the data looks like | Where the effort goes |
|---|---|---|
| Phase I | Few subjects, extremely dense sampling, rapid turnaround, often one unit | Near real-time availability and precise timing relative to dose |
| Phase II | Moderate size, several endpoints under evaluation, design may adapt | Flexibility in the data flow without losing traceability |
| Phase III | Many sites, long duration, many vendors, regulatory consequence | External reconciliation, consistency across sites, lock readiness |
| Phase IV and post-approval | Longer follow-up, looser collection, real-world sources appear | Source provenance and the limits of what the data can answer |
| Clinical operations | Operational metrics across studies in a portfolio | Comparable definitions across studies that were built differently |
| CRO delivery | Multiple sponsors, multiple protocols, contractual separation | Separation enforced in the platform, and sponsor-specific conventions |
| Patient enrolment | Screening, consent, randomisation and discontinuation flow | Timely accuracy, because enrolment decisions are made weekly |
| Site performance | Entry timeliness, query rates, deviations, data quality by site | Query rates adjusted for design cause, so sites are judged fairly |
| Safety data | Adverse events, concomitant medications, laboratory values, coding | Reconciliation with the safety database, and coding completeness |
| Laboratory data | Central and local laboratory values, units, methods, ranges | Unit and method harmonisation, and identity across samples |
| Decentralized and hybrid trials | Remote assessments, connected devices, home nursing, direct-to-patient | Device and timing metadata, plus consent scope for data collected outside a site |
| Risk-based monitoring | Statistical signals across sites and subjects | Signals a central team will act on rather than a monitoring report |
| Database lock readiness | Inputs spread across every system and vendor above | A continuous view, so a lock date is defensible before it is committed |
How it is built
The hard part is identity, not transport
Moving files between systems is solved. Establishing that this subject in the EDC, this sample at the central laboratory, this device record and this patient-reported entry all refer to the same person at the same visit is where clinical integration actually succeeds or fails, and no amount of pipeline engineering substitutes for getting it right.
| System | What it holds | The integration constraint |
|---|---|---|
| EDC | Collected case report form data, queries, audit trail | Mid-study build changes alter structure without warning downstream |
| CTMS | Operational study, site and milestone data | Operational definitions differ from clinical ones and must not be blended |
| eCOA and ePRO | Patient-reported outcomes and diary data | Timing and device metadata matter as much as the response |
| IRT | Randomisation and supply management | Treatment-revealing by nature, so access is the design question |
| Central laboratory | Laboratory results, units, methods, ranges | Identity by sample, and method or range changes mid-study |
| LIMS | Specimen and assay handling within the organization | Specimen chain of custody has to survive into the analysis dataset |
| EHR | Routine care records, where permitted and consented | Collected for care, so provenance and permitted use govern everything |
| Safety database | Cases, coded events, regulatory reporting | Reconciliation with EDC is a standing obligation, not a pre-lock task |
Write the transfer specification before the vendor starts sending. Most external data pain traces to a transfer specification that was thin, agreed late, or inherited from a previous study and never checked. A specification worth having states the file format and delivery mechanism, the exact identifiers and how they map to yours, the units and the precision, the method and reference range metadata, the handling of reruns and corrections, the expected schedule and what happens when it slips, and who is called when a transfer fails. It takes a day to write and it removes the majority of the reconciliation work that would otherwise accumulate for the life of the study.
Trust and compliance
An audit trail that records the change without explaining it is half a control
Clinical trial data carries obligations from the moment it is collected, and they travel with it through every transformation and into every analysis dataset. Which frameworks apply to a given system, how it is classified and what validation it requires are determined by your quality, regulatory and clinical functions. Our role is to build so that the controls they specify are enforceable and the evidence they need exists.
Frameworks where they apply
- ICH E6 Good Clinical Practice principles for the conduct of clinical research
- GxP and GAMP 5 where a system supports a regulated activity
- FDA 21 CFR Part 11 and EU Annex 11 for electronic records and signatures where applicable
- CDISC structures and conventions where submission data is produced
Subject protection
- Informed consent scope honoured in every downstream use of the data
- HIPAA where protected health information is processed
- GDPR and equivalent regimes for personal data of subjects and site staff
- Study blinding enforced per user at row and column level, including for data staff
Data integrity
- Attributable, legible, contemporaneous, original and accurate, plus the complete and enduring extensions
- Audit trail capturing who, what, when, the prior value and the stated reason
- Traceability from any analysis value back to the source record
- Controlled correction, with no silent overwrite anywhere in the chain
Assurance
- Validation scoped to intended use, as classified by your quality function
- Transformation specifications reviewed and approved before they are relied upon
- Change control covering mappings, checks and derivations as the study evolves
- Re-validation triggered by protocol amendment, source change or standard revision
Continuous quality
You cannot measure completeness without knowing what should exist
Completeness is reported as a percentage of expected data received, and the expectation is frequently derived from what arrived rather than from the protocol. A visit that was never scheduled in the system does not appear as missing. A form that was not triggered does not appear as absent. The gap is invisible precisely because the system does not know it should be there.
| Failure | How it presents |
|---|---|
| Expected data is unknown | Completeness reads high because the denominator came from what arrived |
| A protocol amendment lands mid-study | New forms and changed definitions hit mappings and checks nobody revisited |
| An EDC build change alters structure | Extraction succeeds against the old shape and a field silently empties |
| A laboratory changes method or range | Values stay plausible and stop being comparable with earlier ones |
| A vendor transfer repeats or corrects silently | Records duplicate or change and the reconciliation was run before the correction |
| Identity drifts across vendors | Match rates fall, unmatched records grow, and the matched portion stops being representative |
| Coding is incomplete late | Lock readiness looks acceptable until the coding backlog surfaces |
| A query was closed without resolution | The count improves and the underlying discrepancy remains in the data |
Outcomes
Judge it by whether the lock date stopped being a negotiation
Clinical data programmes are measured on cycle times and query counts. The outcome that matters to everybody above the data function is whether a committed lock date holds, and whether the study team knew it would.
| Outcome | How to tell |
|---|---|
| Data quality improved | Discrepancies found on arrival rather than during pre-lock review |
| Data cleaning accelerated | Query volume falling because fewer are generated, not only because closure is faster |
| Manual effort reduced | Reconciliation and completeness reporting run automatically and are trusted |
| Study oversight strengthened | Enrolment, site performance and data flow read from one continuous view |
| Submissions supported | Traceability and transformation documentation exist as a product of the work |
| Lock dates hold | Readiness was visible eight weeks out and the date was set against it |
| The next study is cheaper | Query causes, mapping gaps and transfer failures fed back into its design |
Improve clinical data quality, accelerate cleaning and make lock dates defensible
We work with pharmaceutical, biotechnology and CRO organizations on the data layer of clinical development: EDC and operational integration, external vendor data reconciled on arrival, mapping designed while collection can still change, traceability retained, blinding enforced where it has to hold, and lock readiness visible continuously. Your clinical data management, biostatistics and medical functions own the data and the decisions.
Why choose CaliberFocus for Clinical Trial Data Solutions?
CaliberFocus works on the data layer of clinical development for pharmaceutical, biotechnology and CRO organizations. We integrate EDC and operational systems, reconcile external vendor data on arrival, design the mapping while collection can still change, retain traceability, enforce blinding where it has to hold, and keep lock readiness visible continuously, in support of your clinical data management, biostatistics and medical functions.
- Query volume analysed by the field and check that caused it
- External vendor data reconciled on arrival, at value level
- SDTM mapping designed before first patient in
- Lock readiness visible continuously, not assembled late
Security & Compliance
