Używanie zagadnień dotyczących użycia przekształcania danych DICOM w rozwiązaniach do obsługi danych medycznych
W tym artykule opisano najważniejsze zagadnienia, które należy omówić przed użyciem funkcji przekształcania danych DICOM. Zrozumienie tych czynników zapewnia bezproblemową integrację i działanie w środowisku rozwiązań do obsługi danych medycznych. Ten zasób pomaga również skutecznie poruszać się po niektórych potencjalnych wyzwaniach i ograniczeniach związanych z tą funkcją.
Rozmiar pliku pozyskiwania
Obecnie istnieje logiczny limit rozmiaru wynoszący 8 GB dla plików ZIP i do 4 GB dla natywnych plików DCM. Jeśli pliki przekraczają te limity, mogą wystąpić dłuższe czasy wykonywania lub nieudane pozyskiwanie. Zalecamy podzielenie plików ZIP na mniejsze segmenty (poniżej 4 GB), aby zapewnić pomyślne wykonanie. W przypadku natywnych plików DCM większych niż 4 GB upewnij się, że węzły (funkcje wykonawcze) Spark są skalowane w górę zgodnie z potrzebami.
Wyodrębnianie tagów DICOM
Priorytetem jest dla nas promocja 29 tagów obecnych w brązowej tabeli delta magazyn lakehouse ImagingDicom z następujących dwóch powodów:
- Te 29 znaczników ma kluczowe znaczenie dla ogólnego wykonywania zapytań i eksploracji danych DICOM, takich jak modalność i dosłowność.
- Te tagi są niezbędne do generowania i wypełniania srebrnych tabel delta (FHIR) i złotych (OMOP) w kolejnych krokach wykonywania.
Możesz rozszerzać i promować inne tagi DICOM, które Cię interesują. Jednak notesy przekształcania danych DICOM nie rozpoznają automatycznie ani nie przetwarzają żadnych innych kolumn tagów DICOM dodanych do tabeli różnicowej ImagingDicom w brązie magazyn lakehouse. Dodatkowe kolumny należy przetworzyć niezależnie.
Dołącz wzór w brązowym magazynie lakehouse
Wszystkie nowo pozyskane pliki DCM (lub ZIP) są dołączane do tabeli delta ImagingDicom w brązie magazyn lakehouse. Dla każdego pomyślnie pozyskanego pliku DCM tworzony jest nowy wpis rekordu w tabeli delta ImagingDicom . Nie ma logiki biznesowej dla operacji scalania lub aktualizowania na poziomie brązowego magazynu lakehouse.
Tabela różnicowa ImagingDicom odzwierciedla każdy pozyskany plik DCM na poziomie instancji DICOM i powinna być traktowana jako taka. Jeśli ten sam plik DCM zostanie ponownie pozyskany do folderu Ingest , dodamy kolejny wpis do tabeli delta ImagingDicom dla tego samego pliku. Jednak nazwy plików są różne ze względu na sygnaturę czasową prefiksu Unix. W zależności od daty pozyskania plik może zostać umieszczony w innym YYYY\MM\DD folderze.
Wersje i rozszerzenia obrazowania OMOP
Obecna implementacja złotego magazynu lakehouse opiera się na Observal Medical Outcomes Partnership (OMOP) Common Data Model w wersji 5.4. OMOP nie ma jeszcze normatywnego rozszerzenia do obsługi danych obrazowania. W związku z tym możliwość ta implementuje rozszerzenie zaproponowane w Rozwój standaryzacji danych obrazowania medycznego dla Imaging-Based Observational Research: rozszerzenie Common Data Model OMOP. To rozszerzenie jest najnowszą propozycją w dziedzinie badań obrazowych opublikowaną 5 lutego 2024 r. Bieżąca wersja funkcji przekształcania danych DICOM jest ograniczona do tabeli Image_Occurrence w złotym magazynie Lakehouse.
Przesyłanie strumieniowe ze strukturą na platformie Spark
Przesyłanie strumieniowe ze strukturą to skalowalny i odporny na uszkodzenia aparat przetwarzania strumieniowego oparty na aparacie Spark SQL. Obliczenia przesyłania strumieniowego można wyrazić w taki sam sposób, jak w przypadku obliczeń wsadowych na danych statycznych. System zapewnia kompleksowe gwarancje odporności na awarie dzięki punktom kontrolnym i dziennikom zapisu z wyprzedzeniem. Aby dowiedzieć się więcej na temat przesyłania strumieniowego ze strukturą, zobacz Przewodnik programowania przesyłania strumieniowego ze strukturą (wersja 3.5.1).
Używamy ForeachBatch do przetwarzania danych przyrostowych. Ta metoda stosuje dowolne operacje i zapisuje logikę w danych wyjściowych zapytania przesyłania strumieniowego. Zapytanie jest wykonywane na danych wyjściowych każdej mikropartii zapytania przesyłania strumieniowego. W funkcji przekształcania danych DICOM przesyłanie strumieniowe ze strukturą jest używane w następujących krokach wykonywania:
| Krok wykonywania | Punk kontrolny lokalizacji folderu | Śledzone obiekty |
|---|---|---|
| Wyodrębnianie metadanych DICOM do brązowego magazynu lakehouse | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_metadata_extraction |
DCM w brązie magazyn lakehouse poniżej Files\Process\Imaging\DICOM\YYYY\MM\DD. |
| Konwertowanie metadanych DICOM na format FHIR | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_to_fhir |
Tabela Delta ImagingDicom w brązie magazyn lakehouse. |
| Pozyskiwanie danych do tabeli delta ImagingStudy brązowego magazynu lakehouse | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
Pliki NDJSON FHIR w brązie magazyn lakehouse poniżej Files\Process\Clinical\FHIR NDJSON\YYYY\MM\DD\ImagingStudy. |
| Pozyskiwanie danych do tabeli delta ImagingStudy srebrnego magazynu lakehouse | healthcare#.HealthDataManager\DMHCheckpoint\<silverlakehouse>\ImagingStudy |
Tabela delta ImagingStudy brązowego magazynu lakehouse. |
Porada
Możesz użyć Eksploratora plików OneLake, aby wyświetlić zawartość plików i folderów wymienionych w tabeli. Aby uzyskać więcej informacji, zobacz Korzystanie z eksploratora plików OneLake.
Grupuj wzór w brązowym magazynie lakehouse
Wzorce grup mają zastosowanie podczas pozyskiwania nowych rekordów z tabeli delta ImagingDicom w brązie magazyn lakehouse do tabeli delta ImagingStudy w brązie magazyn lakehouse. Funkcja przekształcania danych DICOM grupuje wszystkie rekordy na poziomie instancji w tabeli delta ImagingDicom według poziomu badania. Tworzy jeden rekord na badanie DICOM jako ImagingStudy, a następnie wstawia rekord do tabeli delta ImagingStudy w brązowym magazynie lakehouse.
Wzór Upsert w srebrnym magazynie lakehouse
Operacja upsert porównuje tabele delta FHIR między brązowymi i srebrnymi magazynami lakehouse na podstawie {FHIRResource}.id:
- Jeśli zostanie zidentyfikowane dopasowanie, a srebrny rekord jest aktualizowany do nowego brązowego rekordu.
- Jeśli nie zostanie zidentyfikowane dopasowanie, brązowy rekord jest wstawiany jako nowy rekord w srebrnym magazynie lakehouse.
Używamy tego wzorca do tworzenia zasobów w srebrnej tabeli magazyn lakehouse ImagingStudy .
Ograniczenia ImagingStudy
Operacja upsert działa zgodnie z oczekiwaniami w przypadku pozyskiwania plików DCM z tego samego badania DICOM w tym samym wykonaniu wsadowym. Jeśli jednak później pozyskasz więcej plików DCM (z innej partii), które należą do tego samego badania DICOM, które zostało wcześniej pozyskane do srebrnego magazyn lakehouse, pozyskanie spowoduje operację wstawiania . Proces nie wykonuje operacji aktualizacji .
Ta operacja wstawiania jest wykonywana, ponieważ notes tworzy nowy {FHIRResource}.id element dla ImagingStudy w każdym wykonaniu wsadowym. Ten nowy identyfikator nie jest zgodny z identyfikatorami w poprzedniej partii. W rezultacie w srebrnej tabeli zostaną wyświetlone dwa rekordy ImagingStudy z różnymi wartościami ImagingStudy.id. Te identyfikatory są powiązane z odpowiednimi wykonaniami partii, ale należą do tego samego badania DICOM.
Aby obejść ten problem, ukończ wykonania wsadowe i scal dwa rekordy ImagingStudy w srebrnym magazynie lakehouse na podstawie kombinacji unikatowych identyfikatorów. Nie należy jednak używać ImagingStudy.id do scalania. Zamiast tego można użyć innych identyfikatorów, takich jak [studyInstanceUid (0020,000D)] i [patientId (0010,0020)] , aby scalić rekordy.
Podejście do śledzenia OMOP
Notes healthcare#_msft_omop_silver_gold_transformation używa OMOP interfejsu API do monitorowania zmian w srebrnej magazyn lakehouse tabeli delta. Identyfikuje nowo zmodyfikowane lub dodane rekordy, które wymagają wykonania upsert do tabel delta złotego magazynu lakehouse. Ten proces jest nazywany Oznaczaniem znakiem wodnym.
Interfejs API OMOP porównuje wartości daty i godziny między {Silver.FHIRDeltatable.modified_date} i {Gold.OMOPDeltatable.SourceModifiedOn} w celu określenia rekordów przyrostowych, które zostały zmodyfikowane lub dodane od ostatniego wykonania notesu. Jednak to podejście do śledzenia OMOP nie ma zastosowania do wszystkich tabel delta w złotym magazynie lakehouse. Następujące tabele nie są pozyskiwane z tabeli delta w srebrnym magazynie lakehouse:
- pojęcie
- concept_ancestor
- concept_class
- concept_relationship
- concept_synonym
- fhir_system_to_omop_vocab_mapping
- słownictwo
Te złote tabele delta są wypełniane przy użyciu danych słownictwa zawartych w przykładowym OMOP wdrożeniu danych. Zestaw danych słownictwa w tym folderze jest zarządzany przy użyciu Przesyłania strumieniowego ze strukturą na platformie Spark.
Wzór Upsert w złotym magazynie lakehouse
Wzór upsert w złotym magazynie lakehouse różni się od wzoru w srebrnym magazynie lakehouse. Interfejs OMOP API używany przez notes healthcare#_msft_omop_silver_gold_transformation tworzy nowe identyfikatory dla każdego wpisu w tabelach delta złotego magazyn lakehouse. Interfejs API tworzy te identyfikatory podczas pozyskiwania lub konwertowania nowych rekordów ze srebrnego na złoty magazyn lakehouse. Interfejs API OMOP obsługuje również mapowania wewnętrzne między nowo utworzonymi identyfikatorami i odpowiadającymi im identyfikatorami wewnętrznymi w tabeli delta srebrnego magazynu lakehouse.
Interfejs API działa następująco:
Jeśli konwertujesz rekord ze srebrnej na złotą tabelę delta po raz pierwszy, generuje nowy identyfikator w złotym magazynie lakehouse OMOP i mapuje go na oryginalny nowy identyfikator w srebrnym magazynie lakehouse. Następnie wstawia rekord do złotej tabeli delta z nowo wygenerowanym identyfikatorem.
Jeśli ten sam rekord w srebrnym magazynie lakehouse zostanie poddany pewnym modyfikacjom i zostanie ponownie pozyskany do złotego magazynu lakehouse, interfejs API OMOP rozpozna istniejący rekord w złotym magazynie lakehouse (przy użyciu informacji mapowania). Następnie aktualizuje rekordy w złotym magazynie lakehouse przy użyciu tego samego identyfikatora, który został wygenerowany wcześniej.
Mapowania między nowo wygenerowanymi identyfikatorami (ADRM_ID) w złotym magazynie lakehouse i oryginalnymi identyfikatorami (INTERNAL_ID) dla każdej tabeli delta OMOP są przechowywane w plikach parquet usługi OneLake. Pliki parquet można znaleźć w następującej ścieżce:
[OneLakePath]\[workspace]\healthcare#.HealthDataManager\DMHCheckpoint\dtt\dtt_state_db\KEY_MAPPING\[OMOPTableName]_ID_MAPPING
Możesz również wykonać zapytanie dotyczące plików parquet w notesie platformy Spark, aby wyświetlić mapowanie.
ObrazowanieProjekt Metastore w kolorze srebrnym magazyn lakehouse
Pojedynczy plik DICOM może zawierać do 5 000 różnych tagów, co sprawia, że mapowanie i tworzenie pól dla wszystkich tych znaczników w srebrnym magazyn lakehouse jest nieefektywne i wymaga dużej ilości zasobów. Jednak zachowanie dostępu do pełnego zestawu tagów jest niezbędne, aby zapobiec utracie danych i zachować elastyczność, zwłaszcza jeśli potrzebujesz tagów poza 29 wyodrębnionymi i reprezentowanymi w modelu danych. Aby rozwiązać ten problem, srebrna tabela delta magazyn lakehouse ImagingMetastore przechowuje wszystkie tagi DICOM w kolumnie metadata_string . Te tagi są reprezentowane jako pary klucz-wartość w ciągowym formacie JSON, co umożliwia wydajne wykonywanie zapytań za pośrednictwem punkt końcowy analizy SQL. Takie podejście jest zgodne ze standardowymi praktykami zarządzania złożonymi danymi JSON we wszystkich polach w warstwie Silver magazyn lakehouse.
Od tabeli ImagingDicom w brązie magazyn lakehouse do tabeli ImagingMetastore w srebrnej magazyn lakehouse, transformacja nie wykonuje żadnego grupowania. Zasoby są reprezentowane na poziomie wystąpienia w obu tabelach. Jest jednak uwzględniony {FHIRResource}.id w tabeli ImagingMetastore . Ta wartość umożliwia wykonywanie zapytań dotyczących wszystkich artefaktów na poziomie instancji skojarzonych z określonym badaniem poprzez odwoływanie się do jego unikalnego identyfikatora.
Integracja z usługą DICOM
Bieżąca integracja między funkcją przekształcania danych DICOM a usługą DICOM Azure Health Data Services obsługuje tylko zdarzenia Tworzenia i Aktualizowania. Można tworzyć nowe badania obrazowe, serie i instancje, a nawet aktualizować istniejące. Jednak integracja nie obsługuje jeszcze zdarzeń usuwania . Jeśli usuniesz badanie, serię lub wystąpienie w usłudze DICOM, możliwość przekształcania danych DICOM nie odzwierciedla tej zmiany. Dane obrazowania pozostaną niezmienione i nie zostaną usunięte.
Ostrzeżenia dotyczące tabeli
Ostrzeżenia są wyświetlane dla wszystkich tabel w każdej magazyn lakehouse w których co najmniej jedna kolumna używa złożonych typów danych zorientowanych obiektowo do reprezentowania danych. W tabelach ImagingDicom i ImagingMetastore kolumna metadata_string używa struktury JSON do mapowania tagów DICOM jako par klucz-wartość. Ten projekt uwzględnia ograniczenie punktów końcowych sieci szkieletowej SQL, które nie obsługują złożonych typów danych, takich jak struktury, tablice i mapy. Możesz wykonywać zapytania dotyczące tych kolumn jako ciągów przy użyciu SQL punkt końcowy (T-SQL) lub pracować z ich typami natywnymi (strukturami, tablicami, mapami) przy użyciu platformy Spark.
