Przemyślenia z rozwijania produktu dla niszy. Case study upmedic – narzędzia trzykrotnie przyspieszającego pracę teleradiologa.

W pacode (software house dla startupów) głęboko wierzymy w learning by doing oraz learning by example, dlatego chcielibyśmy podzielić się przemyśleniami z tworzenia upmedic – naszego produktu dla radiologów.

W sektorze ochrony zdrowia występuje zjawisko niezaspokojonego popytu (szczególnie w takich krajach, jak np. w Polsce, gdzie jednym z założeń jest to, że usługi medyczne z perspektywy pacjenta są darmowe). Wykonywanie usług medycznych wymaga użycia specjalistycznego sprzętu oraz pracy lekarzy, których wykształcenie jest kosztowne i czasochłonne. Średnia wieku lekarzy specjalistów w Polsce to aż 54 lata (dla porównania: średni wiek specjalisty w branży IT to 30 lat). Radiolodzy to lekarze, którzy specjalizują się w wykonywaniu, analizowaniu i interpretowaniu badań, np. USG, tomografii komputerowej, rentgena. Część badań nie wymaga obecności lekarza, dlatego powstały takie zawody, jak np. technik elektroradiolog, skupiające się wyłącznie na wykonywaniu badania i przesyłaniu zebranych zdjęć do radiologów w celu interpretacji. Niedobór radiologów jest tak duży, że jeden często świadczy swoje usługi wielu placówkom zdalnie, stąd określa się ich mianem teleradiologów. Radiologia rozwijała się w swojej zdalnej postaci jeszcze przed pandemią COVID-19. Teleradiolog otrzymuje od placówki zdjęcia i jego/jej zadaniem jest utworzenie opisu radiologicznego, czyli tego co w zdjęciach dało się zauważyć. Jest to bardzo cenne z punktu widzenia lekarza, który – patrząc na dostarczony przez radiologa opis – planuje dalsze leczenie. Przykładowo onkolog, planując dalszą chemioterapię, potrzebuje wiedzieć, czy ciało pacjenta pozytywnie reaguje na dotychczasowe leczenie.

Teleradiologia, z racji zapotrzebowania, dąży do tego, aby dany radiolog był w stanie jak najszybciej wytwarzać opisy zdjęć diagnostycznych przy zachowaniu troski o precyzję diagnozy.

AI nie rozwiąże wszystkich problemów

Panująca obecnie ekscytacja rozwiązaniami opartymi o sztuczną inteligencję (a w szczególności o machine learning) ma wpływ na to, co się dzieje w świecie radiologicznym. Uczenie maszynowe (szczególnie sieci splotowe) doskonale sprawdza się w rozpoznawaniu wzorców w zdjęciach. Dlatego tworzone są modele, które mają na celu zautomatyzowanie rozpoznawania np. guzów, złamań, poszczególnych organów w zdjęciach. Odpowiednio przygotowany model jest w stanie automatycznie zmierzyć objętości organów, ułatwiając diagnozę. Niestety, problemem jest to, do jak wąskiej klasy problemów można zastosować dany model. Praca włożona w trenowanie modelu rozpoznającego wątrobę na zdjęciach niekoniecznie pomoże w budowaniu modelu wykrywającego zmiany onkologiczne. Pozostaje też kwestia odpowiedzialności za stawianą diagnozę. Czy możemy winić model, gdy popełni błąd? Wobec tych wyzwań mówimy o rozszerzonym o AI workflow radiologicznym, w którym radiolog wspomagany jest przez AI poprzez sugestie fraz opisu na podstawie automatycznej analizy zdjęć, ale ostatecznie to on/ona tworzy tekst opisu radiologicznego, decyduje o tym, którego modelu z wielu dostępnych użyć do analizy elementów zdjęcia diagnostycznego, podpisuje się pod opisem, poświadczając medyczną poprawność dokumentu.

Edytor tekstu dla radiologów? Przecież mamy już Worda!

upmedic to inteligentny edytor opisów radiologicznych. Po co radiologowi dedykowany edytor tekstu, jeśli istnieje już Word? Inne są cele realizowane przez upmedic, a inne przez Worda. Twórcy Worda udostępniają edytor tekstu, który ma dawać możliwie jak największy zestaw narzędzi do tworzenia dokumentów o dowolnym wyglądzie. Główną rolę w dokumencie gra tekst, ale użytkownik potrzebuje móc dowolnie edytować wygląd dokumentu, np. wstawiać grafikę, ustawiać marginesy i nagłówki.

