CMS-0057-F ja 1. tammikuuta 2027: maksajien rajapinnat omissa korvaus- ja ennakkohyväksyntäjärjestelmissä

Medicare Advantage -organisaatioilla (yksityiset Medicare-vakuuttajat) ja osavaltioiden suoriteperusteisilla (fee-for-service) Medicaid- ja CHIP-ohjelmilla (pienituloisten ja lasten julkinen terveysturva) on oltava 1. tammikuuta 2027 mennessä käytössä neljä FHIR-rajapintaa. Sitä edellyttää CMS Interoperability and Prior Authorization final rule (CMS-0057-F), yhteentoimivuutta ja ennakkohyväksyntää koskeva lopullinen sääntö, jonka on antanut Medicarea ja Medicaidia hallinnoiva liittovaltion virasto CMS. Rajapinnat ovat jo käytössä oleva Patient Access API, jota laajennetaan ennakkohyväksyntätiedoilla, sekä uudet Provider Access API, Payer-to-Payer API ja Prior Authorization API. Medicaid managed care -vakuuttajat, CHIP managed care -toimijat ja liittovaltion markkinapaikoilla toimivat Qualified Health Plan (QHP) -vakuutusten myöntäjät seuraavat ensimmäisestä sopimuskaudesta (rating period) tai vakuutusvuodesta (plan year), joka alkaa tuona päivänä tai sen jälkeen. Nyt, 16. lokakuuta 2026, siihen on yksitoista viikkoa, eikä CMS ole siirtänyt päivämäärää.

Säännön toiminnallinen puolisko on jo voimassa. Vuodesta 2026 lähtien sääntelyn piiriin kuuluvien maksajien (impacted payers: vakuuttajat ja ohjelmat, joita sääntö koskee) on pitänyt perustella jokainen kielteinen ennakkohyväksyntäpäätös yksilöidysti, tehdä päätökset kiinteissä määräajoissa ja julkaista ennakkohyväksyntöjä koskevia tunnuslukuja.

Jos korvauskäsittelyn, utilization managementin (UM, hoidon tarpeellisuuden ja korvattavuuden arviointi) ja vakuutettujen tietojen järjestelmät tulevat ohjelmistotoimittajalta, joka tuo nämä neljä rajapintaa valmiina, suurin osa rakentamisesta on toimittajan työtä. Oma osuutesi on konfigurointi, digitoidut ennakkohyväksyntäsäännöt, vakuutetuille lähetettävät ilmoitukset ja testaus kumppanien kanssa.

Tämä artikkeli on tarkoitettu muille: vakuuttajille ja virastoille, joiden korvauskäsittelymoottori, UM-työnkulku tai vakuutettujen tiedot ovat niiden omassa järjestelmässä, olipa se itse rakennettu, räätälöity niin pitkälle, ettei sitä enää voi päivittää, tai Medicaid Management Information System (MMIS, osavaltion Medicaid-hallinnon tietojärjestelmä), johon on vuosikymmenten aikana kertynyt paikallisia muutoksia. Niihin kukaan ei toimita rajapintoja valmiina. Olemme insinöörejä, emme juristeja: kerromme, mitä sääntö edellyttää järjestelmältä, emme sitä, miten se koskee omia sopimuksiasi.

Päivämäärät

Lopullinen sääntö julkaistiin liittovaltion virallisessa lehdessä Federal Registerissä 8. helmikuuta 2024, ja se tuli voimaan 8. huhtikuuta 2024. Kaikille neljälle rajapinnalle se asettaa samat määräajat: ”viimeistään 1. tammikuuta 2027 MA-organisaatioille sekä osavaltioiden suoriteperusteisille (FFS) Medicaid- ja CHIP-ohjelmille; viimeistään 1. tammikuuta 2027 tai sen jälkeen alkavalla sopimuskaudella Medicaid managed care -vakuuttajille ja CHIP managed care -toimijoille; ja 1. tammikuuta 2027 tai sen jälkeen alkavista vakuutusvuosista alkaen QHP-vakuutusten myöntäjille FFE-markkinapaikoilla”.

