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

Schema bazei de date FHIR

Cum se stochează resursele FHIR: tabele normalizate vs. JSON cu indecși de căutare vs. graf, schema PostgreSQL pe care rulează Anpheros (resurse, istoric, indecși tipizați, proiecții) și regulile care contează.

O bază de date FHIR stochează resurse HL7 FHIR pentru a putea fi citite, căutate și versionate prin intermediul API-ului FHIR; cel mai comun schema păstrează fiecare resursă ca JSON și completează tabele de index separate pentru parametrii de căutare, în loc să împrăștie fiecare element în tabele relaționale normalizate. Această pagină explică cele trei modele uzuale, schema pe care rulează Anpheros în PostgreSQL și când nu ar trebui să construiți una singur.

Trei modalități de stocare a 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.

Resursele FHIR sunt complexe, opționale și extensibile: o singură observație (Observation) are zeci de elemente, tipuri de alegere (value[x]), codificări repetitive și extensii. Normalizarea acestora în coloane relaționale înseamnă o migrare ori de câte ori un profil adaugă un câmp. Păstrarea resursei ca JSON stochează orice element valid neschimbat; tabelele de indexare îl fac căutabil.

Schema Anpheros

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

Tabelă	Un rând pentru	Coloane cheie
`fhir_resources`	versiunea curentă a unei resurse	`resource_type`, `id`, `patient_id`, `version`, `json` (resursa completă), `last_updated`, `deleted`, plus coloane de proveniență
`fhir_history`	fiecare versiune scrisă vreodată	`resource_type`, `id`, `version`, `json`, `last_updated`
`idx_token`	valoare de căutare codificată sau de identificare	system, code — pentru `code`, `category`, `identifier`, `status`
`idx_string`	valoare de căutare text	text normalizat — pentru nume și text liber
`idx_date`	valoare de căutare dată	început și sfârșit al intervalului — pentru `date`, `onset-date`, `birthdate`
`idx_reference`	valoare de căutare referință	tip țintă și id — pentru `patient`, `subject`, `encounter`
`idx_quantity`	valoare de căutare cantitate	value, system, unit — pentru `value-quantity`
`proj_observations`, `proj_conditions`, `proj_medications`	resursă, aplatizată	coloanele pe care se filtrează API-ul REST simplu

La fiecare scriere, platforma validează resursa, scrie noua versiune în fhir_resources și fhir_history, înlocuiește rândurile indexului și proiecțiile sale și înregistrează Proveniența. O căutare precum Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01 devine join-uri pe idx_reference, idx_token și idx_date; rezultatul returnează JSON-ul stocat așa cum a fost scris.

Reguli de design importante

Indexați doar parametrii de căutare declarați și refuzați-i pe cei necunoscuți cu 400, în loc să-i ignorați silențios.
Nu actualizați niciodată pe loc fără istoric: corecțiile trebuie să păstreze ceea ce era cunoscut anterior.
Ștergere soft (soft delete): o resursă ștearsă dispare din citiri și căutări, dar versiunile sale rămân pentru audit.
Coloana pentru compartimentul pacientului: stocarea patient_id pe fiecare resursă face ca $everything, filtrele de consimțământ și izolarea per pacient să fie ieftine.
Validați înainte de stocare: JSON-ul invalid în stocare va defecta orice cititor ulterior.

Întrebări frecvente

Care este cea mai bună bază de date pentru FHIR?

Majoritatea serverelor FHIR de producție utilizează o bază de date relațională, cum ar fi PostgreSQL, cu resursele stocate ca JSON (JSONB) și parametrii de căutare indexați în tabele separate. Aceasta combină stocarea flexibilă cu căutarea rapidă și standard.

Ar trebui să normalizez resursele FHIR în tabele relaționale?

De obicei, nu pentru stocarea primară. Tabelele normalizate sunt potrivite pentru raportare; păstrați-le ca proiecții construite din resursele stocate, așa cum face Anpheros pentru API-ul său REST mai simplu.

Cum stochează HAPI FHIR resursele?

Serverul JPA al HAPI FHIR stochează, de asemenea, fiecare versiune a resursei ca JSON serializat și păstrează parametrii de căutare în tabele de index separate. Designul Anpheros urmează același principiu.

Trebuie să construiesc singur o bază de date FHIR?

Doar dacă aveți nevoie de control complet asupra profilurilor și tipurilor de resurse. În caz contrar, o platformă FHIR gestionată vă oferă stocare, căutare, istoric, consimțământ și audit fără a gestiona schema.

Conexe

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