CMS-0057-F és 2027. január 1.: finanszírozói API-k saját elszámolási és előzetes engedélyezési rendszereken

2027. január 1-jéig a Medicare Advantage-szervezeteknek (a Medicare-t magánbiztosítóként nyújtó cégeknek), valamint az állami Medicaid- és CHIP-programok (az alacsony jövedelműek, illetve a gyermekek közfinanszírozott egészségbiztosítása) fee-for-service (FFS, szolgáltatásonkénti térítésű) ágainak négy FHIR API-t kell működtetniük a CMS interoperabilitásról és előzetes engedélyezésről szóló végleges rendelete (CMS Interoperability and Prior Authorization final rule, CMS-0057-F) alapján: a meglévő Patient Access API-t, kibővítve az előzetes engedélyezési adatokkal, valamint az új Provider Access, Payer-to-Payer és Prior Authorization API-t. A Medicaid managed care (irányított ellátási) tervek, a CHIP managed care szervezetek és a szövetségi biztosítási piactereken (exchanges) Qualified Health Plan (QHP) terveket kínáló biztosítók az ezen a napon vagy azt követően kezdődő első díjszámítási időszakuktól (rating period), illetve biztosítási évüktől (plan year) követik őket. 2026. október 16-án ez tizenegy hét múlva esedékes, és a CMS nem halasztotta el.

A rendelet működési fele már hatályban van. 2026 óta az érintett finanszírozóknak minden elutasított előzetes engedélyezési kérelemnél konkrét indokot kell adniuk, rögzített határidőkön belül kell dönteniük, és közzé kell tenniük az előzetes engedélyezési mutatóikat.

Ha az elszámolási (claims), igénybevétel-menedzsment (utilization management, UM) és biztosítotti rendszerei olyan szoftvergyártótól származnak, amely ezt a négy API-t is szállítja, a fejlesztés nagy része a gyártó dolga. Az Ön feladata a konfiguráció, a digitalizált előzetes engedélyezési szabályok, a biztosítottaknak szóló értesítések és a partnerekkel végzett tesztelés.

Ez a cikk a többieknek szól: azoknak a terveknek és állami hivataloknak, amelyek elszámolási motorja, UM-folyamata vagy biztosítotti adatai saját tulajdonú rendszerben futnak, legyen az házon belül fejlesztett, a frissíthetőség határán túl testre szabott, vagy évtizedek helyi módosításait hordozó Medicaid Management Information System (MMIS, az állami Medicaid-programok informatikai rendszere). Ezekhez senki nem szállítja az API-kat. Mérnökök vagyunk, nem jogászok: ez a cikk azt magyarázza el, mit vár el a rendelet egy rendszertől, nem azt, hogyan vonatkozik az Ön szerződéseire.

A dátumok

A végleges rendelet 2024. február 8-án jelent meg a Federal Registerben, az amerikai szövetségi hivatalos lapban, és 2024. április 8-án lépett hatályba. Mind a négy API-ra ugyanazokat a határidőket szabja meg: „2027. január 1-jéig az MA szervezetek és az állami Medicaid- és CHIP FFS-programok esetében; a 2027. január 1-jén vagy azt követően kezdődő díjszámítási időszakig a Medicaid managed care tervek és a CHIP managed care szervezetek esetében; valamint a 2027. január 1-jén vagy azt követően kezdődő biztosítási évekre az FFE-ken működő QHP-biztosítók esetében”.

Egy Medicaid managed care tervnek, amelynek díjszámítási időszakai július 1-jén kezdődnek, így 2027. július 1-jéig van ideje. Egy naptári éves szerződéssel működő tervnek viszont nincs ennyi ideje.

A CMS továbbra is ugyanazt a dátumot adja meg. A rendeletről szóló tájékoztató oldala, amelyet utoljára 2026. október 8-án módosítottak, azt írja, hogy „az érintett finanszírozóknak elsősorban 2027. január 1-jéig van idejük teljesíteni az e végleges rendeletben foglalt, alkalmazásprogramozási felületre (API) vonatkozó követelményeket”.

A 2026-os kötelezettségek a CMS tájékoztatójának megfogalmazásában: döntés „gyorsított (azaz sürgős) kérelmek esetén 72 órán belül, standard (azaz nem sürgős) kérelmek esetén hét naptári napon belül” (a piactereken működő QHP-biztosítókra ezek a határidők nem vonatkoznak), konkrét indok minden elutasításnál, valamint nyilvános mutatók, azzal, hogy „a mutatók első csomagját 2026. március 31-ig kell jelenteni”. A Patient Access API használatát szintén minden évben március 31-ig kell jelenteni a CMS-nek. Ha ezek közül bármi még nem működik, az már késésben van, és ugyanazokra az adatokra épül, mint az API-k.

