Demonstration: National MCP Servers for Physical AI Oncology Clinical Trial Systems

Abstract

Prior oncology clinical trial infrastructure has been fragmented, site-specific, and inefficient across the critical dimensions of interoperability, auditability, privacy, and deployment. Each trial site has historically operated its own isolated systems for electronic health records, imaging archives, and audit logging, resulting in inconsistent data formats, duplicated regulatory effort, and limited cross-site collaboration.

This page presents a demonstration of the National MCP Physical AI Oncology Trials system, a proposed end-to-end architecture comprising five Model Context Protocol (MCP) servers that address these gaps through standardized, federated, and safety-governed capabilities. The five servers (Authorization, FHIR Clinical Data, DICOM Imaging, Audit Ledger, and Provenance) expose 23 tools across five hierarchical conformance levels, validated by 668 test functions.

5MCP Servers

23Tools

668Test Functions

381Files

34Integration Adapters

8Safety Modules

13JSON Schemas

6Deployment Modes

Paper: 10.5281/zenodo.18916731 | Repository: kevinkawchak/national-mcp-pai-oncology-trials (DOI: 10.5281/zenodo.18894758)

Architecture Overview

Five domain-specific MCP servers form the protocol surface for Physical AI oncology trials

  NATIONAL MCP FIVE-SERVER DEPLOYMENT
  +---------------------------------------------------+
  |                  SITE DEPLOYMENT                  |
  |                                                   |
  |    +-----------+  +-----------+  +-----------+    |
  |    | trialmcp  |  | trialmcp  |  | trialmcp  |    |
  |    | authz     |  | fhir      |  | dicom     |    |
  |    | (5 tools) |  | (4 tools) |  | (4 tools) |    |
  |    | RBAC,     |  | FHIR R4,  |  | DICOMweb, |    |
  |    | Tokens    |  | HIPAA     |  | RECIST    |    |
  |    +-----+-----+  +-----+-----+  +-----+-----+    |
  |          |              |              |          |
  |          +------+-------+------+-------+          |
  |                 |              |                  |
  |          +------v------+ +-----v-------+          |
  |          | trialmcp    | | trialmcp    |          |
  |          | ledger      | | provenance  |          |
  |          | (5 tools)   | | (5 tools)   |          |
  |          | SHA-256     | | DAG, W3C    |          |
  |          | 21 CFR 11   | | PROV        |          |
  |          +-------------+ +-------------+          |
  |                                                   |
  |  23 tools total across 5 servers                  |
  +---------------------------------------------------+

Figure 1: Five-server deployment topology at each participating clinical site

Authorization Server 5 tools Level 1

servers/trialmcp_authz/ | server.py, policy_engine.py, token_store.py

Deny-by-default RBAC, SHA-256 token lifecycle, policy evaluation

authz_evaluate | authz_issue_token | authz_validate_token
authz_revoke_token | authz_list_policies

FHIR Clinical Data Server 4 tools Level 2

servers/trialmcp_fhir/ | server.py, deid_pipeline.py, fhir_adapter.py

FHIR R4 clinical data with HIPAA Safe Harbor de-identification

fhir_read | fhir_search | fhir_patient_lookup | fhir_study_status

DICOM Imaging Server 4 tools Level 3

servers/trialmcp_dicom/ | server.py, dicom_adapter.py

DICOM imaging queries, RECIST 1.1 measurements

dicom_query | dicom_retrieve_pointer | dicom_study_metadata | dicom_recist_measurements

Audit Ledger Server 5 tools Level 1

servers/trialmcp_ledger/ | server.py, chain.py, storage.py

Hash-chained 21 CFR Part 11 audit trail

ledger_append | ledger_verify | ledger_query
ledger_replay | ledger_export

Provenance Server 5 tools Level 4

servers/trialmcp_provenance/ | server.py, dag.py, storage.py

DAG-based data lineage, SHA-256 fingerprinting

