El requisito previo de la API Payer-to-Payer
Cuando un miembro abandona un plan para unirse a otro, la API Payer-to-Payer es el mecanismo mediante el cual su historial le sigue. El nuevo plan solicita al anterior hasta cinco años de reclamaciones, datos clínicos y autorizaciones previas. Nada se mueve hasta que el miembro da su conformidad. Ese permiso es el único requisito previo, y ninguna API lo recoge por usted. Este artículo trata sobre ese requisito, y está redactado pensando en Medicare Advantage; para el resto de la norma, consulte nuestra descripción general de CMS-0057-F.
En este momento, el calendario importa más que la ingeniería. La Inscripción Anual de Medicare para 2027 transcurre del 15 de octubre al 7 de diciembre de 2026, una ventana fijada por reglamento. La cobertura para todos los que se inscriban comienza el 1 de enero de 2027, el día en que la obligación Payer-to-Payer entra en vigor según 42 CFR 422.121. Para entonces, todo miembro existente tendrá derecho a recibir la opción de dar su consentimiento, y todo aquel que se haya inscrito durante la Inscripción Anual recibirá la misma oferta en el plazo de una semana desde el inicio de la cobertura.
Ambas ofertas se cumplen mediante una comunicación directa con el miembro. Esa comunicación debe obtener un conjunto específico de elementos: entre ellos, quién era el asegurador anterior, a nombre de quién estaba esa cobertura y el propio consentimiento. Recopilar esta información es lo que en este artículo se denomina captación. Un plan que llegue a enero sin un mecanismo para hacerlo habrá convertido el trabajo en una campaña de recuperación de datos sobre toda la membresía. Esa campaña se ejecutará en las mismas semanas que la puesta en marcha de la API.
Qué exige la norma
Para Medicare Advantage, las obligaciones se recogen en la parte Payer-to-Payer de 42 CFR 422.121. Medicaid, CHIP y los emisores de planes de salud calificados en los intercambios federales tienen su propia versión de la misma sección. Medicaid y CHIP difieren en tres aspectos relevantes. En ese contexto, es el Estado quien recoge el consentimiento, no el plan. Un intercambio entre un Estado y sus propios planes contratados no requiere consentimiento alguno. Y los planes de atención gestionada asumen la obligación a través de su contrato con el Estado, y no directamente de CMS.
Para un plan de Medicare Advantage, la obligación funciona de la siguiente manera. Se debe ofrecer el consentimiento y la posibilidad de modificarlo, e iniciar la identificación de los pagadores anteriores y simultáneos del miembro, todo ello a más tardar una semana después del inicio de la cobertura. Se deben realizar esfuerzos razonables cuando el miembro no responda. A continuación, una vez que se cuente con el permiso y la información de identificación suficiente, se envía la solicitud de datos en el plazo de una semana, certificando que el miembro está inscrito y ha dado su consentimiento. Esta acción se repite trimestralmente con los pagadores simultáneos mientras el miembro pertenece a ambos planes. Todo ello debe explicarse en lenguaje sencillo al solicitarlo, una vez al año después, y en un lugar accesible del sitio web público. Lo que se solicita es el conjunto de datos de acceso del paciente de los últimos cinco años, excluidos los reembolsos al proveedor, los copagos del miembro y las autorizaciones previas denegadas, más la documentación no estructurada adjunta a las autorizaciones previas.
Hay tres aspectos que resulta fácil interpretar erróneamente.
El primer plazo de una semana se mide por el momento en que se formula la pregunta, no por el momento en que se recibe la respuesta. El plazo consiste en plantear la pregunta al miembro, no en tener su respuesta. CMS propuso «en el momento de la inscripción» y finalizó la redacción como «inicio de la cobertura» porque, tal como indicó, los pagadores podrían no tener contacto con los pacientes antes de la inscripción. El preámbulo de la norma definitiva añade que la captación «puede llevar más tiempo que el proceso de inscripción». Por lo tanto, mida la proporción de nuevos miembros a quienes se les formuló la pregunta en los primeros siete días, no la proporción que respondió. Lo primero depende de su proceso; lo segundo, del comportamiento del miembro. Un panel de control construido sobre el segundo indicador mostrará siempre valores negativos sin revelar ninguna información útil.
El segundo plazo de una semana es el que puede fallar en silencio. No comienza hasta que se dispone tanto del consentimiento como de la información suficiente para identificar al otro pagador, y a partir de ahí la solicitud tiene una semana para enviarse. Esa es una latencia dentro de su propia cola, el único plazo que sus sistemas pueden incumplir sin que ninguna persona intervenga, y merece una alerta de monitorización.
La norma no indica dónde debe formularse la pregunta. CMS se negó a prescribir un proceso y apuntó en cambio a «un punto de contacto ya establecido con el paciente». Por tanto, el consentimiento no tiene que figurar en el formulario de inscripción. Para Medicare Advantage, el plazo no presupone que así sea, ya que el cómputo comienza desde el inicio de la cobertura y no desde la inscripción. La llamada de bienvenida, el envío de la tarjeta de identificación, el primer acceso al portal y un guion de atención están todos a su disposición. Elija el punto de contacto que controla y puede instrumentalizar.
Dónde empieza FHIR, y dónde no
CMS no estableció un estándar técnico para esto. La norma exige FHIR R4, US Core y la especificación FHIR Bulk Data, haciendo referencia a los estándares de API adoptados por ONC. Recomienda la guía de implementación Da Vinci PDex sin exigirla. Por tanto, la conformidad con PDex es un acuerdo entre socios comerciales y no algo que CMS comprueba. Lo que PDex añade es la estructura del intercambio, y esa estructura es la que indica qué elementos debe recopilar.
El pagador solicitante inicia con $bulk-member-match y envía, por miembro, datos demográficos del paciente, la cobertura anterior y el consentimiento, en los perfiles HRex Patient Demographics, Coverage y Consent. El respondedor evalúa cada miembro de forma independiente y devuelve tres grupos: coincidentes, no coincidentes y con restricción de consentimiento, siendo este último el de los miembros encontrados cuyo consentimiento no puede aceptar. El grupo coincidente alimenta $davinci-data-export (intercambio masivo PDex).
FHIR es el formato de la solicitud, no el formato de la captación. Nada en la norma ni en las guías exige un FHIR Questionnaire para formular las preguntas ni un servidor FHIR para almacenar las respuestas. PDex hace que el almacenamiento del registro Consent sea opcional incluso para el receptor. Solo verifica cuatro aspectos para validar una solicitud: que el miembro haya sido identificado, que el respondedor pueda aceptar el alcance elegido por el miembro, que el período de consentimiento sea válido y que el pagador solicitante sea el pagador indicado en el consentimiento. En el lado solicitante no existe ningún requisito de almacenamiento. Lo que se debe proporcionar es un Patient, Coverage y Consent de HRex conformes en el momento en que se envía la solicitud, y todo lo que queda antes de esa transformación es de libre diseño.
La conectividad tampoco es un requisito previo. El miembro lee el nombre de un pagador en una tarjeta, pero el intercambio necesita una organización con un identificador y un endpoint activo. No existe un identificador nacional de pagador ni un directorio nacional para pasar de uno al otro. CMS indica que los pagadores probablemente tendrán que contactar directamente con el pagador anterior para averiguar si siquiera cuenta con la API. Una propuesta de norma de abril de 2026 comenzaría a cerrar esa brecha, exigiendo a los pagadores que comuniquen a CMS sus endpoints de la API Payer-to-Payer y otras APIs en el plazo de 60 días tras la publicación de una norma definitiva. El mecanismo aún está por determinar, así que trátelo como una orientación futura y no como algo en lo que basar planes concretos. En cualquier caso, es un argumento para recopilar elecciones ahora, porque se convierten en solicitudes a medida que los endpoints van apareciendo.
¿Debería capturar en FHIR de todos modos?
«No obligatorio» no es lo mismo que «no merece la pena». La captación nativa en FHIR puede adoptar dos formas. Si la página que ve el miembro es de su propiedad, puede escribir el Consent directamente cuando el miembro envíe el formulario, sin necesidad de un motor de formularios. Si desea que el formulario sea también un dato, el formulario orientado al miembro es un FHIR Questionnaire, las respuestas se registran como QuestionnaireResponse y el Consent se deriva de ello. Dos argumentos respaldan ambas opciones.
De todos modos necesitará un almacén de consentimientos legible en FHIR en el lado del servidor. Provider Access le permite responder a un proveedor solo si el miembro no ha revocado su consentimiento, y en el lado respondedor de Payer-to-Payer usted valida el consentimiento que llega con cada solicitud. Sus APIs ya leen un almacén de consentimientos en cada llamada. Si capta en otro lugar, tendrá que gestionar una tarea de sincronización. También existe el problema de la evidencia. HRex Consent quiere que source apunte a una DocumentReference, el registro de lo que el miembro aceptó, en lugar de un simple indicador de sí o no. Un QuestionnaireResponse ya es ese registro, con marca de tiempo y vinculado al conjunto de preguntas y su versión.
Un Questionnaire no necesita el ciclo de publicación del proveedor. El argumento en contra de FHIR nativo es la comodidad: los miembros ya están en el flujo del proveedor de inscripción, por lo que añadir dos preguntas allí debe ser más rápido. Eso solo es válido si el proveedor puede implementarlo, y añadir una opción de alcance, una ruta para representantes y una firma a un flujo orientado al miembro no es una solicitud de cambio menor. La propiedad es lo que determina esta decisión. Un portal que usted controla puede escribir el Consent al enviar el formulario. Un formulario que usted aloja puede enlazarse desde el correo de bienvenida, el portal, un SMS o un enlace que un representante lee en voz alta. Un portal que usted no controla no hará ninguna de las dos cosas sin la misma solicitud de cambio. El punto de contacto sigue siendo el mismo en cualquier caso; lo que cambia es quién puede modificar el texto en noviembre.
El argumento real en contra es la migración. Si ya dispone de una tabla de consentimientos que el negocio trata como sistema de registro, adoptar FHIR nativo implica migrarla. Conviene separar esto, porque el canal de captación, el formulario y el sistema de registro son tres decisiones independientes.
Cuatro decisiones que tomar antes del período de inscripción
1. Dónde tiene lugar la captación y qué almacena la respuesta a continuación. El canal es el medio por el que la pregunta llega al miembro: el proveedor de inscripción, el portal, el escritorio de atención o el papel. El sistema de registro es lo que leen sus APIs una vez que el miembro ha respondido, y no tiene que ser el mismo sistema. Si los permisos ya están en una tabla que usted gestiona, esa tabla es un sistema de registro heredado, no un canal, y el canal es lo que la alimenta. Ninguna decisión tiene que esperar a que se construya la API. Sea cual sea su elección, añada una vía para los miembros que no usan portal. CMS «recomienda encarecidamente que exista una forma de que los pacientes registren su permiso por teléfono u otros medios». Las obligaciones de accesibilidad lingüística y para personas con discapacidad recogidas en 45 CFR part 92 se aplican tanto al formulario como al guion.
2. Cuál es el período de consentimiento. CMS indica que la elección «es válida indefinidamente con ese pagador» hasta que el miembro la retire, pero HRex Consent exige tanto una fecha de inicio como una fecha de fin. Por tanto, la fecha de fin es su política interna y no una respuesta del miembro, y debe aparecer en el formulario que el miembro firma.
3. Qué valor de alcance lleva el consentimiento y si el miembro lo elige. HRex reconoce dos valores de política cuyos nombres son contrarios a la intuición: #sensitive concede acceso a todo, incluido lo que la ley considera información sensible; #regular concede acceso a todo excepto esa información. No es obligatorio presentar la elección al miembro, ya que la norma pide un sí o un no y el alcance no se encuentra entre los aspectos que debe explicar.
Lo que no puede omitir es la decisión, porque el valor viaja igualmente en el Consent saliente. Un formulario que no formula la pregunta lo fija mediante política interna, y eso es una cuestión legal más que de diseño. Enviar #sensitive implica afirmar que el miembro autorizó la divulgación de registros protegidos por 42 CFR part 2 y la legislación estatal. La norma permite el intercambio solo cuando la divulgación no está prohibida por otra ley. La cantidad de datos que realmente llega presenta la dinámica contraria. Un respondedor sin etiquetas de seguridad no puede separar el subconjunto sensible, por lo que PDex opta por excluir al miembro en lugar de filtrar. El miembro que solicitó menos no recibirá nada, mientras que el que autorizó todo recibirá un historial completo.
4. A qué versión de PDex se ajustan sus registros almacenados. Un único contacto de inscripción puede recoger a la vez el consentimiento de Payer-to-Payer y la revocación de Provider Access, por lo que esta decisión abarca ambos registros. PDex 2.2.0 añade una codificación de categoría que identifica a qué API pertenece cada registro de consentimiento, obligatoria en el perfil de consentimiento de Provider Access; amplía la figura del firmante a representantes personales y añade tres parámetros de búsqueda. Los registros Payer-to-Payer no se ven afectados, ya que utilizan HRex Consent y ese perfil es idéntico en ambas versiones. Para Provider Access, dé forma a lo que almacena conforme a 2.2.0 en lugar de a 2.1: 2.2.0 es la versión actual, y los registros escritos con la estructura de 2.1 este otoño requerirán una migración. La propia recomendación de CMS aún menciona PDex 2.0.0, por lo que esto es una apuesta por la guía y no por la norma. Conviene verificarlo por separado: ambos perfiles de consentimiento hacen referencia a un Patient de US Core 7.0.0, mientras que la norma en sí apunta a US Core 3.1.1. La versión que asumen sus registros de consentimiento puede no coincidir con la que tiene como objetivo el resto de su implementación.
Qué preguntarle al miembro
«Obligatorio» significa que el perfil no es válido sin ese elemento. «Must support» significa que el sistema receptor debe ser capaz de procesar el elemento si usted lo envía, lo cual no equivale a la obligación de solicitárselo al miembro. «Recomendado» marca un elemento que CMS menciona en el preámbulo pero que el perfil no restringe en absoluto.
| Qué capturar | Por qué | Dónde se registra |
|---|---|---|
| Nombre legal | obligatorio, para la identificación del miembro | Patient.name.family, .given |
| Fecha de nacimiento | obligatorio, para la identificación del miembro | Patient.birthDate |
| Sexo, y sexo de nacimiento si se dispone de él | must support, para la identificación del miembro | Patient.gender, us-core-birthsex |
| Dirección | must support, para la identificación del miembro | Patient.address |
| Teléfono | recomendado: CMS lo menciona entre los elementos adecuados para identificar a un paciente | Patient.telecom |
| Asegurador anterior, tal como aparece impreso en la tarjeta | obligatorio, identifica a quién dirigir la solicitud | Coverage.payor a Organization |
| Número de miembro de esa tarjeta | must support: CMS indica este identificador como el que debe recogerse | Coverage.identifier (número de miembro), Coverage.subscriberId |
| Si ese plan estaba a nombre del propio miembro, de su cónyuge o de uno de sus progenitores | obligatorio: el identificador de una tarjeta suele ser el del titular de la póliza, no el del paciente | Coverage.relationship, dependent, policyHolder |
| Cualquier otro plan, vigente o de los últimos cinco años | obligatorio por la norma: debe identificar a todos los pagadores anteriores y simultáneos, y volver a consultar trimestralmente a los simultáneos | un Coverage por pagador |
| El propio consentimiento | obligatorio, el requisito previo de toda la API | Consent.provision.type = permit |
| Alcance: toda la información, o toda excepto la que la ley considera sensible | obligatorio, el único control de sensibilidad que tiene el perfil | Consent.policy.uri, vinculado a los dos valores de HRex |
| Quién respondió, y la relación y base de autoridad de un representante | obligatorio: HIPAA exige tratar a un representante como al propio miembro y verificar su autoridad | Consent.performer |
| El registro conservado de lo que fue firmado o leído en voz alta | obligatorio: el perfil exige evidencia, no un indicador | Consent.source a DocumentReference |
| El período de consentimiento | obligatorio, pero lo proporciona usted: decisión 2 anterior | Consent.provision.period |
| Qué organización divulga y cuál recibe | obligatorio, pero lo proporciona usted: su identidad más la del pagador anterior | Consent.provision.actor |
Eso es todo. Cada elemento que HRex Consent exige aparece arriba o viene fijado por el propio perfil. El perfil establece por usted el estado, el alcance, la categoría de divulgación, el permiso, la acción de divulgación y los dos roles de actor. El período de consentimiento, los dos actores de la organización y el registro conservado provienen de su propia configuración y no del miembro, y el documento firmado puede seguir donde estén hoy sus documentos. Solo hay una pregunta no obvia que únicamente puede responder el miembro: si la cobertura anterior estaba a su propio nombre.
Qué no preguntar
Tres de los cuatro puntos siguientes proceden del preámbulo. El cuarto es una decisión de diseño que se deriva de él.
- Fechas de inicio y fin de la cobertura. CMS reconoce que «pueden ser útiles en algunos casos», pero las desaconseja: «es poco probable que los pacientes conozcan o recuerden esas fechas exactas, ni que sean fáciles de encontrar». Un campo de fecha obligatorio aporta poca precisión a la identificación y penaliza la tasa de cumplimentación.
- Servicios recientes y sus fechas. Desaconsejados por ser onerosos, ya que el miembro tendría que obtenerlos del pagador al que usted está a punto de consultar.
- Números de la Seguridad Social. Se deben utilizar para identificar a los pacientes «solo cuando sea necesario (y lo permita la ley)».
- El nombre específico del plan. Los comentaristas instaron a CMS a no exigirlo: los nombres de los planes son largos, poco intuitivos y los miembros cambian de plan mientras permanecen con el mismo pagador. CMS no se pronunció en ningún sentido, por lo que omitirlo es una decisión de diseño. Lo que el enrutamiento necesita es el pagador, no el producto.
Lo que CMS sí avala es breve: el nombre del paciente, el número de miembro, la fecha de nacimiento, la dirección física y el número de teléfono, más el nombre del pagador anterior y un número de identificación del paciente o identificador similar.
Cuando el miembro no responde o cambia de opinión
La retirada del consentimiento solo opera hacia el futuro. Detiene las solicitudes futuras, incluido el intercambio trimestral con pagadores simultáneos, pero nada le obliga a eliminar lo que ya ha recibido. Si no se modifica, la elección permanece indefinidamente con ese pagador y no se transfiere: el siguiente plan recoge la suya propia. La revocación tampoco viaja por la red, así que si un miembro contacta directamente con el pagador anterior, ambas partes necesitan una vía operativa para gestionar un cambio de permiso comunicado por teléfono.
Los esfuerzos razonables tienen un mínimo: CMS recomienda realizar un seguimiento una vez antes de concluir que el miembro opta por no dar su consentimiento, y anima a ofrecerle una forma de declinar para que el seguimiento cese. Registre los intentos y las negativas, o no podrá acreditar ninguno de los dos.
Una conversación, dos registros
El aviso de revocación del consentimiento de Provider Access lleva el mismo plazo de activación, una semana después del inicio de la cobertura, lo que permite que un único contacto cubra ambos y convierte dos programas de comunicación en uno solo.
Los registros permanecen separados y tienen estructuras diferentes: el perfil de consentimiento de proveedor de PDex deja opcionales la fecha de fin y el documento fuente, mientras que HRex Consent exige ambos, más dos actores de la organización. La codificación de categoría de PDex 2.2.0 permite distinguirlos en un mismo almacén. Ninguno de los dos indicadores puede condicionar jamás una respuesta de Patient Access, donde el evento de permiso es la autorización del propio miembro en su aplicación.
Cómo ayuda Health Samurai
Payerbox es la plataforma CMS-0057-F de Health Samurai para planes de salud, y ya está operativa con pagadores hoy. El principio de diseño es integrar, no sustituir, y el módulo de captación de consentimientos que estamos desarrollando lo sigue. Usted sigue preguntando a los miembros donde ya los alcanza, y la tabla de consentimientos que ya gestiona sigue siendo el sistema de registro.
Consulte la solución completa en la página de Payerbox para CMS-0057-F. Para analizar su propia vía de captación antes de que cierre el período de inscripción, reserve una llamada. Examinaremos dónde se encuentra hoy su consentimiento, qué debe recopilar su formulario y qué se necesita para convertir eso en una solicitud conforme frente a lo que establezcan sus socios comerciales.
