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

Gesundheitsintegrationen

Derzeit unterstützte Integrationsmuster: Laborberichte in einem Aufruf, Kliniken schreiben im Namen einer Organisation, Geräte, zugestimmte Drittanbieter-Apps, Webhooks und SDKs – und was nicht verfügbar ist.

Eine Gesundheitsintegration verbindet ein System, das Gesundheitsdaten produziert oder benötigt – ein Labor, eine Klinik, ein Gerät, eine andere Anwendung – mit der Patientenakte. Mit Anpheros durchläuft jede Integration dieselbe API und dieselben Regeln: Daten werden als HL7 FHIR R4 geschrieben, ihrer Quelle zugeordnet, für den Patienten sichtbar und nur mit Zustimmung des Patienten an Dritte weitergegeben. Diese Seite beschreibt die Integrationsmuster, die die Plattform heute unterstützt.

Erkunden Sie das Anpheros Integrationsverzeichnis, um jede Integration mit ihrem verifizierten Status (verfügbar, Beta oder Entwicklerhandbuch), den ausgetauschten Daten und FHIR-Ressourcen, ihrer Richtung, Authentifizierung und Dokumentation einzusehen.

Laboratorien: vollständige Berichte in einem Aufruf

Ein Labor oder jedes System, das Laborberichte enthält, sendet einen vollständigen Bericht und die Plattform wandelt jedes Ergebnis in ein Labor Observation um:

curl -X POST https://platform.anpheros.com/v1/patients/$PID/labs/import \
     -H "Authorization: Bearer $KEY" -H "Content-Type: text/csv" \
     -H "X-Anpheros-Source-System: labx" -H "Idempotency-Key: report-2026-0917-77" \
     --data-binary @report.csv

Formate: CSV (rumänische oder englische Kopfzeilen, Dezimalkomma akzeptiert), HL7 v2 ORU^R01 und JSON.
Marker werden LOINC zugeordnet, wenn der Bericht einen Code angibt oder der Name mit der Terminologie der Plattform übereinstimmt; andere behalten den eigenen Code des Labors und werden als unmapped aufgeführt.
Jede Zeile erhält eine stabile Kennung, sodass das erneute Senden desselben Berichts bereits importierte Daten überspringt.
Bis zu 500 Zeilen pro Anfrage; jedes Ergebnis trägt Herkunftsinformationen, die das Quellsystem und den Bericht benennen.

Details: Lab Connector.

Kliniken: Schreiben im Namen einer Organisation

Kliniken und die dort arbeitenden Personen sind Verzeichnisressourcen (Organization, Practitioner, PractitionerRole). Das System einer Klinik kann dann angeben, wer hinter jeder Anfrage steckt:

X-Anpheros-Acting-As: PractitionerRole/<id> — der Praktiker, der über Ihre Anwendung arbeitet; wird im Zugriffsprotokoll vermerkt und dem Patienten namentlich angezeigt;
X-Anpheros-On-Behalf-Of: Organization/<id> — die Organisation, für die eine Schreiboperation durchgeführt wird;
X-Anpheros-Author-Ref: Practitioner/<id> — der Autor, der in Provenance erfasst ist.

Mit Zustimmung des Patienten liest die Klinik den gesamten Datensatz, einschließlich dessen, was andere Organisationen geschrieben haben, und ändert nur das, was sie selbst geschrieben hat. Mehrere Ressourcen können atomar mit einem FHIR transaction Bundle geschrieben werden (POST /fhir/R4).

Ein funktionierendes Beispiel, vom Verzeichnis bis zu einem Besuch, der als eine Transaktion geschrieben wird: How to integrate clinic systems with a FHIR backend.

Der Ablauf Zustimmung → Labor Observation, geschrieben von einem Klinikprojekt → Benachrichtigung in der Patienten-App wurde mit einem Test-Klinikprojekt Ende-zu-Ende umgesetzt.

Geräte und Wearables

Messungen von Geräten sind Observations mit author_type: "device" und einem LOINC-Code – Herzfrequenz, Blutdruck, SpO₂, Gewicht, Glukose, Schritte, Schlafdauer und andere (FHIR code systems). Anpheros Daily schreibt die täglichen Zusammenfassungen, die es aus Apple Health und Health Connect liest, auf die gleiche Weise als Observations. Anpheros verbindet sich nicht direkt mit den Clouds der Gerätehersteller; Ihre Anwendung oder Ihr Backend liest die Gerätedaten und schreibt das Ergebnis. Wie Sie Apple Health, Health Connect und Samsung Health lesen und jede Metrik LOINC zuordnen: Wearable data in FHIR.

Drittanbieteranwendungen: Zugestimmter Zugriff

Eine Anwendung, die Daten benötigt, die eine Person bereits in Anpheros gespeichert hat, registriert sich einmal und fordert die Zustimmung über OAuth 2.1 mit PKCE (SMART on FHIR Standalone Launch) an:

GET /oauth/authorize?...&scope=patient/Observation.rs?category=laboratory offline_access – die gehostete Einwilligungs-Seite;
die Person wählt den Datensatz und die Dauer (30, 90, 180 oder 365 Tage);
POST /oauth/token tauscht den Code gegen ein Zugriffstoken (30 Minuten) und ein rotierendes Refresh-Token (30 Tage) aus;
die Anwendung sieht nur diesen Patienten, nur innerhalb ihrer Scopes, unter ihrer eigenen paarweisen ID.

Authentifizierung und OAuth

Events: Reagieren auf Änderungen

Anstatt zu pollen, registrieren Sie einen Webhook. Lieferungen werden mit HMAC-SHA256 signiert, mit Backoff bis zu 24 Stunden wiederholt und enthalten IDs, niemals klinische Inhalte. Wenn ein anderes Projekt in einen Datensatz schreibt, auf den Sie Zugriff haben, teilt Ihnen das Ereignis dies mit (data.external: true, mit der Quelle). Webhooks

SDKs

Die TypeScript (@anpheros/sdk) und Dart / Flutter (anpheros_sdk) SDKs implementieren alle oben genannten Funktionen – Laborexport (labs.importCsv, labs.importHl7, labs.importItems), OAuth mit PKCE, Webhook-Verwaltung und Signaturprüfung. SDKs

Was nicht verfügbar ist

Fertige Konnektoren zu spezifischen Krankenhaus-EHRs oder Laborinformationssystemen; Integrationen werden gegen die API erstellt.
SMART EHR-Start (Start innerhalb eines EHR); nur der eigenständige Start wird unterstützt.
Direkte Integrationen mit Geräteherstellern.