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 dei dati, seguire questa procedura.
- 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 è 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 $import |
| 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 distribuire un servizio MedTech e il servizio FHIR corrispondente all'interno di un'area di lavoro di Servizi per i dati sanitari di Azure esistente o nuova e puntare i dispositivi al nuovo hub eventi del dispositivo 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 seguente. 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. • 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. • 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 sono disponibili qui: 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 le differenze dei due server.
Configurare tutti i processi precedentemente in esecuzione nel server API di Azure per FHIR precedente (ad esempio processi
$export)
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 tutte le pipeline rimanenti in esecuzione in API di Azure per FHIR. Se necessario, eliminare i dati dall'account di archiviazione intermedio usato nello strumento di migrazione. Eliminare i dati dal server API di Azure per FHIR e rimuovere le autorizzazioni dell'account API di Azure per FHIR.
Nota
FHIR® è un marchio registrato di HL7 ed è usato con l'autorizzazione di HL7.