Servicios
Desarrollo de software conforme con HIPAA: HIPAA no es una casilla que marcar, sino una Privacy Rule, una Security Rule con más de 50 especificaciones de implementación, una Breach Notification Rule con un plazo de 60 días y sanciones HITECH que sitúan a los socios comerciales (business associates) directamente en el punto de mira de la potestad sancionadora de la OCR. Construimos el análisis de riesgos del §164.308(a)(1)(ii)(A), las salvaguardas administrativas, físicas y técnicas conforme a los §164.308–316, los pipelines cifrados de información médica protegida (PHI) en servicios de AWS/GCP/Azure aptos para HIPAA, el flujo del Business Associate Agreement conforme al §164.504(e) y el runbook de Breach Notification conforme a los §164.400–414. Controles de nivel de ingeniería, evidencias legibles por juristas y documentación defendible ante la OCR. Proyectos acotados con el presupuesto acordado antes de empezar el trabajo, sin recargo empresarial.
Ingenieros que leen el Terraform antes que la carpeta de políticas · alineado con el RGPD · preparado para ISO 27001 · SOC 2 Type II en curso · apto para HIPAA · HITECH contemplado · jornada CET con solapamiento de 9:00–13:00 ET
El registro de acuerdos de resolución (Resolution Agreements) de la OCR es un muro de acuerdos de siete cifras por fallos totalmente evitables en el código: análisis de riesgos inexistentes, portátiles sin cifrar, registros de auditoría que nadie lee y BAA que nunca se firmaron. Las sanciones civiles de la estructura escalonada de HITECH llegan a $2,067,813 por categoría de infracción y año (ajustado en 2024). El entregable adecuado no es una carpeta de políticas, sino un sistema en el que cada punto de contacto con PHI queda registrado, cada miembro del personal tiene un ID único, cada copia de seguridad está cifrada con una clave de KMS rotable por el cliente y cada BAA está vigente. Lo construimos así desde la primera vez. Véalo en la práctica en nuestro caso de éxito de Unilab.
El artefacto fundamental que la OCR pide primero. Inventario de activos, emparejamiento de amenazas y vulnerabilidades, puntuación de probabilidad e impacto según NIST SP 800-30, decisiones sobre el riesgo residual firmadas por el responsable de seguridad (Security Official) y un plan de remediación con seguimiento actualizado al menos una vez al año.
Controles del §164.312 en código: ID de usuario únicos, cierre de sesión automático, AES-256 en reposo, TLS 1.2+ en tránsito, controles de integridad, autenticación de personas y entidades con MFA y registros de auditoría que resisten la manipulación. Claves de KMS rotables por el cliente y segregadas por tenant.
Programa del §164.308: designación del Security Official, autorización del personal, política de sanciones, plan de contingencia con copia de seguridad, recuperación ante desastres y operación en modo de emergencia, evaluación periódica y un runbook de procedimientos de incidentes de seguridad vinculado al flujo de Breach Notification.
Plantilla de Business Associate Agreement del §164.504(e), traslado de obligaciones (flow-down) de los BAA a subcontratistas, cuestionario de due diligence de proveedores y un inventario que registra la fecha de entrada en vigor, el alcance y la renovación de cada BAA. BAA de los proveedores de nube (AWS/GCP/Azure) firmados antes de que llegue ninguna PHI.
Runbook de los §164.400–414: plantilla de evaluación de riesgos de cuatro factores, notificación de BA a CE en 60 días, notificación de CE a la persona, envío al portal de la OCR del HHS (500+ en 60 días; anual para los menores) y desencadenantes de notificación a los medios. Evidencias de puerto seguro (safe harbor) para PHI cifrada preparadas de antemano.
Controles de auditoría del §164.312(b): eventos de acceso a PHI por registro, almacén de logs inmutable (S3 Object Lock o equivalente), conservación de 6 años para ajustarse al §164.530(j) y un SOP semanal de revisión de logs con alertas de anomalías que alimentan el procedimiento de incidentes de seguridad.
Semana 1: confirmamos si es entidad cubierta (covered entity) o socio comercial (business associate), inventariamos cada punto de contacto con PHI, mapeamos los flujos de datos entre cuentas de nube y subcontratistas e identificamos el alcance del BAA del proveedor de nube dentro del que realmente opera.
Semanas 2–3: análisis de riesgos completo del §164.308(a)(1)(ii)(A) con la metodología NIST SP 800-30, puntuación de brechas de cada especificación de implementación de las Privacy y Security Rules y una hoja de ruta de remediación firmada por el Security Official.
Semanas 4–12: construimos las salvaguardas técnicas en código e IaC, entregamos las políticas administrativas y la formación del personal, firmamos (formalizamos) los BAA, ponemos en marcha el registro de auditoría con conservación de 6 años y ensayamos el flujo de Breach Notification.
Mensual: revisión de logs, seguimiento de los BAA de proveedores, registro de sanciones, delta trimestral del análisis de riesgos, renovación completa anual y un ensayo de auditoría al estilo de la OCR que pone a prueba la lista de solicitud de documentación del §164.308.
Cuanto más clínico es el flujo de trabajo y más lugares recorre la PHI, más hay que diseñar las salvaguardas, la pista de auditoría y la cadena de BAA. Estos son los dominios de producto de HealthTech que conocemos a nivel de código.
Apps para pacientes y suites de personal por roles en varias clínicas: citas, historiales y paneles con ID de usuario únicos, MFA, PHI cifrada y registro de auditoría construidos conforme al §164.312. Entregamos exactamente esto, apto para HIPAA para EE. UU. y la UE, en nuestra plataforma para clínicas médicas.
Ver el desarrollo de la clínica →Captura clínica, historiales de pacientes y exportación DICOM/HL7 donde los controles de integridad (§164.312(c)) y la seguridad de la transmisión (§164.312(e)) son lo que más pesa. Nuestra plataforma de endoscopia ArgoView registra, almacena y exporta estudios con captura en el navegador para clínicas de EE. UU. y la UE.
Ver el desarrollo de diagnóstico →Plataformas de pacientes multisede con reserva de citas, resultados digitales e integraciones de agenda y contabilidad, donde la PHI cruza muchos sistemas y cada salto necesita un BAA y un mapa de flujo de datos. Lo construimos para la red Unilab de 40 ciudades con más de 2,500 pruebas.
Ver el desarrollo de la red de laboratorios →Apps de agenda de terapia, seguimiento del estado de ánimo y apoyo en crisis en las que la granularidad del consentimiento es crítica: 42 CFR Part 2 se aplica a los datos de consumo de sustancias y las leyes estatales de paridad en telemedicina suelen añadir requisitos de consentimiento. Construimos el modelo de consentimiento por capas, las particiones de datos separadas para los registros de la Part 2 y el registro de auditoría de divulgaciones específico de cada estado junto a las salvaguardas estándar de HIPAA.
Ver trabajos de HealthTech →Los portales de planes de salud, los motores de tramitación de reclamaciones y las plataformas de gestión de utilización son entidades cubiertas cuya superficie de PHI abarca los flujos de elegibilidad, reclamaciones, EOB y UM. El Mínimo necesario (§164.502(b)) y las reglas de Derechos individuales (acceso, rectificación, contabilización de divulgaciones) pesan más. Construimos los flujos de solicitud de derechos, el cifrado en reposo de los datos de reclamaciones y los pipelines EDI 837/835 en servicios aptos para HIPAA.
Ver trabajos de HealthTech →Las plataformas de RPM que agregan flujos biométricos de dispositivos conectados crean un pipeline de PHI que funciona 24/7 desde el domicilio del paciente hasta el panel del clínico. La superficie de HIPAA incluye la seguridad de la transmisión del dispositivo a la nube (§164.312(e)), el control de acceso a nivel de API para las conexiones posteriores con la historia clínica electrónica y el traslado de obligaciones (flow-down) del BAA al fabricante del dispositivo. Diseñamos el pipeline de datos para que la PHI nunca toque un servicio no apto y el registro de auditoría capture cada evento de lectura del dispositivo.
Ver trabajos de HealthTech →De dos a tres semanas, alcance cerrado. Análisis de riesgos del §164.308(a)(1)(ii)(A), análisis de brechas frente a las Privacy y Security Rules, mapa de flujo de datos de PHI, inventario de BAA y una hoja de ruta de remediación con rangos de esfuerzo y coste. Alcance cerrado, presupuesto acordado de antemano.
De ocho a doce semanas. Desarrollo de las salvaguardas administrativas, físicas y técnicas, cifrado y registro de auditoría, refuerzo de IAM, plantillas de BAA y traslado de obligaciones (flow-down) a subcontratistas, materiales de formación del personal, procedimientos de incidentes de seguridad y runbook de Breach Notification. Alcance cerrado por fase, presupuesto acordado de antemano.
Iguala mensual. Renovación trimestral del análisis de riesgos, SOP semanal de revisión de logs, seguimiento de sanciones, renovaciones de BAA y due diligence de proveedores, ensayo anual de auditoría al estilo de la OCR y respuesta a incidentes en iguala. Iguala mensual, alcance transparente.
Lo que mueve la cifra: el número de puntos de contacto con PHI y de sistemas de su mapa de flujo de datos, si es entidad cubierta o socio comercial, el número de cuentas de nube y de BAA de subcontratistas que formalizar y si hay regímenes solapados dentro del ámbito: los registros de consumo de sustancias de 42 CFR Part 2, las leyes estatales (CMIA, Texas HB 300) o el artículo 9 del RGPD para pacientes de la UE añaden cada uno trabajo de evaluación de impacto relativa a la protección de datos (EIPD/DPIA) y de mapeo. Las franjas anteriores son de tarifa fija para el alcance estándar; son los factores, y no una estimación por tarifa diaria, los que fijan dónde cae un presupuesto a medida.
La defensa en investigaciones de la OCR y el apoyo a Resolution Agreements se presupuestan aparte en tiempo y materiales. Mínimo de tres meses en Cumplimiento continuo y después mes a mes con preaviso de 30 días. NDA, DPA y BAA firmados antes del inicio.
Una app para pacientes y una suite de personal basada en roles que unifica varias clínicas: citas, historiales y paneles, apta para HIPAA para EE. UU. y la UE.
App para pacientes de una red de laboratorios en 40 ciudades: reserva de citas, resultados digitales, más de 2,500 pruebas e integraciones de agenda y contabilidad.
Grabación de endoscopias pensada para tabletas, historiales de pacientes y exportación DICOM/HL7, con Laravel + React y captura WebRTC en el navegador para clínicas de EE. UU. y la UE.
Alineado con el RGPD · preparado para ISO 27001 · SOC 2 Type II en curso · apto para HIPAA · HITECH contemplado
Leemos el repositorio, el Terraform, la política de IAM y el pipeline de registros de auditoría antes de escribir un solo párrafo de política. Las salvaguardas se acreditan con código, no con un PDF que contradice lo que hace realmente producción.
HIPAA, las series CC y C de SOC 2, el anexo A de ISO 27001: los controles de fondo se solapan en más de un 70 %. Construimos una única biblioteca de evidencias que cubre los deberes de los tres y, para pacientes de la UE, se extiende al RGPD, de modo que no tenga que pasar auditorías en paralelo.
Cada artefacto se redacta para resistir una solicitud de datos de la OCR. Versionado en su repositorio, firmado por el Security Official y trazable a la especificación de implementación del §164.308 que cubre.
Para las investigaciones de la OCR del HHS y el apoyo a Resolution Agreements trabajamos junto a su asesoría jurídica sanitaria y producimos los paquetes de evidencias que necesita, no las presentaciones comerciales que entregaría un consultor generalista.
Un software de flujo de trabajo clínico que los hospitales realmente adopten es poco habitual. YuSMP desarrolló una plataforma de endoscopia pensada primero para iPad, con captura de vídeo HD, exportación DICOM e integración HL7. El personal médico apenas necesitó formación porque la experiencia de usuario es realmente intuitiva.
Gestionar citas y resultados de pruebas en varias ciudades sobre tres plataformas es realmente complejo. YuSMP resolvió un problema de integración heredado que llevábamos dos años esquivando y entregó una experiencia de paciente que se reflejó de inmediato en nuestras puntuaciones de NPS.
Las entidades cubiertas según 45 CFR §160.103 son los planes de salud, las cámaras de compensación sanitarias y los prestadores de servicios sanitarios que transmiten PHI por vía electrónica en relación con una transacción HIPAA. Los socios comerciales son los proveedores que crean, reciben, mantienen o transmiten PHI en nombre de una entidad cubierta: aquí entran la mayoría de los productos SaaS que atienden a prestadores de servicios sanitarios, pagadores o farmacéuticas. HITECH 2009 hizo a los socios comerciales directamente sujetos a la potestad sancionadora de la OCR. Clasificamos su papel, redactamos o revisamos el Business Associate Agreement (BAA) conforme al §164.504(e) y documentamos el traslado de obligaciones (flow-down) a subcontratistas para que los proveedores posteriores (nube, analítica, herramientas de soporte) hereden las mismas obligaciones.
La Security Rule (45 CFR §164.308–316) exige salvaguardas administrativas, físicas y técnicas. Técnicas: control de acceso con ID de usuario únicos (§164.312(a)), cierre de sesión automático, cifrado en reposo y en tránsito (AES-256, TLS 1.2+), registros de auditoría que capturan el acceso a PHI (§164.312(b)), controles de integridad (§164.312(c)) y autenticación (§164.312(d)). Administrativas: autorización del personal, política de sanciones, plan de contingencia con copia de seguridad de datos, recuperación ante desastres y operación en modo de emergencia (§164.308(a)(7)) y el análisis de riesgos del §164.308(a)(1)(ii)(A), actualizado como mínimo cada año. Físicas: controles de acceso a las instalaciones, seguridad de las estaciones de trabajo y eliminación de dispositivos y soportes (§164.310). Construimos todo esto en su cuenta de AWS/GCP/Azure con servicios aptos para HIPAA bajo el BAA del proveedor de nube.
AWS enumera ~150 servicios aptos para HIPAA bajo su BAA (EC2, S3, RDS, Lambda, ECS/EKS, CloudFront, KMS, etc.); GCP y Azure publican listas equivalentes. La PHI solo debe llegar a servicios aptos, con el BAA firmado antes del tratamiento. Configuramos VPC dedicadas sin superficie pública de PHI, cifrado respaldado por KMS, CloudTrail+VPC Flow Logs enviados a un almacén de logs inmutable, IAM con roles de mínimo privilegio y guardrails SCP, y políticas de bucket de S3 que deniegan el acceso sin TLS. La conservación de logs es de 6 años para ajustarse al requisito de conservación de registros del §164.530(j).
Según 45 CFR §164.400–414, una violación de seguridad es un uso o una divulgación no permitidos de PHI no asegurada que compromete la seguridad o la privacidad, salvo que una evaluación de riesgos de cuatro factores demuestre una baja probabilidad de compromiso. Las entidades cubiertas deben notificar a las personas afectadas sin demora injustificada y, en cualquier caso, a más tardar a los 60 días naturales; notificar a la OCR del HHS en 60 días las violaciones que afecten a 500+ personas (y cada año las más pequeñas); notificar a los medios destacados cuando sean 500+ en un estado o jurisdicción. Los socios comerciales deben notificar a la entidad cubierta en 60 días. El cifrado conforme a NIST SP 800-111 (en reposo) y a módulos validados FIPS 140-2 (en tránsito) da puerto seguro (safe harbor): la PHI cifrada no está «no asegurada» y el plazo de notificación no empieza a correr. Dejamos preparados antes del lanzamiento el runbook, las evidencias de logs y la plantilla de notificación de BA a CE, no después del incidente.
HIPAA es un suelo, no un techo. Las leyes estatales suelen añadir requisitos: la CMIA de California cubre una definición de información médica más amplia que HIPAA; Texas HB 300 amplía la condición de entidad cubierta. CCPA/CPRA se aplica ahora a datos afines a HIPAA no cubiertos por HIPAA (p. ej., datos de apps de bienestar fuera de una relación con un prestador de servicios sanitarios). 42 CFR Part 2 impone reglas de consentimiento más estrictas para los registros de trastornos por consumo de sustancias, recientemente alineadas con HIPAA mediante la norma final de 2024. Para pacientes de la UE, el artículo 9 del RGPD (categorías especiales de datos) se aplica en paralelo y exige base jurídica, DPIA y representante en la UE para responsables de fuera de la UE. Construimos un único mapa de datos de PHI/PII que satisface todos los regímenes solapados.
Tres proyectos acotados, cada uno con un presupuesto acordado antes de empezar el trabajo, sin recargo empresarial. La evaluación HIPAA es de alcance cerrado (de dos a tres semanas): análisis de riesgos del §164.308(a)(1)(ii)(A), análisis de brechas frente a las Privacy y Security Rules, mapa de flujo de datos de PHI, inventario de BAA y hoja de ruta de remediación. La implementación es de alcance cerrado por fase (de ocho a doce semanas): desarrollo de las salvaguardas técnicas, administrativas y físicas, cifrado y registro de auditoría, refuerzo de IAM, plantillas de BAA, materiales de formación del personal, runbook de respuesta a incidentes y flujo de Breach Notification. El cumplimiento continuo es una iguala mensual con alcance transparente: renovación trimestral del análisis de riesgos, revisión de logs, seguimiento de sanciones, renovaciones de BAA, due diligence de proveedores y un ensayo anual de auditoría al estilo de la OCR del HHS. La defensa en investigaciones de la OCR y el apoyo a Resolution Agreements se presupuestan aparte. Cada proyecto se presupuesta frente a un alcance escrito, de modo que usted aprueba el presupuesto antes de empezar.
El marco de entidad cubierta y socio comercial de HIPAA es el punto de partida: una app de bienestar de consumo sin relación con una entidad cubierta generalmente no está sujeta a HIPAA, pero en cuanto se integra con la historia clínica electrónica de un prestador de servicios sanitarios o maneja PHI en nombre de una entidad cubierta, se aplican las obligaciones de BAA y de la Security Rule. La FTC Health Breach Notification Rule (actualizada en 2024) cubre el hueco de las apps de salud directas al consumidor: una violación de seguridad de información de salud identificable individualmente activa una obligación de notificación paralela con independencia de la condición HIPAA. Mapeamos primero el perímetro regulatorio para que la arquitectura refleje las obligaciones reales y no una hipótesis del peor caso que sobredimensiona ni una del mejor caso que protege de menos.
Sí, si la PHI las toca. Google Analytics 4 tiene un BAA disponible bajo Google Workspace; Google Analytics sin el BAA no puede recibir PHI, incluidas direcciones IP identificables en un contexto médico. Mixpanel, Amplitude y Segment publican cada uno su enfoque HIPAA: no todos ofrecen BAA y los que lo hacen restringen qué funciones entran en el ámbito. Intercom, Zendesk y herramientas de soporte similares que reciben texto de tickets en los que los usuarios describen síntomas o medicaciones son socios comerciales. Auditamos cada proveedor de su mapa de flujo de datos, identificamos cuáles necesitan un BAA, lo obtenemos o recomendamos una alternativa conforme y documentamos la decisión en el análisis de riesgos.
No, o solo bajo las mismas salvaguardas que en producción, lo que lo hace antieconómico. La HIPAA Security Rule se aplica dondequiera que se conserve ePHI, así que un entorno de desarrollo con PHI real exige el mismo cifrado, los mismos controles de acceso, registros de auditoría y BAA que prod. La respuesta práctica es la generación de datos sintéticos (Synthea para registros realistas de historia clínica electrónica, Faker o equivalente para datos demográficos) o un pipeline de desidentificación con el método Safe Harbor (puerto seguro) (§164.514(b)(2): eliminar los 18 identificadores enumerados) o Expert Determination (determinación por experto). Construimos el pipeline de desidentificación como parte de la implementación para que su equipo de QA trabaje con datos realistas pero limpios desde el primer día.
Un Designated Record Set (DRS) según el §164.501 es el grupo de registros que mantiene una entidad cubierta y que se usan para tomar decisiones sobre una persona: historiales médicos, registros de facturación y cualquier otro registro usado con ese fin. Los pacientes tienen derechos de acceso (§164.524) y de rectificación (§164.526) sobre su DRS y usted debe elaborar una contabilización de las divulgaciones (§164.528). Arquitectónicamente esto significa: la PHI debe poder consultarse por identificador de paciente, el esquema debe admitir borrados lógicos y pistas de auditoría de rectificaciones y el registro de accesos debe capturar los eventos de lectura a nivel de registro, no solo los eventos de inicio de sesión. Diseñamos el modelo de datos teniendo en cuenta las obligaciones del DRS antes de la primera migración, para que no tenga que adaptar a posteriori API de acceso individual a un esquema que no se construyó para ellas.
Guías prácticas sobre HIPAA, cumplimiento del software sanitario y seguridad de los datos.
Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.