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

FHIR-Datenbankschema

Wie FHIR-Ressourcen gespeichert werden: normalisierte Tabellen vs. JSON mit Suchindizes vs. Graph, das PostgreSQL-Schema, das Anpheros ausführt (Ressourcen, Historie, typisierte Indizes, Projektionen) und die Regeln, die wichtig sind.

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

Three ways to store FHIR data

	Normalised tables	JSON + search indexes	Graph database
Stores any valid resource unchanged	—	✓	✓
Standard FHIR search on any parameter	◐	✓	◐
New fields need a schema migration	✓	—	—
Easy SQL reporting	✓	◐	—
Used by mainstream FHIR servers	◐	✓	—

◐ = possible with extra work. HAPI FHIR and Anpheros both keep the resource as JSON and index search parameters separately.

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

How a FHIR database is laid out (the Anpheros design)

APIFHIR R4 REST and the simpler /v1 REST API
Current resourcesOne row per resource: type, id, patient, version, the full FHIR JSON (JSONB)
Search indexesTyped tables filled on every write: token, string, date, reference, quantity
HistoryEvery version of every resource, never overwritten
ProjectionsFlat tables for the common REST views: observations, conditions, medications
PostgreSQLOne database per environment; sandbox and production are separate

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.