Skip to content
TechSol Clinical Domain

Platform scope and promotion ledger

Status vocabulary

Section titled “Status vocabulary”
Status Meaning
Proposed Core Required by the greenfield Platform + EDC + eTMF target, but awaiting product approval
Candidate Credible evidence exists; a current scenario or architecture decision is still missing
Extension pressure Real behavior that must remain possible but is outside the initial model
Deferred Intentionally outside current Platform/EDC/eTMF scope
Rejected Considered and deliberately excluded from Platform

Status does not claim implementation. “Proposed Core” is a review classification only.

Object and archetype ledger

Section titled “Object and archetype ledger”
ID Concept Owner Archetype Aggregate root Promotion reason Required scenario Status
PLAT-OBJ-001 Workspace Account & Environment Entity / boundary coordinate No Every identity and authority decision needs a customer boundary All scenarios Proposed Core
PLAT-OBJ-002 ProductEntitlement Account & Environment Aggregate Yes Independent operational eligibility and withdrawal evidence Enable/disable product Proposed Core
PLAT-OBJ-003 Principal Identity & Access Aggregate Yes Acting identity survives credential and access changes PI access; system delivery Proposed Core
PLAT-OBJ-004 AuthenticationBinding Identity & Access Entity Within Principal policy boundary External authentication identity is independently revocable Disable/rebind account Proposed Core
PLAT-OBJ-005 ProductActionDefinition Owning product Published Definition Product-owned Access requires stable action meaning and allowed scope kinds Assign EDC/eTMF authority Proposed Core
PLAT-OBJ-006 RegisteredActionCatalogue Identity & Access Projection/compatibility registry No Platform must validate product action compatibility without owning meaning Define/revise Role Proposed Core
PLAT-OBJ-007 RoleDefinition Identity & Access Aggregate / Definition Yes Stable product-bounded grant bundle with immutable revisions Revise Data Manager Role Proposed Core
PLAT-OBJ-008 RoleRevision Identity & Access Immutable Definition Revision Contained by Role Historical authority must pin exact evaluated meaning Any regulated command Proposed Core
PLAT-OBJ-009 AccessAssignment Identity & Access Aggregate Yes Effective-dated, independently revocable scope grant PI/site access Proposed Core
PLAT-OBJ-010 AccessDecision Identity & Access Decision / evidence value No Accepted/refused command must reconstruct evaluated authority Every protected command Proposed Core
PLAT-OBJ-011 Organization Party Registry Aggregate Yes Stable legal/operating party identity across Studies Register Sponsor/Site operator Proposed Core
PLAT-OBJ-012 PersonProfile Party Registry Aggregate Yes Study responsibility may predate or outlive an account Add Principal Investigator Proposed Core
PLAT-OBJ-013 Site Party Registry Aggregate Yes Reusable operational location differs from Study participation Associate Site to Study Proposed Core
PLAT-OBJ-014 Study Study Registry Aggregate Yes Canonical suite coordinate independent of product roots Enable EDC/eTMF Proposed Core
PLAT-OBJ-015 CountryReference Study Registry Governed reference value No Study Country requires stable country identity Plan Study Country Proposed Core
PLAT-OBJ-016 StudyCountry Study Registry Aggregate Yes Country-level access and eTMF filing need independent identity Country filing scope Proposed Core
PLAT-OBJ-017 StudySite Study Registry Aggregate Yes Site-level access and both products require immutable Study-specific identity EDC Site/eTMF Site scope Proposed Core
PLAT-OBJ-018 ResponsibilityDefinition Clinical Coordination Governed Definition No separate lifecycle initially Party-kind and scope rules cannot be free text Add Study Party Proposed Core
PLAT-OBJ-019 StudyPartyParticipation Clinical Coordination Aggregate Yes Effective responsibility has independent evidence and replacement semantics PI replacement Proposed Core
PLAT-OBJ-020 StudyProductEnablement Suite Composition Aggregate Yes Cross-owner enable/disable needs retained operation identity Enable eTMF; proposed EDC seam Proposed Core
PLAT-OBJ-021 product-owned EdcStudy / EtmfStudy reference EDC / eTMF External reference contract No Platform must acknowledge but never own product root Product enablement Proposed Core boundary
PLAT-OBJ-022 ContentItem Content Aggregate Yes Stable provenance and retention coordinate across immutable revisions eTMF filing; EDC import Proposed Core
PLAT-OBJ-023 ContentRevision Content Immutable Entity Contained by Content Item Exact bytes, digest and provenance must be addressable Bind verified revision Proposed Core
PLAT-OBJ-024 ContentVerificationDecision Content Decision No Verification may change without mutating immutable revision bytes Quarantine/release Proposed Core
PLAT-OBJ-025 ContentBinding Content Retained association evidence Within Content Item Same content has no product meaning until exact owner-purpose binding eTMF document / EDC import Proposed Core
PLAT-OBJ-026 EvidenceEnvelope Evidence & Audit Immutable Value Object No Owner facts need consistent actor, authority, time and lineage Every regulated mutation Proposed Core
PLAT-OBJ-027 ElectronicSignatureEvidence Evidence & Audit Decision evidence mechanism No Exact signer, product-supplied meaning, time and revision must remain bound EDC attestation / eTMF approval Candidate pending product command
PLAT-OBJ-028 StudyMilestone Study Timeline Aggregate Yes One narrow shared date fact supports more than one product Site Activated Proposed Core, narrow
PLAT-OBJ-029 MilestoneTypeDefinition Study Timeline Governed Definition No separate lifecycle initially Scope/source/uniqueness rules require governed meaning Site Activated Proposed Core, one type
PLAT-OBJ-030 DevelopmentProduct Development Product Registry Aggregate Yes Stable asset identity may be shared without supply/safety semantics Study Intervention reference Candidate pending current EDC/eTMF scenario
PLAT-OBJ-031 StudyIntervention Development Product Registry Aggregate Yes Study/product/role association may require independent contract identity Product references in EDC/eTMF Candidate pending current EDC/eTMF scenario
PLAT-OBJ-032 ProductConnectionContractRevision Integration Contracts Code-published immutable contract descriptor No Source/target meaning and mapping must be version-pinned Enablement and correction delivery Proposed Core descriptor
PLAT-OBJ-033 ProductFactDelivery Work & Integration Mechanisms Mechanism aggregate Yes Retry/refusal/reconciliation must be retained independently Late/out-of-order delivery Proposed Core for first connection

