CMS-0057-F et le 1er janvier 2027 : les API des payeurs sur des systèmes maison de remboursement et d'autorisation préalable

Au 1er janvier 2027, les organisations Medicare Advantage (les assureurs privés qui gèrent des plans Medicare) et les programmes Medicaid et CHIP (l'assurance maladie des enfants) que les États gèrent en fee-for-service (paiement à l'acte) doivent avoir en service quatre API FHIR, comme l'exige la règle finale des Centers for Medicare & Medicaid Services (CMS) sur l'interopérabilité et l'autorisation préalable (CMS-0057-F) : la Patient Access API existante, étendue aux données d'autorisation préalable, et les nouvelles API Provider Access, Payer-to-Payer et Prior Authorization. Les plans Medicaid en managed care (soins gérés), les entités CHIP en managed care et les assureurs qui proposent des Qualified Health Plans (QHP) sur les places de marché fédérales de l'assurance santé suivent à partir de leur première rating period (période de tarification du contrat avec l'État) ou de leur premier plan year (année de couverture) commençant à cette date ou après. Au 16 octobre 2026, cela laisse onze semaines, et les CMS n'ont pas déplacé l'échéance.

Le volet opérationnel de la règle s'applique déjà. Depuis 2026, les payeurs concernés doivent motiver précisément chaque refus d'autorisation préalable, statuer dans des délais fixés et publier des indicateurs sur leurs autorisations préalables.

Si vos systèmes de remboursement, de gestion de l'utilisation des soins (utilization management, UM) et de gestion des assurés viennent d'un éditeur qui livre ces quatre API, l'essentiel du développement lui revient. Il vous reste la configuration, la numérisation des règles d'autorisation préalable, les notifications aux assurés et les tests avec vos partenaires.

Cet article s'adresse aux autres : les plans et les agences dont le moteur de remboursement, le workflow d'UM ou les données des assurés reposent sur un système qui leur appartient, qu'il ait été développé en interne, personnalisé au point de ne plus pouvoir être mis à jour, ou qu'il s'agisse d'un Medicaid Management Information System (MMIS, le système d'information Medicaid d'un État) chargé de décennies de modifications locales. Pour ces systèmes-là, personne ne livre les API. Nous sommes ingénieurs, pas juristes : cet article explique ce que la règle demande à un système, pas comment elle s'applique à vos contrats.

Les dates

La règle finale a été publiée au Federal Register (le journal officiel fédéral) le 8 février 2024 et elle est entrée en vigueur le 8 avril 2024. Pour chacune des quatre API, elle fixe les mêmes dates de mise en conformité : « au plus tard le 1er janvier 2027 pour les organisations MA et les programmes FFS Medicaid et CHIP des États ; au plus tard à la rating period commençant le 1er janvier 2027 ou après pour les plans Medicaid en managed care et les entités CHIP en managed care ; et pour les plan years commençant le 1er janvier 2027 ou après pour les assureurs QHP sur les FFE ».

Un plan Medicaid en managed care dont les rating periods commencent le 1er juillet a donc jusqu'au 1er juillet 2027. Un plan dont le contrat suit l'année civile, non.

Les CMS maintiennent la même date. Leur page consacrée à la règle, modifiée pour la dernière fois le 8 octobre 2026, indique que « les payeurs concernés ont principalement jusqu'au 1er janvier 2027 pour satisfaire aux exigences de cette règle finale relatives aux interfaces de programmation (API) ».

