Firmar un contrato para una herramienta de IA puede parecer la línea de meta de un proceso de adquisición, pero para los gestores de centros de atención primaria es, en realidad, el punto de partida. Una vez firmado el contrato y desplegada la herramienta, las obligaciones clínicas, legales y regulatorias asociadas a ese despliegue recaen firmemente sobre el centro, no sobre el proveedor. El despliegue de IA está superando la evaluación rigurosa en el mundo real y la regulación de formas que crean un riesgo genuino para los centros que no han realizado una diligencia debida exhaustiva. Esta guía establece las preguntas específicas que los gestores de centros deben formular y los documentos que deben revisar antes de firmar cualquier contrato.

¿Está la herramienta clasificada como dispositivo médico y qué significa eso para ti?

No todas las herramientas de IA utilizadas en un entorno clínico son dispositivos médicos, pero muchas sí lo son. La distinción tiene un peso regulatorio significativo. En el Reino Unido, la Agencia Reguladora de Medicamentos y Productos Sanitarios (MHRA) clasifica el software como dispositivo médico. Si una herramienta de IA apoya el diagnóstico clínico, las decisiones de triaje o las recomendaciones de tratamiento, es probable que se incluya en la definición de Software como Dispositivo Médico (SaMD) y requiera el marcado UKCA o CE según el Medical Device Regulation (MDR).

Antes de firmar, los gestores de centros deben:

• Buscar en la Base de Datos de Productos y Registro de la MHRA (PARD) para confirmar si la herramienta está registrada como dispositivo médico

• Preguntar directamente al proveedor sobre su estado de registro en la MHRA y la clase de dispositivo

• Comprobar si la herramienta cuenta con una evaluación NICE, un Informe de Innovación Medtech (MIB), Guía de Diagnóstico (DG) o Evaluación de Valor Temprano (EVA)

• Confirmar si la herramienta tiene un marcado UKCA o CE válido si está clasificada como dispositivo médico

El GP Mythbuster 109 de la CQC sobre IA, publicado en julio de 2025, deja claro que los inspectores comprobarán si los centros han verificado el registro en la MHRA cuando sea aplicable y si la adquisición se realizó conforme a los estándares DCB0160 y Criterios de Evaluación de Tecnología Digital (DTAC). Las herramientas que no están clasificadas como dispositivos médicos no están exentas de escrutinio. Siguen teniendo obligaciones de protección de datos, seguridad clínica y gobernanza.

¿Quién tiene la responsabilidad clínica y legal si algo sale mal?

Esta es una de las preguntas más importantes en cualquier contrato de herramienta de IA. Los acuerdos con proveedores frecuentemente la oscurecen. La posición general en atención primaria del NHS es que las organizaciones del NHS pueden seguir siendo responsables de reclamaciones relacionadas con IA incluso cuando utilizan herramientas de terceros. La responsabilidad por usar una solución de IA no conforme recae en la organización que la despliega o en el profesional sanitario individual.

Los proveedores suelen limitar su responsabilidad a que el software funcione según lo descrito en el contrato. No aceptan responsabilidad por decisiones clínicas tomadas sobre la base de resultados de IA. Esto significa que si una historia clínica generada por IA contiene un error que influye en la atención al paciente, el centro, no el proveedor, probablemente asumirá las consecuencias clínicas y legales.

Al revisar los términos del contrato, los gestores de centros deben buscar:

• Declaraciones claras sobre dónde recae la responsabilidad clínica y si el proveedor acepta alguna responsabilidad por los resultados generados por IA que se incorporan a la historia del paciente

• Cláusulas de indemnización y si la indemnización del proveedor cubre incidentes clínicos o se limita a fallos de rendimiento del software

• Si los términos del proveedor exigen que el centro mantenga supervisión humana de todos los resultados de IA y qué documentación de esa supervisión se espera

• Si se ha consultado a la organización de defensa médica o proveedor de indemnización del centro sobre el uso de la herramienta

Surrey & Sussex LMCs aconsejan a los centros que involucren a su Junta de Atención Integrada (ICB) para obtener garantías y asegurar que todos los resultados generados por IA sean verificados por un profesional sanitario antes de incorporarlos a la historia del paciente. Este requisito de supervisión humana no es simplemente una buena práctica, sino una condición para un despliegue seguro según la orientación actual del NHS.

¿Dónde se procesan y almacenan los datos de los pacientes?

