AnpherosAnpheros PlatformDevelopers

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

KI-Agenten und medizinische Daten

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

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

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)
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):

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:

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

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

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

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

Product updates by email

New features, guides and the end of the beta. One email a month at most.

Send me occasional Anpheros Platform updates by email (new features, API changes, guides). I'll confirm by email and can unsubscribe in one click from any email. Privacy