Portale pacjenta zawodzą osoby z niepełnosprawnościami — audyt 8 wiodących portali powiązanych z EHR w USA

Portale pacjenta to główne wejście do nowoczesnego systemu opieki zdrowotnej w USA — i te drzwi są zamknięte dla osób, które potrzebują ich najbardziej. Zbadaliśmy portale skierowane do pacjentów ośmiu amerykańskich dostawców elektronicznej dokumentacji medycznej obsługujących największą liczbę klinik, szpitali i sieci ambulatoryjnych — Epic MyChart, Oracle Health (dawniej Cerner), Allscripts, athenahealth, NextGen, eClinicalWorks, Practice Fusion i Greenway — pod kątem WCAG 2.1 Level AA i ostatecznej reguły Section 504 Biura ds. Praw Obywatelskich HHS opublikowanej 9 maja 2024 r. (89 FR 40066). Na approx. 240 stronach portalu i pięciu podstawowych przepływach zadań opieki zdrowotnej średni wskaźnik zautomatyzowanego audytu wyniósł 61 procent, mediana ręcznie weryfikowanego wskaźnika ukończenia zadań przez użytkowników czytników ekranu wyniosła 54 procent, a najsłabszy portal całkowicie nie spełnił trzech z pięciu podstawowych przepływów. Reguła z maja 2024 r. dotyczy każdego portalu obsługiwanego przez podmiot, który otrzymuje federalną pomoc finansową HHS — co w praktyce, ponieważ Medicare i Medicaid obejmują niemal każdą klinikę, szpital i gabinet ambulatoryjny w kraju, oznacza, że zasadniczo każdy portal w tym dossier jest objęty jej zakresem.

01 · Jak audytowaliśmy osiem portali

Audytem objęto portale skierowane do pacjentów obsługiwane przez ośmiu dostawców EHR w USA z największą zainstalowaną bazą, według łącznej liczby szpitali i klinik ambulatoryjnych: Epic MyChart, Oracle Health (dawny portal pacjenta Cerner, przemianowany po przejęciu przez Oracle w 2022 r.), Allscripts FollowMyHealth, athenahealth athenaPatient, NextGen Patient Portal, eClinicalWorks healow, Practice Fusion Patient Fusion i Greenway Health MyHealthRecord. Łącznie ci dostawcy obsługują doświadczenie portalu pacjenta dla zasadniczo każdej kliniki uczestniczącej w Medicare i Medicaid w kraju.

Dla każdego portalu przeprowadziliśmy dwa równoległe ćwiczenia. Pierwsze to zautomatyzowany skan WCAG 2.1 Level AA na 30 stronach o dużym natężeniu ruchu na markę — strona główna, logowanie, pulpit nawigacyjny, indeks wyników badań, indywidualna strona wyniku badania, lista recept, przepływ refundacji, lista wizyt, rezerwacja wizyty, hol wizyty wideo, wizyta wideo podczas połączenia, skrzynka odbiorcza wiadomości, edytor wiadomości, strona przesyłania dokumentów i próbka stron z treściami edukacyjnymi. Użyliśmy axe-core 4.10 w bezgłowym Chrome oraz Lighthouse 12 i rejestrowaliśmy wskaźnik zaliczeń reguł na stronę oraz liczbę unikalnych naruszeń na kryterium sukcesu WCAG.

Drugie to ręczny test ukończenia zadań dla pięciu podstawowych przepływów opieki zdrowotnej. Każde zadanie próbowano trzy razy na każdym z trzech stosów technologii wspomagających — NVDA 2024.4 z Firefox 124, JAWS 2025 z Edge 124 i VoiceOver na iOS 17.4 z Safari — przez audytora zaznajomionego z każdym stosem. Zadanie było uznawane za „wykonane“ tylko wtedy, gdy audytor osiągnął stan sukcesu bez interwencji widzącego w co najmniej dwóch z trzech prób. Pięć zadań wybrano dlatego, że obejmują to, co pacjenci faktycznie robią na portalach: przeglądanie wyników badań; refundacja aktywnej recepty; dołączanie do zaplanowanej wizyty wideo; przesyłanie dokumentu lub fotografii do wątku wiadomości; oraz zmiana terminu nadchodzącej wizyty stacjonarnej.

02 · Ranking firm w jednym wykresie

