CMS-0057-F e il 1° gennaio 2027: le API dei payer sui sistemi interni di rimborso e autorizzazione preventiva

Entro il 1° gennaio 2027 le organizzazioni Medicare Advantage (assicuratori privati che gestiscono piani Medicare) e i programmi statali Medicaid e CHIP (la copertura sanitaria per i minori) in fee-for-service (pagamento a prestazione) devono avere in esercizio quattro API FHIR, come prevede la norma finale dei Centers for Medicare & Medicaid Services (CMS) su interoperabilità e autorizzazione preventiva (CMS-0057-F): la Patient Access API già esistente, estesa ai dati di autorizzazione preventiva, e le nuove API Provider Access, Payer-to-Payer e Prior Authorization. I piani Medicaid in managed care (assistenza gestita), le entità CHIP in managed care e gli assicuratori che offrono Qualified Health Plan (QHP) sui mercati federali delle assicurazioni sanitarie seguono dal primo rating period (periodo tariffario del contratto con lo Stato) o plan year (anno di copertura) che inizia in quella data o dopo. Al 16 ottobre 2026 mancano undici settimane, e i CMS non hanno spostato la scadenza.

La parte operativa della norma è già in vigore. Dal 2026 i payer interessati devono indicare un motivo specifico per ogni autorizzazione preventiva negata, decidere entro tempi fissati e pubblicare indicatori sulle autorizzazioni preventive.

