Garantizar la privacidad de la información, en especial cuando ésta se refiere a datos personales que contienen información confidencial, es precisamente uno de los aspectos más  relevantes que cualquier política de seguridad debe contemplar. Esta afirmación es especialmente cierta en el ámbito médico asistencial. Se trata en este caso de un ámbito específico, complejo y singular en el que confluyen necesidades e intereses que en algunos casos son de difícil encaje. Definir criterios y fórmulas que permitan equilibrar la tensión permanente y de fondo que se establece entre la necesidad de acceso a la información por parte del facultativo y el derecho a la protección de la privacidad por parte del paciente o usuario no es una tarea siempre fácil. A esta inherente complejidad se le suma una casuística rica y variada en matices y lecturas que incrementa, más si cabe, la dificultad para poder definir y encontrar soluciones estandarizadas que sean de aplicación  general.

Aunque el marco legal que rige la protección de datos personales es extenso, en algunos casos la concreción y traducción al lenguaje técnico de las distintas directrices que en el se definen continua siendo una tarea compleja. Son muchas las veces que se hace referencia a conceptos y criterios de difícil interpretación o implementación técnica. Pese a todo y a este respecto hay que reconocer que la aparición del reciente reglamento de la LOPD, reglamento que fija las medidas de seguridad que deben aplicarse, ha contribuido a paliar en parte esta situación. Este reglamento da un paso más allá en el camino de definir cuáles son las actuaciones de índole técnica que un organismo, sea público o privado, debe implementar para adecuar su normal funcionamiento a lo que fija la LOPD. Si bien es verdad que la evolución de la tecnología genera nuevos paradigmas y escenarios de seguridad inicialmente no previstos, en términos generales, el reglamento es suficientemente claro. Creemos sin embargo que todavía faltan casos prácticos que permitan visualizar soluciones específicas a problemas concretos en entornos reales. Y es esta una carencia que el presente artículo, en la medida de lo posible, pretende compensar: queremos mostrar un caso práctico real que pueda servir de ejemplo de una actuación de seguridad en temas de privacidad de datos realizada en un ámbito sanitario asistencial público. Cumpliendo con este requerimiento pedagógico empezaremos primero concretando qué perseguía la actuación que se realizó y en que contexto se hizo. Posteriormente responderemos a la pregunta de qué se hizo, cómo se hizo.

La actuación que aquí se describe formaba parte de un proyecto global más amplio y ambicioso en el ámbito de la seguridad de la información en el entorno de CatSalut, ente público catalán encargado de garantizar el derecho a la protección de la salud en Cataluña.  Uno de los sub-proyectos que estructuraba el proyecto principal era precisamente el que presentamos ahora: un proyecto de disociación de datos personales . El objetivo principal del mismo era garantizar la confidencialidad y la privacidad de los datos personales que se gestionan en un entorno tan extenso y complejo, organizativamente hablando, como es el del CatSalut. Inherente a este objetivo también se establecía la necesidad de cumplir con la normativa legal en el ámbito de la protección de datos.

Para entender mejor el porqué de las distintas actuaciones realizadas resulta muy útil identificar los requerimientos legales que fija la legislación tanto en la LOPD como en su reglamento. En ellos se establece, entre otras, la obligación de preservar la confidencialidad de los datos personales en cualquier proceso de cesión o comunicación de información entre empresas u organismos. La propia ley estipula que esta obligación debe garantizarse mediante la ejecución del llamado Proceso de Disociación de los datos que se van a ceder o comunicar. Aparece aquí por primera vez este concepto, Proceso de Disociación, concepto clave sobre el que se basó el proyecto de protección de la privacidad. Aparte, y de manera similar, el reglamento fija en uno de sus puntos la prohibición de realizar pruebas, modificaciones, actualizaciones o mejoras de los entornos de gestión de Bases de Datos utilizando datos reales. Este segundo requerimiento define en la práctica la necesidad de disponer de un entorno de pre-producción anonimizado, es decir, un entorno de características similares al de producción contra el cual se puedan lanzar y testear nuevas aplicaciones y funcionalidades por parte de terceros sin riesgo para los datos. En cualquier caso y tal como establece el reglamento, los datos en dicho entorno no pueden ser reales por lo que deben haber sido sometidos a un procesos de disociación o enmascaramiento..

