Payer-to-Payer API : Le consentement du membre est un livrable de l'automne 2026

Le verrou de la Payer-to-Payer API

Lorsqu'un membre quitte un régime pour un autre, la Payer-to-Payer API permet à son historique de le suivre. Le nouveau régime demande à l'ancien jusqu'à cinq ans de données sur les demandes de remboursement, les données cliniques et les autorisations préalables. Rien ne bouge tant que le membre n'a pas donné son accord. Cette permission constitue l'unique verrou, et aucune API ne la recueille à votre place. Cet article porte sur ce verrou et est rédigé pour Medicare Advantage ; pour le reste de la règle, consultez notre aperçu de CMS-0057-F.

En ce moment, le calendrier importe davantage que l'ingénierie. La période d'inscription annuelle Medicare pour 2027 s'étend du 15 octobre au 7 décembre 2026, une fenêtre fixée par règlement. La couverture de toutes les personnes inscrites débute le 1er janvier 2027, jour où l'obligation liée à la Payer-to-Payer entre en vigueur en vertu du 42 CFR 422.121. D'ici là, chaque membre existant a droit à la possibilité de donner son consentement, et chaque personne ayant adhéré pendant la période d'inscription annuelle a droit à la même offre dans la semaine suivant le début de la couverture.

Les deux démarches s'effectuent en parlant au membre. L'échange doit permettre de recueillir un ensemble précis d'éléments, notamment l'identité de l'assureur précédent, le nom sous lequel cette couverture était enregistrée, et le consentement lui-même. La collecte de ces informations est ce que cet article appelle la « capture ». Un régime qui arrive en janvier sans moyen de procéder à cette capture aura transformé le travail en une campagne de rattrapage auprès de l'ensemble des membres. Cette campagne se déroule durant les mêmes semaines que la mise en service de l'API.

Ce qu'exige la règle

Pour Medicare Advantage, les obligations figurent dans la section Payer-to-Payer du 42 CFR 422.121. Medicaid, CHIP et les émetteurs de QHP sur les échanges fédéraux ont chacun leur propre version de la même section. Medicaid et CHIP diffèrent sur trois points importants. Dans ce cas, c'est l'État qui recueille le consentement plutôt que le régime. Un échange entre un État et ses propres régimes contractuels n'exige aucun consentement. Et les régimes de soins gérés assument l'obligation par le biais de leur contrat avec l'État plutôt que directement auprès de CMS.

Pour un régime Medicare Advantage, l'obligation fonctionne ainsi. Offrir le consentement et un moyen de le modifier, et commencer à identifier les assureurs antérieurs et actuels du membre, le tout au plus tard une semaine après le début de la couverture. Déployer des efforts raisonnables lorsque le membre ne répond pas. Ensuite, une fois la permission et suffisamment d'informations d'identification en main, envoyer la demande de données dans la semaine, en attestant que le membre est inscrit et a donné son consentement. Répéter la démarche auprès des assureurs simultanés chaque trimestre tant que le membre est dans les deux régimes. Tout expliquer en langage clair lors de la demande, une fois par an par la suite, et dans un endroit accessible sur votre site Web public. Ce que vous demandez est l'ensemble de données Patient Access des cinq dernières années, à l'exclusion des remises aux prestataires, de la quote-part des membres et des autorisations préalables refusées, plus la documentation non structurée jointe aux autorisations préalables.

Trois points peuvent facilement être mal interprétés.

La première semaine s'applique à la demande, non à la réponse. L'échéance est de soumettre la question au membre, non d'avoir sa réponse en main. CMS avait proposé « à l'inscription » et a finalisé « au début de la couverture », car, comme il l'a indiqué, les assureurs pourraient ne pas avoir de contact avec les patients avant l'inscription. Le préambule de la règle finale précise que la collecte « peut prendre plus de temps que le processus d'inscription ». Mesurez donc la proportion de nouveaux membres interrogés dans les sept jours, non la proportion ayant répondu. La première mesure relève de votre processus, la seconde du comportement du membre. Un tableau de bord construit sur la seconde affichera du rouge chaque mois sans rien vous apprendre.

La deuxième semaine est celle qui peut échouer silencieusement. Elle ne commence que lorsque vous avez obtenu à la fois le consentement et suffisamment d'informations pour identifier l'autre assureur ; à partir de là, la demande doit être envoyée dans la semaine. C'est une latence à l'intérieur de votre propre file d'attente — le seul délai que vos systèmes peuvent manquer sans qu'aucune personne soit impliquée — et il mérite un moniteur.