La residencia de los datos es una cuestión fundamental en cualquier adquisición de IA clínica. Las respuestas de los proveedores no siempre son claras. Según el Reglamento General de Protección de Datos del Reino Unido y el deber de confidencialidad del derecho común, los datos de los pacientes son datos de categoría especial y su procesamiento debe ser legal, transparente y proporcionado. Si los datos de los pacientes, incluidas las grabaciones de audio de las consultas, se transfieren fuera del Reino Unido o la UE para su procesamiento o almacenamiento, se requieren salvaguardas adicionales.

La orientación de NHS England sobre productos de transcripción ambiental confirma que es muy probable que una Evaluación de Impacto en la Protección de Datos (DPIA) sea un requisito legal antes del despliegue, dado el procesamiento a gran escala de datos de salud de categoría especial involucrado. La orientación de gobernanza de información del NHS Transformation Directorate refuerza esto. Las DPIA deben abordar los tipos de datos que se procesan (incluidos audio y transcripciones), la reutilización de datos por parte del proveedor para entrenamiento de modelos de IA y las obligaciones de transparencia con los pacientes.

Preguntas clave para hacer a los proveedores antes de firmar:

• ¿Dónde se procesan los datos de los pacientes? ¿En el Reino Unido, la UE o en un tercer país?

• ¿Quiénes son los subprocesadores del proveedor y dónde están ubicados?

• ¿Utiliza el proveedor datos de consultas de pacientes para entrenar o mejorar sus modelos de IA y, de ser así, sobre qué base legal?

• ¿Se incluye un Acuerdo de Procesamiento de Datos (DPA) en el contrato y cumple con el Artículo 28 del RGPD del Reino Unido?

• ¿Cuál es la distinción entre datos anonimizados y seudonimizados en el procesamiento del proveedor y cuál es el riesgo residual de reidentificación?

El comentario legal de Spencer West LLP señala que la distinción entre datos anonimizados y seudonimizados es especialmente importante en este contexto. Los datos seudonimizados conservan un riesgo residual de reidentificación y no pueden tratarse como fuera del alcance de la ley de protección de datos.

¿Qué certificaciones de seguridad debe tener el proveedor?

Las certificaciones de seguridad no son una garantía absoluta, pero su ausencia es una señal significativa sobre la madurez e inversión del proveedor en protección de datos. Para herramientas de IA clínica utilizadas en atención primaria del NHS, existe una base mínima de certificaciones y evaluaciones que un proveedor creíble debería poder demostrar.

Los centros deben esperar que los proveedores tengan o estén trabajando activamente para obtener:

• ISO 27001, el estándar internacional para sistemas de gestión de seguridad de la información

• Cumplimiento del NHS Data Security and Protection (DSP) Toolkit, el marco propio del NHS para evaluar la seguridad de datos, que es un requisito contractual para organizaciones que acceden a datos de pacientes del NHS

• Cyber Essentials o Cyber Essentials Plus, la certificación de ciberseguridad básica del gobierno del Reino Unido

• Cumplimiento DTAC, el marco de NHS England que cubre protección de datos, seguridad técnica, interoperabilidad y seguridad clínica

La guía de adquisición de iatroX para compradores del NHS recomienda que los centros se aseguren de que un proveedor tenga un paquete DTAC aprobado antes del despliegue. La orientación de NHS England sobre transcripción ambiental también señala riesgos de ciberseguridad específicos de los modelos de lenguaje grandes (LLM), incluido el potencial de ataques de inyección de prompts y filtración de datos a través de los resultados del modelo.

Un proveedor que no pueda aportar evidencia de estas certificaciones o que no pueda proporcionar una presentación actual del DSP Toolkit debe tratarse con cautela, independientemente de cuán convincente sea su demostración del producto.

¿Cómo se integra la herramienta con tu sistema de historias clínicas existente?

La mayoría de los centros de atención primaria en Inglaterra utilizan EMIS Web o SystmOne como su sistema principal de historias clínicas. El valor práctico de una herramienta de IA, especialmente un escriba médico de IA o asistente de documentación, depende en gran medida de qué tan bien se integra con el sistema existente del centro. La integración que requiere copiar y pegar manualmente el contenido generado por IA en la historia clínica aumenta significativamente el riesgo de errores de transcripción y elimina gran parte del beneficio de eficiencia.

Antes de firmar, los gestores de centros deben establecer:

• Si la herramienta cuenta con una integración nativa y certificada con EMIS Web o SystmOne, o si depende de una solución alternativa

• Quién es responsable de mantener la integración cuando el proveedor del sistema de historias clínicas publica actualizaciones: el proveedor de IA, el proveedor del sistema o el propio centro

• Si la integración se ha probado en un entorno de atención primaria real, no solo en un entorno de desarrollo o atención especializada

• Cuál es el proceso de respaldo si la integración falla durante una sesión clínica

La guía de iatroX sobre herramientas de IA para centros de atención primaria del Reino Unido destaca la integración con el sistema de historias clínicas como uno de los criterios principales de evaluación para escribas médicos de IA. Las decisiones de adquisición deben tener en cuenta el coste total de propiedad, incluido el ajuste de flujo de trabajo requerido cuando la integración es imperfecta. Los fallos de integración no son solo un inconveniente técnico. En un entorno clínico, pueden crear lagunas en la historia del paciente o introducir errores que tienen implicaciones para la seguridad del paciente.

¿Qué sucede con tus datos si finalizas el contrato?

La portabilidad y eliminación de datos al finalizar el contrato son áreas donde los contratos de proveedores suelen ser vagos. Los centros pueden encontrarse en una posición difícil si no han negociado términos claros por adelantado. Las preguntas a resolver antes de firmar son:

• ¿Cuánto tiempo retiene el proveedor los datos de los pacientes después de la terminación del contrato y sobre qué base legal?

• ¿Puede el centro exportar una copia completa de todos los datos de pacientes en poder del proveedor antes de la terminación?

• ¿Qué significa realmente "eliminación bajo solicitud"? ¿Cubre todas las copias, incluidas las copias de seguridad y los datos de subprocesadores?

• ¿Cuál es el cronograma para la eliminación confirmada y proporcionará el proveedor confirmación por escrito?

Según el RGPD del Reino Unido, los interesados tienen derechos que incluyen el derecho al borrado. El centro, como responsable del tratamiento de datos, es responsable de garantizar que esos derechos puedan ejercerse incluso después de que finalice una relación con un proveedor. La privacidad y seguridad a lo largo del ciclo de vida de los datos de salud es un área de creciente escrutinio regulatorio. Los centros que no pueden dar cuenta de dónde fueron los datos de los pacientes después de que finalizó un contrato con un proveedor pueden enfrentar problemas de cumplimiento.

Los términos del contrato que permiten a los proveedores retener datos durante períodos prolongados después de la terminación para fines de "mejora del producto" o "entrenamiento de modelos" deben señalarse para revisión legal antes de firmar.

¿Está la herramienta de IA entrenada con datos clínicos del NHS o equivalentes?

Los datos de entrenamiento utilizados para desarrollar una herramienta de IA tienen una relación directa con su precisión clínica en un contexto de atención primaria del Reino Unido. Una herramienta entrenada predominantemente con datos clínicos de EE. UU., por ejemplo, puede tener un rendimiento deficiente en codificación clínica específica del Reino Unido (SNOMED CT como se usa en el NHS), nombres de medicamentos y convenciones de dosificación, vías de derivación o el estilo particular de documentación de consultas de atención primaria.

Las perspectivas de los profesionales sanitarios sobre la IA en atención primaria plantean de forma recurrente preocupaciones sobre sesgos introducidos a través de datos de entrenamiento. Laranjo et al. en Lancet Primary Care han señalado que el despliegue rápido antes de una evaluación robusta plantea preocupaciones sobre consecuencias no deseadas en la calidad de la atención. Estos no son riesgos abstractos: se traducen directamente en la precisión de las historias clínicas, la idoneidad de los códigos clínicos sugeridos y la fiabilidad de cualquier resultado de soporte a la decisión.

Al evaluar las afirmaciones sobre los datos de entrenamiento de un proveedor, los gestores de centros deben preguntar:

• ¿Se entrenó el modelo con datos del NHS o de atención primaria del Reino Unido y puede el proveedor proporcionar documentación de ello?

• ¿Se ha validado el modelo específicamente con datos de consultas de atención primaria del Reino Unido?

• ¿Publica el proveedor una tarjeta de modelo o documentación técnica equivalente que describa las fuentes de datos de entrenamiento, limitaciones conocidas y puntos de referencia de rendimiento?