WordArt jako przykład dowolności w reprezentacji wizualnej treści dokumentu w Word

Natomiast nadrzędnym celem upmedic jest jak najszybsze tworzenie wysokiej jakości dokumentacji medycznej. Przyjmujemy wobec tego podejście: zmierz i optymalizuj. Mierzymy, ile czasu zajmują konkretne czynności podczas tworzenia opisu i szukamy rozwiązań, jak sprawić, by przerzucić na oprogramowanie powtarzalne czynności, pozostawiając lekarzowi sprawy bardzo indywidualne dla danego opisu oraz dopisywanie nietypowych patologii. Przeanalizowaliśmy sposób pracy radiologów oraz kilkaset opisów ich autorstwa i dzielimy się ważniejszymi spostrzeżeniami:

• 85% opisów zawiera powtarzalne frazy,
• lekarze nie lubią pisania na klawiaturze lub piszą dość wolno,
• interpunkcja, o ile często konieczna, zabiera cenny czas. 

Jak poradzić sobie z powtarzalnością treści opisów? Uznaliśmy, że najlepiej będzie stworzyć bazę najczęściej występujących przy danym badaniu fraz i określiliśmy taki zbiór szablonem. Szablony tworzymy własne, ale dajemy lekarzom możliwość dostosowania ich do indywidualnych potrzeb. Są one swego rodzaju inwestycją lekarza w nasze oprogramowanie, bo ich utworzenie zajmuje nieco czasu. 

Pracę z programem dzielimy wobec tego na dwie części: pracę nad własną biblioteką szablonów oraz pracę nad opisami na bazie szablonów. Pracę nad biblioteką szablonów realizujemy częściowo także po naszej stronie, ponieważ dobrze przygotowany szablon badania może służyć innym, jednocześnie zwiększając atrakcyjność dla nowych lekarzy. 

Cechy dobrze przygotowanego szablonu:

• prowadzi lekarza podczas opisu badania, zachowując kolejność opisywanych organów (coś, jak lista TODO), w której należy odhaczyć kolejne elementy, aby uznać opis za skończony – minimalizujemy ryzyko pominięcia ważnego elementu,
• zawiera frazy opisujące zdrowego pacjenta, a także najczęściej używane opisy patologii.

Design thinking z lekarzami

Design thinking (albo tak zwane myślenie projektowe) zakłada kreatywne podejście do rozwiązywania problemów na bazie bezpośredniego kontaktu z użytkownikiem. Staramy się, aby nasze rozwiązanie odpowiadało na prawdziwe potrzeby lekarza, dlatego, stosując niektóre techniki zaczerpnięte z design thinking, przeprowadzamy nieustanne iteracje z naszymi klientami dla poprawienia oferowanych usług. Między innymi: przeprowadzamy wywiady pogłębione, identyfikujemy pain points i gain points, tworzymy persony oraz prototypujemy i testujemy.

Dzięki takiemu podejściu udało nam się uniknąć poświęcenia cennych zasobów i czasu na opracowywanie funkcji, które okazały się zbędne już na etapie rozmów z użytkownikami. Warto jednak mieć krytyczne podejście do uwag wyrażanych przez użytkownika – często prawdziwa potrzeba jest ukryta między wierszami. Może on twierdzić, że potrzebuję konkretnie danej funkcji, jednak po dłuższej rozmowie i głębszej analizie okazuje się, że prawdziwą potrzebą jest przyspieszenie pracy i może być ona osiągnięta za pomocą różnych rozwiązań. Dlatego istotny jest etap testowania, gdy nasze założenia zostają zderzone z klientem i zweryfikowane. Niemniej jednak na wszystkich etapach należy mieć na uwadze potrzeby użytkownika – w końcu chcemy stworzyć rozwiązanie, z którego będzie korzystał i które pomoże mu przy optymalizacji pracy. Poszukując product/market fit, wkładaj pracę tylko w wartość dodaną.

Webowe technologie u podstaw

