Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Migrazione da un server FHIR esistente
Per migrare i dati da un server FHIR esistente a, segui questi passaggi. HealthLake
Fase 1: Convalida l'ambiente HealthLake
Prima di iniziare qualsiasi migrazione dei dati, configura e convalida HealthLake tramite un proof-of-concept in un account di sviluppo.
Per convalidare il tuo ambiente HealthLake
-
Crea un archivio dati con la strategia di autorizzazione prescelta (SMART su FHIR o AWS SigV4-only) e la chiave di AWS KMS crittografia. La configurazione di autorizzazione è specificata come parte della richiesta di creazione dell'archivio dati. Per ulteriori informazioni, consultare Creazione di un archivio HealthLake dati e .
-
Configura il tuo proxy API Gateway.
-
Verifica che HealthLake funzioni con i modelli di integrazione dell'API FHIR del tuo EHR.
-
Convalida il CapabilityStatement (
GET /metadata) rispetto alle risorse supportate e ai parametri di ricerca previsti dall'applicazione.
Fase 2: Esportazione dal server FHIR esistente
Esegui un'$exportoperazione (System-level o Group-level) sul tuo attuale server FHIR per l'IG FHIR Bulk
Se il server non lo supporta$export, estrai le risorse direttamente dal database sottostante e serializzale come bundle JSON FHIR R4.
Fase 3: Stage in Amazon S3 e importazione
Carica NDJSON contenente risorse FHIR in un bucket Amazon S3. La richiesta di lavoro di importazione richiede i seguenti quattro parametri:
-
L'URI di input di Amazon S3
-
L'URI di output di Amazon S3 (per i risultati del lavoro)
-
L'ID del data store
-
Il ruolo di accesso ai dati IAM ARN
Per ulteriori informazioni, consulta Avvio di un processo di importazione FHIR.
Imposta il ValidationLevel parametro in base alla tua posizione in materia di qualità dei dati:
| Livello di convalida | Description |
|---|---|
strict (predefinito) |
Le risorse vengono convalidate in base all'elemento del profilo della risorsa o alla specifica R4 se non è presente alcun profilo. I profili devono essere supportati da. HealthLake Per un elenco dei profili supportati, vedereValidazioni del profilo FHIR per HealthLake. HealthLake rifiuta le risorse che non superano la convalida. |
structure-only |
Le risorse vengono convalidate rispetto a R4, ignorando i profili di riferimento. |
minimal |
Le risorse vengono convalidate minimamente, ignorando alcune regole R4. Le risorse che non superano i controlli di struttura richiesti search/analytics vengono aggiornate per includere un'estensione di avviso per l'audit. |
Per ulteriori informazioni sui livelli di convalida, vedere.
Fase 4: Convalida dell'importazione
HealthLake genera un manifest.json file nel bucket Amazon S3 di output per ogni processo di importazione, riportando il conteggio delle risorse in termini di successo e fallimento.
Per convalidare l'importazione
-
Riconcilia i conteggi del manifesto con i conteggi delle risorse del sistema di origine per tipo.
-
FAILURE/Esamina i log per individuare le cause più comuni: riferimenti non validi, formati di data non corretti o errori di convalida del profilo.
Fase 5: Cutover
Durante la finestra di modifica, utilizza HealthLake lo standard FHIR per creare e aggiornare le API per le scritture in tempo reale, mentre l'importazione in blocco gestisce il backfill cronologico. Per ulteriori informazioni, consultare Creazione di una risorsa FHIR e Aggiornamento di una risorsa FHIR. Una volta completata, reindirizza l'endpoint FHIR dell'applicazione a. HealthLake
HealthLake espone un'API RESTful FHIR R4 standard, quindi la modifica a livello di applicazione è in genere uno scambio di URL di base. Se l'applicazione utilizza SMART su FHIR, è inoltre necessario aggiornare l'URL del server di risorse FHIR del server di autorizzazione in modo che punti all'endpoint del data store. HealthLake
Fase 6: convalida Post-migration
Verifica che tutte le operazioni FHIR funzionino come previsto. HealthLake offre opzioni di monitoraggio su tutti gli archivi di dati tramite Amazon CloudWatch e AWS CloudTrail.
Nota
HealthLake supporta solo R4. Se il server esistente esegue STU3 o DSTU2, è necessario trasformare le risorse in R4 prima dell'importazione. AWS HealthLake I partner forniscono strumenti di conversione per dati non R4.