EDC domain model

Product boundary

EDC designs the study’s collection structure, instantiates a casebook for each subject, captures site-reported data, runs rules, manages queries and review, records signatures and audit history, and governs freeze and lock. It does not own site activation, treatment allocation, the safety-case decision, or TMF completeness.

Recognizable EDC hierarchy

The established execution hierarchy is Study → Site → Casebook → Event Group → Event → Form → Item Group → Item. It also explicitly uses both Subject and Casebook: Subject represents the participating person within the Study; Casebook contains the study-execution records for that Subject.

The TechSol model preserves that language:

Study
└── StudySite
    └── Subject
        └── Casebook                         one adopted Casebook Definition version
            ├── EventGroupInstance           visit-cycle/repeating-group occurrence
            │   └── EventInstance            dated planned or unscheduled event
            │       └── FormInstance         placed CRF occurrence
            │           └── ItemGroupInstance
            │               └── Item         current value + revision history
            ├── Query
            ├── Review
            ├── Signature
            └── ProtocolDeviation

Subject and Casebook are separate objects. A subject can acquire a later Casebook Definition version through an amendment, but collected occurrences remain traceable to the definition version under which they were created.

Study design model

EDCStudyDesign
├── CasebookDefinitionVersion
│   ├── EventGroupDefinition
│   │   └── EventDefinition
│   │       └── FormPlacement
│   ├── FormDefinition
│   │   └── ItemGroupDefinition
│   │       └── ItemDefinition
│   ├── Codelist / UnitCodelist
│   ├── RuleDefinition
│   ├── ReviewPlan
│   ├── SignatureDefinition
│   └── SubjectStatusDefinition
└── Deployment
    └── AmendmentPlan

Object	Identity and fields	Commands and invariants
`CasebookDefinitionVersion`	study, version, schedule, state, predecessor	validate, publish, retire; published content is immutable
`EventGroupDefinition`	OID, label, repeatability, maximum, included events	group events into a cycle; repetition produces sequences, never copied definitions
`EventDefinition`	OID, type, planned/unscheduled eligibility, visit method	place forms; actual date belongs to Event Instance
`FormDefinition`	OID, name, version, item groups	reusable independently of schedule placement
`ItemGroupDefinition`	OID, repeatability, item order	every Item Definition belongs to a group
`ItemDefinition`	OID, datatype, question, requiredness, range, codelist/unit	typed values only; incompatible datatype change requires a new version
`RuleDefinition`	expression, evaluation scope, action, targets, state	action is explicit: query, derive, set status, add event group/event/form, email, review override
`ReviewPlan`	review type, selection criteria, required scope	decides expected SDV or DMR coverage, not completion itself
`SignatureDefinition`	attestation meaning, signable scope	a signature binds signer, attestation and exact signed revision set
`Deployment`	source build, destination environment, validated package, decision	production publish is distinct from subject amendment adoption
`AmendmentPlan`	deployed version, site/subject scope, change classification	refuses destructive adoption where existing data makes the change unsafe

Execution objects and states

Object	State / behaviour
`Subject`	subject number, site, status, status history; status is governed by named transitions or rules
`Casebook`	created under one definition version; adopts a later version through an amendment decision
`EventGroupInstance`	sequence identity for repeating cycles; dynamic groups may be added or removed only while empty
`EventInstance`	expected, in progress, submitted, did-not-occur, inactive; owns event date and visit-method occurrence
`FormInstance`	`blank → in-progress → submitted → in-edit`; reset is explicit and audited
`Item`	current typed value plus ordered revisions; intentional blank is a meaningful assertion
`Query`	`open → answered → closed`, with governed reopen; system and manual origin are distinguished
`Review`	SDV or DMR decision against an exact Item/Form/Event revision; change breaks the review
`Signature`	applies at Form, Event or Casebook scope; a subsequent relevant data change invalidates it
`Freeze`	prevents data change while allowing queries, signatures and review activity
`Lock`	prevents data change at Item/Form/Event/Casebook/Site/Study scope until an audited unlock

Item value and audit model

type ItemValue =
  | { kind: 'text'; value: string }
  | { kind: 'integer'; value: number }
  | { kind: 'decimal'; value: number; unit?: CodedTerm }
  | { kind: 'date'; value: string; precision: 'day' | 'month' | 'year' }
  | { kind: 'coded'; code: string; decode: string; codelistVersion: string }
  | { kind: 'boolean'; value: boolean }
  | { kind: 'intentional-blank'; reason: CodedTerm };

Every accepted value change records the prior value, next value, reason for change, actor, source, clinical occurrence time, entry time, and revision. Query, SDV, DMR, signature, freeze and lock events are separate audit events; they are not flags overwritten on the Item.

Rule outcomes

Rules evaluate submitted data in a precise Casebook context and may produce:

SystemQueryOpened
ItemValueDerived
SubjectStatusChanged
EventGroupAdded / EventAdded / FormAdded
DynamicComponentRemovalRequested
ReviewRequirementOverridden
ProtocolDeviationProposed
NotificationRequested

A false dynamic rule may remove a generated component only when its execution records are blank. Otherwise it creates a removal conflict requiring deliberate resolution.

Cross-vertical facts

EDC consumes: StudyActivatedForEDC, StudySiteActivated, StudySiteLocked, SubjectScreenedInRTSM, SubjectRandomized, controlled terminology, lab transfers, eCOA transfers.

EDC publishes: SubjectCreated, SubjectStatusChanged, SubjectVisitChanged, ProcedureChanged, ProtocolDeviationChanged, ReviewCoverageChanged, CasebookLocked, StudyLocked, StudyDataExtractProduced, EndOfStudyMediaProduced.

The CTMS projection may show Subjects, Subject Visits, Procedures, milestone dates and review coverage. It does not become the owner of the source EDC records.

Product evidence → TechSol decision

Observed product behaviour	TechSol decision	Difference requiring review
Creating a Casebook creates Subject and execution records	`CreateCasebook` is an aggregate command that produces Subject + Casebook + initial schedule outcomes	Should Subject exist before a Casebook when RTSM screens first?
Published designs instantiate execution objects	Definitions and instances are different types with immutable version references	Eager creation versus derived/lazy schedule materialization is not yet decided
Repeating Event Groups create sequences	`EventGroupInstance.sequence` is part of occurrence identity	Can sequences ever be renumbered after entry?
Dynamic rules add/remove groups, events and forms	Structural rule actions are first-class outcomes	Nonblank removal becomes conflict, never silent deletion
Queries are Open, Answered, Closed	Query owns a conversation lifecycle	Whether response is a child entity or ordered value remains open
SDV/DMR can break after data changes	Review decision binds an exact revision	Material-change policies may preserve some reviews; requires policy evidence
Form/Event/Casebook signatures invalidate on change	Signature binds immutable scope manifest	Exact invalidation propagation must be scenario-tested
Freeze permits other data-management activity	Freeze and Lock are separate decisions	Scope precedence across nested levels must be specified

Standards alignment

The collection and exchange semantics are cross-checked against CDISC ODM v2.0.