A Safety-Bounded SDC-to-MCP Gateway for Medical AI Agents

• Medical-device state must be legible to agents without granting non-deterministic models authority over device operation.The motivating setting is vendor-neutral communication and traceable data exchange in operating rooms and intensive care units.Source: §1 · p. 1
• The two constrained uses are read-only situational awareness and structured action proposals that the gateway accepts or rejects without execution.The awareness use excludes treatment recommendations or parameter changes, and neither use grants device-operation authority.Source: §1 · pp. 1–2
• The study asks whether SDC state can become stable, semantic MCP resources while preserving no-execution, visibly rejecting bad state, and supporting accurate agent interpretation.The questions cover software-reference protocol projection, unavailable or invalid state, and comparison with deterministic and representation baselines.Source: §1 · p. 2
• The gateway maps SDC device, metric, alarm, context, and operation constructs to read-only resources and dry-run tools.Its SDC-MIE mapping makes codes, handles, units, alarm references, provenance, and policy metadata explicit.Source: §1 · p. 2

• SDC uses BICEPS and MDIB structures for device components, metrics, alerts, operations, and context, but does not define agent-facing exposure or action constraints.Providers expose their MDIB and services for consumers to discover and access.Source: §2 · p. 2
• SDPi profiles support point-of-care connectivity, reporting, alerting, and external control; the gateway neither replaces SDPi nor establishes profile conformance.SDPi belongs to the device-integration layer, not the EHR interface.Source: §2 · p. 2
• FHIR supports healthcare information exchange, while this gateway turns a current device-state snapshot into an agent-readable catalogue rather than a longitudinal clinical record.FHIR/EHR integration and SDC-based device interaction can coexist; live SDC metric state and MCP resource context have distinct scopes.Source: §2 · pp. 2–3
• MCP standardizes resources and tools but supplies neither medical-device semantics nor an application-specific no-execution policy.The gateway adds explicit mapping status and deterministic limits on agent-facing request effects.Source: §2 · p. 2
• Table 1 positions systems conceptually by intended use, temporal semantics, agent interface, and write authority, not by measured performance.The proposed gateway sits between device-state structures and agent-readable MCP resources, with action affordances restricted to dry runs.Source: §2 · p. 2, Table 1 · p. 3

• The architecture normalizes SDC state, exposes MCP resources and selected dry-run tools, and separates proposal validation from device execution.Green write-path arrows and the infusion-pump extension are prospective; the evaluated prototype does not execute device operations.Source: §3 · p. 3, Figure 1 · p. 4
• The Python prototype exercises separate Python providers and an independent Java SDCri implementation using TLS, SOAP/XML, and MDIB initialization.MCP uses stdio on a same-host subprocess; dry-run approvals are recorded without calling an SDC Set Service or ActivateOperation.Source: §3 · p. 3
• The bounded property is zero SDC write-operation calls for exposed requests, tested under controlled conditions without external updates.The assumed scope excludes compromised code or configuration, adapter bypass, forged providers, authentication failures, and clinical appropriateness.Source: §3 · p. 3
• Unchanged pre- and post-request state digests are only an additional controlled-test observation, not a live-network invariant.A provider may legitimately change measurements during a read, and the tests do not prove every possible implementation execution satisfies the property.Source: §3 · pp. 3, 5
• Independent enforcement layers reject write-enabled configuration, restrict the consumer to reads, validate dry-run semantics, and count attempted device writes in tests.The threat model also uses exact provider-reference allowlisting, fail-closed schemas, secret redaction, and configuration and snapshot hashes.Source: §3 · p. 5
• The local MCP transport does not assess remote-user authentication or multi-tenant authorization, and EPR allowlisting is not provider authentication.The software testbed's mTLS authenticates configured TLS peers, not free-form synthetic approval identities.Source: §3 · p. 5

4 SDC-to-MCP Mapping

• The gateway projects normalized SDC state into MCP resources and policy-validated dry-run tools, evaluating snapshots and ordered updates but not a production subscription stream.The projection is deterministic for fixed snapshot, mapping, and policy inputs.Source: §4 · p. 5
• Metric and alarm mapping preserves identifiers, units, timestamps, and related metric handles, while context is exposed as references rather than expanded clinical records.The mapping joins an alarm to its corresponding mapped metric, such as a high airway-pressure alarm to airway_pressure.Source: §4 · p. 6
• SDC-MIE explicitly links SDC/BICEPS codes, handles, and units to agent-readable semantics, constraints, policies, and provenance, with mapping status retained for unresolved codes.Only mapped tuples are enriched; unmapped, unsupported, or conflicting entries are not silently interpreted as known concepts.Source: §4 · pp. 6–7
• Whitelisted action-like tools check schema, range, target, freshness, and policy, then return dry-run results without exposing SDC service-control objects.Proposals bind device, operation, parameters, policy and MDIB versions, freshness, snapshot hash, proposer, and expiry; even approval grants no SDC authority.Source: §4 · pp. 6–7