Osiem portali nie działa jednakowo. Dwa — Epic MyChart i athenaPatient — przekraczają próg 70 procent zautomatyzowanego audytu i zaliczają cztery z pięciu ręcznych przepływów zadań na większości stosów. Trzy znajdują się w środku pasma. Trzy — Practice Fusion, Greenway i NextGen — są na dole, z zautomatyzowanymi wskaźnikami zaliczeń poniżej 55 procent i co najmniej dwoma niespełnionymi podstawowymi przepływami każdy. Wzorzec jest spójny w ćwiczeniach automatycznych i ręcznych: portale, które dobrze wypadają w skanowaniu, dobrze wypadają też w testach, a portale, które słabo wypadają w skanowaniu, testują jeszcze gorzej, niż same liczby skanowania sugerowałyby.

Ranking celowo używa automatycznego wskaźnika zaliczeń jako widocznej zmiennej, ponieważ jest to najbardziej odtwarzalna liczba w dossier — inny audytor uruchamiający axe-core 4.10 na tych samych 30 stronach powinien uzyskać wyniki w granicach kilku punktów procentowych od powyższych danych. Ręczne wskaźniki ukończenia zadań są bardziej zaszumione (zaznajomienie audytora ze stosem, drift wersji AT, przerywane błędy po stronie serwera), ale silnie korelują ze skanem automatycznym: portal, który nie spełnia 40 procent zautomatyzowanych reguł, nie zaliczy też znacznej części ręcznych zadań, ponieważ te same podstawowe problemy (brakujące etykiety kontrolek formularzy, niezapowiedziane stany ładowania, pułapki fokusa w modalnych oknach dialogowych) napędzają oba wyniki.

Żaden portal w dossier nie osiąga 80 procent. Nawet najlepszy z ośmiu nie spełnia mniej więcej co piątej reguły WCAG 2.1 AA — a najsłabszy nie spełnia więcej niż połowy.

03 · Pięć podstawowych przepływów opieki zdrowotnej

Procentowe wskaźniki zaliczeń zautomatyzowanych reguł są przydatne na poziomie strony, ale pacjenci nie odwiedzają portali po to, żeby czytać strony — odwiedzają je, żeby wykonywać zadania. Pięć zadań poniżej obejmuje większość tego, po co portale pacjenta istnieją, i każde z nich było testowane ręcznie na każdym z trzech stosów technologii wspomagających dla każdego z ośmiu portali.

Przeglądanie wyników badań jest zadaniem najczęściej wykonywanym, ponieważ jest najbliższe zwykłemu dokumentowi tekstowemu — strona to tabela, komórki tabeli zawierają tekst, a większość portali przynajmniej zadowalająco wiąże programistycznie nagłówki wierszy z komórkami danych. Błędy, które się pojawiają, koncentrują się w filtrach zakresu dat tracących fokus po przesłaniu, w dokumentach wyników renderowanych jako PDF z niescannowanymi obrazami bez dostępności oraz w widżetach wykresów trendów prezentujących informacje tylko wizualnie bez równoważnej alternatywy tekstowej. Odwołania reguły Section 504 do kryterium sukcesu WCAG SC 1.1.1 (treść niebędąca tekstem), 1.3.1 (informacje i relacje) i 1.4.5 (obrazy tekstu) obejmują wszystkie trzy tryby błędów.

Refundacja recepty jest strukturalnie prostsza niż wygląda — to formularz z kilkoma przyciskami opcji, selektorem apteki i przyciskiem wysłania — a mimo to spada do 58 procent. Dominującym błędem są brakujące lub programistycznie niepoprawne etykiety formularzy dla selektora apteki i pola „preferowany czas odbioru“, często w połączeniu z niestandardowo zbudowanym polem kombi, które nie implementuje semantyki ARIA combobox. SC 1.3.1 (informacje i relacje), SC 3.3.2 (etykiety lub instrukcje) i SC 4.1.2 (nazwa, rola, wartość) są wielokrotnie cytowane w dzienniku naruszeń.

Przesyłanie dokumentów — fotografii karty ubezpieczenia, skierowania od innego lekarza lub fotografii rany do wątku wiadomości — to miejsce, gdzie automatyczne wskaźniki i ręczne wyniki najbardziej się rozchodzą. Większość przesyłaczy portali używa niestandardowego widżetu drag-and-drop, który w zasadzie obsługuje klawiaturę, ale nie ogłasza swojego stanu ani postępu. Użytkownicy czytnika ekranu, którym udało się wywołać selektor plików, często nie mogą stwierdzić, czy przesyłanie się powiodło, ponieważ stan sukcesu renderowany jest jako wizualny toast, który nie jest ogłaszany. SC 4.1.3 (komunikaty o stanie) i SC 2.1.1 (klawiatura) to dominujące naruszenia.