El proceso de disociación es un proceso que tiene como objetivo modificar o enmascarar la información de los registros que contienen la base de datos de tal manera que una vez ejecutado el proceso ya no sea posible identificar a una persona conocida a partir de los datos que se ceden. No es una concepto trivial o sea que vayamos por partes para entenderlo mejor: es sabido que en la mayoría de los registros personales que forman una base de datos se acostumbra a distinguir dos categorías de información: (1) una identificativa, más o menos explícita y (2) otra de tipo privado más o menos confidencial. La primera categoría hace referencia a campos como nombre, DNI, número de tarjeta Sanitaria, etc... mientras que la segunda categoría hace referencia a datos como pueden ser edad, sexo, estado civil, domicilio, historial de ingresos en centros asistenciales, resultados de pruebas médicas realizadas, antecedentes psiquiátricos, medicación prescrita etc... No hacemos referencia aquí a una historia clínica compartida, estamos hablando de información de usuarios o pacientes localizada en alguna de las tablas que puedan formar una base de datos de un organismo asistencial. En todo caso el proceso de disociación persigue modificar mediante técnicas de enmascaramiento no sólo el valor de los campos que contienen datos identificativos sino también aquellos campos no directamente identificadores pero que pueden inducir a la identificación de la persona. Pongamos un ejemplo: María García, 22 años, viuda, residente en una población menor de 36.000 habitantes, Valls por ejemplo, y seropositiva. Al ser la situación de María poco común, viuda y joven, la disociación de este registro no puede limitarse al simple enmascaramiento del nombre y el apellido de la persona, ya que cualquier persona que conozca a María y lea que se trata de una joven viuda de Valls, aunque el nombre sea diferente, la identificará y asociará a su persona la información confidencial. No todo el mundo conoce a María pero todos aquellos que la conozcan pueden inferir fácilmente que es seropositiva. Y es aquí donde radica la dificultad del proceso de disociación: en ser capaz de identificar qué registros y variables deben ser modificados y de qué manera. En el caso de María, a parte de los datos directamente identificativos, la variable edad debe ser modificada asignando un valor nuevo en un rango que va de los 22 a los 27 años, por ejemplo, y modificando la localidad de manera que no se asocie la información a una ciudad o pueblo sino por ejemplo a una comarca. La realización de este proceso en el caso de una base de datos extensa y compleja no es tarea trivial y es aquí en donde reside el valor de la actuación presentada. El resultado final del proceso de disociación aplicado a este registro ficticio sería por ejemplo un registro en que la mujer en cuestión pasaría a llamarse Isabel Pérez de 25 años, residente en la comarca del l’Alt Camp (zona sur de Cataluña). El estado civil no cambiaría así como tampoco el hecho que esa persona fuese seropositiva, ya que esta información confidencial es la que se quiere preservar por considerarse significativa. Esta información puede ser importante y utilizarse para correlacionar por ejemplo el estado civil con una enfermedad.

En el caso de CatSalut tanto la cantidad de datos como el número de tablas asociadas, 1800 variables en 400 tablas con un volumen de información de aproximadamente un Terabyte, hicieron imprescindible un estudio previo que tenía como objetivo determinar y seleccionar para cada tabla cuales eran las variables que había que enmascarar y que método de enmascaramiento debía usarse. Este fue un factor clave del proceso pues en muchos casos y al objeto de preservar la función de testeo del entorno de pre-producción es importante obtener valores enmascarados similares a los originales. Pongamos de nuevo un ejemplo, al modificar el campo numérico EDAD, un niño no puede pasar a ser un anciano y viceversa. En este sentido el hecho que nuestra empresa sea una spin off de uno de los grupos de investigación punteros en el mundo en temas de confidencialidad nos permitió seleccionar para cada variable el mejor método de enmascaramiento existente. El criterio de selección también incluyó reducir al mínimo el impacto del proceso de disociación en el normal funcionamiento del entorno de gestión de la base de datos.

La ejecución del proceso de disociación en el entorno de pre-producción se realizó mediante el uso del paquete Data Masking de Oracle. Se trata de una aplicación nueva que permite seleccionar y enmascarar aquellas tablas y variables de una base de datos que se deseen de manera segura y eficiente en tiempo y coste computacional. Entre otras ventajas, Data Masking permite preservar la integridad referencial del conjunto de aplicaciones. Es este un atributo importante pues no hay que olvidar que el objetivo funcional último del entorno de pre-producción es el de servir como entorno de pruebas y testeo de aplicaciones desarrolladas por terceros. El tiempo de ejecución propiamente dicho del proceso de disociación para un conjunto de 12 millones de registros en un equipo de gama media alta se estimó en unas 6 horas en total.

A modo de conclusión podemos establecer que las ventajas que se obtienen al implementar un proceso de disociación como el detallado son muchas y variadas; por un lado se da respuesta a uno de las cuestiones más complejas que plantea la legislación vigente en temas de protección de datos y por otro se crea un entorno de pruebas, desarrollo y testeo seguro que permite el acceso y la cesión de datos anonimizados a terceros. 

Por último resaltar que creemos que este caso representa un claro ejemplo de colaboración real entre distintas empresas y organismos para establecer y ejecutar principios conceptuales y técnicos aplicables a una situación real. De manera conjunta con Oracle y la Cátedra Unesco en Privacidad de Datos de la Universidad Rovira i Virgili, nuestra empresa, STAITEC, ha liderado una experiencia de disociación de datos que tenía como principal objetivo garantizar  la privacidad en el ámbito de una administración pública. Creemos que este caso práctico representa un buen ejemplo de colaboración entre partners de especialidades distintas pero a su vez complementarias. Igualmente esta experiencia revela la existencia en el mercado actual de herramientas tecnológicamente sofisticadas que permiten aplicar de manera eficiente los requisitos legales que fija la legislación estatal en lo que corresponde a la protección de datos.