Domande frequenti sull'API di Azure per FHIR

FHIR (Fast Healthcare Interoperability Resources) è uno standard di interoperabilità destinato ad abilitare lo scambio di dati del settore sanitario tra diversi sistemi sanitari. Questo standard è stato sviluppato dall'organizzazione HL7 e viene adottato dalle organizzazioni sanitarie in tutto il mondo. La versione più recente di FHIR disponibile è R4 (versione 4). L'API di Azure per FHIR supporta R4 e la versione precedente STU3 (Standard per l'uso della versione di valutazione 3). Per altre informazioni su FHIR, visitare HL7.org.

Sì, i dati vengono archiviati in database gestiti in Azure. L'API di Azure per FHIR non fornisce l'accesso diretto all'archivio dati sottostante.

Nel servizio gestito non è possibile accedere ai dati sottostanti. Ciò consente di garantire che l'API di Azure per FHIR offra le certificazioni di privacy e conformità necessarie per i dati sanitari. Se è necessario accedere ai dati sottostanti, è possibile usare il server FHIR open source.

È supportato Microsoft Azure Active Directory come provider di identità.

No, non è supportato B2C nell'API di Azure per FHIR. Se sono necessari controlli di accesso più granulari, è consigliabile esaminare il proxy FHIR open source.

Il backup dei dati per il servizio gestito viene eseguito automaticamente ogni 4 ore e vengono mantenuti due backup. Quindi la durata della conservazione è di 8 ore. Il ripristino dei dati viene eseguito dal team di supporto e l'obiettivo del punto di ripristino (RPO) è inferiore a 240 minuti.

I clienti possono richiedere di ripristinare i dati o modificare i criteri di backup dei dati predefiniti tramite un ticket di supporto.

Sono supportate le versioni 4.0.0 e 3.0.1. Per altre informazioni, vedere le funzionalità supportate da FHIR. È anche possibile leggere le informazioni sulle modifiche apportate tra le versioni di FHIR (DA STU3 a R4) nella cronologia delle versioni per HL7 FHIR.

Azure IoT Connector per FHIR (anteprima) supporta attualmente solo FHIR versione R4 ed è visibile nelle istanze R4 dell'API di Azure per FHIR.

L'API di Azure per FHIR è un servizio FHIR gestito a livello generale. Servizi dati di Integrità di Azure consente di distribuire un servizio FHIR e un servizio DICOM nella stessa area di lavoro. La panoramica di Servizi dati sull'integrità di Azure offre altri dettagli.

L'API di Azure per FHIR è una versione ospitata e gestita del server Microsoft FHIR open source per Azure. Nel servizio gestito, Microsoft fornisce tutti gli aggiornamenti e la manutenzione.

Quando si esegue il server FHIR per Azure, si ha accesso diretto ai servizi sottostanti, ma siamo responsabili della gestione e dell'aggiornamento del server e di tutte le operazioni di conformità necessarie se si archiviano i dati PHI.

La disponibilità generale è disponibile sia per il pubblico che per il governo in più aree geografiche. Per informazioni sui servizi cloud per enti pubblici in Microsoft, vedere Servizi di Azure di FedRAMP.

La pagina delle note sulla versione offre una panoramica di tutti gli elementi forniti al servizio gestito nel mese precedente.

Per altre informazioni sul rilascio nell'API di Azure per FHIR, vedere versioni del server FHIR open source. Si è lavorato per contrassegnare gli elementi con Azure-API-for-FHIR se verranno rilasciati al servizio gestito e in genere sono disponibili due settimane dopo che sono nella pagina di rilascio in open source. Sono state inoltre incluse istruzioni su come testare la compilazione se si vuole eseguire il test nel proprio ambiente.

Per visualizzare il pacchetto di versione attualmente incluso nel servizio gestito, è possibile visualizzare l'istruzione di funzionalità per l'API di Azure per FHIR nella software.version proprietà . Verrà visualizzato il pacchetto distribuito.

È possibile trovare la versione FHIR esatta esposta nell'istruzione capability nella fhirVersion proprietà .

No. Non è possibile modificare la versione di un database esistente. Sarà necessario creare una nuova API di Azure per FHIR e ricaricare i dati. È possibile sfruttare il convertitore JSON per FHIR come punto di partenza per convertire i dati STU3 in R4.

No. Non è possibile modificare l'URL per l'API di Azure per FHIR.

SMART (Substitutable Medical Applications and Reusable Technology) in FHIR è un set di specifiche aperte per integrare le applicazioni partner con i server FHIR e altri sistemi IT sanitari, ad esempio i record di integrità elettronici e gli scambi di informazioni sanitarie. Creando un'applicazione SMART on FHIR, è possibile assicurarsi che l'applicazione sia accessibile e sfruttata da un'ampia gamma di sistemi diversi. Per altre informazioni su SMART, visitare il sito Web SMART Health IT .

Sì, la funzionalità SMART on FHIR è supportata usando esempi AHDS. Questa operazione viene definita SMART on FHIR(Enhanced). SMART on FHIR(Enhanced) può essere considerato in grado di soddisfare i requisiti con SMART on FHIR Implementation Guide (v 1.0.0) e §170.315(g)(10) API standardizzata per i servizi di paziente e popolazione. Per altre informazioni, vedere la documentazione di SMART on FHIR(Enhanced).

Non sono consentite risorse FHIR personalizzate. Se è necessaria una risorsa FHIR personalizzata, è possibile creare una risorsa personalizzata sopra la risorsa Basic con estensioni.

È possibile caricare tutti i dati JSON FHIR validi nel server. Se si vuole archiviare la definizione della struttura che definisce l'estensione, è possibile salvarla come risorsa di definizione della struttura. Per cercare le estensioni, è necessario definire i propri parametri di ricerca.

La risorsa deve essere inferiore a 2 MB. Si tratta di una limitazione dell'archivio dati sottostante e non è possibile aumentare questo valore.

Nel servizio gestito è supportato solo JSON. Il server FHIR open source supporta JSON e XML. Per visualizzare la versione XML in open source, usare _format= application/fhir+xml.

Il limite corrente per _count è 1000. Se si imposta _count su più di 1000, verrà visualizzato un avviso nel bundle che verranno visualizzati solo 1000 record.

Per l'esportazione di gruppi vengono esportati solo i riferimenti inclusi dal gruppo e non tutte le caratteristiche della risorsa di gruppo.

Attualmente è supportata la registrazione di bundle batch, ma non è supportata la registrazione di bundle di transazioni nell'API di Azure per FHIR. È possibile usare il servizio FHIR in Servizi dati di integrità di Azure se è necessario il supporto del bundle delle transazioni.

È possibile usare l'operazione Patient-$everything oppure usare una ricerca raggruppamento nell'API di Azure per FHIR. In questo modo è possibile ottenere tutte le risorse correlate a un paziente specifico. Si noti che il raggruppamento dei pazienti include tutte le risorse correlate al paziente ma non al paziente stesso, quindi sarà necessario cercare anche per ottenere il paziente se è necessaria la risorsa del paziente nei risultati.

È supportato l'ordinamento in base alla data dell'ultimo aggiornamento: _sort=_lastUpdated. Sono supportati anche _sort sugli elementi FirstName, LastName, BirthDate e ClinicalDate. Per altre informazioni sugli altri parametri di ricerca supportati, vedere Panoramica della ricerca FHIR.

Sì, abbiamo il supporto per la $everything dei pazienti. Per altre informazioni, vedere la guida su come $Everything paziente.

No, l'API di Azure per FHIR non supporta le operazioni di terminologia oggi.

$export fa parte della specifica FHIR. Se il servizio FHIR è configurato con un'identità gestita e un account di archiviazione e se l'identità gestita ha accesso a tale account di archiviazione, è possibile chiamare $export nell'API FHIR e tutte le risorse FHIR verranno esportate nell'account di archiviazione. Per altre informazioni, vedere l'articolo $export.

È disponibile uno strumento open source per de-identificare i dati FHIR. La stessa tecnologia è integrata anche nell'API di Azure per FHIR sotto forma di esportazione de-identificata .

L'esportazione anonima è attualmente supportata solo in un'esportazione completa del sistema (/$export) e non per l'esportazione dei pazienti (/paziente/$export). Stiamo lavorando per renderlo disponibile anche a livello di paziente.

Esistono due tipi di eliminazione di base supportati nell'API di Azure per FHIR. Si tratta di eliminazione e eliminazione condizionale.

• Con Elimina è possibile scegliere di eseguire un'eliminazione temporanea (tipo più comune) e comunque essere in grado di ripristinare le versioni storiche del record.
• Con l'eliminazione condizionale è possibile passare criteri di ricerca per eliminare una risorsa una volta o più alla volta.
• Con Elimina o Elimina condizionale, se è stato passato il hardDelete parametro, tutti i record e la cronologia vengono eliminati e non recuperabili.

È possibile recuperare i file eliminati se non si usa il hardDelete parametro . I record nell'API di Azure per FHIR devono comunque esistere. I record sono disponibili eseguendo una ricerca cronologia nella risorsa e cercando l'ultima versione con i dati.

Per informazioni dettagliate sull'abilitazione dei log di controllo e delle query di esempio, vedere Abilitare la registrazione diagnostica nell'API di Azure per FHIR. Per includere informazioni aggiuntive nei log, vedere l'uso di intestazioni HTTP personalizzate.

Per risolvere questo problema, è possibile aumentare la velocità effettiva o passare alla scalabilità automatica per assicurarsi di disporre di un calcolo sufficiente per elaborare le richieste. Se si verificano problemi, aprire un ticket di supporto.

Il valore minimo dell'UR deve essere almeno 40 UR per GB. Durante il caricamento dei dati, le UR nel database aumentano se si è al di sotto di questo valore minimo.

Nella pagina Health Architecture GitHub è disponibile una raccolta di architetture di riferimento.

Per eseguire il controllo dell'integrità nel servizio FHIR, immettere {{fhirurl}}/health/check nella richiesta GET. Dovrebbe essere possibile visualizzare lo stato del servizio FHIR. Risposta al codice di stato HTTP con 200 e OverallStatus come "Integro" in risposta, significa che il controllo di integrità ha esito positivo. In caso di errori, si riceverà una risposta di errore con codice di stato HTTP 404 (Not Found) o codice di stato 500 (Errore server interno) e informazioni dettagliate nel corpo della risposta in alcuni scenari.

Sì, l'API di Azure per FHIR consente di configurare chiavi gestite dal cliente, sfruttando il supporto di Azure Cosmos DB. Per altre informazioni sulla crittografia dei dati con una chiave personale, vedere Configurare chiavi gestite dal cliente in REST.