---
{
  "title": "Comment vérifier vos API CMS-0057-F : sept questions à poser à votre équipe",
  "description": "Votre équipe affirme que les API CMS-0057-F sont prêtes. Sept questions à poser avant les échéances de 2027, avec les preuves qui devraient vous être fournies.",
  "date": "2026-11-12",
  "author": "Mike Kulakov",
  "reading-time": "15 min read",
  "tags": [
    "Compliance",
    "Integrations"
  ],
  "tldr": "Une démonstration fonctionnelle ne prouve pas que les bonnes données parviennent à la bonne partie en temps voulu. Chaque obligation prévue par CMS-0057-F concerne une personne externe à votre régime : l'application d'un membre, un fournisseur demandant des données sur un patient, un fournisseur demandant une autorisation préalable, un autre régime d'assurance maladie, un développeur d'application, CMS et le public. Voici une question pour chacun d'eux, plus une pour votre propre équipe, avec ce que le règlement prescrit et les preuves qui devraient accompagner la réponse.",
  "utm-campaign": "fhir_expert",
  "utm-content": "cms0057-cio-how-to-check"
}
---

> For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt).
> Use it to discover all available pages before guessing URLs.

---
Votre équipe, ou votre fournisseur, affirme que les API CMS-0057-F sont prêtes. La démonstration fonctionne : une application de test se connecte et récupère les réclamations d'un membre. Le 1er janvier 2027, les API Provider Access, Payer-to-Payer et Prior Authorization deviennent obligatoires, et les données d'autorisation préalable s'ajoutent à l'API Patient Access. La question qui se pose à vous est de savoir si « prêtes » signifie « conformes ».

Une démonstration montre qu'un point de terminaison répond. Elle ne montre pas le délai d'arrivée des données, si un fournisseur voit uniquement ses propres patients, ou si un développeur peut lire la documentation sans créer de compte. Le règlement précise les trois. Chaque obligation concerne une personne externe à votre régime, et c'est elle qui remarque en premier lorsqu'une obligation n'est pas respectée.

Voici donc sept questions à soumettre à votre équipe. Les quatre premières suivent les données à la sortie de chaque API jusqu'au destinataire : l'application d'un membre, un fournisseur souhaitant obtenir des données sur un patient, un fournisseur souhaitant obtenir une autorisation préalable, un autre régime d'assurance maladie. Les trois dernières portent sur ce que les quatre API ont en commun : une documentation qu'un développeur d'application peut lire, les rapports et avis que CMS et le public consultent, ainsi que les tests qui sous-tendent l'ensemble.

Chaque question est accompagnée de ce que le règlement prescrit et des preuves que votre équipe devrait être en mesure de vous fournir. Rien de tout cela ne nécessite de lire du code. Et il ne s'agit pas d'une vérification ponctuelle : posez ces questions avant les échéances de 2027 et continuez à les poser par la suite.

Si vous gérez un régime Medicaid géré, les mêmes obligations vous incombent en vertu de votre contrat avec l'État, et chaque question indique là où elles diffèrent. Les dates fonctionnent différemment. Les vôtres suivent votre période de cotation, soit les 12 mois pour lesquels l'État fixe vos taux de capitation. Chaque État détermine quand sa période de cotation commence, de sorte qu'une obligation de 2027 peut entrer en vigueur pour vous le 1er avril, le 1er juillet ou le 1er septembre 2027.