provenance_record | provenance_query_forward | provenance_query_backward
provenance_fingerprint | provenance_lineage

Hash-Chained Audit Record (from `servers/trialmcp_ledger/chain.py`)

GENESIS_HASH = "0" * 64

def canonical_json(record: dict[str, Any]) -> str:
    filtered = {k: v for k, v in sorted(record.items())
                if k != "hash"}
    return json.dumps(filtered, sort_keys=True,
                      ensure_ascii=True)

def compute_audit_hash(record, prev_hash: str) -> str:
    canonical = canonical_json(record)
    payload = prev_hash + canonical
    return hashlib.sha256(
        payload.encode("utf-8")).hexdigest()

Seven Interactive Diagram Sections

Each section corresponds to a process diagram from docs/mcp-process/

1 Robot Procedure Lifecycle

Source: docs/mcp-process/01-robot-procedure-lifecycle.md

The robot procedure lifecycle defines the complete state machine for robot-assisted clinical procedures. Each state transition requires specific MCP server interactions and safety validations, with timing constraints enforcing clinical safety protocols.

SCHEDULED

→

PRE_CHECK

→

GATES_EVAL

→

HUMAN_APPROVAL

→

IN_PROGRESS

→

COMPLETED

  State Transitions and MCP Server Interactions:

  SCHEDULED --(pre-check triggers)--> PRE_CHECK
    Servers: trialmcp-authz (token validation)
             trialmcp-fhir  (patient eligibility)
             trialmcp-dicom (imaging availability)

  PRE_CHECK --(all checks pass)--> GATES_EVAL
    Servers: safety/gate_service (5 gates evaluated)

  GATES_EVAL --(all gates pass)--> HUMAN_APPROVAL
    Servers: safety/approval_checkpoint (clinician review)
    Timeout: 300 seconds

  HUMAN_APPROVAL --(approved)--> IN_PROGRESS
    Servers: trialmcp-ledger (audit record)
             safety/procedure_state (state transition)

  IN_PROGRESS --(procedure complete)--> COMPLETED
    Servers: trialmcp-provenance (lineage record)
             trialmcp-ledger (final audit)

  Any State --(e-stop triggered)--> ABORTED
    Servers: safety/estop (signal propagation)
             trialmcp-ledger (abort audit record)

Figure 2: Robot procedure state machine with MCP server interactions per transition

2 Cross-Site MCP Communication

Source: docs/mcp-process/02-cross-site-mcp-communication.md

The cross-site communication model connects hospital sites, cancer centers, sponsors, and CROs through a federated coordination layer. Each site operates its own five-server deployment while participating in cross-site audit chain synchronization and token exchange protocols.

  MULTI-SITE MCP TOPOLOGY

  +------------------+     +------------------+     +------------------+
  |   SITE ALPHA     |     |   SITE BETA      |     |   SITE GAMMA     |
  |  (Hospital)      |     |  (Cancer Center) |     |  (Hospital)      |
  | +------+ +-----+ |     | +------+ +-----+ |     | +------+ +-----+ |
  | |authz | |fhir | |     | |authz | |fhir | |     | |authz | |fhir | |
  | +------+ +-----+ |     | +------+ +-----+ |     | +------+ +-----+ |
  | +------+ +-----+ |     | +------+ +-----+ |     | +------+ +-----+ |
  | |dicom | |ledger||     | |dicom | |ledger||     | |dicom | |ledger||
  | +------+ +-----+ |     | +------+ +-----+ |     | +------+ +-----+ |
  | +----------+     |     | +----------+     |     | +----------+     |
  | |provenance|     |     | |provenance|     |     | |provenance|     |
  | +----------+     |     | +----------+     |     | +----------+     |
  +--------+---------+     +--------+---------+     +--------+---------+
           |                        |                        |
           +----------+-------------+-------------+----------+
                      |                           |
               +------v--------+           +------v--------+
               |   SPONSOR     |           |     CRO       |
               |  MCP Client   |           |  MCP Client   |
               +---------------+           +---------------+

