# KI-Agenten und medizinische Daten

> Kontrollierter Zugriff für KI-Agenten auf Patientenakten: OAuth-Scopes, die Werkzeuge, die ein Agent benötigt, Audit und Herkunft dessen, was er liest und schreibt, sowie ereignisgesteuerte Agenten.

Source: https://developers.anpheros.com/de/guides/ai-agents-medical-data

**Ein KI-Agent ist ein Programm, bei dem ein Sprachmodell Schritt für Schritt entscheidet, welche Aktionen es ausführen soll – welche Daten es lesen, welches Werkzeug es aufrufen, was es schreiben soll –, um eine Aufgabe zu erfüllen.** Wenn die Aufgabe die medizinische Akte eines Patienten betrifft, benötigt der Agent einen kontrollierten Zugriff: Er sollte nur auf die Akten zugreifen dürfen, die ihm erlaubt sind, nur die Teile davon, die er benötigt, eine Spur dessen hinterlassen, was er gelesen hat, und das, was er geschrieben hat, als KI-generiert kennzeichnen. Anpheros bietet diesen kontrollierten Zugriff über seine API; das Agenten-Framework und das Modell gehören Ihnen.

Anpheros verfügt über keine integrierte Agentenlaufzeit, keinen Model Context Protocol (MCP)-Server und keine offizielle Integration mit einem Agenten-Framework oder Modell-Anbieter. Agenten nutzen es wie jede andere Anwendung: über die REST- und FHIR-API oder die SDKs.

## Die Architektur

```
Patient ── grants access (OAuth scopes, duration) ────────────────┐
                                                                  ▼
Agent runtime (your code, any framework) ── tools ──► Anpheros API ──► the patient's FHIR record
      │   ▲                                   │
      │   └── context, search results ◄───────┘      every call: scope checks + access log
      ▼
The model you choose (hosted or local) ── plans the next step
```

Das Modell schlägt Aktionen vor; Ihre Laufzeitumgebung führt diese mit den ihr vorliegenden Anmeldeinformationen aus. Das Modell selbst hält niemals einen Anpheros-Schlüssel oder -Token.

## Kontrollierter Zugriff

- **Wessen Datensätze.** Mit einem API-Schlüssel sieht der Agent die Patienten, die Ihr Projekt erstellt hat. Um auf den bestehenden Datensatz einer Person zuzugreifen, benötigt er eine OAuth-Berechtigung von dieser Person – für einen Patienten, für 30 bis 365 Tage.
- **Welche Daten.** Scopes begrenzen Ressourcentypen und Aktionen, optional auf eine Kategorie: `patient/Observation.rs?category=laboratory` erlaubt einem Agenten, Laborergebnisse zu lesen und zu suchen, und nichts anderes. Um einen Kontext aufzubauen, muss die Berechtigung das Lesen von Beobachtungen, Zuständen, Medikamenten und Allergien erlauben (zum Beispiel `patient/*.rs`).
- **Standardmäßig schreibgeschützt.** Gewähren Sie Schreib-Scopes nur, wenn der Agent etwas aufzeichnen soll.
- **Widerrufbar.** Die Person kann die Berechtigung jederzeit widerrufen; der nächste Aufruf des Agenten wird abgelehnt.

## Werkzeuge, die ein Agent typischerweise benötigt

