CMS-0057-F i 1 stycznia 2027: API płatników we własnych systemach obsługi roszczeń i uprzedniej autoryzacji

Do 1 stycznia 2027 organizacje Medicare Advantage (prywatne plany w ramach Medicare) oraz stanowe programy Medicaid i CHIP (publiczne ubezpieczenie dla osób o niskich dochodach i dla dzieci) w modelu fee-for-service (FFS, płatność za każdą usługę) muszą mieć uruchomione cztery API FHIR, których wymaga ostateczne rozporządzenie CMS w sprawie interoperacyjności i uprzedniej autoryzacji (CMS Interoperability and Prior Authorization final rule, CMS-0057-F): istniejące Patient Access API, rozszerzone o dane o uprzednich autoryzacjach, oraz nowe Provider Access API, Payer-to-Payer API i Prior Authorization API. Plany Medicaid managed care (opieki zarządzanej), podmioty CHIP managed care i ubezpieczyciele oferujący Qualified Health Plan (QHP) na federalnych giełdach ubezpieczeniowych podlegają tym wymogom od pierwszego okresu taryfowego (rating period) lub roku polisowego (plan year), który zaczyna się tego dnia lub później. Na dzień 16 października 2026 do tego terminu zostało jedenaście tygodni, a CMS go nie przesunął.

Część operacyjna rozporządzenia już obowiązuje. Od 2026 roku płatnicy objęci przepisami muszą podawać konkretny powód każdej odmowy uprzedniej autoryzacji, wydawać decyzje w ustalonych terminach i publikować wskaźniki dotyczące uprzedniej autoryzacji.

Jeśli systemy obsługi roszczeń (claims), zarządzania wykorzystaniem świadczeń (utilization management, UM) i ewidencji ubezpieczonych pochodzą od dostawcy, który dostarcza te cztery API, większość prac leży po jego stronie. Po stronie płatnika zostaje konfiguracja, zdigitalizowane reguły uprzedniej autoryzacji, powiadomienia dla ubezpieczonych i testy z partnerami.

Ten artykuł jest dla pozostałych: planów i agencji stanowych, których silnik obsługi roszczeń, proces UM albo dane ubezpieczonych działają w systemie, który same posiadają, czy to zbudowanym we własnym zakresie, czy dostosowanym tak mocno, że aktualizacje nie są już możliwe, czy w Medicaid Management Information System (MMIS, stanowym systemie informatycznym Medicaid) z dziesięcioleciami lokalnych zmian. Do takich systemów nikt nie dostarczy gotowych API. Jesteśmy inżynierami, nie prawnikami: wyjaśniamy, czego rozporządzenie wymaga od systemu, a nie to, jak stosuje się do konkretnych umów.

Terminy

Ostateczne rozporządzenie opublikowano 8 lutego 2024 w Federal Register, federalnym dzienniku urzędowym, a w życie weszło 8 kwietnia 2024. Dla każdego z czterech API wyznacza te same terminy: „do 1 stycznia 2027 dla organizacji MA oraz stanowych programów Medicaid i CHIP FFS; do okresu taryfowego rozpoczynającego się 1 stycznia 2027 lub później dla planów Medicaid managed care i podmiotów CHIP managed care; oraz dla lat polisowych rozpoczynających się 1 stycznia 2027 lub później dla ubezpieczycieli QHP na FFE”.

Plan Medicaid managed care, którego okresy taryfowe zaczynają się 1 lipca, ma więc czas do 1 lipca 2027. Plan z umową na rok kalendarzowy go nie ma.

CMS wciąż podaje tę samą datę. Jego strona poświęcona rozporządzeniu, ostatnio zmieniona 8 października 2026, stwierdza, że „płatnicy objęci przepisami mają czas co do zasady do 1 stycznia 2027 na spełnienie wymogów tego ostatecznego rozporządzenia dotyczących interfejsów programistycznych aplikacji (API)”.

Obowiązki na 2026 rok, tak jak ujmuje je nota informacyjna CMS, to decyzje „w ciągu 72 godzin w przypadku wniosków przyspieszonych (tj. pilnych) i siedmiu dni kalendarzowych w przypadku wniosków standardowych (tj. niepilnych)” (ubezpieczyciele QHP na giełdach są z tych terminów wyłączeni), konkretny powód każdej odmowy oraz publiczne wskaźniki, przy czym „pierwszy zestaw wskaźników należy zgłosić do 31 marca 2026”. Wykorzystanie Patient Access API również raportuje się CMS co roku do 31 marca. Jeśli coś z tego jeszcze nie działa, termin już minął, a potrzebne są do tego te same dane co do API.

