← Volver a los proyectos
Caso de estudio · Privacidad de los datos sanitarios
Público · Caso de estudio

Healthcare Data Privacy Lab

Los sistemas sanitarios deberían eliminar lo que las herramientas externas no necesitan.

Construí un pequeño prototipo de anonimización sin conexión para notas clínicas porque los datos sanitarios sensibles no deberían pasar por defecto a herramientas de IA, productos SaaS ni flujos de trabajo compartidos. Más tarde encontré OpenMed y empecé a contribuir al ecosistema de código abierto más amplio.

Sistemas que priorizan lo local // Desidentificación // OpenMed // Riesgo de los datos en SaaS // Texto clínico
El problema

El momento peligroso ocurre antes de la subida

El momento peligroso no es solo cuando un modelo da una respuesta.

El momento peligroso llega antes, cuando alguien copia texto sanitario sensible en una herramienta externa sin saber adónde va, quién puede acceder a él, si queda registrado, si se puede borrar o si el sistema necesitaba esos datos en primer lugar.

Esa herramienta puede ser un producto de IA. También puede ser una plataforma SaaS corriente, un sistema de tickets, una aplicación de transcripción, un panel de analítica, un formulario de admisión o un conversor de archivos.

Los nombres son evidentes. Las fechas no. Los lugares no. Los identificadores no. Una nota clínica puede exponer a una persona incluso después de eliminar el nombre.

Lo primero que construí

Un pequeño prototipo local con una pregunta más grande

Primero construí un prototipo local para macOS en torno a NLM Scrubber, para que un usuario pudiera arrastrar y soltar notas sanitarias y eliminar la información sanitaria protegida antes de usar el texto en otro lugar.

No era un producto médico ni una garantía de cumplimiento. Era una prueba de principio: el texto sensible debe limpiarse en local antes de que pase a cualquier otro sitio.

Prototipo

health-data-anonymiser es el primer artefacto público de esta línea de trabajo. La idea más amplia cruza fronteras e idiomas: los formularios sanitarios, los identificadores, las fechas y las expectativas legales difieren entre Europa, Estados Unidos, Bélgica, España, Marruecos y otros contextos. El repositorio público no es un motor de cumplimiento global. Es el primer artefacto local del principio de minimización de datos.

Después encontré OpenMed

Lo más maduro fue contribuir

Después de construir el prototipo, encontré OpenMed: un proyecto sanitario de código abierto más amplio que trabaja en el procesamiento de texto clínico que prioriza lo local, la detección de PII, la desidentificación y la extracción de entidades médicas.

Lo más maduro no fue hacer ver que mi prototipo era la respuesta completa. Lo más maduro fue contribuir al proyecto que ya avanzaba con más profundidad.

Atribución

OpenMed no es mío y no lo construí yo. OpenMed es un proyecto de código abierto más grande, mantenido por su propia comunidad. Mi papel es el de un pequeño colaborador en trabajos concretos de privacidad y fiabilidad.

Esta no es una historia sobre ser dueño del proyecto más grande. Es una historia sobre detectar pronto el problema adecuado, construir un primer artefacto y unirme después al ecosistema más sólido cuando lo encontré.

La dirección de mi contribución a OpenMed

Casos límite aburridos que importan

Mi trabajo en OpenMed es una pequeña parte de un esfuerzo comunitario más amplio. No enumero aquí todas mis contribuciones porque el objetivo no es un marcador. Lo que importa es el tipo de trabajo que necesitan los sistemas de privacidad:

  1. Gestión de fechas.
  2. Conservación del formato.
  3. Comportamiento determinista.
  4. Cobertura de CI.
  5. Casos límite de privacidad.

En la privacidad sanitaria, los errores pequeños con las fechas no son pequeños. Una fecha puede identificar a una persona, corromper una cronología o hacer que un texto desidentificado induzca a error.

Ejemplo sintético

Sin datos reales de pacientes

Ejemplo sintético. Sin datos reales de pacientes.
AntesPaciente Maria Lopez, con fecha de nacimiento 15/03/1972, acudió al St. Mary Hospital el 12/01/2024. Teléfono: 555 0199. Diagnóstico: seguimiento de hipertensión.
DespuésPaciente [NOMBRE], con fecha de nacimiento [FECHA], acudió a [LUGAR] el [FECHA]. Teléfono: [TELÉFONO]. Diagnóstico: seguimiento de hipertensión.
Por qué importa ahora

La pregunta es qué llega al sistema

Los datos sanitarios están entrando en una fase cargada de nueva regulación.

La pregunta importante no es solo qué modelo o producto SaaS se utiliza. La pregunta importante es qué datos llegan al sistema, qué se elimina antes, qué se queda en local, qué se registra y qué se puede auditar después.

Esto importa porque los datos sanitarios pueden usarse para algo más que la atención sanitaria: la elaboración de perfiles, la evaluación del riesgo en los seguros, la selección de personal, la elegibilidad en el sector público, las comprobaciones de fraude, la publicidad, la intermediación de datos, la ingeniería social y el robo de identidad se vuelven más fáciles cuando circula demasiado contexto sensible sin trazabilidad.

Mi interés está en la capa previa al teatro del cumplimiento: minimización de datos, desidentificación, procesamiento local, revisión humana y evidencia.

Contexto normativo
  • El Reglamento Europeo de IA (AI Act) utiliza un marco basado en el riesgo, que incluye categorías de alto riesgo en las que los sistemas pueden afectar a la salud, la seguridad o los derechos fundamentales.
  • Colorado SB26-189 enmarca ahora la tecnología de toma de decisiones automatizada en torno a las decisiones con consecuencias relevantes, entre ellas los servicios de atención sanitaria, con obligaciones de documentación para desarrolladores y responsables del despliegue a partir del 1 de enero de 2027.
  • El sistema DROP de California marca el rumbo para los intermediarios de datos: los residentes pueden presentar solicitudes de supresión y los intermediarios de datos deben empezar a tramitarlas a partir del 1 de agosto de 2026.
  • La herramienta de la FTC para aplicaciones móviles de salud trata la privacidad y la seguridad de las aplicaciones de salud como una obligación empresarial, no como algo que se añade al final del diseño.
Lo que demuestra esto

Del artefacto a la colaboración

Esta línea del proyecto demuestra 4 cosas:

  1. Puedo identificar riesgos de privacidad en flujos de trabajo con texto clínico.
  2. Puedo construir pequeñas herramientas locales que demuestran el principio.
  3. Puedo contribuir a infraestructuras sanitarias de código abierto de mayor tamaño.
  4. Puedo traducir los problemas técnicos de privacidad en cuestiones de gobernanza, de producto y operativas.
Límites

Dónde está la línea de la honestidad

  • No es un producto médico, una herramienta de diagnóstico ni un consejo médico.
  • No es una garantía de cumplimiento y no afirma cumplir con HIPAA.
  • La desidentificación reduce el riesgo. No elimina todos los riesgos de reidentificación.
  • OpenMed no es mi proyecto. Mi contribución es pequeña, concreta y forma parte de un esfuerzo comunitario más amplio.
  • Los datos clínicos reales siguen necesitando una revisión de privacidad, una revisión jurídica y una revisión humana de los resultados antes de usarse.
Empieza aquí

Antes de que un sistema externo vea el texto

Si tu equipo está experimentando con IA sanitaria o con cualquier flujo de trabajo SaaS con datos de salud, empieza por la frontera de los datos.

¿Qué se elimina?

¿Qué se queda en local?

¿Qué llega al sistema externo?

¿Quién revisa el resultado?

¿Qué evidencia demuestra que el sistema se comportó de forma responsable?