Medicaid managed care -vakuuttajalla, jonka sopimuskaudet alkavat 1. heinäkuuta, on siis aikaa 1. heinäkuuta 2027 asti. Kalenterivuoden mukaisella sopimuksella toimivalla vakuuttajalla ei ole.

CMS pitää yhä kiinni samasta päivämäärästä. Viraston sivu säännöstä, jota on viimeksi muokattu 8. lokakuuta 2026, toteaa, että ”sääntelyn piiriin kuuluvilla maksajilla on pääosin 1. tammikuuta 2027 asti aikaa täyttää tämän lopullisen säännön sovellusrajapintaa (API) koskevat vaatimukset”.

Vuoden 2026 velvoitteet ovat CMS:n tiedotteen sanoin päätökset ”72 tunnin kuluessa nopeutetuissa (eli kiireellisissä) pyynnöissä ja seitsemän kalenteripäivän kuluessa tavanomaisissa (eli ei-kiireellisissä) pyynnöissä” (markkinapaikkojen QHP-vakuutusten myöntäjät on rajattu määräaikojen ulkopuolelle), yksilöity peruste jokaiselle kielteiselle päätökselle ja julkiset tunnusluvut, joista ”ensimmäiset tunnusluvut on raportoitava 31. maaliskuuta 2026 mennessä”. Myös Patient Access API:n käytöstä raportoidaan CMS:lle vuosittain 31. maaliskuuta mennessä. Jos jokin tästä ei ole vielä käytössä, se on jo myöhässä, ja se nojaa samoihin tietoihin kuin rajapinnat.

Lääkkeet jäävät kaiken tämän ulkopuolelle. Jokainen CMS-0057-F:n ennakkohyväksyntää koskeva säännös rajaa ne pois.

Keitä sääntö koskee ja keitä ei

Sääntö kutsuu niitä nimellä impacted payers: Medicare Advantage (MA) -organisaatiot, osavaltioiden suoriteperusteiset (FFS) Medicaid- ja CHIP-ohjelmat, Medicaid managed care -vakuuttajat, CHIP managed care -toimijat sekä QHP-vakuutusten myöntäjät liittovaltion ylläpitämillä Federally-facilitated Exchanges (FFEs) -markkinapaikoilla. Säännön vaikutusarvio mainitsee ”365 emo-organisaatiota, mukaan lukien osavaltioiden Medicaid- ja CHIP-virastot”, jotka ”vastaavat kolmen uuden rajapinnan käyttöönotosta ja ylläpidosta”, ja toteaa, että ”75 prosentilla tämän luokan maksajista on alle 500 työntekijää”. Moni on alueellinen vakuuttaja ilman suurta alustatiimiä.

Ainakaan suoraan soveltamisalaan eivät kuulu:

• Näiden ohjelmien ulkopuoliset työnantajien vakuutukset sekä Original Medicare (valtion itse hoitama perinteinen Medicare). Ne eivät ole sääntelyn piiriin kuuluvien maksajien luettelossa.
• Palveluntuottajat. Niiden puolella vastine on Medicaren Promoting Interoperability -ohjelmien Electronic Prior Authorization -mittari, joka täytetään sertifioidulla potilastietojärjestelmäteknologialla (certified EHR technology). Medicaren sairaalakorvauksia koskeva vuosittainen sääntö, 4. elokuuta 2026 annettu FY 2027 IPPS final rule, teki siitä sairaaloille vapaaehtoisen bonusmittarin vuodelle 2027.
• Delegoidut UM-toimijat ja TPA:t (ulkopuoliset hallinnointipalvelujen tarjoajat). Niillä ei ole omaa velvoitetta, mutta maksajan velvoite kulkee niiden järjestelmien kautta. QHP-vakuutusten myöntäjistä sääntö toistaa, että ne ”vastaavat omasta vaatimustenmukaisuudestaan ja kaikkien delegoitujen tai alempana ketjussa toimivien tahojen vaatimustenmukaisuudesta”.

