Strategie di migrazione per il passaggio dall'API di Azure per FHIR

Importante

L'API di Azure per FHIR verrà ritirata il 30 settembre 2026. Seguire le strategie di migrazione per passare al servizio FHIR di Servizi per i dati sanitari di Azure entro tale data. A causa del ritiro dell'API di Azure per FHIR, le nuove distribuzioni non saranno consentite a partire dal 1° aprile 2025. Il servizio FHIR di Servizi per i dati sanitari di Azure è la versione evoluta dell'API di Azure per FHIR che consente ai clienti di gestire i servizi FHIR, DICOM e MedTech con integrazioni in altri servizi di Azure.

Il servizio FHIR di Servizi per i dati sanitari di Azure è la piattaforma di nuova generazione per l'integrazione dei dati sanitari. Offre servizi FHIR, DICOM e MedTech di livello aziendale gestiti per scambi di dati sanitari diversificati.

Quando si esegue la migrazione dei dati FHIR dall'API di Azure per FHIR al servizio FHIR dai Servizi per i dati sanitari di Azure, l'organizzazione può trarre vantaggio da prestazioni, scalabilità, sicurezza e conformità migliorate. Le organizzazioni possono anche accedere a nuove funzionalità e funzionalità che non sono disponibili nell'API di Azure per FHIR.

L'API di Azure per FHIR verrà ritirata il 30 settembre 2026, quindi è necessario eseguire la migrazione dei dati FHIR al servizio FHIR di Servizi per i dati sanitari di Azure appena possibile. Per semplificare il processo, sono stati creati alcuni strumenti e suggerimenti che consentono di valutare l'idoneità, preparare i dati, eseguire la migrazione delle applicazioni e passare al nuovo servizio.

Approccio consigliato

Per eseguire la migrazione delle origini dati, seguire questi passaggi:

• Passaggio 1: valutare l'idoneità
• Passaggio 2: preparare la migrazione
• Passaggio 3: eseguire la migrazione di carichi di lavoro di dati e applicazioni
• Passaggio 4: eseguire il cutover dall'API di Azure per FHIR a Servizi per i dati sanitari di Azure

Passaggio 1: valutare l'idoneità

Confrontare le differenze tra l'API di Azure per FHIR e Servizi per i dati sanitari di Azure. Esaminare anche l'architettura e valutare se è necessario apportare modifiche.

Funzionalità	API di Azure per FHIR	Servizi per i dati sanitari di Azure
Impostazioni	Supportate: • Controllo degli accessi in base al ruolo locale • Proxy SMART on FHIR	Deprecazione pianificata: • Controllo degli accessi in base al ruolo locale (6/9/23) • Proxy SMART on FHIR (21/9/26)
Volume di archiviazione dati	Più di 4 TB	Il supporto corrente è di 4 TB (aprire una richiesta di supporto tecnico di Azure se sono necessari più di 4 TB)
Dati in ingresso	Strumenti disponibili nel software open source	$operazione di importazione
Scalabilità automatica	Supporto su richiesta e a pagamento	Abilitato per impostazione predefinita senza costi aggiuntivi
Parametri di ricerca	Tipo di bundle supportato: batch • Includere e invertire l'inclusione, modificatore di iterazione non supportato • Ordinamento supportato per nome, cognome, data di nascita e appuntamento medico	Tipo di bundle supportato: batch e transazione • Parametri di ricerca selezionabili • Includere, invertire l'inclusione e modificatore di iterazione supportato • Ordinamento supportato per stringa e campi DateTime
Eventi	Non supportato	Supportato
Infrastruttura	Supportate: • Chiavi gestite dal cliente • DR tra aree (ripristino di emergenza)	Supportate: • PITR (ripristino temporizzato) • Chiavi gestite dal cliente Imminente: • Supporto della zona di disponibilità

Aspetti da considerare che possono influire sull'architettura

• L'operatore di sincronizzazione è deprecato. Se si usa l'operatore di sincronizzazione per connettersi a Dataverse, vedere Panoramica del Data Integration Toolkit

• Il proxy FHIR è deprecato. Se si usa il proxy FHIR per gli eventi, fare riferimento alla funzionalità di gestione eventi predefinita. Le alternative possono essere personalizzate e compilate usando il toolkit dei Servizi per i dati sanitari di Azure.

• Il proxy SMART on FHIR è deprecato. È necessario usare la nuova capacità SMART on FHIR. Altre informazioni: SMART on FHIR

• Il servizio FHIR di Servizi per i dati sanitari di Azure non supporta il controllo degli accessi in base al ruolo locale e l'autorità personalizzata. L'autorità emittente del token deve essere l'endpoint di autenticazione per il tenant in cui è in esecuzione il servizio FHIR.

• Il connettore IoT è supportato solo con un'API di Azure per il servizio FHIR. Il connettore IoT viene seguito dal servizio MedTech. È necessario implementare un servizio MedTech e il servizio FHIR corrispondente in un'area di lavoro esistente o nuova dei Servizi per i dati sanitari di Azure e puntare i dispositivi al nuovo hub eventi di Hub eventi di Azure. Utilizzare i file di mappatura dei dispositivi e delle destinazioni del connettore IoT esistenti con la distribuzione del servizio MedTech.