Zmiana terminu wizyty plasuje się w środku tabeli z 67 procentami, ponieważ większość widżetów kalendarza portali jest niedostępna dla czytników ekranu, ale odzyskuje się poprzez alternatywny „widok listy“, który użytkownik musi znaleźć. Tam, gdzie widok listy jest osiągalny, zadanie się powodzi; tam, gdzie jest ukryty, ukryty za przełącznikiem, który nie jest ogłaszany, lub niedostępny na urządzeniach mobilnych, zadanie się nie powodzi. Błąd dotyczy odkrywalności, a nie podstawowej funkcjonalności.

Dołączanie do wizyty wideo jest zadaniem o najgorszym wyniku w dossier — 33 procent ukończenia, osiem sukcesów z dwudziestu czterech prób. Następna sekcja jest mu poświęcona.

04 · Wizyty wideo: najbardziej konsekwentnie zepsuta powierzchnia

Spośród pięciu podstawowych przepływów sekwencja dołączania do wizyty wideo to ta, która najbardziej konsekwentnie pokonuje użytkowników technologii wspomagających na największej liczbie portali. Siedem z ośmiu portali nie zaliczyło co najmniej jednego stosu AT w przepływie dołączania; trzy nie zaliczyły wszystkich trzech. Tryby błędów skupiają się w trzech powtarzających się wzorcach:

• Okno dialogowe uprawnień urządzenia przed dołączeniem. Gdy przeglądarka prosi użytkownika o przyznanie dostępu do kamery i mikrofonu, monit jest zazwyczaj natywnym oknem dialogowym przeglądarki, nad którym portal nie ma kontroli. Jednak strony holu poprzedzające monit — „kliknij Kontynuuj, aby przetestować kamerę“ — są często niedostępne: kafelek podglądu wideo bez odpowiednika tekstowego, wskaźnik głośności mikrofonu bez wartości programistycznej, przycisk przełączania napisów, który można ogniskować klawiaturą, ale nie jest ogłaszany jako przycisk. Cztery z ośmiu portali nie spełniają tego kroku na co najmniej jednym stosie.
• Powierzchnia podczas połączenia. Właściwe okno połączenia to miejsce, gdzie sześć z ośmiu portali nie spełnia SC 4.1.2 (nazwa, rola, wartość) dla kontrolek wyciszenia, włączenia kamery, podniesienia ręki i zakończenia połączenia. Kontrolki niestandardowo budowane renderują się jako przyciski bez etykiet; w dwóch portalach jedynym sposobem na wyciszenie jest skrót klawiaturowy nigdzie nieudokumentowany w sposób widoczny dla czytnika ekranu. Napisy na żywo nie są domyślnie włączone w żadnym z ośmiu portali, mimo że SC 1.2.4 (napisy, na żywo) to kryterium poziomu AA, a reguła Section 504 wymienia je wprost.
• Stan fokusa po połączeniu. Gdy rozmowa wideo się kończy, sześć z ośmiu portali pozostawia fokus klawiatury wewnątrz teraz zamkniętego modalu połączenia, tworząc pułapkę fokusa, z której użytkownik musi odświeżyć stronę, żeby wyjść. SC 2.1.2 (brak pułapki klawiatury) i SC 2.4.3 (kolejność fokusa) to odpowiednie kryteria. Zachowanie jest na tyle spójne u różnych dostawców, że sugeruje wspólny wzorzec przyczyny głównej w sposobie montowania widżetu wizyty wideo w powłoce portalu.

Język reguły ma tu znaczenie, ponieważ telemedyczne wizyty wideo nie są już funkcją peryferyjną — są podstawową powierzchnią uczestnictwa w objętych programach. CMS kontynuowało refundację telemedycyny Medicare na poziomie parytetu przez CY2024 i sygnalizowało kontynuację parytetu przez CY2026 dla zdrowia behawioralnego i kwalifikujących się usług ambulatoryjnych. Kiedy federalny płatnik płaci za wizyty wideo, a federalny egzekutor praw obywatelskich stwierdza, że wizyty wideo muszą być dostępne i użyteczne dla osób z niepełnosprawnościami na poziomie WCAG 2.1 AA, portal, którego powierzchnia wizyty wideo nie spełnia sześciu z ośmiu nazwanych kryteriów sukcesu WCAG 2.1 AA dotyczących wideo, jest, prima facie, niezgodny z przepisami.

05 · Reguła Section 504 — co obejmuje, czego nie

