Règle finale CMS-0057-F : 4 API FHIR requises d'ici 2027

Qu'est-ce que la règle finale CMS-0057-F?

CMS-0057-F est la règle qui transforme les autorisations préalables et l'échange de données entre payeurs en une échéance d'ingénierie. Publiée au Federal Register le 8 février 2024, la règle finale d'interopérabilité et d'autorisation préalable de CMS impose aux régimes de santé réglementés une date fixe — le 1er janvier 2027 — pour exploiter quatre API FHIR en production, en plus d'un ensemble de règles opérationnelles sur les autorisations préalables qui sont en vigueur depuis un an. CMS estime que la règle permettra au système de santé d'économiser environ 15 milliards de dollars sur dix ans, en grande partie en réduisant les frictions liées aux autorisations préalables.

Au cœur de la règle se trouvent quatre API HL7 FHIR R4. L'une d'elles est peut-être déjà en place sous une certaine forme. Les trois autres sont nouvelles.

• Patient Access API : permet aux membres de récupérer leurs réclamations, leurs données cliniques et leurs informations d'autorisation préalable dans des applications tierces.
• Provider Access API : partage les réclamations et les données cliniques des membres attribués à un prestataire, en lot.
• Payer-to-Payer API : transfère l'historique d'un membre à son nouveau régime lorsqu'il change de payeur.
• Prior Authorization API : gère le flux de travail électronique des autorisations préalables de bout en bout.

Le schéma est identique pour les quatre API. Chacune expose des données déjà détenues, par le biais d'une interface normalisée, à un public précis. C'est pourquoi le véritable effort réside moins dans la mise en place des API que dans les données qui les sous-tendent. La nature de ce travail varie selon l'API; les sections ci-dessous examinent chacune d'elles tour à tour.

Qui doit se conformer, et qui est exempté

La règle s'applique à six types de payeurs : les organisations Medicare Advantage, les programmes d'État Medicaid et CHIP à l'acte, les organisations de soins gérés Medicaid, les entités de soins gérés CHIP, et les émetteurs de régimes de santé admissibles (Qualified Health Plans) sur les échanges à financement fédéral. Si vous gérez l'un de ces régimes, vous devez mettre en place les quatre API.

De nombreuses organisations ne sont pas visées par la règle. Medicare traditionnel, les régimes autoassurés ERISA parrainés par un employeur, les régimes autonomes Part D pour les médicaments et les complémentaires Medigap n'y sont pas assujettis. Les entités déléguées sont une source de confusion plus fréquente. Un fournisseur de gestion de l'utilisation, un TPA, un MSO ou un IPA n'est pas lui-même réglementé par CMS-0057-F. L'obligation demeure avec le payeur, même pour les fonctions qu'il délègue. En pratique, cela signifie qu'un régime qui délègue les autorisations préalables doit tout de même exposer une Prior Authorization API conforme; il doit donc soit construire cette API par-dessus le système du fournisseur, soit exiger que le fournisseur la mette en place. Le fournisseur est entraîné dans la démarche sur le plan commercial, et non parce que la règle le désigne nommément.

Il y a une exception à bien retenir, car c'est le détail que la plupart des gens interprètent mal. Les émetteurs de QHP sur les échanges ne sont pas soumis aux délais de décision d'autorisation préalable. Ces délais s'appliquent à Medicare Advantage, Medicaid et CHIP. Tout le reste s'applique bien aux QHP : les quatre API, la règle sur le motif de refus précis et la publication des indicateurs. Donc, si vous gérez un QHP, planifiez la totalité du travail lié aux API et excluez le chronomètre de décision.

Deux échéances, deux types de travail

La règle a inscrit deux dates au calendrier, et elles mobilisent des équipes différentes.

La première, le 1er janvier 2026, est déjà passée. Depuis lors, les payeurs visés (les QHP mis à part, pour ce qui est des délais) doivent rendre leurs décisions d'autorisation préalable dans un délai de 72 heures pour les demandes urgentes et de sept jours civils pour les demandes ordinaires, indiquer un motif précis pour chaque refus, et publier chaque année les indicateurs d'autorisation préalable sur leur site Web. Le premier de ces rapports publics était dû le 31 mars 2026, couvrant l'année civile 2025, et il est reconduit annuellement. Il s'agit d'un travail de politique et de processus. Il est possible d'y répondre par des changements de flux de travail et de gouvernance.

La seconde, le 1er janvier 2027, est l'échéance des API, et c'est la plus exigeante. C'est un travail d'ingénierie qu'on ne peut pas clore par une note de service. Les quatre sections qui suivent décrivent en quoi consiste concrètement ce travail d'ingénierie.

