Considerazioni sull'utilizzo per Trasformazione di dati DICOM nelle soluzioni per dati sanitari
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
Attualmente, esiste un limite logico di dimensione pari a 8 GB per i file ZIP e fino a 4 GB 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 4 GB) per garantire la corretta esecuzione. Per i file DCM nativi di dimensioni superiori a 4 GB, assicurarsi di aumentare le dimensioni dei nodi Spark (esecutori) in base alle necessità.
Estrazione di tag DICOM
Diamo priorità alla promozione dei 29 tag presenti nella tabella bronze lakehouse ImagingDicom delta per i due motivi seguenti:
- Questi 29 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 dei dati DICOM non riconoscono né elaborano automaticamente altre colonne di tag DICOM aggiunte alla tabella ImagingDicom delta nel file bronze lakehouse. Devi elaborare le colonne aggiuntive in modo indipendente.
Aggiungere il modello nel lakehouse Bronze
Tutti i file DCM (o ZIP) appena acquisiti vengono aggiunti alla tabella delta ImagingDicom nel file bronze lakehouse. Per ogni file DCM acquisito correttamente, creiamo una nuova voce di record nella tabella delta ImagingDicom . Non esiste alcuna logica di business per le operazioni di unione o aggiornamento a livello del lakehouse Bronze.
La tabella delta ImagingDicom riflette ogni file DCM acquisito a livello di istanza DICOM e dovrebbe essere considerata come tale. Se lo stesso file DCM viene nuovamente inserito nella cartella Ingest , aggiungiamo un'altra voce alla tabella delta ImagingDicom 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 essere inserito in una cartella diversa. YYYY\MM\DD
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, 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 garantisce la tolleranza agli errori end-to-end tramite checkpoint e registri 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 bronzo lakehouse sotto Files\Process\Imaging\DICOM\YYYY\MM\DD. |
| Convertire i metadati DICOM nel formato FHIR | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_to_fhir |
Tabella Delta ImagingDicom nel bronzo lakehouse. |
| Inserire dati nella tabella delta ImagingStudy del lakehouse Bronze | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
File FHIR NDJSON nel bronzo lakehouse sotto 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 si applicano quando si ingeriscono nuovi record dalla tabella delta ImagingDicom nel bronzo lakehouse alla tabella delta ImagingStudy nel bronzo lakehouse. La capacità di trasformazione dei dati DICOM raggruppa tutti i record a livello di istanza nella tabella delta ImagingDicom 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 le case sul lago bronzo e argento 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.
Utilizziamo questo schema per creare risorse nella tabella lakehouse ImagingStudy argento.
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 si ingeriscono altri file DCM (da un batch diverso) che appartengono allo stesso studio DICOM precedentemente ingerito nel file lakehouse silver, l'ingestione genera un'operazione Inserisci . Il processo non esegue un'operazione di aggiornamento .
Questa operazione Inserisci 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. In alternativa, è possibile utilizzare altri ID come [studyInstanceUid (0020,000D)] e [patientId (0010,0020)] per unire i record.
Approccio di rilevamento OMOP
Il notebook healthcare#_msft_omop_silver_gold_transformation utilizza l'API OMOP per monitorare le modifiche nella tabella delta 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 dell'oro vengono popolate utilizzando i dati del vocabolario inclusi nella distribuzione dei dati campione. OMOP Il set di dati del vocabolario in questa cartella viene gestito usando lo streaming strutturato in Spark.
Modello upsert nel lakehouse Gold
Il modello upsert nel lakehouse Gold è diverso dal lakehouse Silver. L' OMOP API utilizzata dal notebook healthcare#_msft_omop_silver_gold_transformation crea nuovi ID per ogni voce nelle tabelle delta dell'oro lakehouse. 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.
Design ImagingMetastore in argento lakehouse
Un singolo file DICOM può contenere fino a 5.000 tag distinti, rendendo inefficiente e dispendioso in termini di risorse mappare e creare campi per tutti questi tag nel file silver lakehouse. Tuttavia, mantenere l'accesso al set completo di tag è essenziale per prevenire la perdita di dati e mantenere la flessibilità, soprattutto se sono necessari tag oltre ai 29 estratti e rappresentati nel modello di dati. Per risolvere questo problema, la tabella delta lakehouse ImagingMetastore silver memorizza tutti i tag DICOM nella colonna metadata_string . Questi tag sono rappresentati come coppie chiave-valore in un formato JSON stringato, consentendo query efficienti tramite l'analisi SQL endpoint. Questo approccio è in linea con le pratiche standard per la gestione di dati JSON complessi in tutti i campi nel file silver lakehouse.
Dalla tabella ImagingDicom nel lakehouse bronzo alla tabella ImagingMetastore nel lakehouse argento, la trasformazione non esegue alcun raggruppamento. Le risorse sono rappresentate a livello di istanza in entrambe le tabelle. Tuttavia, {FHIRResource}.id è incluso nella tabella ImagingMetastore . Questo valore consente di interrogare tutti gli artefatti a livello di istanza associati a uno studio specifico facendo riferimento al suo ID univoco.
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. È possibile creare nuovi studi di imaging, serie e istanze, oppure aggiornare quelli esistenti. Tuttavia, l'integrazione non supporta ancora gli eventi Delete . 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.
Avvertenze sulla tabella
Gli avvisi vengono visualizzati per tutte le tabelle in ogni lakehouse in cui una o più colonne utilizzano tipi di dati complessi orientati agli oggetti per rappresentare i dati. Nelle tabelle ImagingDicom e ImagingMetastore , la colonna metadata_string utilizza una struttura JSON per mappare i tag DICOM come coppie chiave-valore. Questa progettazione tiene conto della limitazione degli endpoint Fabric SQL, che non supportano tipi di dati complessi quali strutture, array e mappe. È possibile interrogare queste colonne come stringhe utilizzando SQL endpoint (T-SQL) oppure lavorare con i loro tipi nativi (strutture, array, mappe) utilizzando Spark.
