# FHIR-Datenbankschema

> Speicherung von FHIR-Ressourcen: normalisierte Tabellen vs. JSON mit Suchindizes vs. Graph, das PostgreSQL-Schema, das Anpheros verwendet (Ressourcen, Verlauf, typisierte Indizes, Projektionen) und die wichtigen Regeln.

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

**Eine FHIR-Datenbank speichert HL7 FHIR-Ressourcen, damit sie über die FHIR-API gelesen, durchsucht und versioniert werden können. Das gängigste Schema speichert jede Ressource als JSON und füllt separate Indextabellen für die Suchparameter, anstatt jedes Element über normalisierte relationale Tabellen zu verteilen.** Diese Seite erklärt die drei üblichen Designs, das Schema, das Anpheros in PostgreSQL verwendet, und wann Sie keines selbst erstellen sollten.

## Drei Wege zur Speicherung von FHIR

<!-- visual:schema-compare -->

FHIR-Ressourcen sind tief, optional und erweiterbar: Eine Observation allein hat Dutzende von Elementen, Wahltypen (`value[x]`), wiederholende Codierungen und Erweiterungen. Die Normalisierung in relationale Spalten bedeutet eine Migration, wann immer ein Profil ein Feld hinzufügt. Das Speichern der Ressource als JSON bewahrt alles Gültige unverändert; die Indextabellen machen sie durchsuchbar.

## Das Anpheros-Schema

<!-- visual:schema-stack -->

| Tabelle | Eine Zeile pro | Schlüsselspalten |
|---|---|---|
| `fhir_resources` | aktuelle Version einer Ressource | `resource_type`, `id`, `patient_id`, `version`, `json` (die vollständige Ressource), `last_updated`, `deleted`, sowie Provenance-Spalten |
| `fhir_history` | jede jemals geschriebene Version | `resource_type`, `id`, `version`, `json`, `last_updated` |
| `idx_token` | codierter oder Identifikator-Suchwert | system, code — für `code`, `category`, `identifier`, `status` |
| `idx_string` | Text-Suchwert | normalisierter Text — für Namen und Freitext |
| `idx_date` | Datums-Suchwert | Start und Ende des Bereichs — für `date`, `onset-date`, `birthdate` |
| `idx_reference` | Referenz-Suchwert | Zieltyp und ID — für `patient`, `subject`, `encounter` |
| `idx_quantity` | Mengen-Suchwert | Wert, System, Einheit — für `value-quantity` |
| `proj_observations`, `proj_conditions`, `proj_medications` | Ressource, abgeflacht | die Spalten, nach denen die einfache REST-API filtert |

Bei jedem Schreibvorgang validiert die Plattform die Ressource, schreibt die neue Version in `fhir_resources` und `fhir_history`, ersetzt ihre Indexzeilen und Projektionen und zeichnet Provenance auf. Eine Suche wie `Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01` wird zu Joins auf `idx_reference`, `idx_token` und `idx_date`; das Ergebnis gibt das gespeicherte JSON zurück, so wie es geschrieben wurde.

## Designregeln, die wichtig sind

- **Nur deklarierte Suchparameter indizieren** und unbekannte mit `400` ablehnen, anstatt sie stillschweigend zu ignorieren.
- **Niemals Updates direkt ohne Historie durchführen**: Korrekturen müssen das bisher Bekannte beibehalten.
- **Soft Delete**: Eine gelöschte Ressource verschwindet aus Lese- und Suchvorgängen, aber ihre Versionen bleiben für Auditzwecke erhalten.
- **Patienten-Compartment-Spalte**: Das Speichern von `patient_id` in jeder Ressource ermöglicht kostengünstig `$everything`, Zustimmungsfilter und isolierte Patientenverwaltung.
- **Vor dem Speichern validieren**: Ungültiges JSON im Speicher bricht später jeden Leser.

## Häufig gestellte Fragen

### Was ist die beste Datenbank für FHIR?
Die meisten produktiven FHIR-Server verwenden eine relationale Datenbank wie PostgreSQL, wobei die Ressource als JSON (JSONB) gespeichert und Suchparameter in separaten Tabellen indiziert werden. Dies kombiniert flexible Speicherung mit schneller, standardmäßiger Suche.

### Sollte ich FHIR-Ressourcen in relationale Tabellen normalisieren?
Normalerweise nicht für den primären Speicher. Normalisierte Tabellen eignen sich für die Berichterstattung; bewahren Sie sie als Projektionen auf, die aus den gespeicherten Ressourcen erstellt werden, so wie Anpheros es für seine einfachere REST API tut.

### Wie speichert HAPI FHIR Ressourcen?
Der JPA-Server von HAPI FHIR speichert jede Ressourcenversion ebenfalls als serialisiertes JSON und hält Suchparameter in separaten Indextabellen. Das Anpheros-Design folgt demselben Prinzip.

### Muss ich selbst eine FHIR-Datenbank erstellen?
Nur wenn Sie die volle Kontrolle über Profile und Ressourcentypen benötigen. Andernfalls bietet Ihnen eine verwaltete FHIR-Plattform Speicher, Suche, Verlauf, Zustimmung und Audit, ohne das Schema ausführen zu müssen.

<!-- visual:cta-schema -->

## Verwandte Themen

- [FHIR im Vergleich zu einer benutzerdefinierten medizinischen Datenbank](https://developers.anpheros.com/de/guides/fhir-vs-custom-database)
- [Speichern von Krankenakten mit FHIR R4](https://developers.anpheros.com/de/guides/store-medical-records-fhir)
- [Kostenlose FHIR-Datenbank und Sandbox](https://developers.anpheros.com/de/guides/free-fhir-database)
- [Vergleich von Anpheros mit anderen FHIR-Servern](https://developers.anpheros.com/de/guides/fhir-server-comparison)
- [FHIR-Plattform](https://developers.anpheros.com/de/guides/fhir)