Leki są poza tym wszystkim. Każdy przepis CMS-0057-F dotyczący uprzedniej autoryzacji je wyłącza.

Kogo to dotyczy, a kogo nie

Rozporządzenie nazywa ich płatnikami objętymi przepisami (impacted payers): to organizacje Medicare Advantage (MA), stanowe programy Medicaid i CHIP fee-for-service (FFS), plany Medicaid managed care, podmioty CHIP managed care oraz ubezpieczyciele QHP na Federally-facilitated Exchanges (FFE, giełdach prowadzonych przez rząd federalny). Analiza skutków wymienia „365 organizacji macierzystych, w tym stanowe agencje Medicaid i CHIP”, które „odpowiadają za wdrożenie i utrzymanie trzech nowych API”, i zauważa, że „75 procent płatników w tej kategorii zatrudnia mniej niż 500 pracowników”. Wiele z nich to plany regionalne bez dużego zespołu platformowego.

Poza zakresem, przynajmniej bezpośrednio, pozostają:

• Plany pracownicze spoza tych programów oraz Original Medicare (tradycyjny, federalny Medicare). Nie ma ich na liście płatników objętych przepisami.
• Świadczeniodawcy. Po ich stronie jest Electronic Prior Authorization measure, miernik w programach Promoting Interoperability w Medicare, spełniany za pomocą certyfikowanej technologii EHR. Ostateczne rozporządzenie IPPS na rok budżetowy 2027 (dotyczące płatności Medicare za leczenie szpitalne) z 4 sierpnia 2026 zrobiło z niego dla szpitali w 2027 roku opcjonalny miernik premiowany dodatkowymi punktami.
• Podmioty, którym delegowano UM, oraz TPA (zewnętrzni administratorzy). Nie mają własnych obowiązków, ale obowiązki płatnika przechodzą przez ich systemy. W przypadku ubezpieczycieli QHP rozporządzenie powtarza, że „odpowiadają za własną zgodność z przepisami oraz za zgodność wszelkich podmiotów delegowanych lub działających na dalszym szczeblu”.

Wyjść awaryjnych jest niewiele i na tym etapie żadne z nich wiele nie pomoże. Stan może wystąpić o jednorazowe, roczne przedłużenie terminu dla swojego programu Medicaid lub CHIP FFS, ale wniosek składa się w ramach Advance Planning Document (APD, dokumentu planowania, przez który stan uzyskuje federalne finansowanie IT) i musi on zostać „zatwierdzony przed terminem zapewnienia zgodności”. Stan, w którym co najmniej 90 procent beneficjentów Medicaid korzysta z managed care, może wystąpić o zwolnienie, a ubezpieczyciele QHP mogą poprosić giełdę o wyjątek. Co do samych planów CMS napisał: „Nie zaproponowaliśmy przedłużeń ani zwolnień dla organizacji MA ani planów Medicaid managed care”. Stany mogą też ubiegać się o 90-procentowe, podwyższone federalne współfinansowanie budowy API, zatwierdzane indywidualnie w ramach APD.

Co musi robić każde API

Wszystkie cztery zależą od jednej rzeczy, której systemom budowanym na zamówienie często brakuje: uprzedniej autoryzacji w postaci ustrukturyzowanych danych z historią statusów. Wystarczy zbudować to raz, a wszystkie cztery będą z tego czytać.

Patient Access API: uzupełnienie o uprzednie autoryzacje

To API działa od 1 stycznia 2021 i obejmuje roszczenia, dane o udzielonych świadczeniach (encounters) oraz dane kliniczne. Od 2027 roku musi też przenosić każdą uprzednią autoryzację dotyczącą produktów i usług: jej status, datę zatwierdzenia lub odmowy, datę zakończenia, zatwierdzone produkty i usługi, konkretny powód w razie odmowy oraz powiązaną ustrukturyzowaną dokumentację od świadczeniodawcy. Dane muszą być dostępne „nie później niż 1 dzień roboczy po” otrzymaniu wniosku przez płatnika, aktualizowane w ciągu jednego dnia roboczego od każdej zmiany statusu i przechowywane, dopóki autoryzacja jest aktywna, oraz co najmniej rok po jej ostatniej zmianie.