| Werkzeug | Anpheros-Aufruf | Hinweise |
|---|---|---|
| Kontext für eine Aufgabe abrufen | `POST /v1/context` | der erste Aufruf für die meisten Aufgaben; budgetiert und quellengekennzeichnet ([LLM-Anwendungen und Gesundheitsdaten](https://developers.anpheros.com/de/guides/llm-healthcare-data)) |
| Aktuelle Ergebnisse auflisten | `GET /v1/patients/{id}/observations?category=laboratory&from=…` | Filter: `category`, `code`, `from`, `to` |
| Aktive Medikamente | `GET /v1/patients/{id}/medications?status=active` | |
| Was ist wann passiert | `GET /v1/patients/{id}/timeline?from=…` | eine chronologische Liste über alle Typen hinweg |
| Vollständige FHIR-Details | `GET /fhir/R4/{type}?patient=…` | wenn eine Zusammenfassung nicht ausreicht |
| Eine Standardzusammenfassung | `GET /fhir/R4/Patient/{id}/$summary` | International Patient Summary Bundle |
| Code nachschlagen | `GET /v1/terminology/loinc?q=…` | gebündelte LOINC-Teilmengen; Medikamente über `GET /v1/search` |
| Notiz aufzeichnen | `POST /v1/patients/{id}/observations` mit `author_type: "ai"` | nur mit Schreibberechtigung |

Die OpenAPI-Spezifikation (`https://developers.anpheros.com/openapi.json`) beschreibt jeden Endpunkt und kann in Tool-Definitionen umgewandelt werden; die TypeScript- und Dart-SDKs können direkt als Tools verpackt werden.

## Beispiel: Ein Agent zur Vorbereitung eines Besuchs mit Patienteneinwilligung

Ein Patient, der bereits einen Datensatz in Anpheros führt, bittet einen Drittanbieter-Assistenten, Fragen für einen Kardiologiebesuch vorzubereiten. Der Agent benötigt Lesezugriff auf den Datensatz für eine begrenzte Zeit – nicht mehr.

**1. Einwilligung (OAuth 2.1 + PKCE, SMART v2 Scopes).** Der Assistent leitet die Person zur Einwilligungsseite mit den engsten Scopes weiter, die dennoch einen Kontext ermöglichen (Beobachtungen, Zustände, Medikamente und Allergien):

```ts
import { Anpheros, OAuthAuth, OAuthFlow, generatePkce } from '@anpheros/sdk';

const flow = new OAuthFlow({ baseUrl: 'https://platform.anpheros.com', clientId: CLIENT_ID, redirectUri: REDIRECT_URI });
const pkce = await generatePkce();
const url = flow.authorizeUrl({
  scopes: ['patient/Observation.rs', 'patient/Condition.rs', 'patient/MedicationStatement.rs',
           'patient/AllergyIntolerance.rs', 'offline_access'],
  state, pkce, purpose: 'treatment',
});
// … the person chooses the record and the duration (30–365 days) and allows; on the callback:
const tokens = await flow.exchange(code, pkce);
const anpheros = new Anpheros({ auth: new OAuthAuth({ tokens, onRefresh: flow.refresh }) });
const patient = tokens.patient!;   // this application's own (pairwise) id for the person
```

**2. Werkzeuge.** Die Agentenlaufzeit stellt dem Modell einige Funktionen zur Verfügung; jede davon ist ein echter API-Aufruf, der mit dem Zugriffstoken durchgeführt wird:

```ts
const tools = {
  // POST /v1/context — relevant sections, within a budget, labelled with author type and source
  get_context: (a: { question: string }) =>
    anpheros.context.build({ patient, task: 'prepare a cardiology visit', question: a.question, budget_tokens: 2000, format: 'text' }),
  // GET /v1/patients/{id}/observations?category=laboratory&code=…&from=…
  list_lab_results: (a: { code?: string; from?: string }) =>
    anpheros.observations.list(patient, { category: 'laboratory', code: a.code, from: a.from, limit: 20 }),
  // GET /v1/patients/{id}/timeline?from=…
  get_timeline: (a: { from: string }) => anpheros.timeline.list(patient, { from: a.from, limit: 50 }),
};
```

Beschreiben Sie diese dem Modell im Tool- oder Funktionsaufruf-Format, das Ihre Modell-API verwendet; das Modell schlägt einen Aufruf vor, Ihre Laufzeit führt ihn aus und gibt das JSON zurück. Das Modell sieht niemals das Token.

**3. Was die Plattform erzwingt.** Das Token erreicht nur den Datensatz dieser Person und nur die gescopten Typen; alles andere beantwortet `403` (ein Typ außerhalb der Scopes) oder `404` (ein anderer Patient). Jeder Aufruf – einschließlich jeder Kontextanfrage mit ihrem `manifest_id` – erscheint im Zugriffslog der Person für diese Anwendung. Wenn die Person den Zugriff widerruft, beantwortet der nächste Aufruf `401` und der Agent muss stoppen; das Refresh-Token kann ihn nicht zurückbringen.

**4. Ausgabe.** Der Agent gibt Fragen für den Arzt mit den verwendeten Quellen zurück. Er schreibt nichts zurück, da ihm kein Schreib-Scope gewährt wurde.

## Audit und Herkunft

- Jeder Aufruf, den der Agent tätigt, ist ein Zugriff auf den Datensatz und erscheint im Zugriffsprotokoll des Patienten für Ihre Anwendung – einschließlich jeder Kontextanforderung, die auch ein Manifest der verwendeten Abschnitte und Quellen speichert.
- Alles, was der Agent schreibt, wird in `Provenance` als KI-generiert aufgezeichnet. Wenn später ein Kontext erstellt wird, werden KI-generierte Werte unter `ai_notes` aufgeführt, getrennt von klinischen Fakten, damit ein Agent nicht seine eigene frühere Ausgabe als Beweis zitiert.

## Agents von Events starten

Webhooks ermöglichen es einem Agenten, bei Änderungen – einem neuen Laborergebnis (`resource.created`), einer neuen Zustimmung (`consent.granted`) – ausgeführt zu werden, anstatt abzufragen. Events enthalten nur IDs; der Agent liest dann, was seine Scopes zulassen. [Webhooks](https://developers.anpheros.com/de/guides/webhooks)

## Design-Regeln, die beibehalten werden sollten

1.  Geben Sie dem Agenten die engsten Scopes, die die Aufgabe erfüllen.
2.  Beginnen Sie mit einem Kontext, nicht mit rohen Massenlesevorgängen; beachten Sie `omitted` und `warnings`.
3.  Zeigen Sie die Datenquellen des Patienten in der Antwort des Agenten an.
4.  Lassen Sie den Agenten niemals eigenständig eine Diagnose stellen oder eine Behandlung ändern; leiten Sie solche Ausgaben an einen Kliniker weiter.
5.  Protokollieren Sie die `manifest_id` jedes Kontexts neben der Antwort des Agenten, damit eine Person später sehen kann, worauf die Antwort basierte.

## Verwandte Themen

- [Wie man einem KI-Agenten Zugriff auf medizinische Akten gewährt](https://developers.anpheros.com/de/guides/ai-agent-access-medical-records): Schritt-für-Schritt-Anleitung in Python
- [FHIR MCP-Server für KI-Agenten](https://developers.anpheros.com/de/guides/mcp)
- [KI-Anwendungen im Gesundheitswesen](https://developers.anpheros.com/de/guides/ai-healthcare)
- [LLM-Anwendungen und Gesundheitsdaten](https://developers.anpheros.com/de/guides/llm-healthcare-data)
- [Wie man einen medizinischen Chatbot mit strukturierten Daten erstellt](https://developers.anpheros.com/de/guides/ai-medical-assistant)
- [Einwilligungs- und Zugriffsmodell](https://developers.anpheros.com/de/guides/consent)
- [Authentifizierung und OAuth](https://developers.anpheros.com/de/guides/authentication)
- [Medikationsdaten für Gesundheits-Apps und KI-Agenten](https://developers.anpheros.com/de/guides/medication-data-ai-agents): die Patientenliste im Vergleich zu Arzneimittel-Wissensquellen