Pakoteitä on vähän, eikä yksikään niistä auta paljon näin myöhään. Osavaltio voi hakea FFS-pohjaiselle Medicaid- tai CHIP-ohjelmalleen kertaluonteista vuoden lisäaikaa, mutta hakemus tehdään sen Advance Planning Documentissa (APD, osavaltion suunnitteluasiakirja liittovaltion tietojärjestelmärahoitusta varten), ja se on ”hyväksyttävä ennen määräpäivää”. Osavaltio, jonka Medicaid-edunsaajista vähintään 90 prosenttia on managed care -piirissä, voi hakea vapautusta, ja QHP-vakuutusten myöntäjät voivat pyytää markkinapaikalta poikkeusta. Itse vakuuttajista CMS kirjoitti: ”Emme ehdottaneet lisäaikoja tai vapautuksia MA-organisaatioille tai Medicaid managed care -vakuuttajille.” Osavaltiot voivat myös hakea rajapintojen rakentamiseen 90 prosentin korotettua liittovaltion vastinrahoitusta (enhanced federal matching funds), joka hyväksytään tapauskohtaisesti APD:n kautta.

Mitä kunkin rajapinnan on tehtävä

Kaikki neljä nojaavat yhteen asiaan, joka räätälöidystä järjestelmästä usein puuttuu: ennakkohyväksyntään rakenteisena tietona, jolla on tilahistoria. Rakenna se kerran, niin kaikki neljä lukevat siitä.

Patient Access API: ennakkohyväksynnät mukaan

Tämä rajapinta on ollut sinulla käytössä 1. tammikuuta 2021 lähtien korvausvaatimuksia (claims), käyntitietoja (encounters) ja kliinisiä tietoja varten. Vuodesta 2027 sen on välitettävä myös jokainen tarvikkeita ja palveluja koskeva ennakkohyväksyntä: sen tila, hyväksymis- tai hylkäyspäivä, päättymispäivä, hyväksytyt tarvikkeet ja palvelut, yksilöity peruste, jos hakemus on hylätty, sekä palveluntuottajalta saatu siihen liittyvä rakenteinen dokumentaatio. Tietojen on oltava saatavilla ”viimeistään 1 arkipäivän kuluttua” siitä, kun maksaja vastaanottaa pyynnön, ne on päivitettävä yhden arkipäivän kuluessa jokaisesta tilamuutoksesta, ja ne on säilytettävä niin kauan kuin hyväksyntä on voimassa ja vähintään vuoden ajan sen viimeisimmästä muutoksesta.

UM-järjestelmä, joka kirjaa päätökset vapaamuotoisina muistiinpanoina tai lähettää tilatiedon vain faksilla, ei pysty tuottamaan tätä ilman muutoksia.

Provider Access API

Verkostoon kuuluvat palveluntuottajat voivat pyytää potilaan tietoja: korvausvaatimukset ja käyntitiedot ilman palveluntuottajien maksuerittelyjä (remittances) tai omavastuita (cost-sharing), USCDI:n (Yhdysvaltain kliinisten ydintietojen määrittely) kliiniset tietoluokat sekä ennakkohyväksyntätiedot, 1. tammikuuta 2016 alkaen annetuista palveluista. Maksaja vastaa yhden arkipäivän kuluessa, mutta vain niiden potilaiden osalta, jotka se on kohdentanut kyseiselle palveluntuottajalle ja jotka eivät ole kieltäneet tietojensa luovutusta.

Siihen tarvitaan kolme asiaa, joita vanhassa järjestelmässä on harvoin. Kohdentamisprosessi (attribution), joka liittää vakuutetut palveluntuottajiin. Kieltomahdollisuus (opt-out), jota vakuutettu voi muuttaa milloin tahansa, ja siitä kertovat selkeäkieliset ilmoitukset ennen ensimmäistä käyttöä, viikon kuluessa vakuutuksen alkamisesta ja joka vuosi. Ja massavienti, koska vaadittuihin standardeihin kuuluu FHIR Bulk Data Access palveluntuottajalle, joka hakee tietoja koko potilasjoukostaan.

Payer-to-Payer API