System UM, który zapisuje decyzje jako notatki tekstowe albo przekazuje status wyłącznie faksem, nie dostarczy tych danych bez zmian.

Provider Access API

Świadczeniodawcy z sieci mogą zażądać danych pacjenta: roszczeń i świadczeń bez danych o płatnościach na rzecz świadczeniodawców (remittances) i bez udziału własnego pacjenta (cost-sharing), klas danych klinicznych USCDI (amerykańskiego standardowego zestawu danych do wymiany) oraz informacji o uprzedniej autoryzacji, z datami świadczeń od 1 stycznia 2016. Płatnik odpowiada w ciągu jednego dnia roboczego, ale wyłącznie w odniesieniu do pacjentów, których przypisał do danego świadczeniodawcy i którzy nie zgłosili sprzeciwu (opt-out).

Wymaga to trzech rzeczy, których starsze systemy rzadko mają. Pierwsza to proces przypisania (attribution), który wiąże ubezpieczonych ze świadczeniodawcami. Druga to sprzeciw, który ubezpieczony może zmienić w każdej chwili, wraz z powiadomieniami napisanymi prostym językiem przed pierwszym użyciem, w ciągu tygodnia od rozpoczęcia ochrony i co roku. Trzecia to eksport zbiorczy, bo wymagane standardy obejmują FHIR Bulk Data Access dla świadczeniodawcy, który pyta o całą swoją listę pacjentów.

Payer-to-Payer API

Gdy ubezpieczony dołącza do planu, nowy płatnik prosi o zgodę (tu obowiązuje opt-in) i w ciągu tygodnia od rozpoczęcia ochrony zaczyna ustalać poprzednich i równoległych płatników. Gdy już ich zna, w ciągu tygodnia żąda danych z pięciu lat: roszczeń i świadczeń bez danych o płatnościach i udziale własnym, danych USCDI oraz uprzednich autoryzacji z wyjątkiem odmownych, wraz z ich nieustrukturyzowaną dokumentacją. Poprzedni płatnik odpowiada w ciągu jednego dnia roboczego. Przy równoległym ubezpieczeniu wymiana powtarza się co najmniej raz na kwartał.

Trudna część to nie odpowiedź wychodząca. Trudne jest przyjmowanie danych od płatników, z którymi nigdy nie prowadzono testów, i włączanie ich do kartoteki ubezpieczonego, czego wymaga rozporządzenie.

Prior Authorization API

To API sięga rdzenia UM. Musi podawać listę objętych ochroną produktów i usług, które wymagają uprzedniej autoryzacji, wskazywać dokumentację wymaganą dla każdego z nich, obsługiwać wniosek i odpowiedź zgodne z HIPAA (federalną ustawą, która reguluje m.in. elektroniczne transakcje w ochronie zdrowia) oraz informować, czy płatnik zatwierdził wniosek (z datą zakończenia), odmówił (z konkretnym powodem), czy potrzebuje więcej informacji.

CMS zaleca tu, choć nie wymaga, trzy przewodniki implementacyjne Da Vinci: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) i Prior Authorization Support (PAS). W praktyce reguły zakresu ochrony i kwestionariusze dokumentacji muszą stać się czytelne maszynowo, zamiast istnieć jako podręcznik zasad w PDF. Płatnicy w ankiecie WEDI (amerykańskiej organizacji branżowej zajmującej się elektroniczną wymianą danych w ochronie zdrowia) wymienili „digitalizację zasad uprzedniej autoryzacji” wśród trzech największych wyzwań.

W samej transakcji HHS zostawił płatnikom swobodę. 28 lutego 2024 roku ogłosił odstąpienie od egzekwowania przepisów (enforcement discretion): według CMS jego zespół National Standards Group „nie będzie podejmować działań egzekucyjnych na podstawie HIPAA Administrative Simplification wobec podmiotów objętych HIPAA, które zdecydują się nie stosować standardu X12 278 w ramach elektronicznego procesu uprzedniej autoryzacji opartego na FHIR”. Można zbudować wyłącznie FHIR albo FHIR z X12 i równolegle utrzymać transakcję wyłącznie w X12.

Standardy