Les liens dans cet article renvoient aux [sections de la règle relatives à Medicare Advantage](https://www.ecfr.gov/current/title-42/section-422.119). Les sections Medicaid se trouvent dans [42 CFR part 438](https://www.ecfr.gov/current/title-42/part-438). Pour une vue d'ensemble du règlement, commencez par notre [aperçu de CMS-0057-F](/articles/understanding-the-cms-0057-f-interoperability-and-prior-authorization-final-rule).

Les sept questions en un coup d'œil :

| Question | S'applique à partir de | Preuves à demander |
|---|---|---|
| 1. L'application d'un membre | Depuis 2021. Données d'autorisation préalable à partir du 1er janvier 2027 | Réclamations dans l'API dans un délai d'un jour ouvrable ; nombre par année depuis 2016 ; un motif pour chaque refus |
| 2. Un fournisseur demandant des données sur un patient | 1er janvier 2027 | Un test d'attribution à trois requêtes ; exclusion des membres ayant refusé le partage ; réponse complète dans un délai d'un jour ouvrable |
| 3. Un fournisseur demandant une autorisation préalable | 1er janvier 2027 | Chaque code de la liste traité via l'API ; même documentation et mêmes résultats que vos réviseurs |
| 4. Un autre régime d'assurance maladie | 1er janvier 2027 | Consentement proposé à temps ; demandes envoyées dans un délai d'une semaine ; un échange de test dans les deux sens |
| 5. Un développeur d'application | Patient Access depuis 2021. Les trois autres API à partir du 1er janvier 2027 | Documentation accessible depuis votre page d'accueil sans compte ; critères écrits pour résilier l'accès d'une application |
| 6. CMS et le public | Rapports au plus tard le 31 mars chaque année, à partir de 2026. Pages membres depuis 2021 | Chaque rapport, avis et page, chacun avec un responsable et un lien |
| 7. Votre propre équipe | Patient Access depuis 2021. Les trois autres API à partir du 1er janvier 2027 | Vérifications 1 à 4 selon un calendrier avec alertes ; versions par API ; dernier rapport de test de conformité |

Pour un régime Medicaid géré, une date de 2026 ou 2027 désigne la première période de cotation commençant à cette date ou après.

## 1. L'application d'un membre

**Posez la question à votre équipe.** Lorsque l'application d'un membre demande ses données, celles-ci sont-elles toutes présentes et livrées à temps ?

**Ce que le règlement prescrit.** L'API Patient Access doit fournir à l'application d'un membre les données suivantes que vous détenez, pour les dates de service à partir du 1er janvier 2016 :

- Les réclamations que vous avez réglées, y compris les décisions de paiement pouvant faire l'objet d'un appel, qui font l'objet d'un appel ou qui en ont fait l'objet, avec les remboursements aux fournisseurs et la part des coûts du membre. Délai : un jour ouvrable après le traitement de la réclamation.
- Les données d'expériences provenant des fournisseurs que vous rémunérez par capitation. Délai : un jour ouvrable après réception.
- Les données cliniques : chaque classe de données figurant dans le US Core Data for Interoperability (USCDI), la liste fédérale des données de santé normalisées telles que les diagnostics, les résultats de laboratoire, les médicaments et les allergies. Délai : un jour ouvrable après réception.
- Si vous offrez la Partie D, les réclamations de médicaments de la Partie D avec remboursements et participation aux coûts, dans un délai d'un jour ouvrable après le règlement de la réclamation, ainsi que votre formulaire avec ses paliers et ses règles de gestion de l'utilisation.
- À partir du 1er janvier 2027, chaque autorisation préalable pour les articles et les services, à l'exclusion des médicaments. L'application affiche son statut, la date d'approbation ou de refus, la date d'expiration, ce qui a été approuvé, un motif précis pour un refus, et la documentation structurée que le fournisseur a soumise. Délai : un jour ouvrable après la demande et après chaque changement de statut, et conservée pendant au moins un an après le dernier changement.

Un régime Medicaid géré exclut les médicaments ambulatoires couverts, et inclut toutes ses données d'expériences ainsi que les réclamations et données d'expériences de ses sous-traitants.

**Ce que la réponse devrait démontrer.** Trois résultats, tirés des journaux de chargement et de l'API plutôt que du document de conception.

- **Délais.** Votre équipe devrait savoir quelle proportion des réclamations de la semaine dernière est apparue dans un délai d'un jour ouvrable à compter de la date à laquelle le système de réclamations les a marquées comme traitées. L'objectif est la totalité, avec un motif pour chacune des réclamations en retard. Ils devraient disposer du même chiffre pour les données d'expériences, les données cliniques, les réclamations de la Partie D et les autorisations préalables, chacun compté à partir de la date fixée par le règlement. Un chargement qui s'exécute chaque nuit peut être conforme. Un chargement hebdomadaire ne peut pas l'être.
- **Historique.** Prenez un échantillon de membres de longue date et comptez leurs réclamations et données d'expériences pour chaque année depuis 2016, une fois dans l'API et une fois dans vos propres dossiers. Cela signifie chaque système qui détient les données du membre, y compris un système de réclamations que vous avez remplacé depuis, si vous en conservez toujours les données. Pour un régime Medicaid, cela inclut également les données des sous-traitants et des fournisseurs capités. Une plateforme chargée uniquement depuis sa date de lancement ne satisfait pas à cette exigence, et il en va de même pour une plateforme dont une année est manquante.
- **Refus.** Deux chiffres pour le mois dernier qui devraient être égaux. Le premier correspond au nombre de demandes d'autorisation préalable pour des articles et des services que vous avez refusées, à l'exclusion des médicaments, dans chaque système qui les traite. Cela inclut tout fournisseur qui les traite pour vous, puisque le régime reste responsable de ses fournisseurs. Le second correspond au nombre de ces refus qui parviennent à l'API avec un motif précis. Un écart entre les deux signifie que des refus ne parviennent jamais à l'API, ou y parviennent sans motif. Depuis le 1er janvier 2026, chaque refus que vous envoyez à un fournisseur doit déjà comporter un motif précis, quelle que soit la façon dont vous l'envoyez. Le motif existe donc quelque part, et la question est de savoir si le flux de données le transmet à l'API. Le règlement ne définit pas de liste de codes de motifs, donc demandez également à voir cinq refus tels qu'une application de membre les affiche. Chacun devrait indiquer le motif, par exemple les critères auxquels la demande ne satisfaisait pas.

Jusqu'en 2027, effectuez les vérifications des autorisations préalables en pré-production, sur de vraies demandes et de vrais refus issus du flux de production. Les données de test sont fournies avec un motif renseigné, ce qui ne permettra pas de révéler un écart.

## 2. Un fournisseur demandant des données sur un patient

**Posez la question à votre équipe.** Lorsqu'un fournisseur du réseau demande les données d'un patient, ne voit-il que ses propres patients, et uniquement ceux qui n'ont pas refusé le partage ?

**Ce que le règlement prescrit.** À partir du 1er janvier 2027, l'[API Provider Access](https://www.ecfr.gov/current/title-42/section-422.121) donne aux fournisseurs du réseau les mêmes données que Patient Access, remontant au 1er janvier 2016, sans les remboursements aux fournisseurs ni la part des coûts du membre. Les données doivent être fournies au plus tard un jour ouvrable après la demande du fournisseur. Avant de partager, vous confirmez l'identité du fournisseur et vérifiez que le membre lui est attribué, en utilisant votre propre processus de liaison des membres aux fournisseurs du réseau. Les membres peuvent refuser à tout moment et changer d'avis, et la possibilité de refuser doit être offerte avant le premier partage de données.

**Ce que la réponse devrait démontrer.**

- **Attribution.** Un test avec trois requêtes. Un fournisseur du réseau qui demande des données sur un membre qui lui est attribué reçoit les données. Le même fournisseur qui demande des données sur un membre qui ne lui est pas attribué ne reçoit rien. Un fournisseur hors réseau ne reçoit rien.
- **Refus du partage.** Un membre ayant refusé le partage est exclu de la réponse. Une fois que ce membre rétablit son consentement, ses données sont à nouveau disponibles.
- **Délais.** Le temps que prend chaque demande jusqu'à ce que les données soient disponibles. Ce délai doit être d'un jour ouvrable ou moins. Pour une demande portant sur un groupe entier de patients, le délai se mesure jusqu'à la réponse complète, et non jusqu'au premier enregistrement.
- **Historique.** La même vérification année par année que dans la question 1.

## 3. Un fournisseur demandant une autorisation préalable

**Posez la question à votre équipe.** L'API Prior Authorization fournit-elle à un fournisseur la même réponse que nos réviseurs, pour chaque code, y compris les codes qu'un fournisseur externe révise pour nous ?

**Ce que le règlement prescrit.** À partir du 1er janvier 2027, l'[API Prior Authorization](https://www.ecfr.gov/current/title-42/section-422.122) doit contenir votre liste des articles et services nécessitant une autorisation préalable. Elle doit également indiquer au fournisseur la documentation requise pour chacun, et préciser si vous approuvez (et jusqu'à quand), refusez ou avez besoin d'informations supplémentaires. Un refus doit être accompagné d'un motif précis.

