Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

LLM-Anwendungen und Gesundheitsdaten

Verwendung von Large Language Models mit Gesundheitsdaten: die Context API-Anfrage und -Antwort, Cloud- und lokale Modelle, agentische Systeme, Retrieval vs. Kontext und Prompting mit Herkunftsnachweis.

Eine Anwendung, die ein Large Language Model mit Gesundheitsdaten verwendet, muss ein Problem lösen, das das Modell nicht kann: Welchen Teil der Patientenakte soll sie in den Prompt aufnehmen und wie soll sie ihn kennzeichnen, damit das Modell Fakten von Notizen unterscheiden kann. Anpheros löst dies auf Datenseite mit einer Kontext-API: Gegeben einen Patienten, eine Aufgabe und ein Token-Budget, gibt sie die relevanten Abschnitte des HL7 FHIR R4-Datensatzes des Patienten zurück, wobei jeder Eintrag mit seiner Quelle gekennzeichnet ist. Ihre Anwendung sendet diesen Kontext an das von Ihnen gewählte Modell – gehostet oder lokal.

Wie verbinde ich ein LLM mit FHIR-Medizindaten? Bewahren Sie die Datensätze in einem FHIR-Speicher auf, auf den das Modell nicht direkt zugreifen kann – mit Anpheros, dem HL7 FHIR R4-Datensatz des Patienten – fordern Sie einen budgetierten, quellengekennzeichneten Kontext an (POST /v1/context) und fügen Sie diesen Kontext in den Prompt des von Ihnen gewählten Modells ein. Das Modell erhält niemals Datenbank- oder API-Anmeldeinformationen; Ihre Anwendung führt die Aufrufe im Rahmen der Zustimmung des Patienten durch.

Anpheros führt keine Modelle aus und hat keine native Integration mit einem Modell-Anbieter oder einer lokalen Laufzeitumgebung.

Das Muster

1. your app  ── POST /v1/context {patient, task, question, budget_tokens, format} ──►  Anpheros
2. Anpheros  ── sections + text + omitted + warnings + manifest_id ──────────────────►  your app
3. your app  ── system prompt + context + user question ─────────────────────────────►  the model
4. the model ── answer ───────────────────────────────────────────────────────────────►  your app
5. your app  ── optional write-back with author_type "ai" ──────────────────────────►  Anpheros

Der Kontext-Request

curl -X POST https://platform.anpheros.com/v1/context -H "Authorization: Bearer $TOKEN" -H 'content-type: application/json' -d '{
  "patient": "'$PID'",
  "task": "medication review before a cardiology visit",
  "question": "How did blood pressure evolve over the last 3 months?",
  "budget_tokens": 1500,
  "format": "text"
}'

Die Kontextantwort

• sections — zum Beispiel eine Zusammenfassungskarte, Diagnosen, Medikamente, Allergien, Impfungen, Laborergebnisse, Vitalparameter mit wöchentlichen Trends und Markern vor/nach der Behandlung, Symptome, Zeitachse und Dokumente. Jeder Eintrag trägt author_type und source.
• omitted — was nicht ins Budget passte; teilt dem Modell mit, dass sein Kontext unvollständig ist.
• warnings, provenance_note.
• text — wenn format text ist.
• manifest_id — der Nachweis, welche Abschnitte und Quellen verwendet wurden, verknüpft mit dem Zugriffsprotokoll.
• ein ai_notes-Abschnitt — Werte, die eine KI zuvor geschrieben hat, erscheinen nur dort, markiert als nicht verifiziert, niemals vermischt mit den klinischen Abschnitten.

Cloud-Modelle

Bei einem gehosteten Modell – von OpenAI, Anthropic, Google, xAI oder einem anderen Anbieter – stellt Ihr Backend den Kontext in den Prompt und ruft die API des Anbieters auf. Der Kontext verlässt Ihre Infrastruktur für diesen Anbieter, daher:

• stellen Sie sicher, dass die Zustimmung des Patienten und Ihre Datenschutzerklärung das Senden von Daten dorthin abdecken;
• schließen Sie eine Datenverarbeitungsvereinbarung mit dem Anbieter ab, die für Gesundheitsdaten geeignet ist;
• senden Sie nur das, was die Aufgabe benötigt – das Token-Budget und explizite needs helfen dabei.

Lokale Modelle

Bei einem Modell, das Sie selbst ausführen – zum Beispiel über Ollama oder eine andere lokale Laufzeitumgebung – ist der einzige Netzwerkaufruf, der Patientendaten überträgt, der zwischen Ihrem Backend und Anpheros; der Prompt und die Antwort verbleiben auf Ihrer Infrastruktur. Kleinere lokale Modelle haben kleinere Kontextfenster: geringere budget_tokens entsprechend und bevorzugen format: "text".

Agentische Systeme

Wenn das Modell entscheidet, welche Aufrufe es tätigen soll, stellen Sie ihm Werkzeuge (Kontext, Suche, Zeitachse) anstelle von rohen Anmeldeinformationen zur Verfügung, halten Sie die Scopes eng und protokollieren Sie jeden manifest_id neben der Antwort. KI-Agenten und medizinische Daten

Context API oder eigene Abfrage?

Eine Abfrage-Pipeline über Freitext (Einbettung von Dokumentenabschnitten und deren Suche) ist nützlich für unstrukturierte Notizen. Für strukturierte medizinische Daten ist die Context API in der Regel einfacher und sicherer: Sie arbeitet mit kodierten FHIR-Ressourcen, behält die Herkunft bei, kennt Trends und Behandlungszeiträume, respektiert Einwilligungen und wird auditiert. Die beiden können kombiniert werden – zum Beispiel Kontext von Anpheros plus abgerufene Passagen aus von Ihnen verwalteten Dokumenten.

Prompting mit Provenienz

Behalten Sie die Labels im Prompt bei und erklären Sie dem Modell, was sie bedeuten:

The context below comes from the patient's record. Each item is labelled with its author type
(patient, practitioner, device, import, derived) and source. Items under ai_notes were written by an
AI earlier and are not verified. Say which items your answer relies on. If the context is marked as
partial, say so. Do not give a diagnosis or change a treatment; suggest discussing it with a clinician.

Verwandte Themen

• KI-gestützte Gesundheitsanwendungen
• KI-Agenten und medizinische Daten
• Erstellung eines medizinischen Chatbots mit strukturierten Daten
• Sicherheit, Datenschutz und Datenresidenz

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card