The number that killed the trial

The primary endpoint: change in LDL cholesterol from baseline to week 12.

Subject 2103, Site 031. Baseline LDL: 142 mg/dL. Week 12 LDL: 42 mg/dL. A 70% reduction. The drug worked.

Except it didn't. The site coordinator mistyped 142 as 42. Nobody caught it until database lock. The site couldn't find the source document. The data point was excluded from analysis.

One data point. In a trial powered for 85% enrollment, every exclusion matters. This one contributed to a failed primary endpoint. The drug that might have helped millions never reached them.

Bad data doesn't just slow trials down. It kills them.

Catch errors at entry, not at lock

The coordinator enters 42 mg/dL. The edit check fires: "LDL value <50 requires confirmation. Previous value was 142. Please verify."

The coordinator checks the source document. 142. They correct it. The query never opens. The data manager never sees it. The correct value enters the database on the first try.

This is what edit checks do. Not catch errors after they happen—prevent them from happening.

In Seal, edit checks fire in real time:

• Range checks — Physiologically impossible values flagged immediately
• Cross-field logic — If pregnant, age cannot be <12 or >55
• Temporal logic — Date of death cannot precede date of randomization
• Cross-visit logic — LDL cannot drop 70% without explanation

The site sees the warning before they save. They fix it before it becomes a query.

eCRF design that enforces your protocol

Your protocol says: collect vital signs at every visit, adverse events whenever reported, concomitant medications at baseline and changes thereafter.

The eCRF should enforce this—not as a checklist, but structurally. Visit 4 cannot be marked complete without vital signs. An AE form must exist before an SAE can be reported. Medication changes require start dates.

In Seal, eCRF design is protocol-driven:

• Required fields cannot be skipped
• Conditional logic shows only relevant fields. No pediatric forms for adults.
• Visit dependencies ensure data flows in order
• Edit checks validate against the protocol, not just ranges

Queries that resolve, not accumulate

The data manager reviews incoming data. Subject 2847, Visit 6: heart rate 32 bpm. That's bradycardia—clinically significant. But was it entered correctly?

Query opened: "Heart rate 32 bpm at Visit 6. Please verify against source and confirm if this triggered an AE."

In legacy systems, this query sits for weeks. The site forgot to check. The data manager escalated. The monitor mentioned it at the next visit. Eventually it resolves.

In Seal, queries are urgent:

• Auto-escalation if not addressed within N days
• Site portal surfaces open queries prominently
• Email reminders to coordinators with direct links
• Query aging reports for study management

Queries resolve because ignoring them becomes harder than answering them.

Lock the database, ship the data

Before analysis, the database must be locked. All queries resolved. All coding complete. All SAEs reconciled. Medical review finished.

Seal enforces lock prerequisites systematically:

• Zero open queries — Can't lock with unresolved questions
• Complete coding — Every AE has a MedDRA term, every medication a WHO Drug code
• SAE reconciliation — EDC matches safety database
• 100% SDV on critical fields (if required by protocol)

When prerequisites are met, lock is one click. The audit trail captures who locked, when, and under what conditions. Data becomes read-only—changes require formal amendment with full documentation.

CDISC from the start

Regulatory submission requires CDISC formats: CDASH for collection, SDTM for submission, ADaM for analysis.

Most teams scramble to map their data after collection. Non-standard variable names. Inconsistent codelists. Manual transformation.

Seal builds CDISC compliance into collection:

• CDASH-aligned forms — Variable names match the standard
• Controlled terminology — Codelists from CDISC, not custom
• Automated mapping — eCRF fields map to SDTM domains automatically
• Export validation — Conformance checked before export

When you lock the database, the SDTM datasets are ready. No post-hoc cleanup. No mapping errors. Data that regulators expect in the format they expect.

The clinical ecosystem, connected

EDC doesn't exist alone:

• CTMS — Subject visits drive expected eCRF completion
• IRT — Randomization results flow into EDC
• Safety database — SAEs reconcile automatically
• Central labs — Results import without transcription
• eTMF — Source documents link to data points

In Seal, these connections exist by default. Events in one system trigger actions in others. A randomization creates the subject in EDC. An SAE creates a case in safety. A lab result populates the eCRF.

The trial runs as one system, not seven.