# Architektur von Gesundheitsanwendungen

> Diagramme und Datenflüsse: Patient zu Anwendung zu Anpheros API zum FHIR-Datensatz und externen Diensten, und KI-Agent zur Kontext-API zu autorisierten Daten.

Source: https://developers.anpheros.com/de/guides/architecture

Anpheros ist die medizinische Datenebene zwischen Ihrer Anwendung (oder Ihrem KI-Agenten) und dem Patientenakt. Ihre Anwendung behält ihre eigene Benutzeroberfläche und Geschäftslogik bei; der medizinische Datensatz, die Zustimmung, die Herkunft und die Überprüfung leben in Anpheros und sind über eine API erreichbar.

```
  Your application, backend or AI agent
  (mobile app, web app, clinic system, lab system, LLM-based assistant)
                        │  HTTPS · API key (sk_test_ / sk_live_) or OAuth token (at_…)
                        ▼
  Anpheros Platform API
  ├─ /v1        simplified REST: patients, observations, conditions, medications,
  │             documents, timeline, provenance, context, labs, webhooks
  ├─ /fhir/R4   strict FHIR R4: 26 resource types, search, history, transactions,
  │             $everything, $summary (IPS), $validate
  └─ /oauth     OAuth 2.1 + PKCE, SMART on FHIR, OpenID Connect
                        │  every request: project isolation · scopes · rate limits
                        ▼
  One FHIR R4 record per patient
  ├─ versions of every resource (history)   ├─ Provenance for every write
  ├─ Consent resources for every grant      └─ access log visible to the patient
                        │
                        ▼
  Events out: signed webhooks to your server (ids only, never clinical content)
```

## Die Sicht des Patienten: Von der Person zu externen Diensten

```
Patient
   ↓   uses an app, chooses what to share, sees every access
Healthcare application          Anpheros Daily, or your own app
   ↓   REST v1 / FHIR R4 over HTTPS, API key or OAuth token
Anpheros API
   ↓   isolation, scopes, idempotency, provenance
FHIR medical data               the patient's record: 26 resource types, every version kept
   ↓   only what the patient allowed, only for as long as allowed
External healthcare services    laboratories (lab import), clinics (directory, acting-as),
                                other apps (OAuth / SMART), your backend (webhooks)
```

## Die KI-Ansicht: Vom Agenten zu autorisierten Daten

```
AI agent or LLM application     runs the model you choose — hosted or local
   ↓   POST /v1/context  {patient, task, question, budget_tokens}
Medical context API             plans which parts of the record matter, fits them into the budget,
   ↓                            labels every item with author type and source, records a manifest
Authorised medical data         only records the project created or the patient granted;
                                the read appears in the patient's access log
```