La règle ne précise pas où poser la question. CMS a refusé de prescrire un processus et a plutôt renvoyé à « un point de contact déjà établi avec le patient ». Le consentement n'a donc pas à figurer sur le formulaire d'inscription. Pour Medicare Advantage, le délai ne le suppose pas, puisque le compte à rebours part du début de la couverture plutôt que de l'inscription. L'appel de bienvenue, l'envoi de la carte d'identité, la première connexion au portail et un script de service sont tous disponibles. Choisissez le point de contact que vous contrôlez et pouvez instrumenter.

Là où FHIR commence, et là où il ne commence pas

CMS n'a pas rédigé de norme technique à ce sujet. La règle exige FHIR R4, US Core et la spécification FHIR Bulk Data, en renvoyant aux normes d'API adoptées par ONC. Elle recommande le guide d'implémentation Da Vinci PDex sans l'exiger. La conformité à PDex relève donc d'un accord entre partenaires d'échange plutôt que d'une vérification par CMS. Ce que PDex ajoute, c'est la forme de l'échange, et cette forme est ce qui détermine les éléments que vous devez collecter.

L'assureur demandeur commence par $bulk-member-match et soumet, pour chaque membre, les données démographiques du patient, la couverture antérieure et la permission, selon les profils HRex Patient Demographics, Coverage et Consent. Le répondeur évalue chaque membre individuellement et retourne trois groupes : correspondant, non correspondant, et contraint par le consentement — ce dernier regroupant les membres trouvés mais dont le consentement ne peut être honoré. Le groupe correspondant alimente $davinci-data-export (échange groupé PDex).

FHIR est le format de la demande, non le format de la capture. Rien dans la règle ni dans les guides n'exige un Questionnaire FHIR pour poser les questions ou un serveur FHIR pour conserver les réponses. PDex rend le stockage de l'enregistrement Consent optionnel même pour le récepteur. Il ne vérifie que quatre choses pour valider une demande : que le membre correspond, que le répondeur peut honorer la portée choisie par le membre, que la période de consentement est valide, et que l'assureur qui demande est celui nommé dans le consentement. Du côté demandeur, il n'y a aucune exigence de stockage. Ce que vous devez fournir, c'est un Patient, Coverage et Consent HRex conforme au moment où la demande est envoyée, et tout ce qui se trouve en amont de cette transformation est à votre discrétion.

La connectivité n'est pas non plus un prérequis. Le membre lit le nom d'un assureur sur une carte, mais l'échange nécessite une organisation avec un identifiant et un point de terminaison actif. Il n'existe pas d'identifiant national d'assureur ni de répertoire national pour passer de l'un à l'autre. CMS indique que les assureurs devraient probablement contacter directement l'assureur précédent pour savoir s'il prend en charge l'API. Une règle proposée en avril 2026 commencerait à combler cet écart en exigeant que les assureurs communiquent leurs points de terminaison Payer-to-Payer et autres API à CMS dans les 60 jours suivant une règle finale. Le mécanisme reste à déterminer ; traitez-le donc comme une orientation plutôt que comme quelque chose sur lequel planifier. Quoi qu'il en soit, c'est un argument pour collecter les élections dès maintenant, car elles se transforment en demandes au fur et à mesure que les points de terminaison apparaissent.

Faut-il quand même capturer en FHIR ?

« Non requis » ne signifie pas « sans intérêt ». La capture native en FHIR peut prendre deux formes. Si la page que le membre voit est la vôtre, elle peut écrire directement le Consent lorsqu'il soumet, sans qu'aucun moteur de formulaire soit impliqué. Si vous souhaitez que le formulaire soit également des données, le formulaire côté membre est un Questionnaire FHIR, les réponses arrivent sous forme de QuestionnaireResponse, et le Consent en est dérivé. Deux arguments s'appliquent aux deux approches.

Vous avez besoin d'un magasin de consentements lisible en FHIR du côté serveur de toute façon. Provider Access vous permet de répondre à un prestataire uniquement si le membre n'a pas refusé, et du côté répondeur Payer-to-Payer vous validez le consentement joint à chaque demande. Vos API lisent déjà un magasin de consentements à chaque appel. Capturez ailleurs et vous héritez d'une tâche de synchronisation. Il y a aussi le problème des preuves. HRex Consent veut que source pointe vers une DocumentReference — l'enregistrement de ce à quoi le membre a consenti plutôt qu'un indicateur oui/non. Une QuestionnaireResponse est déjà cet enregistrement, horodatée et liée à l'ensemble de questions et à sa version.

