Una respuesta ausente no es un no

Una pila suelta de expedientes de papel, en abanico, sobre una mesa. El expediente de arriba, con líneas como un formulario sin terminar, está cruzado en ángulo por un sello de tinta color óxido que dice NO RESPONDIDO.

Entre abril de 2023 y junio de 2024, los estados volvieron a revisar la elegibilidad de Medicaid para 94.3 millones de personas. Casi 21 millones perdieron su cobertura. De esas bajas, 14.3 millones fueron procedimentales, que es el término oficial para un caso cerrado porque los papeles no llegaron de vuelta. Las otras 6.5 millones fueron personas a quienes un estado determinó, de hecho, que ya no eran elegibles.

De esa diferencia quiero escribir. Para aproximadamente siete de cada diez personas que perdieron Medicaid, nadie decidió que ya no calificaban. El registro dice que el estado no volvió a saber de ellas.

Quiero ser precisa sobre lo que ese número es y lo que no es. No es un conteo de personas dadas de baja por error. Algunas se mudaron, algunas pasaron a otra cobertura por edad, algunas consiguieron un empleo con seguro, algunas no quisieron renovar. Un cierre procedimental no es lo mismo que un error. Pero tampoco es una determinación, y ambas cosas terminan escritas en el mismo campo, reportadas en el mismo total, y entregadas a la misma persona como el mismo evento. La cobertura terminó.

KFF plantea el riesgo con claridad: las bajas procedimentales ocurren cuando el estado tiene información de contacto desactualizada, o cuando alguien no entiende o no devuelve el paquete de renovación a tiempo, y muchas de las personas dadas de baja de esta forma podrían seguir siendo elegibles (se abre en una pestaña nueva). Su trabajo de encuestas respalda esa preocupación. Entre las personas adultas que dijeron haber sido dadas de baja durante el desenrollamiento, el 47 por ciento se había vuelto a inscribir en Medicaid para inicios de 2024, y el 70 por ciento quedó sin seguro al menos temporalmente en el camino. Un sistema que cierra un caso y lo reabre cuatro meses después no tomó una decisión sobre esa persona. La dejó caer.

Yo misma he lanzado este error a producción

Reconozco esta falla porque sigo encontrándola en mi propio código.

plumbline (se abre en una pestaña nueva) es un arnés de auditoría de cierre-seguro que escribí para calificar sistemas de IA construidos para uso gubernamental. Un objetivo devolvió 174 respuestas en blanco y obtuvo una puntuación perfecta de 1.0000 en fundamentación, privacidad, daños representacionales, equidad y comportamiento entre idiomas. La compuerta salió con PASS. Cada una de esas verificaciones está formulada como la ausencia de un problema, y el silencio no contiene ningún problema. El silencio pasó la prueba.

Una vez que vi el patrón, estaba en todas partes en mis propios repositorios. ceqa-preflight (se abre en una pestaña nueva) imprimió cuatro líneas de PASS sobre un paquete de presentación cuyos PDF habían agotado el tiempo de espera, idénticas byte a byte a las líneas que produce un paquete limpio, y una de esas cuatro era la verificación de contenido activo, así que el reporte declaró aprobado un documento que nunca había abierto. Un monitor semanal en id-churn-sentinel (se abre en una pestaña nueva) se mantuvo en verde durante cuatro semanas consecutivas mientras su registro dejaba cero de 152 fuentes elegibles para revisar, porque no observar nada emitía la misma señal que observar que no hubo cambios. Una estadística de calibración de jueces en fare-policy-assistant (se abre en una pestaña nueva) reportó un acuerdo perfecto de 1.000, porque cada etiqueta que registraba un desacuerdo se había vuelto obsoleta y la muestra que sobrevivía era la mitad que sí coincidía.

Cada uno de esos casos estaba en verde en su momento. Cada uno era una verificación que no podía fallar. La corrección fue la misma en todos los casos: separar la ausencia de evidencia de la evidencia de ausencia, y darle al caso faltante su propio nombre.

La razón por la que escribo sobre sistemas de beneficios y no sobre mis propios arneses de prueba es que lo que está en juego no es comparable. Cuando plumbline se equivoca en esto, un reporte queda mal. Cuando un sistema de elegibilidad se equivoca en esto, alguien pierde su cobertura de salud y se entera en el mostrador de la farmacia.

Cómo se ve la respuesta ausente dentro de un sistema de elegibilidad

En septiembre de 2023, CMS les dijo a los estados que se detuvieran (se abre en una pestaña nueva). Treinta estados habían reportado el mismo defecto: sus sistemas de elegibilidad estaban ejecutando renovaciones automáticas a nivel del hogar en lugar de a nivel individual, como exigen las reglas federales. El efecto práctico fue que un hogar con un solo integrante que necesitara presentar algo podía tener la cobertura de todos sus integrantes dada de baja, incluyendo a niños y niñas sobre quienes el estado ya tenía datos que mostraban que seguían siendo elegibles. CMS ordenó a esos estados pausar las bajas procedimentales y restituir la cobertura de las personas afectadas. GAO reportó después (se abre en una pestaña nueva) que cerca de 420,000 personas en 29 estados perdieron su cobertura de esta manera, y que todas fueron restituidas para enero de 2024.

