cs.DCSep 25, 2026
SaveA Safety-Bounded SDC-to-MCP Gateway for Medical AI Agents
Organizations: University of Lübeck, Lübeck, Germany
Abstract
The Model Context Protocol (MCP) provides a common interface through which AI applications discover and use external resources and tools. It allows language-model agents to ground their reasoning in current system state and interact with heterogeneous services. In medical environments, however, exposing device state and action affordances requires deterministic constraints on possible effects. We present an IEEE 11073 Service-Oriented Device Connectivity (SDC)-to-MCP gateway that exposes metrics, alarms, context references, and semantic metadata as read-only resources, while representing selected action affordances as policy-validated dry-run tools. The term safety-bounded denotes a narrow no-execution property: agent-facing requests dispatch no SDC device operation. A Python prototype supports simulated fault and lifecycle experiments, a software-reference protocol path spanning independent Java and Python implementations, deterministic baselines, representation ablations, and multi-model agent evaluation. The results show semantically explicit resource exposure, visible rejection of invalid or outdated state, and preservation of the no-execution boundary across resource, proposal, and authorization paths. Explicit semantic metadata improved conformity to required metric identifiers in structured alarm outputs relative to a generic representation, while retained structured-output failures reveal a distinction between plausible narrative answers and task-compliant machine-readable results.
Figures & tables
| Approach | Intended/temporal semantics | Agent interface | Write authority/boundary |
|---|---|---|---|
| FHIR/EHR | Longitudinal record/workflow | Patient-data APIs | Separate from device operations |
| Direct SDC | Current MDIB/device state | Application-specific | SDC roles/local logic |
| Generic MCP | Application-defined context | Generic resources/tools | Server-specific |
| SDC-MCP+MIE | Current state+semantics | Read-only/proposals | No-execution boundary |
Table 1: Conceptual positioning (not a performance ranking).
Figure 1: SDC-to-MCP gateway architecture and intended extension points. The evaluated prototype exposes read-only MCP resources and policy-checked dry-run tools; proposals and approvals do not execute device operations. Green write-path arrows and the “future/controlled” tool label denote prospective functionality only. The infusion pump is an illustrative extension, not an evaluated provider.
| Actor | Responsibility; excluded authority |
|---|---|
| Agent | Interpret context/propose; no clinical or device authority |
| MCP host/client | Launch/constrain subprocess and protect credentials; no policy bypass |
| Gateway | Map, validate, redact, audit, and enforce no execution |
| SDC provider | Supply identity/state; authenticity not established by EPR alone |
| Clinician | Retain clinical judgment and any future approval |
| Operator | Approve configuration, protect host/keys/logs, anchor audits |
Table 2: Responsibility and accountability boundary.
| SDC/BICEPS-side construct | MCP representation | Role |
|---|---|---|
| Device/component descriptor | sdc://devices | Inventory |
| Metric descriptor/state | sdc://devices/ {id}/metrics | Measurements |
| Alert condition/state | sdc://devices/ {id}/alarms | Alarm status |
| Context state | sdc://devices/ {id}/context | References |
| Normalized state view | sdc://devices/ {id}/mdib/raw | Trace/debug |
| Codes, handles, units, policies | sdc://mapping | SDC-MIE metadata |
Table 3: Conceptual SDC-to-MCP mapping.
| Stage | Selected content and role |
|---|---|
| Normalized source | Device holdout-monitor-a ; handle metric.hr ; code 150456 ; value 148; unit beats/min . Alarm alarm.hr.high refers to this handle, is present, and has medium priority. |
| Declared semantics | SDC-MIE schema 1.0 , document 1.0.0 : semantic_name=heart_rate , read-only access, informational safety class. Compatible code/handle/unit yield mapping_state=mapped . |
| MCP resources | sdc://devices/holdout-monitor-a/metrics carries the mapped measurement; the corresponding /alarms resource carries alarm state and its metric reference. Payloads include mapping version and source-file hash. |
| Agent context | A joined active-alarm record identifies the same device, heart_rate , value 148, unit beats/min , and medium priority. The ventilator alarm remains a separate record. |
| Observed response | The enriched-context model returned active_alarm=true , the monitor’s heart_rate alarm with medium priority, and the ventilator’s airway_pressure alarm with high priority. The frozen alarm-detection grader passed this response. |
Table 4: Trace of one synthetic monitor metric through the evaluated interface. Fields are selected for explanation, not a complete protocol message. The final row summarizes an archived GPT-4.1-mini response, repetition 1.
| RQ | Evidence | Tested outcome | Boundary |
|---|---|---|---|
| 1 | Functional scenarios; Python and Java software providers | Readable resources, protocol snapshots, explicit mapping coverage | No hardware or multi-vendor deployment |
| 2 | Instrumented requests, static checks, abstract workflow, proposal and approval cases | No attempted device operation; unchanged state in controlled tests | Mechanically checked, not full implementation verification |
| 3 | Fourteen ordered-event cases | Visible rejection and recovery under specified faults and alarm transitions | No continuous subscription or clinical timing validation |
| 4 | Twenty-eight task–scenario pairs, five models, representation ablation | Task compliance, repeated-output consistency, interpretable failure modes | Synthetic tasks; ablation uses one model |
Table 5: Research questions, evidence, and scope of inference.
| Configuration | Main challenge | Tasks |
|---|---|---|
| Multiple devices and alarms | Interpret simultaneous alarms and retain device associations | 6 |
| Ambiguous device catalogue | Select exact same-type device, metric, and resource; resist embedded instructions | 6 |
| Unmapped metric | Abstain from inventing the meaning of an unsupported code | 5 |
| Unavailable provider | Identify missing state without inventing a device or URI | 5 |
| Invalid and stale state | Distinguish validity and freshness from the presence of a value | 6 |
Table 6: Synthetic hold-out configurations. Counts are distinct applicable task–scenario pairs before model repetitions.
| Model label | Configured identifier | Hosting route |
|---|---|---|
| GPT-4.1 mini | gpt-4.1-mini-2025-04-14 | OpenAI |
| Gemini 2.5 Flash | gemini-2.5-flash | Google Gemini API |
| GPT-OSS 20B | gpt-oss:20b | Ollama Cloud |
| Gemma 4 26B | gemma-4-26b-a4b-it | University of Lübeck AI Lab |
| Qwen 3.6 27B | qwen3.6-27b | Digital Hub Schleswig-Holstein |
Table 7: Configured model identifiers in the frozen run. Hosting routes are experimental context, not privacy or quality endorsements.
| Evidence layer | Date | Unit and extent | Version or provenance anchor |
|---|---|---|---|
| In-memory reference | 21 May | Four scenarios, three runs each; 200 measured iterations after 20 warm-ups per run | Historical simulator aggregates; separate from protocol timings |
| Multi-model hold-out | 8 August | Five models 28 task–scenario pairs three repetitions; deterministic baseline once per pair | Frozen 32-file scientific input set; model identifiers in Table 7 |
| Representation ablation | 9 August | Two new arms 28 pairs three repetitions; reuse 84 enriched and 28 deterministic cases | Separate input lock; same GPT-4.1-mini snapshot and task definitions |
| Python/Python protocol | 10 August | Three MDIB profiles five discovery/snapshot repetitions; eight MCP reads per snapshot | sdc11073 2.4.1; isolated containers, Python 3.12 |
| Java/Python protocol | 10 August | One independent provider; five snapshot repetitions; eight MCP reads per snapshot | SDCri 7.0.0 ( cc46b3b ); sdc11073 2.4.1 |
| Deterministic consolidation | 10 August | 28 agent cases; 14 lifecycle cases; seven authorization cases; no-execution and mapping checks | Clean code commit 7b269c0 ; model and protocol artifacts reused and hash-linked |
Table 8: Recorded experimental provenance and replication units. Dates are in 2026. Reused reports are not additional model observations; snapshot reads are not independent devices.
| Provider/consumer path | Snapshots | MCP reads | Coverage and setting |
|---|---|---|---|
| Python/Python, three profiles | 15/15 | 120/120 | 7/11 metrics mapped; separate Linux containers |
| SDCri Java/Python | 5/5 | 40/40 | 0/11 generic codes mapped; loopback |
Table 9: Software-reference protocol results. Mapping counts refer to exposed metric coverage, not multiplied repetition counts.
| Model or representation | Passed | Rate (%) | Mean call (s) |
|---|---|---|---|
| A. Enriched resources: 28 task–scenario pairs, three repetitions | |||
| Gemini 2.5 Flash | 84/84 | 100.0 | 5.01 |
| Hosted Gemma 4 26B | 84/84 | 100.0 | 1.16 |
| Hosted Qwen 3.6 27B | 84/84 | 100.0 | 13.62 |
| GPT-4.1 mini | 81/84 | 96.4 | 2.14 |
| GPT-OSS 20B | 81/84 | 96.4 | 3.14 |
Table 10: Descriptive model and representation results. Repeated cases are not independent task samples. Mean hosted-call times include service conditions.
| Case | Expected | Archived output | Frozen decision |
|---|---|---|---|
| A: GPT-OSS summary, enriched context | No active alarm; active_alarm=false | “No active alarms are present on either device.” Yet active_alarm=true . | Fail: explicit Boolean contradicts the expected state despite correct prose. |
| B: GPT-4.1 mini, alarm detection | Monitor metric heart_rate , medium priority, active | Generic: High Heart Rate . Enriched: heart_rate . Both identify the correct device, priority, and active state. | Generic fails only the metric-name check; enriched passes. |
| B: GPT-4.1 mini, simultaneous alarm set | Monitor heart_rate and ventilator airway_pressure , with their priorities | Generic: heart rate , airway pressure . Enriched: heart_rate , airway_pressure . | Generic fails exact set matching; enriched passes. Device and priority associations are retained in both. |
Table 11: Expected answers, archived outputs, and unchanged grader decisions. Both alarm tasks in example B show the same generic-versus-enriched outcome across all three repetitions.