# FHIR vs. un database medico personalizzato

> Le tue tabelle o HL7 FHIR R4 per i dati medici: la stessa lettura archiviata in entrambi i modi, i compromessi fianco a fianco, quando ciascuno è appropriato e la solita divisione tra il tuo database e il record FHIR.

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

**Un team che avvia un prodotto sanitario di solito affronta la stessa scelta fin dall'inizio: progettare le proprie tabelle per pazienti, misurazioni e diagnosi in PostgreSQL o in un altro database, oppure archiviare i dati medici come risorse HL7 FHIR R4 fin dall'inizio.** Uno schema personalizzato è più veloce il primo giorno e si adatta esattamente al tuo prodotto. FHIR costa più riflessione iniziale e ripaga ogni volta che i dati devono lasciare il tuo sistema, essere sottoposti ad audit, essere condivisi con consenso o essere letti da qualcuno che non sei tu. Questa pagina espone onestamente i compromessi, con la stessa lettura archiviata in entrambi i modi, e indica quando ciascuna scelta è appropriata.

Questa è una domanda diversa da *quale* server FHIR utilizzare. Per quello, vedi [Come Anpheros si confronta con altri server FHIR](https://developers.anpheros.com/it/guides/fhir-server-comparison).

## La stessa lettura, due modi

Una lettura della pressione sanguigna in uno schema personalizzato:

```sql
CREATE TABLE bp_readings (
  id          uuid PRIMARY KEY,
  user_id     uuid REFERENCES users(id),
  systolic    int,
  diastolic   int,
  measured_at timestamptz,
  created_at  timestamptz DEFAULT now()
);
```

Semplice, veloce da interrogare, esattamente ciò di cui l'app ha bisogno. Poi arrivano le domande a cui la tabella non risponde:

- Quale dispositivo o persona ha prodotto il valore? È stato digitato dal paziente, misurato da un bracciale, o inserito da un infermiere?
- Qual era il valore prima che qualcuno lo correggesse, e chi lo ha corretto?
- Come lo legge un sistema clinico, un laboratorio o un assicuratore? Cosa significa `systolic` nel loro sistema?
- Come lo condivide il paziente con l'app del suo medico e come smette di condividerlo il mese prossimo?
- Quando si aggiungono frequenza cardiaca, peso, HbA1c e altre 200 misurazioni, si tratta di 200 tabelle o di un'unica tabella generica da progettare autonomamente?

La stessa lettura come FHIR R4:

```json
{"resourceType": "Observation", "status": "final",
 "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs"}]}],
 "code": {"coding": [{"system": "http://loinc.org", "code": "85354-9", "display": "Blood pressure panel"}]},
 "subject": {"reference": "Patient/d09e3942-…"}, "effectiveDateTime": "2026-10-10T08:30:00Z",
 "component": [
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}, "valueQuantity": {"value": 138, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}},
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}, "valueQuantity": {"value": 88, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}}],
 "meta": {"versionId": "1"}}
```

Più verboso, ma ogni parte ha un significato che ogni sistema FHIR condivide: LOINC dice cosa è stato misurato, UCUM dice l'unità, `meta.versionId` avvia una cronologia, e la stessa forma `Observation` contiene le altre 200 misurazioni. Con Anpheros, una risorsa `Provenance` registra anche chi l'ha scritta. [Come archiviare cartelle cliniche utilizzando FHIR R4](https://developers.anpheros.com/it/guides/store-medical-records-fhir) lo illustra.

## Affiancato

| | Schema personalizzato | FHIR R4 |
|---|---|---|
| Tempo alla prima funzionalità | ore | un giorno o due per apprendere le risorse |
| Adattamento al tuo prodotto | esatto | generale; la vista del tuo prodotto si sovrappone |
| Aggiunta di un nuovo tipo di dati | una migrazione per tipo | solitamente un nuovo codice in una risorsa esistente |
| Significato al di fuori del tuo sistema | nessuno senza una mappatura | codici condivisi (LOINC, ICD-10, ATC, UCUM) |
| Cronologia e correzioni | lo progetti tu | versioni e `_history` per design |
| Chi ha scritto cosa | lo progetti tu | `Provenance` (automatico in Anpheros) |
| Scambio con cliniche, laboratori, altre app | integrazione personalizzata ogni volta | API FHIR R4, importazione HL7 v2, International Patient Summary |
| Consenso del paziente per applicazione | lo progetti tu | ambiti SMART on FHIR e OAuth |
| Query per analisi | SQL semplice | ricerca FHIR, o esportazione nel tuo warehouse |
| Regolamentazione (GDPR Articolo 9, EHDS) | documenti ogni parte | formati standard a cui la regolamentazione fa riferimento |

## Quando uno schema personalizzato è la scelta giusta

- **I dati non sono strettamente medici, o non riguardano una singola persona.** Piani di allenamento, contenuti, un catalogo prodotti: usa le tue tabelle.
- **Un prototipo di breve durata** per testare l'interesse per il prodotto, con dati sintetici e un piano di migrazione.
- **Dati che non si adattano bene a modelli standard**, ad esempio una nuova misurazione di ricerca. FHIR può comunque trasportarli (`Observation` con il tuo sistema di codici personalizzato, o `Basic`), ma una tabella personalizzata potrebbe essere più chiara.
- **Analisi intensive.** Anche con FHIR come sistema di registrazione, la maggior parte dei team copia i dati in un data warehouse nella propria struttura per la reportistica.

## Quando FHIR è la scelta giusta

- I dati sono la cartella clinica di una persona: misurazioni, diagnosi, farmaci, allergie, risultati di laboratorio, documenti.
- Dovranno lasciare il tuo sistema: al paziente, a un medico, a una clinica, a un laboratorio, a un assicuratore, a un modello AI o a un concorrente quando il paziente si sposta.
- Devi mostrare chi ha scritto cosa e cosa è cambiato: audit, sicurezza clinica, controversie.
- I pazienti concederanno e revocheranno l'accesso per applicazione.
- Vendi nell'Unione Europea, dove l'European Health Data Space si aspetta che le cartelle siano scambiabili in formati standard.

## Il percorso intermedio usuale

La maggior parte dei prodotti finisce per avere entrambi, suddivisi per tipo di dati:

```
your database                         FHIR record (Anpheros)
─────────────                         ──────────────────────
users, sessions, settings             Patient
subscriptions, billing                Observation, Condition, MedicationStatement
product content, feature flags        AllergyIntolerance, Immunization, DocumentReference
user id → patient id (one column)     Provenance, Consent, history
caches and analytics copies  ◄─────── webhooks
```

Il tuo database rimane piccolo e con la forma del prodotto. La cartella clinica è standard, versionata e condivisibile, e non hai dovuto costruirla. [Medical app backend and database](https://developers.anpheros.com/it/guides/medical-app-backend) descrive questa suddivisione in dettaglio, e [How to build a healthcare API with TypeScript](https://developers.anpheros.com/it/guides/healthcare-api-typescript) la realizza.

## Cosa serve per costruire FHIR da zero

Scegliere FHIR non significa scrivere un server FHIR. Le tue opzioni sono un server open-source che gestisci, uno store FHIR di un provider cloud, una piattaforma sanitaria open-source o un database sanitario gestito come Anpheros. Differiscono per chi gestisce il consenso, l'audit, la provenienza, la residenza e le integrazioni, come descritto in [Come Anpheros si confronta con altri server FHIR](https://developers.anpheros.com/it/guides/fhir-server-comparison).

## Domande frequenti

### FHIR è un database?
No. FHIR è uno standard per la struttura e lo scambio di dati sanitari: risorse, codici e un'API REST. Un server FHIR o un database FHIR gestito memorizza le risorse e implementa l'API sopra un database reale.

### Posso memorizzare risorse FHIR in PostgreSQL da solo?
Sì, come colonne JSON con i tuoi indici, e alcuni server open-source fanno esattamente questo. Il lavoro consiste in tutto ciò che riguarda l'archiviazione: parametri di ricerca, versioning, riferimenti, validazione, controllo degli accessi per paziente e provenienza.

### Posso iniziare con uno schema personalizzato e passare a FHIR in seguito?
Puoi farlo, e molti team lo fanno, ma la migrazione è un progetto di mappatura: ogni tabella necessita di codici, unità e autori che non ha mai registrato. Memorizzare dati medici come FHIR dalla prima funzionalità costa meno che convertirli in seguito.

### Ho bisogno di FHIR per essere conforme al GDPR?
No. Il GDPR non richiede un formato particolare. FHIR rende più facile soddisfare diversi obblighi: portabilità (il record viene esportato in un formato standard), controllo degli accessi per finalità e dimostrazione di chi ha elaborato quali dati.

## Correlati

- [Schema del database FHIR](https://developers.anpheros.com/it/guides/fhir-database-schema): come le risorse FHIR vengono archiviate e indicizzate
- [Come archiviare cartelle cliniche utilizzando FHIR R4](https://developers.anpheros.com/it/guides/store-medical-records-fhir)
- [Piattaforma FHIR](https://developers.anpheros.com/it/guides/fhir)
- [Come Anpheros si confronta con altri server FHIR](https://developers.anpheros.com/it/guides/fhir-server-comparison)
- [Backend e database per app mediche](https://developers.anpheros.com/it/guides/medical-app-backend)
- [API Sanitaria](https://developers.anpheros.com/it/guides/healthcare-api)