Considerazioni sull'utilizzo per Trasformazione di dati DICOM nelle soluzioni per dati sanitari
Nota
Questo contenuto è in fase di aggiornamento.
In questo articolo vengono descritte le considerazioni chiave da esaminare prima di utilizzare la funzionalità Trasformazione di dati DICOM. La comprensione di questi fattori garantisce un'integrazione e un funzionamento senza problemi nell'ambiente delle soluzioni per dati sanitari. Questa risorsa ti consente anche di esplorare in modo efficace alcune potenziali sfide e limitazioni relative alla funzionalità.
Dimensioni dei file per inserimento
Per la versione corrente della funzionalità Trasformazione di dati DICOM, esiste un limite di dimensione logica di 3 GB per i file ZIP e fino a 600 MB per i file DCM nativi. Se i file superano questi limiti, è possibile che i tempi di esecuzione siano più lunghi o che l'inserimento non riesca. Consigliamo di suddividere i file ZIP in segmenti più piccoli (meno di 3 GB) per garantire la corretta esecuzione. Per i file DCM nativi di dimensioni superiori a 600 MB, assicurati di aumentare i nodi Spark (esecutori) come necessario.
Estrazione di tag DICOM
Diamo la priorità alla promozione dei 30 tag presenti nella tabella delta dicomimagingmetastore del lakehouse Bronze per i seguenti due motivi:
- Questi 30 tag sono fondamentali per le query generali e l'esplorazione dei dati DICOM, come modalità e lateralità.
- Questi tag sono necessari per generare e popolare le tabelle delta dei lakehouse Silver (FHIR) e Gold (OMOP) nei passaggi di esecuzione successivi.
Puoi estendere e promuovere altri tag DICOM di tuo interesse. Tuttavia, i notebook di Trasformazione di dati DICOM non riconoscono né elaborano automaticamente altre colonne di tag DICOM aggiunte alla tabella delta dicomimagingmetastore nel lakehouse Bronze. Devi elaborare le colonne aggiuntive in modo indipendente.
Aggiungere il modello nel lakehouse Bronze
Tutti i file DCM (o ZIP) appena inseriti vengono aggiunti alla tabella delta dicomimagingmetastore nel lakehouse Bronze. Per ogni file DCM inserito correttamente, creiamo una nuova voce di record nella tabella delta dicomimagingmetastore. Non esiste alcuna logica di business per le operazioni di unione o aggiornamento a livello del lakehouse Bronze.
La tabella delta dicomimagingmetastore riflette ogni file DCM inserito a livello di istanza DICOM e deve essere considerata come tale. Se lo stesso file DCM viene nuovamente inserito nella cartella Ingest, aggiungiamo un'altra voce alla tabella delta dicomimagingmetastore per lo stesso file. Tuttavia, i nomi di file sono diversi a causa del timestamp del prefisso Unix. A seconda della data di inserimento, il file potrebbe trovarsi in una cartella yyyy/mm/dd diversa.
Estensioni per i dati di imaging e la versione OMOP
L'attuale implementazione del lakehouse Gold è basata su Common Data Model OMOP (Observational Medical Outcomes Partnership) versione 5.4. OMOP non dispone ancora di un'estensione normativa per supportare i dati di imaging. Pertanto, la funzionalità implementa l'estensione proposta in Sviluppo della standardizzazione dei dati di imaging medico per la ricerca osservativa basata sull'imaging: estensione di Common Data Model OMOP. Questa estensione è la proposta più recente nel campo della ricerca sull'imaging ed è stata pubblicata il 5 febbraio 2024. La versione corrente della funzionalità Trasformazione di dati DICOM è limitata alla tabella Image_Occurrence nel lakehouse Gold.
Streaming strutturato in Spark
Lo streaming strutturato è un motore di elaborazione dei flussi scalabile e a tolleranza di errore basato sul motore Spark SQL. Puoi esprimere il calcolo in streaming nello stesso modo in cui esprimeresti un calcolo batch su dati statici. Il sistema assicura garanzie di tolleranza di errore end-to-end tramite checkpoint e log write-ahead. Per ulteriori informazioni sullo streaming strutturato, vedi Guida alla programmazione dello streaming strutturato (v3.5.1).
Usiamo ForeachBatch per elaborare i dati incrementali. Questo metodo applica operazioni arbitrarie e scrive la logica nell'output di una query di streaming. La query viene eseguita sui dati di output di ogni microbatch di una query di streaming. Nella funzionalità Trasformazione di dati DICOM, lo streaming strutturato viene utilizzato nei seguenti passaggi di esecuzione:
| Passaggio di esecuzione | Posizione della cartella Checkpoint | Oggetti registrati |
|---|---|---|
| Estrarre metadati DICOM nel lakehouse Bronze | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_metadata_extraction |
File DCM nel lakehouse Bronze in Files\Process\Imaging\DICOM\yyyy\mm\dd. |
| Convertire i metadati DICOM nel formato FHIR | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_to_fhir |
Tabella delta dicomimagingmetastore nel lakehouse Bronze. |
| Inserire dati nella tabella delta ImagingStudy del lakehouse Bronze | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
File NDJSON FHIR nel lakehouse Bronze in Files\Process\Clinical\FHIR NDJSON\yyyy\mm\dd\ImagingStudy. |
| Inserire dati nella tabella delta ImagingStudy del lakehouse Silver | healthcare#.HealthDataManager\DMHCheckpoint\<silverlakehouse>\ImagingStudy |
Tabella delta ImagingStudy nel lakehouse Bronze. |
Suggerimento
Puoi utilizzare Esplora file di OneLake per visualizzare il contenuto di file e cartelle elencati nella tabella. Per altre informazioni, vedi Utilizzare Esplora file di OneLake.
Modello di raggruppamento nel lakehouse Bronze
I modelli di gruppo vengono applicati quando si inseriscono nuovi record dalla tabella delta dicomimagingmetastore nel lakehouse Bronze alla tabella delta ImagingStudy nel lakehouse Bronze. La funzionalità Trasformazione di dati DICOM raggruppa tutti i record a livello di istanza nella tabella delta dicomimagingmetastore in base al livello di studio. Crea un record per studio DICOM come ImagingStudy, quindi inserisce il record nella tabella delta ImagingStudy nel lakehouse Bronze.
Modello upsert nel lakehouse Silver
L'operazione upsert confronta le tabelle delta FHIR tra i lakehouse Bronze e Silver in base a {FHIRResource}.id
- Se viene identificata una corrispondenza, il record Silver viene aggiornato con il nuovo record Bronze.
- Se non viene identificata alcuna corrispondenza, il record Bronze viene inserito come nuovo record nel lakehouse Silver.
Limitazioni di ImagingStudy
L'operazione upsert funziona come previsto quando inserisci file DCM dallo stesso studio DICOM nella stessa esecuzione batch. Tuttavia, se in seguito inserisci più file DCM (da un batch diverso) che appartengono allo stesso studio DICOM precedentemente inserito nel lakehouse Silver, l'inserimento si traduce in un'operazione Insert. Il processo non esegue alcuna operazione Update.
Questa operazione Insert si verifica perché il notebook crea un nuovo {FHIRResource}.id per ImagingStudy in ogni esecuzione batch. Questo nuovo ID non corrisponde agli ID del batch precedente. Di conseguenza, nella tabella Silver vengono visualizzati due record ImagingStudy con valori ImagingStudy.id diversi. Questi ID sono correlati alle rispettive esecuzioni batch, ma appartengono allo stesso studio DICOM.
Per ovviare al problema, completa le esecuzioni batch e unisci i due record ImagingStudy nel lakehouse Silver in base a una combinazione di ID univoci. Tuttavia, non utilizzare ImagingStudy.id per l'unione. Usa invece altri ID, ad esempio [studyinstanceuid (0020,000D)] e [patientid (0010,0020)] per unire i record.
Approccio di rilevamento OMOP
Il notebook healthcare#_msft_silver_omop usa l'API OMOP per monitorare le modifiche nella tabella delta del lakehouse Silver. Identifica i record appena modificati o aggiunti che richiedono l'upserting nelle tabelle delta del lakehouse Gold. Questo processo è noto come Applicazione di filigrane.
L'API OMOP confronta i valori di data e ora tra {Silver.FHIRDeltatable.modified_date} e {Gold.OMOPDeltatable.SourceModifiedOn} per determinare i record incrementali che sono stati modificati o aggiunti dall'ultima esecuzione del notebook. Tuttavia, questo approccio di rilevamento OMOP non si applica a tutte le tabelle delta nel lakehouse Gold. Le tabelle seguenti non vengono inserite dalla tabella delta nel lakehouse Silver:
- concept
- concept_ancestor
- concept_class
- concept_relationship
- concept_synonym
- fhir_system_to_omop_vocab_mapping
- vocabulary
Queste tabelle delta Gold vengono popolate usando i dati del vocabolario inclusi nella distribuzione dei dati di esempio clinici. Il set di dati del vocabolario in questa cartella viene gestito usando lo streaming strutturato in Spark.
Puoi individuare i dati di esempio del vocabolario nel seguente percorso:
healthcare#.HealthDataManager\DMHSampleData\healthcare-sampledata\msft_dmh_omop_vocab_data
Modello upsert nel lakehouse Gold
Il modello upsert nel lakehouse Gold è diverso dal lakehouse Silver. L'API OMOP usata dal botebook healthcare#_msft_silver_omop crea nuovi ID per ogni voce nelle tabelle delta del lakehouse Gold. L'API crea questi ID quando inserisce o converte nuovi record dal lakehouse Silver a quello Gold. L'API OMOP gestisce anche mapping interni tra gli ID appena creati e gli ID interni i corrispondenti nella tabella delta del lakehouse Silver.
L'API funziona come segue:
Se si converte per la prima volta un record da una tabella delta Silver a una Gold, genera un nuovo ID nel lakehouse Gold OMOP e lo mappa al nuovo ID originale nel lakehouse Silver. Inserisce quindi il record nella tabella delta Gold con l'ID appena generato.
Se lo stesso record nel lakehouse Silver subisce qualche modifica e viene inserito di nuovo nel lakehouse Gold, l'API OMOP riconosce il record esistente nel lakehouse Gold (utilizzando le informazioni sul mapping). Aggiorna quindi i record nel lakehouse Gold con lo stesso ID generato in precedenza.
I mapping tra gli ID appena generati (ADRM_ID) nel lakehouse Gold e gli ID originali (INTERNAL_ID) per ogni tabella delta OMOP vengono archiviati nei file parquet di OneLake. Puoi trovare i file parquet nel seguente percorso di file:
[OneLakePath]\[workspace]\healthcare#.HealthDataManager\DMHCheckpoint\dtt\dtt_state_db\KEY_MAPPING\[OMOPTableName]_ID_MAPPING
Puoi anche eseguire una query sui file Parquet in un notebook Spark per visualizzare il mapping.
Integrazione con il servizio DICOM
L'integrazione corrente tra la funzionalità Trasformazione di dati DICOM e il servizio DICOM Servizi per i dati sanitari di Azure supporta solo gli eventi di creazione e aggiornamento. Ciò significa che puoi creare nuovi studi di imaging, serie e istanze, o anche aggiornare quelli esistenti. Tuttavia, l'integrazione non supporta ancora gli eventi di eliminazione . Se elimini uno studio, una serie o un'istanza nel servizio DICOM, la funzionalità Trasformazione di dati DICOM non riflette questa modifica. I dati di imaging rimangono invariati e non vengono eliminati.