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

Schema database FHIR

Come archiviare risorse FHIR: tabelle normalizzate vs JSON con indici di ricerca vs grafo, lo schema PostgreSQL su cui gira Anpheros (risorse, cronologia, indici tipizzati, proiezioni) e le regole che contano.

Un database FHIR archivia le risorse HL7 FHIR in modo che possano essere lette, cercate e versionate tramite l'API FHIR; lo schema più comune mantiene ogni risorsa come JSON e popola tabelle di indice separate per i parametri di ricerca, invece di distribuire ogni elemento attraverso tabelle relazionali normalizzate. Questa pagina spiega i tre schemi usuali, lo schema su cui si basa Anpheros in PostgreSQL e quando non dovresti costruirne uno tu stesso.

Tre modi per archiviare 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.

Le risorse FHIR sono profonde, opzionali ed estensibili: una singola Observation ha dozzine di elementi, tipi di scelta (value[x]), codifiche ripetute ed estensioni. Normalizzare ciò in colonne relazionali significa una migrazione ogni volta che un profilo aggiunge un campo. Mantenere la risorsa come JSON memorizza qualsiasi dato valido invariato; le tabelle di indice la rendono ricercabile.

Lo 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

Tabella	Una riga per	Colonne chiave
`fhir_resources`	versione corrente di una risorsa	`resource_type`, `id`, `patient_id`, `version`, `json` (la risorsa completa), `last_updated`, `deleted`, più colonne di provenienza
`fhir_history`	ogni versione mai scritta	`resource_type`, `id`, `version`, `json`, `last_updated`
`idx_token`	valore di ricerca codificato o identificatore	system, code — per `code`, `category`, `identifier`, `status`
`idx_string`	valore di ricerca testuale	testo normalizzato — per nomi e testo libero
`idx_date`	valore di ricerca data	inizio e fine dell'intervallo — per `date`, `onset-date`, `birthdate`
`idx_reference`	valore di ricerca di riferimento	tipo di destinazione e id — per `patient`, `subject`, `encounter`
`idx_quantity`	valore di ricerca di quantità	value, system, unit — per `value-quantity`
`proj_observations`, `proj_conditions`, `proj_medications`	risorsa, appiattita	le colonne su cui filtra la semplice API REST

Ad ogni scrittura, la piattaforma valida la risorsa, scrive la nuova versione in fhir_resources e fhir_history, sostituisce le sue righe di indice e le proiezioni, e registra la Provenienza. Una ricerca come Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01 diventa join su idx_reference, idx_token e idx_date; il risultato restituisce il JSON memorizzato così come è stato scritto.

Regole di progettazione importanti

Indicizza solo i parametri di ricerca dichiarati e rifiuta quelli sconosciuti con 400 anziché ignorarli silenziosamente.
Non aggiornare mai sul posto senza cronologia: le correzioni devono mantenere ciò che era noto in precedenza.
Eliminazione logica (soft delete): una risorsa eliminata scompare dalle letture e dalle ricerche, ma le sue versioni rimangono per l'audit.
Colonna del compartimento del paziente: memorizzare patient_id su ogni risorsa rende economici $everything, i filtri di consenso e l'isolamento per paziente.
Valida prima di memorizzare: JSON non valido nello store interrompe ogni lettore in seguito.

Domande frequenti

Qual è il miglior database per FHIR?

La maggior parte dei server FHIR in produzione utilizza un database relazionale come PostgreSQL con la risorsa memorizzata come JSON (JSONB) e i parametri di ricerca indicizzati in tabelle separate. Combina archiviazione flessibile con ricerca veloce e standard.

Devo normalizzare le risorse FHIR in tabelle relazionali?

Di solito non per lo store primario. Le tabelle normalizzate sono adatte per il reporting; conservale come proiezioni costruite dalle risorse memorizzate, come fa Anpheros per la sua API REST più semplice.

Come memorizza le risorse HAPI FHIR?

Il server JPA di HAPI FHIR memorizza anche ogni versione della risorsa come JSON serializzato e mantiene i parametri di ricerca in tabelle di indice separate. Il design di Anpheros segue lo stesso principio.

Devo creare io stesso un database FHIR?

Solo se hai bisogno di un controllo completo su profili e tipi di risorse. Altrimenti, una piattaforma FHIR gestita ti fornisce archiviazione, ricerca, cronologia, consenso e audit senza dover gestire lo schema.

Correlati

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