Cuándo se considera producto sanitario un software de salud

Para un equipo que desarrolla software de salud, la respuesta a esta pregunta cambia el plazo y el coste del proyecto. El mismo código puede llevar una carga de cumplimiento muy distinta según cómo se defina el producto.

Imagine dos aplicaciones. Ambas toman los síntomas introducidos por el usuario, ejecutan un algoritmo y devuelven una lista. El código es casi idéntico. Una está sujeta a la normativa sobre productos sanitarios, la otra no.

Lo que marca la diferencia es el texto descriptivo en la tienda de aplicaciones. La primera dice "informa sobre posibles afecciones según sus síntomas". La segunda dice "evalúa sus síntomas y muestra el diagnóstico probable". Esta segunda frase convierte el producto en uno presentado con fines de diagnóstico, y con ello entran en juego la clasificación de riesgo, la evaluación de la conformidad, el expediente técnico, la evaluación clínica y las obligaciones de vigilancia poscomercialización.

Este es el error más caro y más fácilmente evitable que he visto en proyectos de tecnología sanitaria. La descripción del producto la redacta el equipo de marketing, nadie piensa en su consecuencia jurídica, y el producto entra en un régimen de conformidad que nunca se pretendió asumir.

La finalidad de uso es un texto jurídico

La regla práctica que se deriva de esto es la siguiente. La descripción del producto debe redactarse con el mismo cuidado que una política de privacidad, y pasar por una revisión jurídica antes de publicarse.

Esa revisión no debe limitarse a la descripción de la tienda. El titular en el sitio web, la frase del vídeo promocional, la afirmación en la presentación comercial y el texto del documento de soporte pueden producir el mismo resultado. Si en un sitio ha dicho "diagnostica", decir en otro "es solo informativo" no retira esa declaración.

Hay que tomar la decisión desde el principio. Si el producto va a ser un producto sanitario, el proceso que exige ese régimen se establece desde el inicio y entra en el plan como una partida de coste. Si no va a serlo, mantener ese límite en cada texto debe convertirse en una regla de desarrollo del producto.

La arquitectura de acceso a los datos de salud

El artículo 6 de la Ley 6698 considera los datos de salud una categoría especial de datos personales y somete su tratamiento a condiciones más restringidas. La traducción técnica de esta calificación queda incompleta en la mayoría de los proyectos.

El panorama que veo con frecuencia es este. La aplicación funciona, los datos se guardan, pero en el sistema todo el mundo puede ver todo. El desarrollador puede consultar la base de datos de producción, el equipo de soporte puede abrir el historial del paciente, la persona directiva puede ver datos en bruto en los informes. Esto significa que el acceso no está limitado, y es difícil de defender en una auditoría.

El diseño correcto empieza por el control de acceso basado en roles, pero no termina ahí. Cada acceso debe quedar registrado, ese registro debe mostrar quién lo hizo y con qué finalidad, y un acceso fuera de lo habitual debe poder detectarse. Si alguien abre el historial de un paciente a medianoche, eso tiene que ser visible en el sistema.

El entorno de pruebas es una cuestión aparte. Probar con datos reales de pacientes es el hábito más común y más arriesgado en la tecnología sanitaria. Trabajar con datos enmascarados o sintéticos elimina en gran medida ese riesgo y no es técnicamente difícil de implementar.

Apoyo clínico a la decisión y responsabilidad

Los sistemas de apoyo a la decisión con inteligencia artificial plantean la pregunta de quién es responsable. En la práctica, la configuración segura es que el sistema genere la recomendación y la decisión final quede en manos del profesional sanitario competente.

Para que esta configuración no quede solo sobre el papel, deben conservarse conjuntamente tres registros. La recomendación producida por el sistema, los datos en que se basa esa recomendación, y la decisión final tomada por el profesional sanitario. Si los tres se guardan por separado, no podrán cruzarse después; si no se guardan en absoluto, no podrá demostrarse dónde recae la responsabilidad.

Conviene añadir aquí un indicador. Debe vigilarse la tasa con la que el profesional sanitario rechaza la recomendación del sistema. Si esa tasa se acerca a cero, la supervisión humana se ha vuelto formal, y en ese punto es de hecho el sistema quien toma la decisión. Esta constatación puede ser determinante en un debate sobre responsabilidad.

Los servicios de salud a distancia

Los servicios de salud a distancia se rigen por la normativa del Ministerio de Salud. Qué servicios pueden prestarse a distancia, las obligaciones de registro y los límites del servicio se determinan en normativa secundaria. Como esta normativa puede cambiar con el tiempo, al diseñar el producto hay que consultar el texto vigente.

El principio que no cambia es este. Las situaciones que requieren una exploración presencial no pueden atenderse a distancia. Una aplicación de salud a distancia debe poder reconocer y redirigir una solicitud que exceda ese límite. Que el sistema pueda decir "para esta situación, acuda por favor a un médico" no es una característica de usabilidad, es un requisito jurídico.

Al empezar un proyecto

En los proyectos de tecnología sanitaria, la pregunta que hay que responder en la primera reunión no es qué hará el producto, sino qué va a declarar que es. Cada línea de código escrita sin haber respondido a esta pregunta puede haberse escrito conforme al régimen equivocado.

La segunda pregunta corresponde al modelo de datos. Qué dato es realmente necesario, quién podrá verlo, dónde se registrará el acceso y qué ocurrirá cuando la finalidad haya terminado. La respuesta a estas cuatro preguntas determina directamente el diseño de las tablas, y cambiarlo después, al exigir migrar datos de pacientes ya existentes, genera un problema tanto técnico como jurídico.