Sicherer klinischer LLM-Zugriff über MCP

Ein forschungsorientiertes Framework für den sicheren Zugriff auf strukturierte klinische Daten unter Verwendung von Open-Weight Large Language Models und dem Model Context Protocol (MCP).

Überblick

Large Language Models können eine intuitive Schnittstelle zur Erkundung komplexer Daten bieten, aber die direkte Verbindung eines LLM mit einer klinischen Datenbank bringt wichtige Herausforderungen in Bezug auf Datenzugriff, Sicherheit, Zuverlässigkeit und Kontrolle mit sich.

Dieses Projekt untersucht eine kontrollierte Alternative: die Bereitstellung strukturierter klinischer Daten für ein LLM über eine Reihe von eng begrenzten, validierten und auditierbaren Tools unter Verwendung des Model Context Protocol (MCP).

Anstatt dem Modell zu erlauben, beliebiges SQL zu generieren und auszuführen, stellt das System zweckgebundene Tools für den Zugriff auf klinische Informationen bereit. Dadurch entsteht eine explizite Sicherheitsgrenze zwischen dem Sprachmodell und der zugrunde liegenden Datenbank.

Das Projekt kombiniert:

• Open-Weight-LLMs

• Model Context Protocol (MCP)

• Strukturierte relationale klinische Daten

• Python-basierte Datentransformations-Pipelines

• Tool-begrenzten Datenbankzugriff

• Eingabevalidierung und Ergebnisgrößenbegrenzungen

• Audit-Protokollierung

• Sicherheitstests

• LLM-basierte Beantwortung klinischer Fragen

Alle in diesem Projekt verwendeten klinischen Daten sind synthetisch. Es werden keine echten Patientendaten gespeichert oder verarbeitet.

Related MCP server: atlas_mcp

Forschungsmotivation

Das Projekt untersucht die folgende Frage:

Wie können Open-Weight-Sprachmodelle auf strukturierte klinische Daten zugreifen und diese analysieren, während eine kontrollierte und auditierbare Datenzugriffsgrenze aufrechterhalten wird?

Dies ist besonders relevant für klinische Forschungsumgebungen, in denen medizinisches Fachpersonal möglicherweise einen Zugriff in natürlicher Sprache auf komplexe Datensätze benötigt, ohne einem LLM uneingeschränkten Zugriff auf die zugrunde liegende Datenbank zu gewähren.

Das System konzentriert sich daher auf die Schnittstelle zwischen:

Human
  │
  │ Natural-language question
  ▼
Open-weight LLM
  │
  │ Tool selection
  ▼
MCP Interface
  │
  │ Validated, scoped request
  ▼
Clinical Database
  │
  ▼
Synthetic Clinical Data

Systemarchitektur

                  ┌──────────────────────────┐
                  │       User / Clinician   │
                  └────────────┬─────────────┘
                               │
                       Natural-language
                            question
                               │
                               ▼
                  ┌──────────────────────────┐
                  │    Open-weight LLM       │
                  │      (Ollama)             │
                  └────────────┬─────────────┘
                               │
                         Tool selection
                               │
                               ▼
                  ┌──────────────────────────┐
                  │       MCP Client          │
                  │     Clinical Agent        │
                  └────────────┬─────────────┘
                               │
                         MCP protocol
                               │
                               ▼
                  ┌──────────────────────────┐
                  │       MCP Server          │
                  │                          │
                  │  • Input validation      │
                  │  • Tool scoping          │
                  │  • Result limits         │
                  │  • PII exclusion         │
                  │  • Audit logging          │
                  └────────────┬─────────────┘
                               │
                       Controlled tools
                               │
                               ▼
                  ┌──────────────────────────┐
                  │    Relational Database   │
                  │        SQLite            │
                  └────────────┬─────────────┘
                               │
                               ▼
                  ┌──────────────────────────┐
                  │   Synthetic Clinical     │
                  │        Data              │
                  │        Synthea            │
                  └──────────────────────────┘

Daten-Pipeline

Klinische Daten werden mit Synthea generiert, einem synthetischen Patientengenerator, der realistische, aber nicht identifizierbare medizinische Aufzeichnungen erzeugen soll.

Die generierten heterogenen CSV-Dateien werden in eine verknüpfte relationale Datenbank transformiert:

Synthea
   │
   ├── Patients
   ├── Encounters
   ├── Conditions
   ├── Observations
   └── Medications
          │
          ▼
     Ingestion Pipeline
          │
          ▼
   Relational SQLite DB

Die Ingestions-Pipeline ist in Python implementiert und stellt Beziehungen zwischen Patienten, Behandlungskontakten, Diagnosen, Beobachtungen und Medikamenten her.