• ¿Cómo maneja el modelo la terminología clínica específica del Reino Unido, nombres de medicamentos y convenciones de derivación?

Los proveedores deben poder responder estas preguntas con evidencia documentada, no solo con afirmaciones de marketing. Cuando un proveedor no puede proporcionar esta información, existe una brecha significativa en su base de evidencia clínica.

¿Quién en el centro es responsable de supervisar la herramienta?

La gobernanza de herramientas de IA no es una decisión de adquisición puntual. Es una responsabilidad operativa continua. El GP Mythbuster 109 de la CQC establece lo que los inspectores buscarán, incluido el nombramiento de un Oficial de Seguridad Clínica (CSO), el mantenimiento de una evaluación de riesgos y registro de peligros, y evidencia de que la supervisión humana de los resultados de IA está integrada en los flujos de trabajo del centro.

El requisito de nombrar un CSO a nivel de centro es uno que Surrey & Sussex LMCs reconocen como un desafío práctico para centros más pequeños. Es una expectativa regulatoria, no una mejora opcional. El CSO no necesita ser un rol a tiempo completo, pero el centro debe poder identificar a una persona nombrada que tenga esta responsabilidad y pueda demostrar que la está cumpliendo.

La documentación de gobernanza que el centro debe mantener incluye:

• Un caso de seguridad clínica DCB0160 completado para el despliegue de la herramienta

• Una evaluación de riesgos y registro de peligros, revisados regularmente y actualizados cuando la herramienta cambia

• Registros de capacitación de profesionales sanitarios sobre la herramienta, incluida la concienciación sobre sus limitaciones

• Un registro de cualquier incidente o casi incidente que involucre resultados generados por IA

• Evidencia de que todo el contenido generado por IA que se incorpora a la historia del paciente ha sido revisado por un profesional sanitario

Esta documentación no solo es relevante para la inspección de la CQC. Es la base de evidencia que protege al centro si ocurre un incidente clínico y se plantean preguntas sobre cómo se desplegó y supervisó la herramienta.

¿Cómo es el soporte y la respuesta a incidentes del proveedor?

Un Acuerdo de Nivel de Servicio (SLA) es un componente estándar de cualquier contrato de software, pero para herramientas de IA clínica las consecuencias de un fallo de soporte son mayores que para la mayoría del software. Si un escriba médico de IA falla a mitad de una consulta, o si una historia clínica generada por IA contiene un error sistemático que no se detecta de inmediato, el centro necesita saber que el proveedor responderá rápidamente y con comprensión clínica.

Antes de firmar, los gestores de centros deben revisar:

• Tiempos de respuesta y resolución en el SLA y si estos diferencian entre incidentes de seguridad clínica y problemas técnicos generales

• Si el proveedor tiene un contacto asignado para centros de atención primaria o si el soporte se gestiona a través de un servicio de ayuda genérico

• Cuál es el proceso del proveedor para notificar a los centros sobre un incidente de seguridad clínica, incluida la rapidez con la que comunicarán y qué información proporcionarán

• Si el proveedor tiene un proceso documentado de reporte de incidentes de seguridad clínica que cumpla con los estándares del NHS

La orientación de NHS England sobre productos de transcripción ambiental exige que los acuerdos contractuales definan claramente roles, responsabilidades y rendición de cuentas, incluida la respuesta a incidentes. Un proveedor que no puede articular un proceso claro de incidentes de seguridad clínica no está listo para el despliegue en un entorno de atención primaria.

¿Se ha evaluado la herramienta en un entorno real de atención primaria?

Esta es una pregunta con la que muchos proveedores tienen dificultades para responder con evidencia sólida. La brecha entre una demostración convincente y una evaluación revisada por pares en un entorno de atención primaria real es significativa. La investigación sobre escribas médicos de IA en atención primaria ha comenzado a documentar experiencias de proveedores y preocupaciones éticas en entornos del mundo real, pero la base de evidencia sigue siendo limitada y en gran medida exploratoria.

La revisión de Frontiers in Health Services de los marcos de adquisición de IA del NHS recomienda que la documentación de cumplimiento del proveedor incluya evidencia clínica, no solo certificaciones técnicas. Los gestores de centros deben pedir a los proveedores que proporcionen:

• Estudios publicados revisados por pares o resultados de pilotos documentados en entornos de atención primaria

