# FHIR im Vergleich zu einer benutzerdefinierten medizinischen Datenbank

> Eigene Tabellen oder HL7 FHIR R4 für medizinische Daten: dieselbe Lesung auf beide Arten gespeichert, die Kompromisse nebeneinander, wann jede richtig ist, und die übliche Trennung zwischen Ihrer Datenbank und dem FHIR-Datensatz.

Source: https://developers.anpheros.com/de/guides/fhir-vs-custom-database

**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](https://developers.anpheros.com/de/guides/fhir-server-comparison).

## Dieselbe Messung, zwei Wege

Eine Blutdruckmessung in einem benutzerdefinierten Schema:

```sql
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:

```json
{"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](https://developers.anpheros.com/de/guides/store-medical-records-fhir) 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](https://developers.anpheros.com/de/guides/medical-app-backend) beschreibt diese Aufteilung im Detail, und [How to build a healthcare API with TypeScript](https://developers.anpheros.com/de/guides/healthcare-api-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](https://developers.anpheros.com/de/guides/fhir-server-comparison) 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.

## Verwandte Themen

- [FHIR-Datenbankschema](https://developers.anpheros.com/de/guides/fhir-database-schema): Wie FHIR-Ressourcen gespeichert und indiziert werden
- [Speichern von medizinischen Akten mit FHIR R4](https://developers.anpheros.com/de/guides/store-medical-records-fhir)
- [FHIR-Plattform](https://developers.anpheros.com/de/guides/fhir)
- [Vergleich von Anpheros mit anderen FHIR-Servern](https://developers.anpheros.com/de/guides/fhir-server-comparison)
- [Backend und Datenbank für medizinische Apps](https://developers.anpheros.com/de/guides/medical-app-backend)
- [Healthcare API](https://developers.anpheros.com/de/guides/healthcare-api)