Warum MCP statt direktem SQL?

Eine zentrale Designentscheidung ist es, dem Sprachmodell kein generisches SQL-Ausführungstool zur Verfügung zu stellen.

Eine naive Architektur könnte wie folgt aussehen:

LLM → Generate SQL → Execute SQL → Database

Dieser Ansatz gibt dem Modell erhebliche Kontrolle über die Datenbank und schafft unnötige Sicherheitsrisiken.

Dieses Projekt verwendet stattdessen:

LLM
 │
 ▼
MCP Tool
 │
 ├── Validate parameters
 ├── Restrict operation
 ├── Limit result size
 ├── Exclude identifying fields
 └── Record audit event
 │
 ▼
Database

Jedes Tool hat einen eng definierten Zweck.

Zum Beispiel:

get_patient_summary()
get_conditions()
get_medications()
get_lab_trends()
get_encounters()

Das Modell kann diese Tools auswählen und parametrisieren, aber es kann kein beliebiges SQL ausführen.

Dadurch entsteht eine Sicherheitsgrenze auf Tool-Ebene, die unabhängig von der Fähigkeit des Modells ist, System-Prompts zu befolgen.

Sicherheitsmodell

Das Projekt behandelt das LLM als nicht vertrauenswürdige Komponente.

Sicherheitskontrollen werden daher wo immer möglich außerhalb des Modells implementiert.

Implementierte Kontrollen

• Tool-begrenzter Datenbankzugriff

• Eingabevalidierung

• Nur-Lese-Operationen

• Ergebnisgrößenbegrenzungen

• Ausschluss identifizierender Felder

• Audit-Protokollierung

• Tests auf Protokollebene

• Sicherheitstest-Suite

Das Designziel ist:

Verlassen Sie sich nicht darauf, dass das LLM Sicherheitsrichtlinien durchsetzt, die von der Anwendungsschicht durchgesetzt werden können.

Dies ist besonders wichtig, wenn Sprachmodelle mit sensiblen Datenquellen verbunden werden.

MCP-Tools

Der MCP-Server stellt derzeit fünf kontrollierte Tools bereit.

Jedes Tool validiert seine Argumente, bevor es auf die Datenbank zugreift.

LLM-Integration

Das Projekt ist für die Arbeit mit lokalen Open-Weight-Sprachmodellen über Ollama konzipiert.

Beispiel:

User:
Find a female patient and summarize her conditions.

        ↓

Open-weight LLM

        ↓

MCP tool selection

        ↓

get_patient_summary(...)

        ↓

Validated database query

        ↓

Structured result

        ↓

LLM-generated response

Die Architektur hält die klinische Datenbank lokal, anstatt zu verlangen, dass Patientendaten an eine externe LLM-API gesendet werden.

Evaluierung

Das Projekt umfasst ein Evaluierungs-Framework, das sowohl Sicherheit als auch Benutzerfreundlichkeit abdeckt.

Sicherheitsevaluierung

Die Sicherheitstest-Suite prüft, ob die MCP-Schicht unbefugte oder unsichere Operationen korrekt verhindert.

Beispiele umfassen:

• Ungültige Tool-Parameter

• Übermäßige Ergebnisanfragen

• Unbefugter Feldzugriff

• Unsichere Datenbankoperationen

• Verstöße gegen Tool-Grenzen

• Verhalten der Audit-Protokollierung

Aktueller Status der Sicherheitstests:

7 / 7 security tests passing

Benutzerfreundlichkeitsevaluierung

Das Evaluierungs-Framework ist darauf ausgelegt, Folgendes zu messen:

• Genauigkeit der Fragenbeantwortung

• Genauigkeit der Tool-Auswahl

• Antwortlatenz

• Erfolgreiche Durchführung klinischer Abfragen

• Fehlerfälle

Das Ziel ist es, nicht nur zu bewerten, ob das System funktioniert, sondern wie zuverlässig ein LLM über eingeschränkte Tools mit strukturierten klinischen Daten interagieren kann.

Projektstruktur

secure-clinical-llm-mcp/
│
├── agent/
│   ├── __init__.py
│   └── clinical_agent.py
│
├── eval/
│   ├── security_tests.py
│   ├── usability_benchmark.py
│   └── EVALUATION_REPORT.md
│
├── mcp_server/
│   └── server.py
│
├── pipeline/
│   └── ingest.py
│
├── synthea/
│   └── synthea.properties
│
├── requirements.txt
├── README.md
└── .gitignore

Installation

1. Repository klonen

git clone https://github.com/eyasu11321238a/secure-clinical-llm-mcp.git
cd secure-clinical-llm-mcp

2. Python-Abhängigkeiten installieren

pip install -r requirements.txt

