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

FHIR vs. eine benutzerdefinierte medizinische Datenbank

Eigene Tabellen oder HL7 FHIR R4 für medizinische Daten: das gleiche Lesen auf beiden Wegen gespeichert, die Kompromisse nebeneinander, wann jede richtig ist, und die übliche Trennung zwischen Ihrer Datenbank und der FHIR-Akte.

Ein Team, das ein Gesundheitsprodukt startet, steht in der Regel früh vor der gleichen Wahl: Entwerfen Sie eigene Tabellen für Patienten, Messungen und Diagnosen in PostgreSQL oder einer anderen Datenbank, oder speichern Sie medizinische Daten von Anfang an als HL7 FHIR R4-Ressourcen. Ein benutzerdefiniertes Schema ist am ersten Tag schneller und passt genau zu Ihrem Produkt. FHIR kostet anfangs mehr Überlegungen und zahlt sich jedes Mal aus, wenn die Daten Ihr System verlassen müssen, geprüft werden müssen, mit Zustimmung geteilt werden müssen oder von jemandem gelesen werden müssen, der nicht Sie sind. Diese Seite stellt die Kompromisse ehrlich dar, mit derselben Lesung, die auf beide Arten gespeichert ist, und sagt, wann jede Wahl richtig ist.

Dies ist eine andere Frage als welchen FHIR-Server Sie verwenden. Dazu siehe Wie Anpheros im Vergleich zu anderen FHIR-Servern abschneidet.

Dieselbe Messung, zwei Wege

Eine Blutdruckmessung in einem benutzerdefinierten Schema:

CREATE TABLE bp_readings (
  id          uuid PRIMARY KEY,
  user_id     uuid REFERENCES users(id),
  systolic    int,
  diastolic   int,
  measured_at timestamptz,
  created_at  timestamptz DEFAULT now()
);

Einfach, schnell abzufragen, genau das, was die App benötigt. Dann kommen die Fragen, die die Tabelle nicht beantwortet:

Welches Gerät oder welche Person hat den Wert erzeugt? Wurde er vom Patienten eingegeben, mit einer Manschette gemessen oder von einer Krankenschwester erfasst?
Was war der Wert, bevor jemand ihn korrigierte, und wer hat ihn korrigiert?
Wie liest ein Kliniksystem, ein Labor oder ein Versicherer ihn? Was bedeutet systolic in deren System?
Wie teilt der Patient ihn mit der App seines Arztes und wie beendet er die Freigabe nächsten Monat?
Wenn Sie Herzfrequenz, Gewicht, HbA1c und 200 weitere Messungen hinzufügen, sind das dann 200 Tabellen oder eine generische Tabelle, die Sie selbst entwerfen?

Dieselbe Messung als FHIR R4:

{"resourceType": "Observation", "status": "final",
 "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs"}]}],
 "code": {"coding": [{"system": "http://loinc.org", "code": "85354-9", "display": "Blood pressure panel"}]},
 "subject": {"reference": "Patient/d09e3942-…"}, "effectiveDateTime": "2026-10-10T08:30:00Z",
 "component": [
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}, "valueQuantity": {"value": 138, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}},
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}, "valueQuantity": {"value": 88, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}}],
 "meta": {"versionId": "1"}}

Ausführlicher, aber jeder Teil hat eine Bedeutung, die jedes FHIR-System teilt: LOINC gibt an, was gemessen wurde, UCUM die Einheit, meta.versionId startet eine Historie, und die gleiche Observation-Struktur enthält die anderen 200 Messungen. Mit Anpheros zeichnet eine Provenance-Ressource auch auf, wer sie geschrieben hat. Speichern von medizinischen Aufzeichnungen mit FHIR R4 führt Sie durch den Prozess.

Nebeneinander

	Benutzerdefiniertes Schema	FHIR R4
Zeit bis zum ersten Feature	Stunden	ein bis zwei Tage, um die Ressourcen zu lernen
Passform für Ihr Produkt	exakt	allgemein; die Ansicht Ihres Produkts sitzt obenauf
Hinzufügen einer neuen Datenart	eine Migration pro Art	normalerweise ein neuer Code in einer bestehenden Ressource
Bedeutung außerhalb Ihres Systems	keine ohne Mapping	geteilte Codes (LOINC, ICD-10, ATC, UCUM)
Historie und Korrekturen	Sie entwerfen es	Versionen und `_history` by design
Wer hat was geschrieben	Sie entwerfen es	`Provenance` (automatisch in Anpheros)
Austausch mit Kliniken, Laboren, anderen Apps	benutzerdefinierte Integration jedes Mal	FHIR R4 API, HL7 v2 Import, International Patient Summary
Patienteneinwilligung pro Anwendung	Sie entwerfen es	SMART on FHIR Scopes und OAuth
Abfragen für Analysen	Plain SQL	FHIR-Suche oder Export in Ihr Warehouse
Regulierung (DSGVO Artikel 9, EHDS)	Sie dokumentieren jeden Teil	Standardformate, auf die sich die Regulierung bezieht

