Jeśli prowadzą Państwo klinikę, centrum obrazowania, mobilną usługę radiologiczną lub małą praktykę diagnostyczną, przesyłanie badań z urządzeń obrazujących do Cloud PACS powinno być rutyną, a nie ryzykiem. W rzeczywistości routing może być mylący, ponieważ kroki konfiguracyjne znajdują się w trzech różnych miejscach jednocześnie: w konsoli modalności, w sieci i w ustawieniach docelowych PACS.
Ten przewodnik przeprowadzi Państwa przez konfigurację routingu z urządzenia medycznego do Cloud PACS przy użyciu PostDICOM i jego komunikatora urządzeń medycznych, MeDiC. Dowiedzą się Państwo, co oznacza routing w terminologii DICOM, które ustawienia są najważniejsze, jak skonfigurować czystą i łatwą w obsłudze konfigurację oraz jak przetestować system przed uruchomieniem. Po zakończeniu powinni Państwo być w stanie jasno wyjaśnić swoją konfigurację dostawcy PACS, inżynierowi serwisu modalności i dostawcy IT, co zmniejszy przestoje w przyszłości.
• Routing to po prostu ścieżka, jaką badanie pokonuje z modalności do docelowego systemu PACS, przy użyciu ustawień sieciowych DICOM, takich jak AE Title, adres IP i port.
• Większość błędów routingu wynika z drobnych niedopasowań: błędny AE Title, zły port, zablokowana reguła zapory sieciowej (firewall) lub urządzenie znajdujące się poza oczekiwanym segmentem sieci.
• MeDiC został zaprojektowany do pracy w sieci klinicznej i łączenia urządzeń obrazujących z PostDICOM Cloud PACS bez konieczności korzystania z VPN, co upraszcza wdrożenia w wielu małych firmach.
• Testowanie przed uruchomieniem powinno obejmować sprawdzenie łączności, rzeczywiste badanie testowe oraz potwierdzenie, że badania wyświetlają się poprawnie w przeglądarce w chmurze z nienaruszonymi identyfikatorami pacjenta i seriami.
• Bezpieczeństwo nie jest opcjonalne. Należy stosować podejście oparte na ryzyku, wdrażać kontrole dostępu i upewnić się, że wymagania dotyczące bezpiecznego transportu są zrozumiałe dla DICOM i wszystkich systemów wspierających.
Podstawy routingu obejmują zrozumienie, w jaki sposób urządzenia DICOM znajdują się nawzajem, uwierzytelniają na poziomie sieci i niezawodnie przesyłają badania. Gdy zrozumieją Państwo ten język, konfiguracja stanie się przewidywalną listą kontrolną, a nie metodą prób i błędów.
W obrazowaniu medycznym routing oznacza skonfigurowanie urządzenia tak, aby po zakończeniu badania mogło ono wysłać badanie do właściwego miejsca docelowego przy użyciu protokołu DICOM. Miejscem docelowym może być serwer PACS, brama (gateway) lub router, który przekazuje badania do Cloud PACS.
Proszę pomyśleć o tym w ten sposób. Państwa modalność to encja aplikacji DICOM (Application Entity), a docelowy PACS to kolejna encja aplikacji. Podczas wysyłania obrazów obie strony nawiązują sesję sieciową DICOM (asocjację), uzgadniają, co zostanie wysłane i w jaki sposób, a następnie przesyłają dane. Jeśli asocjacja nie może zostać nawiązana, nic nie zostanie przesłane. Jeśli asocjacja zostanie nawiązana, ale negocjacje będą błędne, mogą Państwo zobaczyć częściowe badania, brakujące serie lub powtarzające się próby wysłania.
W przypadku PostDICOM, MeDiC służy jako komponent lokalny, który umożliwia lokalnym urządzeniom komunikację z PostDICOM Cloud przy użyciu standardowych operacji DICOM.
Terminy te pojawiają się na prawie każdym ekranie konfiguracji modalności i PACS. Jeśli potrafią Państwo odczytać i zweryfikować te wartości, szybko rozwiążą Państwo większość problemów z routingiem.
AE Title to nazwa encji aplikacji DICOM. Jest używana w żądaniu asocjacji do identyfikacji systemów wywołujących i wywoływanych. W standardzie DICOM wywołujący AE Title (Calling AE Title) identyfikuje wnioskodawcę, a wywoływany AE Title (Called AE Title) identyfikuje zamierzonego odbiorcę. W praktyce klinicznej Państwa modalność i miejsce docelowe mają własne AE Title. Obie strony muszą uzgodnić, jakie to wartości.
Częsta pułapka w małych firmach: ktoś wpisuje poprawny AE Title, ale dodaje spację na końcu, używa niewłaściwych reguł wielkości liter dla danego urządzenia lub konfiguruje docelowy AE Title, który nie pasuje do tego, czego oczekuje strona odbierająca. To pojedyncze niedopasowanie może spowodować natychmiastowe odrzucenie asocjacji.
Adres IP to adres sieciowy, którego urządzenie używa do dotarcia do miejsca docelowego. Wewnątrz kliniki jest to zazwyczaj prywatny adres IP sieci LAN. W konfiguracjach routingu w chmurze, które korzystają z lokalnej bramy, modalność często wysyła ruch do adresu LAN bramy, a nie bezpośrednio do chmury.
Dlatego lokalizacja w sieci ma znaczenie. Własne wytyczne PostDICOM zaznaczają, że MeDiC powinien być zainstalowany w sieci lokalnej, a węzły DICOM muszą znajdować się w tej samej sieci, aby się komunikować.
Port to port nasłuchu TCP w odbierającym węźle DICOM. Urządzenie lub oprogramowanie docelowe musi nasłuchiwać na tym porcie, a każda zapora (firewall) między nadawcą a odbiorcą musi zezwalać na ruch na tym porcie.
W wielu środowiskach wartości portów są zmieniane z domyślnych ze względów polityki bezpieczeństwa lub konfliktów. Jedyną zasadą, która ma znaczenie, jest spójność: nadawca musi celować w dokładnie ten port, na którym nasłuchuje odbiorca, i ten port musi być osiągalny.
Asocjacja DICOM to wynegocjowane połączenie między dwiema encjami aplikacji, które umożliwia przepływ poleceń i danych. Podczas nawiązywania asocjacji systemy identyfikują się za pomocą AE Titles i negocjują, co będą wymieniać. Jeśli system odbierający nie może zweryfikować wywoływanego AE Title lub jeśli łączność sieciowa zawiedzie, asocjacja nie zostanie ukończona.
Podczas rozwiązywania problemów zawsze należy oddzielić problemy z asocjacją od problemów z transferem. Jeśli asocjacja nie udaje się, problem zazwyczaj dotyczy tożsamości, IP, portu lub zapory. Jeśli asocjacja działa, ale transfer nie, problemem jest często obsługa składni transferu (transfer syntax), obsługa klas pamięci masowej (storage SOP) lub ograniczenia zasobów.
Routing nie jest pojedynczą architekturą. Większość klinik wpisuje się w jeden z dwóch schematów.
W tej konfiguracji modalność wysyła badania bezpośrednio do punktu końcowego w chmurze. Może to działać w niektórych środowiskach, ale często wymaga bardziej złożonej sieci, ściślejszych zmian w zaporze sieciowej i starannej weryfikacji bezpiecznego transportu. Wiele małych firm uważa to za trudniejsze w obsłudze, ponieważ dostawcy modalności mogą być niechętni do rozwiązywania problemów z bezpośrednim routingiem internetowym.
W tej konfiguracji modalności wysyłają badania do lokalnej bramy (gateway), która przekazuje je do chmury. MeDiC jest powszechnie używany w tej roli we wdrożeniach PostDICOM, instalowany na komputerze w sieci kliniki lub szpitala i używany do łączenia urządzeń obrazujących z PostDICOM Cloud PACS. PostDICOM zauważa również, że MeDiC działa bezpiecznie za zaporami ogniowymi i nie wymaga połączenia VPN, co jest praktyczną zaletą dla wielu małych zespołów.
Dla większości małych klinik model z bramą jest łatwiejszy w zarządzaniu, ponieważ modalności muszą jedynie połączyć się z lokalnym adresem IP i portem, co jest znanym środowiskiem dla inżynierów serwisu modalności.
Zanim zmienią Państwo jakiekolwiek ustawienia, proszę zebrać wymagania wstępne. Zapobiegnie to najczęstszemu scenariuszowi: wykonaniu połowy konfiguracji, a następnie oczekiwaniu dniami na brakującą wartość, którą posiada tylko jedna osoba.
Po pierwsze, proszę potwierdzić, że mają Państwo dostęp do konta PostDICOM z uprawnieniami do tworzenia lub zarządzania MeDiC oraz do przeglądania przychodzących badań. Po drugie, proszę zidentyfikować komputer, na którym będzie działał MeDiC. Powinien on znajdować się w tym samym segmencie sieci klinicznej, co modalności, które będą wysyłać obrazy. Wytyczne PostDICOM kładą nacisk na umieszczenie w sieci LAN i wykorzystanie tej samej sieci dla węzłów DICOM.
Po trzecie, proszę zebrać wartości sieciowe DICOM dla każdej modalności. Potrzebny jest AE Title modalności, IP modalności i port, którego będzie używać, jeśli ma odbierać jakikolwiek ruch DICOM. Nawet jeśli modalność tylko wysyła dane, nadal warto mieć kompletny rekord węzła dla dokumentacji.
Po czwarte, proszę zebrać wartości docelowe PostDICOM, które skonfigurują Państwo w MeDiC, w tym ustawienia PACS, których MeDiC używa do połączenia z miejscem docelowym w chmurze. Baza wiedzy PostDICOM przeprowadza przez edycję ustawień serwera PACS MeDiC i dodawanie węzłów z opisem, AE Title, IP i portem.
Na koniec, proszę uzgodnić działania z osobą kontrolującą reguły zapory sieciowej i segmentację sieci. Nawet w małej klinice może to być dostawca usług zarządzanych (MSP), dostawca routera lub starszy pracownik. Proszę zadecydować z góry, czy chcą Państwo dedykowaną sieć VLAN do obrazowania, czy maszyna MeDiC będzie miała statyczny adres IP i jak będą dokumentowane zmiany.
Ta sekcja to praktyczny poradnik. Postępuje zgodnie z tą samą kolejnością, której będą Państwo potrzebować podczas wdrażania, aby nie tworzyć pętli konfiguracyjnych.
 - Created by PostDICOM.jpg)
