Zgodność, przyjęcie i odpowiedzialność za przechowanie

„Kompatybilność z DICOM” brzmi jak właściwość typu tak albo nie, dopóki dwa systemy nie spróbują wymienić obiektu pochodnego. Jeden system może zapisywać CT, ale nie Segmentation Storage; drugi może przyjąć segmentację bez jej wyświetlenia; dwa produkty mogą obsługiwać tę samą klasę obiektu, lecz nie mieć wspólnej Transfer Syntax. We wszystkich trzech przypadkach sieć może być osiągalna, a zamierzony przepływ pracy nadal zawiedzie.

Zgodność jest macierzą możliwości

Obsługę DICOM lepiej traktować jako macierz konkretnych obietnic. Dla danej SOP Class zapytaj, który system działa jako SCU, a który jako SCP, jakie Transfer Syntaxes są proponowane lub akceptowane oraz jakie opcje, poziomy obsługi, wymagania konfiguracyjne i ograniczenia udokumentowano. Produkt implementuje wybraną część standardu potrzebną do swoich rzeczywistych działań; nie implementuje automatycznie każdego opcjonalnego komponentu.

DICOM Conformance Statement pozwala zbadać ten wybór. Zwykle opisuje Application Entities produktu, Real-World Activities, SOP Classes, role SCU/SCP, Transfer Syntaxes, rozszerzoną negocjację, opcje, ograniczenia i wymagania konfiguracyjne, takie jak AE Titles i porty. Dokument jest kontraktem możliwości służącym do porównania, a nie certyfikatem, że nieprzetestowany przepływ pracy zadziała. Może pomóc kompetentnemu odbiorcy przewidzieć, czy komunikacja może być obsługiwana, ale rzeczywiste produkty, konfiguracja i dane nadal wymagają testu od początku do końca.

Porównanie można przeprowadzić mechanicznie. Dla każdego obiektu i każdej usługi wymaganej przez przepływ pracy porównaj wiersz SCU nadawcy z wierszem SCP odbiorcy. Poszukaj wspólnej SOP Class i co najmniej jednej zgodnej Transfer Syntax, a następnie przeczytaj opcje i ograniczenia po obu stronach. Przecięcie pozwala przewidzieć konkretną możliwość; nie jest gwarancją dla każdego obiektu ani każdej drogi przez przeglądarkę.

Trzy sposoby, na jakie macierz może zawieść

Rozważmy trzy skonstruowane przypadki. W pierwszym archiwum deklaruje CT i MR Storage, ale nie Segmentation Storage. C-STORE obiektu SEG kończy się niepowodzeniem, ponieważ odbiorca nie zadeklarował obsługi tej SOP Class. Stan sieci nie dowodzi niczego przeciwnego; wymaganej możliwości brakuje.

W drugim odbiorca przyjmuje i archiwizuje Segmentation Storage, ale nie dokumentuje możliwości wyświetlania w przeglądarce diagnostycznej. Obiekt może być obecny i możliwy do pobrania, podczas gdy radiolog nie widzi maski w bieżącym kontekście interpretacji. Przyjęcie i wyświetlanie są różnymi wierszami przepływu pracy.

W trzecim oba produkty implementują odpowiednią SOP Class, lecz proponują i akceptują rozłączne Transfer Syntaxes. TCP może się połączyć i można podjąć próbę nawiązania asocjacji, jednak kontekst prezentacji dla tego obiektu zostaje odrzucony. Awaria dotyczy przecięcia sposobów kodowania, niekoniecznie sieci.

Przypadki te wyjaśniają, dlaczego deklaracja na poziomie produktu, taka jak „obsługuje DICOM”, jest zbyt ogólna dla decyzji integracyjnej. Zbadaj komórkę, która ma znaczenie: klasę obiektu, rolę, sposób kodowania i udokumentowane ograniczenia rzeczywistego przepływu pracy.

Przyjęcie nie jest odpowiedzialnością za przechowanie

Takie samo rozdzielenie jest potrzebne po udanym transferze. Udany C-STORE wskazuje, że informacja została zapisana na jakimś nośniku i jest dostępna przez pewien określony przez implementację czas. Sam w sobie nie ustanawia bezterminowej trwałości, dostępności dla przyszłego zapytania ani możliwości wyrenderowania przez przeglądarkę.

Storage Commitment jest oddzielną usługą DICOM dotyczącą innej obietnicy. W Push Model strona żądająca występuje o zobowiązanie dla wskazanych SOP Instances za pomocą N-ACTION; SCP usługi Storage Commitment przekazuje później przez N-EVENT-REPORT instancje objęte zobowiązaniem i instancje, dla których operacja się nie powiodła. Wymiana jest asynchroniczna i oddzielona od pierwotnego potwierdzenia C-STORE. Dokładne zachowanie usługi i wszelkie zasady lokalne nadal trzeba sprawdzić względem właściwej specyfikacji i implementacji.

Utrzymuj trzy pytania osobno:

1. Przyjęcie: czy usługa odbierająca przyjęła obiekt teraz?
2. Zobowiązanie: czy usługa odbierająca wskazała, że odpowiada za zachowanie i późniejsze pobranie wskazanych instancji w ramach usługi Storage Commitment?
3. Dostępność: czy zamierzona strona żądająca może później znaleźć, pobrać i wykorzystać obiekt w przepływie pracy?

Każda odpowiedź może być inna. Obiekt może zostać przyjęty bez żądania zobowiązania; deklaracja zobowiązania może istnieć, choć późniejsze zapytanie lub droga trasowania jest niesprawna; dostępny obiekt może nadal nie być obsługiwany przez przeglądarkę. Jest to wzorzec systemów rozproszonych wyrażony przez usługi DICOM: potwierdzenie, odpowiedzialność i użyteczna dostępność są odrębnymi obietnicami.

Rozróżnienie ma szczególne znaczenie dla wyników pochodnych. Jeśli usługa AI wysyła tysiące obiektów SEG lub SR, odpowiedź odbiorcy o przyjęciu sama w sobie nie wskazuje późniejszego podmiotu odpowiedzialnego za przechowanie ani nie dowodzi, że osoba interpretująca może pobrać wyniki. Przepływ pracy potrzebuje jawnych zapisów obietnicy, na której polega. Następną granicą nie jest transport ani odpowiedzialność za przechowanie, lecz poufność: zachowanie użyteczności badawczej przy jednoczesnym ograniczeniu sposobów, na jakie wydany zbiór danych może identyfikować osobę.