**Ce que la réponse devrait démontrer.**

- **Liste de codes.** Chaque code figurant sur votre liste d'autorisations préalables est traité via l'API, y compris les codes qu'un fournisseur externe révise pour vous. Les médicaments sont exclus du champ d'application. Lorsqu'un code est assorti de conditions, comme le contexte de prestation ou le nombre d'unités, testez un cas qui satisfait à la condition et un cas qui n'y satisfait pas. Un échantillon de codes qui ne figurent pas sur la liste est retourné comme ne nécessitant pas d'autorisation préalable. L'API et vos réviseurs travaillent à partir d'une même liste à jour.
- **Documentation.** Pour un échantillon de codes, l'API demande la même documentation que vos réviseurs.
- **Décisions.** Pour quelques demandes de test, l'API retourne le résultat auquel un réviseur est parvenu : approuvé avec la date ou l'événement marquant son expiration, refusé avec un motif précis, ou demande d'informations supplémentaires.

## 4. Un autre régime d'assurance maladie

**Posez la question à votre équipe.** Lorsqu'un membre provient d'un autre régime, demanderons-nous son historique dans les délais prévus ? Lorsqu'un autre régime nous le demande, répondrons-nous dans les délais ?

**Ce que le règlement prescrit.** À partir du 1er janvier 2027, les deux sens de communication transitent par l'API Payer-to-Payer, et les deux dépendent du consentement du membre.