• Estudios de caso de entornos de atención primaria del Reino Unido con resultados medibles (tiempo de documentación, precisión clínica, satisfacción del profesional sanitario)

• Evidencia de evaluación frente a flujos de trabajo específicos del NHS y sistemas de historias clínicas

• Cualquier limitación conocida o modo de fallo identificado durante las pruebas en el mundo real

La evidencia de atención especializada o de entornos de atención primaria internacionales no se transfiere directamente a la práctica general del Reino Unido. Las estructuras de consulta, convenciones de documentación y requisitos regulatorios difieren materialmente. Una herramienta que funciona bien en un entorno ambulatorio hospitalario o en un contexto de atención primaria de EE. UU. puede no funcionar de manera equivalente en un centro de atención primaria del Reino Unido.

También hay una brecha de evidencia más amplia que reconocer. Como Laranjo et al. en Lancet señalan, el despliegue de IA en atención primaria está actualmente superando la evaluación robusta necesaria para comprender su impacto en el mundo real. Esto no significa que los centros deban evitar las herramientas de IA, pero las afirmaciones de los proveedores deben examinarse cuidadosamente y el monitoreo posterior al despliegue es esencial.

Una lista de verificación previa a la firma para gestores de centros de atención primaria

La siguiente lista de verificación consolida los puntos clave tratados en este artículo. Úsala como referencia práctica antes de firmar cualquier contrato de herramienta de IA.

Seguridad regulatoria y clínica

• [ ] Estado de registro en MHRA confirmado y clase de dispositivo (buscar en PARD si es aplicable)

• [ ] El proveedor tiene documentación de caso de seguridad clínica DCB0129

• [ ] El centro ha completado o iniciado el caso de seguridad clínica DCB0160 para el despliegue

• [ ] Evaluación DTAC completada y aprobada por el proveedor

• [ ] Evaluación NICE verificada (MIB, DG o EVA) si es aplicable

Protección de datos y gobernanza de la información

• [ ] DPIA completada antes del despliegue

• [ ] Acuerdo de Procesamiento de Datos incluido en el contrato, cumple con el Artículo 28 del RGPD del Reino Unido

• [ ] Residencia de datos confirmada: procesamiento y almacenamiento en Reino Unido o UE

• [ ] Subprocesadores identificados y evaluados

• [ ] Política del proveedor sobre el uso de datos de pacientes para entrenamiento de modelos revisada y acordada

• [ ] Términos de eliminación y portabilidad de datos confirmados al finalizar el contrato

Seguridad

• [ ] Certificación ISO 27001 confirmada

• [ ] Cumplimiento del NHS DSP Toolkit confirmado

• [ ] Cyber Essentials o Cyber Essentials Plus confirmado

• [ ] Sección de ciberseguridad DTAC aprobada

Responsabilidad y contratación

• [ ] Asignación de responsabilidad claramente definida en el contrato

• [ ] Cláusulas de indemnización revisadas: alcance confirmado

• [ ] Organización de defensa médica o proveedor de indemnización consultado

• [ ] Roles, responsabilidades y respuesta a incidentes definidos en el contrato

Integración del sistema de historias clínicas

• [ ] Integración nativa con EMIS Web o SystmOne confirmada

• [ ] Responsabilidad de mantenimiento de integración definida

• [ ] Probada en entorno de atención primaria del Reino Unido en vivo

Gobernanza

• [ ] Oficial de Seguridad Clínica nombrado a nivel de centro

• [ ] Evaluación de riesgos y registro de peligros iniciado

• [ ] Plan de capacitación de profesionales sanitarios en marcha

• [ ] Revisión humana de todos los resultados de IA confirmada como requisito de flujo de trabajo

Evidencia y soporte

• [ ] Evidencia clínica de entornos de atención primaria del Reino Unido revisada

• [ ] SLA revisado: tiempos de respuesta a incidentes de seguridad clínica confirmados

• [ ] Contacto asignado del proveedor para centros de atención primaria confirmado

• [ ] Origen de datos de entrenamiento documentado por el proveedor

Firmar con confianza, no solo con rapidez

La adquisición de IA en atención primaria es una decisión de gobernanza clínica tanto como operativa. Las herramientas disponibles en 2025 y 2026 ofrecen un potencial genuino para reducir la carga de documentación y apoyar a los profesionales sanitarios, pero ese potencial solo se realiza de manera segura cuando el centro ha verificado el cumplimiento regulatorio, las obligaciones de protección de datos, la asignación de responsabilidades y la evidencia clínica antes de que comience el despliegue.

