Användningsöverväganden för DICOM-dataomvandling i vårddatalösningar
Den här artikeln beskriver viktiga överväganden att granska innan du använder funktionen DICOM-dataomvandling. Genom att förstå dessa faktorer säkerställer du smidig integrering och drift i din miljö för vårddatalösningar. Den här resursen hjälper dig också att effektivt navigera i vissa potentiella utmaningar och begränsningar med funktionen.
Filstorlek för inmatning
För närvarande finns det Dit en logisk storleksgräns på 8 GB för ZIP-filer och upp till 4 GB för interna DCM-filer. Om filerna överskrider dessa gränser kan det ta längre tid att köra eller att inmatningen misslyckas. Vi rekommenderar att du delar upp ZIP-filerna i mindre segment (under 4 GB) för att säkerställa en lyckad körning. För interna DCM-filer som är större än 4 GB ska du se till att du skalar upp Spark-noderna (utförare) efter behov.
Extrahering av DICOM-tagg
Vi prioriterar att marknadsföra de 29 taggar som finns i brons sjöhus ImagingDicom deltatabellen av följande två skäl:
- Dessa 29 taggar är avgörande för allmänna frågor och utforskning av DICOM-data, till exempel modalitet och lateralitet.
- Dessa taggar är nödvändiga för att generera och fylla i deltatabellerna silver (FHIR) och guld (OMOP) i efterföljande körningssteg.
Du kan utöka och höja upp andra DICOM-taggar som du är intresserad av. DICOM-datatransformeringsanteckningsböckerna känner dock inte automatiskt igen eller bearbetar några andra kolumner med DICOM-taggar som du lägger till i ImagingDicom-deltatabellen i brons sjöhus. Du måste bearbeta de extra kolumnerna oberoende av varandra.
Lägg till mönster i bronssjöhuset
Alla nyligen inmatade DCM-filer (eller ZIP-filer) läggs till i deltatabellen ImagingDicom i brons sjöhus. För varje inmatad DCM-fil skapar vi en ny postpost i deltatabellen ImagingDicom . Det finns ingen affärslogik för sammanslagnings- eller uppdateringsåtgärder på bronssjöhusnivå.
Deltatabellen ImagingDicom återspeglar varje inmatad DCM-fil på DICOM-instansnivå och bör betraktas som sådan. Om samma DCM-fil matas in igen i inmatningsmappen lägger vi till ytterligare en post i deltatabellen ImagingDicom för samma fil. Filnamnen skiljer sig emellertid åt på grund av tidsstämpeln för Unix-prefixet. Beroende på inmatningsdatumet kan filen placeras i en annan YYYY\MM\DD mapp.
OMOP version och bildtillägg
Den nuvarande implementeringen av guldsjöhuset är baserad på Observational Medical Outcomes Partnership (OMOP) Common Data Model version 5.4. OMOP har ännu inget normativt tillägg för att stödja bilddata. Därför implementerar funktionen det tillägg som föreslås i Development of Medical Imaging Data Standardization for Imaging-Based Observational Research: OMOP Common Data Model Extension. Denna förlängning är det senaste förslaget inom bildforskningsområdet som publicerades den 5 februari 2024. Den aktuella versionen av funktionen för DICOM-dataomvandling är begränsad till tabellen Image_Occurrence i guldsjöhuset.
Strukturerad direktuppspelning i Spark
Strukturerad direktuppspelning är en skalbar och feltolerant direktuppspelningsmotor som bygger på Spark SQL-motorn. Du kan uttrycka din direktuppspelningsberäkning på samma sätt som du uttrycker en batchberäkning på statiska data. Systemet säkerställer garantier för feltolerans från slutpunkt till slutpunkt via kontrollpunkter och Write-Ahead-loggar. Mer information om strukturerad direktuppspelning finns i Programmeringsguide för strukturerad direktuppspelning (v3.5.1).
Vi använder ForeachBatch för att bearbeta inkrementella data. Den här metoden tillämpar godtyckliga åtgärder och skriver logiken på utdata från en strömmande fråga. Frågan körs på utdata för varje mikrobatch i en strömmande fråga. I funktionen DICOM-dataomvandling används strukturerad direktuppspelning i följande körningssteg:
| Körningssteg | Mappplats för kontrollpunkt | Spårade objekt |
|---|---|---|
| Extrahera DICOM-metadata till bronssjöhuset | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_metadata_extraction |
DCM-filer i brons sjöhus under Files\Process\Imaging\DICOM\YYYY\MM\DD. |
| Konvertera DICOM-metadata till FHIR-formatet | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_to_fhir |
Delta-tabellen ImagingDicom i brons sjöhus. |
| Mata in data i deltatabellen ImagingStudy i bronssjöhuset | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
FHIR NDJSON-filer i brons sjöhus under Files\Process\Clinical\FHIR NDJSON\YYYY\MM\DD\ImagingStudy. |
| Mata in data i deltatabellen ImagingStudy i silversjöhuset | healthcare#.HealthDataManager\DMHCheckpoint\<silverlakehouse>\ImagingStudy |
Deltatabell ImagingStudy i bronssjöhuset. |
Tips!
Du kan använda OneLake utforskaren för att visa innehållet i filerna och mapparna som listas i tabellen. Mer information finns i Använda OneLake-utforskaren.
Gruppmönster i bronssjöhuset
Gruppmönster gäller när du matar in nya poster från ImagingDicom-deltatabellen i brons sjöhus till ImagingStudy delta-tabellen i brons sjöhus. DICOM-datatransformeringsfunktionen grupperar alla poster på instansnivå i ImagingDicom-deltatabellen efter studienivå. Den skapar en post per DICOM-studie som en ImagingStudy och infogar sedan posten i deltatabellen ImagingStudy i bronssjöhuset.
Upsert-mönster i silversjöhuset
upsert-åtgärden jämför FHIR-deltatabellerna mellan brons- och silversjöhusen baserat på {FHIRResource}.id:
- Om en match identifieras uppdateras silverrekordet med det nya bronsposten.
- Om det inte finns någon matchning identifierad infogas bronsposten som en ny post i silversjöhuset.
Vi använder det här mönstret för att skapa resurser i den silvriga sjöhus ImagingStudy-tabellen .
ImagingStudy-begränsningar
Upsert-operationen fungerar som förväntat när du matar in DCM-filer från samma DICOM-studie i samma batchkörning. Men om du senare importerar fler DCM-filer (från en annan batch) som tillhör samma DICOM-studie som tidigare importerats till silver sjöhus, resulterar inmatningen i en Insert-åtgärd . Processen utför ingen uppdateringsåtgärd .
Den här Insert-åtgärden inträffar eftersom notebook-filen skapar en ny {FHIRResource}.id för ImagingStudy i varje batchkörning. Det nya ID:t matchar inte ID:n i föregående batch. Det innebär att du ser två poster för ImagingStudy i silvertabellen med olika ImagingStudy.id-värden. Dessa ID:n är relaterade till deras respektive batchkörningar men tillhör samma DICOM-studie.
Som en tillfällig lösning slutför du batchkörningarna och sammanfogar de två posterna för ImagingStudy i silversjöhuset baserat på en kombination av unika ID:n. Använd emellertid inte ImagingStudy.id för sammanslagningen. I stället kan du använda andra ID:n, till exempel [studyInstanceUid (0020,000D)] och [patientId (0010,0020)] för att sammanfoga posterna.
OMOP spårningsmetod
Notebook-filen healthcare#_msft_omop_silver_gold_transformation använder API:et OMOP för att övervaka ändringar i den silverfärgade sjöhus deltatabellen. Den identifierar nyss modifierade eller tillagda poster som behöver uppdateras eller infogas i deltatabellerna i guldsjöhuset. Den här processen kallas för vattenstämpling.
OMOP API:et jämför datum- och tidsvärdena mellan {Silver.FHIRDeltatable.modified_date} och {Gold.OMOPDeltatable.SourceModifiedOn} för att fastställa de inkrementella poster som har ändrats eller lagts till sedan den senaste notebook-körningen. Den här OMOP spårningsmetoden gäller dock inte för alla deltatabeller i guldsjöhus. Följande tabeller matas inte in från deltatabellen i silversjöhus:
- koncept
- concept_ancestor
- concept_class
- concept_relationship
- concept_synonym
- fhir_system_to_omop_vocab_mapping
- vokabulär
Dessa gulddeltatabeller fylls i med hjälp av vokabulärdata som ingår i exempeldatadistributionen OMOP . Vokabulärdatauppsättningen i den här mappen hanteras med hjälp av Strukturerad direktuppspelning i Spark.
Upsert-mönster i guldsjöhuset
Upsert-mönstret i guldsjöhuset skiljer sig från silversjöhuset. API OMOP :et som används av notebook-filen healthcare#_msft_omop_silver_gold_transformation skapar nya ID:n för varje post i deltatabellerna i guld sjöhus. API:et skapar dessa ID:n när det matar in eller konverterar nya poster från silver till guldsjöhus. API:et OMOP underhåller även interna mappningar mellan de nyligen skapade ID:erna och deras motsvarande interna ID:n i deltatabellen silversjöhus.
API fungerar enligt följande:
Om du konverterar en post från en silver- till gulddeltatabell för första gången genereras ett nytt ID i OMOP guldsjöhuset och mappas till det ursprungliga nya ID:t i silversjöhuset. Den infogar sedan posten i gulddeltatabellen med det nyligen genererade ID:t.
Om samma post i silversjöhuset genomgår någon ändring och matas in igen i gold lakehouse, identifierar API:et OMOP den befintliga posten i guldsjöhus (med hjälp av mappningsinformationen). Den uppdaterar sedan posterna i guldsjöhus med samma ID som den genererade tidigare.
Mappningar mellan de nyligen genererade ID:erna (ADRM_ID) i guldsjöhus och de ursprungliga ID:na (INTERNAL_ID) för varje OMOP deltatabell lagras i OneLake parquet-filer. Du kan hitta parquet-filerna på följande filsökväg:
[OneLakePath]\[workspace]\healthcare#.HealthDataManager\DMHCheckpoint\dtt\dtt_state_db\KEY_MAPPING\[OMOPTableName]_ID_MAPPING
Du kan också fråga parquet-filerna i en Spark notebook-fil för att visa mappningen.
ImagingMetastore design i silver sjöhus
En enda DICOM-fil kan innehålla upp till 5 000 olika taggar, vilket gör det ineffektivt och resurskrävande att mappa och skapa fält för alla dessa taggar i silversjöhus. Det är dock viktigt att behålla åtkomsten till den fullständiga uppsättningen taggar för att förhindra dataförlust och upprätthålla flexibiliteten, särskilt om du behöver taggar utöver de 29 som extraheras och representeras i datamodellen. För att lösa det här problemet lagrar den silverfärgade sjöhus ImagingMetastore-deltatabellen alla DICOM-taggar i kolumnen metadata_string . Dessa taggar representeras som nyckel/värde-par i ett strängifierat JSON-format, vilket möjliggör effektiva frågor via analys-slutpunkt SQL. Den här metoden överensstämmer med standardmetoderna för att hantera komplexa JSON-data i alla fält i silver sjöhus.
Från tabellen ImagingDicom i brons sjöhus till tabellen ImagingMetastore i silver sjöhus utför omvandlingen ingen gruppering. Resurser representeras på instansnivå i båda tabellerna. {FHIRResource}.id ingår dock i tabellen ImagingMetastore . Med det här värdet kan du fråga alla artefakter på instansnivå som är associerade med en specifik studie genom att referera till dess unika ID.
Integrering med DICOM-tjänst
Den nuvarande integrationen mellan funktionen DICOM-dataomvandling och Azure Health Data Services DICOM-tjänsten stöder endast Skapa och Uppdatera. Du kan skapa nya avbildningsstudier, serier och instanser, eller till och med uppdatera befintliga. Integreringen har dock ännu inte stöd för borttagningshändelser . Om du tar bort en studie, serie eller instans i DICOM-tjänsten återspeglar inte funktionen DICOM-dataomvandling den här ändringen. Bilddata förblir oförändrade och tas inte bort.
Varningar för tabeller
Varningar visas för alla tabeller i varje sjöhus där en eller flera kolumner använder komplexa objektorienterade datatyper för att representera data. I tabellerna ImagingDicom och ImagingMetastore använder kolumnen metadata_string en JSON-struktur för att mappa DICOM-taggar som nyckel/värde-par. Den här designen hanterar begränsningen för Fabric SQL-slutpunkter, som inte stöder komplexa datatyper som strukturer, matriser och kartor. Du kan fråga dessa kolumner som strängar med hjälp av SQL slutpunkt (T-SQL) eller arbeta med deras interna typer (structs, matriser, kartor) med hjälp av Spark.