- **Demande.** Vous proposez le consentement et commencez à identifier les régimes antérieurs et simultanés de chaque membre. Pour les membres actuels, les deux démarrent au plus tard le 1er janvier 2027. Pour les nouveaux membres, les deux démarrent dans la semaine suivant le début de la couverture, ou après l'acceptation de l'inscription par CMS si cette date est postérieure. Une fois que vous détenez le consentement et suffisamment d'informations sur l'autre régime, la demande est envoyée dans un délai d'une semaine. Pour un régime auquel le membre est simultanément inscrit, vous répétez la demande au moins chaque trimestre.
- **Réponse.** Lorsqu'un autre régime vous contacte et atteste que le membre est inscrit chez lui et a donné son consentement, vous mettez les données à disposition dans un délai d'un jour ouvrable.
- **Données.** Les données de Patient Access des cinq dernières années, sans les remboursements aux fournisseurs, la part des coûts du membre et les autorisations préalables refusées. S'y ajoute la documentation non structurée que les fournisseurs ont soumise avec les autorisations préalables.

Si vous gérez un régime Medicaid géré, le règlement confie à l'État la responsabilité du consentement et de la recherche des régimes antérieurs et simultanés, l'État partageant ensuite le consentement avec vous. Le règlement ne précise pas comment, et tous les États ne disposent pas encore d'un processus en place. L'envoi des demandes, leur répétition et les réponses aux autres régimes vous incombent dans tous les cas.

**Ce que la réponse devrait démontrer.**

- **Offre de consentement.** La proportion de membres actuels à qui le consentement a été proposé d'ici le 1er janvier 2027, et la proportion de nouveaux membres à qui il a été proposé dans un délai d'une semaine. Comptez les offres, pas les réponses, car l'échéance porte sur la démarche de demande. Pour un régime Medicaid, demandez plutôt ce que votre État a mis en place pour l'offre de consentement et comment ses consentements vous parviendront. Si la réponse est « rien encore », demandez qui recueille le consentement entre-temps et où il est conservé. Aucune demande ne peut être envoyée sans consentement.
- **Délais.** Le temps écoulé entre la réception du consentement et des coordonnées de l'autre régime, et l'envoi de la demande. Ce délai doit être d'une semaine ou moins. Pour les membres ayant un régime simultané, la dernière demande répétée doit dater de moins d'un trimestre.
- **Échange de test.** En pré-production, dans les deux sens, avec le système de test d'un autre régime d'assurance maladie ou un système simulé. Votre demande indique que le membre est inscrit chez vous et a donné son consentement. Votre réponse à leur demande est disponible dans un délai d'un jour ouvrable. Pour un membre de test ayant plus de cinq ans d'historique, elle retourne exactement les données décrites ci-dessus.

## 5. Un développeur d'application

**Posez la question à votre équipe.** Une personne sans compte peut-elle lire la documentation des quatre API ?