Wyznajemy zasadę, że domyślną platformą, na którą powstaje nowoczesne oprogramowanie, powinna być platforma webowa. Czasem pojawiają się argumenty, które zmuszają do wyboru innych platform (konieczność użycia niskopoziomowych API, wymagania wydajnościowe, pozyskanie konkretnej grupy użytkowników), jednak korzyści, jakich dostarcza web, to:

• wiele platform, 
• brak jawnego procesu instalacji oprogramowania, nie trzeba podnosić uprawnień użytkownika, aby zacząć korzystać z oprogramowania w przeglądarce internetowej (szczególnie ważne w szpitalach), 
• zawsze najnowsza wersja programu dostępna dla użytkowników,
• społeczność wokół platformy: mnóstwo nowoczesnych bibliotek, mających ułatwić budowę UI z gotowych komponentów, stosowanie najnowszych wzorców projektowych.

Gotowe biblioteki komponentów

Ograniczone liczbowo zespoły oraz rosnące oczekiwania, dotyczące bogactw interakcji z aplikacjami, sprawiają, że warto korzystać z bibliotek komponentów. Takie biblioteki pozwalają na łatwe ustalenie wspólnego języka między UX a IT, zdejmują z zespołów dużo prac dokumentacyjnych, utrzymaniowych, a przede wszystkim przyspieszają wytwarzanie UI. Przykładmi takich bibliotek są UI-Kit oraz ant design (www.ant.design).

Storybook – piaskownica z naszymi komponentami

Ciekawym sposobem na prezentowanie, testowanie oraz dokumentowanie dostosowanych pod aplikację komponentów jest Storybook (www.storybook.js.org), który pozwala przeglądać komponenty z różnych miejsc w naszej aplikacji, oderwane od ich kontekstu. Możemy symulować interakcje, opisywać zachowania, aby wytłumaczyć, jak zachowuje się komponent w różnych sytuacjach, testować ich zgodność ze specyfikacją.

Analiza interakcji użytkowników – HotJar

Nie jest możliwe przeprowadzenie wywiadu z każdym użytkownikiem naszego produktu, ale już po samej obserwacji tego, jak użytkownik korzysta z oprogramowania, można wyciągać wiele wniosków. HotJar pozwala na przeglądanie (wybranych) nagrań z tego, jak użytkownicy wchodzą w interakcje, ile one trwały, z jakiego urządzenia korzystają.

Iteracje z UX – Problematyczne struktury zagnieżdżone (drzewa) i ich różne przedstawianie w zależności od tego, co chcemy pokazać

Operujemy na dokumentach, które z natury zawierają w sobie zagnieżdżone elementy (np. edytorach tekstowych, gdzie mamy różne poziomy nagłówków). Dane układane w ten sposób reprezentowane są często za pomocą drzew. W upmedic mamy produkt, który pozwala na budowanie wywiadów medycznych, w których pytania zależą od tego, jak udzielono odpowiedzi na wcześniejsze pytania. Co ankiety mają wspólnego z dokumentami? To również są drzewa! 

W tym temacie kluczowe jest jednak, jak to, co chcemy pokazać, ma wpływ na sposób prezentacji. Drzewo dokumentów prezentujemy tak, jakby dokument był wydrukowany na kartce papieru, bo chcemy mieć podgląd całości. W przypadku ankiet sytuacja jest inna, bo chcemy pokazywać przyczyny występowania pytania o danej treści, a prezentowanie całej ankiety może zaciemniać obraz całości użytkownikowi. Zdecydowaliśmy się wobec tego na prezentację drzewa w postaci przewijanych bloków, z połączeniami wskazującymi na to, jaka odpowiedź na poprzednie pytanie spowodowała, że wyświetlamy konkretne pytanie.

Przykład nieoczywistego na pierwszy rzut oka drzewa -> sformatowany opis radiologiczny

Ankiety jako przykład innego sposobu prezentacji drzew.

Równowaga między dotykiem a precyzją kursora myszy

Chociaż oryginalnie upmedic powstał z myślą o dużych ekranach, to z wywiadów z lekarzami wynika, że chcieliby korzystać z oprogramowania na tabletach. Ponieważ dla większości opisów nie trzeba praktycznie używać klawiatury, to używanie upmedic na tabletach ma swoje uzasadnienie, np. podczas ustawiania tabletu przy aparacie do USG i tworzenia opisu w trakcie wykonywania badania w gabinecie. 