El informe de Digital Health sobre adquisición de IA del NHS resume claramente la realidad regulatoria actual: los estándares existentes no fueron diseñados para sistemas de IA de aprendizaje. El ritmo de actividad de los proveedores en atención primaria significa que los centros necesitan ser, en palabras del Director Nacional de Información Clínica de NHS England, "rigurosos al asegurar que lo que estamos haciendo es seguro, garantizado y va a ofrecer beneficios".

Las preguntas y verificaciones de este artículo no son obstáculos para la adopción. Son la base sobre la cual se construye una adopción segura, efectiva y defendible. Un proveedor que no puede responderlas claramente y con evidencia documentada no está listo para ser desplegado en un entorno clínico. Un centro que no las ha formulado está asumiendo un riesgo del que puede que aún no sea consciente.

Preguntas frecuentes

¿Necesita una herramienta de IA utilizada en un centro de atención primaria estar registrada como dispositivo médico?

Depende de lo que haga la herramienta. Si apoya el diagnóstico clínico, las decisiones de triaje o las recomendaciones de tratamiento, es probable que sea clasificada como Software como Dispositivo Médico por la Agencia Reguladora de Medicamentos y Productos Sanitarios y requiera el marcado UKCA o CE según el Medical Device Regulation. Los gestores de centros deben buscar en la Base de Datos de Productos y Registro de la MHRA para confirmar el estado de registro de una herramienta antes de firmar cualquier contrato. Las herramientas que no están clasificadas como dispositivos médicos igualmente tienen obligaciones de protección de datos, seguridad clínica y gobernanza.

¿Quién es responsable si una historia clínica generada por IA contiene un error que afecta la atención al paciente?

En atención primaria del NHS, la responsabilidad por incidentes clínicos relacionados con IA suele recaer en la organización que la despliega o en el profesional sanitario individual, no en el proveedor. Los proveedores generalmente limitan su responsabilidad a que el software funcione según lo descrito en el contrato y no aceptan responsabilidad por decisiones clínicas tomadas sobre la base de resultados de IA. Los gestores de centros deben revisar cuidadosamente las cláusulas de indemnización, confirmar si se ha consultado a su organización de defensa médica y asegurar que todo el contenido generado por IA sea revisado por un profesional sanitario antes de incorporarlo a la historia del paciente.

¿Dónde deben procesarse y almacenarse los datos de los pacientes al usar una herramienta de IA clínica?

Los datos de los pacientes son datos de categoría especial según el Reglamento General de Protección de Datos del Reino Unido y deben procesarse de manera legal, transparente y proporcionada. Si los datos se transfieren fuera del Reino Unido o la UE, se requieren salvaguardas adicionales. Antes de firmar, los centros deben confirmar dónde procesa y almacena datos el proveedor, quiénes son sus subprocesadores y si se incluye un Acuerdo de Procesamiento de Datos que cumpla con el Artículo 28 del RGPD del Reino Unido en el contrato. NHS England confirma que es muy probable que una Evaluación de Impacto en la Protección de Datos sea un requisito legal antes del despliegue.

¿Qué certificaciones de seguridad debe tener un proveedor de IA clínica?

Los proveedores creíbles deben tener o estar trabajando activamente para obtener ISO 27001 (el estándar internacional para gestión de seguridad de la información), cumplimiento del NHS Data Security and Protection Toolkit, Cyber Essentials o Cyber Essentials Plus, y cumplimiento de los Criterios de Evaluación de Tecnología Digital. El NHS DSP Toolkit es un requisito contractual para organizaciones que acceden a datos de pacientes del NHS. Un proveedor que no pueda aportar evidencia de estas certificaciones o que no pueda proporcionar una presentación actual del DSP Toolkit debe tratarse con cautela.

¿Qué sucede con los datos de los pacientes si un centro finaliza su contrato con un proveedor de IA?

Esta es un área donde los contratos de proveedores suelen ser vagos. Los centros deben confirmar antes de firmar cuánto tiempo retiene el proveedor los datos de los pacientes después de la terminación, si es posible una exportación completa de todos los datos de pacientes y qué cubre "eliminación bajo solicitud" en la práctica, incluidas las copias de seguridad y los datos de subprocesadores. Según el RGPD del Reino Unido, el centro como responsable del tratamiento de datos es responsable de garantizar que los derechos de los pacientes, incluido el derecho al borrado, puedan ejercerse incluso después de que finalice una relación con un proveedor. Los términos del contrato que permiten a los proveedores retener datos para entrenamiento de modelos tras la terminación deben señalarse para revisión legal.