A gyógyszerek mindebből kimaradnak. A CMS-0057-F minden előzetes engedélyezési rendelkezése kizárja őket.

Kire vonatkozik, és kire nem

A rendelet érintett finanszírozóknak (impacted payers) nevezi őket: Medicare Advantage (MA) szervezetek, állami Medicaid- és CHIP fee-for-service (FFS) programok, Medicaid managed care tervek, CHIP managed care szervezetek, valamint a Federally-facilitated Exchanges (FFE-k, szövetségi működtetésű piacterek) QHP-biztosítói. Hatásvizsgálata „365 anyaszervezetet, köztük állami Medicaid- és CHIP-hivatalokat” vesz számba, amelyek „felelősek három új API bevezetéséért és fenntartásáért”, és megjegyzi, hogy „az ebbe a kategóriába tartozó finanszírozók 75 százalékának 500-nál kevesebb alkalmazottja van”. Sokuk regionális terv, nagy platformcsapat nélkül.

Nem tartoznak a hatály alá, legalábbis közvetlenül nem:

• Az e programokon kívüli munkáltatói tervek és az Original Medicare (a hagyományos, állami Medicare). Nem szerepelnek az érintett finanszírozók listáján.
• Az ellátók (providers). Az ő oldalukat az Electronic Prior Authorization measure jelenti, a Medicare Promoting Interoperability programjainak egyik mutatója, amelyet tanúsított EHR-technológiával teljesítenek. A 2026. augusztus 4-i FY 2027 IPPS végleges rendelet (a Medicare kórházi fekvőbeteg-ellátásának finanszírozásáról) ezt 2027-re a kórházak számára választható bónuszmutatóvá tette.
• A delegált UM-szervezetek és a TPA-k (külső adminisztrátorok). Saját kötelezettségük nincs, de a finanszírozóé az ő rendszereiken keresztül valósul meg. A QHP-biztosítókról a rendelet megismétli, hogy „felelősek saját megfelelésükért, valamint bármely delegált vagy továbbszerződött szervezet megfeleléséért”.

Kevés a kiút, és ilyen későn egyik sem segít sokat. Egy állam egyszeri, egyéves halasztást kérhet Medicaid- vagy CHIP FFS-programjára, de a kérelmet az Advance Planning Documentben (APD, az a tervezési dokumentum, amellyel az állam szövetségi támogatást kér informatikai fejlesztéseire) kell benyújtania, és azt „a megfelelési határidő előtt jóvá kell hagyni”. Az az állam, amelyben a Medicaid-kedvezményezettek legalább 90 százaléka managed care tervben van, mentességet kérhet, a QHP-biztosítók pedig kivételt kérhetnek a piactértől. Magukról a tervekről a CMS ezt írta: „Nem javasoltunk halasztást vagy mentességet az MA szervezetek vagy a Medicaid managed care tervek számára.” Az államok az API-k kiépítésére 90 százalékos emelt szövetségi társfinanszírozást is igényelhetnek, amelyet esetenként, az APD-n keresztül hagynak jóvá.

Mit kell tudnia az egyes API-knak

Mind a négy egyetlen dolgon múlik, amely egy egyedi rendszerből gyakran hiányzik: az előzetes engedélyezésen mint strukturált adaton, állapotelőzményekkel. Ha ezt egyszer megépíti, mind a négy ebből olvas.

Patient Access API: bővítés az előzetes engedélyekkel

Ezt az API-t 2021. január 1. óta működteti az elszámolásokhoz, az ellátási eseményekhez (encounters) és a klinikai adatokhoz. 2027-től minden termékre és szolgáltatásra vonatkozó előzetes engedélyt is tartalmaznia kell: az engedély állapotát, a jóváhagyás vagy elutasítás dátumát, a lejáratát, a jóváhagyott termékeket és szolgáltatásokat, elutasítás esetén a konkrét indokot, valamint az ellátótól kapott kapcsolódó strukturált dokumentációt. Az adatoknak „legkésőbb 1 munkanappal azután” elérhetőnek kell lenniük, hogy a finanszírozó megkapta a kérelmet, minden állapotváltozás után egy munkanapon belül frissülniük kell, és meg kell őrizni őket, amíg az engedély érvényes, majd az utolsó változását követően még legalább egy évig.