Proszę zacząć wewnątrz PostDICOM od utworzenia lub wybrania aplikacji MeDiC, a następnie pobrać instalator dla systemu operacyjnego, którego będą Państwo używać. PostDICOM zapewnia wskazówki dotyczące instalacji dla systemów Windows i Linux oraz odnotowuje wsparcie dla popularnych systemów operacyjnych desktop.
Instalując MeDiC, proszę traktować maszynę hosta jak infrastrukturę, a nie jak zwykłą stację roboczą. Oznacza to stabilne zasilanie, przewodowe połączenie sieciowe w miarę możliwości, zaplanowane aktualizacje systemu operacyjnego i dostęp ograniczony do osób, które go potrzebują.
Co najważniejsze, proszę umieścić go poprawnie w sieci. Dokumentacja PostDICOM wyraźnie stwierdza, że MeDiC musi znajdować się w sieci lokalnej, a węzły DICOM muszą znajdować się w tej samej sieci, aby się komunikować.
W MeDiC skonfigurują Państwo ustawienia docelowe PACS, które definiują, gdzie MeDiC przekazuje badania. PostDICOM udostępnia przewodnik krok po kroku dotyczący edycji ustawień serwera PACS w MeDiC, gdzie upewnią się Państwo, że wartości docelowe w chmurze są poprawne.
Robiąc to, proszę udokumentować wartości docelowe w prostym arkuszu routingu. Należy uwzględnić nazwę miejsca docelowego, docelowy AE Title, docelowy host, docelowy port i datę ostatniej weryfikacji. Małe firmy korzystają na tym, ponieważ zapobiega to problemowi „tylko jedna osoba zna ustawienia”.
Następnie proszę zarejestrować swoje modalności wewnątrz MeDiC jako węzły DICOM. Wytyczne MeDiC od PostDICOM pokazują szczegóły węzła, które mają znaczenie: opis, AE Title, IP i port, oraz opisują dodawanie węzła DICOM, aby MeDiC mógł komunikować się z modalnościami kompatybilnymi z DICOM, takimi jak CT, MRI, CR i USG.
Proszę zachować spójność w nazewnictwie. Należy używać konwencji nazewnictwa, którą przyszły technik szybko zrozumie, np. TK_Sala1, USG_Sala2, RTG_Mobilne, i uwzględnić producenta oraz model urządzenia w dokumentacji wewnętrznej.
Teraz proszę przejść do konsoli każdej modalności i skonfigurować miejsce docelowe DICOM wskazujące na MeDiC. To miejsce docelowe będzie używać AE Title MeDiC, adresu IP LAN MeDiC i skonfigurowanego portu nasłuchu MeDiC.
Tutaj często liczy się koordynacja z inżynierami serwisu modalności. Wiele modalności przechowuje miejsca docelowe DICOM w menu serwisowym, a inżynier będzie potrzebował dokładnych wartości. Państwa zadaniem jest dostarczenie ich w przejrzysty sposób i zweryfikowanie ich podczas wprowadzania.
Praktyczna uwaga dla klinik: jeśli mają Państwo wiele modalności, proszę nie konfigurować ich wszystkich naraz. Proszę w pełni skonfigurować jedną modalność, przetestować ją od początku do końca, a następnie powielić ten schemat. Ogranicza to zasięg ewentualnych błędów i przyspiesza ich rozwiązywanie.
Weryfikacja powinna odbywać się warstwami.
Po pierwsze, proszę potwierdzić podstawową osiągalność sieciową z segmentu sieci modalności do hosta MeDiC. Po drugie, proszę potwierdzić, że ustawienia węzła DICOM są zgodne po obu stronach. Wytyczne PostDICOM kładą nacisk na dodanie nawzajem swoich AE Title, IP i portu w celu komunikacji, co jest istotą tego kroku.
Następnie proszę wysłać badanie testowe. Należy użyć prawdziwego, ale bezpiecznego testu, takiego jak badanie fantomu lub wyznaczonego pacjenta testowego zgodnie z polityką kliniki. Proszę zweryfikować wszystkie poniższe elementy w PostDICOM: badanie dociera, liczba serii się zgadza, kluczowe obrazy otwierają się w przeglądarce, a identyfikatory pacjenta wyświetlają się poprawnie zgodnie z potrzebami przepływu pracy. Strona rozwiązania dla klinik PostDICOM opisuje, jak wysyłać obrazy z urządzeń obrazujących do MeDiC po zakończeniu konfiguracji DICOM.
Jeśli Państwa praktyka korzysta z reguł automatycznego wysyłania, proszę zapoznać się z wytycznymi PostDICOM dotyczącymi zarządzania ustawieniami automatycznego wysyłania DICOM, ponieważ automatyzacja może być pomocna, ale może również potęgować błędy, jeśli zostanie skonfigurowana zbyt wcześnie.
Testowanie to nie tylko pojedyncze udane wysłanie. Bezpieczne uruchomienie ma trzy fazy: testy funkcjonalne, testy przepływu pracy i gotowość operacyjna. Dowiedz się więcej o liście kontrolnej uruchomienia PostDICOM.
Testy funkcjonalne dowodzą, że trasa działa. Oznacza to powtarzane wysyłanie, a nie tylko jedno, oraz co najmniej jedno większe badanie, jeśli modalności generują dużą liczbę serii.
Testy przepływu pracy dowodzą, że obrazy trafiają tam, gdzie personel ich oczekuje. Proszę potwierdzić, że radiolodzy i klinicyści mogą znaleźć badania po nazwisku pacjenta lub numerze akcesyjnym, że przepływ pracy raportowania nie jest zablokowany i że dostęp zdalny zachowuje się tak, jak oczekuje tego firma.
Gotowość operacyjna to nudna część, która chroni Państwa później. Proszę stworzyć krótki instruktaż (runbook), który zawiera szczegóły hosta MeDiC, kto konserwuje PC, do kogo dzwonić w przypadku problemów z modalnością i jaki jest plan wycofania zmian (rollback), jeśli routing zawiedzie pierwszego dnia. Małe firmy odnoszą sukces, gdy proces jest spisany, a nie uwięziony w czyjejś pamięci.
Rozwiązywanie problemów z routingiem DICOM jest najłatwiejsze, gdy pracują Państwo od dołu do góry. Proszę nie zgadywać. Należy sprawdzić każdą warstwę, a następnie przejść wyżej.
Proszę zacząć od oczywistych niedopasowań. Potwierdzić pisownię AE Title po obu stronach. Potwierdzić, że docelowy adres IP w modalności jest zgodny z adresem IP LAN hosta MeDiC. Potwierdzić, że port jest zgodny z portem nasłuchu MeDiC i że jest otwarty w lokalnej zaporze. Konfiguracja DICOM obraca się wokół AE Titles i portów TCP IP, a standard wyraźnie traktuje je jako skonfigurowane wartości, a nie magiczne domyślne ustawienia.
Następnie należy wyizolować asocjację od transferu. Jeśli modalność w ogóle nie może się połączyć, nadal są Państwo w obszarze asocjacji. Jeśli łączy się, ale zawodzi w trakcie transferu, należy zbadać obsługę składni transferu (transfer syntax), obsługę klas pamięci masowej (storage class) lub limity zasobów na hoście MeDiC.
Następnie proszę sprawdzić lokalizację w sieci. Jeśli modalność znajduje się w innej sieci VLAN lub jeśli reguła routera blokuje komunikację boczną, zobaczą Państwo przerywane awarie lub całkowity brak możliwości połączenia. Uwaga PostDICOM o tym, że MeDiC i węzły DICOM muszą być w tej samej sieci, jest silną wskazówką do diagnozowania tych przypadków.
Na koniec proszę uważać na problemy operacyjne, które wydają się być awariami technicznymi. Jeśli host MeDiC jest uśpiony, uruchamia się ponownie w celu aktualizacji lub kończy mu się miejsce na dysku, routing zawiedzie, mimo że konfiguracja jest poprawna. Proszę traktować hosta MeDiC jak mały serwer.
Routing Cloud PACS dotyka regulowanych danych w wielu środowiskach, więc Państwa postawa w zakresie bezpieczeństwa musi być zgodna z obowiązkami. W Stanach Zjednoczonych zasada bezpieczeństwa HIPAA (HIPAA Security Rule) ustanawia standardy ochrony elektronicznych chronionych informacji zdrowotnych i wymaga zabezpieczeń administracyjnych, fizycznych i technicznych.
Dla małych firm najbardziej praktycznym podejściem jest przestrzeganie uznanych ram szczegółów wdrożenia. NIST SP 800 66 Rev 2 jest napisany specjalnie, aby pomóc podmiotom regulowanym każdej wielkości we wdrażaniu zabezpieczeń zasady bezpieczeństwa HIPAA w praktyczny sposób.
Od strony DICOM bezpieczny transport nie jest niejasnym pojęciem. DICOM Część 15 definiuje profile bezpieczeństwa i zarządzania systemem, w tym profile bezpiecznego połączenia transportowego opartego na TLS, i odwołuje się do nowoczesnych wytycznych dotyczących najlepszych praktyk TLS, takich jak rekomendacje IETF.
Z punktu widzenia wdrażania należy skupić się na tych dyscyplinach niezawodności i bezpieczeństwa.
• Po pierwsze, kontrola dostępu. Należy ograniczyć, kto może administrować MeDiC i kto ma dostęp do kont PostDICOM. Proszę używać silnego uwierzytelniania i oddzielić konta administracyjne od codziennych kont użytkowników.
• Po drugie, szyfrowanie w transporcie. Proszę upewnić się, że rozumieją Państwo, w jaki sposób ruch DICOM jest chroniony między komponentami, i że każdy dostęp webowy do przeglądarek w chmurze korzysta z nowoczesnych konfiguracji TLS zgodnych z zaleceniami najlepszych praktyk.
• Po trzecie, audytowalność. W większych ekosystemach profile takie jak IHE ATNA kładą nacisk na uwierzytelnianie węzłów, rejestrowanie audytów i szyfrowanie telekomunikacji jako elementy fundamentalne. Nawet jeśli nie wdrażają Państwo pełnego audytu korporacyjnego, nadal powinni Państwo prowadzić dzienniki (logi) i wiedzieć, gdzie szukać, gdy coś pójdzie nie tak.
• Po czwarte, odporność. Klinika powinna zdecydować, co robić, gdy internet nie działa lub host MeDiC jest offline. Czy modalności kolejkują badania lokalnie, czy personel ręcznie wysyła je ponownie, czy mają Państwo ścieżkę zapasową? Prosta spisana polityka w tym zakresie zapobiega panice i wielokrotnemu wysyłaniu duplikatów.
PostDICOM stwierdza, że MeDiC działa bezpiecznie za zaporami ogniowymi i nie wymaga połączenia VPN. W praktyce może to uprościć wdrożenie, ponieważ modalności wysyłają ruch do lokalnej bramy, która obsługuje łączność z chmurą.
Co najmniej potrzebny jest AE Title modalności, adres IP modalności i konfiguracja portu, a także wartości docelowe dla MeDiC. Błędy routingu są najczęściej spowodowane niedopasowaniem AE Title, nieprawidłowymi adresami IP lub nieprawidłowymi portami.
Różne urządzenia mogą znajdować się w różnych segmentach sieci, mieć różne reguły zapory lub używać różnych profili docelowych. Proszę potwierdzić, że modalność, która nie działa, może połączyć się z hostem MeDiC na odpowiednim porcie i że wartości AE Title pasują dokładnie.
Proszę skorzystać z wyznaczonego przepływu pracy testowej zatwierdzonego przez politykę kliniki, takiego jak badania fantomu lub rekord pacjenta testowego stworzony do walidacji technicznej. Celem jest zweryfikowanie, czy badania docierają, otwierają się poprawnie i zachowują integralność serii, zanim włączą Państwo rutynowe wysyłanie.
Proszę udokumentować AE Title, IP i port każdego węzła, szczegóły hosta MeDiC, ustawienia docelowe w chmurze i dokładną datę uruchomienia. W przypadku zgłoszeń serwisowych ta jedna strona często drastycznie skraca czas rozwiązania problemu.
Konfiguracja routingu urządzenia medycznego do Cloud PACS nie jest trudna, gdy potraktują to Państwo jako ustrukturyzowany system: tożsamość DICOM, osiągalność sieciowa, stabilna brama i zdyscyplinowane testowanie. Dla małych firm największą korzyścią jest przewidywalność. Gdy zespół potrafi wyjaśnić ścieżkę routingu, zweryfikować każdą wartość i powtórzyć konfigurację dla każdej modalności, zmniejszają Państwo przestoje i chronią przychody.
Jeśli planują Państwo przenieść przepływy pracy obrazowania do Cloud PACS i chcą przejrzystej, łatwej w obsłudze konfiguracji routingu, proszę rozpocząć okres próbny z PostDICOM i skonfigurować MeDiC w sieci klinicznej. Gdy pierwsza modalność będzie wysyłać czyste badania testowe od początku do końca, skalowanie na resztę urządzeń stanie się powtarzalnym procesem.
|
Cloud PACS i Przeglądarka DICOM OnlinePrześlij obrazy DICOM i dokumenty kliniczne na serwery PostDICOM. Przechowuj, przeglądaj, współpracuj i udostępniaj swoje pliki obrazowania medycznego. |
