API de payeur à payeur : le consentement du membre est un livrable de l'automne 2026

Le verrou de l'API de payeur à payeur

Lorsqu'un membre quitte un régime pour un autre, l'API de payeur à payeur permet à son dossier de le suivre. Le nouveau régime demande à l'ancien jusqu'à cinq ans de données sur les réclamations, 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 collecte à votre place. Cet article porte sur ce verrou et est rédigé pour Medicare Advantage; pour le reste de la règle, commencez par notre aperçu de CMS-0057-F.

À l'heure actuelle, le calendrier importe plus que l'ingénierie. L'inscription annuelle Medicare pour 2027 se déroule du 15 octobre au 7 décembre 2026, une période fixée par règlement. La couverture de toutes les personnes inscrites commence le 1er janvier 2027, jour où l'obligation de payeur à payeur entre en vigueur en vertu du 42 CFR 422.121. D'ici là, chaque membre existant doit se voir offrir la possibilité de donner son consentement, et chaque personne inscrite durant la période d'inscription annuelle doit recevoir la même offre dans la semaine suivant le début de sa couverture.

Les deux offres se concrétisent par un échange avec le membre. La conversation doit aboutir à la collecte d'un ensemble précis d'éléments, notamment l'identité de l'assureur précédent, le nom sous lequel cette couverture était souscrite et le consentement lui-même. La collecte de ces éléments est ce que cet article appelle la « saisie ». Un régime qui arrive au 1er janvier sans moyen de procéder à cette saisie devra mener une campagne de rattrapage auprès de l'ensemble des membres. Cette campagne se déroulera durant les mêmes semaines que la mise en service de l'API.

Ce que la règle exige

Pour Medicare Advantage, les obligations figurent dans la partie « payeur à payeur » du 42 CFR 422.121. Medicaid, CHIP et les émetteurs de plans de couverture qualifiés sur les échanges à gestion fédérale disposent chacun de leur propre version de la même section. Medicaid et CHIP diffèrent sur trois points importants. C'est l'État qui recueille le consentement, et non le régime. Un échange entre un État et ses propres régimes sous contrat n'exige aucun consentement. Et les régimes de soins gérés reçoivent cette obligation par l'entremise de leur contrat d'État plutôt que directement de CMS.

Pour un régime Medicare Advantage, l'obligation se présente comme suit. Offrir le consentement et un moyen de le modifier, et commencer à identifier les payeurs précédents et simultanés du membre, le tout au plus tard une semaine après le début de la couverture. Faire des efforts raisonnables lorsque le membre ne répond pas. Puis, une fois le consentement et suffisamment d'informations d'identification en main, envoyer la demande de données dans un délai d'une semaine, en attestant que le membre est inscrit et a donné son consentement. Répéter l'opération auprès des payeurs simultanés chaque trimestre tant que le membre est dans les deux régimes. Expliquer tout cela 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 correspond à l'ensemble de données Patient Access des cinq dernières années, à l'exclusion des remboursements aux prestataires, de la part des membres aux frais et des autorisations préalables refusées, ainsi que la documentation non structurée jointe aux autorisations préalables.

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

La première semaine commence à la demande, non à la réponse. L'échéance est de poser la question au membre, non d'avoir sa réponse en main. CMS avait proposé « à l'inscription » et a finalement retenu « début de la couverture », car, comme il l'a précisé, les payeurs pourraient ne pas avoir de contact avec les patients avant l'inscription. Le préambule de la règle définitive ajoute que la collecte « peut prendre plus de temps que le processus d'inscription ». Mesurez donc la proportion de nouveaux membres auxquels vous avez posé la question dans les sept jours, et non la proportion ayant répondu. La première mesure évalue votre processus, la seconde le comportement des membres. Un tableau de bord fondé sur la seconde mesure sera constamment dans le rouge sans rien vous apprendre.

La deuxième semaine est celle qui peut échouer silencieusement. Elle ne commence que lorsque vous disposez à la fois du consentement et de suffisamment d'informations pour identifier l'autre payeur, et à partir de là, la demande doit partir dans un délai d'une semaine. Il s'agit d'une latence dans votre propre file d'attente, le seul délai que vos systèmes peuvent manquer sans qu'aucune personne ne soit impliquée, et il mérite une surveillance.