**Ce que le règlement prescrit.** Chaque API nécessite une documentation publique : comment l'appeler, ce qu'elle accepte, ce qu'elle retourne, et comment une application s'enregistre. Le règlement interdit « d'exiger une inscription ou la création d'un compte pour recevoir la documentation ». Il est également interdit de facturer des frais, de l'envoyer uniquement par courriel, ou d'obliger les développeurs à consulter du matériel promotionnel ou à accepter de recevoir des messages au préalable.

Le règlement limite également les cas où vous pouvez refuser l'accès à une application. Si vous refusez ou mettez fin à l'accès d'une application à l'une des quatre API, vous devez disposer de critères objectifs et vérifiables appliqués de la même façon à chaque application. La décision doit reposer sur la constatation que l'application fait courir un risque inacceptable aux données de santé des membres sur vos systèmes.

**Ce que la réponse devrait démontrer.** Vous pouvez vérifier la documentation vous-même. Le règlement exige qu'elle soit publiée sur votre site Web ou accessible via un lien public, alors commencez là où un développeur commencerait : la page d'accueil de votre régime, ouverte dans une fenêtre de navigation privée. Trouvez la page destinée aux développeurs à partir de là et suivez les liens pour chaque API. Si vous ne pouvez pas la trouver depuis la page d'accueil, un développeur ne le pourra pas non plus. Vous devriez pouvoir lire l'intégralité de la documentation, y compris la procédure d'enregistrement d'une application, sans vous inscrire, remplir un formulaire de courriel, payer ou cocher une case. L'enregistrement d'une application peut encore nécessiter un compte. La lecture de la procédure pour le faire ne le peut pas. Une documentation hébergée dans le portail d'un fournisseur derrière son authentification n'est pas conforme. Pour la résiliation de l'accès d'une application, demandez les critères écrits et la personne qui les applique.

## 6. CMS et le public

**Posez la question à votre équipe.** Quels rapports, avis aux membres et pages le règlement exige-t-il, qui en est responsable, et où puis-je les consulter ?

**Ce que le règlement prescrit.** Une partie du règlement ne concerne pas des points de terminaison, mais des rapports et des pages en langage clair :

- Les données d'utilisation de l'API Patient Access, transmises à CMS au plus tard le 31 mars chaque année, première échéance le 31 mars 2026.
- Les statistiques sur les autorisations préalables, publiées sur votre site Web au plus tard le 31 mars chaque année, première échéance le 31 mars 2026.
- Une page qui aide les membres à choisir une application en toute sécurité et leur indique où déposer une plainte. Elle s'applique à Patient Access depuis le 1er janvier 2021.
- Pour Provider Access, des informations en langage clair à l'intention des membres concernant l'échange et la façon de refuser. Ces informations sont envoyées avant le premier partage de données, puis chaque année, et demeurent sur votre site Web public. Les nouveaux membres les reçoivent dans la semaine suivant le début de la couverture, ou après l'acceptation de l'inscription par CMS si cette date est postérieure. Pour un régime Medicaid, c'est dans la semaine suivant l'inscription. Les fournisseurs reçoivent également des instructions en langage clair sur votre site Web, notamment sur la façon d'utiliser votre processus d'attribution.
- Pour Payer-to-Payer, des informations en langage clair à l'intention des membres lors de la demande de consentement, chaque année et sur votre site Web public. Un régime Medicaid les fournit chaque année et sur son site Web. L'avis accompagnant la demande de consentement relève de la responsabilité de l'État.

**Ce que la réponse devrait démontrer.** Une liste de chaque rapport, avis et page, chacun avec un responsable désigné. Pour les deux rapports, la soumission de mars 2026 à CMS et la page contenant les statistiques. Pour chaque page, un lien que vous pouvez ouvrir. Pour les avis aux membres, le dernier envoi ou message et la date à laquelle il a été transmis.

## 7. Votre propre équipe

**Posez la question à votre équipe.** Saurons-nous quand l'une de ces vérifications commencera à échouer, et utilisons-nous les versions des normes autorisées par le règlement ?

**Ce que le règlement prescrit.** Chacune des quatre API nécessite « des tests et une surveillance réguliers » pour s'assurer qu'elle fonctionne.