Wann ein benutzerdefiniertes Schema die richtige Wahl ist

Die Daten sind nicht wirklich medizinisch oder nicht über eine Person. Trainingspläne, Inhalte, ein Produktkatalog: Verwenden Sie Ihre eigenen Tabellen.
Ein kurzlebiger Prototyp, um zu testen, ob jemand das Produkt wünscht, mit synthetischen Daten und einem Plan für die Migration.
Daten, die von keinem Standardmodell gut abgedeckt werden, z. B. eine neuartige Forschungsmessung. FHIR kann sie immer noch übertragen (Observation mit Ihrem eigenen Codesystem oder Basic), aber eine benutzerdefinierte Tabelle ist möglicherweise klarer.
Umfangreiche Analysen. Selbst wenn FHIR das System of Record ist, kopieren die meisten Teams Daten in ein Warehouse in ihrer eigenen Form für die Berichterstattung.

Wann FHIR die richtige Wahl ist

Die Daten sind die Gesundheitsakte einer Person: Messungen, Diagnosen, Medikationen, Allergien, Laborergebnisse, Dokumente.
Sie werden Ihr System jemals verlassen: zum Patienten, einem Arzt, einer Klinik, einem Labor, einem Versicherer, einem KI-Modell oder einem Wettbewerber, wenn der Patient umzieht.
Sie müssen anzeigen, wer was geschrieben hat und was sich geändert hat: Audits, klinische Sicherheit, Streitigkeiten.
Patienten werden den Zugriff pro Anwendung gewähren und widerrufen.
Sie verkaufen in der Europäischen Union, wo der Europäische Gesundheitsdatenraum den Austausch von Akten in Standardformaten erwartet.

Der übliche Mittelweg

Die meisten Produkte enden mit beidem, aufgeteilt nach Art der Daten:

your database                         FHIR record (Anpheros)
─────────────                         ──────────────────────
users, sessions, settings             Patient
subscriptions, billing                Observation, Condition, MedicationStatement
product content, feature flags        AllergyIntolerance, Immunization, DocumentReference
user id → patient id (one column)     Provenance, Consent, history
caches and analytics copies  ◄─────── webhooks

Ihre Datenbank bleibt klein und produktförmig. Der medizinische Datensatz ist standardisiert, versioniert und teilbar, und Sie mussten ihn nicht selbst erstellen. Medical app backend and database beschreibt diese Aufteilung im Detail, und How to build a healthcare API with TypeScript baut sie auf.

Was es braucht, um FHIR selbst zu entwickeln

Die Wahl von FHIR bedeutet nicht, einen FHIR-Server selbst zu schreiben. Ihre Optionen sind ein Open-Source-Server, den Sie betreiben, der FHIR-Speicher eines Cloud-Anbieters, eine Open-Source-Gesundheitsplattform oder eine verwaltete Gesundheitsdatenbank wie Anpheros. Sie unterscheiden sich darin, wer die Zustimmung, Prüfung, Herkunft, Ansässigkeit und Integrationen verwaltet, was Wie Anpheros im Vergleich zu anderen FHIR-Servern abschneidet darlegt.

Häufig gestellte Fragen

Ist FHIR eine Datenbank?

Nein. FHIR ist ein Standard für die Struktur und den Austausch von Gesundheitsdaten: Ressourcen, Codes und eine REST API. Ein FHIR-Server oder eine verwaltete FHIR-Datenbank speichert die Ressourcen und implementiert die API auf einer echten Datenbank.

Kann ich FHIR-Ressourcen selbst in PostgreSQL speichern?

Ja, als JSON-Spalten mit eigenen Indizes, und einige Open-Source-Server tun genau das. Die Arbeit steckt in allem, was mit der Speicherung zu tun hat: Suchparameter, Versionierung, Referenzen, Validierung, Zugriffskontrolle pro Patient und Provenienz.

Kann ich mit einem benutzerdefinierten Schema beginnen und später zu FHIR wechseln?

Das können Sie, und viele Teams tun das auch, aber die Migration ist ein Mapping-Projekt: Jede Tabelle benötigt Codes, Einheiten und Autoren, die sie nie erfasst hat. Medizinische Daten von Anfang an als FHIR zu speichern, kostet weniger als die spätere Konvertierung.

Benötige ich FHIR, um die DSGVO einzuhalten?

Nein. Die DSGVO schreibt kein bestimmtes Format vor. FHIR erleichtert die Erfüllung mehrerer Verpflichtungen: Portabilität (der Datensatz wird in einem Standardformat exportiert), Zugriffskontrolle pro Zweck und die Anzeige, wer welche Daten verarbeitet hat.