El Slack de tecnología sanitaria de CMS ofrece a las empresas de IA un atajo político hacia Medicare
CMS otorgó a un espacio de trabajo de 1.700 miembros un papel inusualmente directo en las conversaciones sobre aplicaciones sanitarias con IA, historiales médicos y políticas de pago de Medicare. El Slack de tecnología sanitaria de CMS incluía a Microsoft, OpenAI, Anthropic, Apple, Google, inversores y otros intereses tecnológicos. Sin embargo, según los informes, médicos, representantes de hospitales y defensores de pacientes tuvieron una presencia mucho menor.
El acuerdo importa porque CMS está haciendo más que recabar comentarios técnicos. La agencia ha lanzado una Biblioteca de Aplicaciones de Medicare y ha abierto un modelo de pago para la atención de enfermedades crónicas respaldada por tecnología. Ambas iniciativas pueden convertir la visibilidad gubernamental en distribución, credibilidad e ingresos para las empresas participantes.
Una investigación sobre Slack de KFF Health News y CBS News describe reuniones privadas, conversaciones sobre políticas y el impulso gubernamental a las aplicaciones de salud. CMS califica la iniciativa como una colaboración técnica abierta y voluntaria. Los críticos ven un proceso que se asemeja a la formulación de políticas sin el equilibrio y la transparencia que se esperan de un organismo asesor federal formal.
El conflicto central no enfrenta a las empresas tecnológicas con el gobierno. Se trata de un impulso liderado por la industria para acelerar el acceso a datos de salud frente a las salvaguardas públicas que normalmente acompañan a la política sanitaria federal. Ese conflicto determinará quién controla los historiales médicos, qué aplicaciones promueve Medicare y quién asume la responsabilidad cuando falla el consejo de una IA.
El Slack de tecnología sanitaria de CMS se convirtió en algo más que un foro técnico
Un canal privado de coordinación pasó a formar parte de la maquinaria que conecta el diseño de productos, la política federal, la distribución de Medicare y los futuros reembolsos.
CMS creó su Ecosistema de Tecnología Sanitaria para facilitar a los pacientes el acceso y el intercambio de sus historiales médicos. La iniciativa también buscaba aplicaciones que pudieran utilizar esos historiales para programar citas, apoyar enfermedades crónicas e implementar IA conversacional.
El gobierno federal presentó inicialmente ese trabajo como un amplio esfuerzo de interoperabilidad. La interoperabilidad implica que distintos sistemas sanitarios puedan intercambiar y utilizar la misma información del paciente mediante estándares técnicos compartidos.
En julio de 2025, la administración Trump anunció compromisos de importantes organizaciones tecnológicas y sanitarias. Amazon, Anthropic, Apple, Google y OpenAI figuraban entre los participantes nombrados.
Más de 60 organizaciones asumieron compromisos iniciales, según reportes de la época. Posteriormente, CMS afirmó que la participación había crecido a más de 700 organizaciones para abril de 2026.
La iniciativa pública incluía dos objetivos conectados. Uno consistía en hacer que los historiales médicos fueran portables entre proveedores y aplicaciones. El otro consistía en fomentar productos orientados a los pacientes que pudieran utilizar esos historiales.
Detrás de esa campaña pública, CMS gestionaba un espacio de trabajo de Slack que, según los informes, creció hasta 1.700 miembros. El espacio puso a funcionarios federales en contacto recurrente con empresas tecnológicas, inversores, consultores y emprendedores del sector sanitario.
Slack en sí no es el problema importante. Las agencias necesitan habitualmente conversaciones técnicas con especialistas externos. La preocupación es qué ocurrió a través del canal y quién obtuvo un acceso significativo.
Según la investigación, CMS utilizó el espacio de trabajo para invitar a empresas seleccionadas a reuniones con funcionarios federales. Una sesión de febrero involucró al menos a 35 organizaciones del sector y se centró en productos de IA conversacional para pacientes.
La Administración de Alimentos y Medicamentos participó porque algunas aplicaciones de salud pueden quedar bajo su autoridad sobre dispositivos médicos. Según los informes, se pidió a las empresas que describieran sus productos y explicaran cómo accedían a información sensible de los pacientes.
La reunión no apareció en el calendario público de la FDA ni en un aviso regulatorio, según los reportes. Los pacientes y el público en general no fueron invitados mediante un proceso abierto.
Un asesor de políticas de CMS describió la sesión como una oportunidad para ayudar a la FDA a dar forma a futuras orientaciones. Ese lenguaje situó a las empresas participantes cerca de la elaboración de normas que regían sus propios productos.
CMS ha cuestionado la idea de que el espacio de trabajo sea un comité asesor de políticas. Según los informes, su código de conducta indicaba que el grupo no proporcionaría asesoramiento ni recomendaciones a funcionarios federales.
Esa distinción resulta más difícil de sostener cuando los funcionarios solicitan opiniones sobre orientaciones, requisitos de productos y vías de pago. Una exención de responsabilidad describe la categoría jurídica prevista, pero no resuelve cómo funcionó el grupo en la práctica.
El espacio de trabajo también presentaba un marcado desequilibrio de participación. La investigación encontró apenas un puñado de médicos, representantes de hospitales y defensores de pacientes entre sus 1.700 miembros.
Ese desequilibrio importa en la atención sanitaria. Los desarrolladores pueden explicar API, sistemas de identidad y comportamiento de modelos. No pueden representar de forma independiente a pacientes que enfrentan deterioro cognitivo, enfermedades crónicas, barreras lingüísticas o acceso digital limitado.
Por tanto, el Slack de tecnología sanitaria de CMS creó su primera gran tensión. La agencia quería una rápida coordinación técnica, pero el proceso concentró la influencia entre organizaciones posicionadas para beneficiarse del sistema resultante.
La Biblioteca de Aplicaciones de Medicare convierte la visibilidad en poder de mercado
Un lugar en la Biblioteca de Aplicaciones de Medicare puede funcionar como una señal de confianza gubernamental, incluso cuando CMS no respalda formalmente el producto.
CMS lanzó la primera ola de su Ecosistema HealthTech en abril de 2026. El lanzamiento combinó infraestructura técnica, aplicaciones orientadas a los pacientes y una Biblioteca de Aplicaciones de Medicare.
La biblioteca dirige a adultos mayores y personas con discapacidad hacia aplicaciones comerciales de salud. Sus primeras inclusiones cubrían usos como la gestión del peso, el apoyo a la diabetes, la atención oncológica y la orientación sanitaria asistida por IA.
Según los informes, funcionarios de CMS hablaron directamente de esa visibilidad con participantes del sector. Antes del lanzamiento público, un funcionario describió cómo los beneficiarios podrían confiar en una aplicación porque Medicare.gov la promocionaba.
Esa observación resume el valor comercial. Medicare no necesita afirmar que una aplicación es segura, eficaz o clínicamente superior para que los usuarios perciban una aprobación.
Una inclusión federal tiene peso institucional. Muchos beneficiarios no distinguirán entre una entrada en un directorio, una cualificación técnica, un resultado de acreditación y un respaldo clínico.
CMS indica a los desarrolladores que una aplicación debe primero adherirse al compromiso del Ecosistema de Tecnología Sanitaria. Después debe cumplir requisitos relacionados con verificación de identidad, interoperabilidad, seguridad, privacidad y acreditación externa.
Las normas de envío de aplicaciones de la agencia exigen conexiones a redes de datos alineadas con CMS. También requieren compatibilidad con FHIR R4 y SMART on FHIR.
FHIR es un estándar para intercambiar información sanitaria estructurada. SMART on FHIR añade un marco de autorización que permite a las aplicaciones solicitar acceso autorizado a esos historiales.
Esos requisitos abordan problemas técnicos reales. Un paciente puede recibir atención de varios hospitales, laboratorios, especialistas, farmacias y aseguradoras. Cada organización puede almacenar solo una parte del historial.
Una aplicación aprobada podría reunir esos fragmentos en una sola vista. Un asistente de IA podría entonces utilizar resultados de laboratorio, historiales de medicamentos, diagnósticos o datos de dispositivos wearables para personalizar sus respuestas.
Eso supone una mejora significativa frente a pedir a los usuarios que recuerden cada prueba y receta. También crea una recopilación de datos mucho más sensible dentro de un producto de consumo.
CMS afirma que los asistentes conversacionales deben etiquetar las respuestas generadas por IA y distinguir la información educativa del consejo clínico. Sin embargo, una etiqueta no puede impedir que los usuarios traten una orientación personalizada como juicio médico.
La distinción se vuelve aún menos clara cuando un asistente conoce las enfermedades y medicamentos de una persona. El consejo basado en un historial médico completo parecerá más autorizado que la respuesta de un chatbot genérico.
La biblioteca también puede favorecer a los proveedores más grandes. Microsoft y Google ya cuentan con amplias relaciones en la nube, identidad, seguridad y atención sanitaria. OpenAI y Anthropic aportan productos de IA ampliamente reconocidos y recursos técnicos considerables.
Las empresas sanitarias más pequeñas pueden tener un conocimiento más profundo de una enfermedad concreta. Sin embargo, pueden afrontar costes relativos más altos de acreditación, verificación de identidad, integración de redes, revisión de seguridad e interacción con el gobierno.
Esto produce una ventaja estructural. Las empresas que ya están dentro del Slack de tecnología sanitaria de CMS pueden saber cómo evolucionan los requisitos mientras construyen los sistemas destinados a cumplirlos.
El acceso no prueba favoritismo. Sí acorta la distancia entre la hoja de ruta de un proveedor y las expectativas emergentes del gobierno.
Por tanto, los pacientes deberían interpretar la Biblioteca de Aplicaciones de Medicare como un punto de acceso seleccionado, no como una clasificación de calidad clínica. Los responsables políticos deben dejar clara esa frontera antes de que la confianza se convierta en un sustituto de la evidencia.
El acceso al Slack de tecnología sanitaria de CMS ahora se conecta con los pagos de Medicare
Lo que estaba en juego aumentó cuando un proyecto de interoperabilidad obtuvo una vía hacia el reembolso de Medicare para la atención respaldada por tecnología.
CMS lanzó el Modelo ACCESS en julio de 2026. ACCESS significa Advancing Chronic Care with Effective, Scalable Solutions.
El modelo voluntario crea pagos alineados con resultados para organizaciones que apoyan a personas con enfermedades crónicas. En lugar de pagar solo por actividades clínicas definidas, CMS puede vincular los pagos a resultados de salud medibles.
Las áreas iniciales incluyen hipertensión arterial, diabetes, dolor musculoesquelético crónico y depresión. CMS afirma que más de dos tercios de los beneficiarios de Medicare viven con enfermedades cubiertas por el modelo inicial.
El programa se extiende durante diez años. Para abril de 2027 están previstas vías adicionales para insuficiencia cardíaca, enfermedad pulmonar obstructiva crónica, trastorno por consumo de sustancias y abandono del tabaco.
En virtud del modelo de pago ACCESS, los clínicos pueden trabajar con organizaciones que ofrecen monitorización remota, aplicaciones, acompañamiento u otros servicios relacionados respaldados por tecnología.
Este enfoque responde a una verdadera brecha de pago. El Medicare tradicional de pago por servicio remunera actividades específicas, mientras que la atención digital puede producirse de forma continua y asíncrona entre citas.
Una aplicación podría monitorizar la presión arterial, identificar mediciones omitidas e instar a un paciente a contactar con un clínico. Otro servicio podría combinar acompañamiento con datos de dispositivos wearables para el manejo de la diabetes.
Los pagos vinculados a resultados pueden animar a los proveedores a centrarse en la mejora del paciente en lugar de en minutos de interacción o volumen de notificaciones. Sin embargo, el modelo también dirige dinero público hacia empresas que desarrollan las herramientas.
Ese cambio hace que el acceso temprano a las políticas sea comercialmente importante. El mismo ecosistema aborda el acceso a datos, la cualificación de aplicaciones, la distribución y una vía hacia servicios financiados por Medicare.
La investigación informó que funcionarios de CMS sugirieron que los participantes de la Biblioteca de Aplicaciones de Medicare podrían recibir trato prioritario dentro del nuevo modelo. La página pública de envío de CMS indica que los participantes de ACCESS reciben una designación especial en la biblioteca.
También afirma que esos participantes están exentos de determinados requisitos de revisión y acceso de prueba de CMS. Esa relación estrecha la conexión entre el pago gubernamental y la visibilidad gubernamental.
Por lo tanto, una empresa puede obtener varias ventajas a través de un único ecosistema. Puede conseguir conexiones con historiales médicos, aparecer en un directorio de Medicare, generar confianza entre los beneficiarios y participar en un modelo de pago basado en resultados.
Ningún beneficio aislado demuestra una influencia indebida. Su combinación cambia la naturaleza de la iniciativa.
El gobierno no se limita a publicar un estándar técnico. Está ayudando a definir el mercado, organizar a sus participantes, distribuir sus productos y establecer las condiciones de pago.
Esa combinación presiona a tres grupos.
Los desarrolladores independientes se enfrentan a estándares configurados mediante un proceso en el que quizá no influyeron. Los médicos se enfrentan a herramientas que pueden insertar servicios comerciales en la atención en curso. Los pacientes se enfrentan a decisiones sobre si compartir historiales médicos completos con aplicaciones privadas.
CMS también enfrenta su propia presión. Debe avanzar con suficiente rapidez para que la portabilidad de los datos sea útil, al tiempo que demuestra que la velocidad no ha desplazado la evaluación independiente.
Los compromisos originales de la agencia destacaban el control por parte del paciente, una menor carga para los proveedores y mejores resultados de salud. Esos objetivos siguen siendo razonables.
La prueba consiste en determinar si el sistema de pagos verifica los resultados de forma independiente. También debe impedir que las empresas seleccionen a los pacientes más fáciles, usen grupos de comparación débiles o definan el éxito en torno a mediciones limitadas.
Una aplicación puede reducir un indicador registrado sin mejorar la atención general de un paciente. También puede generar buenos resultados promedio mientras falla a las personas con conectividad limitada o afecciones complejas.
El pago basado en resultados no equivale automáticamente a rendición de cuentas. El diseño de la medición determina si el sistema recompensa la mejora de la salud, la selección favorable de pacientes o la presentación ingeniosa de informes.
Un acceso más rápido a los historiales médicos crea una disyuntiva de privacidad
Hacer portátiles los historiales da a los pacientes más control, pero también traslada información sensible más allá de los límites de privacidad sanitaria conocidos.
El marco de interoperabilidad de CMS busca un acceso amplio mediante credenciales de identidad aprobadas y redes de datos alineadas. Un paciente verificado no debería necesitar cuentas de portal separadas para cada proveedor.
El marco también exige registros de transacciones que muestren quién accedió a la información, cuándo ocurrió el acceso y por qué. Estos controles pueden reducir la fricción y hacer más visible el uso de los datos.
El enfoque aborda una antigua falla de la atención sanitaria. A menudo, los pacientes no pueden recuperar historiales completos sin navegar por varios portales, solicitudes por fax y procedimientos institucionales.
La transferencia sencilla puede ayudar cuando alguien cambia de médico o necesita atención urgente. También puede ofrecer a una aplicación contexto suficiente para detectar conflictos de medicación o preparar preguntas útiles para una cita.
La portabilidad no garantiza la privacidad después de la transferencia. Las protecciones legales pueden cambiar cuando un paciente indica a un proveedor que envíe información a una aplicación de consumo independiente.
La orientación de HHS explica que HIPAA, por lo general, no cubre la información introducida en una aplicación operada fuera de una relación sanitaria regulada. Esto sigue siendo cierto incluso cuando la información se originó en un historial médico protegido.
La orientación sobre aplicaciones y HIPAA establece un límite importante. La aplicación de un hospital suele seguir estando sujeta a HIPAA, mientras que una aplicación de consumo no relacionada puede no estarlo.
Aun así, se aplican otras protecciones. La Comisión Federal de Comercio puede impugnar declaraciones de privacidad engañosas y hacer cumplir las obligaciones de notificación de brechas contra muchos proveedores de aplicaciones de salud.
La norma actualizada sobre brechas de salud de la FTC cubre explícitamente muchas aplicaciones y dispositivos conectados fuera de HIPAA. Las divulgaciones no autorizadas pueden considerarse brechas, no solo los incidentes de piratería externa.
Estas protecciones son importantes, pero no hacen que todos los regímenes de privacidad sean equivalentes. HIPAA establece obligaciones detalladas para las entidades cubiertas y sus asociados comerciales antes de que ocurra una brecha.
La legislación de consumo suele depender de lo que una empresa prometió, de si su conducta fue engañosa o de si una divulgación no autorizada activó la obligación de notificar. La aplicación de la ley puede llegar después de que la información ya se haya trasladado.
Los historiales médicos son excepcionalmente difíciles de restablecer. Un paciente puede reemplazar una contraseña o una tarjeta de pago, pero no puede reemplazar un diagnóstico, un riesgo genético, un historial psiquiátrico o un registro de medicación.
Los servicios de IA plantean más preguntas. Una empresa debe explicar si los datos de salud entrenan modelos, mejoran productos, respaldan publicidad o se transmiten a proveedores de servicios.
Los usuarios también necesitan saber cómo funciona la eliminación. Eliminar una conversación de una interfaz no responde necesariamente a si los datos derivados, registros, copias de seguridad o registros de seguridad permanecen en otro lugar.
El consentimiento se convierte en el problema central de diseño. Una única pantalla de autorización puede permitir técnicamente el acceso sin ayudar a alguien a comprender las consecuencias.
Un consentimiento significativo debería separar la obtención de historiales del uso secundario. Debería identificar cada categoría de datos, cada destinatario, el período de conservación y un proceso práctico de revocación.
Los adultos mayores pueden afrontar desafíos adicionales. Algunos beneficiarios dependen de cuidadores, usan dispositivos compartidos o tienen afecciones que afectan a la comprensión y la toma de decisiones.
Una credencial de identidad segura puede confirmar quién solicita información. No puede establecer que esa persona comprende cada uso posterior de los datos.
Según informes, el Slack de tecnología sanitaria de CMS incluyó conversaciones sobre cuánto consentimiento necesitan las aplicaciones antes de acceder a historiales. Precisamente ahí es donde los representantes de pacientes merecen una influencia comparable.
Los desarrolladores optimizan naturalmente para reducir los pasos porque cada pantalla adicional puede disminuir la adopción. Los pacientes pueden preferir decisiones más lentas y claras cuando el producto solicita información médica de toda una vida.
Esta es la principal disyuntiva. La fricción puede obstaculizar el acceso de los pacientes, pero eliminar toda fricción puede convertir el consentimiento en una transferencia de poder casi invisible.
El proceso plantea preguntas sobre la captura por la industria
La crítica más sólida se refiere a quién ayudó a configurar las reglas, no a si CMS debería colaborar con empresas privadas de tecnología.
Las agencias federales de salud no pueden diseñar una infraestructura moderna de datos sin experiencia externa. Los proveedores tecnológicos entienden sistemas que los funcionarios gubernamentales quizá nunca construyan por sí mismos.
Las organizaciones sanitarias también dependen de software privado, servicios en la nube, proveedores de identidad y proveedores de historiales médicos electrónicos. Excluir a las empresas produciría una política técnica más débil.
El problema comienza cuando la consulta se vuelve estructuralmente desequilibrada. Un foro dominado por proveedores puede definir las necesidades de los pacientes mediante supuestos comerciales.
Por ejemplo, las empresas pueden considerar que el acceso más rápido a los historiales es la principal medida del control del paciente. En cambio, un defensor de pacientes podría centrarse en la revocación, el uso secundario, la accesibilidad o la protección frente a la manipulación.
Un médico puede preguntar cómo gestiona un asistente de IA los síntomas ambiguos. Un proveedor puede poner el énfasis en si el asistente puede recuperar suficientes datos para ofrecer una respuesta personalizada.
Ambas perspectivas son pertinentes. No son intercambiables.
Joseph Daval, exabogado de la FDA y especialista en investigación de Harvard Medical School, revisó mensajes de Slack para la investigación. Dijo que el grupo se parecía en algunos aspectos a un comité asesor federal.
Los comités asesores federales suelen operar bajo requisitos diseñados para respaldar la visibilidad pública, la participación independiente y una membresía equilibrada. Sigue sin resolverse si este Slack cumplía legalmente esa definición.
Según informes, el código de conducta de CMS señalaba que el espacio de trabajo no constituía un comité asesor. También advertía a los empleados federales que no respaldaran productos o empresas específicos.
Estas salvaguardas muestran que los funcionarios reconocían el límite. Las conversaciones reportadas plantean dudas sobre si la práctica real se mantuvo cómodamente dentro de él.
Una reunión reportada involucró a un funcionario que describía Medicare.gov como una fuente de confianza para los beneficiarios respecto de las aplicaciones incluidas. Otras grabaciones supuestamente vincularon las aplicaciones destacadas con oportunidades de pago.
Un empleado del gobierno puede explicar un programa sin respaldar un producto. Sin embargo, prometer distribución o describir una iniciativa como un motor comercial se acerca a una línea sensible.
CMS no respondió varias preguntas detalladas de los reporteros, entre ellas cómo seleccionó las aplicaciones para la biblioteca. Tampoco explicó plenamente por qué los funcionarios hablaron de promocionar productos.
La agencia afirmó que el ecosistema es abierto y voluntario. Destacó la colaboración con pacientes, proveedores, pagadores, organizaciones tecnológicas y otras partes interesadas.
La apertura no puede medirse únicamente por la cantidad total de miembros. También depende de las prácticas de invitación, el acceso a las reuniones, los registros de decisiones, las oportunidades para intervenir y la manera en que las opiniones contrapuestas afectan la política final.
Un canal de 1.700 miembros puede seguir siendo limitado si la mayoría de los participantes activos comparten intereses financieros similares. Una membresía amplia incluso puede ocultar quién configuró las decisiones decisivas.
La transparencia no exigiría publicar cada mensaje informal. Las agencias necesitan conversaciones de trabajo, y las empresas a veces comparten detalles técnicos confidenciales.
CMS aún puede publicar calendarios de reuniones, listas de participantes, agendas escritas, resúmenes de decisiones, declaraciones de conflicto de intereses y explicaciones de cambios sustanciales en las políticas.
También puede crear un consejo de pacientes y médicos con una representación significativa. Ese grupo debería revisar el lenguaje de privacidad, los flujos de consentimiento, las descripciones de aplicaciones y las métricas de resultados antes de que lleguen a los beneficiarios.
Las pruebas independientes son igualmente importantes. La acreditación de seguridad no puede establecer la precisión clínica, el beneficio para la salud, la facilidad de uso ni el acceso equitativo.
Un asistente de IA puede cumplir requisitos técnicos y, aun así, ofrecer orientaciones inconsistentes. Una aplicación para la diabetes puede proteger los datos mientras produce resultados débiles para usuarios con necesidades médicas complejas.
La marca Medicare puede condensar estas distinciones en una única impresión de confianza. CMS debe impedir que una inclusión en el directorio se convierta en una recomendación clínica implícita.
Tres señales mostrarán si CMS puede restablecer el equilibrio
La siguiente etapa debería evaluarse mediante un proceso público, resultados medibles para los pacientes y protecciones de datos exigibles.
La primera señal es cómo explica CMS la selección de aplicaciones. La agencia debería publicar estándares claros de inclusión, eliminación, clasificación y designaciones especiales en la Biblioteca de Aplicaciones de Medicare.
Esos estándares deberían distinguir la elegibilidad técnica de la evidencia clínica. Cada ficha debería indicar a los usuarios qué revisó CMS y qué no revisó.
CMS también debería revelar si las empresas incluidas participaron en reuniones privadas sobre las reglas. La participación no las descalificaría automáticamente, pero la transparencia expondría posibles ventajas.
Si CMS publica registros detallados de selección, la medida reforzaría su afirmación de que el programa sigue siendo abierto. La ambigüedad continuada reforzaría las preocupaciones sobre el acceso privilegiado.
La segunda señal es cómo ACCESS informa los resultados. Las tasas de éxito agregadas no serán suficientes.
CMS debería mostrar retención, eventos adversos, quejas de pacientes y resultados por grupos demográficos y clínicos. También debería explicar cómo los participantes definen a los pacientes elegibles y miden la mejora.
La evaluación independiente debería comparar la atención respaldada por tecnología con alternativas creíbles. De lo contrario, un proveedor puede obtener resultados favorables de pacientes que ya tenían probabilidades de mejorar.
El programa también debe identificar quién asume la responsabilidad clínica. Los pacientes necesitan una vía clara de escalamiento cuando la orientación automatizada entra en conflicto con la atención profesional o no detecta una afección grave.
Una evaluación sólida respaldaría el argumento de que ACCESS recompensa una mejor atención. Una información débil sugeriría que el reembolso avanzó más rápido que la evidencia.
La tercera señal es si los controles de privacidad siguen siendo comprensibles después de que los historiales médicos salen de los sistemas sanitarios tradicionales. CMS debería exigir divulgaciones específicas antes de que una aplicación recupere datos.
Los usuarios deberían poder ver si un producto utiliza los historiales para entrenamiento de modelos, desarrollo de productos, marketing o investigación. También deberían recibir herramientas directas para revocar el acceso y solicitar la eliminación.
Los registros de auditoría deberían llegar a los pacientes, no solo a los administradores de red. Una persona debería poder ver qué servicio abrió un historial y qué información recibió.
Las filtraciones y divulgaciones no autorizadas pondrán a prueba estas salvaguardas. Las medidas de cumplimiento, la retirada de aplicaciones o los avisos tardíos dejarían al descubierto las brechas entre los requisitos escritos y la protección real.
La promesa más amplia sigue siendo valiosa. Los pacientes no deberían necesitar máquinas de fax, formularios repetidos ni depender únicamente de la memoria para gestionar sus historiales médicos.
Las aplicaciones de IA pueden ayudar a las personas a preparar preguntas, controlar enfermedades crónicas y orientarse en un sistema sanitario intimidante. Esos beneficios justifican una experimentación cuidadosa.
No justifican permitir que los proveedores definan el experimento en gran medida entre ellos mismos. Una innovación más rápida no puede sustituir una participación equilibrada, el razonamiento público y la evidencia independiente.
Para desarrolladores y compradores empresariales, la lección va más allá de Medicare. El acceso a datos sensibles conlleva obligaciones de gobernanza que los equipos de producto no pueden relegar a las divulgaciones legales.
Los equipos necesitan registros duraderos de debates sobre políticas, decisiones de riesgo, requisitos técnicos y comentarios de los usuarios. Una base de conocimientos de IA con capacidad de búsqueda puede ayudar a preservar ese contexto institucional, pero la documentación es solo el comienzo.
La historia de Slack sobre tecnología sanitaria de CMS tiene ahora una prueba sencilla. ¿Hará CMS que el sistema sea tan transparente para los pacientes como lo ha sido accesible para las empresas participantes?
Siga las divulgaciones sobre la selección de la biblioteca, los datos de resultados de ACCESS y los controles de privacidad vinculados a las transferencias de historiales. En conjunto, estas señales mostrarán si esto se convierte en una infraestructura centrada en el paciente o en un canal de distribución para IA sanitaria respaldado por el gobierno.