Ramą prawną tego audytu jest ostateczna reguła Section 504 Biura ds. Praw Obywatelskich HHS, opublikowana 9 maja 2024 r. w 89 FR 40066, skodyfikowana w 45 CFR Part 84, Subpart I. Jest to najbardziej konsekwentna federalna regulacja dotycząca dostępności w opiece zdrowotnej od trzech dekad. Trzy cechy reguły sprawiają, że bezpośrednio dotyczy ona ośmiu portali w tym dossier.

Po pierwsze, reguła dotyczy odbiorców federalnej pomocy finansowej HHS. Centers for Medicare and Medicaid Services administruje federalną pomocą finansową poprzez Medicare Part A, Medicaid i Program Ubezpieczenia Zdrowotnego Dzieci. Klinika, szpital lub praktyka ambulatoryjna, która wystawia rachunki Medicare lub przyjmuje Medicaid, jest odbiorcą. Zasadniczo każdy szpital opieki ogólnej w kraju uczestniczy w Medicare; zasadniczo każda praktyka podstawowej opieki zdrowotnej obsługująca dzieci uczestniczy w Medicaid lub CHIP. Praktycznym efektem klauzuli zakresu jest to, że reguła obejmuje operatora każdego portalu w tym dossier.

Po drugie, reguła ustanawia WCAG 2.1 Level AA federalnym standardem technicznym. Nie przyjmuje WCAG 2.0, nie przyjmuje WCAG 2.2 i nie przyjmuje niejasnego standardu „zasadniczo równoważnego dostępu“. Wskazanie konkretnego, cytowalnego, zewnętrznie utrzymywanego standardu ze stabilnym słownictwem kryteriów sukcesu jest najważniejszą operacyjnie cechą reguły. Redukuje lata argumentów o „znacznej zgodności“ w sporach sądowych dotyczących dostępności w opiece zdrowotnej do jednej liczby.

Po trzecie, terminy zgodności reguły są stopniowane według wielkości odbiorcy. Odbiorcy zatrudniający 15 lub więcej pracowników muszą dostosować się do 11 maja 2026 r. — czyli w oknie audytowym tego dossier. Mniejsi odbiorcy mają czas do 10 maja 2027 r. Ośmiu dostawców portali w tym dossier nie jest samo w sobie odbiorcami, ale ich klienci są nimi, a obowiązek klienta rozciąga się na doświadczenie portalu: szpital, który wdraża niezgodny portal, sam jest niezgodny.

Istotne jest też to, czego reguła nie robi. Nie wiąże bezpośrednio dostawców EHR jako takich — dostawcy nie są odbiorcami federalnej pomocy finansowej HHS, a reguła wiąże odbiorców. Ekspozycja dostawców przebiega przez żądania kontraktowe ich klientów. Ale żądania kontraktowe nadchodzą: każdy duży system szpitalny podpisujący nowy kontrakt MyChart, Oracle Health lub athenahealth w 2025–2026 umieszcza w umowie głównej zapisy dotyczące WCAG 2.1 AA, ponieważ alternatywą jest podpisanie kontraktu, który stawia sam szpital w niezgodności. Dostawcy, którzy już się przygotowali — Epic i athenahealth prowadzą w dossier — są w silniejszej pozycji komercyjnej niż dostawcy, którzy tego nie zrobili.

Reguła nie uchyla też prywatnych procesów sądowych. Osoba z niepełnosprawnością, która nie może wykonać wyszukiwania wyników badań na portalu objętym Section 504, nadal ma prywatne roszczenie na podstawie ADA Title III (dla powierzchni miejsca publicznego kliniki), Section 1557 Affordable Care Act (dla powierzchni federalnie finansowanego programu zdrowotnego) oraz stanowych ustaw dotyczących niepełnosprawności (Unruh Act Californii, nowojorska Human Rights Law i inne). Reguła Section 504 dodaje federalne minimum regulacyjne; nie zastępuje istniejących ścieżek procesowych.

06 · Jak wygląda zgodny portal

Audyt nie rysuje jednostajnie ponurego obrazu. Dwa z ośmiu portali — Epic MyChart i athenahealth athenaPatient — zbliżają się do zgodnej podstawy na większości powierzchni, a luki, które mają, są zasadniczo do naprawienia w oknie zgodności reguły. Trzy z ośmiu — Allscripts FollowMyHealth, Oracle Health, eClinicalWorks healow — są w zasięgu zgodności przy skupionej remediacji. Trzy — NextGen, Greenway, Practice Fusion — mają znacznie więcej pracy do zrobienia i przy obecnej trajektorii nie dotrą do terminu maja 2026 bez zobowiązania, którego dotąd nie wyraziły publicznie.

