# Wie Anpheros im Vergleich zu anderen FHIR-Servern abschneidet

> Selbst gehostete FHIR-Server, Cloud-FHIR-Speicher, Open-Source-Gesundheitsplattformen und Anpheros im Vergleich: Wer den Zugriff autorisiert, Zustimmung, Herkunft, Wohnort, Preise und wann die jeweilige Option die richtige Wahl ist.

Source: https://developers.anpheros.com/de/guides/fhir-server-comparison

**Teams, die ein FHIR-Backend wählen, wägen normalerweise vier Arten von Optionen ab: einen Open-Source-Server, den sie selbst hosten, einen verwalteten FHIR-Speicher von einem Cloud-Anbieter, eine Open-Source-Gesundheitsplattform mit einer gehosteten Edition oder eine verwaltete Gesundheitsdatenbank wie Anpheros.** Dieser Leitfaden beschreibt, wofür jede Art gut geeignet ist und wo Anpheros positioniert ist, basierend auf der öffentlichen Dokumentation vom Oktober 2026. Überprüfen Sie für jedes hier genannte Produkt dessen eigene Dokumentation; Funktionen ändern sich.

## Die vier Arten

| | Self-hosted FHIR-Server (z.B. HAPI FHIR) | Cloud FHIR-Speicher (z.B. Google Cloud Healthcare API, Azure Health Data Services, AWS HealthLake) | Gesundheitsplattform (z.B. Medplum) | Anpheros |
|---|---|---|---|---|
| Was es ist | Ein FHIR-Server, den Sie betreiben | Ein FHIR-Datenspeicher innerhalb eines Cloud-Kontos | Eine FHIR-native Anwendungsplattform mit Authentifizierung, Workflows und einer gehosteten Edition | Eine verwaltete Gesundheitsdatenbank: FHIR R4 Datensatz pro Patient, Zustimmung, API, Audit |
| Wer den Zugriff autorisiert | Was auch immer Sie darum herum aufbauen | Das IAM der Cloud, pro Projekt oder Datensatz | Die Zugriffspolicies der Plattform, von Ihnen konfiguriert | Der Patient (OAuth 2.1 Zustimmung) oder die Organisation (API-Schlüssel) |
| Patientenseitige Zustimmung und Audit | Nein | Nein | Aufbau mit dem Policy-Modell möglich | Integriert, für den Patienten sichtbar |
| Provenienz bei jedem Schreibvorgang | Wenn Sie es hinzufügen | Wenn Sie es hinzufügen | Unterstützt durch FHIR; Sie erzwingen es | Erforderlich und automatisch |
| Identifikator-Isolation zwischen Anwendungen | Nein | Nein | Nein | Paarweise IDs pro Anwendung |
| Laborimport (HL7 v2) | Separate Tools | Teilweise (v2 zu FHIR-Mapping in einigen Speichern) | Von Ihnen geschriebene Integrationen | Integriert, eine Anfrage |
| Datenresidenz | Wo auch immer Sie es hosten | Die vom Anbieter angebotenen Regionen | Abhängig vom Hosting | Nur Europäische Union |
| Preisgestaltung | Ihre Infrastruktur und Zeit | Nutzungsbasiert (Anfragen, Speicher) | Pro Plan oder Self-hosted | Pro Organisation, nach gespeicherten Patienten |
| Am besten geeignet für | Lernen, volle Kontrolle, ungewöhnliche Datenmodelle | Teams, die sich bereits in dieser Cloud befinden und die Gesundheitsschicht selbst aufbauen werden | Teams, die auf einer Open-Source-Codebasis aufbauen und den gesamten Stack besitzen möchten | Teams, die die Gesundheitsschicht erledigt haben möchten und das Produkt als ihre Arbeit |

## Google Cloud Healthcare API oder eine verwaltete Plattform?

Googles Produkt heißt buchstäblich Cloud Healthcare API und erscheint daher bei vielen Suchen nach "Healthcare API" zuerst. Es ist ein Cloud FHIR-Speicher (plus HL7 v2 und DICOM-Speicher) innerhalb Ihres Google Cloud-Projekts: Speicher, FHIR-Suche und IAM-basierter Zugriff, abgerechnet nach Nutzung. Den Rest bauen Sie selbst – patientenorientierte Zustimmung und Auditierung, Anwendungsisolierung, Laborimporte, SDKs und eine Sandbox mit Testdaten. Anpheros stellt diese Teile bereit und speichert Daten in der EU; es bietet Ihnen keinen FHIR-Speicher innerhalb Ihres eigenen Cloud-Kontos. Wählen Sie danach, wer die Healthcare-Schicht besitzen soll: Ihr Team (Cloud Healthcare API) oder die Plattform (Anpheros).