4.2 Worked Example: From Monitor State to Agent Response

• The worked example resolves code 150456 and metric.hr to heart_rate, preserves the source value, and joins active alarms to mapped metrics by device and handle.At 100 s, the synthetic hold-out monitor reports 148 beats/min with a medium-priority alarm; these are fixture values, not proposed clinical thresholds.Source: §4.2 · p. 7, Table 4 · p. 8
• Known mappings do not make state trustworthy: the example retains stale heart-rate and invalid oxygen-saturation status, and the lifecycle suite rejects stale or invalid snapshots.Schema and cross-entry checks do not establish that a manually supplied clinical label is medically correct; mapping curation remains separate.Source: §4.2 · p. 8

5 Evaluation Methods

• Evaluation evidence separates representation correctness, protocol interoperability, device effects, and model behavior, with different experimental units and acquisition paths.Ordered simulator states are not continuous SDC report streams, and hosted-model responses are not measurements from physical devices.Source: §5 · p. 8

5.1 Simulated Devices and Task Context

• Four development scenarios check inventory and resource selection across devices and unambiguous alarm states, while a separate hold-out contains five configurations and 28 applicable task–scenario pairs.Exploratory scenarios and tasks used to develop prompts and graders are excluded from final model aggregates.Source: §5.1 · p. 9

5.2 Software-SDC Protocol Paths

• The same-stack protocol path exercises three versioned MDIB profiles five times each, while an independent Java-provider check tests cross-stack discovery, snapshot acquisition, resource readability, and mapping coverage.The independent check is not a multi-vendor medical-device installation; protocol latency is a local snapshot-to-resource measurement, not a clinical deadline or real-time guarantee.Source: §5.2 · pp. 9–10

5.3 No-execution, Lifecycle, and Provenance Checks

• No-execution checks compare operation-attempt counts and normalized state digests before and after resource and tool requests, alongside source inspection, property-based inputs, and abstract workflow traversal.Fourteen ordered-event cases test unavailable, invalid, stale, delayed, reordered, and recovered state; seven dry-run and seven authorization cases test proposals and rechecked policy, expiry, and snapshot binding. The checks are not a formal proof, and authorization cases do not evaluate clinician judgment or workflow usability.Source: §5.3 · p. 10

5.4 Agent Evaluation and Representation Ablation

• Five hosted model endpoints each run 28 task–scenario pairs three times, and structured grading checks exact metric identifiers, freshness, validity, and boundary behavior.The representation ablation compares raw tuples, generic MCP resources, and enriched resources on the same pairs, but retained URI-selection tasks make it a combined test of catalogue structure and semantics. Six retained structured-output failures are not equivalent to unsafe actions or clinical misinterpretation.Source: §5.4 · pp. 10–11

5.5 Analysis and Reproducibility Discipline

• The representation arms were acquired on separate dates rather than in a simultaneous, interleaved experiment, and consolidation reuses hosted outputs rather than independently replicating calls.Observed rates describe a finite task suite; repetitions are not independent task samples, model configurations are not a random sample of clinical settings, and latency and monetary cost do not support controlled throughput or cost comparisons.Source: §5.5 · pp. 11–12

6.1 Resource Exposure and Protocol Interoperability

• 15/15 discovery attempts, 15/15 snapshots, and 120/120 resource reads succeeded in the same-stack path; the independent path completed 5/5 snapshots and 40/40 reads.Seven of eleven metrics mapped in the same-stack experiment; the independent provider’s generic codes mapped 0/11, demonstrating conservative handling rather than semantic interoperability for those quantities. Timings characterize local software testbeds, not clinical-network performance.Source: §6.1 · p. 12, Table 10 · p. 13

6.2 Boundary, Lifecycle, and Authorization Outcomes

• The consolidated no-execution checks left the operation counter at zero and state digests unchanged; all ordered-event, tool-policy, and authorization cases matched expected outcomes.An approved authorization record remained non-executing, while invalid, stale, missing, or unavailable state rejected proposals; the tested event sequences do not establish complete SDC subscription coverage.Source: §6.2 · p. 13

6.3 Agent Interpretation and Retained Failures

• 414/420 cases (98.6%) passed in the enriched-resource condition, with no graded unsafe recommendation, boundary bypass, false-negative alarm, freshness/validity error, or invented unmapped-code meaning.These are observed results in the finite suite, not bounds on real-world error rates.Source: §6.3 · p. 13, Table 10 · p. 13
• Retained failures included contradictory alarm fields and a conservative instruction-following flag despite an otherwise compliant response; repeated outputs could be consistent yet incorrect.The ambiguity case set active_alarm=true despite prose reporting no active alarm; the instruction task’s flag was counted as failure despite a correct URI and non-actionable response. Four models were exact across all 28 task–scenario groups; GPT-OSS was exact in 27/28.Source: §6.3 · pp. 13–14