3. Synthea herunterladen

Synthea ist nicht im Repository enthalten.

Laden Sie die neueste Version herunter:

cd synthea

curl -L -o synthea-with-dependencies.jar \
  https://github.com/synthetichealth/synthea/releases/download/master-branch-latest/synthea-with-dependencies.jar

Java 17 oder neuer ist erforderlich.

4. Synthetische klinische Daten generieren

java -jar synthea-with-dependencies.jar \
  -p 25 \
  -c synthea.properties \
  Massachusetts

5. Die relationale Datenbank aufbauen

cd ../pipeline

python ingest.py \
  --csv-dir ../synthea/output/csv \
  --db ../data/clinical.db

6. Den MCP-Server starten

cd ../mcp_server

python server.py

7. Die Sicherheitstests ausführen

cd ../eval

python security_tests.py

Lokales LLM

Der Agent kann mit einem Open-Weight-Modell verbunden werden, das lokal über Ollama läuft.

Zum Beispiel:

ollama pull llama3.2:3b

Dann ausführen:

python agent/clinical_agent.py \
  "Find a female patient and summarize her conditions"

Der Agent kommuniziert mit dem MCP-Server, anstatt direkt auf die Datenbank zuzugreifen.

Aktueller Status

Abgeschlossen

• Synthetische Generierung klinischer Daten mit Synthea

• Ingestions-Pipeline für heterogene klinische Daten

• Relationale klinische SQLite-Datenbank

• MCP-Server

• Fünf begrenzte klinische Datentools

• Eingabevalidierung

• Ergebnisgrößenbeschränkungen

• Ausschluss identifizierender Felder

• Audit-Protokollierung

• MCP-Tests auf Protokollebene

• Integration lokaler Ollama-Agenten

• Sicherheitstest-Suite

• 7/7 Sicherheitstests bestanden

In Arbeit

• Schema-bewusste klinische Abfrageebene

• Erweiterter Benchmark für klinische Fragen

• Evaluierung der Tool-Auswahlgenauigkeit

• Latenzevaluierung

• Evaluierung von Prompt-Injection

• Erweiterte Sicherheitsanalyse

• Forschungs-Evaluierungsbericht

Zukünftige Arbeiten

Es sind mehrere Erweiterungen geplant, um den Prototyp zu einem umfassenderen Forschungs-Framework weiterzuentwickeln.

1. Schema-bewusstes Reasoning

Stellen Sie dem LLM strukturierte Beschreibungen des relationalen Schemas bereit und untersuchen Sie, wie effektiv es geeignete Tools und Parameter auswählen kann.

2. Erweiterter klinischer Benchmark

Entwickeln Sie einen Benchmark mit klinischen Fragen, die von einfachen Nachschlageabfragen bis zu analytischen Multi-Tabellen-Abfragen reichen.

3. Sicherheitsevaluierung

Bewerten Sie die Robustheit gegenüber:

• Prompt-Injection

• Bösartigem klinischem Text

• Unbefugten Datenanfragen

• Tool-Manipulation

• Übermäßigem Datenabruf

• Versuchen, Zugriffskontrollen zu umgehen

4. Heterogene medizinische Daten

Erweitern Sie die Pipeline, um zusätzliche Darstellungen von Gesundheitsdaten zu unterstützen, einschließlich FHIR-Ressourcen.

5. Modellvergleich

Vergleichen Sie mehrere Open-Weight-LLMs hinsichtlich:

• Genauigkeit der Tool-Auswahl

• Genauigkeit klinischer Abfragen

• Latenz

• Fehlerrate

• Sicherheitsrobustheit

Einschränkungen

Dieses Projekt ist ein Forschungsprototyp und kein klinisches Entscheidungsunterstützungssystem.

Die Daten sind vollständig synthetisch und bilden daher nicht die volle Komplexität, das Rauschen, die fehlenden Werte oder die Verteilung realer Krankenhausdaten ab.

Das System sollte nicht für medizinische Diagnosen, Behandlungsentscheidungen oder die reale Patientenversorgung verwendet werden.

Vor einer Anwendung des Ansatzes in realen klinischen Umgebungen wären weitere Validierungen erforderlich.

Forschungsrelevanz

Dieses Projekt befindet sich an der Schnittstelle von:

Large Language Models
        +
Structured Data
        +
Medical Informatics
        +
MCP / Tool Calling
        +
Data Engineering
        +
AI Security
        +
Evaluation

Das zentrale Ziel ist es zu untersuchen, wie Sprachmodelle eine Schnittstelle in natürlicher Sprache zu strukturierten klinischen Daten bereitstellen können, ohne dem Modell uneingeschränkten Zugriff auf die zugrunde liegende Datenquelle zu gewähren.