Candidate ledger

Section titled “Candidate ledger”
Concept Evidence Missing before promotion
Explicit Environment domain identity Mature suites isolate validation/training/production Decide whether this is domain identity or deployment topology
Principal–Person Profile link Useful for responsibility prerequisites Identity governance, privacy and cardinality decision
Organization affiliation/contact models Useful directory behavior Current EDC/eTMF scenario and lawful shared data set
Site address revision and canonical timezone Operationally important Decide canonical versus Study/product-specific ownership
Duplicate-candidate and merge-decision aggregates Common operational problem Supported object types, authority and reversible lineage
Retention Assignment / Legal Hold Regulatory evidence Product-owner instruction contract and concrete disposition scenario
Certified Copy Verification Regulatory evidence EDC/eTMF copy-production scenario and owner
Break-glass Access Assignment Security extension pressure Approval, expiry, monitoring and evidence policy
Service-provider engagement GCP responsibility evidence Platform vs future CTMS/Quality ownership
Computerised-system intended-use/validation model Assurance evidence Product scope and ownership decision

Rejected Platform concepts

Section titled “Rejected Platform concepts”
Rejected concept Reason
Universal Document Content identity and eTMF Document meaning have different owners
Universal Workflow or state machine Similar transitions do not establish shared clinical meaning
Universal Task / WorkItem Product work and technical delivery have different authority and completion rules
Universal Approval Approval meaning, prerequisites and evidence are product-owned
Universal Requirement / Rule EDC validation and eTMF expectation semantics are not interchangeable
Generic Party aggregate Organization and Person Profile have different fields and governance
Global clinical Participant Subject identity and privacy remain product/study scoped
Platform-owned Product Participation Platform owns enablement coordination; EDC/eTMF own product roots
Tenant-wide compliance flag Compliance depends on intended use, configuration, process and evidence
Arbitrary custom clinical object Hides identity, ownership and lifecycle rather than modelling them

Context exclusions

Section titled “Context exclusions”

Platform does not own protocol objectives, endpoints, arms, epochs, schedule of activities, EDC design, Casebooks, Subjects, Datapoints, Queries, review/lock semantics, eTMF Filing Plans, Expectations, Filing Slots, TMF Documents, quality decisions or completeness.