Blog de Raymundo Vásquez Ruiz

Las aplicaciones de software médico, debido a su naturaleza de potencial riesgo para la salud de una persona, operan en un entorno donde las regulaciones sobran. En los tiempos actuales dichas regulaciones también tienen que ver con el lugar de residencia y procesamiento de los datos de los pacientes.

En Europa existe una constante labor por parte de las autoridades para evitar que los datos de pacientes europeos sean almacenados o procesados en los EEUU ya que en ese país existen lineamientos que permiten a ciertas instituciones acceder a la información manejada por sus empresas. Las grandes empresas de servicios en la nube con origen en los EEUU (AWS, Azure o Google Cloud) son conscientes de dichas preocupaciones y constantemente publican información para asegurar que los centros de datos ubicados en Europa son completamente adecuados para manejar dicha información.

Aún así los gobiernos de ciertos países como Alemania prefieren evitar sorpresas por completo y promueven el desalojamiento de la información de los centros de datos de operadores con origen estadounidense, independientemente de su ubicación, dentro del marco de algunos programas nacionales. Esto obliga a que las empresas que publican aplicaciones de software médico en la nube busquen alternativas puramente europeas para continuar con sus operaciones con pacientes alemanes.

Debido a esta situación durante los últimos meses he tenido que evaluar a estos proveedores de servicios en la nube, elegir al más competente en base a requerimientos técnicos y regulatorios y, finalmente, alterar el diseño del sistema de la aplicación para permitir que los datos de ciertos pacientes no sean hospedados en AWS, el proveedor original de la aplicación.

Eligiendo al proveedor

En realidad no existen numerosos proveedores puramente europeos con la capacidad de otorgar variedad de servicios a escala considerable. Concretamente se requiere mínimamente, para este caso, que cuente con un cortafuegos (firewall), un load balancer, lanzamientos escalables de imágenes docker, una red de entrega de contenidos (CDN), almacenamiento de objetos, manejador de dominios, almacenamiento con Mongo DB, un servicio de caching (REDIS idealmente), almacenamiento de bitácoras de operaciones (algo muy importante para los estándares médicos) y estándares internacionales como ISO 27001 para seguridad en el acceso y manejo de la información.

Dado el conjunto descrito anteriormente se eligió a Open Telekom Cloud (OTC) como la mejor opción ya que cuenta con todos los requerimientos además de proveer un buen servicio hacia el cliente y con soporte técnico adecuado. Sus centros de datos están ubicados en Holanda y Alemania, sin alguna comunicación con los EEUU.

Algunos servicios en la oferta de OTC. La lista completa se encuentra aquí.

Cabe recordar que las empresas estadounidenses cuenta con experiencia de mercado que lleva décadas de ventaja, por lo tanto es irreal esperar que una empresa europea, de creación reciente, pueda otorgar los mismos niveles de servicio que AWS. Por ejemplo, la SDK de OTC no otorga el soporte adecuado para Node.js, el análisis de la bitácora de actividades está muy lejos del ideal, la versión más reciente de Mongo DB ofrecida está aún en la rama 4.x, entre otras.

Adecuando el diseño del sistema para soportar multi-cloud

Una vez elegido el proveedor llegó el momento de evaluar cómo incorporarlo y permitir que los datos de los pacientes sean almacenados conforme a los requerimientos.

Aunque se consideró la posibilidad de lanzar una nueva aplicación totalmente independiente para dicho país y poder tener claridad en la implementación técnica, algo como tal requiere de un costo en regulaciones difícil de determinar. Al final se optó por la creación de un servicio intermedio que maneja identidades de usuarios y las asocia con su correspondiente proveedor.

Este servicio intermedio almacena información básica para poder determinar la asociación de un paciente con un proveedor a través de un registro. Este registro se crea cuando un usuario accede por primera vez y sus valores están determinados por ciertos parámetros que el usuario proporciona.

Servicio de Manejo de Identidades

El flujo de datos queda definido como:

1. El paciente registra una nueva cuenta. El Servicio de Manejo de Identidades (SMI) determina con qué proveedor debe comunicarse dicho paciente y almacena un registro al respecto.
2. El SMI informa al usuario sobre su proveedor de servicios.
3. Las llamadas consecuentes son dirigidas al proveedor apropiado.

De esta manera la aplicación es completamente agnóstica del proveedor de cómputo y la carga de la decisión se transfiere al SMI. Un proceso similar se efectua la siguiente vez que el paciente acceda a su cuenta. Por defecto el SMI sigue la regla de redirigir al servicio original (AWS) en caso de no contar con un registro para el usuario.

Cabe mencionar que, para cumplir correctamente con los lineamientos, el SMI debe también residir en OTC.

Lanzamientos multi-cloud

A consecuencia de la introducción de un nuevo operador se requiere que la línea de lanzamiento de aplicaciones adapte una forma de mantener los servicios en múltiples sistemas. Para este caso se optó por kubernetes como interfaz ya que tanto AWS como OTC lo soportan.

Conclusión

Aunque es perfectamente entendible la preocupación de los gobiernos europeos por el manejo de los datos de sus ciudadanos, considero que forzar decisiones como la expuesta en este artículo pueden también presentar un riesgo para la aplicación de software médico por una razón principal:

La calidad de los servicios europeos de cómputo en la nube aún no está a la par de los estadounidenses.

Esto conlleva que la capacidad de manejo y resolución de errores se vea comprometida y no permite a las empresas de software médico operar con los últimos estándares y más recientes tecnologías.

Personalmente la considero más una solución política que una basada en análisis adecuados.

Aún con lo anterior es posible crear sistemas multi cloud en donde el riesgo de fallos se minimice atendiendo a una base sólida de usuario en un proveedor sólido de servicios.