Różnica natomiast jest w nawigowaniu, ponieważ dla klasycznych desktopów myszka jest głównym narzędziem do poruszania się po programie, a dla tabletów jest to dotyk. Od użytkownika tabletu nie można oczekiwać precyzji tak dużej, jak od użytkowników myszy, wobec tego panel nawigowania po opisie prezentuje się różnie, zależnie od wielkości ekranu użytkownika. Na tablecie elementy klikalne są znacznie większe, aby ułatwić trafienie w nie. 

Zbyt jaskrawe kolory nie zawsze pomagają w zwróceniu uwagi

Temat dotyczył naszej funkcji konotacji, która ma krytyczne znaczenie dla modeli przetwarzania naturalnego, trenowanych na opisach utworzonych w upmedic. Konotacje pozwalają na oznaczenie, czy dana fraza ma pozytywny czy negatywny wpływ na całościową diagnozę pacjenta. Pierwszy pomysł: dajmy jak najbardziej jaskrawe kolory dla konotacji (czerwony = negatywna, zielony = pozytywna) – będą zwracały uwagę! Niestety, okazało się, że zamiast pomagać, tak użyte kolory wprowadzają zamieszanie dla użytkownika. Rozwiązaniem było zmniejszenie intensywności (saturacji) oryginalnych kolorów, aby zwiększył się kontrast między kolorem konotacji a tekstem. 

Nakierowywanie użytkownika na domyślne zachowania

Przyjmujemy zasadę, że im coś jest częściej wykonywane przez użytkownika, tym mniej wysiłku powinno kosztować wykonanie tej czynności. W przypadku tworzenia opisu radiologicznego taką czynnością jest dodawanie nowych porcji tekstu do dokumentu. Wobec tego najbardziej podstawowa czynność, czyli klik lewym przyciskiem myszy, realizuje dokładnie tę czynność. Checkbox przy frazach realizuje to samo, ale jest tam obecny głównie jako wskazówka, w jakim celu istnieje w UI ta fraza.

Zniechęcanie użytkownika do drogi na skróty, gdy w dłuższej perspektywie się to mu/jej nie opłaca

W dowolnym momencie lekarz mógłby sprowadzić upmedic do zwykłego edytora tekstu, dodając pole tekstowe i wpisując tam całą treść opisu (określamy to opisem zdegenerowanym). Jednorazowo może mieć to sens, ale: tak utworzony opis trudno automatycznie analizować, a gdyby w przyszłości przydały się frazy zawarte w opisie, z racji tego, że nie są one w szablonie, trzeba wpisać je ponownie, na co traci się czas. Dlatego UX-owo zniechęcamy użytkownika do takich działań, np. poprzez wymaganie przełączenia całego okna z opisem w tryb edycji.

PoC, czyli jak zrobić dużo, szybko i wybrać, w co warto inwestować

Powtarzana wszędzie zasada Pareto (w formie przydatnej dla naszych rozważań: 80% zamierzonego efektu kosztuje 20% całości) w zastosowaniu dla oprogramowania objawia się poprzez pojęcie Proof of Concept (PoC). Dla szerokiej klasy problemów stosunkowo łatwe jest wytworzenie czegoś nieco lepszego niż makieta, a dającego wartość użytkownikom nawet w swojej podstawowej, prymitywnej formie. W ten sposób, zamiast stworzyć jedną rzecz, zużywając planowane 100% zasobów, można zrealizować 5 (w prawdziwym świecie nie jest tak idealnie, 3 brzmi bardziej realnie) mniejszych projektów na poziomie PoC i zobaczyć, w który warto zainwestować więcej czasu i wysiłku, aby doprowadzić do finalnej formy.

Chociaż upmedic to produkt dla niszy, to korzystamy ze sprawdzonych narzędzi oraz ze znanych technik. Przede wszystkim staramy się brać to, co już jest, i nasze wysiłki wkładać w to, co doda wartości do obecnego stanu rzeczy. Chociaż kuszące czasem jest tworzenie wszystkiego po swojemu, na własnych zasadach, to należy brać pod uwagę to, czy wysiłki włożone w wynajdywanie koła na nowo nie mogłyby pójść w coś innego, co mogłoby użytkownikom dać znacznie więcej wartości.

Autorzy: Paweł Paczuski, Krzysztof Paczuski, Renteria Sophia