--- { "title": "Libro HIPAA de Aidbox. Parte 1. Salvaguardas técnicas", "description": "Spoiler: HIPAA es sencillo cuando se utiliza Aidbox. La Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA) establece estándares en Estados Unidos para proteger la información de salud individualmente identificable.", "date": "2021-10-25", "author": "Mike Kulakov", "reading-time": "9 min read", "tags": [ "Compliance", "Aidbox" ], "seo-tags": [ "hipaa", "aidbox", "compliance" ] } --- > For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt). > Use it to discover all available pages before guessing URLs. --- La Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA) establece estándares en Estados Unidos para proteger la información de salud individualmente identificable. HIPAA se aplica a las «entidades cubiertas», que incluyen: planes de salud, proveedores de atención sanitaria, centros de intercambio de información sanitaria y organizaciones que realizan ciertas funciones en su nombre, conocidas como «asociados comerciales». Por ejemplo, una consulta médica es una entidad cubierta, y un proveedor del sistema de historia clínica electrónica (EHR) utilizado por los médicos de esa consulta es un asociado comercial. La información de salud individualmente identificable **gestionada por entidades cubiertas y asociados comerciales** se denomina información de salud protegida o PHI. Es importante comprender que no toda la información de salud identificable es PHI. Por ejemplo, si está desarrollando software que recibe información de salud directamente de los pacientes, su organización y su software no están regulados por HIPAA si no interviene ninguna entidad cubierta. La Norma de Seguridad de HIPAA exige a las entidades cubiertas y a sus asociados comerciales que protejan la confidencialidad, integridad y disponibilidad de la PHI mediante salvaguardas administrativas, físicas y técnicas. El [backend FHIR de Aidbox](https://www.health-samurai.io/fhir-server) y su infraestructura automatizada cuentan con numerosos componentes integrados que abordan las [salvaguardas HIPAA](https://www.health-samurai.io/articles/aidbox-hipaa-book-technical-safeguards) técnicas y administrativas. Veamos cómo los sistemas sanitarios basados en Aidbox se mantienen en conformidad con HIPAA. ***Spoiler: HIPAA es sencillo cuando se utiliza Aidbox.*** ## Salvaguardas técnicas de HIPAA ### ESTÁNDAR § 164.312(a)(1) Control de acceso El estándar de control de acceso exige implementar políticas y procedimientos técnicos en sus soluciones que mantengan la ePHI para permitir el acceso únicamente a las personas o programas informáticos a los que se hayan concedido derechos de acceso. El estándar de control de acceso tiene asociadas cuatro especificaciones de implementación. *1. Identificación única de usuario (Obligatoria) 2. Procedimiento de acceso de emergencia (Obligatorio) 3. Cierre de sesión automático (Abordable) 4. Cifrado y descifrado (Abordable)* 1. IDENTIFICACIÓN ÚNICA DE USUARIO (O) - § 164.312(a)(2)(i) - **obligatoria** > Asignar un nombre único y/o número para identificar y rastrear la identidad del usuario. Esta especificación exige que las soluciones de tecnología sanitaria asignen un identificador único a cada usuario del sistema. Toda la actividad del usuario, incluidas las sesiones, las llamadas a la API, etc., debe etiquetarse con este identificador. Este modelo de implementación aporta transparencia y trazabilidad, y permite rastrear la actividad específica del usuario y hacer a los usuarios responsables de las funciones realizadas en los sistemas de información con ePHI. *HIPAA no define requisitos técnicos para los formatos de identificación de usuarios, por lo que los enfoques de los implementadores pueden diferir.* El [módulo de gestión de usuarios y control de acceso](https://www.health-samurai.io/docs/aidbox/access-control/access-control) de Aidbox utiliza UUIDs para la identificación de usuarios. Cada usuario recibe un ID único durante el proceso de registro. El uso de este ID permite gestionar los permisos de forma granular. Estas funcionalidades están disponibles en Aidbox con los recursos User, AccessPolicy y Role. Para organizaciones consolidadas con infraestructuras de TI complejas, Aidbox permite el uso de [mecanismos de identidad federada](https://www.health-samurai.io/docs/aidbox/access-control/access-control) para gestionar y mapear identidades de usuario de confianza en múltiples sistemas de TI o incluso organizaciones. En este escenario, se sigue asignando un UUID único para que Aidbox identifique al usuario. 2. PROCEDIMIENTO DE ACCESO DE EMERGENCIA (O) - § 164.312(a)(2)(ii) - **obligatorio** > Establecer (e implementar según sea necesario) procedimientos para obtener la información de salud protegida electrónica necesaria durante una emergencia. Esta especificación de implementación exige establecer (e implementar según sea necesario) procedimientos para obtener la ePHI necesaria durante una emergencia. Cuando se produzca un incidente que comprometa la disponibilidad del sistema, deberá contar con instrucciones documentadas y prácticas operativas que permitan obtener acceso a la ePHI necesaria. Esto incluye no solo salvaguardas técnicas, sino también un proceso administrativo que otorgue a los usuarios los privilegios necesarios para acceder a la ePHI en condiciones de emergencia si la intervención manual es inevitable. El procedimiento de acceso de emergencia de Aidbox aprovecha los mecanismos de copia de seguridad y replicación de la infraestructura de base de datos automatizada de Aidbox, que garantizan la integridad de los datos. Estas medidas minimizan la posibilidad de pérdida de datos en caso de emergencia y proporcionan la capacidad de restaurar la versión más reciente e íntegra de la ePHI. Por ejemplo, la infraestructura de Aidbox emplea una arquitectura de base de datos activa-pasiva en la que un nodo pasivo replica en tiempo real todos los cambios producidos en el nodo activo. Con la configuración adecuada, el retraso se minimiza a varios minutos, reduciendo la posibilidad de pérdida de datos en caso de emergencia. Este enfoque también garantiza una alta disponibilidad, ya que el nodo pasivo se promueve a activo en caso de que el nodo activo deje de estar disponible. El módulo de [control de acceso](https://www.health-samurai.io/docs/aidbox/access-control/access-control) de Aidbox admite la creación de políticas de acceso de emergencia que permitirán el acceso necesario a la ePHI para usuarios identificados. Los administradores pueden identificar a los usuarios que requieren acceso de emergencia y configurar políticas de acceso de emergencia para recuperar la ePHI necesaria desde un entorno restaurado en caso de emergencia. 3. CIERRE DE SESIÓN AUTOMÁTICO (A) - § 164.312(a)(2)(iii) - **abordable** > Implementar procedimientos electrónicos que terminen una sesión electrónica tras un tiempo predeterminado de inactividad. Esta especificación es una salvaguarda razonable, pero no es obligatoria y no incumplirá su conformidad con HIPAA si decide no implementarla por cualquier motivo. Todo usuario que inicie sesión en el sistema debe tener un tiempo de sesión predeterminado. La duración de la sesión puede determinarse en función del rol del usuario, la sensibilidad de la información, etc. Si un usuario permanece inactivo durante este período, deberá autenticarse antes de continuar usando los servicios. El módulo de [control de acceso](https://www.health-samurai.io/docs/aidbox/access-control/access-control) de Aidbox permite establecer un tiempo de expiración para el token de sesión JWT del usuario. También se puede configurar un tiempo de expiración para los clientes de API. Se pueden configurar múltiples recursos de cliente para roles de usuario que requieran duraciones de sesión diferentes. 4. CIFRADO Y DESCIFRADO (A) - § 164.312(a)(2)(iv) - **abordable** > Implementar un mecanismo para cifrar y descifrar la información de salud protegida electrónica. Los datos de ePHI deben cifrarse para reducir la posibilidad de acceso no autorizado. Esto puede aplicarse no solo al almacenamiento en base de datos, sino también a las copias de seguridad y los registros de actividad para evitar el acceso no autorizado y la exposición de ePHI. La infraestructura automatizada de [Aidbox](https://www.health-samurai.io/fhir-server) utiliza particiones cifradas para los datos en reposo de forma predeterminada. Los datos se cifran/descifran automáticamente durante las operaciones de entrada/salida de la base de datos mediante las claves emitidas por el proveedor de la nube. Las claves de cifrado son rotadas por el proveedor de la nube, y el período de rotación también es configurable. El IAM del proveedor de la nube ([AWS](https://aws.amazon.com/iam/?nc1=h_ls), [Azure](https://azure.microsoft.com/en-us/products/category/identity/) y [Google](https://cloud.google.com/iam)) se utiliza para evitar el acceso no autorizado a la infraestructura de nube subyacente. ### ESTÁNDAR § 164.312(b) Controles de auditoría > Implementar mecanismos de hardware, software y/o procedimientos que registren y examinen la actividad en los sistemas de información que contengan o utilicen información de salud protegida electrónica. El control de auditoría exige que un sistema disponga de capacidades de auditoría para hacer a los usuarios responsables de las operaciones realizadas usando ePHI. Debe capturarse un registro de auditoría para todos los componentes de software utilizados en los servicios conformes con HIPAA. La mejor guía actualizada para los registros de auditoría de aplicaciones sanitarias puede encontrarse en la norma ASTM E2147-18, «Especificación estándar para registros de auditoría y divulgación para uso en sistemas de información sanitaria», que fue seleccionada por ONC para la tecnología EHR certificada. Aidbox [registra automáticamente](https://www.health-samurai.io/docs/aidbox/core-modules/logging-and-audit) todos los eventos de autenticación, API, base de datos y red. Los registros incluyen la marca de tiempo del evento, el tipo de acción, el ID de usuario, el cuerpo de la solicitud, la consulta a la base de datos, el ID del cliente de API, etc., según el tipo de registro. De forma predeterminada, Aidbox utiliza [ElasticSearch para la persistencia de registros](https://www.health-samurai.io/docs/aidbox/modules-1/observability/logging-and-audit/how-to-guides/elastic-logs-and-monitoring-integration), y Kibana/Grafana para el análisis y la visualización de registros. También puede configurar la integración con soluciones de monitorización y gestión de registros de terceros como [Datadog](https://www.health-samurai.io/docs/aidbox/core-modules/logging-and-audit/datadog-guide), Splunk o SumoLogic. Además, la monitorización y el registro también pueden configurarse en el lado del proveedor de la nube con soluciones como Stackdriver, CloudWatch, etc. Con este enfoque, puede investigar la actividad de los clientes en los componentes de software que rodean el backend y la base de datos de Aidbox. Estos componentes incluyen enrutadores de red, servidores proxy Nginx, motores de orquestación de contenedores y entornos de ejecución de aplicaciones. Puede encontrar más detalles sobre el registro y la auditoría en [nuestra documentación](https://www.health-samurai.io/docs/aidbox/core-modules/logging-and-audit). ### ESTÁNDAR § 164.312(c)(1) Integridad > Implementar políticas y procedimientos para proteger la información de salud protegida electrónica frente a alteraciones o destrucción indebidas. El estándar de integridad exige que el software implemente políticas y procedimientos para proteger la ePHI frente a alteraciones o destrucción indebidas. La infraestructura de Aidbox dispone de varios medios para garantizar la integridad de los datos. En primer lugar, la mayoría de las operaciones de API están envueltas en transacciones de PostgreSQL con un nivel de aislamiento de al menos «lectura confirmada». Esto evita cambios concurrentes no deseados y permite revertir la operación en caso de que se produzca un error durante la ejecución de la consulta. Además, Aidbox garantiza la integridad de los datos mediante el uso de [mecanismos estándar de replicación y copia de seguridad de bases de datos PostgreSQL](https://www.health-samurai.io/aidbox#Infrastructure). El sistema de copias de seguridad está configurado para ejecutarlas según un calendario predefinido (cada hora, diariamente, por la noche) y archivar los registros WAL de forma continua. En caso de corrupción de datos, por ejemplo si se ejecutó una consulta maliciosa, este enfoque permite realizar una recuperación a un punto en el tiempo, es decir, restaurar a la versión más reciente e íntegra de los datos. Para poder restaurar desde la copia de seguridad lo antes posible, se recomienda probar el proceso de recuperación de forma proactiva. Las copias de seguridad se almacenan en almacenamiento en la nube altamente disponible y cifrado. Es posible realizar una configuración adicional del almacenamiento del proveedor de la nube que implemente redundancia multirregión. La replicación de la base de datos y las copias de seguridad pueden configurarse por el equipo de Aidbox durante el despliegue del proyecto. 1. MECANISMO PARA AUTENTICAR LA INFORMACIÓN DE SALUD PROTEGIDA ELECTRÓNICA (A) - § 164.312(c)(2) - **abordable** > Implementar mecanismos electrónicos para corroborar que la información de salud protegida electrónica no ha sido alterada o destruida de manera no autorizada. Aidbox solo permite a usuarios o servicios autorizados utilizar sus APIs, garantizando así la ausencia de destrucción o alteración indebida o accidental de la ePHI. El [módulo de registro y auditoría](https://www.health-samurai.io/docs/aidbox/access-control/audit-and-logging) permite investigar todas las actividades de los usuarios para que cualquier operación no deseada pueda detectarse y revertirse. ### ESTÁNDAR § 164.312(d) Autenticación de persona o entidad > Implementar procedimientos para verificar que una persona o entidad que solicita acceso a la información de salud protegida electrónica es quien dice ser. La autenticación confirma que una persona que intenta acceder a la ePHI es efectivamente quien dice ser. Esto se logra aportando una prueba de identidad. Existen varias formas de aportar prueba de identidad para la autenticación, como contraseñas, claves privadas, posesión de dispositivos o incluso biometría. El control de acceso de Aidbox proporciona una experiencia de autenticación segura con inicio de sesión mediante contraseña y flujos integrados de recepción y confirmación de contraseña. Para mayor seguridad, Aidbox ofrece [autenticación multifactor](https://www.health-samurai.io/docs/aidbox/security-and-access-control-1/auth/two-factor-authentication) (MFA) para proteger las cuentas de usuario frente a accesos no autorizados. Puede habilitar [2FA](/blog/2fa-in-your-healthcare-application) para un usuario y configurarlo con AuthConfig, Client y AidboxConfig. Se utiliza un TOTP (contraseña de un solo uso basada en el tiempo) para obtener un token de acceso para su aplicación. Para fines de desarrollo también se admiten métodos de autenticación simples como la autenticación básica. ### ESTÁNDAR § 164.312(e)(1) Seguridad en la transmisión > Implementar medidas de seguridad técnica para protegerse contra el acceso no autorizado a la información de salud protegida electrónica que se transmite a través de una red de comunicaciones electrónicas. 1. CONTROLES DE INTEGRIDAD (A) - § 164.312(e)(2)(i) - **abordable** > Implementar medidas de seguridad para garantizar que la información de salud protegida electrónica transmitida electrónicamente no sea modificada indebidamente sin detección hasta su eliminación. [Aidbox](https://www.health-samurai.io/fhir-server) utiliza HTTP sobre TLS para la transmisión de ePHI y este protocolo garantiza por diseño que los datos enviados son los mismos que los datos recibidos. No se requiere ningún esfuerzo adicional para cumplir con esta especificación si su aplicación utiliza Aidbox para todas sus necesidades de transmisión de datos. 2. CIFRADO (A) - § 164.312(e)(2)(ii) - **abordable** > Implementar un mecanismo para cifrar la información de salud protegida electrónica cuando se considere apropiado. [Aidbox](https://www.health-samurai.io/fhir-server) utiliza HTTP sobre TLS para la transmisión de ePHI y este protocolo cifra todos los datos transmitidos. La infraestructura automatizada de Aidbox incorpora un gestor de certificados SSL que emite y actualiza los certificados SSL automáticamente para que no se pierda su caducidad. En general, utilizamos certificados proporcionados por Let's Encrypt, pero se puede configurar cualquier proveedor compatible con ACME. Además, también es posible el uso de un certificado existente emitido por el proveedor de la nube (por ejemplo, el ACM de Amazon). En los próximos capítulos explicaremos cómo Aidbox ayuda a cubrir las salvaguardas administrativas de HIPAA. > Comience con el [servidor FHIR](https://www.health-samurai.io/aidbox) de Aidbox para el almacenamiento de datos, integraciones, análisis sanitario y más, o [contrate a nuestro equipo](https://www.health-samurai.io/services) para satisfacer sus necesidades de desarrollo de software. [![Aidbox FHIR Platform Free Trial](image-1.avif)](https://www.health-samurai.io/aidbox) Véase también: [Preparar FHIR para producción](/blog/first-steps-to-get-your-fhir-based-solution-ready-for-production).