Überlegungen zur Nutzung für DICOM-Datentransformation in Datenlösungen für das Gesundheitswesen
In diesem Artikel werden die wichtigsten Überlegungen beschrieben, die Sie berücksichtigen sollten, bevor Sie die DICOM-Datentransformationsfunktion verwenden. Das Verständnis dieser Faktoren gewährleistet eine reibungslose Integration und einen reibungslosen Betrieb innerhalb Ihrer Datenlösungsumgebung für das Gesundheitswesen. Diese Ressource hilft Ihnen auch, einige potenzielle Herausforderungen und Einschränkungen mit der Funktion effektiv zu meistern.
Größe der Erfassungsdatei
Derzeit gibt es eine logische Größenbeschränkung von 8 GB für ZIP-Dateien und bis zu 4 GB für native DCM-Dateien. Wenn Ihre Dateien diese Grenzwerte überschreiten, kann es zu längeren Ausführungszeiten oder fehlgeschlagenen Aufnahmen kommen. Wir empfehlen, die ZIP-Dateien in kleinere Segmente (unter 4 GB) aufzuteilen, um eine erfolgreiche Ausführung zu gewährleisten. Stellen Sie bei nativen DCM-Dateien, die größer als 4 GB sind, sicher, dass Sie die Spark-Knoten (Executors) nach Bedarf hochskalieren.
Extraktion von DICOM-Tags
Wir legen aus den folgenden zwei Gründen Wert auf die Förderung der 29 Tags in der bronzenen Lakehouse ImagingDicom Delta-Tabelle :
- Diese 29 Tags sind entscheidend für die allgemeine Abfrage und Untersuchung von DICOM-Daten, wie z. B. Modalität und Lateralität.
- Diese Tags sind erforderlich, um die Delta-Tabellen Silver (FHIR) und Gold (OMOP) in nachfolgenden Ausführungsschritten zu generieren und aufzufüllen.
Sie können andere DICOM-Tags, die Sie interessieren, erweitern und bewerben. Die DICOM-Datentransformations-Notebooks erkennen oder verarbeiten jedoch nicht automatisch andere Spalten mit DICOM-Tags, die Sie der ImagingDicom Delta-Tabelle im Bronze-Format Lakehouse hinzufügen. Sie müssen die zusätzlichen Spalten unabhängig voneinander verarbeiten.
Anfügemuster im Bronze-Lakehouse
Alle neu aufgenommenen DCM- (oder ZIP-)Dateien werden an die ImagingDicom Delta-Tabelle im bronzenen Lakehouse angehängt. Für jede erfolgreich aufgenommene DCM-Datei erstellen wir einen neuen Datensatzeintrag in der ImagingDicom Delta-Tabelle. Es gibt keine Geschäftslogik für Zusammenführungs- oder Aktualisierungsvorgänge auf der Bronze-Lakehouse-Ebene.
Die ImagingDicom Deltatabelle spiegelt jede aufgenommene DCM-Datei auf der DICOM-Instanzebene wider und sollte als solche betrachtet werden. Wenn dieselbe DCM-Datei erneut in den Ordner Ingest aufgenommen wird, fügen wir der Delta-Tabelle ImagingDicom einen weiteren Eintrag für dieselbe Datei hinzu. Die Dateinamen unterscheiden sich jedoch aufgrund des Unix-Präfix-Zeitstempels. Abhängig vom Aufnahmedatum kann die Datei in einem anderen YYYY\MM\DD Ordner abgelegt werden.
OMOP-Version und Imaging-Erweiterungen
Die derzeitige Implementierung des Gold-Lakehouse basiert auf dem Observal Medical Outcomes Partnership (OMOP) Common Data Model Version 5.4. OMOP verfügt noch nicht über eine normative Erweiterung zur Unterstützung von Bilddaten. Daher implementiert die Funktion die Erweiterung, die in Development of Medical Imaging Data Standardization for Imaging-Based Observational Research: OMOP Common Data Model Extension vorgeschlagen wurde. Diese Erweiterung ist der jüngste Vorschlag im Bereich der Bildgebungsforschung, der am 5. Februar 2024 veröffentlicht wurde. Die aktuelle Version der DICOM-Datentransformationsfunktion ist auf die Tabelle Image_Occurrence im Gold-Lakehouse beschränkt.
Strukturiertes Streaming in Spark
Strukturiertes Streaming ist eine skalierbare und fehlertolerante Streamverarbeitungs-Engine, die auf der Spark SQL-Engine basiert. Sie können Ihre Streamingberechnung auf die gleiche Weise ausdrücken wie eine Batchberechnung für statische Daten. Das System gewährleistet durch Prüfpunkte und Write-Ahead-Protokolle eine durchgängige Fehlertoleranz. Weitere Informationen zum strukturierten Streaming finden Sie im Programmhandbuch für strukturiertes Streaming (v3.5.1).
Wir verwenden ForeachBatch, um die inkrementellen Daten zu verarbeiten. Diese Methode wendet beliebige Vorgänge an und schreibt die Logik in die Ausgabe einer Streamingabfrage. Die Abfrage wird für die Ausgabedaten jedes Mikrobatches einer Streamingabfrage ausgeführt. In der DICOM-Datentransformationsfunktion wird strukturiertes Streaming in den folgenden Ausführungsschritten verwendet:
| Ausführungsschritt | Speicherort des Prüfpunktordners | Verfolgte Objekte |
|---|---|---|
| DICOM-Metadaten in das Bronze-Lakehouse extrahieren | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_metadata_extraction |
DCM-Dateien im bronzenen Lakehouse unter Files\Process\Imaging\DICOM\YYYY\MM\DD. |
| DICOM-Metadaten in das FHIR-Format konvertieren | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_to_fhir |
Delta-Tisch ImagingDicom in der Bronzefarbe Lakehouse. |
| Daten in die ImagingStudy-Delta-Tabelle des Bronze-Lakehouse aufnehmen | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
FHIR NDJSON-Dateien im bronzenen Lakehouse unter Files\Process\Clinical\FHIR NDJSON\YYYY\MM\DD\ImagingStudy. |
| Daten in die ImagingStudy-Delta-Tabelle des Silver-Lakehouse aufnehmen | healthcare#.HealthDataManager\DMHCheckpoint\<silverlakehouse>\ImagingStudy |
Delta-Tabelle ImagingStudy im Bronze-Lakehouse. |
Trinkgeld
Sie können den OneLake-Datei-Explorer verwenden, um den Inhalt der in der Tabelle aufgeführten Dateien und Ordner anzuzeigen. Weitere Informationen finden Sie unter OneLake-Datei-Explorer verwenden.
Gruppenmuster im Bronze-Lakehouse
Gruppenmuster werden angewendet, wenn Sie neue Datensätze aus der ImagingDicom Deltatabelle im bronzenen Lakehouse in die ImagingStudy Deltatabelle im bronzenen Lakehouse übernehmen. Die DICOM-Datentransformationsfunktion gruppiert alle Datensätze auf Instanzebene in der ImagingDicom Deltatabelle nach Studienebene. Sie erstellt einen Datensatz pro DICOM-Untersuchung als ImagingStudy und fügt den Datensatz dann in die ImagingStudy-Delta-Tabelle im Bronzene-Lakehouse ein.
Upsert-Muster im Silver-Lakehouse
Der Upsert Vorgang vergleicht die FHIR-Deltatabellen zwischen den Bronze- und Silber-Lakehouses basierend auf {FHIRResource}.id:
- Wenn eine Übereinstimmung festgestellt wird, wird der Silver-Datensatz mit dem neuen Bronze-Datensatz aktualisiert.
- Wenn keine Übereinstimmung gefunden wird, wird der Bronze-Datensatz als neuer Datensatz in das Silver-Lakehouse eingefügt.
Wir verwenden dieses Muster, um Ressourcen in der silbernen Tabelle Lakehouse ImagingStudy zu erstellen.
ImagingStudy-Einschränkungen
Der Upsert-Vorgang funktioniert wie erwartet, wenn Sie DCM-Dateien aus derselben DICOM-Studie in derselben Batchausführung erfassen. Wenn Sie jedoch später weitere DCM-Dateien (aus einem anderen Stapel) aufnehmen, die zu derselben DICOM-Studie gehören, die zuvor in das silberne Lakehouse aufgenommen wurde, führt die Aufnahme zu einem Einfügevorgang . Der Vorgang führt keinen Aktualisierungsvorgang aus.
Dieser Einfügevorgang erfolgt, weil das Notebook bei jeder Batch-Ausführung ein neues {FHIRResource}.id Objekt für ImagingStudy erstellt. Diese neue ID stimmt nicht mit IDs im vorherigen Batch überein. Als Ergebnis sehen Sie in der Silver-Tabelle zwei ImagingStudy-Datensätze mit unterschiedlichen ImagingStudy.id-Werten. Diese IDs beziehen sich auf die jeweiligen Batchausführungen, gehören aber zur selben DICOM-Untersuchung.
Um dieses Problem zu umgehen, schließen Sie die Batchausführungen ab, und führen Sie die beiden ImagingStudy-Datensätze im Silver-Lakehouse basierend auf einer Kombination eindeutiger IDs zusammen. Verwenden Sie ImagingStudy.id jedoch nicht für die Zusammenführung. Stattdessen können Sie andere IDs wie [studyInstanceUid (0020,000D)] und [patientId (0010,0020)] verwenden, um die Datensätze zusammenzuführen.
Ansatz zur OMOP-Verfolgung
Das healthcare#_msft_omop_silver_Gold_transformation Notebook verwendet die OMOP API, um Änderungen in der Deltatabelle „Silber“ Lakehouse zu überwachen. Es identifiziert neu geänderte oder hinzugefügte Datensätze, die ein Upserting in die Gold-Lakehouse-Delta-Tabellen erfordern. Dieser Prozess wird als Watermarking bezeichnet.
Die OMOP-API vergleicht die Datums- und Uhrzeitwerte zwischen {Silver.FHIRDeltatable.modified_date} und {Gold.OMOPDeltatable.SourceModifiedOn}, um die inkrementellen Datensätze zu ermitteln, die seit der letzten Notebook-Ausführung geändert oder hinzugefügt wurden. Dieser Ansatz zur OMOP-Verfolgung gilt jedoch nicht für alle Delta-Tabellen im Gold-Lakehouse. Die folgenden Tabellen werden nicht aus der Delta-Tabelle im Silver-Lakehouse übernommen:
- concept
- concept_ancestor
- concept_class
- concept_relationship
- concept_synonym
- fhir_system_to_omop_vocab_mapping
- vocabulary
Diese Gold-Delta-Tabellen werden mithilfe der Vokabulardaten gefüllt, die in der OMOP Beispieldatenbereitstellung enthalten sind. Das Vokabular-Dataset in diesem Ordner wird mithilfe des strukturierten Streamings in Spark verwaltet.
Upsert-Muster im Gold-Lakehouse
Das Upsert-Muster im Gold-Lakehouse unterscheidet sich vom Silver-Lakehouse. Die vom Notebook OMOP healthcare#_msft_omop_silver_Gold_transformation verwendete API erstellt für jeden Eintrag in den Deltatabellen des Goldes Lakehouse neue IDs. Die API erstellt diese IDs, wenn sie neue Datensätze vom Siver-Lakehouse in das Gold-Lakehouse aufnimmt oder konvertiert. Die OMOP-API verwaltet auch interne Zuordnungen zwischen den neu erstellten IDs und den entsprechenden internen IDs in der Silver-Lakehouse-Delta-Tabelle.
Die API funktioniert wie folgt:
Wenn ein Datensatz zum ersten Mal von einer Silver- in eine Gold-Delta-Tabelle konvertiert wird, wird eine neue ID im OMOP-Gold-Lakehouse generiert und der ursprünglichen neuen ID im Silver-Lakehouse zugeordnet. Anschließend wird der Datensatz mit der neu generierten ID in die Gold-Delta-Tabelle eingefügt.
Wenn derselbe Datensatz im Silver-Lakehouse geändert und erneut in das Gold-Lakehouse aufgenommen wird, erkennt die OMOP-API den vorhandenen Datensatz im Gold-Lakehouse (anhand der Zuordnungsinformationen). Anschließend werden die Datensätze im Gold-Lakehouse mit der gleichen ID aktualisiert, die zuvor generiert wurde.
Zuordnungen zwischen den neu generierten IDs (ADRM_ID) im Gold-Lakehouse und den ursprünglichen IDs (INTERNAL_ID) für jede OMOP-Delta-Tabelle werden in OneLake-Parquet-Dateien gespeichert. Sie können die Parquet-Dateien unter folgendem Dateipfad finden:
[OneLakePath]\[workspace]\healthcare#.HealthDataManager\DMHCheckpoint\dtt\dtt_state_db\KEY_MAPPING\[OMOPTableName]_ID_MAPPING
Sie können auch die Parquet-Dateien in einem Spark-Notebook abfragen, um die Zuordnung anzuzeigen.
ImagingMetastore-Design in Silber Lakehouse
Eine einzelne DICOM-Datei kann bis zu 5.000 verschiedene Tags enthalten. Das Zuordnen und Erstellen von Feldern für alle diese Tags im silbernen Lakehouse ist daher ineffizient und ressourcenintensiv. Allerdings ist es wichtig, den Zugriff auf den vollständigen Tag-Satz beizubehalten, um Datenverlust zu vermeiden und die Flexibilität zu wahren, insbesondere, wenn Sie mehr als die 29 extrahierten und im Datenmodell dargestellten Tags benötigen. Um dieses Problem zu beheben, speichert die silberne Delta-Tabelle Lakehouse ImagingMetastore alle DICOM-Tags in der Spalte metadata_string . Diese Tags werden als Schlüssel-Wert-Paare in einem Zeichenfolgen-JSON-Format dargestellt, was effiziente Abfragen durch die SQL-Analyse Endpunkt ermöglicht. Dieser Ansatz entspricht den Standardverfahren zur Verwaltung komplexer JSON-Daten in allen Feldern im silbernen Lakehouse.
Von der ImagingDicom Tabelle im bronzenen Lakehouse zur ImagingMetastore Tabelle im silbernen Lakehouse führt die Transformation keine Gruppierung durch. Ressourcen werden in beiden Tabellen auf Instanzebene dargestellt. Es ist jedoch in der Tabelle {FHIRResource}.id ImagingMetastore enthalten. Mit diesem Wert können Sie alle Artefakte auf Instanzebene abfragen, die mit einer bestimmten Studie verknüpft sind, indem Sie auf ihre eindeutige ID verweisen.
Integration mit DICOM-Dienst
Die derzeitige Integration zwischen der DICOM-Datentransformationsfunktion und dem Azure Health Data Services-DICOM-Dienst unterstützt nur Erstellungs- und Aktualisierungsereignisse . Sie können neue Bildgebungsstudien, -serien und -instanzen erstellen oder sogar vorhandene aktualisieren. Die Integration unterstützt jedoch noch keine Lösch Ereignisse. Wenn Sie eine Untersuchung, eine Serie oder eine Instanz im DICOM-Dienst löschen, spiegelt die DICOM-Datentransformationsfunktion diese Änderung nicht wider. Die Bilddaten bleiben unverändert und werden nicht gelöscht.
Tabellenwarnungen
Warnungen werden für alle Tabellen in jedem Lakehouse angezeigt, in denen eine oder mehrere Spalten komplexe objektorientierte Datentypen zur Darstellung von Daten verwenden. In den Tabellen ImagingDicom und ImagingMetastore verwendet die Spalte metadata_string eine JSON-Struktur, um DICOM-Tags als Schlüssel-Wert-Paare zuzuordnen. Dieses Design berücksichtigt die Einschränkung der Fabric-Endpunkte SQL, die keine komplexen Datentypen wie Strukturen, Arrays und Maps unterstützen. Sie können diese Spalten mit SQL Endpunkt (T-SQL) als Zeichenfolgen abfragen oder mit Spark mit ihren nativen Typen (Strukturen, Arrays, Maps) arbeiten.
