# Come Anpheros si confronta con altri server FHIR

> Server FHIR self-hosted, archivi FHIR cloud, piattaforme sanitarie open-source e Anpheros a confronto: chi autorizza l'accesso, il consenso, la provenienza, la residenza, i prezzi e quando ciascuno è la scelta giusta.

Source: https://developers.anpheros.com/it/guides/fhir-server-comparison

**I team che scelgono un backend FHIR solitamente valutano quattro tipi di opzione: un server open-source che ospitano autonomamente, un archivio FHIR gestito da un provider cloud, una piattaforma sanitaria open-source con un'edizione ospitata, o un database sanitario gestito come Anpheros.** Questa guida descrive a cosa serve ciascun tipo e dove si posiziona Anpheros, basandosi sulla documentazione pubblica di ottobre 2026. Per qualsiasi prodotto qui nominato, consultare la sua documentazione; le funzionalità cambiano.

## I quattro tipi

| | Server FHIR self-hosted (es. HAPI FHIR) | Store FHIR cloud (es. Google Cloud Healthcare API, Azure Health Data Services, AWS HealthLake) | Piattaforma sanitaria (es. Medplum) | Anpheros |
|---|---|---|---|---|
| Cos'è | un server FHIR che gestisci | uno store di dati FHIR all'interno di un account cloud | una piattaforma applicativa nativa FHIR con autenticazione, workflow e un'edizione ospitata | un database sanitario gestito: record FHIR R4 per paziente, consenso, API, audit |
| Chi autorizza l'accesso | ciò che costruisci attorno ad esso | l'IAM del cloud, per progetto o dataset | le policy di accesso della piattaforma, configurate da te | il paziente (consenso OAuth 2.1) o l'organizzazione (API key) |
| Consenso e audit rivolti al paziente | no | no | realizzabile con il suo modello di policy | integrato, visibile al paziente |
| Provenienza su ogni scrittura | se lo aggiungi | se lo aggiungi | supportato da FHIR; lo fai rispettare tu | richiesto e automatico |
| Isolamento degli identificatori tra applicazioni | no | no | no | ID pairwise per applicazione |
| Importazione di laboratorio (HL7 v2) | strumenti separati | parziale (mapping da v2 a FHIR in alcuni store) | integrazioni che scrivi | integrato, una richiesta |
| Residenza dei dati | ovunque lo ospiti | le regioni offerte dal provider | dipende dall'hosting | solo Unione Europea |
| Prezzi | la tua infrastruttura e il tuo tempo | basato sull'utilizzo (richieste, storage) | per piano o self-hosted | per organizzazione, in base ai pazienti memorizzati |
| Ideale per | apprendimento, controllo completo, modelli di dati insoliti | team già su quel cloud che costruiranno da soli il livello sanitario | team che vogliono costruire su una codebase aperta e possedere lo stack completo | team che vogliono il livello sanitario pronto e il prodotto come loro lavoro |

## Google Cloud Healthcare API o una piattaforma gestita?

Il prodotto di Google si chiama letteralmente Cloud Healthcare API, quindi appare per primo in molte ricerche di "healthcare API". È uno store FHIR cloud (più store HL7 v2 e DICOM) all'interno del tuo progetto Google Cloud: storage, ricerca FHIR e accesso basato su IAM, fatturato in base all'utilizzo. Il resto lo costruisci tu: consenso e audit rivolti ai pazienti, isolamento delle applicazioni, importazione di laboratori, SDK e una sandbox con dati di test. Anpheros fornisce queste parti e memorizza i dati nell'UE; non ti fornisce uno store FHIR all'interno del tuo account cloud. Scegli in base a chi dovrebbe possedere il livello sanitario: il tuo team (Cloud Healthcare API) o la piattaforma (Anpheros).

## Server FHIR open-source o gestito?

Server open-source come HAPI FHIR possono essere eseguiti ovunque (sono disponibili immagini Docker) e supportano la specifica FHIR completa, con i propri profili ed estensioni. Eseguirli in produzione significa gestire autonomamente il database, gli aggiornamenti, la sicurezza, i backup e il livello di accesso. Una piattaforma gestita scambia parte di questa libertà (Anpheros memorizza 26 tipi di risorse) per non doverla eseguire. Vedere [Schema del database FHIR](https://developers.anpheros.com/it/guides/fhir-database-schema) per ciò che un tale server memorizza internamente.

## Quando Anpheros è la scelta giusta

- Stai costruendo un prodotto per pazienti, cliniche, laboratori o AI e vuoi scrivere il prodotto, non il record.
- Il consenso del paziente e un audit che il paziente può leggere sono requisiti, non opzioni desiderabili (Articolo 9 del GDPR, EHDS).
- I tuoi dati devono rimanere nell'Unione Europea.
- Desideri FHIR R4 ma anche una vista REST più semplice, SDK e webhook, da un unico fornitore.
- Vuoi iniziare gratuitamente, in una sandbox con pazienti sintetici realistici, e passare alla produzione senza riscrivere.

## Dove un'altra opzione è migliore

- Hai bisogno di tipi di risorse FHIR, profili o estensioni al di fuori dei 26 supportati da Anpheros, o di un modello di dati completamente personalizzato: un server self-hosted ti offre questa libertà.
- La tua organizzazione richiede che tutto sia all'interno di un unico account cloud per motivi di conformità: un FHIR store cloud si adatta a tale politica.
- Vuoi possedere e modificare l'intera stack, inclusi il server di autorizzazione e i componenti UI: una piattaforma open-source è progettata per questo.
- Hai bisogno oggi di launch EHR, Bulk Data export o ambiti `system/`: Anpheros non li offre ancora (vedi [Come implementare il consenso del paziente con SMART on FHIR](https://developers.anpheros.com/it/guides/smart-on-fhir-backend)).

## Un modo equo per decidere

Conta le parti del livello sanitario necessarie al tuo prodotto: consenso, provenienza, audit, identificatori, importazione di laboratorio, archiviazione documenti, residenza e stima i mesi necessari per costruire e mantenere ciascuna di esse nell'opzione che preferisci. Confronta quindi questo dato con il lavoro sul prodotto a cui quei mesi avrebbero potuto essere dedicati. Anpheros è la risposta giusta quando il secondo numero è maggiore.

## Correlati

- [Piattaforma API per la sanità: cosa include e come scegliere](https://developers.anpheros.com/it/guides/healthcare-api-platform): le domande da porre a qualsiasi fornitore
- [FHIR vs. un database medico personalizzato](https://developers.anpheros.com/it/guides/fhir-vs-custom-database): quando progettare le proprie tabelle e quando utilizzare FHIR
- [Database e sandbox FHIR gratuiti](https://developers.anpheros.com/it/guides/free-fhir-database)
- [Piattaforma FHIR](https://developers.anpheros.com/it/guides/fhir)
- [Backend e database per app mediche](https://developers.anpheros.com/it/guides/medical-app-backend)
- [Startup nel settore sanitario](https://developers.anpheros.com/it/guides/healthcare-startups)
- [Sicurezza, privacy e residenza dei dati](https://developers.anpheros.com/it/guides/security)