Figure 3: Multi-site MCP topology with cross-site coordination

Cross-site token exchange enables authorized actors to access resources across sites without requiring site-specific credentials. The token exchange protocol uses scoped, time-limited tokens issued by each site's authorization server, with cross-site audit chain synchronization ensuring a unified compliance record.

3 Clinical System Integration

Source: docs/mcp-process/03-clinical-system-integration.md

The integration adapter architecture connects MCP servers to real hospital infrastructure through 34 adapters organized across six categories in the integrations/ directory.

EHR Integration (FHIR R4)

Epic via SMART on FHIR adapter (integrations/fhir/smart_on_fhir.py)
Cerner via HAPI FHIR adapter (integrations/fhir/hapi_fhir.py)
MEDITECH via terminology mapping
De-identification pipeline: integrations/fhir/deid_adapter.py

Terminology Standards

ICD-10, SNOMED CT, LOINC, RxNorm
Mapping adapter: integrations/fhir/terminology_adapter.py

PACS Integration (DICOM)

dcm4chee: integrations/dicom/dcm4chee_adapter.py
Orthanc: integrations/dicom/orthanc_adapter.py
DICOMweb: integrations/dicom/dicomweb_adapter.py
Modality filter, RECIST adapter, metadata-only retrieval

Identity Providers

OIDC adapter: integrations/identity/oidc_adapter.py
mTLS adapter: integrations/identity/mtls_adapter.py
KMS adapter: integrations/identity/kms_adapter.py

Category	Count	Key Adapters
FHIR	9	HAPI FHIR, SMART on FHIR, de-identification, terminology
DICOM	9	dcm4chee, Orthanc, DICOMweb, RECIST, modality filter
Clinical	3	Scheduling, e-consent, provenance export
Federation	4	Coordinator, policy enforcement, secure aggregation
Identity	5	OIDC, mTLS, KMS, policy engine
Privacy	4	De-identification pipeline, privacy budget, data residency
Total	34

4 Safety Gate Evaluation

Source: docs/mcp-process/04-safety-gate-evaluation.md

Five mandatory pre-procedure safety gates must pass sequentially before any robotic procedure can proceed. Each gate has a 300-second timeout. If any gate fails, the procedure transitions to ABORTED and a full audit record is created.

1

Patient Consent
Verify active, informed consent for the specific procedure

PENDING

2

Site Capability
Validate site meets required conformance level

PENDING

3

Robot Capability
Confirm robot firmware and capability profile match task requirements

PENDING

4

Protocol Compliance
Verify procedure parameters satisfy trial protocol constraints

PENDING

5

Human Approval
Require explicit clinician authorization (300s timeout)

PENDING

The gate evaluation animation above demonstrates the sequential pass/fail workflow. In production, the gate service (safety/gate_service.py) integrates with all five MCP servers to validate each condition.

5 Federated Learning Coordination

Source: docs/mcp-process/05-federated-learning-coordination.md

Multi-site federated learning enables collaborative model training without centralizing patient data. The system supports three aggregation strategies with differential privacy budget tracking per site.

Aggregation Strategies

FedAvg: Weighted averaging proportional to local dataset size
FedProx: Proximal term regularization for heterogeneous data
SCAFFOLD: Variance reduction through control variates

Privacy Controls

Differential privacy budget (epsilon) tracking per site per round
Secure aggregation with mask generation
Privacy adapter: integrations/privacy/privacy_budget.py

1 Coordinator distributes global model to sites

2 Each site trains locally on private data

3 Sites generate masks for secure aggregation

4 Masked model updates submitted to coordinator

5 Aggregation (masks cancel), global model updated

6 Updated model distributed, privacy budgets decremented

Federation adapters are implemented in integrations/federation/, including the coordinator (coordinator.py), policy enforcement (policy_enforcer.py), secure aggregation (secure_aggregation.py), and site harmonization (site_harmonization.py) modules.

