Asocjacja DIMSE, zapis i pobieranie

Inżynier wychodzący od HTTP często oczekuje, że żądanie przyniesie odpowiedź tym samym połączeniem. Klasyczna komunikacja sieciowa DICOM ma inną postać. Obiekty przemieszczają się między jednostkami aplikacyjnymi DICOM za pośrednictwem usług DIMSE, a zanim da się zinterpretować dziennik, trzeba zrozumieć role, negocjację i miejsce docelowe operacji.

Asocjacje i jednostki aplikacyjne

Application Entity (AE) jest punktem końcowym uczestniczącym w komunikacji DICOM. Klasyczną AE identyfikuje się w konfiguracji DICOM przez AE Title wraz z sieciowym punktem końcowym, takim jak host i port, a nie przez adres URL HTTP. W jednej operacji AE może działać jako Service Class User (SCU), inicjując usługę, a w innej jako Service Class Provider (SCP), przyjmując ją i wykonując. PACS może więc przyjmować zapisywane obiekty jako SCP, a zarazem inicjować zapytania jako SCU.

Przed operacją oba systemy negocjują asocjację. Proponowane i akceptowane konteksty prezentacji opisują, których SOP Classes i Transfer Syntaxes można użyć w komunikacji. Tworzy to ważną granicę diagnostyczną: połączenie TCP może się udać, podczas gdy operacja DICOM nadal nie może zostać wykonana, ponieważ strony nie uzgodniły klasy obiektu lub sposobu kodowania. Odrzucenie kontekstu prezentacji jest błędem zgodności na poziomie aplikacji, a nie dowodem braku ścieżki sieciowej.

Operacje DIMSE

Najczęstsze usługi można skondensować do poniższego modelu myślowego. Jest to robocze słownictwo, a nie wyczerpująca lista usług DICOM ani poziomów zapytań.

Operacja	Znaczenie robocze	Typowa rola w przepływie pracy
C-STORE	Wyślij obiekt DICOM do SCP	Zapisz obraz lub obiekt pochodny.
C-FIND	Wyszukaj z użyciem kluczy dopasowania i zwracanych	Znajdź wpis listy roboczej albo pasujące badanie, serię lub instancję.
C-MOVE	Poproś źródłowy SCP o wysłanie dopasowań do wskazanej docelowej AE	Pobierz przez docelową usługę zapisu będącą stroną trzecią.
C-GET	Poproś źródłowy SCP o odesłanie dopasowań przez asocjację żądającą	Pobierz do strony żądającej, gdy usługa jest dostępna.
Modality Worklist	Interakcja zapytania o listę roboczą	Dostarcz urządzeniu obrazującemu zaplanowane informacje o pacjencie i procedurze.

W typowym wzorcu Query/Retrieve stacja robocza najpierw używa C-FIND z kluczami takimi jak PatientID, StudyInstanceUID, StudyDate lub Modality, aby uzyskać pasujące identyfikatory. Następnie używa C-MOVE albo C-GET do pobrania odpowiednich obiektów. Ten dwuetapowy wzorzec pomaga rozumować o systemie, lecz rzeczywista implementacja może wybrać inne poziomy zapytań, usługi pobierania i sposób orkiestracji.

C-MOVE jest operacją trójstronną

C-MOVE jest miejscem, w którym intuicja wyniesiona z HTTP najczęściej zawodzi. Strona żądająca wysyła żądanie C-MOVE do źródłowego SCP i wskazuje w nim docelową AE. Źródłowy SCP otwiera następnie oddzielną asocjację z tym miejscem docelowym i wykonuje tam podoperacje C-STORE. Proces, który zażądał przeniesienia, i proces, który otrzymuje obiekty, nie muszą zatem być tym samym procesem.

Taki układ pozwala lekkiemu klientowi nakazać archiwum dostarczenie badania bezpośrednio do przeglądarki, archiwum lub usługi zapisu. Tworzy też granicę konfiguracyjną, której nie ma w zwykłej odpowiedzi HTTP: miejsce docelowe musi być znane źródłu, osiągalne w sieci i zdolne do przyjmowania odpowiednich operacji C-STORE. Strona żądająca może skutecznie wysłać zapytanie i żądanie przeniesienia, a mimo to nie otrzymać żadnych obiektów lokalnie, jeśli wskazała inne miejsce docelowe albo nie uruchomiła SCP usługi Storage pod oczekiwaną AE.

Końcowa odpowiedź C-MOVE przekazuje wynik podoperacji wykonanych wobec wskazanego miejsca docelowego. Użyteczna interpretacja typowych ścieżek statusu jest następująca:

Status	Interpretacja żądania przeniesienia
0000	Podoperacje C-STORE do wskazanego miejsca docelowego zakończyły się bez zgłoszonych niepowodzeń.
B000	Podoperacje zakończyły się, ale zgłoszono co najmniej jedno niepowodzenie lub ostrzeżenie; sprawdź liczniki operacji ukończonych, nieudanych i zakończonych ostrzeżeniem.
A801	Move Destination jest nieznane źródłowemu SCP; tego miejsca docelowego nie można użyć do przeniesienia.
A701 lub A702	Ścieżka niepowodzenia związana z odmową albo niemożnością wykonania żądanej operacji, zależna od definicji usługi i kontekstu implementacji.
Cxxx	Zgłoszone przez implementację niepowodzenie przetwarzania, którego dokładne znaczenie zależy od właściwej specyfikacji usługi.

Tabela jest celowo ograniczona. Dokładną semantykę statusu oraz liczby podoperacji ukończonych, nieudanych i zakończonych ostrzeżeniem trzeba odczytywać względem właściwej specyfikacji usługi DICOM i dziennika implementacji. W szczególności 0000 nie oznacza, że skrypt wysyłający żądanie otrzymał bajty przez własną asocjację; oznacza, że żądane dostarczenie do wskazanego miejsca docelowego zakończyło się bez zgłoszonych niepowodzeń. A801 jest jawnym niepowodzeniem oznaczającym nieznane miejsce docelowe, a nie udanym transferem donikąd.

C-GET daje inny model myślowy, ponieważ obiekty są odsyłane przez asocjację żądającą. To, czy C-GET jest dostępne, włączone lub odpowiednie, zależy od implementacji i zasad. Wybór protokołu nie usuwa potrzeby sprawdzenia tożsamości obiektu, wynegocjowanych kontekstów prezentacji i odbierającego przepływu pracy.

Rozróżnienie strony żądającej i miejsca docelowego wyjaśnia też częste zgłoszenie awarii: „zapytanie się udało, ale mój skrypt niczego nie otrzymał”. Zapytanie mogło zwrócić poprawne identyfikatory, podczas gdy operacja przeniesienia dostarczyła obiekty do innej zarejestrowanej AE. Przed zmianą modelu lub zapytania należy sprawdzić żądane miejsce docelowe, jego mapowanie AE na punkt końcowy oraz zdolność do przyjmowania C-STORE.

Od DIMSE do DICOMweb

DIMSE pozostaje trwałym sposobem transportu w systemach obrazowania, ale klient webowy zwykle potrzebuje innego modelu interakcji. DICOMweb zapewnia usługi oparte na HTTP do wyszukiwania, pobierania i zapisywania obiektów oraz obsługi elementów pracy. Zachowuje świat obiektów DICOM, zmieniając transport i jego granice operacyjne.