Hay que leer esa falla con cuidado, porque no es una falla de política y no es una falla por fraude. Es una falla de modelado de datos. El sistema tenía la información que necesitaba para renovar a esos niños y niñas. Formuló la pregunta en el nivel equivocado, obtuvo una respuesta incompleta para el hogar, y escribió esa falta de información en cada registro individual debajo. Nadie eligió dar de baja a 420,000 personas. Lo hizo un join.

El mismo patrón aparece en cualquier lugar donde la verificación se topa con una fecha límite:

  • Una consulta de verificación agota el tiempo de espera, y el caso se registra como verificación fallida en lugar de verificación no completada.
  • La carga de un documento falla en silencio en un teléfono, y el archivo se registra como no proporcionado.
  • Un aviso llega a una dirección desactualizada, y la ausencia de respuesta se registra como un no.
  • Alguien que solicita se pierde una entrevista programada por estar en su turno de trabajo, y la solicitud se rechaza en lugar de quedar en espera.

Esto no es raro ni es pequeño. En un estado grande del sur, entre las personas que solicitaron asistencia alimentaria en línea entre septiembre y diciembre de 2023, el 21.1 por ciento del grupo de control fue rechazado porque quienes trabajaban el caso no tenían suficiente información para decidir si eran elegibles (se abre en una pestaña nueva). Una de cada cinco personas solicitantes recibió una respuesta que no era sobre ella. El equipo federal de evaluación que realizó ese estudio describe la categoría con las propias palabras del estado: no presentar los documentos de verificación o no completar la entrevista produce un rechazo por información incompleta, y no un rechazo por inelegibilidad.

La versión de este problema relacionada con las entrevistas tiene una solución medida. Un experimento de campo aleatorizado con aproximadamente 65,000 personas solicitantes de SNAP en Los Ángeles (se abre en una pestaña nueva) encontró que dejar que quienes solicitaban iniciaran su propia entrevista cuando de verdad estaban disponibles, en lugar de exigirles mantener una cita programada, aumentó las aprobaciones en más de seis puntos porcentuales y duplicó las aprobaciones tempranas, de 14 a 27 por ciento para el día cinco. Nada sobre la elegibilidad de nadie cambió. Lo que cambió fue si el sistema podía escucharlas. Quienes escribieron el estudio plantean el caso general con claridad: muchas solicitudes de programas gubernamentales terminan en rechazos procedimentales causados por la carga de solicitar, y no por inelegibilidad.

Los estados que deberían existir

Esta es la parte que encuentro genuinamente alentadora. El gobierno ya modela esto correctamente, por escrito, en más de un programa.

La plantilla de reporte de CMS para el desenrollamiento no tiene una sola categoría llamada "cobertura perdida". La métrica 5b es el número de personas determinadas inelegibles. La métrica 5c es el número de personas cuya cobertura se terminó por razones procedimentales, y la propia plantilla aclara esa frase: no responder. La métrica 5d es el número de personas cuya renovación no se completó. Son resultados distintos con significados distintos, y el requisito de reporte los mantiene separados a propósito (se abre en una pestaña nueva). El ejemplo de SNAP es igual. Un rechazo por información incompleta y un rechazo por inelegibilidad son categorías separadas dentro del propio proceso del estado.

La distinción no es algo que yo esté proponiendo. Existe en la regulación, en la plantilla de reporte, y en el vocabulario de quien trabaja el caso. Se pierde en el camino entre eso y la base de datos.

Lo cual significa que la regla de diseño no es novedosa y no requiere que nadie cambie ninguna política. Requiere que el software preserve una diferencia que la política ya establece. Como mínimo, un sistema de solicitud o renovación debería poder representar, y tratar de forma distinta, lo siguiente:

  • No preguntado. La pregunta nunca aplicó a esta persona, o el flujo nunca llegó hasta ahí.
  • No respondido. Se hizo la pregunta y no llegó nada de vuelta. Este es el estado que se destruye con más frecuencia.
  • Respondido, y la respuesta es no. Una persona o quien trabaja el caso afirmó algo.
  • No se pudo verificar. El sistema intentó verificar y no pudo, porque un servicio estaba caído, una coincidencia falló, o un documento no se pudo leer. Esto no es en absoluto la respuesta de quien solicita. Es la del sistema.
  • No aplica. Irrelevante por estructura, y distinto de todo lo anterior.