Das Modell erhält niemals Anmeldeinformationen und ruft Anpheros niemals selbst auf; Ihre Anwendung fordert den Kontext an und entscheidet, was an das Modell gesendet wird. Zwei vollständige Beispiele mit den API-Aufrufen: eine KI-Gesundheitsanwendung in [KI-Gesundheitsanwendungen](https://developers.anpheros.com/de/guides/ai-healthcare) und ein zustimmungsfähiger Agent in [KI-Agenten und medizinische Daten](https://developers.anpheros.com/de/guides/ai-agents-medical-data). Details: [KI-Agenten und medizinische Daten](https://developers.anpheros.com/de/guides/ai-agents-medical-data), [LLM-Anwendungen und Gesundheitsdaten](https://developers.anpheros.com/de/guides/llm-healthcare-data).

## Der Datensatz

Jeder Patient hat einen Datensatz, der aus FHIR R4-Ressourcen besteht: `Observation` für Vitalparameter, Laborergebnisse, Symptome und tägliche Aktivitätszusammenfassungen, `Condition` und `EpisodeOfCare`, `MedicationStatement` und `MedicationAdministration`, `DocumentReference`, `Immunization`, `AllergyIntolerance` und andere – insgesamt 26 Typen, die live in der CapabilityStatement (`GET /fhir/R4/metadata`) aufgeführt sind. Es gibt kein proprietäres Schema zu lernen: die REST API ist eine vereinfachte Ansicht derselben Ressourcen mit denselben IDs.

Nichts wird stillschweigend überschrieben. Jedes Update erstellt eine neue Version (`/fhir/R4/{type}/{id}/_history`), und jede Version zeichnet das Projekt auf, das sie geschrieben hat, und die Organisation, in deren Namen sie geschrieben wurde.

## Zwei Wege zum Zugriff

| | API-Schlüssel | OAuth-Zugriffstoken |
|---|---|---|
| Sieht aus wie | `sk_test_…` / `sk_live_…` | `at_…` |
| Verwendet von | Ihrem Server | einer Anwendung, die für einen Patienten handelt |
| Sieht | die von Ihrem Projekt erstellten Patienten | genau einen Patienten, innerhalb der vom Patienten gewährten Scopes |
| Typische Verwendung | das Backend Ihrer eigenen App, ein Laborsystem, eine Klinikintegration | eine Drittanbieter-App oder ein KI-Assistent, der auf einen Datensatz zugreift, den der Patient bereits besitzt |

Ein Projekt sieht niemals die Patienten eines anderen Projekts, es sei denn, der Patient gewährt Zugriff. Jedes Projekt erhält seine eigene Kennung für dieselbe Person (pairwise ids), sodass IDs nicht über Anwendungen hinweg korreliert werden können, und ein Datensatz außerhalb Ihres Zugriffs antwortet mit `404`, niemals mit `403`.

## Zwei Umgebungen

Die Sandbox und die Produktion sind getrennte Datenbanken. Ein Sandbox-Schlüssel (`sk_test_`) kann physisch keine echten Patienten erreichen; jedes Sandbox-Projekt erhält seine eigene Kopie von 30 synthetischen Patienten, die es frei ändern und zurücksetzen kann. Produktionsschlüssel (`sk_live_`) werden an verifizierte Organisationen ausgegeben.

## Datenflüsse

**Ihre App schreibt.** `POST /v1/patients/{id}/observations` mit einer `Idempotency-Key`. Die Plattform speichert eine FHIR `Observation`, schreibt einen `Provenance` (Autor-Typ: patient, practitioner, device, import oder ai), protokolliert den Zugriff und sendet einen `resource.created` Webhook an abonnierte Endpunkte.

**Eine andere Anwendung liest mit Zustimmung.** Der Patient genehmigt dies auf der gehosteten Zustimmungsseite (`/oauth/authorize`) und wählt den Datensatz und die Dauer (30–365 Tage). Die Anwendung tauscht den Code gegen Tokens und liest nur, was die Scopes erlauben. Der Patient sieht die Anwendung, ihre Scopes und jeden Lesevorgang in seinem Zugriffslog und kann diese jederzeit widerrufen.

**Ein Labor liefert Ergebnisse.** `POST /v1/patients/{id}/labs/import` mit einem CSV-, HL7 v2 ORU^R01- oder JSON-Bericht; jedes Ergebnis wird zu einem Labor-`Observation` mit LOINC-Codes, wo bekannt, und das erneute Senden desselben Berichts ist sicher.

**Ein KI-Modell benötigt Kontext.** `POST /v1/context` gibt die Teile des Datensatzes zurück, die für eine Aufgabe relevant sind, innerhalb eines Token-Budgets, wobei jedes Element mit seiner Quelle gekennzeichnet ist; der Aufruf wird mit einer Manifest-ID aufgezeichnet. Das Modell selbst läuft, wo immer Sie es wählen.

## Wo Anpheros im Vergleich zum Selbstbau passt

| Anliegen | Selbstbau | Mit Anpheros |
|---|---|---|
| Medizinische Datenmodelle | Tabellen für jede Art von Datensatz entwerfen | FHIR R4 Ressourcen, 26 Typen |
| Interoperabilität | benutzerdefinierte Exportformate | FHIR R4, International Patient Summary, SMART on FHIR |
| Zustimmung | Logik für Gewährung, Umfang, Ablauf und Widerruf erstellen | OAuth 2.1 Grants als FHIR `Consent` gespiegelt |
| Audit | Protokollierung erstellen und eine Möglichkeit, diese Patienten anzuzeigen | Jedes Lesen und Schreiben wird protokolliert und ist für den Patienten sichtbar |
| Laborintegration | Format jedes Labors parsen | CSV, HL7 v2 ORU und JSON Import |
| KI-Kontext | Retrieval- und Zusammenfassungscode schreiben | Kontext-API mit Token-Budget und Provenienz-Labels |

## Verwandte Themen

- [Was ist Anpheros?](https://developers.anpheros.com/de/guides/what-is-anpheros)
- [Entwicklung von Gesundheitssoftware](https://developers.anpheros.com/de/guides/healthcare-software)
- [Backend und Datenbank für medizinische Apps](https://developers.anpheros.com/de/guides/medical-app-backend)
- [Eine Gesundheits-App erstellen](https://developers.anpheros.com/de/guides/build-a-healthcare-app)
- [Einwilligungs- und Zugriffsmodell](https://developers.anpheros.com/de/guides/consent)
- [Sicherheit, Datenschutz und Datenresidenz](https://developers.anpheros.com/de/guides/security)