Un server FHIR memorizza e fornisce risorse FHIR. Una piattaforma FHIR è ciò di cui hai effettivamente bisogno per lanciare un prodotto sanitario: il server, più identità, consenso, provenienza, isolamento tra i clienti, webhook, documenti, terminologia e qualcuno che lo gestisca secondo il GDPR. Questa guida illustra la differenza e descrive come Anpheros Platform colma ogni lacuna, in modo che tu possa decidere se costruirci sopra o gestirne uno tuo.
Versione tecnica per sviluppatori: Piattaforma API per la sanità · Confronto server FHIR su developers.anpheros.com, con richieste, risposte e limiti. Questa pagina è la versione in linguaggio semplice.
Server contro piattaforma
I server FHIR open-source (HAPI, ad esempio) sono eccellenti per la parte FHIR: risorse, ricerca, convalida, cronologia. Ciò che lasciano a te è tutto ciò che lo circonda:
| Necessità | Un server FHIR | Una piattaforma FHIR |
|---|---|---|
| Archiviazione risorse, ricerca, cronologia | sì | sì |
| Chi può leggere quale paziente | il tuo codice | consenso integrato |
| Chi ha scritto ogni valore | il tuo codice | Provenienza su ogni scrittura |
| Diversi clienti su un unico sistema | il tuo codice | isolamento del progetto, ID pairwise |
| Schermata di consenso per il paziente | il tuo codice | OAuth 2.1 + SMART su FHIR |
| Notifiche alla tua app | polling | webhook firmati |
| Dati di test realistici | i tuoi fixture | 30 pazienti sintetici per sandbox |
| Hosting, backup, GDPR, DPA | il tuo team operativo | incluso |
Se hai un team operativo, un responsabile della conformità e sei mesi di tempo, gestire il tuo server è una buona scelta. Se hai un prodotto da lanciare, una piattaforma è più veloce.
Come è costruita Anpheros Platform
Un record FHIR R4 per paziente. 26 tipi di risorse, codificati con LOINC, ICD-10 e ATC, convalidati alla scrittura. La rigorosa API FHIR si trova in /fhir/R4, con una CapabilityStatement in /fhir/R4/metadata, e un'API REST semplice in /v1 serve gli stessi dati con gli stessi ID.
Isolamento del progetto e ID pairwise. Un progetto (una chiave API) vede solo i pazienti che ha creato. Ogni progetto riceve il proprio ID per la stessa persona; gli ID interni non lasciano mai la piattaforma. I riferimenti a pazienti al di fuori del tuo ambito sono mascherati con un token opaco, per progetto.
Il consenso decide le letture, la proprietà decide le scritture. Con il consenso del paziente, un'organizzazione vede l'intero record, comprese le informazioni scritte da altre cliniche, ma può modificare o eliminare solo ciò che ha scritto autonomamente. Ogni versione di ogni risorsa registra il progetto che l'ha scritta; una scrittura da parte di un altro progetto viene rifiutata con una spiegazione.
Provenienza e audit su ogni scrittura. Provenance.agent.onBehalfOf indica la clinica o l'organizzazione al momento della scrittura; una riga di audit registra chi, cosa, quando, con quale autorizzazione, da quale applicazione. Il paziente può leggere il proprio registro di accesso, anche come risorse FHIR AuditEvent.
Webhook sottili e firmati. Gli eventi trasportano ID e versioni, mai contenuti clinici; leggi la risorsa tramite l'API. Le consegne sono firmate con HMAC-SHA256 e ritentate con backoff per un massimo di 24 ore.
Sandbox e produzione sono database separati. Una chiave sk_test_ non può accedere a un paziente reale. La sandbox è gratuita e self-service.
Residenza UE. Cloud Run in europe-west4, con un accordo di elaborazione dei dati per le organizzazioni di produzione.
Cosa è deliberatamente assente
- Nessun supporto decisionale clinico. La piattaforma memorizza, codifica e condivide; non diagnostica né raccomanda trattamenti.
- Nessun database completo di farmaci con interazioni. I farmaci sono codificati con ATC, ed è disponibile un sottoinsieme ATC e LOINC aggregato per la ricerca, ma il controllo delle interazioni è un tuo componente o un servizio con licenza.
- Nessun bus di messaggistica HL7 v2 di livello ospedaliero. Esiste un'importazione HL7 v2 ORU^R01 per i referti di laboratorio; non c'è gestione ADT o ordini.
Conoscere questi limiti in anticipo consente di risparmiare una settimana di ricerca.
Quando gestire il proprio server invece
- Devi ospitare all'interno della tua rete ospedaliera, senza elaboratori esterni.
- Hai bisogno di FHIR R5 o di profili che la piattaforma non implementa.
- Il tuo prodotto è il server FHIR stesso.
In tutti gli altri casi, inizia dalla sandbox, misura e decidi con i dati. La prima ora è descritta su developers.anpheros.com/guides/first-hour; il riferimento API completo è su platform.anpheros.com/docs.
Domande frequenti
Anpheros è un server FHIR?
Ne contiene uno: un'API FHIR R4 con 26 tipi di risorse, ricerca, cronologia, operazioni $everything, $summary, $validate e terminologia. Attorno ad essa ci sono consenso, provenienza, isolamento, webhook e hosting, che è ciò che la rende una piattaforma.
Quale versione FHIR?
FHIR R4 (4.0.1), la versione richiesta dalla normativa UE e USA e implementata dalla maggior parte dei sistemi. La conformità è stata verificata con Inferno; vedere le note di conformità IPS.
Diverse cliniche possono condividere il record di un paziente?
Sì, è questo il punto. Con il consenso del paziente, ogni clinica legge l'intero record e scrive le proprie risorse, ognuna contrassegnata con la propria provenienza. Nessuna clinica può modificare ciò che un'altra ha scritto.
Esiste un backend FHIR gratuito per lo sviluppo?
Sì. La sandbox è gratuita, self-service e include 30 pazienti sintetici per progetto. Vedi Server FHIR gratuito: la sandbox.
Come posso migrare se necessario?
Tutto è FHIR R4 ed esportabile: Patient/{id}/$everything restituisce l'intero record di un paziente come Bundle. Non c'è un formato proprietario da sbrogliare.
Tieni la tua cartella clinica con te
Anpheros Daily conserva sintomi, analisi, farmaci e documenti in un unico posto, in formato standard, sotto il tuo controllo. Il piano Basic è gratuito.