Platforma zgodna z HIPAA dla zespołów reagujących na kryzys opioidowy

Praca odbywała się na papierze. Każde hrabstwo prowadziło własne arkusze kalkulacyjne, więc niczego nie dało się porównać, a żadnego programu nie można było ocenić poza jedną jurysdykcją.

Osoba istniała tylko wtedy, gdy ktoś złożył skierowanie. Jeśli EMS lub szpital jej nie skierowały, zespół nigdy się o niej nie dowiadywał i nikt nie wiedział, ile osób ginęło w ten sposób z pola widzenia.

Przekazania między instytucjami przepadały. Skierowanie do kliniki lub programu mieszkaniowego oznaczało telefon i notatkę w zeszycie. Na pytanie „Czy tam dotarli?” nie było odpowiedzi, a to jedyne pytanie, które się liczy.

W terenie nie było żadnego systemu. Praca terenowa odbywa się w samochodach, schroniskach, obozowiskach namiotowych i na obszarach wiejskich bez zasięgu. Wszystko, co wymagało internetu, stawało się drugą pracą wykonywaną wieczorem z pamięci.

Poprzeczka regulacyjna jest wyjątkowo wysoka. Dane dotyczące używania substancji podlegają zarówno HIPAA, jak i 42 CFR Part 2, które są bardziej restrykcyjne w zakresie ujawniania informacji. Kilka niezależnych instytucji musi pracować z tą samą osobą, a żadna nie może zobaczyć więcej, niż jej przysługuje.

Akveo zbudowało trzy aplikacje: aplikację mobilną do pracy w terenie, jedną aplikację webową, której funkcje zmieniają się w zależności od roli użytkownika, oraz konsolę superadministratora do zarządzania wszystkimi hrabstwami. Za nimi stoi pipeline pobierający dane z systemów EMS oraz publiczne API do integracji.

Wykrywanie przez AI w każdym rekordzie EMS

Przez system przechodzi teraz każdy rekord wezwania EMS, a nie tylko przypadki, które ktoś skierował. Usługa AI oznacza rekordy wyglądające na epizod związany z substancjami. Działa wyłącznie na danych zanonimizowanych i zwraca decyzję wraz z poziomem pewności, uzasadnieniem i kluczowymi wskaźnikami, aby człowiek mógł się z nią nie zgodzić. Ustrukturyzowane wyniki zapewniają powtarzalność klasyfikacji, a gdy model jest niedostępny, przejmuje ją mechanizm awaryjny oparty na regułach.

Każde hrabstwo ma własny profil reguł z twardymi warunkami „tak” i „nie”, skalibrowany z udziałem lokalnych specjalistów klinicznych na danych rzeczywistych. Rozróżnia on prawdziwe przypadki graniczne, takie jak zadławienie bez innych objawów, dzieci, alkohol bez wskazania konkretnej substancji, przedawkowania przepisanych leków i chemia gospodarcza. Jeden rodzaj błędu oznacza zmarnowany wyjazd zespołu, drugi kosztuje ludzkie życie.

Dane napływają czterema kanałami, bo nikt nie ma czystego API: przez ESO i ImageTrend, dwie dominujące w USA platformy dokumentacji EMS; przez HL7 v2 po MLLP z mTLS i deduplikacją; przez szyfrowaną bezpieczną pocztę e-mail; oraz przez formularze webowe z obsługą dostosowaną do każdej jurysdykcji.

Przestaliśmy być narzędziem do zarządzania przepływem pracy i staliśmy się platformą wykrywania, która ratuje życie.

Przepływ skierowań między instytucjami

Skierowanie to nie wiadomość, lecz wniosek z jasno określonym cyklem życia, który widzą obie strony: niewysłane, wysłane, odebrane, przyjęte, w realizacji, zakończone albo odrzucone, nieodebrane i anulowane. Nadawca otrzymuje powiadomienie na każdym etapie, więc nikt nie musi wydzwaniać, by poznać status.

Dwie niezależne organizacje edytują to samo skierowanie z różnymi uprawnieniami do tych samych pól. Prawo do pola zależy od tego, kim jest użytkownik względem rekordu, w jakim stanie jest rekord i jakiego jest typu. Logika znajduje się w dedykowanym silniku opartym na udokumentowanej macierzy stanów, względem której zespół prowadzi testy, zamiast w warunkach rozsianych po interfejsie.

Aplikacja mobilna offline-first z synchronizacją odporną na różnice wersji

Wizyta w piwnicy, schronisku czy samochodzie bez zasięgu i tak zostaje zarejestrowana. Telefon jest prawdziwym rekordem, a nie szkicem do czasu powrotu do biura. Spotkanie można zapisać niedokończone – wymagane są tylko jego typ i sposób rejestracji.

