EDC domain model

Review status

Proposed greenfield model — ready for clinical data-management review, not yet accepted.

This model describes what an Electronic Data Capture product must know and protect throughout a clinical trial. It is written for study designers, clinical programmers, site users, monitors, clinical data managers, medical coders, investigators, and database-lock leads.

It describes clinical records and actions. It does not prescribe a database, API, screen, programming language, or workflow engine.

What EDC is responsible for

EDC is responsible for five connected areas of work:

1. translating the protocol and data-management plan into an approved collection design;
2. making the correct design available to each activated site;
3. creating and maintaining each subject’s casebook;
4. cleaning, reviewing, coding, signing, freezing, and locking reported clinical data; and
5. producing traceable data cuts, extracts, casebook copies, and end-of-study deliveries.

EDC does not own the person’s real-world identity, the clinical trial master file, treatment allocation, investigational-product inventory, the safety-case decision, or the statistical analysis. It exchanges explicit facts with the products that own those responsibilities.

EDC may detect a Potential Protocol Deviation from casebook data, timing, or rules. It publishes the supporting subject/event facts to the owning deviation-management process. That process—not EDC—decides classification, significance, reportability, corrective action, and final disposition.

The model in clinical language

EDC Study
├── Approved Study Designs
│   ├── Protocol Schedule
│   │   ├── Periods and Cycles
│   │   └── Visits / Data-Collection Events
│   │       └── CRF Placements
│   ├── CRF Definitions and Placements
│   │   └── Item-Group Definitions and Placements
│   │       └── Item Definitions and Placements
│   ├── Codelists and Units
│   ├── Conditions, Derivations, and Edit Checks
│   └── Review, Coding, and Signature Plans
├── EDC Sites
│   └── Subjects
│       └── Casebook
│           ├── Visit / Event Occurrences
│           │   └── CRF Occurrences
│           │       └── Item-Group Rows
│           │           └── Datapoints and Corrections
│           ├── Queries
│           ├── SDV and Data-Management Review
│           ├── Medical Coding
│           └── Signatures, Freezes, and Locks
└── Database-Lock Decisions and Data Deliveries

The terms above are deliberately familiar. A visit is used when the protocol describes a visit. A data-collection event covers unscheduled contacts, phone calls, survival follow-up, diary periods, and other occurrences that are not visits.

Responsibility map

Work area	EDC is the source of truth for	EDC receives from elsewhere
Study build	CRFs, visits, collection rules, design publications, site assignments and casebook adoptions	Study identity, protocol and amendment references, controlled standards
Site readiness	EDC activation, active design at the site, EDC suspension and closure	Canonical site identity and evidence that external approvals are satisfied
Subject conduct	EDC subject number, screening record, casebook, visit/form occurrences and EDC disposition	Randomization and treatment facts when owned by RTSM; eCOA or laboratory data when externally originated
Clinical data	Reported values, missing-data assertions, corrections and EDC audit history	Traceable imported data with origin and transfer evidence
Data quality	Edit-check findings, queries, SDV, data-management review and coding decisions	Monitoring plan, coding dictionaries, external reconciliation results
Finalization	Freeze, investigator signature, scoped lock, database lock, reopen and relock	Analysis purpose, external-data readiness and accountable approvals
Delivery	Data cuts, extracts, audit exports, casebook copies and delivery inventories	Required exchange or submission specifications

Review specification

Read these pages in order:

1. Study build and CRF design — the approved collection design, its records, fields, actions, and publication rules.
2. EDC roles and permissions — feature visibility and exact actions for study build, site entry, query, review, coding, signature, freeze, lock and export work.
3. Schedule and dynamic collection — visits, cycles, windows, repeating data, conditions, derivations, and dynamic forms.
4. Sites, subjects, and casebooks — EDC activation, screening, enrollment, subject disposition, and casebook creation.
5. Data entry, missing data, and audit — values, partial dates, invalid input, corrections, data origin, and reconstruction.
6. Edit checks and queries — discrepancy detection and the site conversation used to resolve it.
7. SDV, data review, coding, and signatures — four different kinds of clinical evidence that must not be collapsed into one review flag.
8. Freeze, record lock, and database lock — temporary control, final edit restriction, study finalization, exceptional reopen, and relock.
9. Amendments, external data, and exports — controlled mid-study change, imported data, reconciliations, and reproducible deliveries.
10. Verification scenarios — realistic cases the proposed model must explain without hidden behavior.
11. Product decisions — settled proposals and questions requiring clinical-product approval.

Important distinctions

Do not collapse	Why it matters
Subject and casebook	The subject is the participant record; the casebook is the protocol-driven collection record assigned to that subject.
CRF definition and CRF placement	One reusable CRF can appear at several visits with different contextual requirements.
Item-group/item definition and placement	Reusable clinical meaning stays stable while CRF-specific order, wording, requiredness, applicability and repetition belong to the placement.
Definition and occurrence	“Week 4 Visit” is a design definition; Subject 104’s Week 4 visit is an occurrence.
Blank, unknown, not done, and invalid	They answer different clinical questions and have different query and analysis consequences.
Edit-check finding and query	A finding is detected by a rule; a query is an accountable conversation with the site.
Review plan and completed review	A plan selects what needs review; review evidence says what exact data was reviewed.
SDV and data-management review	One compares reported data with source; the other assesses clinical and logical data quality.
Signature, freeze, and lock	They are independent investigator, operational-control, and finalization decisions.
Form lock and database lock	A record-level edit restriction is not the sponsor’s study-wide declaration that data are ready for analysis.
Data cut and database lock	An interim reproducible cut may be produced while the study remains open.

Standards position

• CDASH guides consistent clinical data collection and traceability to submission.
• CDISC ODM is an exchange and archival representation for study metadata, clinical data, and audit information.
• SDTM is primarily a tabulation and submission model.
• ICH E6(R3) supplies the governing expectations for data capture, metadata, corrections, review, finalization, computerized systems, and investigator endorsement.

These standards inform the model but do not automatically become internal product objects.

Acceptance rule

The model is acceptable only when a clinical reviewer can answer, for every important record:

1. What does it mean in trial conduct?
2. Who is responsible for it?
3. What information does it carry?
4. What actions can be taken and by whom?
5. What must always remain true?
6. What happens after correction, amendment, signature, or lock?
7. What evidence allows the trial to be reconstructed?
8. Which difficult scenario proves that the distinction is necessary?