# Schema del database FHIR

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

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

**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

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

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

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

| 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.

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

## Correlati

- [FHIR vs. un database medico personalizzato](https://developers.anpheros.com/it/guides/fhir-vs-custom-database)
- [Come archiviare cartelle cliniche utilizzando FHIR R4](https://developers.anpheros.com/it/guides/store-medical-records-fhir)
- [Database e sandbox FHIR gratuiti](https://developers.anpheros.com/it/guides/free-fhir-database)
- [Come Anpheros si confronta con altri server FHIR](https://developers.anpheros.com/it/guides/fhir-server-comparison)
- [Piattaforma FHIR](https://developers.anpheros.com/it/guides/fhir)