Clinical EDC.

1A clean database needs one record of change.

Electronic data capture turns a protocol into patient-level data and, eventually, an analysis-ready clinical database. Forms are only part of that work. Visit logic, edit checks, external feeds, coding, queries, corrections, reconciliation and lock all change the state of the data, and the database is only as trustworthy as the record of those changes.

Seal keeps each collected value linked to the protocol requirement it serves, the eCRF version that collected it, the subject and visit, the user or feed that supplied it, and every review, query, correction, derivation and coding decision that followed. Freeze and lock are then gated on that evidence rather than on a status someone sets.

1.1Why teams choose Seal for electronic data capture

A standalone EDC holds the collected values while protocol operations, sites, external data, safety, documents and quality live elsewhere, so the connections are rebuilt at every cleaning cycle and inspection. Seal owns the protocol-to-database state model and composes CTMS, eTMF, clinical operations, training and quality controls on the same records, and an amendment is a new eCRF version that keeps earlier data interpretable under the version that collected it. Data managers see why a subject or site is not ready from the record itself.

2The protocol defines the data contract.

Endpoints, populations, visits, windows, procedures and safety reporting establish what data must exist and when. Every form and field in Seal retains the protocol concept and the downstream use it serves, so a question about a field can be answered by pointing at the requirement behind it.

The study build is versioned. Events, forms, fields, codelists, derivations, edit checks, roles, integrations and export specifications move through design, test, approval, release and amendment together, and active subjects stay on the correct effective version.

Visit logic has to handle real subjects: unscheduled, repeating, missed and out-of-window visits, early termination, screen failure and re-consent. Dates and form expectations recalculate when those events occur without rewriting completion history that has already been recorded.

3Capture data at the site with its provenance intact.

Edit checks can run at entry or asynchronously: ranges, chronology, cross-form consistency, visit windows, dosing and eligibility. When a check fires, Seal retains the rule version, the inputs it evaluated, the message shown, the user’s action and any reason for override. A corrected value and a value that needs a query are different outcomes, and the record shows which occurred.

Site entry stays attributable. The user, role, site, subject, visit, field, original value, new value, time, reason and signature remain available for the life of the study; correcting a value does not replace its history.¹ Screening and randomised identities, treatment assignment and privacy restrictions stay separated according to who is permitted to see them.

4Reconcile, code and review against the source value.

Laboratory, imaging, ECG, eCOA, device, randomisation and drug-supply data arrive as transfers, not as rows that silently appear. Each transfer keeps its file identity, schema version, subject and visit matching, duplicates, rejected rows and transformations, so a late laboratory file or a mismatched subject identifier remains visible work.

Medical coding keeps the verbatim term, dictionary and version, coded term, reviewer and any manual choice linked to the source value. A dictionary upgrade identifies every term and output affected by the new version.

Safety reconciliation records matched, missing, discrepant and resolved cases without conflating the EDC with the safety system of record. Source-data review, source-data verification, medical review and data-management review remain distinct activities, with coverage set by field criticality and the monitoring strategy.²

5A query closes when the data is resolved.

A query records where it came from (an edit check or a reviewer), the field and evidence involved, the assignee, the site’s response, any proposed correction and the review that accepted or reopened it. Response volume and age are operational signals for follow-up; they are not the measure of whether the data is clean.

An answered query can still be waiting for data-management review. Seal keeps it open until the recorded data state changes, and keeps the full history when a closed query is reopened.

6Lock is a gated state, not a status.

Expected forms, missing fields, open queries, coding, external and safety reconciliation, protocol deviations, reviews and investigator signatures roll up by subject, site, country and study. The team can see why a subject or site is not ready while the work is in progress, rather than discovering it in the week before lock.

Derived values keep their algorithm, inputs, units, missing-data handling and version. A submitted dataset can be traced back through mapping and transformation to the collected or received value.

Freeze and lock depend on that evidence. Scope, outstanding work, approved exceptions, authorisation and any unfreeze or unlock keep their reasons and audit trail. When a protocol amendment changes forms or checks, Seal identifies the affected sites, subjects, integrations and mappings, and historical data remains interpretable under the configuration that collected it.

7Prove one complex subject path end to end.

Follow one subject through screening, randomisation, scheduled and unscheduled visits, a conditional repeating form, external laboratory and eCOA data, an edit-check query, coding, safety reconciliation, monitoring review, investigator signature, an amendment, freeze and lock.

Include a late laboratory file, a mismatched subject identifier, an overridden edit check, a reopened query, a dictionary upgrade and a post-freeze correction. Then check that the data and configuration used at every decision can be reproduced from the record.