¿Importa si una herramienta de IA fue entrenada con datos del NHS o de atención primaria del Reino Unido?

Sí. Los datos de entrenamiento tienen una relación directa con la precisión clínica en un contexto de atención primaria del Reino Unido. Una herramienta entrenada predominantemente con datos clínicos de EE. UU. puede tener un rendimiento deficiente en codificación clínica específica del NHS usando SNOMED CT, nombres de medicamentos y convenciones de dosificación del Reino Unido, vías de derivación y estilos de documentación de consultas de atención primaria. Los centros deben preguntar a los proveedores si el modelo fue entrenado y validado con datos de consultas de atención primaria del Reino Unido y si el proveedor publica una tarjeta de modelo que describa las fuentes de datos de entrenamiento, limitaciones conocidas y puntos de referencia de rendimiento. Las afirmaciones de marketing no sustituyen la evidencia documentada.

¿Quién en el centro es responsable de supervisar una herramienta de IA una vez desplegada?

El GP Mythbuster 109 de la Care Quality Commission sobre inteligencia artificial establece que los centros deben nombrar a un Oficial de Seguridad Clínica, mantener una evaluación de riesgos y registro de peligros, e integrar la supervisión humana de los resultados de IA en los flujos de trabajo clínicos. Esta es una expectativa regulatoria, no un paso opcional. Los centros también deben mantener un caso de seguridad clínica DCB0160 completado, registros de capacitación de profesionales sanitarios y un registro de cualquier incidente que involucre resultados generados por IA. Esta documentación protege al centro si ocurre un incidente clínico y se plantean preguntas sobre cómo se desplegó la herramienta.

¿Cómo debe evaluar un centro si una herramienta de IA se integra correctamente con su sistema de historias clínicas?

La mayoría de los centros de atención primaria en Inglaterra utilizan EMIS Web o SystmOne. Los centros deben confirmar si la herramienta cuenta con una integración nativa y certificada con su sistema en lugar de una solución alternativa, quién es responsable de mantener esa integración cuando el proveedor del sistema de historias clínicas publica actualizaciones y si la integración se ha probado en un entorno de atención primaria real. La integración que requiere copiar y pegar manualmente el contenido generado por IA en la historia clínica aumenta el riesgo de errores de transcripción y elimina gran parte del beneficio de eficiencia. Los fallos de integración pueden crear lagunas en la historia del paciente con implicaciones directas para la seguridad del paciente.

¿Qué evidencia clínica debe poder proporcionar un proveedor antes de que un centro firme un contrato?

Los proveedores deben aportar estudios publicados revisados por pares o resultados de pilotos documentados en entornos de atención primaria, estudios de caso de entornos de atención primaria del Reino Unido con resultados medibles y evidencia de evaluación frente a flujos de trabajo específicos del NHS y sistemas de historias clínicas. La evidencia de atención especializada o de entornos de atención primaria internacionales no se transfiere directamente a la práctica general del Reino Unido. Como investigadores que escriben en Lancet han señalado, el despliegue de IA en atención primaria está actualmente superando la evaluación robusta, lo que significa que las afirmaciones de los proveedores deben examinarse cuidadosamente y el monitoreo posterior al despliegue es esencial.

¿Qué debe buscar un centro en los acuerdos de soporte y respuesta a incidentes de un proveedor?

El Acuerdo de Nivel de Servicio debe diferenciar los tiempos de respuesta y resolución entre incidentes de seguridad clínica y problemas técnicos generales. Los centros deben confirmar si el proveedor tiene un contacto asignado para centros de atención primaria o gestiona el soporte a través de un servicio de ayuda genérico, y si el proveedor tiene un proceso documentado de reporte de incidentes de seguridad clínica que cumpla con los estándares del NHS. La orientación de NHS England sobre productos de transcripción ambiental exige que los acuerdos contractuales definan claramente roles, responsabilidades y rendición de cuentas, incluida la respuesta a incidentes. Un proveedor que no puede articular un proceso claro de incidentes de seguridad clínica no está listo para el despliegue en un entorno de atención primaria.