Privacidad, auditoria y consentimiento

Esta pagina documenta reglas de producto y arquitectura vigentes para funcionalidades de salud que tratan datos sensibles. No reemplaza asesoramiento legal y debe mantenerse alineada con lo efectivamente implementado en produccion.

Premisa

BeanCRM debe tratar la informacion de salud como informacion de maximo riesgo del producto. Para producto y arquitectura esto implica:

• Minimizacion: cada pantalla y rol ve solo lo necesario para su tarea.
• Separacion logica entre datos administrativos y clinicos/sensibles.
• Trazabilidad obligatoria de accesos y cambios relevantes.
• Controles explicitos para portal, formularios, exportaciones y cambios de permisos.
• Revision legal antes de textos finales, retencion definitiva y operacion con datos reales.

Separacion de dominios

Las funcionalidades de salud deben separar:

1. Dominio administrativo-operativo: datos necesarios para identificar, agendar, cobrar, contactar y operar la relacion con el paciente.
2. Dominio clinico/sensible: datos de salud, historia clinica, notas de consulta, formularios clinicos, adjuntos de salud y cualquier campo que revele diagnostico, motivo de consulta, tratamiento, evolucion, medicacion o antecedentes.

Reglas de separacion

• Las entidades clinicas no deben ser necesarias para renderizar agenda, cobros, metricas comerciales ni listados administrativos.
• Los permisos clinicos deben concederse explicitamente por rol y, cuando aplique, por relacion profesional-paciente.
• Las busquedas globales deben indexar por defecto datos administrativos.
• La busqueda sobre contenido clinico debe ser una capacidad separada, con permiso especifico y auditoria.
• Los exports deben diferenciar paquetes administrativos y paquetes clinicos.

Roles base

• Owner: administra suscripcion, equipo, configuracion y politicas. No debe leer contenido clinico por ser owner si no tiene rol profesional o permiso clinico explicito.
• Admin/recepcion: opera agenda, cobros y datos administrativos. No accede a notas clinicas ni formularios clinicos.
• Profesional: atiende pacientes. Accede a datos administrativos necesarios y a datos clinicos de sus pacientes asignados o compartidos.
• Paciente/portal: accede a sus turnos, pagos, formularios habilitados y consentimientos. No accede a notas internas por defecto.

Auditoria minima

La auditoria debe registrar actor, rol, tenant, accion, recurso, timestamp UTC, IP, user agent cuando exista, resultado, correlacion y motivo cuando corresponda. Los logs no deben guardar contenido clinico completo; deben registrar metadatos y hashes/versiones cuando sea suficiente.

Eventos minimos:

• Login exitoso/fallido y cambios de autenticacion.
• Lectura, creacion, edicion y borrado logico de datos sensibles.
• Cambios de roles, permisos clinicos y asignacion profesional-paciente.
• Exportaciones administrativas y clinicas.
• Aceptacion o revocacion de consentimientos.
• Accesos denegados relevantes.

Consentimiento

El consentimiento debe tratarse como un registro versionado y verificable, no como un booleano simple.

Entidades conceptuales:

• ConsentTemplate: tipo, texto, version, vigencia, idioma, hash del contenido y estado.
• ConsentGrant: paciente, template, version, fecha/hora, canal, IP/user agent, actor y evidencia.
• ConsentScope: portal, formularios administrativos, formularios clinicos, recordatorios, comunicaciones e intercambio dentro del equipo profesional.
• ConsentRevocation: fecha, alcance revocado, efecto futuro, actor y motivo opcional.

Checklist operativo

• Separacion implementada entre datos administrativos y clinicos.
• RBAC/ABAC validado para owner, admin/recepcion, profesional y paciente/portal.
• Tests de acceso denegado para notas clinicas, formularios clinicos, exports y portal.
• Auditoria minima implementada para eventos sensibles.
• Logs sin contenido clinico completo ni secretos.
• Consentimientos versionados con evidencia de aceptacion/revocacion.
• Backups cifrados y restore probado.
• Terminos, privacidad y consentimientos revisados por profesional legal.