Kun uusi vakuutettu liittyy, maksaja pyytää häneltä lupaa (tässä tarvitaan suostumus, opt-in) ja ryhtyy viikon kuluessa vakuutuksen alkamisesta selvittämään hänen aiemmat ja samanaikaiset maksajansa. Kun ne ovat tiedossa, se pyytää viikon kuluessa viiden vuoden tiedot: korvausvaatimukset ja käyntitiedot ilman maksuerittelyjä tai omavastuita, USCDI-tiedot sekä muut kuin hylätyt ennakkohyväksynnät rakenteettomine dokumentteineen. Edellinen maksaja vastaa yhden arkipäivän kuluessa. Jos vakuutuksia on samanaikaisesti useampi, tiedonvaihto toistetaan vähintään neljännesvuosittain.

Vaikein osa ei ole lähtevä vastaus. Vaikeinta on ottaa vastaan tietoja maksajilta, joiden kanssa et ole koskaan testannut, ja yhdistää ne vakuutetun tietoihin, kuten sääntö edellyttää.

Prior Authorization API

Tämä rajapinta ulottuu UM-järjestelmän ytimeen asti. Rajapinnan on lueteltava ne korvattavat tarvikkeet ja palvelut, jotka edellyttävät ennakkohyväksyntää, kerrottava kunkin vaatima dokumentaatio, tuettava HIPAA:n mukaista pyyntöä ja vastausta sekä kerrottava, onko maksaja hyväksynyt (päättymispäivineen) tai hylännyt (yksilöidyin perustein) pyynnön vai tarvitseeko se lisätietoja.

CMS suosittelee tähän, mutta ei vaadi, kolmea HL7:n Da Vinci -hankkeen toteutusopasta: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) ja Prior Authorization Support (PAS). Käytännössä korvattavuussääntöjen ja dokumentaatiokyselyjen on muututtava koneluettaviksi; PDF-muotoinen ohjekirja ei riitä. WEDI:n (Workgroup for Electronic Data Interchange, yhdysvaltalainen terveydenhuollon sähköisen tiedonsiirron järjestö) kyselyssä maksajat nimesivät ”ennakkohyväksyntäkäytäntöjen digitoinnin” kolmen suurimman haasteensa joukkoon.

Itse transaktion osalta HHS antoi maksajille liikkumavaraa. Se ilmoitti 28. helmikuuta 2024 käyttävänsä harkintaa valvonnassa (enforcement discretion): CMS:n mukaan viraston National Standards Group ”ei ryhdy HIPAA Administrative Simplification -säännösten mukaisiin täytäntöönpanotoimiin sellaisia HIPAA:n piiriin kuuluvia tahoja vastaan, jotka päättävät olla käyttämättä X12 278 -standardia osana sähköistä FHIR-pohjaista ennakkohyväksyntäprosessia”. Voit rakentaa pelkän FHIR-ratkaisun tai FHIR:n ja X12:n yhdistelmän ja pitää rinnalla pelkkää X12:ta käyttävän transaktion.

Standardit

Vaaditut standardit ovat HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access ja OpenID Connect Core; maksajat voivat tietyin ehdoin ottaa vapaaehtoisesti käyttöön päivitettyjä versioita. Vuoden 2024 säännössä US Core 3.1.1 ja SMART App Launch 1.0.0 mainittiin niin, että niiden voimassaolo päättyy 1. tammikuuta 2026, joten päätä, mihin versioihin rakennat, ennen kuin kukaan alkaa kirjoittaa vastaavuuksia.

Missä omat järjestelmät yleensä jäävät vajaiksi

Säännön vaatimusten perusteella nämä ovat puutteet, joita kannattaa etsiä ensin:

