Site + StudySite Specification · v0.2

Clinical-trials reference graph · top:Site · topc:StudySite

1.TL;DR the operational hierarchy, the Site/StudySite split, where everything lives

Site is where trials operate. The Site entity in TOP captures the physical/operational research site as a study-independent operational and feasibility entity — staff, equipment, IRB-of-record default, SFQ feasibility profile, infrastructure. The StudySite entity captures Site's role on a specific Study — the per-Study lifecycle, the per-Study Principal Investigator, the per-Study Delegation of Authority Log, the per-Study IRB approval, the per-Study contracts, and the entry point for Participants and Visit-occurrences at this Site for this Study. The operational chain is Site → StudySite → Study → Protocol → SOA → Visit → Activity. Site has very few direct edges; everything operational is reached via StudySite.

The shape lets a Site Coordinator query "show me my Site's open queries on Study ONCO-423" via Site → StudySite → Study traversal without polluting the Site entity with thousands of per-Study CRF/Visit/Query references. It lets a Sponsor PM query "across all my StudySites, where is enrollment behind target" with one StudySite-level scan. It lets the SFQ projection ("Site X's feasibility for Study Y") run directly off the Site's stable feasibility attributes. It anchors GCP discipline cleanly: R3 Section 2 obligations (qualification, delegation, IP management, records) live on StudySite where they're per-Study real; R3 Section 4.3 computerised-system obligations live on the linked System; Equipment carries calibration and qualification independent of any computerised layer.

Site spec extends the Sponsor spec template with five additions: an architectural-anchor section (the operational hierarchy), R3 alignment as a first-class section (Section 2 / 3 / 4 / Appendix C / Annex 2), an ISF alignment table mapping all 23 sections to TOP entities, a lifecycle state machine (separate for Site and StudySite), a persona-to-Site-view matrix covering ten roles, an SFQ projection as a named query template, and a delegation matrix. Site is the most operationally consequential top-level in the trials commons; the spec depth reflects that.

2.Architectural anchor the operational hierarchy

The operational chain runs from Site at the top of operations through StudySite (the per-Study pivot) down to Activity-occurrences during Visits:

Two sides, meeting at Visit. The definition side is top-down from Protocol: Protocol → SOA → Visit-template → Activity defines what is supposed to happen. The operational side is top-down from Site: Site → StudySite → Participant → Visit-occurrence → Activity-occurrence captures what actually happened at a specific Site for a specific Study.

This anchors three model decisions:

