Review candidate v0.2
What is being reviewed
Section titled “What is being reviewed”This is no longer a list of clinical nouns. Version 0.2 makes falsifiable decisions about identity, ownership, lifecycle, and behaviour. The reviewer is being asked whether these decisions reflect how a serious clinical suite should behave—not whether the page is readable.
The executable TypeScript reference is in src/domain. It contains no database, API, UI,
workflow engine, or vendor-specific extension mechanism.
Twelve decisions to challenge first
Section titled “Twelve decisions to challenge first”| ID | Proposed decision | Why it matters |
|---|---|---|
| D-001 | Study is a stable undertaking; StudyVersion carries versioned scientific design |
A protocol amendment must not create a new Study |
| D-002 | StudyCountry is the participation of a country in a Study, not a country master record |
Country-level approvals, milestones, and activation have a proper owner |
| D-003 | StudySite is the participation of a Facility in a Study |
The same hospital can take part in multiple studies without identity collision |
| D-004 | Site state is operational; enrollment permission is a separate decision | An active site can be temporarily closed to enrollment without being deactivated |
| D-005 | Participant is study-scoped; a human identity is outside the clinical-operations spine |
Subject identity cannot leak across studies by default |
| D-006 | Consent, eligibility, enrollment, randomization, and disposition are separate decisions | A single “subject status” cannot erase why a participant reached a state |
| D-007 | Planned EncounterDefinition and actual SubjectVisit are different objects |
Protocol design does not mutate when a visit occurs late, repeats, or is unscheduled |
| D-008 | DataPoint owns entered clinical value and revision state; CTMS consumes milestones, not the value |
Operational reporting does not become a second EDC |
| D-009 | A protocol deviation is a confirmed classification of an occurrence against an applicable rule | Every operational issue is not automatically a deviation |
| D-010 | MonitoringVisit owns visit conduct; TripReport is evidence produced by it |
A document lifecycle cannot substitute for the monitoring lifecycle |
| D-011 | EssentialRecord is the regulated record expectation/instance; DocumentVersion is content evidence |
TMF semantics do not collapse into generic document metadata |
| D-012 | Cross-domain change happens through named facts with source ownership | “Shared object” does not mean every application may edit it |
Canonical modelling template
Section titled “Canonical modelling template”Every promoted object must answer all nine questions:
- Identity: what remains the same across correction and revision?
- Owner: which bounded context may decide its meaning?
- Fields: which values are intrinsic, typed, and cardinality-controlled?
- Relationships: which objects are owned children and which are references?
- Lifecycle: which states are real domain distinctions?
- Commands: what intention can be submitted to it?
- Invariants: what must always remain true?
- Outcomes: what named fact follows an accepted command?
- Refusals: why can an otherwise understandable command be rejected?
If an entry cannot answer these questions, it remains a term in the language—not a domain object.
Review sequence
Section titled “Review sequence”Review in dependency order:
Study definition → Study participation → Site startup → Participant conduct → Clinical data → Monitoring → Essential records
Do not begin with reports, screens, or existing application boundaries. First decide whether the objects and rules are true. Application packaging comes later.