Urządzenia mogą pozostawać offline tygodniami, a pracownicy terenowi korzystają z różnych wersji aplikacji. Zmiany wprowadzone offline są zapisywane jako intencja – polecenie oznaczone wersją schematu – i po dotarciu na serwer aktualizowane do bieżącego modelu. W drugą stronę każde urządzenie otrzymuje dane w formacie zrozumiałym dla jego wersji. Produkt stale się zmieniał, a nikt w terenie nie musiał aktualizować aplikacji tylko po to, by ją zsynchronizować.

Synchronizacja pobiera tylko to, co się zmieniło. Serwer prowadzi osobny zegar dla każdej rodziny encji, a identyfikatory są generowane na urządzeniu, dzięki czemu rekordy utworzone offline przetrwają wymianę danych i mogą się do siebie odwoływać.

Karta pacjenta zawiera podsumowanie AI, które jest przesyłane strumieniowo sekcja po sekcji przez server-sent events i nigdy nie jest zapisywane.

Kontrola dostępu oparta na kontekście

Nikt nie konfiguruje dostępu ręcznie. Pacjenta widzi się, bo jest się w jego zespole, ma się dla niego zadanie lub prowadzi się wizytę; gdy praca się kończy, dostęp wygasa. Każde uprawnienie przechowuje źródło, które je utworzyło, więc można je automatycznie cofnąć i później wyjaśnić. Zmiany dostępu przemieszczają się razem z danymi: urządzenie dowiaduje się, czego nie może już widzieć, i to usuwa.

Dla pacjenta, który nie jest przypisany do pracownika, ale potrzebuje pomocy natychmiast, hrabstwo może włączyć kontrolowaną ścieżkę. Pracownik odnajduje osobę wyłącznie po pełnym nazwisku, widzi ściśle ograniczony zestaw pól do potwierdzenia tożsamości i uzyskuje dostęp dopiero po potwierdzeniu udzielenia pomocy. Uprawnienie jest zapisywane w historii pacjenta jako przedział czasowy.

Istnieje sześć ról, każda z własnym dostępem do sekcji, a ten dostęp różni się między aplikacją mobilną a webową.

Izolacja wielodzierżawcza z zabezpieczeniami na poziomie wierszy

Wszystkie hrabstwa współdzielą jeden schemat, a zabezpieczenia na poziomie wierszy (row-level security) w PostgreSQL ograniczają każde zapytanie do bieżącego dzierżawcy. Jeśli dzierżawca nie jest ustawiony, nic nie zostaje dopasowane, więc błąd zwraca pusty wynik zamiast danych innego hrabstwa. Administracja między dzierżawcami odbywa się przez osobne API z własną rolą. Nowe hrabstwo jest uruchamiane jedną operacją, która w razie niepowodzenia dowolnego kroku wycofuje wszystkie kroki – zarówno w AWS, jak i w bazie danych.

Zanonimizowana warstwa analityczna

Dashboardy dla hrabstw i podmiotów finansujących działają na osobnym, zanonimizowanym schemacie. Wyzwalacze bazy danych w czasie rzeczywistym usuwają lub maskują wszystkie 18 identyfikatorów HIPAA Safe Harbor. Daty są skracane do miesiąca i roku, a identyfikatory pacjentów zamieniane na jednokierunkowe skróty, dzięki czemu ścieżkę jednej osoby nadal można śledzić w czasie, nie wiedząc, kim ona jest. Analityka jednego hrabstwa nie może pokazać danych sąsiedniego.

Czat w czasie rzeczywistym i SMS do pacjentów

Cała komunikacja odbywa się w jednej sekcji: SMS do pacjentów, wewnętrzne dyskusje o pacjentach, kanały i wiadomości bezpośrednie, każde z licznikiem nieprzeczytanych. SMS-y są oddzielone wizualnie i technicznie, więc nie da się ich pomylić z wiadomościami do współpracowników.

Każde hrabstwo ma własny numer. Rozmowa z pacjentem jest powiązana z numerem telefonu, a nie z pacjentem, ponieważ jeden telefon często należy do kilku osób. Czat działa przez połączenie na żywo, wyłącznie dla rozmów, które użytkownik ma prawo widzieć, a gdy aplikacja jest zamknięta, wysyła powiadomienia push.

Model domenowy dla usług klinicznych i społecznych

Platforma obejmuje ponad 30 rodzajów usług, w większości nieklinicznych: żywność, telefony, odzież, schronienie, długoterminowe zakwaterowanie, rachunki za media, dokumenty, ubezpieczenie, pomoc prawną, zatrudnienie i transport. Część kliniczna obejmuje leczenie uzależnień, redukcję szkód, wymianę strzykawek, leczenie ran, testy na HIV i wirusowe zapalenie wątroby typu C oraz psychiatrię.

Scenariusze kliniczne są wbudowane, a nie doklejone: wdrażanie buprenorfiny ze skalą COWS oraz oceny według kalendarza – od wstępnej, przez 2, 3, 7 i 14 dni, po 1, 2, 3, 6 i 9 miesięcy.