Software multi-clínica: cómo separar datos entre sedes correctamente

Cuando una clínica abre su segunda sede, la pregunta que casi nadie hace a tiempo es: "¿el personal de la sede B puede ver, por accidente o por curiosidad, los pacientes de la sede A?" La respuesta correcta depende de una decisión técnica que rara vez se explica en una demo de ventas.

La diferencia entre "permisos de pantalla" y separación real de datos

Muchos sistemas resuelven el multi-sede ocultando el menú: el usuario de la sede B simplemente no ve un botón para entrar a los datos de la sede A. Eso protege contra un uso normal — pero no contra alguien que cambia un identificador en la URL, usa las herramientas de desarrollador del navegador, o simplemente encuentra un endpoint de la API que no filtró correctamente por sede.

La separación real ocurre en la base de datos, con una técnica llamada Row Level Security (RLS): cada fila de cada tabla (pacientes, citas, ventas, expedientes) lleva asociada la clínica a la que pertenece, y el motor de base de datos rechaza cualquier consulta que intente leer o escribir datos de una clínica distinta a la del usuario autenticado — sin importar por dónde llegue la consulta. No es un filtro que la aplicación decide aplicar; es una regla que la base de datos impone siempre.

Por qué esto no es un detalle técnico menor

En salud, los datos de pacientes son datos sensibles bajo la LFPDPPP (Ley Federal de Protección de Datos Personales en Posesión de los Particulares). Una fuga entre sedes — aunque sea accidental, aunque nadie la explote con mala intención — es una violación de la ley con consecuencias reales, no solo un bug incómodo.

Además, operativamente: si el reporte de negocio (BI) de la sede A mezcla, aunque sea un solo registro, datos de la sede B, cualquier decisión basada en ese reporte queda contaminada. Un dueño de tres clínicas necesita confiar ciegamente en que el número que ve por sede es exacto.

Qué preguntar antes de contratar un sistema multi-sede

"¿La separación es por permisos de la aplicación o por Row Level Security en la base de datos?" Si la respuesta es "por permisos, el usuario no ve el botón", no es suficiente. Pedir específicamente el término RLS o su equivalente exacto en la tecnología que usan.

"¿Un administrador de plataforma puede ver todas las sedes, y un administrador de sede solo la suya?" Debe existir una jerarquía clara: alguien con visión global (el dueño de la cadena de clínicas) y administradores locales limitados a su propia sede, sin que uno pueda escalar accidentalmente al nivel del otro.

"¿Qué pasa si dos sedes comparten un mismo doctor?" Un médico que atiende en dos sucursales necesita ver su propia agenda combinada, sin que eso implique que también vea los pacientes de otros doctores en cada sede.

El costo de no resolverlo bien desde el inicio

Migrar de un sistema sin separación real de datos a uno que sí la tiene, después de que la clínica ya tiene años de historial acumulado, es una migración de datos delicada y costosa. La decisión correcta es evaluar esto antes de la primera carga de datos reales, no después de que el problema ya se manifestó.

Un software multi-clínica bien construido no solo permite crecer a varias sedes — protege legalmente a cada una de ellas desde el primer día, sin depender de que nadie cometa un error de configuración.