• Ennakkohyväksyntä tietueena, ei asiakirjana. Tilan, aikaleimojen, hylkäysten syykoodien ja päättymispäivän on oltava kenttiä, jotka kirjoitetaan muutoshetkellä ja joista jää historia. Faksilla lähetetty päätös tarvitsee rakenteisen vastineen.
• Korvattavuussäännöt. Tiedon siitä, mitkä palvelut vaativat hyväksynnän ja mitä dokumentaatiota kukin niistä vaatii, on oltava muodossa, jonka rajapinta voi tarjota. Monella vakuuttajalla se on ohjeistus-PDF:issä ja käsittelijöiden päässä.
• Korvausvaatimukset FHIR-muodossa. Korvausvaatimusten ja käyntitietojen on tultava ulos FHIR-resursseina niin, että maksuerittelyt ja omavastuut poistetaan palveluntuottajille ja muille maksajille lähtevistä tiedoista mutta säilytetään vakuutetulle.
• Vakuutetun tunnistaminen ja historia. Toisen maksajan tietojen yhdistäminen omaan vakuutettuun ja uuden vakuutetun aiempien maksajien löytäminen vaativat henkilötietoja ja vakuutushistoriaa, joita sinulla ei välttämättä ole yhdessä paikassa.
• Suostumusten tila. Kielto (opt-out) Provider Access -rajapinnassa ja suostumus (opt-in) Payer-to-Payer-rajapinnassa, kumpikin muutettavissa milloin tahansa ja tarkistettava jokaisen pyynnön yhteydessä. Osavaltion on myös välitettävä edunsaajan suostumus tämän Medicaid managed care -vakuuttajille.
• Yhden arkipäivän kello. Yöllinen eräajo keskustietokoneella riittää osalle tiedoista mutta on liian hidas toisille. Mittaa aika päätöksestä rajapintaan, älä pelkästään sitä, vastaako rajapinta.
• Delegoidut toimittajat. Jos päätökset tekee delegoitu UM-toimittaja, sen tietojen on ehdittävä sinulle ajoissa, jotta yhden arkipäivän velvoitteesi täyttyy. WEDI:n helmikuun 2026 kyselyssä maksajien haasteiden kärkeen nousivat ”delegoidut kolmannet osapuolet, joilla on vaikeuksia muodostaa yhteyksiä eri järjestelmiin”.

Kuinka pitkällä ala on

WEDI:n helmikuun 2026 kysely, joka julkaistiin 10. maaliskuuta 2026, osoitti, että rajapintavaatimusten osalta ”10 % ei ole vielä aloittanut työtään”, kun lokakuussa 2025 osuus oli 33 %. Se raportoi myös ”huomattavasta kasvusta yli 5 miljoonan dollarin arvioiduissa kustannuksissa, 15 %:sta (lokakuu ’25) 25 %:iin (helmikuu ’26)”. Otos on pieni: 86 vastausta, joista 52 % maksajilta. Pidä sitä suuntaa antavana, ei kattavana kartoituksena.

Yhdentoista viikon suunnitelma 1. tammikuuta 2027 asti

Lokakuun puolivälistä alkaen MA-organisaatiolla tai osavaltion FFS-ohjelmalla on noin yksitoista viikkoa. Se ei riitä neljän rajapinnan rakentamiseen tyhjästä, joten suunnitelma koskee järjestystä ja sitä, mitä voit näyttää ensimmäisenä päivänä.

1. Tällä viikolla: varmista määräpäiväsi ja lähtötilanteesi. 1. tammikuuta vai myöhempi sopimuskausi tai vakuutusvuosi? Listaa, mikä on jo käytössä: Patient Access API ja Provider Directory API, vuoden 2026 tunnusluvut, hylkäysten perusteet.
2. Viikot 1 ja 2: yhdistä jokainen tietoelementti lähteeseensä. Kirjaa jokaisen rajapinnan osalta, mikä järjestelmä tiedot nyt sisältää (korvausvaatimukset, UM, vakuutusrekisteri, palveluntuottajaverkosto, kliiniset tiedot) ja kuinka tuoreita ne ovat.
3. Viikosta 1 viikkoon 3: päätä, missä FHIR-kerros sijaitsee. FHIR-palvelin tai julkisivu (facade) vanhojen järjestelmien edessä, jota syötetään muutostapahtumilla tai tiheillä poiminnoilla, on yleensä nopeampi ratkaisu kuin ydinjärjestelmän opettaminen puhumaan FHIR:ää. Aika kuluu vastaavuuksiin ja tietovirtoihin.
4. Viikosta 2 viikkoon 7: rakenna yhteiset osat ensin. Ennakkohyväksyntätietue, suostumukset ja kohdentaminen, vakuutettujen täsmäytys. Kaikki neljä rajapintaa ovat niistä riippuvaisia.
5. Viikosta 4 viikkoon 9: rakenna rajapinnat. Patient Access -lisäykset, Provider Access massavientineen, Payer-to-Payer molempiin suuntiin ja Prior Authorization API, johon korvattavuussäännöt on ladattu.
6. Viikosta 8 viikkoon 11: testaa oikeiden vastapuolten kanssa. Palveluntuottajan potilastietojärjestelmän toimittaja, toinen maksaja, delegoitu UM-toimittajasi. Testaa suostumusmuutokset, hylkäys perusteineen ja tilamuutos, joka tavoittaa vakuutetun yhden arkipäivän kuluessa.
7. 1. tammikuuta 2027: käyttöönotto ja mittaus. Seuraa viivettä suhteessa yhden arkipäivän sääntöihin ensimmäisestä päivästä alkaen ja pidä päivättyä listaa siitä, mikä on kesken.