Se i vostri sistemi di rimborso, di utilization management (UM, la gestione dell'appropriatezza delle prestazioni) e di gestione degli iscritti vengono da un fornitore che rilascia queste quattro API, quasi tutto lo sviluppo spetta a lui. A voi restano la configurazione, la digitalizzazione delle regole di autorizzazione preventiva, le comunicazioni agli iscritti e i test con i partner.

Questo articolo è per tutti gli altri: piani e agenzie il cui motore di liquidazione, il cui workflow di UM o i cui dati sugli iscritti risiedono in un sistema di loro proprietà, che sia sviluppato internamente, personalizzato al punto da non poter più essere aggiornato, o un Medicaid Management Information System (MMIS, il sistema informativo Medicaid di uno Stato) con decenni di modifiche locali. Per questi sistemi nessuno rilascia le API. Siamo ingegneri, non avvocati: qui spieghiamo cosa la norma chiede a un sistema, non come si applica ai vostri contratti.

Le date

La norma finale è stata pubblicata nel Federal Register (la gazzetta ufficiale federale) l'8 febbraio 2024 ed è entrata in vigore l'8 aprile 2024. Per ciascuna delle quattro API fissa le stesse date di adeguamento: «entro il 1° gennaio 2027, per le organizzazioni MA e i programmi FFS statali Medicaid e CHIP; entro il rating period che inizia il 1° gennaio 2027 o dopo, per i piani Medicaid in managed care e le entità CHIP in managed care; e per i plan year che iniziano il 1° gennaio 2027 o dopo, per gli assicuratori QHP sui FFE».

Un piano Medicaid in managed care i cui rating period iniziano il 1° luglio ha quindi tempo fino al 1° luglio 2027. Un piano con contratto ad anno solare no.

I CMS confermano la stessa data. La loro pagina dedicata alla norma, modificata l'ultima volta l'8 ottobre 2026, afferma che «i payer interessati hanno tempo principalmente fino al 1° gennaio 2027 per soddisfare i requisiti di questa norma finale relativi alle interfacce di programmazione delle applicazioni (API)».

Gli obblighi del 2026, come li riassume la scheda informativa dei CMS, sono decisioni «entro 72 ore per le richieste accelerate (cioè urgenti) e sette giorni di calendario per le richieste standard (cioè non urgenti)» (gli assicuratori QHP sui mercati sono esclusi da questi tempi), un motivo specifico per ogni diniego e indicatori pubblici, per i quali «il primo insieme di indicatori deve essere comunicato entro il 31 marzo 2026». Anche l'utilizzo della Patient Access API va comunicato ai CMS ogni anno entro il 31 marzo. Se una di queste cose non è ancora operativa, è già in ritardo, e attinge agli stessi dati delle API.

I farmaci restano fuori da tutto questo. Ogni disposizione sull'autorizzazione preventiva della CMS-0057-F li esclude.

Chi rientra nell'ambito e chi no

La norma li chiama impacted payers (payer interessati): le organizzazioni Medicare Advantage (MA), i programmi statali Medicaid e CHIP in fee-for-service (FFS), i piani Medicaid in managed care, le entità CHIP in managed care e gli assicuratori QHP sui Federally-facilitated Exchanges (FFE, i mercati assicurativi gestiti dal governo federale). La sua analisi d'impatto conta «365 organizzazioni capogruppo, comprese le agenzie statali Medicaid e CHIP», che «sono responsabili dell'implementazione e della manutenzione di tre nuove API», e osserva che «il 75% dei payer di questa categoria ha meno di 500 dipendenti». Molti sono piani regionali senza un grande team di piattaforma.

Non rientrano, almeno non direttamente:

• I piani aziendali al di fuori di questi programmi, e Original Medicare (il Medicare tradizionale gestito dal governo federale). Non sono nell'elenco dei payer interessati.
• Gli erogatori di prestazioni sanitarie. La loro parte è la Electronic Prior Authorization measure dei programmi Promoting Interoperability di Medicare, che si soddisfa con una cartella clinica elettronica (EHR) certificata. La norma finale IPPS (il sistema di pagamento dei ricoveri ospedalieri) per l'anno fiscale 2027 del 4 agosto 2026 l'ha resa una misura bonus facoltativa per gli ospedali nel 2027.
• I soggetti delegati per l'UM e i TPA (amministratori per conto terzi). Non hanno obblighi propri, ma quelli del payer passano dai loro sistemi. Per gli assicuratori QHP la norma ribadisce che «sono responsabili della propria conformità e della conformità di qualsiasi soggetto delegato o a valle».

Le vie d'uscita sono poche, e a questo punto nessuna aiuta molto. Uno Stato può chiedere una proroga una tantum di un anno per il suo programma FFS Medicaid o CHIP, ma la richiesta va inserita nel suo Advance Planning Document (APD, il documento di pianificazione da cui dipendono i fondi federali) e deve essere «approvata prima della data di adeguamento». Uno Stato con almeno il 90% dei beneficiari Medicaid in managed care può chiedere un'esenzione, e gli assicuratori QHP possono chiedere un'eccezione al mercato. Sui piani stessi, i CMS hanno scritto: «Non abbiamo proposto proroghe o esenzioni per le organizzazioni MA o per i piani Medicaid in managed care». Gli Stati possono anche richiedere fondi federali di cofinanziamento maggiorati al 90% per costruire le API, approvati caso per caso tramite l'APD.

Cosa deve fare ogni API

Tutte e quattro dipendono da una cosa che spesso manca a un sistema su misura: l'autorizzazione preventiva come dato strutturato, con lo storico degli stati. Costruitela una volta e tutte e quattro leggeranno da lì.

Patient Access API: aggiungere le autorizzazioni preventive

Gestite questa API dal 1° gennaio 2021 per richieste di rimborso, encounter (le registrazioni delle prestazioni erogate in managed care) e dati clinici. Dal 2027 deve riportare anche ogni autorizzazione preventiva per beni e servizi: lo stato, la data di approvazione o di diniego, la scadenza, i beni e servizi approvati, un motivo specifico in caso di diniego e la relativa documentazione strutturata fornita dall'erogatore. I dati devono essere disponibili «non oltre 1 giorno lavorativo dopo» la ricezione della richiesta da parte del payer, aggiornati entro un giorno lavorativo da ogni cambio di stato e conservati finché l'autorizzazione è attiva e per almeno un anno dopo l'ultima modifica.

Un sistema di UM che registra le decisioni come note in testo libero, o che comunica lo stato solo via fax, non può alimentarla senza modifiche.

Provider Access API

Gli erogatori in rete possono richiedere i dati di un paziente: richieste di rimborso ed encounter senza i pagamenti agli erogatori né la compartecipazione alla spesa, le classi di dati clinici USCDI (il set federale di dati clinici per l'interoperabilità) e le informazioni sulle autorizzazioni preventive, per date di prestazione dal 1° gennaio 2016. Il payer risponde entro un giorno lavorativo, ma solo per i pazienti che ha attribuito a quell'erogatore e che non hanno esercitato l'opt-out.

Servono tre cose che un sistema legacy raramente ha. Un processo di attribuzione che colleghi gli iscritti agli erogatori. Un opt-out che l'iscritto può modificare in qualsiasi momento, con informative in linguaggio semplice prima del primo utilizzo, entro una settimana dall'inizio della copertura e ogni anno. E l'esportazione massiva, perché gli standard richiesti includono FHIR Bulk Data Access per l'erogatore che chiede i dati di tutti i suoi pazienti.

Payer-to-Payer API

Quando un iscritto entra, il nuovo payer chiede il suo consenso (qui è opt-in) e, entro una settimana dall'inizio della copertura, comincia a identificare i payer precedenti e concomitanti. Una volta individuati, entro una settimana chiede cinque anni di dati: richieste di rimborso ed encounter senza pagamenti agli erogatori né compartecipazione alla spesa, dati USCDI e autorizzazioni preventive diverse da quelle negate, con la relativa documentazione non strutturata. Il payer precedente risponde entro un giorno lavorativo. In caso di copertura concomitante, lo scambio si ripete almeno ogni trimestre.

La parte difficile non è la risposta in uscita. È ricevere dati da payer con cui non avete mai fatto test e incorporarli nella scheda dell'iscritto, come richiede la norma.

Prior Authorization API

È quella che arriva al cuore dell'UM. L'API deve elencare i beni e servizi coperti che richiedono autorizzazione preventiva, indicare la documentazione necessaria per ciascuno, supportare una richiesta e una risposta conformi a HIPAA (la legge federale che disciplina le transazioni e la riservatezza dei dati sanitari) e dire se il payer ha approvato (con la data di scadenza), negato (con un motivo specifico) o ha bisogno di altre informazioni.

Qui i CMS raccomandano, senza imporle, tre guide di implementazione Da Vinci (un progetto HL7): Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) e Prior Authorization Support (PAS). In pratica le vostre regole di copertura e i questionari sulla documentazione devono diventare leggibili da una macchina, non restare un manuale di policy in PDF. Nel sondaggio WEDI (Workgroup for Electronic Data Interchange, l'associazione statunitense per lo scambio elettronico di dati sanitari) i payer mettono la «digitalizzazione delle policy di autorizzazione preventiva» tra le loro tre sfide principali.

Sulla transazione in sé, l'HHS (il Dipartimento federale della Salute) ha lasciato margine ai payer. Il 28 febbraio 2024 ha annunciato una discrezionalità nell'applicazione delle norme (enforcement discretion): secondo i CMS, il suo National Standards Group «non intraprenderà azioni sanzionatorie ai sensi della HIPAA Administrative Simplification nei confronti delle entità coperte da HIPAA che scelgono di non utilizzare lo standard X12 278 nell'ambito di un processo elettronico di autorizzazione preventiva FHIR». Potete costruire solo in FHIR o in FHIR con X12 (il formato EDI tradizionale), e mantenere accanto una transazione solo X12.

Gli standard

Gli standard richiesti sono HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access e OpenID Connect Core; i payer possono adottare volontariamente versioni aggiornate, a determinate condizioni. La norma del 2024 indicava US Core 3.1.1 e SMART App Launch 1.0.0 con scadenza al 1° gennaio 2026, quindi stabilite le versioni di riferimento prima che qualcuno scriva la mappatura.

Dove i sistemi interni di solito restano indietro

In base a ciò che chiede la norma, queste sono le lacune da cercare per prime:

• L'autorizzazione preventiva come record, non come documento. Stato, timestamp, codici del motivo di diniego e data di scadenza devono essere campi, scritti quando cambiano, con lo storico. Una decisione inviata via fax ha bisogno di un gemello strutturato.
• Le regole di copertura. Quali prestazioni richiedono autorizzazione, e quale documentazione serve per ciascuna, devono essere dati che l'API può servire. In molti piani queste informazioni stanno in PDF di policy e nella testa dei revisori.
• Le richieste di rimborso in FHIR. Richieste di rimborso ed encounter devono uscire come risorse FHIR, senza pagamenti agli erogatori né compartecipazione alla spesa per gli erogatori e gli altri payer, ma con queste informazioni per l'iscritto.
• Identità e storico degli iscritti. Abbinare i dati di un altro payer al vostro iscritto, e trovare i payer precedenti di un nuovo iscritto, richiede dati anagrafici e uno storico di copertura che forse non tenete in un unico posto.
• Lo stato del consenso. Un opt-out per Provider Access e un opt-in per Payer-to-Payer, modificabili in qualsiasi momento e verificati a ogni richiesta. Uno Stato deve inoltre trasmettere l'opt-in di un beneficiario ai piani Medicaid in managed care di quella persona.
• L'orologio del giorno lavorativo. Un batch notturno su mainframe va bene per alcuni dati ed è troppo lento per altri. Misurate il tempo che passa dalla decisione all'API, non solo se l'API risponde.
• I fornitori delegati. Se le decisioni le prende un fornitore di UM delegato, i suoi dati devono arrivarvi in tempo per l'obbligo del giorno lavorativo. Il sondaggio WEDI di febbraio 2026 ha messo «Terzi delegati in difficoltà nel collegarsi a sistemi diversi» al primo posto tra le sfide dei payer.

A che punto è il settore

Il sondaggio WEDI di febbraio 2026, pubblicato il 10 marzo 2026, ha rilevato che per i requisiti sulle API «il 10% non ha ancora iniziato i lavori», contro il 33% di ottobre 2025. Ha inoltre segnalato «un aumento notevole dei costi stimati superiori a 5 milioni di dollari, dal 15% (ott. 2025) al 25% (feb. 2026)». Il campione è piccolo: 86 risposte, il 52% delle quali da payer. Va letto come un segnale, non come un censimento.

Un piano di undici settimane fino al 1° gennaio 2027

Da metà ottobre, un'organizzazione MA o un programma FFS statale ha circa undici settimane. Non bastano per costruire quattro API da zero, quindi il piano riguarda la sequenza, e ciò che potrete mostrare il primo giorno.

1. Questa settimana: confermate la vostra data e il punto di partenza. Il 1° gennaio, o un rating period o plan year successivo? Elencate ciò che è già in esercizio: le API Patient Access e Provider Directory, gli indicatori del 2026, i motivi di diniego.
2. Settimane 1 e 2: associate ogni elemento di dato alla sua fonte. Per ogni API, annotate quale sistema contiene oggi i dati (rimborsi, UM, iscrizioni, rete degli erogatori, dati clinici) e quanto sono aggiornati.
3. Settimane da 1 a 3: decidete dove sta lo strato FHIR. Un server o una facciata FHIR davanti ai sistemi legacy, alimentato da eventi di modifica o estrazioni frequenti, di solito è più rapido che insegnare FHIR al sistema centrale. Il tempo se ne va nella mappatura e nei flussi.
4. Settimane da 2 a 7: costruite prima i componenti condivisi. Il record di autorizzazione preventiva, consenso e attribuzione, l'abbinamento degli iscritti. Tutte e quattro le API dipendono da questi.
5. Settimane da 4 a 9: costruite le API. Le aggiunte alla Patient Access, la Provider Access con l'esportazione massiva, la Payer-to-Payer nelle due direzioni e la Prior Authorization API con le vostre regole di copertura caricate.
6. Settimane da 8 a 11: testate con controparti reali. Il fornitore della EHR di un erogatore, un altro payer, il vostro fornitore di UM delegato. Testate i cambi di consenso, un diniego con il suo motivo e un cambio di stato che raggiunge l'iscritto entro un giorno lavorativo.
7. 1° gennaio 2027: andate in produzione e misurate. Monitorate la latenza rispetto alle regole del giorno lavorativo fin dal primo giorno, e tenete un elenco datato di ciò che non è finito.

Se undici settimane non bastano, portate la questione al vostro team compliance e ai legali adesso, non a dicembre, con un piano che mostri cosa sarà in esercizio il 1° gennaio e cosa seguirà, e quando.

Un piano Medicaid in managed care con rating period dal 1° luglio 2027, o un assicuratore QHP con un plan year successivo, può seguire gli stessi passi con più margine. Iniziate comunque adesso: i payer e gli erogatori con cui farete i test vanno in produzione il 1° gennaio.

Cosa può ancora cambiare

CMS-0062-P. Il 14 aprile 2026 i CMS hanno pubblicato una proposta di norma successiva. Renderebbe obbligatorie dal 1° ottobre 2027 le guide di implementazione oggi raccomandate, aggiungerebbe i farmaci all'autorizzazione preventiva elettronica dalla stessa data e farebbe adottare all'HHS FHIR come standard HIPAA per le transazioni di autorizzazione preventiva al posto di X12 278. Sulle scadenze esistenti dice: «Questa proposta non modificherebbe tali date di adeguamento». I commenti si sono chiusi il 15 giugno 2026 e, al 16 ottobre 2026, nel Federal Register non è comparsa alcuna norma finale. Costruite secondo la norma del 2024 e tenete le versioni delle guide in un unico punto configurabile.

Versioni. Le guide Da Vinci continuano a evolvere. La norma finale IPPS per l'anno fiscale 2027 osserva che le EHR certificate secondo i nuovi criteri per l'autorizzazione preventiva dell'ONC (l'ente federale che sovrintende alla certificazione del software sanitario) «richiederanno l'uso della versione 2.2 delle IG Da Vinci». Sono proprio i sistemi con cui dialogherà la vostra Prior Authorization API.

Niente di tutto questo è una ragione per aspettare. La norma è definitiva, le date sono nel testo regolamentare e i CMS le hanno ribadite l'8 ottobre.

Dove trovare aiuto

Lavoriamo sui sistemi che stanno dietro le API: la mappatura FHIR dei dati di rimborso, degli encounter e delle autorizzazioni, i flussi di modifiche in uscita da piattaforme di rimborso e di UM datate, la logica di consenso e attribuzione, e i test che dimostrano il rispetto delle regole del giorno lavorativo. Il nostro servizio di manutenzione dei sistemi legacy è il punto di partenza quando il sistema centrale è vecchio o chi l'ha costruito se n'è andato, e se la scadenza arriva nel mezzo di una sostituzione di piattaforma, vedete la modernizzazione dei gestionali.

Se la vostra piattaforma di rimborso o di UM è una di quelle per cui nessun fornitore rilascerà queste API, scrivete a office@c9group.dev. Siamo ingegneri, non avvocati esperti di diritto sanitario: le questioni di ambito e di contratto spettano ai vostri legali, e noi costruiamo secondo la loro risposta.