## Open-Source FHIR-Server oder Managed?

Open-Source-Server wie HAPI FHIR laufen überall (Docker-Images sind verfügbar) und unterstützen die vollständige FHIR-Spezifikation mit eigenen Profilen und Erweiterungen. Der Betrieb eines solchen Servers in der Produktion bedeutet, dass Sie die Datenbank, Upgrades, Sicherheit, Backups und die Zugriffsschicht selbst verwalten. Eine Managed Platform tauscht einen Teil dieser Freiheit (Anpheros speichert 26 Ressourcentypen) gegen den Verzicht auf den eigenen Betrieb. Sehen Sie sich das [FHIR-Datenbankschema](https://developers.anpheros.com/de/guides/fhir-database-schema) an, um zu erfahren, was ein solcher Server intern speichert.

## Wann Anpheros die richtige Wahl ist

- Sie entwickeln ein Produkt für Patienten, Kliniken, Labore oder KI und möchten das Produkt schreiben, nicht die Akte.
- Patienteneinwilligung und ein Audit, das der Patient lesen kann, sind Anforderungen und keine "nice-to-haves" (DSGVO Artikel 9, EHDS).
- Ihre Daten müssen in der Europäischen Union verbleiben.
- Sie wünschen sich FHIR R4, aber auch eine einfachere REST-Ansicht, SDKs und Webhooks von einem einzigen Anbieter.
- Sie möchten kostenlos in einer Sandbox mit realistischen synthetischen Patienten starten und ohne Neuentwicklung in die Produktion übergehen.

## Wo eine andere Option besser ist

- Sie benötigen FHIR-Ressourcentypen, -Profile oder -Erweiterungen, die nicht zu den 26 gehören, die Anpheros unterstützt, oder ein vollständig benutzerdefiniertes Datenmodell: Ein selbst gehosteter Server bietet Ihnen diese Freiheit.
- Ihre Organisation verlangt aus Compliance-Gründen, dass alles innerhalb eines Cloud-Kontos liegt: Ein Cloud-FHIR-Store passt zu dieser Richtlinie.
- Sie möchten den gesamten Stack besitzen und modifizieren, einschließlich des Autorisierungsservers und der UI-Komponenten: Eine Open-Source-Plattform ist dafür konzipiert.
- Sie benötigen heute EHR-Launch, Bulk Data Export oder `system/` Scopes: Anpheros bietet diese noch nicht an (siehe [How to implement patient consent with SMART on FHIR](https://developers.anpheros.com/de/guides/smart-on-fhir-backend)).

## Ein fairer Weg zur Entscheidung

Zählen Sie die Teile der Healthcare-Schicht, die Ihr Produkt benötigt: Zustimmung, Herkunft, Audit, Identifikatoren, Laborexport, Dokumentenspeicherung, Wohnsitz, und schätzen Sie die Monate für die Entwicklung und Wartung jedes einzelnen Teils für die von Ihnen bevorzugte Option. Vergleichen Sie dies dann mit der Produktarbeit, in die diese Monate hätten fließen können. Anpheros ist die richtige Antwort, wenn die zweite Zahl größer ist.

## Verwandte Themen

- [Healthcare API-Plattform: Was sie beinhaltet und wie man sie auswählt](https://developers.anpheros.com/de/guides/healthcare-api-platform): Die Fragen, die Sie einem Anbieter stellen sollten
- [FHIR vs. eine benutzerdefinierte medizinische Datenbank](https://developers.anpheros.com/de/guides/fhir-vs-custom-database): Wann Sie Ihre eigenen Tabellen entwerfen sollten und wann Sie FHIR verwenden sollten
- [Kostenlose FHIR-Datenbank und Sandbox](https://developers.anpheros.com/de/guides/free-fhir-database)
- [FHIR-Plattform](https://developers.anpheros.com/de/guides/fhir)
- [Backend und Datenbank für medizinische Apps](https://developers.anpheros.com/de/guides/medical-app-backend)
- [Startups im Gesundheitswesen](https://developers.anpheros.com/de/guides/healthcare-startups)
- [Sicherheit, Datenschutz und Datenresidenz](https://developers.anpheros.com/de/guides/security)