Reduce esos cinco estados a un booleano y habrás construido una máquina que no puede distinguir entre una persona que no califica y una persona a la que no se logró contactar. Mantenlos separados y varias cosas se vuelven posibles que antes no lo eran. El sistema puede enrutar un no-se-pudo-verificar hacia un reintento o hacia quien trabaja el caso, en lugar de hacia un rechazo. Puede decirle a quien solicita exactamente qué falta, en lugar de decir que su solicitud está incompleta. Puede reportar los cierres procedimentales por separado de los rechazos por inelegibilidad, para que una agencia pueda ver la carga que su propio proceso está generando, en lugar de leerla como una lista de personas inelegibles. Y puede fallar de forma ruidosa hacia la agencia mientras falla de forma suave hacia el residente, que es la dirección correcta para ambos.

Un diagrama en estilo de libro contable. Lado izquierdo: cuatro hechos distintos — no preguntado, no respondido, no se pudo verificar, no aplica — que convergen con flechas en una sola casilla sellada que dice RESPUESTA: NO, con un sello de COLAPSADO. Lado derecho: cinco filas separadas de libro contable, cada una con un estado — no preguntado, no respondido, respondido y la respuesta es no, no se pudo verificar, no aplica — cada una con su propia descripción de una línea.
Cinco estados, un solo campo: lo que un registro booleano colapsa frente a lo que un registro de cinco estados mantiene separado.

Los números de renovación automática (ex parte) muestran cuánto margen hay. De las personas cuya cobertura de Medicaid se renovó durante el desenrollamiento, el 61 por ciento fue renovada automáticamente a partir de datos que el estado ya tenía, sin que la persona inscrita hiciera nada. Esa tasa superó el 90 por ciento en Arizona, Carolina del Norte y Rhode Island, y fue del 11 por ciento o menos en Pensilvania y Texas. Las mismas reglas federales, las mismas fuentes de datos disponibles, y al menos una diferencia de ocho veces en qué tan seguido el estado responde su propia pregunta en lugar de enviársela por correo a una familia. Lo que daña a las personas aquí no es la automatización. Es pedirles información que el gobierno ya tiene.

Lo que hago ahora

Tengo una regla en los proyectos que publican mediciones sobre instituciones reales, y sobrevive el contacto con producción precisamente porque es aburrida: un valor que no fue medido nunca se muestra como un valor medido.

En afterward (se abre en una pestaña nueva), que vincula programas de capacitación de California con las proyecciones ocupacionales del estado, los resultados suprimidos o no reportados nunca se muestran como cero, y la cobertura es un resultado publicado y no una nota al pie. En disclosed (se abre en una pestaña nueva), que califica a universidades por lo que divulgan y no por su desempeño, cada valor publicado se clasifica como reportado, inverosímil, suprimido, no aplicable o faltante, porque una medida suprimida y un cero son hechos distintos que la mayoría de las herramientas muestran de forma idéntica. En GTFS Scorecard, un feed que mi extractor no pudo alcanzar se califica como "no medido", que es un resultado de primera clase distinto de aprobado, y una prueba hace fallar la compilación si un objetivo silencioso vuelve a calificar como limpio.

Nada de eso es ingenioso. Es la misma regla cinco veces: mantener separado el caso faltante, nombrarlo en el esquema, y hacer que la interfaz lo muestre.

Aprendí el comienzo de esto hace una década en el gobierno del estado de California, construyendo el Registro público de Asistentes de Cuidado en el Hogar y los flujos de renovación y servicio continuo detrás de él. Todo registro con renovación tiene que responder la misma pregunta que CMS les estaba haciendo a los estados en 2023: ¿qué hace el sistema cuando la renovación no llega de vuelta? Esa es una decisión de diseño. Alguien la toma, usualmente temprano, usualmente con prisa, y usualmente sin dejar constancia de que la tomó. Después se ejecuta sobre todas las personas, para siempre, a la escala que el programa alcance.

La obligación

Sigo volviendo a una frase de mi último ensayo sobre calificar datos públicos: todo número necesita un denominador, y todo estado necesita un significado. En un sistema de beneficios, el estado es la cobertura de una persona, y ese significado más vale que sea el que la agencia pretendía.

Catorce punto tres millones de bajas procedimentales no son catorce punto tres millones de respuestas equivocadas. Son catorce punto tres millones de casos en los que el software registró un resultado que ningún ser humano determinó. Algunos de ellos eran correctos. El sistema no puede decirte cuáles, y ese es el defecto.

Un sistema público de beneficios debería poder decir "todavía no lo sabemos" en voz alta, tanto a quien solicita como a la agencia, mientras eso siga siendo cierto. La puerta de entrada a un programa público nunca debería poder decir no por accidente.

  • Beneficios públicos
  • Carga administrativa
  • Sistemas de elegibilidad
  • Tecnología cívica
  • Calidad de datos
  • Tecnología de interés público