Wymagane standardy to HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access i OpenID Connect Core; płatnicy mogą dobrowolnie, pod pewnymi warunkami, stosować nowsze wersje. Rozporządzenie z 2024 roku wymieniało US Core 3.1.1 i SMART App Launch 1.0.0 z datą wygaśnięcia 1 stycznia 2026, więc wersje docelowe trzeba ustalić, zanim ktokolwiek zacznie pisać mapowanie.

Gdzie własne systemy zwykle nie wystarczają

Z tego, czego wymaga rozporządzenie, wynikają luki, których warto szukać w pierwszej kolejności:

• Uprzednia autoryzacja jako rekord, nie dokument. Status, znaczniki czasu, kody powodów odmowy i data zakończenia muszą być polami, zapisywanymi w chwili zmiany, z historią. Decyzja wysłana faksem potrzebuje ustrukturyzowanego odpowiednika.
• Reguły zakresu ochrony. To, które usługi wymagają autoryzacji i jakiej dokumentacji wymaga każda z nich, musi istnieć jako dane, które API może udostępnić. W wielu planach te informacje są w plikach PDF z zasadami i w głowach osób oceniających wnioski.
• Roszczenia jako FHIR. Roszczenia i świadczenia muszą wychodzić jako zasoby FHIR, bez danych o płatnościach i udziale własnym dla świadczeniodawców i innych płatników, ale z tymi danymi dla ubezpieczonego.
• Tożsamość i historia ubezpieczonego. Dopasowanie danych innego płatnika do własnego ubezpieczonego i ustalenie poprzednich płatników nowego ubezpieczonego wymaga danych demograficznych i historii ubezpieczenia, które mogą nie być przechowywane w jednym miejscu.
• Stan zgód. Sprzeciw (opt-out) dla Provider Access i zgoda (opt-in) dla Payer-to-Payer, każde do zmiany w dowolnym momencie i sprawdzane przy każdym żądaniu. Stan musi też przekazać zgodę beneficjenta planom Medicaid managed care tej osoby.
• Zegar jednego dnia roboczego. Nocne przetwarzanie wsadowe na mainframie wystarcza dla części danych, a dla innych jest za wolne. Trzeba mierzyć czas od decyzji do API, a nie tylko to, czy API odpowiada.
• Delegowani dostawcy. Jeśli decyzje podejmuje dostawca UM, któremu delegowano to zadanie, jego dane muszą docierać do płatnika na tyle wcześnie, by ten zdążył z obowiązkiem jednego dnia roboczego. Ankieta WEDI z lutego 2026 umieściła na pierwszym miejscu wśród wyzwań płatników „delegowane podmioty zewnętrzne, które mają trudności z łączeniem się z różnymi systemami”.

Na jakim etapie jest branża

Ankieta WEDI z lutego 2026, opublikowana 10 marca 2026, wykazała, że w przypadku wymogów dotyczących API „10% jeszcze nie rozpoczęło prac”, wobec 33% w październiku 2025. Odnotowała też „wyraźny wzrost udziału szacowanych kosztów przekraczających 5 mln USD, z 15% (paźdz. ’25) do 25% (luty ’26)”. Próba jest mała: 86 odpowiedzi, z czego 52% od płatników. To sygnał, a nie spis całej branży.

Plan na jedenaście tygodni do 1 stycznia 2027

Od połowy października organizacja MA albo stanowy program FFS ma około jedenastu tygodni. To za mało, by zbudować cztery API od zera, więc plan dotyczy kolejności i tego, co da się pokazać pierwszego dnia.

