El requisito previo de la API entre Aseguradoras
Cuando un asegurado abandona un plan para incorporarse a otro, la API entre Aseguradoras es el mecanismo por el que 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 asegurado dice que sí. Ese permiso es el único requisito previo, y ninguna API lo recopila por usted. Este artículo trata sobre ese requisito y está redactado para Medicare Advantage; para el resto de la norma, consulte nuestro resumen 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 en la regulación. La cobertura de todos los inscritos comienza el 1 de enero de 2027, el día en que la obligación de la API entre Aseguradoras entra en vigor según 42 CFR 422.121. Para entonces, todos los asegurados existentes tienen derecho a recibir la oferta de aceptación, y quienes se incorporaron durante la Inscripción Anual deben recibir la misma oferta en el plazo de una semana desde el inicio de la cobertura.
Ambas ofertas se materializan hablando con el asegurado. La conversación debe recabar un conjunto específico de elementos: entre ellos, quién era el asegurador anterior, a nombre de quién estaba esa cobertura, y el permiso en sí. Recopilar esa información es lo que este artículo denomina captura. Un plan que llegue a enero sin un mecanismo para hacerlo habrá convertido el trabajo en una campaña de recuperación de datos para toda la base de asegurados. Esa campaña se ejecuta en las mismas semanas que la puesta en marcha de la API.
Lo que exige la norma
Para Medicare Advantage, las obligaciones se encuentran en la parte de API entre Aseguradoras de 42 CFR 422.121. Medicaid, CHIP y los emisores de planes de salud cualificados (QHP) en los mercados federales tienen su propia versión de la misma sección. Medicaid y CHIP difieren en tres aspectos que conviene conocer. En esos casos, es el Estado quien recopila el consentimiento, no el plan. El intercambio entre un Estado y sus propios planes contratados no requiere ningún consentimiento. Y los planes de atención gestionada asumen la obligación a través de su contrato con el Estado, no directamente desde CMS.
Para un plan de Medicare Advantage, la obligación funciona así. Ofrezca el consentimiento y un modo de modificarlo, e inicie la identificación de los aseguradores anteriores y simultáneos del asegurado, todo ello a más tardar una semana después del inicio de la cobertura. Realice esfuerzos razonables cuando el asegurado no responda. Luego, una vez que disponga del permiso y de suficiente información identificativa, envíe la solicitud de datos en el plazo de una semana, con la confirmación de que el asegurado está inscrito y ha dado su consentimiento. Repita el proceso con los aseguradores simultáneos trimestralmente mientras el asegurado esté en ambos planes. Explíquelo todo en lenguaje sencillo al realizar la consulta, una vez al año posteriormente, y en un lugar accesible en su sitio web público. Lo que se solicita es el conjunto de datos de Patient Access de los últimos cinco años, excluidos los reembolsos a proveedores, el copago del asegurado y las autorizaciones previas denegadas, más la documentación no estructurada adjunta a las autorizaciones previas.
Hay tres puntos que es fácil interpretar incorrectamente.
La primera semana cuenta desde la pregunta, no desde la respuesta. El plazo es para formular la pregunta al asegurado, no para tener su respuesta. CMS propuso «en el momento de la inscripción» y finalizó «inicio de la cobertura» porque, como señaló, las aseguradoras podrían no tener contacto con los pacientes antes de la inscripción. El preámbulo de la norma final añade que la recopilación «puede llevar más tiempo que el proceso de inscripción». Por tanto, mida el porcentaje de nuevos asegurados a quienes preguntó en los primeros siete días, no el porcentaje que respondió. Lo primero depende de su proceso; lo segundo, del comportamiento del asegurado. Un panel de control basado en lo segundo mostrará alertas cada mes sin decirle nada útil.
La segunda semana es la que puede fallar silenciosamente. No comienza hasta que usted disponga tanto del consentimiento como de información suficiente para identificar a la otra aseguradora, y a partir de ahí la solicitud tiene una semana para enviarse. Esa es la latencia dentro de su propia cola, el único plazo que sus sistemas pueden incumplir sin intervención humana, y merece una alerta de monitoreo.
La norma no le indica dónde preguntar. CMS se abstuvo de prescribir un proceso y señaló en cambio «un punto de contacto ya establecido con el paciente». Por tanto, el consentimiento no tiene que formar parte del formulario de inscripción. Para Medicare Advantage, el plazo no presupone que lo hará, ya que el cómputo comienza desde el inicio de la cobertura, no desde la inscripción. La llamada de bienvenida, el envío de la tarjeta identificativa, el primer inicio de sesión en el portal y un guión de atención al cliente están todos a su disposición. Elija el punto de contacto que controla y puede medir.
Dónde empieza FHIR, y dónde no
CMS no redactó un estándar técnico para esto. La norma exige FHIR R4, US Core y la especificación FHIR Bulk Data, remitiéndose 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, no algo que CMS verifique. Lo que PDex añade es la estructura del intercambio, y esa estructura es la que determina qué elementos debe recopilar.
La aseguradora solicitante inicia con $bulk-member-match y envía, por asegurado, datos demográficos del paciente, la cobertura anterior y el permiso, según los perfiles HRex Patient Demographics, Coverage y Consent. El respondedor evalúa a cada asegurado individualmente y devuelve tres grupos: coincidentes, no coincidentes y con restricción de consentimiento, siendo este último el de los asegurados encontrados cuyo consentimiento no puede honrarse. El grupo coincidente alimenta $davinci-data-export (intercambio masivo PDex).
FHIR es el formato de la solicitud, no el formato de la captura. Ni la norma ni las guías exigen un Questionnaire FHIR para formular las preguntas ni un servidor FHIR para almacenar las respuestas. PDex incluso hace opcional el almacenamiento del registro Consent para el receptor. Solo verifica cuatro aspectos para validar una solicitud: que el asegurado coincida, que el respondedor pueda respetar el alcance elegido por el asegurado, que el período de consentimiento sea válido, y que la aseguradora solicitante sea la aseguradora nombrada en el consentimiento. En el lado solicitante no existe ningún requisito de almacenamiento. Lo que se debe proporcionar es un HRex Patient, Coverage y Consent conformes en el momento en que se envía la solicitud, y todo lo que precede a esa transformación es de diseño libre.
La conectividad tampoco es un requisito previo. El asegurado lee el nombre de una aseguradora en su tarjeta, pero el intercambio necesita una organización con un identificador y un endpoint activo. No existe un identificador nacional de aseguradoras ni un directorio nacional para pasar de uno a otro. CMS señala que las aseguradoras probablemente tendrían que ponerse en contacto directamente con la aseguradora anterior para saber si esta soporta la API. Una norma propuesta en abril de 2026 comenzaría a cerrar esa brecha, exigiendo a las aseguradoras que notifiquen a CMS sus endpoints de API entre Aseguradoras y otros endpoints en un plazo de 60 días tras una norma final. El mecanismo aún está por determinar, así que trátelo como una dirección de avance más que como algo sobre lo que planificar en este momento. En cualquier caso, es un argumento para recopilar las elecciones ahora, porque se convierten en solicitudes a medida que los endpoints van apareciendo.
¿Debería capturar en FHIR de todos modos?
Que no sea obligatorio no significa que no valga la pena. La captura nativa en FHIR puede adoptar dos formas. Si la página que ve el asegurado es la suya, puede escribir el Consent directamente cuando el asegurado envíe el formulario, sin necesidad de un motor de formularios. Si desea que el formulario también sea un dato, el formulario orientado al asegurado es un Questionnaire FHIR, las respuestas llegan como QuestionnaireResponse y el Consent se deriva de ello. Hay dos argumentos que respaldan ambas opciones.
De todos modos necesita un almacén de consentimientos legible por FHIR en el lado servidor. Provider Access le permite responder a un proveedor solo si el asegurado no ha optado por no participar, y en el lado respondedor de la API entre Aseguradoras usted valida el consentimiento que acompaña a cada solicitud. Sus APIs ya leen un almacén de consentimientos en cada llamada. Si captura en otro lugar, tendrá que gestionar un proceso de sincronización. También está el problema de la evidencia. HRex Consent necesita un campo source que apunte a un DocumentReference, el registro de lo que el asegurado acordó en lugar de un simple indicador de sí o no. Un QuestionnaireResponse ya es ese registro, con marca temporal y vinculado al conjunto de preguntas y su versión.
Un Questionnaire no necesita el turno de publicación del proveedor. El argumento en contra de la captura nativa en FHIR es la comodidad: los asegurados ya están en el flujo del proveedor de inscripción, por lo que añadir dos preguntas allí debería ser más rápido. Esto solo es válido si el proveedor puede implementarlo, y añadir una elección de alcance, un flujo para representantes y una firma a un flujo orientado al asegurado no es una solicitud de cambio menor. Lo que decide esto es quién tiene el control. Un portal bajo su control puede escribir el Consent al enviarse. Un formulario que usted aloja puede vincularse desde el correo de bienvenida, el portal, un SMS o un enlace que un representante dicta por teléfono. Un portal que no controla no hará ninguna de las dos cosas sin la misma solicitud de cambio. El punto de contacto permanece donde estaba en cualquier caso; lo que cambia es quién puede corregir el texto en noviembre.
El argumento real en contra es la migración. Si ya dispone de una tabla de consentimientos que el negocio considera el sistema de registro, pasar a FHIR nativo implica migrarla. Vale la pena separar esto, porque el canal de captura, el formulario y el sistema de registro son tres decisiones distintas.
Cuatro decisiones que tomar antes del período de inscripción
1. Dónde se produce la captura y qué almacena la respuesta posteriormente. El canal es el punto en que la pregunta llega al asegurado: el proveedor de inscripción, el portal, el escritorio de atención al cliente o el papel. El sistema de registro es aquello que leen sus APIs una vez que el asegurado ha respondido, y no tiene por qué ser el mismo sistema. Si los permisos ya se almacenan en una tabla que usted gestiona, esa tabla es un sistema de registro heredado más que un canal, y el canal es lo que lo alimenta. Ninguna de las dos decisiones tiene que esperar a la construcción de la API. Sea cual sea su elección, añada un camino para los asegurados que no utilizan el portal. CMS «recomienda encarecidamente que exista una forma de que los pacientes registren su permiso telefónicamente o por otros medios». Las obligaciones de accesibilidad lingüística y para personas con discapacidad establecidas en 45 CFR parte 92 se aplican al formulario y al guión.
2. Cuál es el período de consentimiento. CMS indica que la elección es «válida indefinidamente con esa aseguradora» hasta que el asegurado la retire, pero HRex Consent hace obligatorias tanto la fecha de inicio como la fecha de fin. Por tanto, la fecha de fin es una política suya y no una respuesta del asegurado, y debe aparecer en el formulario que firma el asegurado.
3. Qué valor de alcance lleva el consentimiento y si el asegurado lo elige. HRex reconoce dos valores de política cuyos nombres resultan contraintuitivos: #sensitive concede acceso a todo, incluido lo que la ley trata como información sensible; #regular concede acceso a todo excepto a esa información. No tiene que presentar la elección al asegurado, porque la norma solicita un sí o un no y el alcance no está entre las cosas que debe explicar.
Lo que no puede omitir es la decisión, porque el valor sigue viajando en el Consent saliente. Un formulario que no realiza la pregunta lo fija por política, y eso es una cuestión legal más que de diseño. Enviar #sensitive implica afirmar que el asegurado autorizó la divulgación de registros protegidos bajo 42 CFR parte 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 recibe actúa en sentido contrario. Un respondedor sin etiquetas de seguridad no puede separar el subconjunto sensible, por lo que PDex lo excluye por completo en lugar de filtrar. El asegurado que pidió menos no recibe nada, mientras que el que dijo «todo» obtiene un historial completo.
4. Para qué versión de PDex están diseñados sus registros almacenados. Un único contacto de inscripción puede recopilar conjuntamente el consentimiento de la API entre Aseguradoras y el rechazo 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 el firmante a representantes personales y añade tres parámetros de búsqueda. Los registros de API entre Aseguradoras no se ven afectados por ello, porque utilizan HRex Consent y ese perfil es idéntico en ambas versiones. Para Provider Access, ajuste lo que almacena a 2.2.0 en lugar de 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 sigue nombrando PDex 2.0.0, por lo que esto es una apuesta por la guía más que por la norma. Vale la pena verificar 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 ser la versión que el resto de su implementación utiliza como objetivo.
Qué preguntar al asegurado
«Obligatorio» significa que el perfil no es válido sin ese elemento. «Must support» significa que el sistema receptor debe poder procesar el elemento si usted lo envía, lo que no equivale a la obligación de pedírselo al asegurado. «Recomendado» señala un elemento que CMS menciona en el preámbulo pero que el perfil no restringe en absoluto.
| Qué capturar | Por qué | Dónde se almacena |
|---|---|---|
| Nombre legal | obligatorio, para la identificación del asegurado | Patient.name.family, .given |
| Fecha de nacimiento | obligatorio, para la identificación del asegurado | Patient.birthDate |
| Sexo, y sexo al nacer cuando se disponga de él | must support, para la identificación del asegurado | Patient.gender, us-core-birthsex |
| Domicilio | must support, para la identificación del asegurado | Patient.address |
| Teléfono | recomendado: CMS lo menciona entre los elementos adecuados para identificar a un paciente | Patient.telecom |
| Asegurador anterior, tal como figura en la tarjeta | obligatorio en la solicitud; identifica a quién dirigirse; el asegurado puede dar su consentimiento antes de que se conozca, pero el registro Consent lo necesita | Coverage.payor a Organization |
| Número de asegurado de esa tarjeta | must support: CMS lo señala como el identificador a recopilar; el perfil necesita este dato o el ID del titular de la póliza (us-core-15) | Coverage.identifier (número de asegurado), Coverage.subscriberId (el ID del titular de la póliza) |
| Si ese plan estaba a nombre del propio asegurado, de su cónyuge o de uno de sus progenitores | obligatorio: el ID en una tarjeta suele ser el del titular, no el del paciente | Coverage.relationship, dependent, policyHolder |
| Cualquier otro plan, actual o dentro de los últimos cinco años | obligatorio según la norma: debe identificar a todos los aseguradores anteriores y simultáneos, y volver a consultar a los simultáneos trimestralmente | un Coverage por asegurador |
| El permiso en sí | obligatorio, el requisito previo de toda la API | Consent.provision.type = permit |
| Alcance: toda la información, o toda excepto la que la ley trata como sensible | obligatorio, el único control de sensibilidad que tiene el perfil | Consent.policy.uri, vinculado a los dos valores HRex |
| Quién respondió, y la relación y base de autoridad de un representante | obligatorio: HIPAA le exige tratar a un representante como al asegurado y verificar su autoridad | Consent.performer |
| El registro conservado de lo que se firmó o leyó en voz alta | obligatorio: el perfil necesita evidencia, no un indicador | Consent.source a DocumentReference |
| El período de consentimiento | obligatorio, pero usted lo proporciona: decisión 2 anterior | Consent.provision.period |
| Qué organización divulga y cuál recibe | obligatorio, pero usted lo proporciona: su identidad más la de la aseguradora anterior | Consent.provision.actor |
Eso es todo. Cada elemento que HRex Consent requiere aparece arriba o está 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 organizativos y el registro conservado provienen de su propia configuración y no del asegurado, y el artefacto firmado puede permanecer donde estén hoy sus documentos. Solo hay una pregunta no obvia aquí que nadie puede responder excepto el asegurado: 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 admite 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 poco en precisión de identificación y penaliza la tasa de cumplimentación.
- Servicios recientes y sus fechas. Desaconsejados por ser gravosos, ya que el asegurado tendría que obtenerlos de la aseguradora a la que usted está a punto de solicitar los datos.
- Números de la Seguridad Social. Han de utilizarse para identificar a los pacientes «solo cuando sea necesario (y permitido por 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 asegurados cambian de plan manteniéndose con la misma aseguradora. 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 la aseguradora, no el producto.
Lo que CMS sí respalda es conciso: el nombre del paciente, el número de asegurado, la fecha de nacimiento, la dirección física y el número de teléfono, más el nombre de la aseguradora anterior y un número de identificación del paciente o identificador similar.
Cuando el asegurado 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 aseguradores simultáneos, pero nada le obliga a eliminar lo que ya recibió. Si no se modifica, la elección permanece indefinidamente con esa aseguradora y no se transfiere: el siguiente plan recoge la suya propia. Tampoco la revocación viaja a través de la API, por lo que si un asegurado llama directamente a la aseguradora anterior, ambas partes necesitan un procedimiento operativo 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 asegurado opta por no participar, y anima a ofrecerle la posibilidad de declinar formalmente para que se detenga el seguimiento. Registre los intentos y los rechazos, o no podrá justificar ninguno de los dos.
Una conversación, dos registros
El aviso de exclusión de Provider Access lleva el mismo plazo, una semana tras el inicio de la cobertura, lo que permite que un único contacto gestione ambas cuestiones y convierte dos programas de difusión en uno solo.
Los registros permanecen separados y tienen estructuras diferentes: el perfil de consentimiento de PDex para proveedores deja opcionales la fecha de fin y el documento fuente, mientras que HRex Consent los exige a ambos, junto con dos actores organizativos. La codificación de categoría de PDex 2.2.0 los mantiene separables en un mismo almacén. Ningún indicador puede condicionar jamás una respuesta de Patient Access, donde el evento de permiso es la autorización de la propia aplicación del asegurado.
Cómo ayuda Health Samurai
Payerbox es la plataforma de Health Samurai para planes de salud en relación con CMS-0057-F, y está operativa con aseguradoras hoy. El principio de diseño es integrar, no reemplazar, y el módulo de captura de consentimiento que estamos desarrollando ahora lo sigue. Usted sigue contactando con los asegurados donde ya los alcanza, y la tabla de consentimientos que ya gestiona permanece como sistema de registro.
Consulte la solución completa en la página de Payerbox para CMS-0057-F. Para trabajar en su propio proceso de captura antes de que cierre el período de inscripción, reserve una llamada. Analizaremos dónde se encuentra hoy su consentimiento, qué debe recopilar su formulario y lo que se necesita para convertirlo en una solicitud conforme frente a lo que sus socios comerciales pongan en marcha.
