FHIR-Plattform als Backend: Was Ihnen ein FHIR-Backend als Service bietet und was nicht

Ein FHIR-Server speichert und liefert FHIR-Ressourcen. Eine FHIR-Plattform ist das, was Sie tatsächlich benötigen, um ein Gesundheitsprodukt zu liefern: den Server plus Identität, Zustimmung, Herkunft, Isolierung zwischen Kunden, Webhooks, Dokumente, Terminologie und jemanden, der ihn unter DSGVO betreibt. Diese Anleitung erläutert den Unterschied und beschreibt, wie die Anpheros Platform jede Lücke füllt, damit Sie entscheiden können, ob Sie darauf aufbauen oder Ihren eigenen betreiben möchten.

Technische Version für Entwickler: Healthcare API Platform · FHIR Server Vergleich auf developers.anpheros.com, mit Anfragen, Antworten und Limits. Diese Seite ist die Version in einfacher Sprache.

Server versus Plattform

Open-Source-FHIR-Server (z. B. HAPI) sind hervorragend für den FHIR-Teil: Ressourcen, Suche, Validierung, Verlauf. Was sie Ihnen überlassen, ist alles drumherum:

Wenn Sie ein Ops-Team, einen Compliance-Beauftragten und sechs Monate Zeit haben, ist der Betrieb Ihres eigenen Servers eine gute Wahl. Wenn Sie ein Produkt zu liefern haben, ist eine Plattform schneller.

Wie die Anpheros Platform aufgebaut ist

Ein FHIR R4-Datensatz pro Patient. 26 Ressourcentypen, kodiert mit LOINC, ICD-10 und ATC, validiert beim Schreiben. Die strikte FHIR-API befindet sich unter /fhir/R4, mit einer CapabilityStatement unter /fhir/R4/metadata, und eine einfache REST-API unter /v1 liefert dieselben Daten mit denselben IDs.

Projektisolierung und paarweise IDs. Ein Projekt (ein API-Schlüssel) sieht nur die von ihm erstellten Patienten. Jedes Projekt erhält eine eigene ID für dieselbe Person; interne IDs verlassen die Plattform nie. Verweise auf Patienten außerhalb Ihres Geltungsbereichs werden mit einem undurchsichtigen, projektspezifischen Token maskiert.

Zustimmung entscheidet über Lesezugriff, Eigentum entscheidet über Schreibzugriff. Mit der Zustimmung des Patienten sieht eine Organisation den gesamten Datensatz, einschließlich dessen, was andere Kliniken geschrieben haben, kann aber nur ändern oder löschen, was sie selbst geschrieben hat. Jede Version jeder Ressource zeichnet das Projekt auf, das sie geschrieben hat; ein Schreibvorgang durch ein anderes Projekt wird mit einer Erklärung abgelehnt.

Herkunft und Audit bei jedem Schreibvorgang. Provenance.agent.onBehalfOf nennt die Klinik oder Organisation zum Zeitpunkt des Schreibens; eine Audit-Zeile zeichnet auf, wer, was, wann, unter welcher Berechtigung, von welcher Anwendung. Der Patient kann sein Zugriffsprotokoll lesen, auch als FHIR AuditEvent-Ressourcen.

Dünne, signierte Webhooks. Ereignisse enthalten IDs und Versionen, niemals klinische Inhalte; Sie lesen die Ressource über die API. Lieferungen werden mit HMAC-SHA256 signiert und bis zu 24 Stunden lang mit Backoff wiederholt.

Sandbox und Produktion sind getrennte Datenbanken. Ein sk_test_-Schlüssel kann keinen echten Patienten erreichen. Die Sandbox ist kostenlos und selbstbedienbar.

EU-Residenz. Cloud Run in europe-west4, mit einem Auftragsverarbeitungsvertrag für Produktionsorganisationen.

Was bewusst nicht vorhanden ist

• Keine klinische Entscheidungsunterstützung. Die Plattform speichert, kodiert und teilt; sie diagnostiziert oder empfiehlt keine Behandlung.
• Keine Krankenhaus-fähige Medikamentendatenbank mit Wechselwirkungen. Medikamente werden mit ATC kodiert, und ein gebündelter ATC- und LOINC-Teil ist für die Abfrage verfügbar, aber die Wechselwirkungsprüfung ist Ihre Komponente oder ein lizenzierter Dienst.
• Kein Krankenhaus-fähiger HL7 v2 Messaging-Bus. Es gibt einen HL7 v2 ORU^R01-Import für Laborberichte; es gibt keine ADT- oder Auftragsverwaltung.

Das Wissen um diese Grenzen im Voraus spart eine Woche Entdeckungszeit.

Wann Sie stattdessen Ihren eigenen Server betreiben sollten

• Sie müssen innerhalb Ihres eigenen Krankenhausnetzwerks hosten, ohne externen Prozessor.
• Sie benötigen FHIR R5 oder Profile, die die Plattform nicht implementiert.
• Ihr Produkt ist der FHIR-Server selbst.

In allen anderen Fällen beginnen Sie in der Sandbox, messen Sie und entscheiden Sie mit Daten. Die erste Stunde wird unter developers.anpheros.com/guides/first-hour beschrieben; die vollständige API-Referenz finden Sie unter platform.anpheros.com/docs.

Häufige Fragen

Ist Anpheros ein FHIR-Server?

Es enthält einen: eine FHIR R4-API mit 26 Ressourcentypen, Suche, Verlauf, $everything, $summary, $validate und Terminologieoperationen. Drumherum sind Zustimmung, Herkunft, Isolierung, Webhooks und Hosting, was es zu einer Plattform macht.

Welche FHIR-Version?

FHIR R4 (4.0.1), die Version, die von der EU- und US-Regulierung gefordert und von den meisten Systemen implementiert wird. Die Konformität wurde mit Inferno überprüft; siehe die IPS-Konformitätsnotizen.

Können mehrere Kliniken den Datensatz eines Patienten teilen?

Ja, das ist der Sinn der Sache. Mit der Zustimmung des Patienten liest jede Klinik den gesamten Datensatz und schreibt ihre eigenen Ressourcen, die jeweils mit ihrer Herkunft gekennzeichnet sind. Keine Klinik kann ändern, was eine andere geschrieben hat.

Gibt es ein kostenloses FHIR-Backend für die Entwicklung?

Ja. Die Sandbox ist kostenlos, selbstbedienbar und enthält 30 synthetische Patienten pro Projekt. Siehe Kostenloser FHIR-Server: die Sandbox.

Wie migriere ich weg, wenn ich muss?

Alles ist FHIR R4 und exportierbar: Patient/{id}/$everything gibt den gesamten Datensatz eines Patienten als Bundle zurück. Es gibt kein proprietäres Format, das entwirrt werden müsste.