Le règlement CMS précise également les normes que chaque API doit respecter. Pour chacune, il renvoie à une version figurant sur une [liste tenue par le Office of the National Coordinator for Health IT (ONC)](https://www.ecfr.gov/current/title-45/section-170.215) :

- Les quatre API utilisent FHIR R4, la norme de base, et US Core, les profils américains construits sur cette base.
- Toutes sauf Payer-to-Payer utilisent SMART App Launch, le mécanisme de connexion et d'autorisation des applications.
- Provider Access et Payer-to-Payer utilisent Bulk Data, pour un groupe entier de patients en une seule demande.
- Patient Access utilise OpenID Connect, pour confirmer l'identité de l'utilisateur.

Pour deux d'entre elles, le règlement CMS renvoie à des versions anciennes : US Core 3.1.1 et SMART App Launch 1.0.0. Le règlement CMS vous permet d'utiliser une version plus récente si ONC l'a approuvée pour son programme de certification et qu'aucune autre loi ne l'interdit. La transition ne doit pas perturber l'accès des utilisateurs aux données.

À ce jour, le règlement n'exige pas les guides d'implémentation Da Vinci ou CARIN, les spécifications FHIR détaillées pour les données des payeurs. Un [règlement proposé par CMS en avril 2026](https://www.federalregister.gov/documents/2026/04/14/2026-07205/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-interoperability-standards) exigerait CARIN Blue Button, Da Vinci Payer Data Exchange et les guides Da Vinci sur les autorisations préalables à partir du 1er octobre 2027. Il n'est pas définitif.

La même proposition « encourage fortement » les payeurs à utiliser des outils de test tels qu'Inferno, l'outil de test à code source ouvert d'ONC, pour les tests déjà requis par le règlement. Inferno propose des [kits de test](https://inferno.healthit.gov/test-kits/) pour US Core, SMART App Launch, Bulk Data et les guides CARIN et Da Vinci. Un résultat satisfaisant montre que les réponses d'une API respectent la norme. Cela ne démontre pas que les réclamations arrivent à temps, qu'un fournisseur ne voit que ses propres patients, ou que les refus d'un fournisseur externe comportent un motif. Cela répond donc à une partie de cette question, mais pas aux questions 1 à 6.

**Ce que la réponse devrait démontrer.**

- **Surveillance.** Les vérifications des questions 1 à 4 s'exécutant selon un calendrier, avec les derniers résultats et la personne alertée en cas d'échec. Un seul test avant la mise en production n'est pas une surveillance.
- **Versions.** Une ligne pour chaque API et chaque norme, avec la version. Chaque version est soit celle vers laquelle le règlement CMS pointe, soit une version plus récente approuvée par ONC pour son programme de certification. Pour une version plus récente, l'équipe peut expliquer pourquoi la transition n'a pas coupé l'accès aux données pour qui que ce soit. La liste indique également si chaque API respecte les guides CARIN et Da Vinci, afin que vous sachiez quelle part de travail reste à accomplir si la proposition devient définitive.
- **Conformité.** Pour chaque API, le dernier rapport Inferno par rapport aux versions figurant sur cette liste et aux guides que l'API respecte, avec la date d'exécution.

Si une ligne indique encore US Core 3.1.1 ou SMART App Launch 1.0.0, l'équipe devrait avoir un plan pour migrer. L'adoption des deux par ONC a expiré le 1er janvier 2026, et depuis lors, les technologies de santé ne peuvent plus y être certifiées. Un [règlement définitif d'ONC](https://www.federalregister.gov/documents/2026/10/28/2026-21943/health-data-technology-and-interoperability-onc-deregulatory-actions-to-unleash-prosperity) supprime les deux de sa liste le 28 décembre 2026. La proposition de CMS d'avril 2026 interdirait aux payeurs d'utiliser une version expirée, ce qui laisserait US Core 6.1.0, conçu pour la version 3 de USCDI, et SMART App Launch 2.0.0. Jusqu'à ce que cela soit définitif, les versions plus récentes sont autorisées pour les payeurs, sans être obligatoires.

## Comment Health Samurai peut vous aider

Avec [Payerbox](/cms-0057-f), la plateforme de Health Samurai pour CMS-0057-F, vous obtenez bien plus qu'un produit : une équipe qui vous aide à répondre à ces sept questions. [Réservez une heure de révision de conformité](/contacts) et nous passerons en revue les sept points avec votre équipe.