Technicznie poprawny, klinicznie niewidoczny

Sama skuteczność predykcyjna nie wystarcza do wykazania użyteczności w zamierzonym przepływie pracy; skuteczność modelu, integracja systemu i wpływ kliniczny są odrębnymi kwestiami. Obiekt może być prawidłowo utworzony i zapisany, podczas gdy stacja opisowa nie potrafi go pobrać; wynik może zostać powiązany z niewłaściwym badaniem albo dotrzeć do przepływu pracy dopiero po podjęciu istotnej decyzji. Są to informatyczne tryby awarii, a nie podstawy do wnioskowania, że model jest błędny.

Katalog diagnostyczny

Gdy wynik wydaje się nie wywierać wpływu, należy oddzielać kilka klas awarii:

• Niezgodność danych wejściowych lub siatki. Usługa może niejawnie zmienić próbkowanie albo wybrać serię, której geometria lub kontekst akwizycji różni się od oczekiwań osoby interpretującej. Wynik może być wewnętrznie spójny, a zarazem odnosić się do podstawy pomiaru, której odbiorca nie może zbadać.
• Niezgodność tożsamości. Obiekt pochodny może zostać przypisany do niewłaściwego pacjenta, badania lub serii albo zawierać identyfikatory, które uniemożliwiają przeglądarce powiązanie go z interpretowanym badaniem.
• Błąd listy roboczej lub czasu. Wynik może nie zostać skierowany na właściwą listę roboczą albo dotrzeć po faktycznym zakończeniu opisu lub procesu decyzyjnego.
• Błąd pobierania lub wyświetlania. Archiwum może zawierać SEG, SR lub inny obiekt, podczas gdy stacja robocza nie potrafi go wyszukać, zdekodować lub wyrenderować w bieżącym kontekście przeglądarki.
• Utracone informacje o pochodzeniu. System może nie zachować informacji o danych wejściowych, wersji modelu i zdarzeniu przetwarzania, które wytworzyły wynik, co utrudnia prześledzenie rozbieżności.
• Brak śladu audytowego. System może nie mieć możliwego do odtworzenia zapisu zdarzeń potrzebnych do ustalenia, kto lub co obsługiwało obiekt i kiedy.
• Naruszenie poufności. Eksport uznawany za zdezidentyfikowany może nadal zawierać metadane, tekst dowolny, piksele lub kontekst umożliwiający powiązanie z tożsamością.

Lista jest modelem diagnostycznym, a nie wyczerpującą taksonomią ani rankingiem częstości występowania. Ma zapobiegać sytuacji, w której jedno nieprecyzyjne rozpoznanie, takie jak „AI zostało zignorowane”, zlewa tożsamość obiektu, transport, przepływ pracy, możliwości, pochodzenie i poufność w jeden problem.

Ograniczona diagnoza przed zmianą modelu

Rozważmy skonstruowaną sytuację, w której demonstracja dostawcy zadziałała, metryki offline pozostają niezmienione, a osoby interpretujące później mówią, że nigdy nie widzą wyniku. Zanim rozpoczniesz ponowne trenowanie modelu, prześledź jedno badanie za pomocą czterech pytań.

Po pierwsze, czy zamierzona stacja robocza potrafi pobrać i wyrenderować dany typ obiektu? Sukces transferu nie dowodzi możliwości przeglądarki. Po drugie, czy obiekt jest powiązany z właściwym badaniem i serią oraz czy reguła trasowania wybrała zamierzone źródło? Po trzecie, czy wynik dotarł w czasie, w którym mógł jeszcze wejść do przepływu pracy związanego z interpretacją? Po czwarte, czy ośrodek może odtworzyć dane wejściowe, wersję modelu i zdarzenie przetwarzania na tyle dobrze, aby osoba interpretująca mogła zrozumieć wynik i mu zaufać?

Kontrole te stanowią skuteczną kolejność badania, a nie uniwersalny protokół. Odpowiedź może wymagać łącznej analizy zapytań do archiwum, odwołań DICOM, stanu listy roboczej, możliwości przeglądarki, znaczników czasu i zapisów audytowych. Wynik, który przechodzi wszystkie cztery kontrole, nadal wymaga dowodów na to, jak korzystają z niego osoby interpretujące i jakiego twierdzenia dotyczy ocena; widoczność techniczna nie jest tym samym co korzyść kliniczna.

To rozróżnienie wyznacza granicę interpretacji badań wdrożeniowych. Wynik wydajności offline może wspierać twierdzenie o testowanym modelu i danych ewaluacyjnych. Ani wydajność offline, ani sama widoczność techniczna nie dowodzi, że system zmienił decyzje kliniczne lub przyniósł korzyść pacjentom. Projekt dowodowy dla twierdzenia o wpływie musi odpowiadać zamierzonemu pytaniu klinicznemu; rozdział o wdrożeniu klinicznym rozwija tę granicę. Rozdział 10 nie dodaje do tego twierdzenia dowodów z badań z udziałem osób interpretujących.

Awaria po uruchomieniu produkcyjnym

Powierzchnia awarii może także zmieniać się w czasie. Aktualizacja modelu może zmienić wymagania dotyczące pochodzenia, aktualizacja przeglądarki może zmienić obsługiwane typy obiektów, a połączenie systemów może zmienić założenia dotyczące identyfikatorów lub trasowania. Wdrożenie, które działało w jednej konfiguracji, potrzebuje zatem sposobu badania swoich aktualnych kontraktów dotyczących obiektów, przepływu pracy i odpowiedzialności, zamiast opierać się na pierwotnej demonstracji.

Profile interoperacyjności mogą pomóc uczynić część tych kontraktów jawnymi, ale nazwa profilu nie zastępuje testów od początku do końca. Następna sekcja przedstawia profile IHE jako receptury przepływów pracy: połączenia istniejących standardów, które doprecyzowują określone przekazania, nie eliminując lokalnych wyborów implementacyjnych.