1. Ten tydzień: potwierdzenie terminu i punktu wyjścia. 1 stycznia czy późniejszy okres taryfowy albo rok polisowy? Spisać to, co już działa: Patient Access API i Provider Directory API, wskaźniki wymagane od 2026 roku, powody odmów.
2. Tygodnie od 1 do 2: przypisanie każdego elementu danych do źródła. Dla każdego API zapisać, który system przechowuje dziś dane (roszczenia, UM, ewidencja ubezpieczonych, sieć świadczeniodawców, dane kliniczne) i jak bardzo są aktualne.
3. Tygodnie od 1 do 3: decyzja, gdzie ma działać warstwa FHIR. Serwer FHIR albo fasada przed systemami odziedziczonymi, zasilana zdarzeniami zmian lub częstymi ekstraktami, jest zwykle szybszym rozwiązaniem niż uczenie systemu bazowego mówienia w FHIR. Najwięcej czasu zajmują mapowanie i zasilania danymi.
4. Tygodnie od 2 do 7: najpierw elementy wspólne. Rekord uprzedniej autoryzacji, zgody i przypisanie, dopasowywanie ubezpieczonych. Zależą od nich wszystkie cztery API.
5. Tygodnie od 4 do 9: budowa API. Uzupełnienia Patient Access, Provider Access z eksportem zbiorczym, Payer-to-Payer w obu kierunkach i Prior Authorization API z załadowanymi regułami zakresu ochrony.
6. Tygodnie od 8 do 11: testy z prawdziwymi partnerami. Dostawca EHR świadczeniodawcy, inny płatnik, delegowany dostawca UM. Przetestować zmiany zgód, odmowę z powodem i zmianę statusu, która dociera do ubezpieczonego w ciągu dnia roboczego.
7. 1 stycznia 2027: uruchomienie i pomiar. Od pierwszego dnia śledzić opóźnienia względem reguł jednego dnia roboczego i prowadzić datowaną listę tego, co nie jest skończone.

Jeśli jedenaście tygodni nie wystarczy, trzeba to zgłosić zespołowi ds. zgodności i prawnikom już teraz, a nie w grudniu, razem z planem, który pokazuje, co będzie działać 1 stycznia, a co i kiedy dojdzie później.

Plan Medicaid managed care z okresem taryfowym od 1 lipca 2027 albo ubezpieczyciel QHP z późniejszym rokiem polisowym może przejść te same kroki z większym zapasem czasu. Mimo to warto zacząć teraz: płatnicy i świadczeniodawcy, z którymi przyjdzie testować, startują 1 stycznia.

Co jeszcze może się zmienić

CMS-0062-P. 14 kwietnia 2026 CMS opublikował projekt kolejnego rozporządzenia. Na jego mocy obecnie zalecane przewodniki implementacyjne stałyby się obowiązkowe od 1 października 2027, od tej samej daty elektroniczna uprzednia autoryzacja objęłaby leki, a HHS przyjąłby FHIR jako standard HIPAA dla transakcji uprzedniej autoryzacji w miejsce X12 278. O obecnych terminach projekt mówi: „Ta propozycja nie zmieniłaby tych terminów zgodności”. Uwagi przyjmowano do 15 czerwca 2026, a na dzień 16 października 2026 ostateczne rozporządzenie nie ukazało się w Federal Register. Budować trzeba według rozporządzenia z 2024 roku, a wersje przewodników trzymać w jednym konfigurowalnym miejscu.

Wersje. Przewodniki Da Vinci wciąż się zmieniają. Ostateczne rozporządzenie IPPS na rok budżetowy 2027 zauważa, że systemy EHR certyfikowane według nowych kryteriów ONC (federalnego biura koordynującego IT w ochronie zdrowia) dotyczących uprzedniej autoryzacji „będą wymagać stosowania wersji 2.2 przewodników implementacyjnych Da Vinci”. To z tymi systemami będzie się komunikować Państwa Prior Authorization API.

Nic z tego nie jest powodem, by czekać. Rozporządzenie jest ostateczne, terminy są zapisane w tekście przepisów, a CMS powtórzył je 8 października.

Gdzie szukać pomocy

Pracujemy nad systemami, które stoją za API: mapowaniem danych o roszczeniach, świadczeniach i autoryzacjach do FHIR, strumieniami zmian ze starszych platform obsługi roszczeń i UM, logiką zgód i przypisań oraz testami, które pokazują, że reguły jednego dnia roboczego są dotrzymywane. Gdy system bazowy jest stary albo odeszli ludzie, którzy go zbudowali, ta praca zaczyna się od naszej usługi utrzymania systemów odziedziczonych, a jeśli termin wypada w środku wymiany platformy, warto zajrzeć na stronę o modernizacji ERP.

Jeśli Państwa platforma obsługi roszczeń lub UM należy do tych, dla których żaden dostawca nie przygotuje tych API, prosimy o wiadomość na office@c9group.dev. Jesteśmy inżynierami, a nie prawnikami specjalizującymi się w ochronie zdrowia: kwestie zakresu i umów należą do Państwa prawników, a my budujemy zgodnie z ich odpowiedzią.