Les obligations de 2026, telles que les présente la fiche d'information des CMS, sont les suivantes : des décisions « dans un délai de 72 heures pour les demandes accélérées (c'est-à-dire urgentes) et de sept jours calendaires pour les demandes standard (c'est-à-dire non urgentes) » (les assureurs QHP des places de marché ne sont pas soumis à ces délais), un motif précis pour chaque refus, et des indicateurs publics, dont « le premier ensemble d'indicateurs doit être déclaré au plus tard le 31 mars 2026 ». L'utilisation de la Patient Access API est elle aussi déclarée aux CMS chaque année, au plus tard le 31 mars. Si l'un de ces éléments ne fonctionne pas encore, il est déjà en retard, et il puise dans les mêmes données que les API.

Les médicaments sont entièrement à l'écart. Chaque disposition de CMS-0057-F sur l'autorisation préalable les exclut.

Qui est concerné, et qui ne l'est pas

La règle les appelle les impacted payers (payeurs concernés) : les organisations Medicare Advantage (MA), les programmes Medicaid et CHIP des États en fee-for-service (FFS), les plans Medicaid en managed care, les entités CHIP en managed care et les assureurs QHP sur les Federally-facilitated Exchanges (FFE, les places de marché gérées par l'État fédéral). Son analyse d'impact recense « 365 organisations mères, y compris les agences Medicaid et CHIP des États », qui « sont chargées de mettre en œuvre et de maintenir trois nouvelles API », et relève que « 75 % des payeurs de cette catégorie comptent moins de 500 salariés ». Beaucoup sont des plans régionaux sans grande équipe plateforme.

Ne sont pas concernés, du moins pas directement :

• Les plans d'employeurs hors de ces programmes, et Original Medicare (le Medicare traditionnel géré par l'État fédéral). Ils ne figurent pas sur la liste des payeurs concernés.
• Les offreurs de soins. Leur volet est l'Electronic Prior Authorization measure des programmes Promoting Interoperability de Medicare, que l'on remplit avec un logiciel de dossier patient informatisé (EHR) certifié. La règle finale IPPS (paiement des séjours hospitaliers) de l'exercice 2027, datée du 4 août 2026, en a fait une mesure bonus facultative pour les hôpitaux en 2027.
• Les prestataires d'UM délégués et les TPA (gestionnaires pour compte de tiers). Ils n'ont pas d'obligation propre, mais celle du payeur passe par leurs systèmes. Pour les assureurs QHP, la règle rappelle qu'ils « sont responsables de leur propre conformité et de la conformité de toute entité déléguée ou située en aval ».

Les échappatoires sont rares, et aucune n'aide beaucoup à ce stade. Un État peut demander une prolongation unique d'un an pour son programme FFS Medicaid ou CHIP, mais la demande passe par son Advance Planning Document (APD, le dossier de planification qui ouvre droit au financement fédéral) et doit être « approuvée avant la date de mise en conformité ». Un État dont au moins 90 % des bénéficiaires Medicaid relèvent du managed care peut demander une exemption, et les assureurs QHP peuvent solliciter une exception auprès de la place de marché. Pour les plans eux-mêmes, les CMS ont écrit : « Nous n'avons proposé ni prolongation ni exemption pour les organisations MA ou les plans Medicaid en managed care. » Les États peuvent aussi obtenir un cofinancement fédéral majoré à 90 % pour développer les API, accordé au cas par cas via l'APD.

Ce que chaque API doit faire

Les quatre reposent sur une chose qui manque souvent à un système sur mesure : l'autorisation préalable sous forme de données structurées, avec un historique des statuts. Construisez-la une fois, et les quatre API y puisent.

Patient Access API : ajouter les autorisations préalables

Vous exploitez cette API depuis le 1er janvier 2021 pour les demandes de remboursement, les encounters (relevés de soins des plans en managed care) et les données cliniques. À partir de 2027, elle doit aussi exposer chaque autorisation préalable portant sur des produits et prestations : son statut, la date d'accord ou de refus, sa date de fin, les produits et prestations accordés, le motif précis en cas de refus, et la documentation structurée associée fournie par l'offreur de soins. Les données doivent être disponibles « au plus tard 1 jour ouvré après » la réception de la demande par le payeur, mises à jour dans un délai d'un jour ouvré après tout changement de statut, et conservées tant que l'autorisation est active, puis pendant au moins un an après sa dernière modification.

Un système d'UM qui consigne ses décisions dans des notes en texte libre, ou qui ne transmet le statut que par fax, ne peut pas alimenter cette API sans modifications.

Provider Access API

Les offreurs de soins du réseau peuvent demander les données d'un patient : demandes de remboursement et encounters, sans les montants versés aux offreurs ni le reste à charge, les classes de données cliniques de l'USCDI (le socle fédéral de données de santé interopérables), et les informations d'autorisation préalable, pour les soins délivrés depuis le 1er janvier 2016. Le payeur répond dans un délai d'un jour ouvré, mais uniquement pour les patients qu'il a rattachés à cet offreur de soins et qui ne se sont pas opposés au partage.

Il faut pour cela trois choses qu'un système ancien possède rarement. Un processus d'attribution qui rattache les assurés aux offreurs de soins. Un droit d'opposition (opt-out) que l'assuré peut modifier à tout moment, avec des informations en langage clair avant la première utilisation, dans la semaine qui suit le début de la couverture, puis chaque année. Et l'export en masse, car les normes exigées incluent FHIR Bulk Data Access pour un offreur qui interroge toute sa patientèle.

Payer-to-Payer API

Quand un assuré arrive, le nouveau payeur lui demande son autorisation (ici, c'est un opt-in) et commence, dans la semaine qui suit le début de la couverture, à identifier ses payeurs précédents et concomitants. Une fois qu'il les connaît, il demande dans la semaine cinq ans de données : demandes de remboursement et encounters sans les montants versés ni le reste à charge, données USCDI, et autorisations préalables autres que les refus, avec leur documentation non structurée. Le payeur précédent répond dans un délai d'un jour ouvré. En cas de couverture concomitante, l'échange se répète au moins une fois par trimestre.

La difficulté n'est pas la réponse sortante. C'est de recevoir des données de payeurs avec lesquels vous n'avez jamais fait de tests, puis de les intégrer au dossier de l'assuré, comme l'exige la règle.

Prior Authorization API

C'est celle qui touche au cœur de l'UM. L'API doit lister les produits et prestations couverts qui exigent une autorisation préalable, indiquer les pièces justificatives requises pour chacun, gérer une demande et une réponse conformes à HIPAA (la loi fédérale qui encadre les transactions et les données de santé), et dire si le payeur a accordé l'autorisation (avec sa date de fin), l'a refusée (avec un motif précis) ou a besoin d'informations complémentaires.

Les CMS recommandent ici, sans les imposer, trois guides d'implémentation Da Vinci (un projet HL7) : Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) et Prior Authorization Support (PAS). En pratique, vos règles de couverture et vos questionnaires de documentation doivent devenir lisibles par une machine, au lieu de rester un manuel de politiques en PDF. Dans l'enquête du WEDI (Workgroup for Electronic Data Interchange, l'association américaine des échanges électroniques en santé), les payeurs placent « Numérisation des politiques d'autorisation préalable » parmi leurs trois principaux défis.

Pour la transaction elle-même, le HHS (le ministère fédéral de la Santé) a laissé de la marge aux payeurs. Le 28 février 2024, il a annoncé une tolérance dans l'application des règles (enforcement discretion) : selon les CMS, son National Standards Group « ne prendra pas de mesures d'application au titre de la HIPAA Administrative Simplification à l'encontre des entités couvertes par HIPAA qui choisissent de ne pas utiliser la norme X12 278 dans le cadre d'un processus électronique d'autorisation préalable en FHIR ». Vous pouvez construire en FHIR seul ou en FHIR avec X12 (le format EDI historique), et conserver à côté une transaction uniquement X12.

Les normes

Les normes exigées sont HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access et OpenID Connect Core ; les payeurs peuvent utiliser volontairement des versions plus récentes, sous conditions. La règle de 2024 mentionnait US Core 3.1.1 et SMART App Launch 1.0.0 avec une date d'expiration fixée au 1er janvier 2026 : décidez donc des versions visées avant que quiconque commence le mapping.

Là où les systèmes maison pèchent le plus souvent

Au vu de ce que demande la règle, voici les lacunes à chercher en premier :

• L'autorisation préalable comme enregistrement, pas comme document. Le statut, les horodatages, les codes de motif de refus et la date de fin doivent être des champs, écrits au moment où ils changent, avec un historique. Une décision envoyée par fax a besoin d'un double structuré.
• Les règles de couverture. Les prestations soumises à autorisation, et les pièces que chacune exige, doivent être des données que l'API peut servir. Dans beaucoup de plans, cette information se trouve dans des PDF de politiques et dans la tête de ceux qui instruisent les dossiers.
• Les demandes de remboursement en FHIR. Demandes de remboursement et encounters doivent sortir sous forme de ressources FHIR, sans les montants versés ni le reste à charge pour les offreurs de soins et les autres payeurs, mais avec ces informations pour l'assuré.
• L'identité et l'historique des assurés. Rapprocher les données d'un autre payeur de votre assuré, et retrouver les payeurs précédents d'un nouvel assuré, demande des données démographiques et un historique de couverture que vous ne conservez peut-être pas au même endroit.
• L'état du consentement. Un opt-out pour Provider Access et un opt-in pour Payer-to-Payer, modifiables à tout moment et vérifiés à chaque requête. Un État doit en outre transmettre l'opt-in d'un bénéficiaire aux plans Medicaid en managed care de cette personne.
• Le délai d'un jour ouvré. Un batch mainframe nocturne convient pour certaines données et reste trop lent pour d'autres. Mesurez le temps qui sépare la décision de sa disponibilité dans l'API, pas seulement le fait que l'API réponde.
• Les prestataires délégués. Si un prestataire d'UM délégué prend les décisions, ses données doivent vous parvenir à temps pour votre obligation d'un jour ouvré. L'enquête du WEDI de février 2026 place « Tiers délégués confrontés à des difficultés de connexion avec différents systèmes » en tête des défis des payeurs.

Où en est le secteur

L'enquête du WEDI de février 2026, publiée le 10 mars 2026, constate que pour les exigences relatives aux API « 10 % n'ont pas encore commencé leurs travaux », contre 33 % en octobre 2025. Elle fait aussi état d'« une hausse notable des estimations de coût supérieures à 5 millions de dollars, de 15 % (oct. 2025) à 25 % (févr. 2026) ». L'échantillon est réduit : 86 réponses, dont 52 % de payeurs. À lire comme un signal, pas comme un recensement.

Un plan en onze semaines jusqu'au 1er janvier 2027

À partir de la mi-octobre, une organisation MA ou un programme FFS d'État dispose d'environ onze semaines. C'est trop peu pour construire quatre API à partir de rien : le plan porte donc sur l'ordre des chantiers, et sur ce que vous pourrez montrer le premier jour.

1. Cette semaine : confirmer votre date et votre point de départ. Le 1er janvier, ou une rating period ou un plan year plus tardifs ? Listez ce qui est déjà en service : les API Patient Access et Provider Directory, les indicateurs de 2026, les motifs de refus.
2. Semaines 1 et 2 : rattacher chaque élément de données à sa source. Pour chaque API, notez quel système détient les données aujourd'hui (remboursements, UM, adhésions, réseau d'offreurs de soins, données cliniques) et à quel point elles sont fraîches.
3. Semaines 1 à 3 : décider où vit la couche FHIR. Un serveur ou une façade FHIR placé devant les systèmes anciens, alimenté par des événements de modification ou des extractions fréquentes, va généralement plus vite que d'apprendre le FHIR au système central. C'est le mapping et les flux qui prennent le temps.
4. Semaines 2 à 7 : construire d'abord les briques communes. L'enregistrement d'autorisation préalable, le consentement et l'attribution, le rapprochement des assurés. Les quatre API en dépendent.
5. Semaines 4 à 9 : construire les API. Les ajouts à Patient Access, Provider Access avec l'export en masse, Payer-to-Payer dans les deux sens, et la Prior Authorization API avec vos règles de couverture chargées.
6. Semaines 8 à 11 : tester avec de vrais partenaires. L'éditeur d'EHR d'un offreur de soins, un autre payeur, votre prestataire d'UM délégué. Testez les changements de consentement, un refus avec son motif, et un changement de statut qui parvient à l'assuré en un jour ouvré.
7. 1er janvier 2027 : mettre en service et mesurer. Suivez la latence au regard des règles d'un jour ouvré dès le premier jour, et tenez une liste datée de ce qui n'est pas terminé.

Si onze semaines ne suffisent pas, portez la question dès maintenant devant votre équipe conformité et vos avocats, pas en décembre, avec un plan qui montre ce qui sera en service le 1er janvier et ce qui suivra, et quand.

Un plan Medicaid en managed care dont la rating period commence le 1er juillet 2027, ou un assureur QHP dont le plan year commence plus tard, peut suivre les mêmes étapes avec plus de marge. Commencez quand même maintenant : les payeurs et les offreurs de soins avec qui vous ferez vos tests passent en production le 1er janvier.

Ce qui peut encore bouger

CMS-0062-P. Le 14 avril 2026, les CMS ont publié un projet de règle complémentaire. Il rendrait obligatoires, à partir du 1er octobre 2027, les guides d'implémentation aujourd'hui recommandés, ajouterait les médicaments à l'autorisation préalable électronique à la même date, et ferait adopter par le HHS le FHIR comme norme HIPAA pour les transactions d'autorisation préalable, à la place du X12 278. Sur les échéances existantes, il précise : « Cette proposition ne modifierait pas ces dates de mise en conformité. » La période de commentaires s'est close le 15 juin 2026 et, au 16 octobre 2026, aucune règle finale n'a paru au Federal Register. Construisez selon la règle de 2024, et regroupez les versions des guides en un seul endroit configurable.

Versions. Les guides Da Vinci continuent d'évoluer. La règle finale IPPS de l'exercice 2027 note que les EHR certifiés selon les nouveaux critères d'autorisation préalable de l'ONC (l'organisme fédéral qui encadre la certification des logiciels de santé) « exigeront l'utilisation de la version 2.2 des IG Da Vinci ». Ce sont précisément les systèmes avec lesquels votre Prior Authorization API va dialoguer.

Rien de tout cela n'est une raison d'attendre. La règle est définitive, les dates figurent dans le texte réglementaire, et les CMS les ont rappelées le 8 octobre.

Où trouver de l'aide

Nous travaillons sur les systèmes qui se trouvent derrière les API : le mapping FHIR des données de remboursement, d'encounters et d'autorisation, les flux de modifications extraits de plateformes de remboursement et d'UM anciennes, la logique de consentement et d'attribution, et les tests qui prouvent que les règles d'un jour ouvré sont tenues. Notre service de maintenance de systèmes anciens est le point de départ quand le système central est ancien ou que ceux qui l'ont construit sont partis, et si l'échéance tombe en plein remplacement de plateforme, voyez la modernisation d'ERP.

Si votre plateforme de remboursement ou d'UM fait partie de celles pour lesquelles aucun éditeur ne livrera ces API, écrivez à office@c9group.dev. Nous sommes ingénieurs, pas avocats spécialisés en santé : les questions de champ d'application et de contrat relèvent de vos conseils juridiques, et nous construisons selon leur réponse.