6 Audit and Provenance Chain

Source: docs/mcp-process/06-audit-provenance-chain.md

The audit ledger maintains a hash-chained sequence of records using SHA-256 with canonical JSON serialization. Every MCP tool invocation produces an audit record linked to the prior record, creating a tamper-evident chain satisfying 21 CFR Part 11 requirements.

  PROVENANCE DAG (Directed Acyclic Graph)

  [FHIR Read: Patient/P-001]
       |
       v
  [DICOM Query: CT Studies]---->[RECIST Measurement]
       |                              |
       v                              v
  [Robot Procedure]------------>[Audit Record]
       |                              |
       v                              v
  [Provenance Node]            [Chain Block #N]
       |
       v
  [Forward Lineage Query]

  Source types: fhir, dicom, computed, external, federated
  Action types: read, transform, aggregate, transfer, derive

Figure 4: DAG-based provenance graph with forward/backward lineage queries

7 Privacy and De-identification

Source: docs/mcp-process/07-privacy-deidentification.md

The HIPAA Safe Harbor 18-identifier pipeline removes protected health information (PHI) across three stages before clinical data leaves the server boundary. HMAC-SHA256 pseudonymization preserves referential integrity across de-identified records.

1

Direct Identifiers

Patient name
Social Security number
Medical record number
Phone, fax, email
Geographic data (below state)

→

2

Quasi-Identifiers

Dates (birth, admission, discharge)
Age (if over 89)
ZIP code (3-digit generalization)
Device identifiers

→

3

Technical Identifiers

IP addresses
URLs
Biometric identifiers
Full-face photographs

Data residency enforcement ensures compliance with federal, California (CCPA/CMIA), and New York state privacy regulations through the data residency adapter (integrations/privacy/data_residency.py). Access control combines RBAC and ABAC checks across four data classification levels.

National Deployment Topology

Three-tier architecture: National Governance, Regional Layers, 750+ Sites

National Governance Layer

Standards Body | Conformance Registry | Schema Registry | Validation Services

Regional Layers

Region 1 (East)

210 sites

1,050 servers

NY, MA, PA, FL, NC, VA, MD, CT, NJ, GA

Region 2 (Central)

305 sites

1,525 servers

TX, IL, OH, MI, MN, MO, IN, WI, IA, TN

Region 3 (West)

248 sites

1,240 servers

CA, WA, OR, CO, AZ, UT, NV, HI

Federated Layer

Privacy-Preserving Aggregation | Differential Privacy | Audit Chain Merge | FedAvg / FedProx / SCAFFOLD

  NATIONAL GOVERNANCE LAYER
  +-----------------------------------------------------+
  | Standards Body   | Conformance Registry             |
  | Extension Mgmt   | Version Compatibility Policy     |
  | Schema Registry  | Validation Services              |
  +--------+---------+---------+--------+--------+------+
           |                   |                 |
  +--------v------+  +---------v-----+  +--------v-----+
  | REGION 1      |  | REGION 2      |  | REGION N     |
  | (East)        |  | (Central)     |  | (West)       |
  | 200+ Sites    |  | 300+ Sites    |  | 250+ Sites   |
  | 5 Svrs/Site   |  | 5 Svrs/Site   |  | 5 Svrs/Site  |
  +-------+-------+  +-------+-------+  +-------+------+
          |                  |                  |
          +------------------+------------------+
                             |
                    +--------v-----------+
                    | FEDERATED LAYER    |
                    | Aggregation        |
                    | Differential Priv. |
                    | Audit Merge        |
                    +--------------------+

Figure 5: National 3-tier deployment topology from the paper (Section 4.6)

Deployment Simulator

Run deterministic simulations of national deployment, robot procedure workflows, and audit chain verification. All data is synthetic and modeled.

Click a simulation button above to begin.

Conformance Levels

Five hierarchical levels enabling incremental adoption (click to expand)

Eight conformance profiles are defined in profiles/, including five hierarchical profiles and three regulatory overlays (country-us-fda.md, state-us-ca.md, state-us-ny.md).

Safety Modules

Eight safety modules designed for Physical AI systems in clinical environments

Emergency Stop Controller

safety/estop.py

E-stop signal propagation, abort workflow, post-abort evidence capture, recovery with re-authorization.

IDLE

→

TRIGGERED

→

ACKNOWLEDGED

→

RECOVERING

Procedure State Machine

safety/procedure_state.py

State machine enforcement with valid transition validation across 6 states.

IDLE

→

PREPARING

→

ACTIVE

→

COMPLETING

Robot Registry

safety/robot_registry.py

Robot registration, capability validation, firmware version tracking. Capability declaration is required before any procedure.

Task Validator

safety/task_validator.py

Task order validation against safety constraints and robot capabilities using schemas/task-order.schema.json.

Safety Gate Service

safety/gate_service.py

5 mandatory gates with sequential evaluation: Patient Consent, Site Capability, Robot Capability, Protocol Compliance, Human Approval. 300-second timeout per gate.

Approval Checkpoint

safety/approval_checkpoint.py

Multi-party approval requiring concurrent authorization from clinician, system, and regulatory parties before critical procedure transitions.

Site Verifier

safety/site_verifier.py

Site capability verification against conformance requirements and infrastructure readiness checks.

Boundary Enforcer

safety/boundary_enforcer.py

Execution boundary enforcement: spatial boundary validation, force limit enforcement, temporal constraint checking.

Emergency Stop Code (from `safety/estop.py`)

class EStopStatus(Enum):
    IDLE = "IDLE"
    TRIGGERED = "TRIGGERED"
    ACKNOWLEDGED = "ACKNOWLEDGED"
    RECOVERING = "RECOVERING"

class EStopController:
    def trigger_estop(self, procedure_id, reason,
                      triggered_by, current_state=None):
        if self._status == EStopStatus.TRIGGERED:
            raise RuntimeError("E-stop already active")
        signal = EStopSignal(
            signal_id=str(uuid.uuid4()),
            procedure_id=procedure_id,
            reason=reason,
            triggered_by=triggered_by,
            affected_servers=list(self._active_servers),
            preserved_state=current_state or {})
        self._active_signal = signal
        self._status = EStopStatus.TRIGGERED
        return signal

Repository Scale

Quantitative summary of the national repository at v1.2.0

Category	Count
MCP servers	5
Tools (total)	23
JSON schemas	13
Conformance profiles	8
Test functions	668
Integration adapters	34
Specification docs	9
ADRs	7
Total files	381+
Lines of code (approx.)	69,800+

Category	Count
Safety modules	8
Benchmark modules	5
Certification tools	4
Deployment modes	6
Interop scenarios	8
Actor personas	6
Stakeholder guides	5
Operational docs	5
Total directories	88
Regulatory overlays	7

Test Coverage Breakdown

Category	Tests	Validates
Unit (integrations)	205	All 34 integration adapters
Unit (safety)	88	All 8 safety modules
Unit (core server)	32	5 MCP server implementations
Unit (infrastructure)	12	Conformance harness, schema validator
Positive conformance	69	Correct behavior at Levels 1-3
Adversarial	57	AuthZ bypass, chain tampering, PHI leakage
Blackbox	63	Per-server external conformance
Security	39	SSRF prevention, token lifecycle, chain integrity
Interoperability	32	Cross-server trace, schema validation
Negative	26	Invalid input rejection, unauthorized access
Integration	13	Multi-server integration scenarios
Total	668

CI/CD Pipeline (14 Jobs)

The repository maintains quality through a GitHub Actions CI pipeline defined in .github/workflows/ci.yml:

lint-and-format: Ruff linting and formatting (Python 3.10, 3.11, 3.12)
integration-tests: Multi-server integration validation
adversarial-tests: Security attack resistance
schema-validation: JSON Schema Draft 2020-12 validation
schema-compatibility: Schema metadata and field consistency
contract-consistency: Generated model alignment with schemas
benchmark-smoke: Performance benchmark verification
sdk-python: Python SDK import verification
sdk-typescript: TypeScript SDK compilation
cli-smoke: CLI command validation
codegen-consistency: Code generation pipeline verification
security-scan: Dependency audit and secret detection
typescript-build: Reference TypeScript compilation
docs-lint: Documentation completeness and link integrity

Adoption Roadmap

Stakeholder-specific pathways for implementing the national standard

S

Sponsors and CROs

Begin with Level 1 (Core) deployment for centralized audit trail access. Progress to Level 2 for de-identified clinical data queries. Guide: docs/guides/sponsor-cro.md

H

Hospital IT

Deploy five-server stack using Docker Compose (deploy/docker-compose.yml). Integrate with existing EHR via FHIR adapters and PACS via DICOM adapters. Guide: docs/guides/hospital-it.md

R

Regulators and IRBs

Review conformance profiles and regulatory overlays (profiles/). Evaluate audit chain integrity using ledger_verify. Guide: docs/guides/regulator-irb.md

V

Robot Vendors

Implement MCP client interface against the 23-tool contract. Register robots via safety/robot_registry.py. Run conformance tests at Level 5. Guide: docs/guides/robot-vendor.md

C

Standards Community

Review the 9 normative specifications in spec/, 7 ADRs in docs/adr/, and governance framework. Guide: docs/guides/standards-community.md

Robot Procedure Data Flow

  
  ROBOT AGENT         MCP SERVERS         CLINICAL SYSTEMS
  -----------         -----------         ----------------
  +--------+
  | START  |
  +---+----+
      |  1. Request Token
      v
  +--------+        +--------------+
  | AuthZ  |--------| trialmcp-    |       Issue scoped token
  | Phase  |--------| authz        |       (role + expiry)
  +---+----+        +--------------+
      |  2. Query Patient Data
      v
  +--------+        +--------------+       +-----------+
  | FHIR   |--------| trialmcp-    |-------| EHR       |
  | Phase  |--------| fhir         |-------| (FHIR R4) |
  +---+----+        +--------------+       +-----------+
      |  3. Retrieve Imaging
      v
  +--------+        +--------------+       +-----------+
  | DICOM  |--------| trialmcp-    |-------| PACS      |
  | Phase  |--------| dicom        |-------| (DICOM)   |
  +---+----+        +--------------+       +-----------+
      |  4. Execute Procedure
      v
  +--------+
  | ROBOT  |                               Physical AI task
  | ACTION |                               under safety rules
  +---+----+
      |  5. Record Audit
      v
  +--------+        +--------------+
  | Audit  |--------| trialmcp-    |       Hash-chained record
  | Phase  |--------| ledger       |       (21 CFR Part 11)
  +---+----+        +--------------+
      |  6. Record Provenance
      v
  +--------+        +--------------+
  | Prov.  |--------| trialmcp-    |       DAG lineage entry
  | Phase  |--------| provenance   |       (SHA-256)
  +---+----+        +--------------+
      v
  +--------+
  |  DONE  |
  +--------+

Figure 6: Complete data flow for a Physical AI robot agent executing a clinical procedure

Classification and Status

What This IS

A reference architecture demonstration and interactive simulation of the proposed National MCP-PAI Oncology Trials Standard. It serves as an educational and stakeholder communication tool that visualizes the system described in the paper using deterministic simulations with pre-configured data.

What This Is NOT

NOT a deployed clinical system
NOT approved for use in actual oncology trials
NOT connected to real patient data, EHR systems, PACS, or robotic systems
NOT a medical device or software as a medical device (SaMD)

Simulation Conditions and Approximations

All data shown is synthetic
Network latencies, site counts, and response times are modeled approximations based on the paper's architecture
Federated learning rounds use illustrative aggregation, not real model weights
Hash chains demonstrate the algorithm with sample data

What Is Needed for Actual Trial Use

FDA review and recognition as a consensus standard
Clinical pilot deployment at NCI-designated cancer centers
Real EHR/PACS adapter validation with vendor systems (Epic, Cerner, Orthanc, dcm4chee)
Robot vendor certification program
IRB approval at each participating site
21 CFR Part 11 compliance audit of deployed instances
HIPAA security risk assessment

Current Status

This is a proposed reference standard with a complete reference implementation (381 files, approximately 69,800 lines) that has not yet been deployed in clinical settings. The repository (v1.2.0) includes the complete specification, reference implementations in Python and TypeScript, a 668-function test suite, and a 20-page peer-reviewed paper.

Citation and Links

Cite This Work

Kawchak K. National MCP Servers for Physical AI Oncology Clinical Trial Systems. Zenodo. 2026; 10.5281/zenodo.18916731.

BibTeX

@article{kawchak2026national, title = {National MCP Servers for Physical AI Oncology Clinical Trial Systems}, author = {Kawchak, Kevin}, year = {2026}, publisher = {Zenodo}, doi = {10.5281/zenodo.18916731}, url = {https://doi.org/10.5281/zenodo.18916731} }

Repository Links

Repository	DOI	Focus
national-mcp-pai-oncology-trials	10.5281/zenodo.18894758	National standard, SDKs, governance (current)
mcp-pai-oncology-trials	10.5281/zenodo.18869776	MCP server proof of concept, 5-server architecture
pai-oncology-trial-fl	10.5281/zenodo.18840880	Federated learning, privacy modules
physical-ai-oncology-trials	10.5281/zenodo.18445179	USL scoring, single-site Physical AI framework

Paper

PDF: National MCP Servers for Physical AI Oncology Clinical Trial Systems
LaTeX Source: Latex Source Files.zip
Template: kourgeorge/arxiv-style

Contributors

This demonstration was generated by Anthropic Claude Code Opus 4.6 and OpenAI ChatGPT 5.4 Thinking under the direction of Kevin Kawchak.

License

This project is distributed under the MIT License. The paper is distributed under CC BY 4.0.

Abstract

Architecture Overview

Hash-Chained Audit Record (from servers/trialmcp_ledger/chain.py)

Seven Interactive Diagram Sections

1 Robot Procedure Lifecycle

2 Cross-Site MCP Communication

3 Clinical System Integration

EHR Integration (FHIR R4)

Terminology Standards

PACS Integration (DICOM)

Identity Providers

4 Safety Gate Evaluation

5 Federated Learning Coordination

Aggregation Strategies

Privacy Controls

6 Audit and Provenance Chain

7 Privacy and De-identification

Direct Identifiers

Quasi-Identifiers

Technical Identifiers

National Deployment Topology

Region 1 (East)

Region 2 (Central)

Region 3 (West)

Deployment Simulator

Conformance Levels

Safety Modules

Emergency Stop Controller

Procedure State Machine

Robot Registry

Task Validator

Safety Gate Service

Approval Checkpoint

Site Verifier

Boundary Enforcer

Emergency Stop Code (from safety/estop.py)

Repository Scale

Test Coverage Breakdown

CI/CD Pipeline (14 Jobs)

Adoption Roadmap

Sponsors and CROs

Hospital IT

Regulators and IRBs

Robot Vendors

Standards Community

Robot Procedure Data Flow

Classification and Status

What This IS

What This Is NOT

Simulation Conditions and Approximations

What Is Needed for Actual Trial Use

Current Status

Citation and Links

Cite This Work

BibTeX

Repository Links

Paper

Contributors

License

Hash-Chained Audit Record (from `servers/trialmcp_ledger/chain.py`)

Emergency Stop Code (from `safety/estop.py`)