Docelowa strona trzecia w C-MOVE

C-MOVE warto omówić oddzielnie, ponieważ zmienia znaczenie udanego pobrania. W interakcji HTTP klient zwykle otrzymuje żądaną reprezentację od serwera, z którym się skontaktował. W interakcji C-MOVE strona żądająca prosi źródłowy SCP o dostarczenie pasujących obiektów do oddzielnie wskazanej docelowej AE. Źródło komunikuje się następnie z tym miejscem docelowym przez nową asocjację i używa C-STORE.

W operacji uczestniczą zatem trzy strony:

1. żądający SCU, który identyfikuje obiekty i wskazuje miejsce docelowe;
2. źródłowy SCP, który wykonuje operację przeniesienia i przekazuje jej status;
3. docelowa AE, która odbiera obiekty za pomocą C-STORE.

Piksele płyną ze źródła do miejsca docelowego, niekoniecznie z powrotem do procesu wysyłającego żądanie. Jest to zwarty model myślowy operacji, a nie twierdzenie, że każdy produkt udostępnia taki sam interfejs użytkownika lub topologię wdrożenia.

Odczytuj status końcowy w kontekście

Źródłowy SCP może wysyłać odpowiedzi oczekujące podczas wykonywania podoperacji. Odpowiedź końcową zwraca po zakończeniu działań C-STORE wobec wskazanego miejsca docelowego. W używanym tutaj słownictwie statusów 0000 oznacza zakończenie bez zgłoszonych niepowodzeń, natomiast B000 oznacza, że podoperacje zakończyły się z co najmniej jednym niepowodzeniem lub ostrzeżeniem. A801 wskazuje nieznane miejsce docelowe operacji przeniesienia. A701 oznacza, że SCP nie mógł obliczyć liczby dopasowań, A702 oznacza, że nie mógł wykonać podoperacji, a Cxxx oznacza niemożność przetworzenia żądania, której dokładne znaczenie wynika z definicji usługi. Liczniki operacji ukończonych, nieudanych i zakończonych ostrzeżeniem pozostają częścią interpretacji.

Rozróżnienie to ma znaczenie operacyjne. Jeśli docelowa AE jest nieznana, źródło nie może rozpocząć żądanego dostarczenia i zgłasza niepowodzenie. Jeśli miejsce docelowe jest znane, lecz niedostępne albo nie może przyjąć obiektu, niepowodzenie znajduje odzwierciedlenie w ścieżce ostrzeżenia lub błędu, zamiast zostać po cichu zamienione w udaną odpowiedź lokalną. Rzeczywisty 0000 nadal mówi jedynie, że wskazane miejsce docelowe przyjęło podoperacje bez zgłoszonych niepowodzeń. Nie mówi, że skrypt wysyłający żądanie był miejscem docelowym, że określona przeglądarka wyświetliła obiekty ani że późniejszy użytkownik mógł je pobrać.

Dlatego „sukces, ale nic nie dotarło do mojego skryptu” może oznaczać rozbieżność oczekiwań. Skrypt mógł nie być docelową AE, mógł nie uruchamiać SCP usługi Storage albo mógł wskazać miejsce docelowe, którego proces odbierający różnił się od obserwowanego procesu. Prawidłowa diagnostyka zaczyna się od miejsca docelowego w żądaniu C-MOVE i podąża za oddzielną asocjacją C-STORE.

C-GET jest, jeśli implementacja je obsługuje, kontrastującą operacją pobierania z udziałem dwóch stron: źródło odsyła obiekty przez asocjację żądającą. Eliminuje to oddzielną konfigurację miejsca docelowego, ale dostępność i przydatność tej usługi nadal zależą od konkretnej implementacji DICOM i zasad lokalnych. Żadna z usług nie usuwa potrzeby sprawdzenia, czego zażądano, dokąd to wysłano i czy odbiorca może z tego skorzystać.

Przykład C-MOVE odsłania ogólną lekcję informatyczną. Status odpowiedzi opisuje operację protokołu, która go wytworzyła; nie opisuje automatycznie stanu dalszej przeglądarki, archiwum ani klinicznego przepływu pracy. Te późniejsze obietnice wymagają własnych dowodów, dlatego transport trzeba oddzielać od dostępności i widoczności klinicznej.