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

Architektur von Gesundheitsanwendungen

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

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 und ein zustimmungsfähiger Agent in KI-Agenten und medizinische Daten. Details: KI-Agenten und medizinische Daten, LLM-Anwendungen und Gesundheitsdaten.

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