Egy UM-rendszer, amely a döntéseket szabad szöveges jegyzetként rögzíti, vagy az állapotot csak faxon küldi, ezt módosítás nélkül nem tudja kiszolgálni.

Provider Access API

A hálózatba tartozó ellátók lekérhetik egy beteg adatait: az elszámolásokat és ellátási eseményeket az ellátói kifizetési adatok (remittances) és a beteg önrésze (cost-sharing) nélkül, az USCDI (az amerikai egészségügyi interoperabilitási alapadatkészlet) klinikai adatosztályait és az előzetes engedélyezési információkat, a 2016. január 1-jétől kezdődő ellátási dátumokra. A finanszírozó egy munkanapon belül válaszol, de csak azokra a betegekre, akiket az adott ellátóhoz rendelt, és akik nem éltek a kimaradás (opt-out) lehetőségével.

Ehhez három dolog kell, ami egy régi rendszerben ritkán van meg. Egy hozzárendelési folyamat (attribution), amely a biztosítottakat ellátókhoz köti. Egy opt-out, amelyen a biztosított bármikor változtathat, közérthető tájékoztatással az első használat előtt, a biztosítás kezdetétől számított egy héten belül és évente. És tömeges export, mert a kötelező szabványok között szerepel a FHIR Bulk Data Access arra az esetre, ha egy ellátó a teljes betegkörére kérdez rá.

Payer-to-Payer API

Amikor egy biztosított csatlakozik, az új finanszírozó engedélyt kér (itt opt-in, vagyis kifejezett hozzájárulás kell), és a biztosítás kezdetétől számított egy héten belül elkezdi azonosítani a korábbi és párhuzamos finanszírozókat. Ha megvannak, egy héten belül öt évre visszamenőleg kéri le az adatokat: az elszámolásokat és ellátási eseményeket a kifizetési adatok és az önrész nélkül, az USCDI-adatokat, valamint az előzetes engedélyeket az elutasítottak kivételével, a hozzájuk tartozó strukturálatlan dokumentációval együtt. A korábbi finanszírozó egy munkanapon belül válaszol. Párhuzamos biztosítás esetén a csere legalább negyedévente megismétlődik.

A nehéz rész nem a kimenő válasz. Az a nehéz, hogy olyan finanszírozóktól kell adatokat átvennie, amelyekkel soha nem tesztelt, és ezeket a rendelet előírása szerint be kell építenie a biztosítotti nyilvántartásba.

Prior Authorization API

Ez az az API, amely az UM magjáig ér. Fel kell sorolnia azokat a fedezett termékeket és szolgáltatásokat, amelyekhez előzetes engedély kell, meg kell adnia az egyes tételekhez szükséges dokumentációt, támogatnia kell a HIPAA-nak (az amerikai egészségügyi adatcseréről és adatvédelemről szóló szövetségi törvénynek) megfelelő kérelmet és választ, és közölnie kell, hogy a finanszírozó jóváhagyta-e a kérelmet (a lejárat dátumával), elutasította-e (konkrét indokkal), vagy további információra van-e szüksége.

A CMS itt három Da Vinci implementációs útmutatót ajánl, de nem ír elő: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) és Prior Authorization Support (PAS). A gyakorlatban a fedezeti szabályoknak és a dokumentációs kérdőíveknek géppel olvashatóvá kell válniuk, PDF-es szabálykézikönyv helyett. A WEDI (az amerikai egészségügyi elektronikus adatcserével foglalkozó szakmai szervezet) felmérésében a finanszírozók „az előzetes engedélyezési szabályzatok digitalizálását” a három legnagyobb kihívásuk közé sorolták.

Magára a tranzakcióra a HHS mozgásteret hagyott a finanszírozóknak. 2024. február 28-án bejelentette, hogy eltekint a jogérvényesítéstől (enforcement discretion): a CMS szerint a hivatal National Standards Group nevű egysége „nem indít HIPAA Administrative Simplification szerinti végrehajtási eljárást azokkal a HIPAA hatálya alá tartozó szervezetekkel szemben, amelyek úgy döntenek, hogy egy elektronikus, FHIR-alapú előzetes engedélyezési folyamat részeként nem használják az X12 278 szabványt”. Építhet csak FHIR-t, vagy FHIR-t X12-vel, és mellette megtarthat egy csak X12-es tranzakciót is.

A szabványok