Patient Access API

Patient Access est la seule API que la plupart des régimes visés exploitent déjà sous une certaine forme, car elle remonte à la règle de 2020. Un membre autorise une application tierce, et le régime lui retourne ses données par le biais d'un flux SMART on FHIR sécurisé avec OAuth 2.0. Le membre détient l'autorisation et peut la révoquer.

Les données qui y transitent sont variées : réclamations liquidées et données de consultation au format CARIN Blue Button, données cliniques sous forme de USCDI, et, pour les régimes couvrant les médicaments, les informations sur le formulaire. CMS-0057-F y ajoute un élément d'ici le 1er janvier 2027 : les informations d'autorisation préalable, le statut et le motif précis, pour tout sauf les médicaments.

Le travail porte rarement sur le point de terminaison lui-même. Il porte sur la qualité des données qui le sous-tendent : mapper correctement les réclamations, maintenir le flux à jour et prendre en charge les lacunes. Les régimes déclarent également chaque année à CMS les indicateurs d'utilisation de Patient Access. Bien réalisée, cette API dépasse le simple cadre de la conformité. Le même niveau de données propres, orienté vers les membres, peut aussi alimenter votre propre application ou portail membre.

Provider Access API

Provider Access est nouvelle, et c'est là que les équipes sous-estiment l'effort, car il ne s'agit pas seulement d'un point de terminaison. Elle donne à un prestataire en réseau accès aux réclamations, aux données de consultation, aux données cliniques USCDI et aux informations d'autorisation préalable des membres qui lui sont attribués, livré en lot.

Le modèle d'authentification diffère de Patient Access. Aucun patient ne clique sur « approuver ». Le régime authentifie l'organisation prestataire en tant que système, par le biais de SMART Backend Services, et effectue une exportation FHIR Bulk Data sur le groupe de membres attribués au prestataire. L'effort ne réside pas dans l'exportation, mais dans la gouvernance qui l'entoure :

• Attribution. Le régime doit savoir quels prestataires ont une relation thérapeutique avec quels membres, et maintenir ces listes d'attribution à jour.
• Désinscription. Les membres peuvent refuser que leurs données soient partagées avec des prestataires, et le régime doit respecter et consigner ce choix.

Si ces deux points sont bien gérés, l'exportation elle-même devient une opération de routine.

Payer-to-Payer API

Payer-to-Payer est d'abord un projet d'identité et de consentement avant d'être un projet d'API. Lorsqu'un membre rejoint votre régime, vous disposez d'une semaine pour demander à son ancien payeur jusqu'à cinq ans d'historique — réclamations, données cliniques et dossiers d'autorisation préalable — afin de démarrer avec du contexte plutôt qu'un dossier vierge. Lorsqu'un membre quitte votre régime, vous êtes de l'autre côté de cet appel, répondant au nouveau régime. Les données de coût, les remises aux prestataires et la quote-part de l'assuré ne sont pas incluses.

Le transfert est la partie facile. Les parties difficiles sont les deux obstacles qui le précèdent. La correspondance des membres : vous et l'autre régime devez vous assurer que vous parlez de la même personne malgré des identifiants différents, sans clé commune. Le consentement : contrairement à Provider Access, aucune donnée ne circule à moins que le membre n'accepte, ce qui nécessite un mécanisme pour recueillir et honorer cet accord. Pour les membres couverts simultanément par plusieurs régimes, l'échange se fait au moins trimestriellement plutôt qu'une seule fois à l'adhésion.

Prior Authorization API

Les trois premières API publient ou déplacent des données. La Prior Authorization API est d'une autre nature : elle exécute une transaction. Un prestataire pose une question à votre régime, et votre régime doit répondre par une décision réelle, dans un délai imparti. Il s'agit d'une intégration de processus métier, et non d'une exposition de données, ce qui en fait la plus complexe des quatre et celle qui fait appel au plus grand nombre de normes.

Trois guides d'implémentation Da Vinci s'enchaînent pour faire fonctionner ce processus. Il commence par CRD, Coverage Requirements Discovery. Lorsqu'un prestataire prescrit ou planifie un acte ou un service, un déclencheur s'active depuis le DSÉ et votre régime répond en temps réel : une autorisation préalable est-elle requise, et quelle documentation est nécessaire? Si c'est le cas, DTR, Documentation Templates and Rules, remet au DSÉ un questionnaire intelligent et pré-remplit ce qu'il peut à partir du dossier, afin que le prestataire n'ait pas à ressaisir des données déjà connues du système. Enfin, PAS, Prior Authorization Support, soumet la demande et retourne la décision : approuvée, refusée avec un motif précis, ou en attente d'informations supplémentaires. CMS recommande ces guides, mais ne les impose pas formellement.