• Site has very few direct edges. Direct Site edges go only to: Organization (legal), other Sites (parentSite, network), Person (study-independent staff and head of clinical research), Equipment (site-bound), StorageLocation (site-bound), Document (institutional records), Credential (institutional credentials), System (Site-operational systems like the Site's own EMR). Everything operational is reached via StudySite.
• StudySite is the operational pivot. Per-Study lifecycle, per-Study performance, per-Study oversight, per-Study qualification, plus the relationships to Participant, Visit-occurrence, MonitoringVisit, Audit, Contract, Sponsor (reportsTo), RegulatoryAuthority, OversightBody, etc. — all per-Study facts.
• Visit splits into template and occurrence. The OOUX Visit object conflates them; this spec flags the correction that Visit needs a template-vs-occurrence split (or a discriminator) when Visit lifts. Per-Study Visit relationships from StudySite point at Visit-occurrences, not Visit-templates.

3.Model summary attributes and key relationships · full set in source/top-strawman.json

Site (operational + feasibility) — selected attributes (full set: 49)

Site — selected relationships (full set: 10)

StudySite (per-Study pivot) — attributes (full set: 17)

StudySite — selected relationships (full set: 18)

4.Why this shape — architectural decisions

Five decisions shape the Site model. Each made in dialogue with the OOUX, USDM, ICH E6(R3), and ISF anchors; reversible if downstream evidence argues against.

5.ICH E6(R3) alignment canonical anchor · Sections 2 / 3 / 4 / Appendix C / Annex 2

ICH E6(R3) Step 4 Final (January 2025) supersedes R2 and is the current GCP standard. The Site model anchors to R3 throughout: Section 2 (Investigator responsibilities) defines what a Site IS; Section 3 (Sponsor responsibilities) grounds the System three-axis decision; Section 4 (Data Governance) shapes the System horizontal's attribute set; Appendix C (Essential Records) drives the Document.essentialRecordPurpose taxonomy; Annex 2 frames decentralized modalities.

R3 Section 2 — Investigator/Institution responsibilities

R3 Section 3 — Sponsor responsibilities (touchpoints with Site)

R3 Section 3 grounds the Sponsor side of the Site relationship. Key touchpoints:

• 3.6 Agreements: documented agreements between Sponsor and any service provider, including Sites. Encoded as Sponsor.engages → Site (already on Sponsor v0.1) plus the StudySite.hasContract relationship.
• 3.9 Sponsor oversight: proportionate oversight obligation. Grounds the System three-axis decision (System.oversightHeldBy → Sponsor for sponsor-critical Systems).
• 3.10 Quality management / risk management: drives the StudySite.oversightTier enum (LOW/MEDIUM/HIGH) — risk-based monitoring tier per StudySite.
• 3.11 QA / QC / monitoring: StudySite.hasMonitoringVisit, StudySite.hasAudit.
• 3.13 Safety reporting: StudySite.reportsTo → Sponsor.
• 3.14 Insurance: Site.insuranceCarrier / coverage / expiry (Site-level institutional insurance).

R3 Section 4 — Data Governance and Computerised Systems

R3 Section 4 maps directly onto the System horizontal:

R3 Appendix C — Essential Records taxonomy

R3 Appendix C is the canonical record taxonomy, replacing R2's Section 8 prescriptive document list. Records are categorized by two axes:

• essentialRecordPurpose: what the record contributes to under GCP. Currently a placeholder enum (QUALIFICATION, DELEGATION, TRAINING, IP_MANAGEMENT, MONITORING, DATA_HANDLING, SYSTEMS_VALIDATION, OTHER) flagged with _partialEnum in source — full enum requires Appendix C transcription pending PDF access.
• responsibleParty: INVESTIGATOR_INSTITUTION · SPONSOR · IRB_IEC · REGULATORY_AUTHORITY · VENDOR · OTHER.

The legacy ISF section taxonomy is captured in Document.isfSection as a free-text mapping; the operational continuity is preserved without making ISF the canonical primary axis.

R3 Annex 2 — non-traditional / decentralized

R3 doesn't enumerate DCT modalities formally; it places decentralized aspects within the principles and Annex 1 applicability with proportionate/risk-based approaches. TOP's existing siteType enum (HOSPITAL, CLINIC, ACADEMIC_MEDICAL_CENTER, RESEARCH_CENTER, COMMUNITY_PRACTICE, DECENTRALIZED_HUB, VIRTUAL) is sufficient. The flexibility lives in how existing relationships are populated (a VIRTUAL Site has no fixed address; a DECENTRALIZED_HUB has 0..N addresses) rather than in a new enum.

6.ISF alignment legacy operational view · 23 sections mapped to TOP

The ISF section taxonomy is the legacy operational view that maps onto R3 Appendix C. Maintaining the alignment is operationally valuable — sponsors, CROs, and sites organize day-to-day artifacts against the ISF — but the canonical anchor is R3 Appendix C; ISF mappings are secondary.

The ISF reference used here is a 23-section TOC (sourced from a Singapore HSA-flavored ISF that mirrors the international ICH E6 essential-documents structure). Re-validate against the actual CDISC ISF Provisional v1 PDF when accessible — section names and counts may differ.

Coverage summary: ~28 ISF subsections fully covered, ~9 partial (mostly waiting for flagged-missing horizontals: MonitoringVisit, RegulatoryAuthority, TrainingRecord, OversightBody, Shipment), ~2 explicit gaps (CRF horizontal, Meeting horizontal — neither lifts in v0.2.0; tracked).

7.Lifecycle state machines Site and StudySite separately

Site lifecycle

The Site itself doesn't really have a strong lifecycle — it's a research facility that exists across studies. Site.status is a coarse-grained ACTIVE / INACTIVE / RETIRED enum. The interesting lifecycle is StudySite (per-Study).

StudySite lifecycle

8.Stress-test scenarios eight cases · plain English to graph shape

9.Persona-to-Site-view matrix ten roles · what each one cares about

10.Query patterns six concrete NGSI-LD HTTP shapes

GET /entities?type=Discrepancy
  &q=relatedStudy=="urn:ngsi-ld:Study:ONCO-423"
  &q=relatedSite=="urn:ngsi-ld:Site:mskcc-main"
  &q=queryStatus=="OPEN"
  &options=keyValues

GET /entities?type=StudySite
  &q=forStudy=="urn:ngsi-ld:Study:ONCO-423"
  &q=studySiteStatus=="ACTIVE"
  &options=keyValues
# Then client-side filter: actualEnrollment / enrollmentTarget < 0.7

GET /entities?type=StudySite
  &q=forStudy=="urn:ngsi-ld:Study:ONCO-423"
  &q=oversightTier=="HIGH"
  &q=lastMonitoringVisitDate<"2026-02-08"
  &options=keyValues

GET /entities?type=StudySite
  &q=studySiteStatus=="ACTIVE"
  &q=forSite.partOfSiteNetwork=="urn:ngsi-ld:Organization:elevate-research"
  &options=keyValues
# Client-side: traverse forStudy → engages_inverse → Sponsor

GET /entities?type=StudySite
  &q=forSite=="urn:ngsi-ld:Site:mskcc-main"
  &q=forStudy=="urn:ngsi-ld:Study:ONCO-423"
  &options=sysAttrs

# Then for each Person in delegatesAuthorityTo:
GET /entities?type=Person&id=<personId>&options=keyValues
GET /entities?type=Credential&q=forPerson==<personId>

GET /entities?type=Document
  &q=hasEssentialRecord_inverse=="urn:ngsi-ld:StudySite:mskcc-onco423"
  &options=keyValues
# Group by essentialRecordPurpose

11.SFQ projection named query template · operational artifact

The Site Feasibility Questionnaire (SFQ) is the canonical sponsor-selection artifact. Sponsor portfolio teams use SFQs to qualify Sites for upcoming Studies. The SFQ projection is a named query template that runs against the Site's stable feasibility attributes — no per-Study data needed.

Named query: SiteFeasibilityProjection

QUERY SiteFeasibilityProjection(siteId)
RETURNS FROM Site WHERE Site.siteId = $siteId:
  -- Identity
  siteId, siteName, siteType, address, country
  -- Therapeutic / population fit
  therapeuticAreasExperienced, indicationExperience, patientPopulationAccess
  -- Past trial experience (benchmarks)
  totalTrialsConducted, trialsByPhase, averageEnrollmentRate,
  firstPatientInToActivationDays, queryResponseTimeHours, sponsorRetentionRate
  -- Infrastructure
  freezerCapacity, imagingCapabilities, labCapabilities,
  pharmacyOnSite, dctCapable, econsentCapable, eproCapable,
  edcVendorExperience
  -- Regulatory / ethics defaults
  irbType, typicalIrbApprovalDays, regulatoryAuthorityExperience,
  sopsAvailable, sopLibrarySize
  -- Insurance
  insuranceCarrier, insuranceCoverageAmount, insuranceCurrency, insuranceExpiry
  -- Staff capacity
  subInvestigatorCount, coordinatorCount, regulatoryCoordinatorCount,
  studyNurseCount, labTechCount, languagesSupported, gcpTrainingCurrencyRate
  -- Network membership (for SMO sites)
  partOfSiteNetwork → Organization (organizationName, organizationType)
  -- Equipment summary (for infrastructure verification)
  hostsEquipment[equipmentClass IN (FREEZER, CENTRIFUGE, ECG_MACHINE, MRI, ...)]
RETURN AS JSON-LD with @context: top-clinical-trials

The projection contains zero per-Study data. A Sponsor portfolio team can score the Site for fit without entering a CTA, signing CDAs, or escalating engagement — the SFQ projection IS the qualification surface. Once the Site qualifies, a StudySite is created with the per-Study scope and engagement begins. Versioning the SFQ projection (capturing the exact attribute values at SFQ submission time) is a v0.3 enhancement; the projection runs on current Site state for v0.2.0.

12.Delegation matrix role · scope · timing

R3 Section 2.3.3 GCP-requires a Delegation of Authority Log: "the investigator should ensure a record is maintained of the persons and parties to whom the investigator has delegated trial-related activities." TOP encodes this as StudySite.delegatesAuthorityTo → Person with role/scope/temporal attributes carried on the relationship.

Each delegatesAuthorityTo triple carries a role enum (one of the above), a validFrom/validUntil temporal pair, and an optional scope restriction (free-text or structured). When Person, PersonRole, or DelegationRecord lift to richer entities in v0.3, the role can move from a relationship attribute to a structured PersonRole entity with full audit trail.

13.NLP-to-NGSI-LD translation how operator language maps to graph predicates

The pattern that earns its keep: operator questions about Site decompose to either Site (study-independent) or StudySite (per-Study) plus one or two attribute or relationship constraints. Site-level questions about feasibility/capability never need to traverse to per-Study data; per-Study questions never need to reach back into Site-level feasibility. The split is paying for itself in NLP tractability.

14.SHACL invariants what the validator catches · ten total · 4 Sponsor + 6 Site/StudySite/System/Credential

The SHACL shapes in shapes/clinical-trials-shapes.ttl are emitted from the source intermediate by tools/build_shacl.py. The full graph (Sponsor + Study + Site + 9 horizontals) emits 14 NodeShapes and 290 property shapes. Domain invariants are encoded as sh:SPARQLConstraint shapes (validated by pyshacl in --advanced mode).

Domain invariants (10 total)

Invariants pending

15.Cross-walks how Site and StudySite project into other vocabularies

16.Open issues tracked, not hidden

Items called out for resolution before v0.1 of the clinical-research reference graph publishes. Each is tracked; none block the architectural decisions in §4.