A kötelező szabványok a HL7 FHIR Release 4.0.1, a US Core, a SMART App Launch, a Bulk Data Access és az OpenID Connect Core; a finanszírozók bizonyos feltételekkel önkéntesen újabb verziókat is használhatnak. A 2024-es rendelet a US Core 3.1.1-et és a SMART App Launch 1.0.0-t 2026. január 1-jei lejárattal sorolta fel, ezért döntse el, melyik verziókra fejleszt, mielőtt bárki megírná a leképezést.

Hol maradnak el jellemzően a saját rendszerek

A rendelet elvárásaiból kiindulva ezeket a hiányokat érdemes először keresni:

• Az előzetes engedély mint rekord, nem dokumentum. Az állapotnak, az időbélyegeknek, az elutasítási okkódoknak és a lejárat dátumának mezőknek kell lenniük, amelyek változáskor íródnak, előzményekkel együtt. A faxon küldött döntésnek strukturált megfelelőre van szüksége.
• A fedezeti szabályok. Hogy mely szolgáltatásokhoz kell engedély, és melyikhez milyen dokumentáció, annak az API által kiszolgálható adatnak kell lennie. Sok tervnél ez szabályzati PDF-ekben és a bírálók fejében van.
• Elszámolások FHIR-ként. Az elszámolásoknak és az ellátási eseményeknek FHIR-erőforrásként kell kikerülniük, az ellátók és más finanszírozók felé a kifizetési adatok és az önrész nélkül, a biztosított felé azonban azokkal együtt.
• A biztosított azonosítása és előzményei. Ahhoz, hogy egy másik finanszírozó adatait a saját biztosítottjához rendelje, és megtalálja egy új biztosított korábbi finanszírozóit, demográfiai adatokra és biztosítási előzményekre van szükség, amelyeket lehet, hogy nem egy helyen tárol.
• A hozzájárulások állapota. Opt-out a Provider Accesshez és opt-in a Payer-to-Payerhez, mindkettő bármikor módosítható, és minden kérésnél ellenőrizni kell. Az államnak a kedvezményezett opt-in hozzájárulását az illető Medicaid managed care terveinek is tovább kell adnia.
• Az egy munkanapos határidő. Egy éjszakai mainframe-kötegfutás egyes adatokhoz elég, másokhoz túl lassú. A döntéstől az API-ig eltelt időt mérje, ne csak azt, hogy az API válaszol-e.
• Delegált szállítók. Ha a döntéseket egy delegált UM-szállító hozza, az adatainak időben el kell jutniuk Önhöz, hogy teljesíteni tudja az egy munkanapos kötelezettségét. A WEDI 2026. februári felmérésében a finanszírozók kihívásainak listáját ez vezette: „a különböző rendszerekhez való kapcsolódás nehézségeivel küzdő delegált harmadik felek”.

Hol tart az iparág

A WEDI 2026. februári felmérése, amelyet 2026. március 10-én tettek közzé, azt találta, hogy az API-követelmények terén „10% még nem kezdte el a munkát”, szemben a 2025. októberi 33%-kal. Arról is beszámolt, hogy „jelentősen nőtt az 5 millió dollárt meghaladó becsült költség aránya, 15%-ról (’25 okt.) 25%-ra (’26 febr.)”. A minta kicsi: 86 válasz, ezek 52%-a finanszírozóktól. Jelzésként érdemes olvasni, nem teljes körű felmérésként.

Tizenegy hetes terv 2027. január 1-jéig

Október közepétől egy MA szervezetnek vagy egy állami FFS-programnak nagyjából tizenegy hete van. Ez nem elég ahhoz, hogy a semmiből felépítsen négy API-t, ezért a terv a sorrendről szól, és arról, mit tud felmutatni az első napon.