Wzorce odróżniające portale zgodne od niezgodnych nie są szczególnie wyszukane. Kontrolki formularzy mają widoczne etykiety programistycznie powiązane z ich polami. Niestandardowo zbudowane widżety — pola kombi, selektory dat, przesyłacze plików — implementują semantykę ARIA, której potrzebują. Zmiany stanu są ogłaszane przez regiony aria-live lub węzły roli statusu. Kolejność fokusa odpowiada kolejności czytania. Okna dialogowe modalne przechwytują fokus podczas otwierania i prawidłowo go zwracają po zamknięciu. Napisy na żywo są domyślnie włączone w połączeniach wideo, a za nimi stoi opublikowany cel dotyczący wskaźnika błędów wyrazów. Żadna z tych czynności nie jest nowatorską pracą — to podstawowy poziom WCAG 2.1 AA, który każdy dostawca portali miał do przyswojenia od 2018 roku.

07 · Perspektywy na 2026 r.

Trzy wątki definiują nadchodzący rok dla dostępności portali pacjenta w USA.

• Termin maja 2026 r. Odbiorcy zatrudniający 15 lub więcej pracowników muszą dostosować treści internetowe i aplikacje mobilne do WCAG 2.1 Level AA do 11 maja 2026 r. Obejmuje to zasadniczo każdy szpital i każdą praktykę ambulatoryjną uczestniczącą w Medicare o jakiejkolwiek znaczącej wielkości w kraju. OCR sygnalizowało, że po terminie nastąpi egzekucja, a kancelarie ds. praw niepełnosprawnych już przygotowują szablony skarg.
• Cykl kontraktowy dostawców. Kontrakty EHR działają na cyklach trzech do siedmiu lat. Kontrakty podpisywane w 2025 i 2026 r. będą determinować doświadczenie portalu do końca dekady, a podpisujące je szpitale umieszczają w umowach głównych zapisy dotyczące WCAG 2.1 AA. Dostawcy, którzy wchłoną te zapisy bez renegocjacji, zyskają udział w rynku; dostawcy, którzy będą się opierać, stracą udział.
• Przecięcie z Section 1557. Section 1557 Affordable Care Act niezależnie zakazuje dyskryminacji ze względu na niepełnosprawność przez federalnie finansowane programy zdrowotne. HHS wydało zaktualizowaną ostateczną regułę Section 1557 w maju 2024 r. razem z regułą Section 504 i obie działają równolegle. Portal, który nie spełnia wymogów Section 504, jest też narażony na skargi Section 1557 z ich własnymi ścieżkami egzekucyjnymi i środkami zaradczymi.

Przekrój przez całość

Portale pacjenta zostały sprzedane systemowi opieki zdrowotnej w USA jako cyfrowy odpowiednik szerzej otwartych drzwi kliniki — zachęty do znaczącego użytkowania w latach 2010. pchnęły każdą praktykę uczestniczącą w Medicare do postawienia portalu przed swoimi pacjentami, a dostawcy EHR zbudowali infrastrukturę, która je dostarczyła. Audyt pokazuje, że szerzej otwarte drzwi były częściową prawdą: dla pacjentów bez niepełnosprawności drzwi są otwarte. Dla pacjentów z niepełnosprawnościami — tych, którzy używają czytników ekranu, tych, którzy nawigują klawiaturą, tych, którzy polegają na napisach lub powiększeniu, lub sterowaniu głosem — drzwi są otwarte średnio około połowy czasu, a znacznie mniej niż to na trzech najsłabszych portalach w dossier.

Reguła Section 504 z maja 2024 r. to największa pojedyncza zmiana w prawie dostępności opieki zdrowotnej od trzech dekad i uruchomiła zegar. Zegar tyka do maja 2026 r. dla dużych odbiorców i do maja 2027 r. dla mniejszych. Osiem portali w tym dossier ma od dwunastu do dwudziestu czterech miesięcy, żeby zamknąć lukę między tym, gdzie są, a tym, gdzie federalne przepisy teraz wymagają, żeby były. Dwa są blisko. Trzy są w zasięgu. Trzy nie są. Czytaj więcej od Disability World o krajobrazie prawa dostępności w USA, o zapisach raportowania z 2026 r. i o federalnym standardzie Section 508, który informuje o technicznej podstawie.