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

FHIR vs. database medico personalizzato

Le tue tabelle o HL7 FHIR R4 per i dati sanitari: la stessa lettura archiviata in entrambi i modi, i compromessi a confronto, quando scegliere l'uno o l'altro e la solita divisione tra il tuo database e il fascicolo FHIR.

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.

La stessa lettura, due modi

Una lettura della pressione sanguigna in uno schema personalizzato:

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:

{"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 lo illustra.

Affiancato

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 descrive questa suddivisione in dettaglio, e How to build a healthcare API with 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.

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: come le risorse FHIR vengono archiviate e indicizzate
• Come archiviare cartelle cliniche utilizzando FHIR R4
• Piattaforma FHIR
• Come Anpheros si confronta con altri server FHIR
• Backend e database per app mediche
• API Sanitaria

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