Jak setki plików DICOM stają się jednym badaniem

Otrzymujesz folder o nazwie patient_2024_scan/, zawierający 1137 plików .dcm. Nie ma indeksu, manifestu ani „wolumenu”. Są tylko pliki. Nazwa folderu nie mówi, które obiekty tworzą jeden produkt obrazowy, który obiekt jest obrazem do planowania ani czy pliki można złożyć w prawidłowy wolumen. Pierwszym zadaniem nie jest więc konkatenacja plików, lecz ustalenie, co reprezentuje każdy obiekt i które relacje można bezpiecznie wywnioskować.

DICOM zapewnia do tego celu hierarchię organizacyjną. Model relacji między encjami Composite IOD, moduł General Study i moduł General Series pomagają rozdzielić obiekty należące do różnych pacjentów, zdarzeń obrazowania, Series i poszczególnych Instances, ale nie sprawiają, że każdy obiekt w obrębie Study jest jedną akwizycją, jedną siatką przestrzenną lub klinicznie wymiennym obrazem. Hierarchia jest konieczna do interpretacji folderu, lecz nadal nie wystarcza do skonstruowania obrazu.

Folder nie jest badaniem

W klasycznym eksporcie jednoklatkowego CT jeden przekrój może zostać dostarczony jako jeden plik, często obok kilku dodatkowych serii. Jest to częsty sposób pakowania, a nie uniwersalna definicja badania DICOM. Na podstawie samych nazw plików nie można ustalić, które pliki należą do siebie, które są przekrojami osiowymi, a które dwuwymiarowym obrazem lokalizacyjnym, ani w jakiej kolejności je ułożyć. DICOM rozwiązuje problem przynależności za pomocą czteropoziomowej hierarchii; problem kolejności pozostawia geometrii, rozwijanej w rozdziale o geometrii.

Cztery poziomy

Hierarchia opisuje zamierzoną relację zawierania, a nie obietnicę, że każda implementacja zapisuje jeden przekrój w jednym pliku. Uwidacznia też ważne rozróżnienie: dwa różne produkty rekonstrukcji mogą należeć do tego samego Study, pozostając odrębnymi Series, a każda Series może zawierać wiele Instances.

Poziomy warto rozumieć jako cztery powiązane pytania, ale są one roboczymi punktami odniesienia, a nie uniwersalnymi definicjami tego, czym musi być badanie, seria lub przekrój. Na poziomie Patient pytanie dotyczy tego, czyje dane są opisywane. PatientID identyfikuje pacjenta w obrębie jednostki nadającej identyfikator; przy uzgadnianiu rekordów między systemami właściwą parą źródłową jest PatientID wraz z IssuerOfPatientID, a nie sam łańcuch znaków traktowany jako mający znaczenie globalne.

Na poziomie Study pytanie brzmi, z którym zdarzeniem obrazowania powiązane są obiekty. Przydatnym opisem w tym przykładzie jest „CT klatki piersiowej z kontrastem, 2024-03-01”. Obiekty zawierają StudyInstanceUID oraz takie atrybuty jak StudyDate, StudyDescription i dane lekarza kierującego. Opis ten zapewnia kontekst organizacyjny; sam nie dowodzi, że wszystkie obiekty w Study mają wspólną akwizycję, rekonstrukcję, geometrię lub cel kliniczny.

Na poziomie Series pytanie dotyczy logicznej DICOM Series, do której należy obiekt. SeriesInstanceUID odróżnia tę Series od innej Series w tym samym Study; nie definiuje uniwersalnego strumienia akwizycji ani rekonstrukcji. Model informacyjny DICOM nie ustanawia też relacji jeden do jednego między Acquisition i Series: jedna Acquisition może dać wiele Series, a jedna Series może zawierać Instances z wielu Acquisitions. „Osiowa, 1,25 mm, kernel płucny” jest zatem przydatną etykietą roboczą w tym przykładzie, a nie definicją nadawaną przez UID. W procesie Series może zostać wybrana jako kandydat na produkt obrazowy, ale modalność, kernel, odstępy i orientacja są informacjami roboczymi, które trzeba sprawdzić, a nie obietnicą, że powiązane Series można połączyć.