La règle ne prescrit pas l'endroit où demander. CMS a refusé de définir un processus et a plutôt évoqué « 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, l'échéance ne le suppose pas, puisque le délai court à compter du début de la couverture et non 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 à votre disposition. Choisissez le point de contact que vous maîtrisez 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 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 commerciaux et non de quelque chose que CMS vérifie. Ce que PDex ajoute, c'est la forme de l'échange, et c'est cette forme qui vous indique quels éléments vous devez collecter.

Le payeur demandeur commence par $bulk-member-match et soumet, pour chaque membre, les données démographiques du patient, la couverture antérieure et le consentement, sur les profils HRex Patient Demographics, Coverage et Consent. Le répondant évalue chaque membre individuellement et renvoie trois groupes : correspondance trouvée, aucune correspondance, et contrainte de consentement, ce dernier groupe étant les membres trouvés mais dont le consentement ne peut être honoré. Le groupe avec correspondance alimente $davinci-data-export (échange en masse PDex).

FHIR est le format de la demande, non le format de la saisie. Ni la règle ni les guides n'exigent qu'un questionnaire FHIR serve à poser les questions ou qu'un serveur FHIR conserve les réponses. PDex rend même le stockage de l'enregistrement de consentement facultatif pour le récepteur. Il ne vérifie que quatre choses pour valider une demande : que le membre correspond, que le répondant peut honorer la portée choisie par le membre, que la période de consentement est valide, et que le payeur qui demande est bien 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, une Coverage et un Consent HRex conformes au moment de l'envoi de la demande, et tout ce qui se trouve en amont de cette transformation vous appartient à concevoir.

La connectivité n'est pas non plus une condition préalable. Le membre lit le nom d'un payeur sur une carte, mais l'échange nécessite une organisation dotée d'un identifiant et d'un point de terminaison actif. Il n'existe pas d'identifiant national de payeur ni de répertoire national permettant de passer de l'un à l'autre. CMS indique que les payeurs devraient probablement contacter directement le payeur précédent pour savoir s'il prend en charge l'API. Une règle proposée d'avril 2026 commencerait à combler ce manque, en obligeant les payeurs à signaler leurs points de terminaison d'API de payeur à payeur et autres à CMS dans les 60 jours suivant une règle définitive. Le mécanisme reste à déterminer; traitez-le donc comme une orientation plutôt que comme une base de planification. Dans tous les cas, c'est un argument pour collecter les consentements dès maintenant, car ils se transformeront en demandes au fur et à mesure que les points de terminaison apparaîtront.

Devriez-vous quand même saisir les données en FHIR?

« Non requis » ne signifie pas « sans intérêt ». La saisie native en FHIR peut prendre deux formes. Si la page que voit le membre est la vôtre, elle peut écrire le Consent lui-même lors de la soumission, sans moteur de formulaire. Si vous souhaitez que le formulaire soit également une donnée, le formulaire accessible au 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 de toute façon besoin d'un dépôt de consentements lisible en FHIR du côté serveur. Provider Access vous permet de répondre à un prestataire seulement si le membre ne s'est pas désengagé, et du côté répondant à payeur à payeur, vous validez le consentement joint à chaque demande. Vos API lisent déjà un dépôt de consentements à chaque appel. Saisir ailleurs, et vous héritez d'un travail de synchronisation. Il y a aussi le problème de la preuve. HRex Consent veut que source pointe vers un DocumentReference, la trace de ce que le membre a accepté plutôt qu'un simple indicateur oui/non. Une QuestionnaireResponse est déjà cette trace, horodatée et liée à l'ensemble de questions et à sa version.

Un Questionnaire ne nécessite pas le créneau de publication du fournisseur. L'argument contre la saisie native en FHIR est la commodité : les membres se trouvent déjà dans le flux du fournisseur d'inscription, il devrait donc être plus rapide d'y ajouter deux questions. Cela ne tient que si le fournisseur peut le livrer, et l'ajout d'un choix de portée, d'un parcours représentant et d'une signature à un flux orienté membre n'est pas une petite demande de modification. C'est la question de propriété qui tranche. Un portail que vous contrôlez peut écrire le Consent lors de la soumission. Un formulaire que vous hébergez peut être lié 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 le même dans tous les cas; ce qui change, c'est qui peut corriger la formulation en novembre.

Le vrai 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 bien distinguer cela, car le canal de saisie, le formulaire et le système de référence constituent trois décisions distinctes et non une seule.

Quatre décisions à prendre avant la période d'inscription

