Participant is the human subject in the trial-conduct realm. Anchored at StudySite (1..1; multi-Study participation = separate Participant entities). Operator-grounded vocabulary (screeningNumber, randomizationNumber, participantStatus, firstName) — not standards-shaped (no USUBJID column on the entity; SDTM is a projection edge). Lifecycle events as sub-objects: InformedConsent, ScreeningRecord, EnrollmentRecord, WithdrawalRecord — same pattern as SDTM DS records, surfaced as workflow events to the coordinator. participantStatus is an 11-state enum with NGSI-LD temporal-property semantics for queryable trajectory (twin-queryability discipline). USDM v4 has no per-subject runtime entity; cross-walk targets are FHIR R5 ResearchSubject, SDTM DM + DS + IE, CDASH DM. Pre-consent realm is the separate Recruit entity (see recruit-spec.html).
Per first-principles.md: a participant is a participant, full stop. Operators say "Mary." The foundation carries Mary in the operator's vocabulary. Standards (FHIR ResearchSubject, SDTM DM, CDASH DM, USDM design-side links) are projection edges below the line — adapters emit them, the operator never sees them.
Six rules from the first principles, applied here:
StudySite is the anchor (1..1), not Site. The OOUX Participant→1 Site direct edge is a correction surfaced during the Site spec lift (v0.2.0); applied here. Reasons:
Multi-Study participation = separate Participant entities. A real human enrolled in two Studies has two Participant records (one per Study × StudySite pair). Cross-Study identity resolution is federation, not foundation (Datavant tokens, MPI, deployment-edge trust).
Per FIRST-PRINCIPLES, the same human appears in different realms depending on which operator's lens. TOP carries one realm — trial conduct. The others are projection-adapter targets, not TOP entities.
| Realm | Operator role | Mary appears as | Standards projection |
|---|---|---|---|
| Recruitment | Recruiter / outreach coordinator | Recruit (TOP top-level; pre-consent funnel) | (no canonical standard) |
| Trial conduct | Study coordinator / PI / monitor | Participant (THIS spec) | FHIR ResearchSubject, SDTM DM/DS, USDM (no per-subject) |
| Standard care | Primary care nurse / treating physician | Patient (projection-only, not in TOP) | FHIR Patient, USCDI, OMOP PERSON |
| Claims / payer | Claims processor / payer ops | Claimant / Member (projection-only) | FHIR Claim / Coverage, X12 837 |
| Real-world evidence | Epidemiologist / RWE analyst | Patient (post-trial; projection-only) | OMOP CDM, Sentinel, PCORnet CDM |
This is the same projection-edge pattern as standards. Just as TOP doesn't carry FHIR-shaped Patient but emits Patient via the FHIR adapter, TOP doesn't carry Mary-as-Claimant but emits a Claimant view via a claims adapter. The foundation persists; the projections are ephemeral. Identity resolution across realms is federation, not foundation — Datavant tokens, master patient indexes, cross-realm trust agreements at the deployment edge.
A Participant — at every stage — must be spec-able as a digital twin. Twin synthesis is a major axis of research workflow now: synthetic control arms, in-silico trials, individual outcome prediction, shadow-enrollment dashboards. TOP's posture: digital twin is a projection lens, not an entity. The TOP Participant carries the foundation; a downstream twin synthesizer (computational, not part of TOP) reads from TOP and emits a twin representation.
What TOP guarantees so the foundation is twin-spec-able: every Participant — at every stage — is queryable along the dimensions a twin needs.
| Twin dimension | TOP source |
|---|---|
| Demographic foundation | Participant attributes (sex, dateOfBirth, race, ethnicity, country) |
| Disease state at entry | ScreeningRecord + Activity occurrences during screening (when Visit/Activity lift) |
| Treatment assignment | EnrollmentRecord + assignedToArm + protocolVersionAtEnrollment |
| Time-varying observations | Visit / Activity / Observation occurrences (when those lift) |
| Lifecycle state trajectory | participantStatus over time (NGSI-LD temporal property; sub-objects carry transition events) |
| Outcome trajectory | Endpoint values + AE occurrences (when those lift) + final state (COMPLETED / WITHDRAWN / DISCONTINUED) |
| Cross-realm context | Linked Patient (FHIR), Claimant (claims), historical Patient (OMOP) — at the deployment edge, not in TOP |
Twin-for-enrollment is the deferred game-changing use case. Real Recruits + synthetic-Recruits-from-twin populations + historical Participants from completed trials feed a unified twin synthesizer that predicts cohort composition, recruitment timeline, and drop-out risk before the trial opens. Enrollment is the most expensive bottleneck (80%+ trials miss timelines; ~30% trial cost is recruitment). Foundation decisions made in this spec (Decision 9 Recruit-as-separate-entity + Decision 10 twin-queryability) are the load-bearing pre-conditions; twin synthesis itself is computational infrastructure for v0.5+.
Prior art: PMDT (Patient Medical Digital Twin, El Gammal et al., under review at Software and Systems Modeling) is an OWL 2.0 ontology for chronic-care patient digital twins, validated in EU H2020 QUALITOP pilot with real-world immunotherapy patients. Validates the ontology-driven twin direction. PMDT serves chronic care (continuous, longitudinal); TOP serves trial conduct (bounded, protocol-driven). Adjacent realms; same human anchor; different operational tempos. PMDT is OWL 2.0 (DL-classical, SPARQL); TOP is NGSI-LD (broker-mediated, temporal-property). Both legitimate paradigms — TOP can export to OWL/RDF as another projection edge.
| Attribute | Type | Notes |
|---|---|---|
| participantId | NGSI-LD URI | Globally unique. Operators type the parts (screeningNumber + randomizationNumber); USUBJID is a SDTM-projection-time derivation. |
| screeningNumber | string | Site-assigned. Maps to SDTM/CDASH SUBJID. |
| randomizationNumber | string · optional | Sponsor-assigned at randomization. Often used for IP kit assignment. |
| randomizationDate | date · optional | Required when participantStatus=RANDOMIZED (SHACL hard). |
| firstName / middleName / lastName | string · optional | Operator-grounded. Identification-status-agnostic schema (Decision 2): same fields, deployment populates real or de-identified values. |
| dateOfBirth | date · optional | Real DOB / year-only / shifted depending on deployment. Maps to SDTM BRTHDTC. |
| sex | enum (5) | MALE / FEMALE / INTERSEX / UNKNOWN / NOT_REPORTED. Per ICH E5 / FDA. SDTM projection collapses INTERSEX → UNDIFFERENTIATED. |
| race | string · optional | Comma-separated for multiracial. Maps to SDTM RACE; SDTM uses MULTIPLE + SUPPDM RACEMUL. |
| ethnicity | enum (4) | HISPANIC_OR_LATINO / NOT_HISPANIC_OR_LATINO / NOT_REPORTED / UNKNOWN. CDISC controlled term. |
| primaryLanguage | ISO 639-1 · optional | Operator-grounded for site-coordinator UX. |
| country | ISO 3166-1 alpha-3 · optional | Multi-region trials. |
| participantStatus | enum (11) | NGSI-LD temporal property (validFrom/validUntil) for trajectory queryability. See Section 8. |
| enrollmentDate | date · optional | Single canonical Sponsor-assigned moment. Maps to SDTM RFSTDTC. |
| completionDate | date · optional | Soft SHACL: should be populated when participantStatus=COMPLETED. |
| withdrawalDate | date · optional | Most-recent-withdrawal convenience attribute; full history on WithdrawalRecord sub-objects. |
| validFrom / validUntil | dateTime · optional | NGSI-LD-native temporal properties; pattern from Sponsor / StudySite. |
| Relationship | Target | Card. | Notes |
|---|---|---|---|
| forStudySite | StudySite | 1..1 | The operational anchor. Per OOUX correction (was Site directly). |
| forStudy | Study | 1..1 | Reachable via forStudySite.forStudy traversal but kept direct for SHACL invariant simplicity. |
| assignedToArm | Arm | 0..1 | 0 pre-randomization; 1..1 once randomized. Cross-entity SHACL: Arm must belong to Participant.forStudy. |
| hasInformedConsent | InformedConsent | 0..N | Re-consent supported (after amendment / ICF version change / lapse-and-re-establish). |
| hasScreeningRecord | ScreeningRecord | 0..N | Re-screening attempts. |
| hasEnrollmentRecord | EnrollmentRecord | 0..N | Typically 1 per Participant. |
| hasWithdrawalRecord | WithdrawalRecord | 0..N | Multi-event support. |
| convertedFromRecruit | Recruit | 0..1 | Operational-funnel-side trace; empty for direct walk-ins. |
| hasVisit | Visit | 0..N | Flagged-missing (Visit lifts post-Participant). |
| hasAdverseEvent | Event | 0..N | Flagged-missing (Event lifts later). |
| hasTag | Tag | 0..N | Flagged-missing. |
| Sub-object | Role | Key attrs |
|---|---|---|
| InformedConsent | One consent event (ICH E6(R3) §2.4 GCP-required). | consentVersion, consentDate, consentMethod, consenterRelationship, consentStatus (OBTAINED/WITHDRAWN/EXPIRED/RECONSENTED), reconsentRequired |
| ScreeningRecord | One eligibility-screening attempt (ICH E6(R3) §2.5). | screeningStartDate, screeningEndDate, screeningOutcome, screenFailReason, failedInclusionCriteria, failedExclusionCriteria |
| EnrollmentRecord | The enrollment event (eligibility confirmed, on the trial). | enrollmentDate, enrollmentMethod (ON_SITE/REMOTE/HYBRID), enrollmentNumber, protocolVersionAtEnrollment |
| WithdrawalRecord | One withdrawal/discontinuation event. | withdrawalDate, withdrawalCategory (CONSENT_WITHDRAWN/INVESTIGATOR_DECISION/AE/LOST/etc.), withdrawalReason, continueDataCollection, withdrawnFromAllProcedures |
Sub-objects: InformedConsent, ScreeningRecord, EnrollmentRecord, WithdrawalRecord. Each carries its own dates, signatures, witnesses, document references, lifecycle status. Aligns with GCP audit-trail discipline (full event history); supports re-consent after protocol amendment, re-screening, multiple withdrawals if re-enrolled. Flat attributes would lose event-history audit fidelity.
Cross-walk validation: this decision lines up with both authoritative standards that DO model per-subject events. FHIR R5 ResearchSubject.progress is a 0..N list of state-change events (TOP sub-objects map 1:1). CDISC SDTM DS domain has every disposition event as its own DS record with DSDECOD controlled term. Sub-objects-as-events is the SDTM DS pattern.
Same fields exist (firstName, lastName, dateOfBirth); deployment populates real values for operator-facing systems and Datavant tokens / de-identified values for research-warehouse projections. The schema doesn't encode identification status — the deployment handles tokenization, date-shifting, and redaction at the boundary. Same posture as Site spec for de-identification.
Datavant + John Snow Labs are the canonical privacy-engineering layer. TOP is upstream of de-id; PHI engineering happens at the deployment edge.
Participant.forStudySite → StudySite (1..1). NOT Participant → Site directly. The OOUX has Participant pointing at 1 Site; correction tracked in Site spec, applied here. Reasoning per Section 3 (architectural anchor).
Person (TOP commons horizontal, lifted in v0.2.0) is for staff: investigators, coordinators, monitors, pharmacists, regulatory affairs. Participant is for trial subjects. Different role, different entity. Subject identity is bound to the Study; Person identity is independent of any Study.
Edge case: a study staff member who is also enrolled as a participant in the same study (rare; some Phase 1 dose-escalation studies have staff as healthy volunteers). In TOP, that's two entities — one Person record (staff role) and one Participant record (subject role) — backed by the same real human. The schema doesn't link them; that's deliberate (privacy-preserving).
Participant.assignedToArm → Arm (0..1) plus randomizationNumber and randomizationDate as Participant attributes. RandomizationRecord lifts as a sub-object in v0.5+ if studies with complex stratification or multiple-arm-reassignments warrant richer modeling.
SCREENING / SCREEN_FAILED / CONSENTED / ENROLLED / RANDOMIZED / ON_TREATMENT / IN_FOLLOW_UP / COMPLETED / WITHDRAWN / DISCONTINUED / LOST_TO_FOLLOW_UP. Operationally meaningful — operators distinguish all 11 in their daily workflow. State-machine SHACL invariants encode legal transitions. See Section 8.
Per FIRST-PRINCIPLES, the enum is operator-grounded (ON_TREATMENT, not on-study-intervention); cross-walk to FHIR ResearchSubjectStatus + SDTM DSDECOD lives in Section 9.
OOUX has Participant with 1 Study. TOP follows: each Study participation is its own Participant entity. A real human enrolling in two studies has two Participant entities. Cross-Study identity resolution (the same human across multiple Participant records) is federation, not foundation.
Direct on Participant: subject-bound facts (demographics, identifiers, lifecycle status, lifecycle sub-objects). Reached via traversal: Visit-occurrences (via Visit.atParticipant inverse, when Visit lifts), AEs (via Event.atParticipant), CRFs (via CRF.forParticipant), etc. Direct edges flagged-missing where target entity not yet lifted.
The recruitment realm has its own operator (recruitment coordinator), its own workflow, its own data shape (lighter than Participant — no consent, often only contact info + light eligibility pre-check), and a different PHI boundary. Per FIRST-PRINCIPLES (each operator role gets first-class entities), Recruit lifts as a separate top-level rather than as a pre-consent state on Participant.
Top-level count moves 8 → 9. Recruit→Participant transition is captured by Participant.convertedFromRecruit; the InformedConsent sub-object's existence on the Participant IS the canonical conversion event. See recruit-spec.html.
Every Participant lifecycle transition produces a queryable record so a downstream twin synthesizer can reconstruct the trajectory. Combination: (a) sub-objects for canonical events (Consent, Screening, Enrollment, Withdrawal — already in design), and (c) NGSI-LD temporal-property semantics with validFrom/validUntil bracketing on participantStatus for mid-trial state changes (RANDOMIZED → ON_TREATMENT → IN_FOLLOW_UP → COMPLETED).
The Sponsor entity already established the temporal-property pattern for relationship handoffs; Participant extends it to the lifecycle attribute itself. Broker layer answers "what was Mary's status on 2026-08-15?" cleanly.
Each state transition produces either a sub-object (Consent / Screening / Enrollment / Withdrawal — the canonical events) or a NGSI-LD temporal-property change on participantStatus (mid-trial transitions like ON_TREATMENT → IN_FOLLOW_UP). Trajectory is queryable downstream for digital-twin synthesis (Decision 10).
Every Participant attribute, relationship, and sub-object resolves to recognizable FHIR / CDISC structures. Cross-walks are projection-adapter rules, not entity-shape constraints.
| TOP attribute | SDTM DM | FHIR R5 | CDASH DM |
|---|---|---|---|
| screeningNumber | SUBJID | ResearchSubject.identifier (use=secondary) | SUBJID |
| randomizationNumber | (SUPPDM) | ResearchSubject.identifier | RANDNO (custom) |
| firstName/middleName/lastName | (PHI excluded) | Patient.name (linked via ResearchSubject.subject) | (not in CDASH) |
| dateOfBirth | BRTHDTC | Patient.birthDate | BRTHDAT / BRTHDD/BRTHMO/BRTHYY |
| sex | SEX (M/F/U/UNDIFFERENTIATED) | Patient.gender (male/female/other/unknown) | SEX |
| race | RACE | Patient.extension[us-core-race] | RACE |
| ethnicity | ETHNIC | Patient.extension[us-core-ethnicity] | ETHNIC |
| country | COUNTRY | Patient.address.country | COUNTRY |
| TOP participantStatus | FHIR R5 ResearchSubject.status | SDTM DS DSDECOD |
|---|---|---|
| SCREENING | screening | (no DS event during screening window) |
| SCREEN_FAILED | ineligible | SCREEN FAILURE |
| CONSENTED | pending-on-study | INFORMED CONSENT OBTAINED |
| ENROLLED | on-study | ENROLLED |
| RANDOMIZED | on-study | RANDOMIZED |
| ON_TREATMENT | on-study-intervention | (treatment events) |
| IN_FOLLOW_UP | follow-up | (follow-up start) |
| COMPLETED | off-study | COMPLETED |
| WITHDRAWN | withdrawn | WITHDRAWAL OF CONSENT |
| DISCONTINUED | off-study | DISCONTINUED |
| LOST_TO_FOLLOW_UP | off-study | LOST TO FOLLOW-UP |
TOP enum is a superset of FHIR ResearchSubjectStatus (FHIR collapses several operational states under on-study and off-study). TOP-to-FHIR mapping is many-to-one and well-defined; the inverse requires sub-object/DS context to disambiguate.
USDM v4 doesn't model per-subject runtime data (verified: cdisc-org/usdm/main/src/usdm_model/ has no study_subject.py; the closest entity SubjectEnrollment is aggregate-only — a planned-quantity entity for cohort/site/geo-scope, not per-subject). USDM is a study-definition model; per-subject data lives at FHIR / SDTM / CDASH layers.
What TOP Participant connects to USDM via:
Net: TOP carries USDM at the design layer (Study), CDISC SDTM at the analysis layer (DM/DS/IE), FHIR R5 at the operational/exchange layer (ResearchSubject + Consent + Patient), CDASH at the acquisition layer. No standards conflict; TOP is the operator-grounded foundation that all four standards project through.
| # | Severity | Constraint |
|---|---|---|
| 17 | Hard | Post-consent state requires consent. Any participantStatus in {ENROLLED, RANDOMIZED, ON_TREATMENT, IN_FOLLOW_UP, COMPLETED, WITHDRAWN, DISCONTINUED, LOST_TO_FOLLOW_UP} requires at least one InformedConsent with consentStatus=OBTAINED. ICH E6(R3) §2.4 GCP-required. |
| 18 | Hard | SCREEN_FAILED requires record. participantStatus=SCREEN_FAILED requires a ScreeningRecord with screeningOutcome=SCREEN_FAILED. |
| 19 | Hard | RANDOMIZED requires arm and date. participantStatus=RANDOMIZED requires both assignedToArm and randomizationDate populated. |
| 20 | Hard | WITHDRAWN requires consent-withdrawal. participantStatus=WITHDRAWN requires a WithdrawalRecord with withdrawalCategory=CONSENT_WITHDRAWN. WITHDRAWN is reserved for subject-initiated withdrawal; investigator-initiated uses DISCONTINUED. |
| 21 | Soft | COMPLETED needs date. participantStatus=COMPLETED should have completionDate populated. |
| 22 | Hard | Arm-Study consistency. Participant.assignedToArm must reference an Arm whose parent Study matches Participant.forStudy. |
| 23 | Hard | StudySite-Study consistency. Participant.forStudySite must reference a StudySite whose forStudy matches Participant.forStudy. |
Plus 2 new Recruit invariants (24 hard converted-needs-participant; 25 soft stalled-many-attempts) — see recruit-spec.html.
Mary consented under ICF v3.1. Protocol amended (new biomarker assay added with separate informed-consent implications). Site re-consents Mary under ICF v3.2.
Initial screening fails on lab criterion (out-of-range value). Per protocol re-screening rules, Participant returns 4 weeks later for new screen.
Mary withdraws consent for further IP administration but agrees to continue follow-up visits for safety data collection.
Investigator discontinues a Participant after a Grade 3 AE that meets the protocol's discontinuation criteria.
Mary responded to a digital ad in late February. Recruitment coordinator pre-screened, scheduled consent. On consent day at the site, coordinator converts.
Twin synthesizer (downstream tool) needs to know Mary's lifecycle state as of 2026-08-15.
Primary entity user. Creates Participant, conducts screening, manages re-consent, schedules visits. Sees Participant in operator-vocabulary terms; SDTM/FHIR projections happen at export-time. Cares about: contact info, current status, next-visit-date, consent-currency, AE-flagging.
Authority over EnrollmentRecord (eligibilityConfirmedBy 1..1) and DISCONTINUED transitions. Reviews ScreeningRecord outcomes. Cares about: cohort-level eligibility patterns, AE-related discontinuations, protocol-deviation-flagged participants.
Primary user of Recruit. Hands off to Site Coordinator at consent appointment (Recruit→Participant conversion). Cares about: funnel conversion rate, source-channel ROI, contact-attempt cadence.
Reads aggregate Participant counts per StudySite and per status. Cares about: targetEnrollment vs actualEnrollment, time-to-first-enrollment, drop-out rate by site.
Audits Participant records against site source documents during monitoring visits. Cares about: consent-form-vs-record consistency, randomization-date traceability, withdrawal-documentation completeness.
Reviews DISCONTINUED Participants and their WithdrawalRecord categories. Cares about: AE-related discontinuation rate, dose-modification patterns, cohort-vs-cohort safety profile.
GET /ngsi-ld/v1/entities?type=Participant&q=forStudySite=="urn:ngsi-ld:StudySite:mskcc-onco423";participantStatus=="ON_TREATMENT","IN_FOLLOW_UP","RANDOMIZED"
GET /ngsi-ld/v1/entities?type=Participant&q=forStudy=="urn:ngsi-ld:Study:ONCO-423";participantStatus=="RANDOMIZED","ON_TREATMENT","IN_FOLLOW_UP","COMPLETED"&count=true
GET /ngsi-ld/v1/temporal/entities/urn:ngsi-ld:Participant:onco-423-mskcc-p001?timeAt=2026-08-15T00:00:00Z&attrs=participantStatus,assignedToArm,randomizationDate