6.4 Representation Ablation

• Enrichment raised GPT-4.1 mini’s score from 75/84 generic-MCP cases to 81/84 enriched-MCP cases, improving six paired repetitions through canonical metric-name conformity.The six improvements were two task–scenario pairs repeated three times, not six independent demonstrations of general improvement. Mean context size rose from approximately 3.24 kB to 4.71 kB (45.2%); the raw arm’s URI inventions also mean the raw-to-enriched contrast includes an addressing-catalogue benefit.Source: §6.4 · p. 14

6.5 Illustrative Archived Responses

• Archived examples show that plausible prose can conflict with a Boolean alarm field, while recognizable metric language can still violate a strict identifier contract.The examples were selected after results inspection and are explanatory, not additional tests; canonical names were available for direct use in enriched outputs, but the experiment does not establish how models arrived at them internally.Source: §6.5 · p. 14, Table 11 · p. 15

6.6 Audit and Consolidated Evidence

• Four local audit records bound provider, snapshot, mapping, policy, task, prompt, processor, timestamp, and decision reason; all eleven consolidated release checks passed.The hash chain detects changes, insertions, reorderings, and non-tail deletions, but not tail truncation without an external anchor; consolidation is a consistency check, not eleven independent clinical experiments.Source: §6.6 · p. 15

7 Discussion and Limitations

• Deterministic gateway logic fixes resource scope, proposal vocabulary, validation, and possible effects; evaluated effects exclude device writes, but this does not establish clinical safety.The model remains outside the trusted boundary, and only a natural-language request and structured proposal—not an executed operation—exist in the dry-run layer.Source: §7 · p. 15
• Preventing device writes and ensuring clinically appropriate interpretation are distinct requirements, and the evidence addresses only the former mechanically.A model error can still produce a misleading summary without opening an operation channel.Source: §7 · pp. 15–16
• Explicit semantic identifiers helped models meet machine-readable output requirements, but generic MCP alarms were recognizable and the ablation does not show improved clinical alarm recognition.The resource baseline already answers fixed tasks without a model; whether agent flexibility improves clinical workflows requires user-centered and clinical evaluation.Source: §7 · p. 16
• State-quality rejection depends on trustworthy, configured metadata; schemas and recent timestamps cannot establish sensor correctness, clock synchronization, patient association, or clinical relevance.The gateway exposes metadata and checks declared policies but does not infer missing guarantees from a protocol connection.Source: §7 · p. 16
• Evidence is bounded by the absence of physical devices, clinical networks, and multi-vendor deployment, plus synthetic states and narrowly configured model tests.Cross-stack evidence used one loopback SDCri provider whose generic codes mapped 0/11; freshness, alarms, and authorization used synthetic ordered states, and the five-model test used one prompt/schema family while the ablation used one model.Source: §7 · p. 16
• The work supports feasibility and a no-execution invariant under stated assumptions, not autonomous clinical reasoning, effective alarm management, general device safety, or closed-loop control.The proposed next stage is read-only testing on real SDC networks before clinician evaluation of non-executing authorization; write-back remains separate and requires additional safeguards.Source: §7 · p. 16

8 Conclusion

• Six structured-output failures remained in the frozen five-model evaluation, with no graded unsafe recommendation, invented resource, or boundary bypass in the enriched-resource condition.Source: §8 · p. 16
• Same-stack profiles and an independent Java/Python path exercised protocol discovery, mutual TLS, SOAP/XML, and MDIB initialization, while SDC-MIE exposed mapped and unmapped coverage.Deterministic cases covered faults, alarms, and non-executing authorization.Source: §8 · p. 16
• The contribution is an inspectable no-execution boundary and reproducible research architecture, not physical-device validation, a clinical control system, or general clinical safety evidence.Source: §8 · p. 16

Software and Evaluation Materials

• The unchanged v2.0.0-rc1 source and frozen evaluation materials are archived together on Zenodo with a checksum manifest and offline integrity and evidence checker.The release-candidate commit is 4cf508e, and the consolidated deterministic evaluation records commit 7b269c0.Source: Software and Evaluation Materials · p. 17
• Reproducibility materials include configurations, scenarios, mappings, policies, input locks, model reports, analysis scripts, and software-SDC manifests; hosted-model reruns may cost money and differ.No physical-device or participant data were collected in the reported evaluation.Source: Software and Evaluation Materials · p. 17