C'est également ici qu'il faut corriger une interprétation erronée courante. FHIR ne remplace pas X12. Le guide PAS est conçu pour transporter la transaction X12 278 mandatée par HIPAA, de sorte que la demande et la réponse sous-jacentes restent en X12. Un payeur peut exploiter le backend en FHIR uniquement, en X12 uniquement, ou en mode hybride et répondre quand même aux exigences de la règle. La documentation clinique complémentaire est acheminée par un mécanisme Da Vinci distinct, CDex, plutôt que d'être intégrée dans le message d'autorisation lui-même.

Un dernier élément relie le côté payeur aux prestataires. À compter de la période de performance 2027, les cliniciens et les hôpitaux admissibles attestent, dans le cadre du programme Medicare Promoting Interoperability, qu'ils ont soumis au moins une demande d'autorisation préalable par voie électronique via une Prior Authorization API. Cette mesure est le signal de la demande. C'est pourquoi votre Prior Authorization API n'est pas seulement un point de terminaison de conformité, mais quelque chose que votre réseau de prestataires est désormais censé utiliser.

Ce qui a changé par rapport à la règle de 2020

Si CMS-0057-F vous semble familière, c'est parce qu'elle s'appuie sur CMS-9115-F, la règle d'interopérabilité et d'accès aux données des patients de 2020. Cette règle antérieure avait établi la Patient Access API et la Provider Directory API. Elle appelait également à un échange de données entre payeurs, mais CMS n'a jamais appliqué cette disposition et elle n'était pas fondée sur une API.

CMS-0057-F achève le travail. Elle conserve les API antérieures, reconstruit le Payer-to-Payer en une API FHIR exécutoire, ajoute Provider Access et Prior Authorization, intègre les données d'autorisation préalable dans Patient Access, et superpose les délais opérationnels et les obligations de publication publique. La direction est cohérente. La portée et les moyens d'application sont nouveaux. CMS n'a pas associé d'amende précise à la règle, mais elle applique par les pouvoirs qu'elle détient déjà sur chaque programme — contrats Medicare Advantage, surveillance Medicaid et CHIP, et certification QHP. L'exposition est contractuelle et réglementaire plutôt qu'exprimée en un montant publié.

Comment Health Samurai peut aider

Payerbox est la plateforme CMS-0057-F de Health Samurai pour les régimes de santé, construite sur notre noyau Aidbox natif FHIR R4. Elle met en œuvre les quatre API, avec prise en charge en production des guides Da Vinci d'autorisation préalable — CRD, DTR et PAS.

Le principe de conception est celui qu'une échéance serrée exige réellement : intégrer, ne pas remplacer. Votre plateforme de réclamations, votre système de gestion de l'utilisation et votre répertoire demeurent en place. Payerbox se positionne devant eux, lit leurs données et les traduit en FHIR conforme pour chaque API. La valeur ne réside pas dans le déplacement des dossiers vers un nouveau système, mais dans l'exposition des dossiers déjà détenus, correctement, par le biais d'une interface normalisée.

Cette couche FHIR continue de rapporter des bénéfices après l'échéance. L'entrepôt constitué pour les quatre API est également un entrepôt analytique : les mêmes données normalisées alimentent l'ajustement des risques, les mesures Stars et de qualité, ainsi que la santé des populations. Les dépenses de conformité se transforment en un actif de données réutilisable plutôt qu'en un enrobage à usage unique, et la prochaine exigence réglementaire s'appuie sur des données déjà normalisées.

Il s'agit d'un logiciel de production, non d'une promesse théorique. Payerbox est actuellement en exploitation chez des payeurs. VillageCareMAX dessert sa Patient Access API sur Payerbox et s'est classé 2e, avec un score de 91 sur 100, dans le tableau de bord indépendant de novembre 2025 de Flexpa, ce qui signifie qu'il ne fait pas que fonctionner, mais qu'il figure parmi les meilleurs. Un fournisseur délégué d'autorisations préalables exploite en production la pile complète Payerbox ePA — CRD, DTR et PAS. Et nous maintenons la pile conforme en la présentant au volet Burden Reduction du HL7 Da Vinci Connectathon.

Découvrez la solution complète sur la page Payerbox consacrée à CMS-0057-F. Lorsque vous souhaitez une analyse d'architecte à architecte de la position de votre régime par rapport à l'échéance de janvier 2027, planifiez un appel : nous cartographierons vos obligations, examinerons vos systèmes sources et vous montrerons à quoi ressemble une mise en œuvre de Payerbox au regard de votre calendrier restant.