Se si desidera eseguire la migrazione dei dati FHIR del dispositivo del connettore IoT esistenti dal servizio API di Azure per FHIR al servizio FHIR dei Servizi per i dati sanitari di Azure, usare la funzionalità di esportazione e importazione in massa nello strumento di migrazione. Un altro percorso di migrazione è implementare un nuovo servizio MedTech e riprodurre i messaggi del dispositivo IoT tramite il servizio MedTech.

Passaggio 2: preparare la migrazione

Creare innanzitutto un piano di migrazione. È consigliabile usare i modelli di migrazione descritti nella tabella. A seconda della tolleranza dell'organizzazione per i tempi di inattività, è possibile decidere di usare determinati modelli e strumenti per facilitare la migrazione.

Modello di migrazione	Dettagli	Come?
Lift-and-shift	Modello più semplice. Ideale se la propria pipeline di dati può comportare tempi di inattività più lunghi.	Scegliere l'opzione più adatta alla propria organizzazione: • Configurare un flusso di lavoro per $export i dati nell'API di Azure per FHIR, quindi $import nel servizio FHIR di Servizi per i dati sanitari di Azure. • Il repository GitHub fornisce suggerimenti sull'esecuzione di questi comandi e uno script per automatizzare la creazione del payload $import. • In alternativa, creare uno strumento personalizzato per eseguire la migrazione dei dati usando $export e $import.
Copia incrementale	Versione continua di lift-and-shift, con meno tempi di inattività. Ideale per grandi quantità di dati che richiedono più tempo per essere copiati o se si vuole continuare a eseguire l'API di Azure per FHIR durante la migrazione.	Scegli l'opzione più adatta in base alle esigenze della tua organizzazione. • È stato creato uno strumento di migrazione del software open source per facilitare questo modello di migrazione. • In alternativa, è possibile creare uno strumento personalizzato per eseguire la migrazione incrementale dei dati.

Considerazioni sugli strumenti di migrazione del software open source

Se si decide di usare lo strumento di migrazione del software open source, esaminare e comprendere le funzionalità e le limitazioni dello strumento di migrazione.

Preparare il server per API di Azure per FHIR

Identificare i dati di cui eseguire la migrazione.

• Sfruttare questa opportunità per pulire i dati o i server FHIR non più in uso.

• Decidere se si vuole eseguire o meno la migrazione delle versioni cronologiche.

Distribuire un nuovo server del servizio FHIR di Servizi per i dati sanitari di Azure.

• Distribuire innanzitutto un'area di lavoro di Servizi per i dati sanitari di Azure.

• Distribuire quindi un server del servizio FHIR di Servizi per i dati sanitari di Azure. Altre informazioni: Distribuire un servizio FHIR in Servizi per i dati sanitari di Azure

• Configurare il nuovo server del servizio FHIR di Servizi per i dati sanitari di Azure. Se è necessario usare le stesse configurazioni disponibili nell'API di Azure per FHIR per il nuovo server, vedere l'elenco consigliato delle verifiche della documentazione dello strumento di migrazione. Configurare le impostazioni prima della migrazione.

Passaggio 3: eseguire la migrazione dei dati

Scegliere il modello di migrazione più adatto per l'organizzazione. Se si usano gli strumenti di migrazione del sistema operativo, seguire le istruzioni in GitHub.

Passaggio 4: eseguire la migrazione delle applicazioni e riconfigurare le impostazioni

Eseguire la migrazione delle applicazioni che puntavano al server FHIR precedente.

• Modificare gli endpoint nelle applicazioni in modo che puntino al nuovo URL del server FHIR.

• Configurare di nuovo le autorizzazioni per queste app.

• Riconfigurare le impostazioni rimanenti nel nuovo server del servizio FHIR di Servizi per i dati sanitari di Azure dopo la migrazione.

• Se si vuole verificare che il servizio FHIR di Servizi per i dati sanitari di Azure e l'API di Azure per FHIR abbiano le stesse configurazioni, è possibile controllare entrambi gli endpoint di metadati per confrontare e mostrare le differenze dei due server.

• Configurare tutti i processi precedentemente in esecuzione nel server di API di Azure per FHIR precedente (ad esempio, $export processi)

Passaggio 5: eseguire il passaggio dei servizi FHIR di Servizi per i dati sanitari di Azure

Quando si ha certezza che il server del servizio FHIR di Servizi per i dati sanitari di Azure sia stabile, è possibile iniziare a usare tale servizio per soddisfare gli scenari aziendali. Disattivare le pipeline rimanenti in esecuzione nell'API di Azure per FHIR, eliminare i dati dall'account di archiviazione intermedio usato nello strumento di migrazione se necessario, eliminare i dati dal server dell'API di Azure per FHIR e rimuovere l'account dell'API di Azure per FHIR.