Na poziomie Instance pytanie brzmi, który pojedynczy obiekt DICOM jest obsługiwany. W klasycznym jednoklatkowym sposobie pakowania CT, używanym w ograniczonym przykładzie RIDER i TRACE-CT, jedna SOP Instance jest jednym obiektem obrazu, zwykle reprezentowanym przez plik, i może odpowiadać jednemu przekrojowi; ma własne SOPInstanceUID, ImagePositionPatient i PixelData. Relacja ta jest właściwością tego przykładu pakowania, a nie uniwersalną regułą DICOM, ponieważ wieloklatkowa SOP Instance może zawierać wiele klatek.

Konkretny przykład folderu

Zastosuj ten model myślowy do folderu, nie zakładając, że jego pliki tworzą jeden wolumen. Grupowanie według StudyInstanceUID, a następnie w tym kontekście według SeriesInstanceUID, może ujawnić trzy serie w tym jawnie fikcyjnym przykładzie:

Seria	Pliki	Co przedstawia
Seria A	320 przekrojów × 1,25 mm, sharp lung kernel	cienkowarstwowy wolumen z kernelem płucnym
Seria B	80 przekrojów × 5,0 mm, standard/soft-tissue kernel	grubowarstwowy wolumen tkanek miękkich
Seria C	1 obraz, 2D	obraz lokalizacyjny (scout/localizer) — obraz do planowania, a nie przekrój osiowy

Trzeci wiersz pokazuje, dlaczego grupowanie nie jest tym samym co konstruowanie wolumenu. W tym procesie CT obraz, którego ImageType zawiera zdefiniowaną wartość LOCALIZER, jest traktowany jako obraz do planowania. Wartość ta nie definiuje uniwersalnego kształtu ani kompletnego filtra opartego na jednym tagu. Jest to w pełni prawidłowy obraz DICOM w tym samym Study, lecz konkatenacja każdej Instance w tym Study w jeden stos uszkodziłaby wolumen. Tę rolę planistyczną potwierdza opis LOCALIZER w module CT Image.

Proces wczytywania potrzebuje więc reguły wyboru zamierzonego produktu obrazowego. W ograniczonym procesie źródłowym ImageType, ConvolutionKernel i SliceThickness są sygnałami wyboru używanymi obok typu obiektu, SeriesInstanceUID i geometrii; nie stanowią normatywnej listy selektorów. Niezawodny wybór waliduje te relacje przed zachowaniem przekrojów osiowych wybranej Series. Mapa nauki TRACE-CT przedstawia przykład implementacyjny w load_ct_volume_explicit(), która odrzuca obrazy lokalizacyjne i waliduje regularność, zanim uzna stos za zdatny do użycia.

Dlaczego hierarchia jest konieczna, ale niewystarczająca

Hierarchia rozdzieliła produkty obrazowe, ale nie powiedziała, jak ułożyć Instances jednej Series w wolumen 3D. Decyzja ta zależy od atrybutów przestrzennych poszczególnych instancji, w tym:

• ImagePositionPatient (0020,0032) — współrzędnych (x, y, z) środka lewego górnego woksela w układzie współrzędnych pacjenta.
• ImageOrientationPatient (0020,0037) — cosinusów kierunkowych osi wiersza i kolumny.
• PixelSpacing (0028,0030) — odstępów wierszy i kolumn w płaszczyźnie obrazu.
• SliceThickness — nominalnej grubości przekroju; SpacingBetweenSlices, jeśli występuje, opisuje odległość między środkami. Nie są to wymienne wartości z.