Un Questionnaire n'a pas besoin du créneau de publication du fournisseur. L'argument contre la capture native en FHIR est la commodité : les membres sont déjà dans le flux du fournisseur d'inscription, donc ajouter deux questions là doit être plus rapide. Cela ne tient que si le fournisseur peut le livrer, et ajouter un choix de portée, un chemin pour représentant et une signature à un flux côté membre n'est pas une petite demande de modification. C'est la propriété qui tranche. Un portail que vous contrôlez peut écrire le Consent à la soumission. Un formulaire que vous hébergez peut être référencé depuis le courriel de bienvenue, le portail, un SMS, ou un lien qu'un représentant lit à voix haute. Un portail que vous ne contrôlez pas ne fera ni l'un ni l'autre sans la même demande de modification. Le point de contact reste où il était dans tous les cas ; ce qui change, c'est qui peut corriger la formulation en novembre.

Le véritable argument contre est la migration. Si vous gérez déjà une table de consentements que l'entreprise considère comme le système de référence, passer au mode natif FHIR signifie la déplacer. Il vaut la peine de distinguer cela, car le canal de capture, le formulaire et le système de référence sont trois décisions distinctes.

Quatre décisions à prendre avant la saison d'inscription

1. Où se fait la capture et ce qui conserve la réponse par la suite. Le canal est l'endroit où la question atteint le membre : le fournisseur d'inscription, le portail, le bureau de service, ou le papier. Le système de référence est ce que vos API lisent une fois que le membre a répondu, et ce n'est pas nécessairement le même système. Si les permissions se trouvent déjà dans une table que vous gérez, cette table est un système de référence que vous avez hérité plutôt qu'un canal, et le canal est ce qui l'alimente. Ni l'une ni l'autre de ces décisions n'a à attendre la construction de l'API. Quoi que vous choisissiez, ajoutez un chemin pour les membres qui ne sont pas sur un portail. CMS « recommande fortement qu'il existe un moyen pour les patients d'enregistrer leur permission par téléphone ou autrement ». Les obligations d'accès linguistique et pour les personnes handicapées prévues au 45 CFR part 92 s'appliquent au formulaire et au script.

2. Quelle est la durée du consentement. CMS indique que l'élection est « valide indéfiniment avec cet assureur » jusqu'à ce que le membre la retire, mais HRex Consent rend obligatoires à la fois une date de début et une date de fin. La date de fin relève donc de votre politique plutôt que d'une réponse du membre, et elle doit apparaître sur le formulaire que le membre signe.

3. Quelle valeur de portée le consentement porte, et si le membre la choisit. HRex reconnaît deux valeurs de politique dont les noms vont à l'encontre de l'intuition : #sensitive accorde tout, y compris ce que la loi traite comme sensible ; #regular accorde tout sauf cela. Vous n'êtes pas obligé de présenter ce choix au membre, car la règle demande un oui ou un non et la portée ne fait pas partie des éléments que vous devez expliquer.

Ce que vous ne pouvez pas éviter, c'est la décision, car la valeur voyage quand même dans le Consent sortant. Un formulaire qui ne pose pas la question la fixe par politique, et c'est une question juridique plutôt qu'une question de conception. Envoyer #sensitive affirme que le membre a autorisé la divulgation de dossiers protégés en vertu du 42 CFR part 2 et de la législation provinciale. La règle ne permet l'échange que lorsque la divulgation n'est pas interdite par une autre loi. La quantité de données qui vous parvient effectivement joue en sens inverse. Un répondeur sans étiquettes de sécurité ne peut pas séparer le sous-ensemble sensible, de sorte que PDex exclut le membre plutôt que de filtrer. Le membre qui a demandé moins ne reçoit rien, tandis que celui qui a tout autorisé obtient un historique complet.

4. Quelle version de PDex vos enregistrements stockés sont conçus pour. Un seul contact d'inscription peut collecter à la fois le consentement Payer-to-Payer et le refus Provider Access, de sorte que cette décision couvre les deux enregistrements. PDex 2.2.0 ajoute un codage de catégorie qui identifie à quelle API appartient chaque enregistrement de consentement — obligatoire sur le profil de consentement Provider Access —, élargit le signataire aux représentants personnels et ajoute trois paramètres de recherche. Les enregistrements Payer-to-Payer ne sont pas affectés par cela, car ils utilisent HRex Consent et ce profil est identique dans les deux versions. Pour Provider Access, formatez ce que vous stockez selon la version 2.2.0 plutôt que la 2.1 : 2.2.0 est la version actuelle, et les enregistrements écrits selon la forme 2.1 cet automne nécessiteront une migration. La recommandation officielle de CMS cite encore PDex 2.0.0, donc c'est un pari sur le guide plutôt que sur la règle. À vérifier séparément : les deux profils de consentement font référence à un Patient US Core 7.0.0, tandis que la règle elle-même pointe vers US Core 3.1.1. La version que vos enregistrements de consentement présupposent peut ne pas être celle que cible le reste de votre projet.

Ce qu'il faut demander au membre