1. Où se fait la saisie, et ce qui conserve la réponse par la suite. Le canal est l'endroit où la question parvient au membre : le fournisseur d'inscription, le portail, le bureau de service ou le papier. Le système de référence est ce que lisent vos API 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 hérité plutôt qu'un canal, et le canal est ce qui l'alimente. Aucune de ces deux décisions n'a à attendre la construction de l'API. Quel que soit votre choix, prévoyez un parcours 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 en matière de langue et d'accessibilité pour les personnes handicapées prévues au 45 CFR partie 92 s'appliquent au formulaire et au script.

2. Quelle est la période de consentement. CMS indique que le choix est « valable indéfiniment auprès de ce payeur » jusqu'à ce que le membre le retire, mais HRex Consent rend à la fois une date de début et une date de fin obligatoires. La date de fin relève donc de votre politique plutôt que d'une réponse du membre, et elle doit figurer sur le formulaire que le membre signe.

3. Quelle valeur de portée porte le consentement, et si le membre la choisit. HRex reconnaît deux valeurs de politique dont les noms sont à l'opposé de l'intuition : #sensitive accorde tout, y compris ce que la loi considère comme sensible; #regular accorde tout sauf cela. Vous n'êtes pas tenu 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 elle-même, car la valeur transite 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 que de conception. Envoyer #sensitive affirme que le membre a autorisé la divulgation de dossiers protégés par le 42 CFR partie 2 et la législation d'État. 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 joue dans l'autre sens. Un répondant sans étiquettes de sécurité ne peut pas séparer le sous-ensemble sensible; PDex lui demande donc d'exclure 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. Pour quelle version de PDex vos enregistrements stockés sont-ils formatés. Un seul contact d'inscription peut recueillir à la fois le consentement à l'API de payeur à payeur et le désengagement à 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 de payeur à payeur 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 2.1 : 2.2.0 est la version actuelle, et les enregistrements écrits au format 2.1 cet automne nécessiteront une migration. La recommandation officielle de CMS cite encore PDex 2.0.0, ce qui en fait un pari sur le guide plutôt que sur la règle. À vérifier séparément : les deux profils de consentement référencent 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 supposent n'est peut-être pas 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. « Must support » signifie que le système récepteur doit être en mesure de traiter l'élément si vous l'envoyez, ce qui n'équivaut 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.

C'est tout. Chaque élément exigé par HRex Consent 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, l'autorisation, 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ù se trouvent vos documents aujourd'hui. La seule question non évidente ici à laquelle personne d'autre que le membre ne peut répondre est de savoir si la couverture précédente était à son propre nom.

Ce qu'il ne faut pas demander

Trois des quatre points 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 admet 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 il ne leur est pas facile de les trouver. » Un champ de date obligatoire apporte peu de précision dans la correspondance et nuit au taux de complétion.
• Les services récents et leurs dates. Déconseillés car contraignants, puisque le membre devrait les obtenir auprès du payeur que vous êtes sur le point de contacter.
• Les numéros d'assurance sociale. À utiliser pour identifier les patients « uniquement lorsque nécessaire (et permis par la loi) ».
• Le nom précis du plan. Des commentateurs ont demandé à CMS de ne pas l'exiger : les noms de plans sont longs, peu intuitifs, et les membres changent de plan tout en restant chez le même payeur. CMS n'a pas tranché, donc le supprimer est un choix de conception. Ce dont le routage a besoin, c'est du payeur, 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 du payeur 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 s'applique que de manière prospective. Il interrompt les demandes futures, y compris l'échange trimestriel avec les payeurs simultanés, mais rien ne vous oblige à supprimer ce que vous avez déjà reçu. Laissé tel quel, le choix demeure indéfiniment valable auprès de ce payeur et ne se transfère pas : le prochain régime recueille le sien propre. Le retrait ne transite pas non plus par l'API; si un membre appelle directement l'ancien payeur, les deux parties ont besoin d'un parcours 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. Consignez les tentatives et les refus, sans quoi vous ne pouvez défendre ni l'un ni l'autre.

Une conversation, deux enregistrements

L'avis de désengagement de 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 sensibilisation 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 facultatifs, tandis que HRex Consent les exige tous les deux, ainsi que deux acteurs organisationnels. Le codage de catégorie dans PDex 2.2.0 permet de les distinguer dans un seul dépôt. Aucun indicateur ne peut jamais bloquer une réponse Patient Access, où l'autorisation de 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 déjà déployée chez des payeurs. Le principe de conception est d'intégrer, non de remplacer, et le module de saisie du consentement que nous construisons actuellement le respecte. Vous continuez à contacter 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 élaborer votre propre parcours de saisie avant la fermeture de la période 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 des partenaires commerciaux que vous déployez.