Gebruiksoverwegingen voor DICOM-gegevenstransformatie in oplossingen voor gezondheidszorggegevens
In dit artikel worden de belangrijkste aandachtspunten beschreven die u moet overwegen voordat u de mogelijkheid voor DICOM-gegevenstransformatie gebruikt. Als u deze factoren begrijpt, kunt u de integratie en het gebruik binnen uw omgeving met oplossingen voor gezondheidszorggegevens soepel laten verlopen. Deze bron helpt u ook om effectief om te gaan met mogelijke uitdagingen en beperkingen van de functionaliteit.
Bestandsgrootte voor opname
Momenteel geldt er een logische limiet voor de bestandsgrootte van 8 GB voor ZIP-bestanden en tot 4 GB voor native DCM-bestanden. Als uw bestanden deze limieten overschrijden, kunnen uitvoeringen langer duren of kan de opname mislukken. Wij adviseren om de zipbestanden op te splitsen in kleinere segmenten (kleiner dan 4 GB) om een succesvolle uitvoering te garanderen. Voor native DCM-bestanden die groter zijn dan 4 GB, moet u ervoor zorgen dat u de Spark-knooppunten (executors) indien nodig opschaalt.
Extractie van DICOM-tag
We geven prioriteit aan het promoten van de 29 tags die aanwezig zijn in de bronzen lakehouse ImagingDicom delta-tabel om de volgende twee redenen:
- Deze 29 tags zijn cruciaal voor algemene query's in en de verkenning van DICOM-gegevens, zoals modaliteit en lateraliteit.
- Deze tags zijn nodig voor het genereren en vullen van de zilveren (FHIR) en gouden (OMOP) deltatabellen in volgende uitvoeringsstappen.
U kunt andere DICOM-tags waarin u geïnteresseerd bent, uitbreiden en promoten. De notitieboeken voor DICOM-gegevenstransformatie herkennen of verwerken echter niet automatisch andere kolommen met DICOM-tags die u toevoegt aan de ImagingDicom delta-tabel in de bronzen lakehouse. U moet de extra kolommen onafhankelijk verwerken.
Patroon toevoegen in het bronzen lakehouse
Alle nieuw opgenomen DCM- (of ZIP-) bestanden worden toegevoegd aan de ImagingDicom delta-tabel in de bronzen lakehouse. Voor elk succesvol opgenomen DCM-bestand maken we een nieuw recorditem in de ImagingDicom delta-tabel. Er is geen bedrijfslogica voor samenvoegings- of updatebewerkingen op het niveau van het bronzen lakehouse.
De ImagingDicom delta-tabel weerspiegelt elk opgenomen DCM-bestand op DICOM-instantieniveau en moet als zodanig worden beschouwd. Als hetzelfde DCM-bestand opnieuw wordt opgenomen in de map Ingest , voegen we een extra vermelding toe aan de deltatabel ImagingDicom voor hetzelfde bestand. De bestandsnamen verschillen echter vanwege het Unix-prefixtijdstempel. Afhankelijk van de datum van opname, kan het bestand in een andere map worden geplaatst. YYYY\MM\DD
OMOP-versie en beeldvormingsextensies
De huidige implementatie van het gouden lakehouse is gebaseerd op Common Data Model-versie 5.4 voor Observational Medical Outcomes Partnership (OMOP). OMOP heeft nog geen normatieve extensie ter ondersteuning van beeldvormingsgegevens. Derhalve wordt de extensie geïmplementeerd die wordt voorgesteld in Development of Medical Imaging Data Standardization for Imaging-Based Observational Research: OMOP Common Data Model Extension. Deze uitbreiding is het meest recente voorstel op het gebied van beeldvormingsonderzoek, gepubliceerd op 5 februari 2024. De huidige versie van de mogelijkheid voor DICOM-gegevenstransformatie is beperkt tot de tabel Image_Occurrence in het golden lakehouse.
Gestructureerde streaming in Spark
Gestructureerde streaming is een schaalbare en fouttolerante engine voor het verwerken van streams die is gebaseerd op de Spark SQL-engine. U kunt uw streamingberekening op dezelfde manier uitdrukken als een batchberekening op statische gegevens. Het systeem garandeert end-to-end fouttolerantiegaranties via controlepunten en Write-Ahead-logs. Raadpleeg voor meer informatie over gestructureerde streaming de handleiding over het programmeren van gestructureerde streaming (v3.5.1).
Wij gebruiken ForeachBatch om de incrementele gegevens te verwerken. Deze methode past willekeurige bewerkingen toe en schrijft de logica naar de uitvoer van een streamingquery. De query wordt uitgevoerd op de uitvoergegevens van elke microbatch van een streamingquery. In de mogelijkheid voor DICOM-gegevenstransformatie wordt gestructureerde streaming gebruikt in de volgende uitvoeringsstappen:
| Uitvoeringsstap | Maplocatie controlepunt | Gevolgde objecten |
|---|---|---|
| Extraheren van DICOM-metagegevens in het bronzen lakehouse | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_metadata_extraction |
DCM-bestanden in de bronzen lakehouse onder Files\Process\Imaging\DICOM\YYYY\MM\DD. |
| DICOM-metagegevens converteren naar de FHIR-indeling | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_to_fhir |
Delta tabel ImagingDicom in het brons lakehouse. |
| Gegevens opnemen in de deltatabel ImagingStudy in het bronzen lakehouse | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
FHIR NDJSON-bestanden in de bronzen lakehouse onder Files\Process\Clinical\FHIR NDJSON\YYYY\MM\DD\ImagingStudy. |
| Gegevens opnemen in de deltatabel ImagingStudy in het zilveren lakehouse | healthcare#.HealthDataManager\DMHCheckpoint\<silverlakehouse>\ImagingStudy |
Deltatabel ImagingStudy in het bronzen lakehouse. |
Fooi
U kunt de OneLake-bestandsverkenner gebruiken om de inhoud van de bestanden en mappen in de tabel te bekijken. Zie OneLake-bestandsverkenner gebruiken voor meer informatie.
Groepspatroon in het bronzen lakehouse
Groepspatronen zijn van toepassing wanneer u nieuwe records opneemt uit de ImagingDicom deltatabel in de bronzen lakehouse naar de ImagingStudy deltatabel in de bronzen lakehouse. Met de DICOM-gegevenstransformatiefunctie worden alle records op instantieniveau in de ImagingDicom delta-tabel gegroepeerd op studieniveau. Er wordt één record per DICOM-studie gemaakt als een ImagingStudy en vervolgens wordt de record ingevoegd in de deltatabel ImagingStudy in het bronzen lakehouse.
Upsert-patroon in het zilveren lakehouse
De upsert bewerking vergelijkt de FHIR-deltabellen tussen de bronzen en zilveren lakehouses op basis van de {FHIRResource}.id:
- Als er een match wordt gevonden, wordt de zilveren record bijgewerkt met de nieuwe bronzen record.
- Als er geen match wordt gevonden, wordt de bronzen record als nieuwe record in het zilveren lakehouse geplaatst.
We gebruiken dit patroon om bronnen te maken in de zilveren tabel lakehouse ImagingStudy .
Beperkingen van ImagingStudy
De bewerking upsert werkt zoals verwacht wanneer u DCM-bestanden uit dezelfde DICOM-studie in dezelfde batchuitvoering opneemt. Als u echter later meer DCM-bestanden (uit een andere batch) opneemt die behoren tot dezelfde DICOM-studie die eerder is opgenomen in de zilveren lakehouse, resulteert de opname in een Insert -bewerking. Het proces voert geen Update bewerking uit.
Deze Insert bewerking vindt plaats omdat het notitieboek bij elke batch-uitvoering een nieuwe {FHIRResource}.id voor ImagingStudy maakt. Deze nieuwe id komt niet overeen met de id's in de vorige batch. Als resultaat ziet u twee ImagingStudy-records met verschillende ImagingStudy.id-waarden in de zilveren tabel. Deze id's zijn gerelateerd aan hun respectievelijke batchuitvoeringen, maar behoren tot dezelfde DICOM-studie.
U kunt dit probleem omzeilen door de batchuitvoeringen te voltooien en de twee ImagingStudy-records in het zilveren lakehouse samen te voegen op basis van een combinatie van unieke id's. Gebruik echter niet ImagingStudy.id voor de samenvoeging. In plaats daarvan kunt u andere ID's gebruiken, zoals [studyInstanceUid (0020,000D)] en [patientId (0010,0020)] om de records samen te voegen.
Benadering voor het traceren van OMOP
De healthcare#_msft_omop_silver_gold_transformation notebook gebruikt de OMOP API om wijzigingen in de zilveren lakehouse deltatabel te bewaken. Hiermee worden onlangs gewijzigde of toegevoegde records geïdentificeerd die moeten worden geüpsert in de deltatabellen van het gouden lakehouse. Dit proces wordt watermerken genoemd.
De OMOP-API vergelijkt de datum- en tijdwaarden tussen {Silver.FHIRDeltatable.modified_date} en {Gold.OMOPDeltatable.SourceModifiedOn} om te bepalen welke incrementele records zijn gewijzigd of toegevoegd sinds de laatste uitvoering van het notebook. Deze benadering voor het traceren van OMOP is echter niet van toepassing op alle deltatabellen in het gouden lakehouse. De volgende tabellen worden niet vanuit de deltatabel in het zilveren lakehouse opgenomen:
- concept
- concept_ancestor
- concept_class
- concept_relationship
- concept_synonym
- fhir_system_to_omop_vocab_mapping
- vocabulaire
Deze gouden deltatabellen worden gevuld met behulp van de vocabulairegegevens die zijn opgenomen in de OMOP implementatie van voorbeeldgegevens. De gegevensset voor vocabulaire in deze map wordt beheerd met behulp van gestructureerde streaming in Spark.
Upsert-patroon in het gouden lakehouse
Het upsert-patroon in het gouden lakehouse verschilt van het patroon in het zilveren lakehouse. De OMOP API die wordt gebruikt door de healthcare#_msft_omop_silver_gold_transformation notebook, maakt nieuwe ID's voor elk item in de deltatabellen van de gold lakehouse. De API maakt deze id's wanneer nieuwe records vanuit het zilveren worden opgenomen in of geconverteerd naar het gouden lakehouse. De OMOP-API onderhoudt ook interne toewijzingen tussen de nieuwe id's en hun bijbehorende interne id's in de deltatabel van het zilveren lakehouse.
De API werkt als volgt:
Als u voor het eerst een record van een zilveren naar een gouden deltatabel converteert, wordt er een nieuwe id gegenereerd in het gouden OMOP-lakehouse en wordt deze toegewezen aan de oorspronkelijke nieuwe id in het zilveren lakehouse. Vervolgens wordt de record met de nieuwe gegenereerde id ingevoegd in de gouden deltatabel.
Als dezelfde record in het zilveren lakehouse wordt gewijzigd en opnieuw in het gouden lakehouse wordt opgenomen, herkent de OMOP-API de bestaande record in het gouden lakehouse (met behulp van de toewijzingsinformatie). Vervolgens worden de reords in het gouden lakehouse bijgewerkt met dezelfde id die eerder is gegenereerd.
Toewijzingen tussen de nieuw gegenereerde id's (ADRM_ID) in het gouden lakehouse en de originele id's (INTERNAL_ID) voor elke OMOP-deltatabel worden opgeslagen in OneLake-parquet-bestanden. U vindt de parquet-bestanden via het volgende bestandspad:
[OneLakePath]\[workspace]\healthcare#.HealthDataManager\DMHCheckpoint\dtt\dtt_state_db\KEY_MAPPING\[OMOPTableName]_ID_MAPPING
U kunt ook query's uitvoeren op de parquet-bestanden in een Spark-notebook om de toewijzing te bekijken.
ImagingMetastore-ontwerp in het zilver lakehouse
Eén DICOM-bestand kan maximaal 5.000 verschillende tags bevatten. Het toewijzen en maken van velden voor al deze tags in de zilveren versie van lakehouse is daardoor inefficiënt en arbeidsintensief. Het is echter essentieel om toegang te houden tot de volledige set tags om gegevensverlies te voorkomen en flexibiliteit te behouden, vooral als u meer tags nodig hebt dan de 29 die in het datamodel zijn geëxtraheerd en weergegeven. Om dit probleem aan te pakken, slaat de zilveren lakehouse ImagingMetastore delta-tabel alle DICOM-tags op in de metadata_string kolom. Deze tags worden weergegeven als sleutel-waardeparen in een string-JSON-formaat, waardoor efficiënte query's via de SQL-analyse eindpunt mogelijk zijn. Deze aanpak komt overeen met standaardprocedures voor het beheren van complexe JSON-gegevens in alle velden in de zilveren lakehouse.
Van de ImagingDicom tabel in de bronzen lakehouse naar de ImagingMetastore tabel in de zilveren lakehouse voert de transformatie geen groepering uit. In beide tabellen worden bronnen op instantieniveau weergegeven. De {FHIRResource}.id is echter opgenomen in de ImagingMetastore tabel. Met deze waarde kunt u alle artefacten op instantieniveau opvragen die aan een specifieke studie zijn gekoppeld door te verwijzen naar de unieke ID ervan.
Integratie met DICOM-service
De huidige integratie tussen de functie voor DICOM-gegevenstransformatie en de Azure Health Data Services DICOM-service ondersteunt alleen de gebeurtenissen Maken en Bijwerken. U kunt nieuwe beeldstudies, series en instanties maken en bestaande studies, series en instanties bijwerken. De integratie ondersteunt echter nog geen Verwijder gebeurtenissen. Als u een studie, serie of instantie in de DICOM-service verwijdert, wordt deze wijziging niet doorgevoerd in de DICOM-gegevenstransformatiefunctie. De beeldvormingsgegevens blijven ongewijzigd en worden niet verwijderd.
Tabelwaarschuwingen
Er verschijnen waarschuwingen voor alle tabellen in elke lakehouse waarin een of meer kolommen complexe objectgeoriënteerde gegevenstypen gebruiken om gegevens weer te geven. In de tabellen ImagingDicom en ImagingMetastore gebruikt de kolom metadata_string een JSON-structuur om DICOM-tags toe te wijzen als sleutel-waardeparen. Dit ontwerp houdt rekening met de beperking van Fabric SQL-eindpunten, die geen complexe gegevenstypen zoals structs, arrays en maps ondersteunen. U kunt deze kolommen als strings opvragen met behulp van SQL eindpunt (T-SQL) of met hun oorspronkelijke typen (structs, arrays, maps) werken met behulp van Spark.