« Requis » signifie que le profil est invalide sans cet élément. « Doit prendre en charge » (must support) signifie que le système récepteur doit être en mesure de traiter l'élément si vous l'envoyez, ce qui ne constitue pas une obligation de le demander au membre. « Recommandé » désigne un élément que CMS nomme dans le préambule mais que le profil ne contraint pas du tout.

Voilà tout. Chaque élément qu'HRex Consent exige figure soit ci-dessus, soit est fixé par le profil lui-même. Le profil définit pour vous le statut, la portée, la catégorie de divulgation, le permis, l'action de divulgation et les deux rôles d'acteur. La période de consentement, les deux acteurs organisationnels et l'enregistrement conservé proviennent de votre propre configuration plutôt que du membre, et l'artefact signé peut rester où que vivent vos documents aujourd'hui. Une seule question non évidente ici ne peut être répondue que par le membre lui-même : si la couverture précédente était à son propre nom.

Ce qu'il ne faut pas demander

Trois des quatre éléments ci-dessous proviennent du préambule. Le quatrième est un choix de conception qui en découle.

• Les dates de début et de fin de couverture. CMS reconnaît qu'elles « peuvent être utiles dans certains cas », puis les déconseille : « les patients sont peu susceptibles de connaître ou de se souvenir de ces dates exactes, et elles ne sont pas faciles à trouver. » Un champ de date obligatoire apporte peu de précision à la correspondance et nuit au taux de complétion.
• Les services récents et leurs dates. Déconseillé comme trop contraignant, puisque le membre devrait les obtenir auprès de l'assureur que vous êtes sur le point d'interroger.
• Les numéros d'assurance sociale. À utiliser pour identifier les patients « seulement lorsque nécessaire (et permis par la loi) ».
• Le nom spécifique du régime. Des intervenants ont demandé à CMS de ne pas l'exiger : les noms de régime sont longs, peu intuitifs, et les membres changent de régime tout en restant avec le même assureur. CMS n'a pas tranché dans un sens ou dans l'autre ; supprimer ce champ est donc un choix de conception. Ce dont le routage a besoin, c'est de l'assureur, non du produit.

Ce que CMS approuve est bref : le nom du patient, le numéro de membre, la date de naissance, l'adresse physique et le numéro de téléphone, ainsi que le nom de l'assureur précédent et un numéro d'identification du patient ou un identifiant similaire.

Lorsque le membre ne répond pas, ou change d'avis

Le retrait ne fonctionne que pour l'avenir. Il met fin aux demandes futures, y compris à l'échange trimestriel avec les assureurs simultanés, mais rien ne vous oblige à supprimer ce que vous avez déjà reçu. Laissée telle quelle, l'élection reste valide indéfiniment avec cet assureur et ne se transfère pas : le prochain régime collecte la sienne. La révocation ne circule pas non plus sur le réseau, de sorte que si un membre appelle directement l'assureur précédent, les deux parties ont besoin d'un chemin opérateur pour un changement de permission appris par téléphone.

Les efforts raisonnables ont un plancher : CMS recommande d'effectuer un suivi une fois avant de conclure que le membre choisit de ne pas donner son consentement, et encourage à lui offrir un moyen de refuser pour que le suivi cesse. Enregistrez les tentatives et les refus, sans quoi vous ne pourrez défendre ni l'un ni l'autre.

Un seul échange, deux enregistrements

L'avis de refus Provider Access comporte le même déclencheur — une semaine après le début de la couverture — ce qui permet à un seul contact de couvrir les deux et de transformer deux programmes de communication en un seul.

Les enregistrements restent distincts et sont formatés différemment : le profil de consentement prestataire PDex laisse la date de fin et le document source optionnels, tandis qu'HRex Consent les exige tous les deux, plus deux acteurs organisationnels. Le codage de catégorie dans PDex 2.2.0 les maintient distinguables dans un seul magasin. Aucun indicateur ne peut jamais bloquer une réponse Patient Access, pour laquelle l'autorisation par l'application du membre lui-même constitue l'événement de permission.

Comment Health Samurai vous aide

Payerbox est la plateforme CMS-0057-F de Health Samurai pour les régimes de santé, et elle est active auprès des assureurs aujourd'hui. Le principe de conception est d'intégrer, non de remplacer, et le module de capture du consentement que nous développons actuellement le suit. Vous continuez à interroger les membres là où vous les rejoignez déjà, et la table de consentements que vous gérez déjà reste le système de référence.

Consultez la solution complète sur la page Payerbox pour CMS-0057-F. Pour travailler sur votre propre chemin de capture avant la fermeture de la saison d'inscription, prenez rendez-vous. Nous examinerons où se trouve votre consentement aujourd'hui, ce que votre formulaire doit collecter, et ce qu'il faut pour transformer cela en une demande conforme auprès de ce que vos partenaires d'échange mettront en place.