¿Tiene consultorios o clínicas en todo el mundo y desea recopilar datos estadísticos en un único almacenamiento? ¿Quiere además tener la certeza absoluta de que su sistema cumple con HIPAA y sigue las normativas locales (como el RGPD)? ¿O quizás tiene múltiples oficinas en los EE. UU. y desea implementar un almacén de datos médicos para mejorar el rendimiento a nivel local? Todo esto puede lograrse mediante la sincronización de almacenamientos de datos médicos. En este artículo me gustaría compartir nuestra experiencia en la implementación de sincronización de datos conforme a HIPAA entre múltiples instancias de Aidbox.
La sincronización de datos entre múltiples sistemas no es algo nuevo. Se utiliza en sistemas distribuidos con múltiples almacenamientos de datos, generalmente para implementar integraciones con varios sistemas o mejorar el rendimiento. En el ámbito sanitario, este proceso también está asociado a la protección de la PHI. Por ejemplo, los datos personales de los pacientes no deben transmitirse a almacenamientos ubicados en otros países.
El equipo de WaveAccess, en colaboración con Health Samurai, ha desarrollado una solución de extensión para Aidbox para un cliente estadounidense con clínicas en múltiples países. Esta extensión permite la sincronización de datos conforme a HIPAA entre múltiples instancias locales de Aidbox y un Aidbox global. Otro componente esencial de este servicio es el módulo de anonimización de datos, que protege la PHI eliminando todos los identificadores de los pacientes antes de enviar los datos a otra instancia de Aidbox.
A continuación, analizaremos nuestra experiencia real en la implementación de esta solución. También repasaremos los desafíos técnicos específicos que encontramos y explicaremos exactamente cómo los resolvimos.
Este artículo resultará de utilidad para CTOs, responsables técnicos, gestores de proyectos, líderes de equipo y demás profesionales técnicos encargados de la transferencia de datos entre múltiples servidores FHIR.
Continúe leyendo para conocer:
- Descripción del caso de uso
- Cumplimiento de HIPAA
- Desafíos de la sincronización
- Estructura y flujo de trabajo del módulo de sincronización
1. Descripción del caso de uso
El cliente dispone de una cadena de clínicas en múltiples países con su sede central en los EE. UU. Cuenta con varias aplicaciones locales para profesionales sanitarios que utilizan instancias de Aidbox como almacenamiento de datos médicos, y una aplicación global para fines administrativos con su propio Aidbox. El Aidbox global debe contener información médica procedente del nivel local para estadísticas, gestión, etc. Por otro lado, los Aidboxes locales deben disponer de información coherente sobre la estructura organizativa y los datos geoposicionales contenidos en el Aidbox global. Esto significa que los Aidboxes locales deben enviar determinada información anonimizada sobre pacientes, citas, observaciones, diagnósticos y otras entidades relacionadas al Aidbox global, y recibir a su vez información específica relativa a su ubicación (como una lista de países, estados, organizaciones, etc.).
Para implementar el proceso de intercambio de datos, es necesario desarrollar un módulo de sincronización que permita configurar y realizar la sincronización bidireccional con capacidad de anonimizar la PHI de los pacientes.
La arquitectura de alto nivel tiene el siguiente aspecto:

Los Aidboxes locales recopilan los datos de las aplicaciones locales. Los servicios de sincronización reciben estos datos, los anonimizan y los transfieren al Aidbox global. Estos servicios también gestionan el proceso de envío de datos desde el Aidbox global al nivel local.
Este enfoque contribuye a proteger la PHI de los pacientes. Los servicios de sincronización se almacenan localmente, lo que significa que la información sensible también se procesa de forma local. Una vez que estos servicios completan el proceso de anonimización, los datos médicos pueden transferirse de forma segura al Aidbox global.
2. Cumplimiento de HIPAA
La Ley de Portabilidad y Responsabilidad de los Seguros de Salud de 1996 (HIPAA) es una ley federal que exige la creación de estándares nacionales para proteger la información sanitaria sensible de los pacientes frente a su divulgación sin el consentimiento o conocimiento del paciente. Estos datos sensibles se denominan información sanitaria protegida (PHI) e incluyen datos demográficos e información que identifica a las personas, como nombre, dirección, fecha de nacimiento y número de la Seguridad Social.
¿Cómo pueden las organizaciones transferir, recopilar y procesar datos médicos de los pacientes? De acuerdo con la Norma de Privacidad de HIPAA, no existen restricciones sobre el uso o divulgación de información sanitaria desidentificada (anonimizada). La forma más sencilla de desidentificar los datos es eliminar todos los identificadores especificados y cualquier otra información que pudiera utilizarse para identificar a un paciente.
Esto significa que una solución conforme a HIPAA debe contar con una funcionalidad de anonimización que elimine todos los identificadores de los pacientes de los datos médicos antes de transferirlos a otro almacenamiento.
Si desea obtener más información sobre HIPAA, puede consultar el sitio web del Departamento de Salud y Servicios Humanos de los EE. UU. o leer nuestro artículo Aidbox HIPAA book / Part 1 / Technical safeguards.
3. Módulo de sincronización de Aidbox
Analicemos ahora nuestra solución. Según los requisitos, el servicio de sincronización debe contar con las siguientes funcionalidades:
- Sincronización bidireccional entre los Aidboxes locales y el global
- Anonimización de datos conforme a HIPAA
- Configuración de la sincronización
3.1 Estructura general
En el caso más habitual, la arquitectura del módulo de sincronización tiene el aspecto del diagrama siguiente:
El módulo recibe datos de un Aidbox local, los anonimiza y los envía al Aidbox global. Durante el proceso de desarrollo nos enfrentamos a los siguientes desafíos:
- ¿Cómo podemos saber qué datos de un Aidbox local han cambiado y deben, por tanto, enviarse al Aidbox global?
- ¿Cómo podemos garantizar que solo determinadas instancias de Aidbox puedan realizar la sincronización con el Aidbox global?
- ¿Cómo debemos implementar la anonimización de datos?
Veamos cada uno de estos desafíos.
3.2 Seguimiento de cambios en los datos
La tarea de sincronización de datos no puede resolverse sin determinar qué entidades han cambiado desde la iteración de sincronización anterior. Aidbox proporciona un mecanismo para el seguimiento de cambios en los recursos denominado Aidbox Changes API. En lugar de exportar e importar entidades o realizar operaciones masivas, la Changes API utiliza un mecanismo basado en iteraciones de diferentes versiones que aporta transparencia adicional al proceso. Esto resulta muy útil en caso de cualquier incidencia que pueda producirse durante el proceso de sincronización.
También creamos un recurso personalizado llamado ChangesInfo que contiene el nombre de una entidad y un número de versión. Durante el proceso de sincronización, recuperamos este recurso para cada uno de los tipos de recursos FHIR que se sincronizan, obtenemos su versión y llamamos al endpoint $changes. Si alguna entidad ha cambiado desde la iteración de sincronización anterior, el endpoint devuelve la lista de dichas entidades. Finalmente, creamos una transacción de Aidbox con una operación PUT, POST o DELETE para cada una de las entidades modificadas.
3.3 Control de la sincronización
El proceso de sincronización debe ser seguro y controlable. Por ello, definimos otro recurso personalizado, AidboxInstance, que fue añadido al Aidbox global. Este recurso ayuda a restringir el acceso de los Aidboxes locales al Aidbox global para realizar la sincronización. En cada interacción del proceso en segundo plano, comprobamos la entidad AidboxInstance del Aidbox local para verificar que existe en la base de datos del Aidbox global y que debe sincronizarse.
3.4 Anonimización de datos
La anonimización de datos es el proceso de proteger la información privada o sensible mediante la eliminación o el cifrado de los identificadores que vinculan a una persona con los datos almacenados. En nuestro caso, la información sensible que debe anonimizarse son los atributos identifier, name, telecom y address del recurso FHIR Patient; los atributos personalizados patientFirstName, patientLastName y patientMiddleName del recurso FHIR QuestionnaireResponse; y el atributo answer de algunos recursos FHIR QuestionnaireResponse asociados a preguntas como «Correo electrónico personal», «Nombre», «Teléfono», «Fecha de nacimiento» y «Dirección».
Cuando los datos salen del módulo de sincronización, este borra dichos atributos. Naturalmente, el conjunto de entidades y atributos FHIR que deben borrarse puede configurarse en la aplicación.
3.5 Flujo de trabajo de la sincronización
El proceso de sincronización de datos se ilustra en los dos diagramas siguientes. El primero muestra el proceso de envío de datos desde los Aidboxes locales al global. El segundo muestra el proceso en sentido inverso.
El primer paso para transferir datos desde el Aidbox local al global es identificar todos los cambios en los datos mediante la Aidbox Changes API. A continuación, el módulo de anonimización procesa los datos para eliminar todos los atributos de PHI. Finalmente, los datos se transfieren al Aidbox global.
El proceso de transferencia de datos desde el Aidbox global al local es el mismo, salvo por la parte de anonimización. Los datos que se transfieren desde el nivel global tienen un carácter más administrativo y no contienen información sobre pacientes. Este tipo de datos médicos no está cubierto por HIPAA y puede transferirse sin restricciones.
3.6 Resumen
Como resultado, el módulo de sincronización es un servicio aislado que funciona en segundo plano y logra la sincronización entre las entidades definidas del Aidbox local y la entidad del Aidbox global. Además, dispone de una API para realizar la sincronización manual de tipos de entidades concretos.
Para concluir esta sección, me gustaría enumerar las ventajas de esta solución:
- Mantenimiento sencillo. Basado en la Changes API, el servicio proporciona información sobre cada paso del proceso de sincronización para cada entidad, lo que facilita la detección de cualquier incidencia.
- Alta personalización. Podemos añadir cualquier otro paso intermedio, tal como hicimos con el proceso de anonimización. Esto puede afectar al rendimiento final, pero aplicamos multihilo y paralelismo para reducir estos costes adicionales.
- Garantía de seguridad. Hemos especificado el acceso a la sincronización para cada instancia de Aidbox local. Esto significa que solo determinados Aidboxes pueden realizar la sincronización con la instancia global.
- Cumplimiento de HIPAA. El Aidbox global recibe y almacena únicamente información sanitaria desidentificada. El módulo de anonimización elimina todos los identificadores y demás información sensible de los datos, lo que los hace seguros para su transferencia.
Para explorar la sincronización conforme a HIPAA en sus sistemas, considere utilizar la versión gratuita de Aidbox. Esta proporciona un entorno seguro para probar y desarrollar procesos de sincronización, ofreciendo todas las herramientas necesarias sin limitaciones de funcionalidades.
4. Conclusión
En este artículo hemos compartido nuestra experiencia en la implementación de un módulo para el proceso de sincronización de Aidbox conforme a HIPAA. La sincronización de múltiples entornos de almacenamiento de datos médicos es de gran importancia para los sistemas de información sanitaria distribuidos o globales. Un proceso de sincronización bien configurado permite a las organizaciones sanitarias recopilar eficientemente datos estadísticos que pueden utilizarse para investigación médica o de gestión, o mejorar el rendimiento mediante la integración de almacenes de datos en la arquitectura del sistema. Sea cual sea el objetivo que se persiga, no debe olvidarse la protección de la PHI de los pacientes y la anonimización de los datos.
Si tiene oficinas en distintos países, desea integrar un almacén de datos médicos o simplemente tiene alguna pregunta, no dude en ponerse en contacto con nosotros. Tanto nuestro equipo como el de Health Samurai estarán encantados de ayudarle.
Autor:
Paul Chayka,
Experto en soluciones sanitarias | Gestor de proyectos y líder de equipo en WaveAccess

Véase también: Gestión de datos multiconsultorio con OrgBAC.








