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à.
Funzionalità di trasformazione dei dati
Ogni funzionalità riportata di seguito è documentata con cos'è, come funziona, le differenze tra C-CDA le sorgenti CSV e quando utilizzarla.
Profili di trasformazione e controllo delle versioni
Un profilo di trasformazione è la definizione riutilizzabile di come un formato sorgente viene convertito in FHIR R4. Contiene la logica di conversione (modelli Velocity per C-CDA, una configurazione di mappatura YAML per CSV) e viene creato una volta e riutilizzato in tutti i datastore e i processi di trasformazione dell'account. Separare la definizione (profilo) dall'esecuzione (processo) significa creare e testare una conversione una volta, quindi applicare la stessa versione pubblicata a un numero qualsiasi di lavori.
Creazione di un profilo
È possibile creare un profilo in tre modi:
-
Da un profilo iniziale o base: parti da un profilo di lavoro anziché da uno vuoto. Per C-CDA, lo AWS Starter Profile è un AWS-defined profilo predefinito che gestisce immediatamente i formati di C-CDA documento più comuni. Per il formato CSV, fornisci file di esempio in Amazon S3 durante la creazione del profilo, quindi richiami l'agente AI per analizzarli e generare una configurazione di mappatura YAML.
-
Clonando: clona qualsiasi profilo esistente come punto di partenza per uno nuovo.
-
Da una mappatura grezza: fornisci direttamente i modelli Velocity (C-CDA) o una mappatura YAML (CSV). Questo è il percorso per implementare profili controllati dalla versione tramite una pipeline (vedi). CI/CD Guida introduttiva all'SDK e AWS CLI
Importante
La creazione di un profilo CSV con SampleData registra la posizione del campione ma non esegue l'agente AI. Per generare la mappatura YAML, è necessario chiamare dopo la creazione. UpdateProfileWithAgent L'agente analizza i file di esempio a quel punto e produce il profilo di base.
Il ciclo di vita della versione
Un profilo può avere al massimo una bozza e fino a 99 versioni pubblicate:
-
Un nuovo profilo inizia come bozza (versione 0): una copia di lavoro modificabile che puoi modificare liberamente.
-
La pubblicazione della bozza crea una versione numerata immutabile (v1, v2 e così via, fino alla v99). Le versioni pubblicate non cambiano mai.
-
I processi di trasformazione vengono sempre eseguiti con l'ultima versione pubblicata. Poiché la bozza è separata, puoi continuare a modificarla mentre i lavori di produzione continuano a essere eseguiti con l'ultima versione pubblicata: le modifiche in corso non influiscono mai sulle conversioni in corso.
-
Un profilo con una versione pubblicata e modifiche non pubblicate più recenti è in uno stato di modifiche non pubblicate; la versione pubblicata rimane attiva fino a quando non viene pubblicata nuovamente.
Confronto e ripristino
Poiché ogni versione pubblicata viene conservata, puoi vedere esattamente come è cambiata la logica di conversione nel corso della cronologia delle versioni. Il rollback non elimina nulla: crea una nuova versione da un'istantanea precedente, in modo da conservare la cronologia completa e l'audit trail.
Quando usare il controllo delle versioni
Pubblica una versione prima di eseguire un processo di produzione in modo che il processo venga associato alla logica di revisione. Usa il rollback quando una modifica produce un risultato inaspettato e confronta per confermare quale modifica sia stata effettivamente modificata.
Agente AI per la trasformazione dei dati
L'agente Data Transformation AI elimina lo sforzo manuale di creazione e manutenzione delle mappature FHIR. Invece di scrivere a mano la logica di conversione, descrivi il risultato desiderato e l'agente produce o aggiorna la logica sottostante: modelli Velocity per C-CDA, una configurazione di mappatura YAML per CSV. L'agente è incorporato nell'editor dei profili Console di gestione AWS ed è disponibile anche tramite l' UpdateProfileWithAgent API e come strumento MCP, quindi puoi utilizzarlo da, dal Console di gestione AWS codice o da un IDE. MCP-compatible
Cosa fa l'agente
L'agente Data Transformation AI esegue le seguenti attività:
-
Genera una logica di conversione dai tuoi dati. Per il formato CSV, l'agente analizza i file di esempio forniti al momento della creazione del profilo e produce un profilo di base: deducendo le risorse e i campi FHIR di destinazione, in modo da iniziare da una bozza funzionante anziché da un profilo vuoto. Inoltre C-CDA, adatta lo AWS Starter Profile ai tuoi documenti.
-
Modifica la logica di conversione dal linguaggio naturale. Descrivi una modifica in un linguaggio semplice e l'agente aggiorna il modello o la mappatura sottostante. Ad esempio:
-
«Aggiungi una mappatura per la risorsa Farmaci».
-
«Mappa la lingua preferita del paziente dalla sezione LanguageCommunication».
-
«Imposta lo stato predefinito su Washington per le risorse dei pazienti».
-
«Associa la colonna RACE_CD a un'estensione FHIR».
-
«Ignora i record in cui lo stato è stato inserito per errore».
-
-
Spiegazioni e recensioni prima della candidatura. L'agente presenta la modifica proposta come una differenza del modello o della mappatura interessata affinché tu possa esaminarla e la applica solo dopo la tua accettazione. Nulla cambia automaticamente nel profilo pubblicato, l'agente apporta modifiche solo alla versione bozza.
-
Perfeziona in modo iterativo. Collabora con l'agente su più turni per modificare una mappatura finché l'output convertito non sia corretto, visualizzando in anteprima i risultati rispetto ai dati di esempio tra un turno e l'altro con l'API di trasformazione di sincronizzazione.
C-CDA flusso di lavoro (modelli Velocity)
L'agente modifica i modelli Velocity che definiscono il modo in cui le C-CDA sezioni vengono mappate alle risorse FHIR. Chiedendogli di aggiungere una mappatura delle risorse, modificare l'interpretazione di una sezione, impostare valori predefiniti o gestire una variante del documento, aggiorna i modelli e restituisce un diff. Puoi visualizzare l'anteprima della conversione rispetto a C-CDA documenti di esempio prima della pubblicazione.
Flusso di lavoro CSV (mappatura YAML)
Quando si crea un profilo CSV con file di esempio e si richiama l'agente, quest'ultimo analizza le intestazioni, i valori di esempio e i modelli di dati dei file, quindi propone una configurazione di mappatura YAML che include:
-
Mappature da colonna a campo FHIR,
-
rilevamento del formato di data e riformattazione nei formati FHIR, date/time
-
traduzioni di valori (ad esempio, M → male, INPATIENT → IMP),
-
primary/foreign-relazioni chiave tra tabelle,
-
regole di aggregazione che ripiegano le righe della tabella secondaria in array FHIR sulla risorsa principale,
-
eventuali ipotesi formulate dall'agente ed eventuali domande sui tuoi dati.
L'utente accetta, rifiuta o perfeziona ogni mappatura proposta e può chiedere all'agente ulteriori modifiche. L'agente deduce la mappatura da un campione dei tuoi file anziché dall'intero set di dati, quindi fornisci esempi rappresentativi dei tuoi dati ed esamina la mappatura proposta prima di convertirla su larga scala.
Input accettati dall'agente
È possibile comunicare con l'agente tramite input in linguaggio naturale. Alcune combinazioni includono:
-
istruzioni,
-
dati di origine di esempio (C-CDA sezioni o schemi CSV),
-
documentazione dello schema,
-
errori di convalida FHIR derivanti da una conversione precedente.
Modifica manuale
Non è necessario utilizzare l'agente. Puoi modificare i modelli Velocity e le mappature YAML direttamente in qualsiasi momento e combinare le modifiche manuali con le modifiche create dall'agente sullo stesso profilo.
Trasformazione e anteprima sincrone (in tempo reale)
La trasformazione sincrona converte un singolo input e restituisce immediatamente il risultato FHIR, anziché eseguire un processo asincrono su Amazon S3. Esiste per due scopi: testare un profilo mentre lo si crea ed eseguire piccole trasformazioni interattive in un flusso. request/response
Come funziona
Una trasformazione sincrona elabora un singolo input nel modo seguente:
-
Si invia un input (un C-CDA documento o un set di file CSV) rispetto a un profilo e si ricevono le risorse FHIR convertite come pacchetto FHIR nella risposta.
-
L'operazione è disponibile solo tramite l'API REST: non è esposta come comando o SDK. AWS CLI Consulta Accesso a Data Transformation Agent.
-
È possibile abilitare il rilevamento della deriva durante una chiamata di sincronizzazione impostando su true DriftDetectionEnabled per vedere, nella risposta, quali elementi sorgente non sono ancora acquisiti da un profilo: utile durante l'iterazione su una mappatura.
Limiti di dimensione
La trasformazione sincrona accetta C-CDA input fino a 1 MB e input CSV combinati fino a 1 MB per richiesta. Per set di dati più grandi, utilizza un processo di trasformazione in blocco.
Visualizza l'anteprima in Console di gestione AWS
Quando si crea un profilo in modalità sincrona Console di gestione AWS, l'anteprima dal vivo viene attivata: si vede la sorgente su un lato e l'output FHIR convertito sull'altro e l'anteprima si aggiorna man mano che si perfeziona la mappatura. Utilizzatelo per verificare che l'output sia corretto prima della pubblicazione.
Quando usare la sincronizzazione rispetto a quella in blocco
Usa la trasformazione sincrona per convalidare un profilo rispetto a documenti rappresentativi e per conversioni sensibili alla latenza e su richiesta, come un feed live che converte i documenti man mano che arrivano. Utilizza un processo di trasformazione in blocco (di seguito) per set di dati di grandi dimensioni e per l'inserimento diretto in un datastore. HealthLake
Processi di trasformazione in blocco (asincroni)
Un processo di trasformazione in blocco converte un set di dati di grandi dimensioni da Amazon S3 utilizzando un profilo pubblicato, eseguito in modo asincrono mentre si monitora i progressi. Questo è il percorso di produzione per le migrazioni e per il caricamento dei dati in un datastore. HealthLake Fai riferimento a questa pagina per la configurazione delle autorizzazioni IAM.
Come funziona
Un processo di trasformazione in blocco funziona come segue:
-
Indirizza un lavoro a un prefisso Amazon S3 dei file sorgente, scegli un profilo pubblicato e scegli una destinazione di output. Il job analizza l'input, converte ogni file (C-CDA) o set di righe (CSV) e scrive i risultati.
-
Non è necessaria alcuna infrastruttura di provisioning: il job viene scalato automaticamente.
Modalità di output
Un job in blocco supporta le seguenti modalità di output:
-
Autonomo: scrivi FHIR convertito in una posizione Amazon S3. Usa l'API. StartDataTransformationJob
-
Composito (conversione e acquisizione): converti i file sorgente e inserisci le risorse FHIR risultanti direttamente in un HealthLake datastore in un unico passaggio, in modo che i dati siano immediatamente interrogabili. Usa l' StartFHIRImportJob API con i parametri,, e opzionalmente. ProfileId InputFormat DriftDetectionEnabled Il datastore deve essere in stato ATTIVO. Vedi Passaggio 7: conversione e inserimento in un HealthLake datastore per un esempio completo.
Elegante gestione dei guasti
Gli input non validi vengono ignorati e registrati anziché fallire nel batch, quindi un singolo file danneggiato non interrompe mai un lavoro di grandi dimensioni. Gli input non riusciti vengono scritti come file di errore JSON con il percorso del file di input e il messaggio di errore, quindi è possibile esaminarli e rielaborarli.
Layout di output
Il servizio crea una cartella con ambito di lavoro sotto l'URI Amazon S3 di output utilizzando il job ID. All'interno di quella cartella:
-
converted/: file di output FHIR NDJSON (uno per file di input, ad esempio -record.ndjson). converted/patient
-
ERROR/: dettagli dell'errore per gli input non riusciti (file JSON con campi InputFile e ErrorMessage, ad esempio). ERROR/bad-file.json
-
Manifest.json: riepilogo del lavoro con metriche aggregate (file scansionati, convertiti, non riusciti, risorse generate).
-
lavoroLevelDriftResult.json: il rapporto aggregato sulla deriva per il lavoro, se il rilevamento della deriva è stato abilitato.
-
driftDetectionPerFileResults/: per i C-CDA lavori con il rilevamento della deriva abilitato, report di deriva per file (ad esempio, driftDetectionPerFileResults/patient -record_driftMetrics.json), in modo da poter controllare la copertura di un singolo file sorgente anziché solo dell'aggregato a livello di lavoro.
Monitoraggio
Tieni traccia di un processo in corso tramite la pagina dei dettagli del Console di gestione AWS lavoro o l' DescribeDataTransformationJob API: stato, file elaborati (righe per CSV), risorse generate e errori. Le metriche e i log dei lavori sono disponibili anche in Amazon. CloudWatch
Convalida
Data Transformation Agent esegue la convalida in più punti del ciclo di vita della conversione, quindi i problemi vengono rilevati prima che si trasformino in conversioni non riuscite o output non conforme.
-
Convalida della fonte: verifica che gli input siano ben formati e conformi alle C-CDA specifiche. C-CDA Gli errori includono dettagli sulla posizione e indicazioni per la risoluzione, in modo da poter risolvere i problemi relativi all'origine prima di eseguire un lavoro di grandi dimensioni. L' ValidateSource operazione è disponibile tramite l'API REST per visualizzare gli input in anticipo.
-
Convalida dei modelli/mappature: convalida i modelli Velocity (C-CDA) o la mappatura YAML (CSV) di un profilo indipendentemente da qualsiasi dato, in modo da poter confermare che la logica di conversione sia corretta prima di pubblicare o eseguire un lavoro.
-
Convalida FHIR dell'output: verifica che le risorse generate siano conformi a FHIR R4, in modo che le API e i datastore FHIR a valle accettino l'output.
Insieme, ciò significa che un processo fallisce meno spesso per ragioni evitabili: la convalida della fonte rileva input errati, la convalida della mappatura rileva una logica errata e la convalida dell'output conferma che il risultato è conforme agli standard.
OID-to-URI mappatura
C-CDA i documenti identificano i sistemi di codice utilizzando OID (Object Identifiers): identificatori numerici precedenti come (LOINC). 2.16.840.1.113883.6.1 FHIR si aspetta URI di sistema moderni come. http://loinc.org Se gli OID vengono trasferiti senza mappatura, i valori di sistema risultanti non sono interoperabili e gli strumenti FHIR a valle non possono risolvere i codici. Data Transformation Agent esegue le mappature tra di essi durante la conversione.
-
Pre-built mappature: le mappature per gli OID sanitari comuni (ad esempio, LOINC, SNOMED CT,, RxNorm) vengono applicate automaticamente ICD-10, senza alcuna configurazione.
-
Mappature personalizzate: aggiungi le tue mappature per i sistemi di codice specifici OID-to-URI delle tue fonti, in modo che i sistemi proprietari o locali si risolvano correttamente.
Questo vale per le C-CDA fonti, dove gli OID sono il modo nativo in cui i sistemi di codice vengono identificati.
Provenienza
I flussi di lavoro sanitari regolamentati devono rispondere alla domanda «da dove provengono questi dati e come sono stati prodotti?» per qualsiasi risorsa. Quando la provenienza è abilitata su un job, Data Transformation Agent genera una risorsa FHIR Provenance per ogni conversione, fornendo a ciascuna risorsa di output una derivazione completa e interrogabile dalla sua origine.
La catena di provenienza
Provenienza → DocumentReference → file sorgente. La risorsa Provenance fa riferimento a DocumentReference, che registra l'URI Amazon S3 del file sorgente e un checksum. SHA-1 Il checksum consente di dimostrare che l'output è stato derivato da un file sorgente specifico e inalterato. Se tali informazioni sono necessarie, viene fornita anche una risorsa del dispositivo che rappresenta la trasformazione dei AWS HealthLake dati come entità.
Record-level localizzatori
La provenienza si riferisce non solo al file sorgente ma anche alla posizione esatta al suo interno e il localizzatore differisce in base al formato di origine:
-
C-CDA: un XPath che punta all'elemento sorgente da cui è stata derivata la risorsa.
-
CSV: il nome della tabella, la chiave primaria e il numero di riga del record di origine.
Campi acquisiti
Ogni risorsa Provenance registra l'URI e il checksum del file sorgente, la versione del profilo utilizzata per la conversione, un timestamp e il localizzatore a livello di record.
Conformità e utilizzo
Le risorse di provenienza sono conformi al profilo US Core Provenance, quindi interagiscono con gli strumenti statunitensi. Core-aware Attiva la provenienza quando hai bisogno di verificarne la conformità o quando devi far risalire una risorsa di output discutibile all'esatto elemento di origine che l'ha prodotta. La provenienza è abilitata per impostazione predefinita; impostala su false ProvenanceEnabled per disabilitarla.
Rilevamento delle deviazioni
Una conversione può avere esito positivo eliminando silenziosamente i dati di origine che un profilo non ha ancora mappato. Il rilevamento della deriva elimina tale lacuna. È un rapporto: quando abilitato, confronta il contenuto della fonte con ciò che il profilo ha effettivamente prodotto e registra ciò che è stato lasciato.
Cosa contiene il rapporto
Il rapporto di deriva contiene le seguenti informazioni:
-
Il tasso di copertura complessivo per la conversione.
-
Un elenco classificato di sezioni ed elementi di origine non mappati, in modo da poter dare la priorità alle lacune di maggiore impatto.
-
Tutte le risorse previste che non sono state prodotte.
-
Tracciabilità completa fino al file di origine e alla posizione dell'elemento (nome del file e OID per C-CDA, riga per CSV).
Come usare il rilevamento della deriva
Il rilevamento della deriva è disponibile in entrambe le modalità di conversione, quindi puoi utilizzarlo sia che tu stia iterando su un singolo file o convalidando un set di dati completo:
-
Sincronizzazione (in tempo reale): impostato DriftDetectionEnabled su true su una TransformData richiesta per eseguire il rilevamento della deriva su un singolo file e ottenere i risultati nella risposta dell'API. Questo è il modo più veloce per verificare la copertura durante la creazione di un profilo: converti un documento rappresentativo, scopri esattamente cosa non è andato a buon fine nel profilo, perfeziona la mappatura e riprova.
-
In blocco (asincrono): abilita il rilevamento delle deviazioni durante un processo di trasformazione per misurare la copertura dell'intero set di dati. Il report viene scritto come job LevelDriftResult.json nella posizione di output Amazon S3 del job. Per i C-CDA lavori, i report di deriva per file vengono scritti anche nella cartella driftDetectionPerFileResults/, in modo da poter individuare le lacune di copertura in un singolo file sorgente.
Accesso MCP
Il Model Context Protocol (MCP) espone Data Transformation Agent agli agenti IDE-based AI come strumenti richiamabili, in modo che uno sviluppatore possa creare profili, eseguire conversioni e analizzare gli errori di un assistente nel proprio IDE: senza passare al. Console di gestione AWS
-
API per la gestione dei profili e dei lavori: tutte le API per la gestione dei profili e dei job di Data Transformation Agent sono disponibili come strumenti MCP, quindi puoi creare, modificare, pubblicare ed eseguire lavori da qualsiasi client. MCP-compatible
-
Qualsiasi client MCP: funziona con MCP-compatible IDE e assistenti, inclusi Kiro e Cursor.
-
Sessioni durature: supporta sessioni a più turni, quindi una conversazione di debug o di creazione è contestuale.
Nota
L'operazione di conversione di sincronizzazione (TransformData) e la convalida del codice sorgente (ValidateSource) sono REST-only e potrebbero non apparire come strumenti MCP. Il tuo agente può creare ed eseguire le chiamate REST per tuo conto: vedi Fase 3: Verifica con la conversione di sincronizzazione il formato della richiesta.
Poiché MCP condivide la stessa superficie API degli SDK AWS CLI e degli SDK per le operazioni relative ai profili e ai lavori, non vi è alcun divario di capacità per questi flussi di lavoro tra l'utilizzo dell'IDE e l'elaborazione del codice o del. Console di gestione AWS Consulta Guida introduttiva a MCP la configurazione e un esempio di flusso di lavoro.