1. Ezen a héten: erősítse meg a határidejét és a kiindulópontját. Január 1-je, vagy egy későbbi díjszámítási időszak, illetve biztosítási év? Írja össze, mi működik már: a Patient Access és a Provider Directory API, a 2026-os mutatók, az elutasítási indokok.
2. Az 1. héttől a 2. hétig: rendeljen minden adatelemet a forrásához. Minden API-nál írja le, melyik rendszer tárolja ma az adatot (elszámolás, UM, biztosítotti nyilvántartás, ellátói hálózat, klinikai adatok), és mennyire friss.
3. Az 1. héttől a 3. hétig: döntse el, hol fut a FHIR-réteg. Egy FHIR-szerver vagy homlokzat (facade) a régi rendszerek előtt, amelyet változási események vagy gyakori kivonatok táplálnak, általában gyorsabb megoldás, mint FHIR-re tanítani a központi rendszert. Az idő a leképezésre és az adatfolyamokra megy el.
4. A 2. héttől a 7. hétig: először a közös elemeket építse meg. Az előzetes engedélyezési rekordot, a hozzájárulásokat és a hozzárendelést, a biztosítottak párosítását. Mind a négy API ezekre épül.
5. A 4. héttől a 9. hétig: építse meg az API-kat. A Patient Access bővítéseit, a Provider Accesst tömeges exporttal, a Payer-to-Payert mindkét irányban és a Prior Authorization API-t a betöltött fedezeti szabályokkal.
6. A 8. héttől a 11. hétig: teszteljen valódi partnerekkel. Egy ellátó EHR-szállítójával, egy másik finanszírozóval, a delegált UM-szállítójával. Tesztelje a hozzájárulások változását, egy elutasítást az indokával, és egy olyan állapotváltozást, amely egy munkanapon belül eljut a biztosítotthoz.
7. 2027. január 1.: induljon élesben, és mérjen. Az első naptól kövesse a késleltetést az egy munkanapos szabályokhoz képest, és vezessen dátumozott listát arról, mi nincs még kész.

Ha tizenegy hét nem elég, ezt most vigye a megfelelőségi csapata és a jogi tanácsadója elé, ne decemberben, egy olyan tervvel, amely megmutatja, mi lesz éles január 1-jén, és mi mikor következik utána.

Egy 2027. július 1-jén kezdődő díjszámítási időszakú Medicaid managed care terv vagy egy későbbi biztosítási évű QHP-biztosító ugyanezeket a lépéseket több idővel követheti. Ennek ellenére kezdjen most: azok a finanszírozók és ellátók, akikkel tesztelni fog, január 1-jén élesítenek.

Mi változhat még

CMS-0062-P. 2026. április 14-én a CMS közzétett egy kiegészítő rendelettervezetet. Ez 2027. október 1-jétől kötelezővé tenné a jelenleg ajánlott implementációs útmutatókat, ugyanettől a dátumtól az elektronikus előzetes engedélyezést a gyógyszerekre is kiterjesztené, és a HHS az X12 278 helyett a FHIR-t fogadná el HIPAA-szabványként az előzetes engedélyezési tranzakciókhoz. A meglévő határidőkről ezt írja: „Ez a javaslat nem változtatná meg ezeket a megfelelési határidőket.” Az észrevételezési időszak 2026. június 15-én lezárult, és 2026. október 16-ig nem jelent meg végleges rendelet a Federal Registerben. A 2024-es rendeletre fejlesszen, és az útmutatók verzióit egyetlen konfigurálható helyen tartsa.

Verziók. A Da Vinci-útmutatók folyamatosan változnak. Az FY 2027 IPPS végleges rendelet megjegyzi, hogy az ONC (az amerikai egészségügyi informatikáért felelős szövetségi hivatal) új előzetes engedélyezési kritériumai szerint tanúsított EHR-ek „a Da Vinci IG-k 2.2-es verziójának használatát fogják megkövetelni”. Az Ön Prior Authorization API-ja ezekkel a rendszerekkel fog kommunikálni.

Mindez nem ok a várakozásra. A rendelet végleges, a dátumok a rendelet szövegében szerepelnek, és a CMS október 8-án megismételte őket.

Hol kaphat segítséget

Az API-k mögötti rendszereken dolgozunk: az elszámolások, az ellátási események és az engedélyek adatainak FHIR-leképezésén, a régebbi elszámolási és UM-platformokból kivezetett változási adatfolyamokon, a hozzájárulási és hozzárendelési logikán, valamint azokon a teszteken, amelyek igazolják, hogy az egy munkanapos szabályok teljesülnek. Ha a központi rendszer régi, vagy már nincsenek ott, akik építették, ez a munka a régi rendszerek karbantartására vonatkozó szolgáltatásunkkal kezdődik, ha pedig a határidő egy platformcsere közepére esik, nézze meg az ERP-modernizációs oldalunkat.

Ha az elszámolási vagy UM-platformja olyan, amelyhez egyetlen gyártó sem fogja elkészíteni ezeket az API-kat, írjon az office@c9group.dev címre. Mérnökök vagyunk, nem egészségügyi jogászok: a hatály és a szerződések kérdései a jogi tanácsadójára tartoznak, mi pedig az ő válasza szerint építünk.