APIs de imagen dental con cumplimiento HIPAA: lista de verificación de seguridad para integraciones en salud de EE. UU.
Si vas a integrar una API de imagen dental con un DSO, grupo clínico o especialidad en Estados Unidos, HIPAA no es una casilla al final del proyecto. Es una restricción de diseño. Los archivos DICOM cargan PHI en sus cabeceras, los audit logs son obligatorios y las reglas de notificación de brecha aplican a cada byte que tocas. Esta lista captura las diez cosas a las que cualquier CTO u oficial de cumplimiento debería poder responder "sí" antes de salir a producción.
Como referencia, las páginas HIPAA de HHS son la fuente autorizada. Este artículo es orientación operativa, no asesoría legal — trabaja con tu equipo legal para cualquier cosa vinculante.
Lista de 10 puntos
1. Cifrado en reposo y en tránsito
Cada byte de PHI debe estar cifrado en el cable y en disco. Eso significa TLS 1.2 o superior para todas las llamadas API y webhooks, y server-side encryption en la capa de almacenamiento. CBCTHub sirve todo el tráfico sobre TLS 1.3 y guarda los archivos DICOM en Cloudflare R2 con SSE habilitado. Verifica tu propio extremo de la conexión — proxies viejos, balanceadores caseros y agentes on-prem son los puntos débiles típicos de TLS.
2. Política de rotación de API keys
Los secretos de larga vida son una responsabilidad. Rota las API keys al menos cada 90 días, e inmediatamente cuando un empleado con acceso se va. Integra la rotación en tu secret manager (AWS Secrets Manager, Vault, Doppler) para que la nueva key se aprovisione y la vieja se revoque sin downtime. CBCTHub permite múltiples keys activas por cuenta, así puedes hacer roll forward sin ventana de mantenimiento.
3. Verificación HMAC en webhooks
Si tu integración recibe webhooks, cada payload debe verificarse con HMAC SHA-256 antes de tocar tu lógica de negocio. Rechaza cualquier request cuyo X-CBCTHub-Signature no valide contra el secreto compartido y usa una comparación de tiempo constante (por ejemplo, crypto.timingSafeEqual en Node, hmac.compare_digest en Python) para evitar fugas por timing.
4. Audit logs retenidos al menos seis años
La regla general de retención de HIPAA es de seis años. Tu rastro de auditoría debe registrar quién accedió a qué examen, cuándo, desde qué IP y qué acción tomó. CBCTHub expone los audit logs tanto desde el dashboard como por el endpoint /api/account/audit-log, con exportación CSV para retención offline. Envía esos logs a tu SIEM y mantén las copias fuera de almacenamiento mutable.
5. Scoping granular de acceso
El principio de privilegio mínimo aplica a las API keys. No emitas una única super-key por integración — emite keys con scope para lo que cada sistema realmente necesita. Las keys de CBCTHub hoy llevan scopes exams:read y exams:write, con scopes más finos en el roadmap. Usa keys sandbox (cbct_test_) para QA, así los desarrolladores nunca ven PHI de producción.
6. Business Associate Agreement (BAA)
Cualquier proveedor que crea, recibe, mantiene o transmite PHI en tu nombre es un business associate y debe firmar un BAA. No envíes una sola llamada de producción hasta tener el BAA firmado. CBCTHub provee un BAA estándar bajo solicitud para planes Pro o superiores — habla con ventas antes del go-live.
7. Procedimientos de notificación de brecha
Si ocurre una brecha, el cronómetro empieza al instante. Tienes 60 días para notificar a los individuos afectados y a HHS (y a un fiscal estatal, según jurisdicción). Documenta la cadena de mando, las plantillas y la lista de contactos antes de necesitarlos. La política de privacidad de CBCTHub incluye nuestros compromisos y plazos de notificación de brecha.
8. Derechos de acceso del paciente (HIPAA Right of Access)
Bajo HIPAA, los pacientes tienen derecho a acceder a su PHI dentro de 30 días. Tu integración debe soportar esto de punta a punta — dale al paciente una forma de pedir, recibir y descargar su imagen en un formato usable. El portal de paciente de CBCTHub y el endpoint /api/account/export-data cubren los requisitos técnicos; el flujo lo defines tú.
9. Anonimización para investigación y ML
Si alguna vez usas exámenes reales para desarrollo de producto, investigación o entrenamiento de ML, anonimízalos siguiendo el método Safe Harbor (18 identificadores removidos) o el método de Expert Determination. CBCTHub soporta tokens de embed anonimizados que ocultan el nombre del paciente en el visor; combina eso con stripping de cabeceras a nivel DICOM para cualquier dato que salga de producción.
10. Borrado seguro de archivos
Los soft-deletes son cómodos para producto, pero peligrosos para PHI. Cuando el paciente pide borrado o la política de retención lo indica, los bytes deben desaparecer de verdad. Verifica que tu proveedor borre del almacenamiento primario y de los backups dentro de una ventana definida. CBCTHub purga los exámenes borrados de R2 en 30 días y sobreescribe las filas de la base.
Cómo cumple CBCTHub cada punto
| Punto | Estado |
|---|---|
| 1. Cifrado | TLS 1.3 + R2 SSE |
| 2. Rotación de keys | Múltiples keys por cuenta, revocación inmediata |
| 3. HMAC en webhooks | SHA-256 con secreto por subscripción |
| 4. Audit logs | Dashboard + API + exportación CSV |
| 5. Scoping | Scopes read/write, keys sandbox |
| 6. BAA | Disponible en plan Pro o superior |
| 7. Notificación de brecha | Documentada en política de privacidad |
| 8. Acceso del paciente | Portal + endpoint de exportación |
| 9. Anonimización | Tokens de embed anonimizados |
| 10. Borrado seguro | Purga de R2 + DB en 30 días |
Cómo nos comparamos en cumplimiento
Muchos proveedores legacy de imagen dental marcan la casilla de cifrado y ahí se quedan. Los diferenciadores que escuchamos de compradores estadounidenses son BAAs firmados sin fricción legal, audit logs accesibles por API en vez de por ticket de soporte, y webhooks firmados con HMAC. El trabajo para hacer eso bien no aparece en una comparativa de features, pero es exactamente lo que tu revisión de seguridad va a indagar.
Dónde estamos con SOC 2
SOC 2 Type II está en proceso. Compartimos el reporte Type I y la lista actual de controles bajo NDA — escribe a security@cbcthub.com.
Conclusión
El cumplimiento HIPAA para una integración de imagen dental no es un proyecto que se termina — es una postura que se mantiene. Los diez puntos de arriba son la base para cualquier despliegue serio en salud de EE. UU., y los hábitos operativos detrás (rotación, scoping, auditoría, borrado) te protegen tanto de la próxima regulación como de la actual. Constrúyelos desde el día uno y el resto de la integración se vuelve más fácil.
Solicita un BAA y nuestro whitepaper de cumplimiento · Lee la documentación de seguridad
Prueba CBCTHub gratis
Sube, visualiza y comparte examenes DICOM en la nube. Sin instalar nada.
Crear cuenta gratisArticulos relacionados
Proteccion de datos de pacientes en Estados Unidos: guia HIPAA y HITECH para centros radiologicos dentales
Como cumplir HIPAA (Public Law 104-191), Privacy Rule, Security Rule y HITECH Act en una clinica de imagen dental. PHI, BAA, multas OCR hasta USD 1.5M anuales.
Proteccion de datos de pacientes en Mexico: guia LFPDPPP, INAI y NOM-024 para centros radiologicos dentales
Como cumplir la LFPDPPP, su Reglamento, la NOM-024-SSA3-2012 y la NOM-004 en una clinica de imagen dental. INAI, Aviso de Privacidad, multas en UMA. Como ayuda CBCTHub.
Proteccion de datos de pacientes en Argentina: guia Ley 25.326 y Ley 26.529 para centros radiologicos dentales
Como cumplir la Ley 25.326 de Habeas Data, la Ley 26.529 de Derechos del Paciente, AAIP y el reconocimiento de adecuacion de la UE en una clinica dental. Como CBCTHub ayuda.