Jos yksitoista viikkoa ei riitä, vie asia compliance-tiimillesi ja lakimiehillesi nyt, ei joulukuussa, ja ota mukaan suunnitelma, josta näkyy, mikä on käytössä 1. tammikuuta ja mitä seuraa milloinkin.

Medicaid managed care -vakuuttaja, jonka sopimuskausi alkaa 1. heinäkuuta 2027, tai QHP-vakuutusten myöntäjä, jonka vakuutusvuosi alkaa myöhemmin, voi noudattaa samoja vaiheita väljemmällä aikataululla. Aloita silti nyt: maksajat ja palveluntuottajat, joiden kanssa testaat, ottavat rajapinnat käyttöön 1. tammikuuta.

Mikä voi vielä muuttua

CMS-0062-P. CMS julkaisi 14. huhtikuuta 2026 ehdotuksen jatkosäännöksi. Se tekisi nyt suositelluista toteutusoppaista pakollisia 1. lokakuuta 2027 alkaen, toisi lääkkeet sähköisen ennakkohyväksynnän piiriin samasta päivästä, ja sen myötä HHS ottaisi FHIR:n ennakkohyväksyntätransaktioiden HIPAA-standardiksi X12 278:n tilalle. Nykyisistä määräajoista siinä todetaan: ”Tämä ehdotus ei muuttaisi näitä vaatimusten täyttämisen määräaikoja.” Lausuntoaika päättyi 15. kesäkuuta 2026, eikä Federal Registerissä ole 16. lokakuuta 2026 mennessä julkaistu lopullista sääntöä. Rakenna vuoden 2024 säännön mukaan ja pidä toteutusoppaiden versiot yhdessä konfiguroitavassa paikassa.

Versiot. Da Vinci -oppaat muuttuvat jatkuvasti. FY 2027 IPPS final rule toteaa, että ONC:n (Yhdysvaltain terveydenhuollon tietotekniikasta vastaava liittovaltion toimisto) uusien ennakkohyväksyntäkriteerien mukaan sertifioidut potilastietojärjestelmät ”edellyttävät Da Vinci -toteutusoppaiden version 2.2 käyttöä”. Juuri niiden kanssa Prior Authorization API:si viestii.

Mikään tästä ei ole syy odottaa. Sääntö on lopullinen, päivämäärät ovat säädöstekstissä, ja CMS toisti ne 8. lokakuuta.

Mistä saat apua

Työskentelemme rajapintojen takana olevien järjestelmien parissa: korvausvaatimus-, käynti- ja hyväksyntätietojen FHIR-vastaavuudet, muutosvirrat vanhoista korvauskäsittely- ja UM-alustoista, suostumus- ja kohdentamislogiikka sekä testit, jotka osoittavat yhden arkipäivän sääntöjen pitävän. Kun ydinjärjestelmä on vanha tai sen rakentajat ovat lähteneet, työ alkaa vanhojen järjestelmien ylläpitopalvelustamme, ja jos määräaika osuu keskelle alustan vaihtoa, katso toiminnanohjausjärjestelmän modernisointi.

Jos korvauskäsittely- tai UM-alustasi on sellainen, jolle yksikään ohjelmistotoimittaja ei tuo näitä rajapintoja, kirjoita osoitteeseen office@c9group.dev. Olemme insinöörejä, emme terveydenhuoltoon erikoistuneita juristeja: soveltamisalaa ja sopimuksia koskevat kysymykset kuuluvat lakimiehillesi, ja me rakennamme heidän vastauksensa mukaan.