Atrybuty przestrzenne definiuje moduł DICOM Image Plane, ale kolejność instancji jest właściwością geometryczną, a nie numerem porządkowym. Dla wybranego zbioru kandydatów rzut każdego położenia na wektor normalny przekroju może wyznaczyć kolejność dopiero po zwalidowaniu spójnej orientacji, wymiarów, PixelSpacing, skończonych ortonormalnych wektorów kierunkowych, unikalnych położeń i regularności. Sortowanie według InstanceNumber lub nazwy pliku jest jedynie pomocniczą kontrolą diagnostyczną. Konstrukcja i walidacja tej kolejności należą do podrozdziału o porządkowaniu przekrojów w rozdziale o geometrii, a nie do samej hierarchii.

Dlatego „DICOM Study” i „wolumen 3D” są różnymi pojęciami. Study jest jednostką organizacyjną; wolumen jest konstrukcją geometryczną, którą trzeba zbudować i zwalidować z Instances wybranych z Series. Traktowanie Series jako jednostki pracy procesu jest przydatną praktyką, a nie obietnicą, że każda Series jest regularnym wolumenem.

Klasyczny CT jednoklatkowy a Enhanced CT

Użyty wyżej skrót „jeden obiekt na jeden obraz” ogranicza się do klasycznego jednoklatkowego obiektu obrazu CT używanego w omawianym tu, ograniczonym procesie RIDER/TRACE-CT. Ten sposób pakowania nie jest uniwersalną regułą, a rekord kolekcji TCIA sam nie ustala, jak zapakowany jest każdy obiekt w kolekcji. Współczesny DICOM definiuje również Enhanced CT, czyli obiekt wieloklatkowy, w którym jedna SOP Instance zawiera wiele klatek, a każdą opisują makra grup funkcjonalnych dla poszczególnych klatek (ten sam mechanizm wykorzystuje DICOM SEG). Rozróżnienie sposobów pakowania jasno przedstawiają definicje CT Image IOD i Enhanced CT Image IOD. Nie kończ tego rozdziału z przekonaniem, że „DICOM CT zawsze oznacza jeden plik na jeden przekrój”.

Rozróżnienie ma znaczenie, gdy dwie kandydujące Series wyglądają podobnie. Załóżmy, że dwie Series mają identyczne StudyInstanceUID, ten sam PatientID, ten sam ConvolutionKernel i tę samą SliceThickness, ale różne SeriesInstanceUID. Mogą być dwoma eksportami lub rekonstrukcjami o tych samych parametrach albo jedną Series rozdzieloną między dwie akwizycje. Samo podobieństwo metadanych nie jest bezpieczną regułą łączenia. Geometria jest konieczna, ale niewystarczająca: odrębne Series można połączyć tylko wtedy, gdy proweniencja potwierdza, że są zamierzonymi składnikami jednego logicznego stosu, wspólny FrameOfReferenceUID lub inna jawna relacja przestrzenna uprawomocnia ten związek, a połączona geometria jest spójna. Geometria nadal wymaga zwalidowanej orientacji, wymiarów, odstępów w płaszczyźnie, unikalnych położeń i regularnych odległości między środkami. Bez tej proweniencji i relacji przestrzennej należy zachować Series oddzielnie, nawet jeśli ich położenia wydają się ciągłe. Jest to decyzja procesu, a nie uniwersalna reguła równoważności DICOM; odpowiednią granicę przestrzenną wyznacza moduł Frame of Reference.

Hierarchia jest więc kontraktem organizacyjnym, a nie dowodem równoważności przestrzennej lub klinicznej. Zdekodowane wartości pikseli z poprzedniego podrozdziału są już powiązane z konkretnym obiektem i Series, lecz sposób pakowania pozostawia kolejne pytanie o tożsamość: który UID identyfikuje sam obiekt i co odróżnia jego układ przestrzenny od przynależności organizacyjnej? Następny podrozdział śledzi te identyfikatory i różnicę między tożsamością obiektu a jego układem przestrzennym: identyfikatory, które spajają system.