Idioma
EnglishTürkçeSuomiEspañolItalianoDeutschFrançaisNederlandsSvenska
Raznameh Clinics
Guías›Seguridad y cumplimiento

Derecho de seguridad y privacidad · Estados Unidos, Unión Europea, Reino Unido

Primero la ley, después el software que la lleva a cabo.

Una historia de salud mental es una de las clases de datos más protegidas que existen. Una sola mirada equivocada a un solo expediente puede convertirse en una vulneración notificable. Esta página empieza con las tres leyes que deciden qué debe hacer: HIPAA en Estados Unidos, el RGPD en la Unión Europea y UK GDPR en el Reino Unido. Después muestra exactamente qué parte de la plataforma cumple cada deber. Y luego cubre cómo está construido el propio software, cómo controla Odoo Community quién ve qué, cómo se endurece el servidor y, al final, las partes que se quedan con su organización.

Está escrita en lenguaje claro a propósito. Debería poder entregársela a un delegado de protección de datos, a un auditor de seguridad o a un gestor que no haya leído nunca una norma, y que los tres la sigan.

Delegados de protección de datos Auditores de seguridad de la información Direcciones clínicas Compradores en diligencia debida
3regímenes legales cubiertos 5propiedades de cada historia 0formas de anular el acceso AES-256-GCMcifrado en cada fichero 20 añosla conservación más larga modelada
Elija su país Qué pide la ley EE. UU. · UE · RU en paralelo Qué se protege Las cinco propiedades Quién puede abrir una historia Odoo: acceso, inicio de sesión, roles Endurecimiento del servidor Defensa en profundidad Práctica del sector sanitario Si algo sale mal Controles de la plataforma Qué puede demostrar Dónde termina el software
Empiece aquí

Elija el país en el que opera

Casi todo lo que sigue es igual en todas partes: el cifrado, el control de acceso, el registro de auditoría, el endurecimiento del servidor. Lo que cambia por país es la maquinaria de derechos y gobernanza que va encima, y eso tiene su propia página. Si está haciendo una diligencia debida, empiece por su país y vuelva después al material común.

Estados Unidos EE. UU. HIPAA · HITECH · 42 CFR Part 2 · derecho estatal La mayor de las tres. Todas las reglas estadounidenses que alcanzan a una consulta de salud mental, qué se ha construido para cada una y, al final, siete recorridos paso a paso de lo que ocurre de verdad dentro del software.
  • Privacy Rule: todos los derechos del paciente, incluidas las partes que casi todos los sistemas se saltan
  • Security Rule: las ocho salvaguardas técnicas, más los registros administrativos y físicos
  • Notificación de vulneraciones: cuatro factores, 60 días, umbrales por estado, los dos relojes del proveedor
  • 42 CFR Part 2, incluida la regla de 2024
  • Siete flujos : una solicitud de historia, una corrección denegada, una comunicación, una vulneración, un paciente nuevo, una pantalla inactiva y el año de cumplimiento
 Unión Europea GDPR Reglamento (UE) 2016/679 Base jurídica del artículo 9(2)(h) en vez de consentimiento, supresión ejecutada destruyendo la clave de cifrado, portabilidad como exportación registrada, y los dos plazos de vulneración con la exención que hay que ganarse.
  • Por qué las historias de tratamiento no deben apoyarse en el consentimiento
  • Una supresión que atiende el derecho sin destruir la prueba
  • El reloj de 72 horas y la pregunta de si se comprometieron las claves
  • El registro de tratamientos y la evaluación de impacto como registros vivos
 Deutschland Alemania § 203 StGB · § 630f BGB · NIS2 · SGB V Las reglas europeas se aplican aquí sin cambios, y encima Alemania añade una capa propia, una pieza de la cual es derecho penal y decide si una consulta puede comprarnos lícitamente siquiera.
  • § 203 StGB: por qué la elección de proveedor es el riesgo jurídico del terapeuta
  • Qué dice una declaración del § 203, cláusula por cláusula
  • Diez años desde el final del tratamiento, no desde la fecha del expediente
  • NIS2 para grupos de consultas, y el programa ya construido
  • Una cuenta honesta del carril estatutario que no tenemos
 Reino Unido UK GDPR DPA 2018 · NHS Code of Practice 2021 Lo que el Reino Unido añade sobre el RGPD: el criterio de daño grave construido como un flujo que caduca solo, el calendario de conservación del NHS como datos entregados, y un derecho sobre las historias de personas fallecidas.
  • Una reserva que exige un profesional con nombre y decae a los seis meses
  • Veinte años tras el último contacto en las historias de salud mental
  • Access to Health Records Act 1990
  • El Principio Caldicott 7 y por qué la rotura de cristal es una función
 Australia Privacy Act 13 APP · esquema NDB · derecho estatal de conservación Una ley federal sin exención de pequeña empresa para un prestador sanitario, ocho conjuntos de reglas estatales sobre conservación y —desde junio de 2025— un paciente que puede demandar sin esperar a un regulador.
  • Los trece Australian Privacy Principles, uno por uno
  • APP 8: por qué no tiene que salir nada del país
  • Siete años desde la última anotación, y hasta los 25 para un menor
  • El flujo de vulneración, paso a paso, más el aviso de ransomware en 72 horas
  • Essential Eight, ISO 27001, RACGP C6.4, y por qué la SOCI no se aplica
 Canadá PIPEDA y PHIPA 10 principios · leyes provinciales · conservación de los colegios Ni HIPAA ni una sola ley: una ley federal, una ley sanitaria que cambia con la provincia, y un colegio profesional encima de las dos fijando cuánto se conserva una historia.
  • Qué ley y qué comisionado, provincia por provincia
  • Los diez principios de PIPEDA, y la PHIPA custodian por custodian
  • El lockbox: el único concepto canadiense que todavía no tenemos
  • Dos relojes de vulneración, y el informe estadístico anual de cada marzo
  • El carril de facturación provincial en el que no estamos, dicho en la sección 09
 Común a las seis Documentos seguros La maquinaria en la que se apoya cada página de país Cómo se cifra una historia clínica, quién puede abrir una, la vida entera de un documento desde que se archiva hasta que se elimina y, al final, siete riesgos que no tienen arreglo técnico.
  • Cifrado de sobre, y por qué hay dos claves y no una
  • Un acceso que sigue a la relación de tratamiento
  • Eliminación destruyendo una clave en lugar de borrando una fila
  • Siete riesgos dichos con claridad, con lo que se queda de su lado
01 — Empiece por la ley

Qué le piden de verdad HIPAA, el RGPD y UK GDPR

Casi todos los documentos de seguridad empiezan por la tecnología y dejan la ley para el final. Este hace lo contrario, porque la ley es aquello contra lo que se le juzga. Abajo está cada régimen en lenguaje claro: qué es, a quién se aplica y qué deberes pone sobre una clínica. Bajo cada uno está la parte de la plataforma que cumple ese deber.

Estados Unidos

HIPAA

HIPAA es la Health Insurance Portability and Accountability Act. Se aplica a los prestadores sanitarios de Estados Unidos y a las empresas que manejan datos de salud por su cuenta. Está hecha de dos partes principales. La Privacy Rule dice quién puede ver información de salud y qué puede pedir un paciente. La Security Rule dice cómo hay que proteger la información sanitaria electrónica.

  • Mínimo necesario. El personal solo puede ver la información que necesita para el trabajo que tiene delante. En la plataforma esto lo imponen las relaciones asistenciales: una terapeuta alcanza a los pacientes de su propia carga de casos, no a los de toda la clínica.
  • El conjunto designado de historia. Un paciente puede pedir una copia de su historia, pero no de todo lo que guarda la clínica. Cada tipo de documento se marca como dentro o fuera de ese conjunto, y una solicitud no puede devolver lo que queda fuera.
  • Las notas de psicoterapia van aparte. HIPAA trata las notas de proceso del propio terapeuta de forma distinta a la historia. En la plataforma se cifran bajo una clave distinta, así que la clave que abre la historia ordinaria no las abre.
  • Relación de comunicaciones. Un paciente puede preguntar con quién se compartió su información en los últimos seis años. El registro de comunicaciones responde a eso desde registros almacenados.
  • Notificación de vulneraciones. Si se expone información de salud protegida, hay que avisar a las personas, salvo que los datos estuvieran debidamente cifrados. Esa exención se llama el puerto seguro, y es la razón de que el cifrado esté construido como está.
  • 42 CFR Part 2 es una regla estadounidense aparte para las historias de tratamiento por consumo de sustancias. Es más estricta que HIPAA y exige una advertencia de reenvío en todo lo que se comparta. La plataforma genera ese aviso en lugar de pedir al personal que lo teclee.
Unión Europea

GDPR

El RGPD es el Reglamento General de Protección de Datos. Se aplica a cualquier organización que maneje datos personales de personas en la Unión Europea. Los datos de salud son lo que el RGPD llama datos de categoría especial, lo que significa que está prohibido tratarlos salvo que se cumpla una condición concreta. Donde HIPAA va sobre todo de protección, el RGPD va también de los derechos de la persona sobre sus propios datos.

  • Una base jurídica para cada tipo de documento. Para las historias de tratamiento la condición correcta es el artículo 9(2)(h), prestación de asistencia sanitaria, no el consentimiento. Un consentimiento que una persona no puede rechazar libremente no es consentimiento válido, y en un entorno asistencial normalmente no puede rechazarlo. La plataforma registra la base contra el tipo de documento, así que después nunca es una conjetura.
  • El derecho de acceso (art. 15). Una persona puede pedir una copia de sus datos, y hay un plazo legal para responder. La solicitud corre como un flujo con seguimiento y ese reloj encima.
  • El derecho de supresión (art. 17). A menudo llamado derecho al olvido. La plataforma lo atiende destruyendo la clave de cifrado en lugar de la fila de la base de datos, así que el contenido desaparece pero queda la prueba de que una historia existió y se eliminó.
  • El derecho a la portabilidad (art. 20). Una persona puede pedir sus datos en una forma que pueda llevarse a otro sitio. La plataforma construye un zip en memoria y lo transmite, y registra uno a uno cada documento que hay dentro.
  • Notificación de vulneraciones (arts. 33 y 34). Hay que avisar al regulador en las 72 horas siguientes a tener conocimiento. También hay que avisar a las personas afectadas, salvo que los datos estuvieran cifrados.
  • Papeleo de gobernanza (arts. 30 y 35). Debe llevar un registro de sus actividades de tratamiento y hacer una evaluación de impacto en la protección de datos para el trabajo de alto riesgo. Los dos viven en el sistema como registros vivos y no como un documento de texto que se queda obsoleto.
Reino Unido

UK GDPR y la DPA 2018

Al salir de la Unión Europea el Reino Unido conservó el RGPD casi sin cambios y lo llama UK GDPR. La Data Protection Act 2018 lo acompaña y añade reglas propias británicas, varias de las cuales importan mucho en sanidad. El regulador es la Information Commissioner's Office, la ICO.

  • Todo lo que exige el RGPD sigue aplicándose. El acceso, la supresión, la portabilidad, la notificación de vulneraciones y los registros de gobernanza son los mismos deberes que en la UE.
  • El criterio de daño grave. Los datos de salud se pueden reservar frente a la solicitud de acceso de la propia persona cuando entregarlos probablemente le causaría un daño grave. Para un servicio de salud mental esto es el equivalente de la excepción estadounidense de las notas de psicoterapia, y el procedimiento a su alrededor es estricto.
  • Los plazos de conservación del NHS. El NHS Records Management Code of Practice 2021 fija cuánto se conservan las historias: en salud mental, 20 años tras el último contacto. Ese calendario se entrega como datos de partida.
  • Access to Health Records Act 1990. Los familiares de una persona fallecida pueden en algunos casos pedir sus historias. El RGPD no cubre en absoluto a las personas fallecidas, así que este es un derecho solo británico con sus propias reglas sobre quién tiene derecho a pedir.
  • Principio Caldicott 7. La guía sanitaria británica dice que el deber de compartir información puede ser tan importante como el deber de protegerla. Bloquearlo todo es su propia clase de fallo, y por eso el acceso de emergencia existe y queda registrado en lugar de estar prohibido.
En qué coinciden los cuatro

Bajo las diferencias, los cuatro regímenes quieren las mismas cinco cosas. Proteger los datos para que una copia robada no sirva. Dejar que los vea solo la gente correcta. Llevar un registro de quién los vio. Conservarlos solo mientras hagan falta y después eliminarlos como es debido. Y poder demostrar las cuatro cosas después. Esa lista común es lo que la plataforma construye una vez en la capa de almacenamiento, para toda instalación. La maquinaria de derechos que va encima es lo que cambia por país, y se entrega como un módulo aparte que usted instala para su jurisdicción.

Nadie está certificado en esto, y quien diga lo contrario le está vendiendo algo

No existe eso de un producto certificado en HIPAA o en el RGPD. Ninguna autoridad emite ese certificado. Lo que existe es una lista de controles técnicos y organizativos. Un software puede implementar los técnicos y hacer que los organizativos sean fáciles de ejecutar y de evidenciar. No puede hacer que una organización cumpla por sí solo. La última sección de esta página expone exactamente qué partes se quedan con usted.

02 — En paralelo

El mismo núcleo técnico en todas partes. Distinta maquinaria de derechos encima

El cifrado, el control de acceso, el registro de auditoría y la conservación son idénticos en cada país. Se construyen una vez, en el núcleo compartido, y toda instalación los tiene. Lo que cambia entre Estados Unidos, la Unión Europea, el Reino Unido, Australia y Canadá es el trabajo de derechos y gobernanza que se apoya sobre ese núcleo. Por eso un sistema construido a un estándar estadounidense no satisface automáticamente el europeo, y por eso cada país llega como su propio módulo instalable.

Las dos últimas columnas llevan las marcas más honestas. Los Australian Privacy Principles piden menos que Europa en dos puntos, y todavía no hay un módulo australiano: la maquinaria de derechos que usa hoy una instalación australiana es el núcleo compartido más partes de los módulos europeo y británico. La página de Australia nombra cada costura.

Canadá es el más reciente, y la única columna donde el reglamento cambia dentro del país. Tampoco hay un módulo canadiense, y una obligación no tiene equivalente en ningún otro sitio de esta tabla: el lockbox, una instrucción del paciente que valla parte de su propia historia dentro del círculo asistencial. La página de Canadá expone qué significa construirlo y qué ley provincial se aplica dónde.

Qué se exige Estados Unidos
HIPAA · 42 CFR Part 2		 Unión Europea
GDPR		 Reino Unido
UK GDPR · DPA 2018		 Australia
Privacy Act 1988 · APP		 Canadá
PIPEDA · PHIPA y las provinciales
Cifrado, control de acceso, registro de auditoría, conservación ✓ núcleo compartido ✓ núcleo compartido ✓ núcleo compartido ✓ núcleo compartido ✓ núcleo compartido
Un motivo legal registrado para guardar cada tipo de documento — HIPAA no funciona así ✓ Art. 9(2)(h) para las historias de tratamiento, no consentimiento ✓ lo mismo, bajo UK GDPR ✓ APP 3.3 y s16B, registrado por tipo de documento § finalidad y consentimiento, no una base jurídica enumerada
Una persona puede pedir una copia de su historia ✓ 45 CFR 164.524, limitado al conjunto designado de historia ✓ Art. 15, con un plazo legal ✓ Art. 15, más el criterio de daño grave ✓ APP 12, un plazo razonable, y sin tasa por pedirlo ✓ PIPEDA principio 9 y PHIPA s. 52: 30 días, prorrogables
Se les puede reservar parte del material ✓ las notas de psicoterapia quedan fuera del conjunto de historia § estrecho, y depende del Estado miembro ✓ criterio de daño grave, ejecutado como un flujo que caduca ◐ existen las causas del APP 12.3; el flujo se entrega con la lista británica ◐ existen las causas de la PHIPA; el flujo se entrega con la lista británica
Una persona puede pedir que se borren sus datos § HIPAA no da un derecho general; decide la conservación ✓ Art. 17, ejecutado destruyendo la clave ✓ lo mismo, con las excepciones británicas § sin derecho general de borrado; el trabajo lo hace la destrucción del APP 11.2 § sin derecho general; el trabajo lo hacen la conservación y la eliminación
Una persona puede llevarse sus datos a otro sitio § a través del derecho de acceso; HIPAA no tiene uno aparte ✓ Art. 20, zip transmitido, cada fichero registrado ✓ lo mismo § sin derecho de portabilidad; lo lleva el derecho de acceso ✓ el derecho de la Law 25 de Québec aterriza en la exportación del RGPD; sin equivalente federal
Un registro de qué se compartió y con quién ✓ seis años, a petición ✓ qué salió, a quién, con qué base ✓ lo mismo ✓ APP 6, qué salió y con qué base ✓ qué salió, a quién, con qué base y por qué
Avisar al regulador y a las personas afectadas tras una vulneración ✓ valoración de cuatro factores, aviso en 60 días, umbrales de medios y de HHS ✓ Arts. 33 y 34, 72 horas, dos relojes, la pregunta de las claves registrada ✓ lo mismo, comunicado a la ICO ✓ esquema NDB: 30 días para valorar, después avisar cuanto antes sea posible ◐ el registro está completo; los dos escritos y el recuento de marzo no se producen
Registros escritos de gobernanza mantenidos al día ✓ registro de políticas, versionado, seis años por versión ✓ evaluación de impacto (art. 35) y registro de tratamientos (art. 30) ✓ lo mismo ✓ APP 1: registro de políticas, registro de riesgos, quejas como registros ✓ registro de políticas, registro de riesgos, quejas como registros
Un calendario de conservación entregado listo para usar ⚙ varía por estado, así que los plazos los fija usted ⚙ varía por Estado miembro, así que los plazos los fija usted ✓ NHS Records Management Code of Practice 2021 ◐ los plazos se conocen a nivel nacional, y no se precarga ninguno ⚙ los fija su colegio, así que no hay un calendario nacional que precargar
Historias de personas fallecidas ⚙ HIPAA las protege 50 años; la regla no se precarga — el RGPD no se aplica a las personas fallecidas ✓ Access to Health Records Act 1990 § la ley federal se detiene con la muerte; NSW protege 30 años después ⚙ las leyes continúan tras la muerte; el plazo es el de su colegio
Protección extra para las historias de consumo de sustancias ✓ 42 CFR Part 2, con el aviso de reenvío — sin regla equivalente — sin regla equivalente — sin regla equivalente — sin regla equivalente
✓ConstruidoEstá ya en el módulo de jurisdicción, y se puede demostrar. ⚙Construido: usted fija el valorEl mecanismo está y la cifra es suya, porque la ley se lo deja a usted o a su estado. No es una carencia. §Ese régimen pide menosNo falta nada. La ley de este país da un derecho más estrecho, o llega al mismo sitio por otro camino. ◐Construido en parteFalta algo de verdad. La página del país nombra exactamente qué. —En ese régimen no existeLa ley sencillamente no contiene este derecho.

Las dos marcas del medio eran una sola hasta hace poco, lo que se leía como una única clase de carencia cuando solo ◐ es una. Un plazo de conservación que usted fija porque lo fija su estado no es una función que falte, y tampoco lo es que HIPAA no dé un derecho que el RGPD sí da.

03 — Qué se protege

Tres clases de datos, y solo una de ellas es ordinaria

No todo en una clínica necesita la misma protección. Si trata cada campo como máximamente sensible, el sistema se vuelve lento e incómodo y el personal empieza a guardar notas en una hoja de cálculo. Ese es el riesgo real de vulneración en casi todas las clínicas. Si no trata nada como sensible, el sistema es simplemente inseguro. Así que la plataforma clasifica los datos en tres clases y aplica la maquinaria pesada solo a la clase que la necesita.

Clase de datosEjemplosCómo se guardaQuién puede alcanzarlo
Datos ordinarios del negocio Datos de contacto, pedidos, facturas, reservas, mensajes de chat En la base de datos, protegidos por las propias reglas de acceso de Odoo El personal cuyo trabajo lo necesita. El propio paciente, a través del portal
Historias clínicas y profesionales Informes de sesión, expedientes de incidentes y de protección, documentos de identidad Como documentos seguros: cifrados versión a versión, guardados fuera del área normal de ficheros Solo el equipo asistencial de ese paciente, por una regla explícita. Ningún cargo lo concede
Registros financieros Facturas, pagos a profesionales, versiones de contrato, asientos contables En el libro contable, que no se puede editar una vez emitido un asiento Finanzas y dirección. Una corrección deja un rastro en lugar de sobrescribir
Por qué la línea se traza en la historia y no en el campo

Cifrar cada campo haría imposible buscar. El personal guardaría entonces sus notas de trabajo en algún sitio fuera del sistema, donde no se registra nada y no se protege nada. Así que la plataforma traza la línea en la clase de historia y no en el campo individual. El material sensible se queda dentro del sistema, donde cada lectura se puede registrar.

04 — El modelo de historia

Cinco cosas que son ciertas de toda historia protegida

Estas cinco son propiedades de cómo se guardan los datos. No son políticas que se pida al personal que siga. Esa diferencia es todo el argumento de esta página. Un control que depende de que la gente se comporte correctamente es un control que no puede demostrar a un revisor. Un control construido dentro del almacenamiento sí puede.

Propiedad uno

Cada versión se cifra por su cuenta

La plataforma usa cifrado de sobre con AES-256-GCM. Eso significa que cada versión de documento recibe su propia clave aleatoria, y esa clave se cierra después con una segunda clave que pertenece a toda la instalación. Esa segunda clave no se guarda nunca en la base de datos.

  • Quien robe una copia de la base de datos y nada más no tiene nada legible
  • Los ficheros cifrados viven fuera del almacén de ficheros ordinario de Odoo y no se sirven nunca por la ruta normal de descarga
  • Rotar la clave de la instalación vuelve a cerrar las claves pequeñas sin reescribir un solo fichero cifrado
  • El software se niega a arrancar si esa clave falta, es legible por todos, pertenece a la cuenta equivocada o está en un sitio desde el que se copiaría junto a los datos que protege
Propiedad dos

Cerrado salvo que una regla lo abra

Cada lectura tiene que encontrar una regla que la permita y ninguna que la prohíba. Esto se comprueba cada vez, no una vez al iniciar sesión. Ser administrador, ser jefe o ser la persona que escribió el documento no concede nada por sí solo.

  • No hay anulación maestra ni vía de superusuario hacia el contenido clínico
  • El acceso sigue al equipo asistencial del paciente, no al organigrama
  • Cuando el personal archiva un documento, antes de guardarlo el cuadro de diálogo le dice en palabras claras quién podrá abrirlo
Propiedad tres

Cada lectura queda escrita

Se registran las aperturas, no solo las ediciones. El registro es de solo anexado y está encadenado por hash, lo que significa que cada entrada está atada matemáticamente a la anterior. Quitar o alterar una entrada rompe la cadena y se hace visible.

  • La entrada se escribe antes de entregar el contenido, no después
  • Nadie puede editarlo ni borrarlo, incluidas las personas que administran el sistema
  • Se puede producir una lista completa de quién abrió una historia para un paciente, un regulador o sus propios abogados
  • Las lecturas del portal tienen un límite de peticiones por usuario, contado desde ese mismo registro, así que el límite se mantiene incluso entre varios procesos de servidor
Propiedad cuatro

Las correcciones añaden, nunca sobrescriben

Cuando algo se corrige, se archiva una versión nueva. La anterior queda exactamente como estaba, incluidos sus metadatos. Una historia que se puede editar en silencio no vale nada como prueba, y un día la suya puede necesitar valer algo.

  • Una solicitud de corrección se añade a la historia en lugar de sustituirla
  • Cada versión lleva su propia clave, así que la eliminación se puede hacer versión a versión
  • Una alteración es por tanto visible en el historial en lugar de algo que haya que deducir
Propiedad cinco

La eliminación destruye la clave

Cuando vence un plazo de conservación, la plataforma destruye la clave de cifrado en lugar de borrar la fila. El contenido queda ilegible para siempre. El envoltorio vacío y el rastro de auditoría se quedan. Esta técnica se llama cripto-borrado.

  • La eliminación se puede demostrar en lugar de meramente afirmarse
  • La prueba de que una historia existió, y de que se eliminó en plazo, sobrevive
  • La conservación se cuenta desde una fecha de anclaje real: último contacto, fecha de nacimiento o fecha de defunción
La carencia deliberada

Lo que no hará, dicho abiertamente

La plataforma no puede buscar dentro de documentos cifrados. Esta es una consecuencia directa del cifrado, no una función que falte. Los documentos se encuentran por a quién se refieren, de qué tipo son y cuándo se archivaron.

  • Se dice aquí porque un proveedor que promete a la vez cifrado fuerte y búsqueda a texto completo del mismo contenido está prometiendo una de las dos cosas en falso
  • Es un servicio de documentos seguros, no una historia clínica electrónica: ni registro clínico, ni mensajería HL7 o FHIR, ni receta electrónica
  • El núcleo no sabe nada de derecho sanitario. Las reglas de cada país llegan como un módulo aparte por encima
05 — Quién puede abrir una historia

El acceso sigue a la relación asistencial, no al cargo

Esta es la idea más importante de la página, y es lo único que un gestor documental corriente no puede expresar. Una relación asistencial es un vínculo registrado entre un clínico y un paciente, con un tipo, una fecha de inicio y una fecha de fin. Una terapeuta alcanza las historias de las personas de su propia carga de casos. No las de la carga de la clínica. Las suyas. Cuando la relación termina, termina el acceso, tras un breve periodo de gracia suficiente para terminar las notas pendientes.

Esto es lo que convierte el «mínimo necesario» de una política en un manual en algo que el software impone de verdad, y en algo que usted puede demostrar en una auditoría.

Qué ocurre en cada lectura

Cinco pasos, cada vez, para cada documento

  1. ¿Quién lo pide?Un usuario con sesión iniciada, resuelto a una persona concreta. No un rol y no un grupo.
  2. ¿Hay una regla que lo permita?Porque es el interesado, porque está en el equipo asistencial, o porque alguien le concedió acceso con nombre. Sin regla, no hay acceso.
  3. ¿Hay una regla que lo prohíba?Una negativa gana siempre a un permiso. Las notas de psicoterapia, los documentos sellados y las historias reservadas rechazan por todas las vías de entrada.
  4. Escribir la entrada del registroAñadida al registro de solo anexado antes de devolver ningún contenido.
  5. Descifrar en memoria y transmitirNo se escribe nada en disco a la salida y no se sirve nada desde el área de ficheros ordinaria.

Qué no le deja entrar

Listado explícitamente, porque los compradores siempre preguntan

  1. Ser administradorUna cuenta de administración no abre por sí sola ningún contenido clínico. No hay puerta trasera para soporte ni para mantenimiento.
  2. Haberlo escrito uno mismoLos expedientes de incidentes y de protección están cerrados incluso para la persona que los archivó, porque se archivan a la dirección de la clínica.
  3. Ser veteranoLos roles clínicos deciden a qué pantallas de la aplicación llega alguien. Nunca deciden qué puede abrir alguien.
  4. Ser el pacienteUn paciente ve una historia sobre sí mismo solo cuando una regla lo concede expresamente. Esa es una decisión clínica y jurídica, tomada a propósito y registrada con el motivo y el nombre de quien la tomó.
  5. Adivinar una referencia de documentoUn documento que usted no puede ver devuelve «no encontrado», nunca «prohibido». Si no, adivinar referencias se convierte en una forma de descubrir quién tiene historias.
El acceso de emergencia existe, y nunca es silencioso

A veces un clínico necesita de verdad una historia con la que no tiene relación: una crisis, una llamada fuera de horario, un compañero que cae enfermo. Si su organización lo permite, hay una vía de acceso de emergencia. Usarla queda registrado como evento y la revisa después el responsable de privacidad.

Ese es el diseño en una frase: el acceso está disponible cuando alguien lo necesita de verdad, y nunca es silencioso. Es deliberado. Un sistema que solo bloquea falla a su manera. La guía británica (Principio Caldicott 7) dice que el deber de compartir puede ser tan importante como el de proteger, y por eso el acceso de emergencia es una función diseñada del núcleo y no un agujero dejado en él.

06 — El núcleo de negocio

Cómo decide Odoo Community quién es usted y qué ve

La maquinaria clínica descrita arriba se apoya sobre Odoo 19 Community, que es el núcleo de negocio de código abierto. Odoo trae su propio modelo de control de acceso, y merece la pena entenderlo, porque es lo que protege los datos ordinarios del negocio: las reservas, las facturas, los contactos y los mensajes que son la mayor parte del sistema.

Esta sección tiene seis partes: las cuatro capas de control de acceso que deciden a qué puede llegar una persona con sesión iniciada; después, el inicio de sesión —contraseñas, doble factor, claves de acceso y las políticas a su alrededor—; luego, qué significa aquí en realidad «basado en roles» , porque la expresión se usa con ligereza en todas partes; el aislamiento de la base de datos; el OWASP Top Ten con la respuesta de Odoo a cada uno; y qué vale de verdad ser código abierto .

Todo lo de abajo viene con Odoo 19 Community. Nada es un complemento de pago, y todo es código legible que su propio equipo de seguridad puede examinar.

El modelo de acceso de Odoo tiene cuatro capas. Cada una responde a una pregunta distinta, y una petición tiene que pasar las cuatro. Se comprueban dentro de la propia capa de datos, que es la parte importante: las mismas comprobaciones se aplican tanto si se llega a una historia por la interfaz web, por la pasarela de la aplicación móvil o por la API remota de Odoo. No hay ninguna vía que las evite.

Capa uno

Grupos: a qué parte del sistema llega

Un grupo es un rol. La pertenencia decide qué menús, pantallas y botones ve siquiera una persona. Los grupos pueden implicar otros grupos, así que un supervisor tiene automáticamente todo lo que tiene un clínico sin que los permisos se escriban dos veces.

  • Los roles de esta instalación incluyen clínico tratante, supervisor, dirección de la clínica, responsable de historias, recepción y responsable de privacidad
  • Recepción es solo demografía: sin contenido clínico y sin ningún tipo de acceso a documentos
  • Un grupo concede alcance, nunca contenido. Tener el rol de clínico no abre por sí solo el expediente de ningún paciente; eso lo hace la relación asistencial
Capa dos

Derechos de acceso al modelo: qué puede hacer con una clase de historia

Para cada tipo de historia y cada grupo, Odoo guarda cuatro permisos separados: leer, crear, editar y borrar. Se declaran en ficheros de texto plano que vienen con cada módulo, así que se pueden leer y revisar sin ejecutar nada.

  • Esta instalación declara 660 entradas de acceso en 35 módulos
  • Todo lo que no está listado se deniega. El acceso se concede nombrándolo, nunca olvidándose de bloquearlo
  • Leer sin editar es común a propósito: muchos roles pueden ver una historia que no deben cambiar
Capa tres

Reglas de registro: a qué historias concretas puede tocar

Una regla de registro es un filtro aplicado a cada consulta. Es lo que hace reales «sus propios pacientes» y «su propia empresa» en lugar de una cuestión de qué pantalla abre alguien. Las reglas globales se aplican siempre. Las reglas ligadas a un grupo amplían el acceso solo para ese grupo.

  • Esta instalación define 117 reglas de registro en los módulos clínico, de reservas, de contratos, de firma electrónica y de informes
  • Ejemplos típicos: un clínico ve las relaciones asistenciales en las que él es el clínico; un usuario del portal ve solo las reservas de su propia ficha de contacto
  • La regla la aplica la capa de datos, así que vale igual para vistas de lista, informes, exportaciones y la API remota
Capa cuatro

Reglas de campo y separación del portal

Campos concretos se pueden restringir a grupos concretos, así que dos personas pueden abrir la misma historia y ver cantidades distintas de ella. Aparte de eso, Odoo mantiene a los usuarios del portal en una clase completamente distinta de la del personal.

  • Un usuario del portal —un paciente o un contacto externo— tiene ningún acceso al back office, solo a las páginas publicadas expresamente para él
  • Las páginas web públicas corren como un usuario anónimo con casi nada concedido, así que un error en una página pública no puede exponer datos del personal
  • Cada ruta de controlador de esta instalación declara si exige un usuario con sesión iniciada o si es pública a propósito: 174 rutas exigen iniciar sesión, 57 son públicas por diseño
Protección del frameworkQué hace OdooQué evita
Construcción de consultasTodas las consultas a la base de datos las construye el framework a partir de filtros estructurados. El código de la aplicación no escribe SQL en crudo para las lecturas y escrituras ordinariasInyección SQL por campos de búsqueda, filtros y parámetros de URL
Escapado de plantillasEl motor de plantillas de Odoo escapa por defecto los valores que pinta en una página. La salida en crudo hay que pedirla expresamenteCross-site scripting, donde el texto que guarda un usuario se ejecuta como código en el navegador de otro
Tokens de formularioLos formularios web que cambian datos llevan un token atado a la sesión del usuario, y el servidor rechaza un envío sin élCross-site request forgery, donde otro sitio web envía en silencio un formulario como su usuario con sesión iniciada
SesionesEl estado de la sesión se guarda en el servidor. El navegador solo guarda un identificador, en una cookie marcada para que los scripts de la página no puedan leerlaRobo de sesión mediante un script que corre en la página
ContraseñasGuardadas solo como hash de un solo sentido, nunca en una forma reversible. El esquema de hash se puede actualizar sin pedirle a nadie que restablezca la suyaQue una tabla de usuarios robada se convierta en una lista de contraseñas utilizables
Gestor de bases de datosLas pantallas que crean, copian, restauran y borran bases de datos enteras están cerradas en producción, y un nombre de servidor se ata exactamente a una base de datosQue quien llegue al servidor encuentre, copie o sobrescriba una base de datos
Operaciones elevadasEl código puede saltarse las reglas de acceso solo donde un desarrollador lo escribió a propósito, para una operación definida, en un sitio con nombre. El contenido clínico no es uno de esos sitiosUna escalada de privilegios amplia y accidental enterrada en el código de la aplicación
Código abiertoOdoo Community se publica bajo una licencia abierta y los addons de esta plataforma son legibles al completo. Odoo publica las correcciones de seguridad y se aplican a su propia instalaciónTener que aceptar por completo y sobre la fe las afirmaciones de seguridad de un proveedor

Iniciar sesión: contraseñas, segundos factores y las políticas a su alrededor

Las cuatro capas de arriba deciden a qué puede llegar una persona con sesión iniciada. Esta es la parte anterior: cómo establece Odoo que alguien es quien dice ser, y qué hace cuando no lo es. Todo ello viene con Odoo 19 Community; nada es un complemento de pago.

ControlEstadoQué hace, y qué decide usted
Las contraseñas se convierten en hash, nunca se guardan ✓ Guardadas como hash PBKDF2-SHA512 con una sal por contraseña y un factor de trabajo configurable. Un hash no se puede convertir de nuevo en contraseña, así que una tabla de usuarios robada no es una lista de accesos. El factor de trabajo se puede subir a medida que el hardware se acelera, y las contraseñas se vuelven a convertir con el ajuste más fuerte la próxima vez que cada persona inicia sesión; a nadie se le pide restablecerla.

Nadie puede leer una contraseña de vuelta, incluidos sus propios administradores y nosotros: el campo se lee siempre como vacío, lo pregunte quien lo pregunte. Si alguien pierde su contraseña la única vía es un restablecimiento, y esa es la respuesta correcta y no una función que falte.
Doble factor de autenticación ⚙ Construido y entregado en toda instalación, usando los códigos estándar de aplicación autenticadora (TOTP) que funcionan con Google Authenticator, Authy, 1Password y el resto. Una persona puede inscribir su propio dispositivo, y los dispositivos de confianza se pueden recordar durante un tiempo.

Usted fija: si es opcional u obligatorio. Un ajuste lo activa para todo el mundo, otro para todas las cuentas del personal , y quien no tenga una aplicación autenticadora recibe en su lugar un código de un solo uso por correo, así que imponerlo no deja a nadie fuera. En una instalación estadounidense esto debería estar activado: se espera bajo la Security Rule y pasa a ser prácticamente obligatorio si la actualización propuesta se aprueba.
El doble factor cierra también la puerta de la API ✓ El detalle que hace que merezca la pena. Una vez que una persona tiene un segundo factor, su contraseña deja de funcionar por completo para el acceso de máquina a máquina : una integración tiene que usar en su lugar una clave de API con nombre. Sin esa regla, el doble factor protege la pantalla de inicio de sesión y deja la puerta trasera abierta, que es como se derrota en la práctica.
Claves de acceso ⚙ Odoo 19 admite claves de acceso: iniciar sesión con una huella, una cara o una llave de hardware en lugar de una contraseña. No se teclea nada susceptible de phishing, así que elimina toda la clase de ataque en la que se convence a alguien de introducir su contraseña en una copia convincente de su página de acceso. Usted decide si lo ofrece.
Claves de API en lugar de contraseñas para las integraciones ✓ Cada integración recibe su propia clave con nombre y su propio alcance, listada contra la persona que la creó y revocable una a una. Una clave que se filtra se apaga sin cambiar la contraseña de nadie y sin romper las demás integraciones.
Política de contraseñas ⚙ Una longitud mínima impuesta en el momento de fijar una contraseña, con un medidor de fuerza mostrado mientras se teclea. Usted fija el mínimo. De fábrica es cero, lo que significa que decidirlo es parte del arranque y no algo que se descubra después.

Deliberadamente no hay ajuste para obligar a clases de caracteres —una mayúscula, un dígito, un símbolo—. Eso no es un olvido. Tanto la investigación como la guía actual del NIST encontraron que esas reglas son contraproducentes: empujan a la gente hacia sustituciones predecibles y hacia apuntar las contraseñas, y aportan menos de lo que aporta la longitud. La combinación que funciona es longitud más un segundo factor.
Protección contra fuerza bruta ✓ Activada por defecto. Tras diez intentos fallidos, todo intento posterior se rechaza durante sesenta segundos contados desde el fallo más reciente, así que un ataque de adivinanza se estrangula a un intento por minuto en lugar de miles. Los dos números son ajustes que un administrador de base de datos puede cambiar (o desactivar, poniendo el primero a cero). Funciona sin que nadie tenga que darse cuenta de que el ataque está ocurriendo.
Reautenticación para acciones sensibles ✓ Cambiar los ajustes de seguridad, inscribir un segundo factor o crear una clave de API pide a la persona que vuelva a demostrar quién es, incluso a mitad de sesión. Una pantalla desatendida no se puede usar para debilitar la cuenta con la que se inició sesión.
Cambiar una contraseña termina todas las sesiones ✓ La validez de la sesión se deriva de la propia cuenta, así que cambiar una contraseña o desactivar una cuenta invalida todas las sesiones existentes en todas partes a la vez: cada navegador, cada dispositivo, de inmediato. Esto es lo que convierte «alguien se ha ido, déjenlo fuera» en una sola acción y no en una esperanza.
Inicio de sesión corporativo, donde lo use ⚙ Odoo puede autenticar contra su directorio existente (LDAP o Active Directory) o contra un proveedor de identidad OAuth2, así que las altas y las bajas se gestionan una vez en el sitio donde su organización ya las gestiona. Opcional, y solo vale la pena si ya tiene uno.
Documentos del portal tras un segundo factor ⚙ Este es nuestro y no de Odoo, y existe porque el acceso de un paciente es el punto más débil de cualquier sistema clínico. Actívelo y un usuario del portal que no haya inscrito un segundo factor podrá seguir iniciando sesión y ver que existen documentos, pero no podrá abrir ninguno hasta que lo haga. Afecta a quienes ya usan el portal, así que avíseles antes de activarlo.
✓Activado por defectoFuncionando desde el momento en que se instala el sistema. ⚙Construido: usted lo activaPresente y soportado. Si se usa, y con qué rigor, es su decisión.

Qué significa aquí en realidad «basado en roles»

Casi todos los sistemas dicen ser basados en roles. La expresión merece desmontarse, porque en casi todos los productos significa que cambia el menú y en Odoo significa que cambian los datos.

En Odoo un rol es un grupo. Los grupos pueden contener otros grupos, así que un supervisor tiene automáticamente todo lo que tiene un clínico sin que nadie escriba los permisos dos veces, y cuando se corrige un permiso se corrige una vez para todos los que lo heredan. Lo que concede un grupo no es una pantalla. Son cuatro permisos separados (leer, crear, editar, borrar) sobre cada clase de historia, más filtros que deciden qué historias de esa clase, más la posibilidad de ocultar campos concretos.

La consecuencia importante: ocultar un menú no es un permiso. En un sistema donde los roles solo cambian el menú, cualquiera que aprenda una dirección web llega a los datos que hay detrás. En Odoo las comprobaciones viven en la capa de datos, así que ocurre la misma negativa tanto si se llega a la historia por una pantalla, un informe, una exportación, una búsqueda o la API remota. No hay ninguna vía que se las salte.

01Los roles llevan el nombre del trabajo

Clínico tratante, supervisor, dirección de la clínica, responsable de historias, recepción, responsable de privacidad, contabilidad, gestor de contratos. Recepción es solo demografía: sin contenido clínico y sin ningún tipo de acceso a documentos.

Responde a«Enséñeme qué puede ver una recepcionista»
02Los roles conceden alcance, nunca contenido

Tener el rol de clínico no abre por sí solo el expediente de ningún paciente. Eso lo hace la relación asistencial. Esta es la frase más importante sobre el acceso en todo el sitio.

Responde a«¿Puede una terapeuta leer todas las historias de la clínica?»
03Cuatro permisos, no uno

Leer, crear, editar y borrar son separados para cada clase de historia. Leer sin editar es común a propósito: muchos roles deben ver algo que no deben cambiar.

Responde a«¿Quién puede cambiar una factura después de emitirla?»
04Los filtros de fila deciden qué historias

«Sus propios pacientes», «su propia empresa», «las reservas que le pertenecen». Aplicados a cada consulta, así que valen igual para listas, informes, exportaciones y la API.

Responde a«¿Qué impide que una exportación se lo lleve todo?»
05Las reglas globales no se pueden ampliar

Una regla que no está ligada a ningún grupo se aplica a todo el mundo y se combina con todas las demás reglas, así que estrecha el acceso y nunca se puede esquivar añadiendo un rol. La separación entre empresas está construida así.

Responde a«¿Puede una clínica ver los datos de otra?»
06Se pueden ocultar campos concretos

Dos personas pueden abrir la misma historia y ver cantidades distintas de ella. Aquí se usa para las cifras de coste y margen, y para los campos que solo debería leer un responsable de historias.

Responde a«¿Todo el que ve un contrato ve su margen?»
07Los pacientes son una clase distinta de usuario

Un usuario del portal no tiene ningún acceso al back office: ni una vista restringida de él, nada. Solo alcanza las páginas publicadas para él. Las páginas web públicas corren como un usuario anónimo con casi nada concedido.

Responde a«¿Cuál es el peor caso si roban el acceso de un paciente?»
08Cada ruta declara su propio acceso

Cada dirección web de esta instalación indica si exige un usuario con sesión iniciada o si es pública a propósito: 174 exigen iniciar sesión, 57 son públicas por diseño. Nada es público por accidente.

Responde a«¿Cuáles de sus URL funcionan sin iniciar sesión?»
09Es todo configuración legible

Los permisos se entregan como ficheros de texto plano dentro de cada módulo. Su propio equipo de seguridad puede leer quién recibe qué sin ejecutar el sistema, y comparar las diferencias entre versiones.

Responde a«¿Podemos auditar los permisos nosotros mismos?»

Una base de datos por clínica, y ninguna vía entre ellas

Sus datos viven en una base de datos propia. No es una tabla compartida con una columna de cliente, que es la disposición en la que una consulta equivocada devuelve las historias de otro.

Odoo impone esa separación en la conexión: una petición lleva un nombre de servidor, el nombre de servidor selecciona exactamente una base de datos, y no hay ningún camino desde dentro de una base de datos a otra que corra en el mismo servidor. Nada en la aplicación puede dirigirse a una base de datos a la que no se conectó. Encima de eso, las pantallas que crean, copian, restauran y borran bases de datos enteras están cerradas en producción, así que nadie que navegue por el servidor puede enumerar lo que hay.

Dentro de su propia base de datos, una segunda capa hace el mismo trabajo entre empresas: si lleva más de una clínica en una instalación, la separación entre empresas está escrita como reglas globales, del tipo que se aplica a todo el mundo y nunca se puede ampliar añadiendo un rol.

El OWASP Top Ten, y dónde está Odoo en cada uno

El Open Web Application Security Project publica la lista de las formas más comunes de entrar en aplicaciones web. Es la lista que recorre un revisor de seguridad, así que aquí está con la respuesta de Odoo a cada una. El patrón que merece notarse es que la mayoría de ellas las evita el diseño del framework y no que los desarrolladores se acuerden de tener cuidado, que es la única clase de prevención que sobrevive al contacto con una fecha de entrega.

El ataqueEstadoPor qué aquí no funciona
Inyección, especialmente inyección SQLentrada hostil tratada como una orden ✓ El código de la aplicación no escribe consultas a mano. Las construye el framework a partir de filtros estructurados, con cada valor pasado por separado de la propia consulta, así que un texto que alguien tecleó nunca puede convertirse en parte de la orden. Un desarrollador tendría que salirse de su camino para escribir una consulta en crudo, y los módulos clínicos no lo hacen.
Cross-site scriptingel texto que guarda una persona se ejecuta como código para otra ✓ Todo lo que se pinta en una página se escapa por defecto. Poner contenido en crudo en una página hay que pedirlo expresamente y se ve en el código cuando se hace. El valor por defecto es seguro, así que olvidarse produce algo feo y no algo peligroso.
Cross-site request forgeryotro sitio envía un formulario como su usuario con sesión iniciada ✓ Cualquier formulario que cambie datos debe llevar un token atado a la sesión de esa persona, y el servidor rechaza un envío sin él. El token existe solo porque la persona cargó de verdad su página, y el sitio de un atacante no puede obtenerlo.
Ejecución de ficheros maliciososconseguir que el servidor ejecute el código que usted suministró ✓ No hay ninguna función que incluya un fichero remoto. Donde los usuarios privilegiados pueden escribir pequeñas expresiones para personalizar el comportamiento, esas corren en un cajón de arena que bloquea el acceso al sistema de ficheros, a la red y a todo lo que empiece por un doble guion bajo: una lista deliberadamente corta de operaciones permitidas en lugar de una lista de prohibidas.
Referencia directa insegura a objetoscambiar un número en una URL para llegar a la historia de otro ✓ Esta es la que atrapa a casi todos los sistemas, y la respuesta de Odoo es estructural: el control de acceso no está implementado en las pantallas. Cambiar un número de historia en una dirección web llega a la misma comprobación de la capa de datos que todo lo demás y allí se rechaza. Que una referencia sea visible no supone riesgo, porque no es la referencia lo que concede el acceso.
No restringir el acceso por URLllegar a una página conociendo su dirección ✓ La misma respuesta, y merece decirse dos veces porque es la diferencia entre un control de acceso real y un menú ordenado. Aquí la seguridad no depende de que un enlace esté escondido. Donde una página realmente tiene que funcionar sin iniciar sesión —un paciente confirmando una cita desde un correo—, la dirección lleva un token firmado único para esa historia y esa persona.
Almacenamiento criptográfico insegurocredenciales protegidas débilmente o nada ✓ Las contraseñas se convierten en hash con PBKDF2-SHA512 y estiramiento de clave, como se describe arriba, y se pueden evitar del todo en local autenticando contra su propio directorio o proveedor de identidad. Los documentos clínicos van aún más lejos: cifrados por versión bajo claves guardadas fuera de la base de datos.
Comunicaciones insegurastráfico enviado en claro ✓ Conexiones cifradas de principio a fin, con las peticiones sin cifrar redirigidas en lugar de servidas, y cabeceras de navegador que rechazan una degradación. Como esta plataforma se aloja por cuenta propia, este es un control de instalación y no una propiedad del software: se configura como parte de una instalación estándar y se describe en la sección 07.
Llegar a lo interno por la APIllamar a algo que nunca se pensó para ser llamado ✓ No está en la lista de OWASP pero merece añadirse, porque es la que la gente supone que es una carencia. La API remota se niega a llamar a cualquier método interno: todo lo que empiece por un guion bajo, más una lista con nombre de los peligrosos. Desde fuera solo se puede llegar a los métodos publicados a propósito, lo que limita drásticamente lo que puede exponer un error en el código de la aplicación.

El código abierto, y qué vale de verdad

«Código abierto» se dice a menudo como si fuera una función de seguridad por sí misma. No lo es. Lo que le da es concreto y merece nombrarse con precisión.

Puede comprobar en lugar de creer

Cada línea de Odoo Community y cada línea de los módulos clínicos las puede leer su propio equipo de seguridad o los auditores que contrate. Los permisos se entregan como ficheros de texto plano. Nada de esta página hay que aceptarlo sobre la fe, que es una posición distinta de la de un producto cerrado donde las mismas afirmaciones solo se pueden asegurar.

Eso es una invitación a auditar, no un sustituto de auditar.

Lo mira mucha más gente

Odoo lo examinan continuamente usuarios, contribuidores e investigadores de seguridad independientes de todo el mundo, y los informes de errores de la comunidad son una fuente real de retroalimentación de seguridad. Odoo lleva un programa de divulgación responsable y publica las correcciones como avisos.

Su propio proceso de desarrollo incluye revisión de código con la seguridad como una de las cosas revisadas, tanto para el código nuevo como para el aportado.

Usted controla cuándo entran los parches

Alojarlo por su cuenta significa que las correcciones de seguridad se aplican a su instalación en su calendario en lugar de aparecer de la noche a la mañana. Eso es una ventaja para un servicio clínico que debe validar los cambios, y es también un deber, porque una corrección que nadie aplica no protege a nadie.

Mantenerse al día está en la lista del operador en la sección 07, y es la forma con diferencia más común de que una instalación por lo demás bien hecha acabe comprometida.

Una distinción que conviene cuidar

Odoo publica una página de seguridad propia, y partes de ella describen el servicio en la nube de Odoo : sus imágenes de servidor endurecidas, su parcheo, el pequeño número de sus ingenieros que pueden alcanzar una máquina y solo con una clave cifrada desde un portátil cifrado. Eso es real, y no suyo, porque esta plataforma está alojada por su cuenta en su propia infraestructura.

Todo lo de esta página por encima de la línea es una propiedad del software y se le aplica exactamente como está escrito. Los equivalentes del lado del servidor —sistema operativo endurecido, parcheo, quién tiene acceso SSH, cifrado de disco completo en las máquinas que lo administran— son suyos de ejecutar, y están expuestos con honestidad en la sección 07, incluidas las partes que corresponden a quien opera los servidores. Leer la página de la nube de Odoo y suponer que describe su instalación es el error más común que se comete sobre Odoo autoalojado, y es de la clase de cosas que se deshilachan en una revisión de diligencia debida.

Dónde termina el modelo de Odoo y empieza el clínico

Las cuatro capas de Odoo son fuertes, están bien probadas y bastan para los datos ordinarios del negocio. No bastan por sí solas para una historia clínica, por una razón: son configuración, y la configuración la puede cambiar alguien con el rol adecuado. Por eso los documentos clínicos se cifran además bajo claves guardadas fuera de la base de datos, y por eso las notas de psicoterapia usan otra clave distinta. Si mañana todas las reglas de Odoo del sistema estuvieran mal, el contenido cifrado seguiría sin abrirse.

07 — El servidor

Cómo se endurece la propia máquina

La seguridad de la aplicación solo cuenta si el servidor de debajo está bien cerrado. La plataforma se aloja por su cuenta, lo que significa que corre sobre infraestructura que usted controla y no sobre la nube de un proveedor. Eso es una ventaja real para un servicio sanitario, y viene con un deber real: el endurecimiento de abajo es parte de la instalación, y después hay que mantenerlo cierto.

Todo lo de la primera tabla se configura como parte de una instalación estándar y está documentado en las guías de instalación. La segunda tabla es la parte que corresponde a quien lleve los servidores.

ÁreaCómo se configuraPor qué se hace así
Nada se expone directamente Los servicios de la aplicación escuchan solo en la propia máquina. Todo el tráfico exterior llega a través de un proxy inverso nginx, que es lo único en un puerto público Una puerta de entrada en lugar de varias. Los certificados, las cabeceras, los límites y el registro se aplican todos en un solo sitio
Cifrado en tránsito Certificados TLS de Let's Encrypt, emitidos y renovados automáticamente. El HTTP plano se redirige a HTTPS en lugar de servirse No hay ninguna vía de entrada sin cifrar, ni siquiera por error, y la renovación no es algo que una persona tenga que recordar
Cabeceras de seguridad del navegador Strict-Transport-Security durante un año, X-Frame-Options en same-origin, X-Content-Type-Options en nosniff El navegador se niega a bajar a HTTP, se niega a dejar que otro sitio enmarque el suyo y se niega a adivinar tipos de fichero
Cortafuegos Solo los puertos 80 y 443 están abiertos al mundo. Los puertos de la aplicación, la base de datos y Redis no son alcanzables desde fuera de la máquina A la base de datos nunca se puede llegar desde internet. Un teléfono está a dos saltos como mínimo de cualquier fila
Límite de peticiones Límites en el proxy para las peticiones entrantes, más cubos de tokens guardados en Redis dentro de la pasarela para las rutas públicas y las lecturas de documentos del portal El proxy detiene las avalanchas. Los contadores de Redis valen entre varios procesos de servidor, así que un límite por usuario significa lo que dice
Un nombre de servidor, una base de datos Odoo está configurado para que el nombre de servidor de la petición seleccione exactamente una base de datos, y las pantallas de gestión de bases de datos están cerradas Nadie que navegue por el servidor puede listar, copiar, restaurar ni borrar una base de datos
Servicios, no consolas La pasarela y Odoo corren como servicios de sistema gestionados bajo sus propias cuentas, arrancados automáticamente y reiniciados si fallan Nada corre como cuenta de administración, y un reinicio no depende de que alguien haya iniciado sesión
Secretos solo en el servidor Las claves de firma y las credenciales de terceros viven en un fichero de entorno legible solo por la cuenta del servicio. La aplicación móvil no lleva ninguna La aplicación se puede desmontar y no se aprende nada. Una credencial rotada surte efecto para todos a la vez, sin publicar una versión de la aplicación
Los documentos cifrados viven aparte El texto cifrado se escribe en su propio directorio con sus propios permisos, fuera del almacén de ficheros ordinario de Odoo, y no se sirve nunca por la ruta de descarga ordinaria Un servidor web mal configurado no puede publicar por accidente ficheros clínicos
La clave maestra se comprueba al arrancar El módulo de cifrado lee la clave desde una ruta propia y se niega a arrancar si el fichero falta, es legible por todos, pertenece a la cuenta equivocada o está dentro de un directorio que se respalda junto a los datos El fallo de clave más común del mundo real es que la clave acabe en la misma copia de seguridad que los datos que protege. El software lo comprueba en lugar de fiarse de un procedimiento
WebSocket por el mismo canal El chat, la presencia y la señalización de llamadas se actualizan a través del mismo proxy y el mismo certificado que todo lo demás Una conexión, una política, ningún segundo escucha al que asegurar por separado
Trazado de peticiones Cada petición lleva un identificador a través de la pasarela y de vuelta en las cabeceras de respuesta, junto con cuánto tardó Un incidente se puede reconstruir entre servicios en lugar de adivinarse desde ficheros de registro separados

El endurecimiento que corresponde a quien lleva los servidores

Estos no son huecos del software. Son decisiones y rutinas que solo puede tomar el operador, y ningún proveedor puede tomarlas por usted. Están listadas sin rodeos para que nadie suponga que están cubiertas.

  • Parcheo del sistema operativo. Un calendario de actualizaciones de seguridad en el anfitrión, y alguien cuyo trabajo sea confirmar que se aplicaron.
  • Cifrado de disco en el anfitrión. Los documentos los cifra la plataforma uno a uno, pero el cifrado de disco completo protege todo lo demás de la máquina, incluidos los registros y los ficheros temporales.
  • Las copias de seguridad, y su cifrado. A dónde van las copias, cómo se cifran, quién puede restaurarlas y cuánto se conservan. Una copia de seguridad es una copia completa de sus datos sin ninguna de sus reglas de acceso adjunta.
  • La clave maestra se respalda por separado. Si se pierde la clave, todos los documentos cifrados se pierden para siempre: ese es el sentido del diseño. Hay que respaldarla, y no hay que respaldarla junto a los datos.
  • Acceso administrativo al servidor. Claves SSH en lugar de contraseñas, sin acceso directo como root, una lista de quién tiene acceso, y quitarlo el día en que alguien se marcha.
  • Pruebas de restauración. Una copia de seguridad que nadie ha restaurado nunca es una esperanza, no un control. Pruébela con un calendario y deje escrito que lo hizo.
  • Supervisión y alertas. Hay que avisar a alguien cuando un servicio se detiene, un disco se llena, un certificado está a punto de caducar o una tarea programada de conservación deja de ejecutarse.
  • Autenticación multifactor para las cuentas del personal. Muy recomendable para todo el que alcance contenido clínico, y prácticamente obligatoria si se aprueba la actualización propuesta de la HIPAA Security Rule. Confirme con su administración si está activada en su instalación.
  • Ubicación en la red. Si la base de datos está en la misma máquina o en otra, qué puede alcanzarla, y si la administración se hace por una red privada o una VPN.
  • Pruebas de penetración. Todo el conjunto es de código abierto y autoalojado precisamente para que sus propios auditores puedan examinarlo como es debido. Eso es una invitación, no un sustituto de hacerlo.
08 — Defensa en profundidad

Cuatro capas, y cada una rechaza algo que la siguiente no llega a ver

Defensa en profundidad significa no depender de ninguna protección aislada. Una petición tiene que pasar las cuatro capas de abajo. El valor no está en que romper alguna de ellas sea imposible. Está en que fallan de maneras distintas, así que un error en una es muy poco probable que sea un error en las cuatro.

1 · Dispositivo y superficie Lo que una persona tiene en la mano No fiable
Ningún secreto en el dispositivoLa aplicación solo lleva claves públicas. Se puede desmontar y no se aprende nada.
Acceso biométrico y bloqueo de la aplicaciónEncima del bloqueo de pantalla del propio teléfono, no en su lugar.
Tokens en almacenamiento seguroGuardados en el llavero de la plataforma, no en ficheros ordinarios de la aplicación.
A la base de datos no se llegaLa aplicación no puede dirigirse a la base de datos en absoluto, en ninguna red.
HTTPS · token de vida corta
2 · Pasarela El único backend que la aplicación conoce Guarda los secretos
Cada clave de terceros vive aquíLas credenciales de pago, de IA, de mensajería y de almacenamiento no salen nunca del servidor.
Tokens firmados de vida cortaCada uno lleva para quién es, cuándo se emitió, cuándo caduca y un identificador único. Se renuevan en lugar de durar mucho.
Hash de contraseñasDe un solo sentido, y el esquema se puede actualizar sin un restablecimiento.
Límite de peticionesContadores guardados en Redis, compartidos entre todos los procesos de servidor.
Validación de la entradaLas peticiones mal formadas se rechazan aquí, antes de que el núcleo de negocio las vea siquiera.
Enlaces firmados que caducanLos medios pasan por el proxy. No se sirve nada desde una dirección que usted pudiera adivinar.
cuenta de servicio · mínimo privilegio
3 · Núcleo de negocio Donde viven de verdad las reglas Fuente autorizada
Grupos, derechos de acceso y reglas de registroLas cuatro capas de Odoo, aplicadas se llegue a la historia como se llegue.
Resolución del equipo asistencialEl único sitio que decide quién puede abrir una historia clínica.
Roles clínicosDeciden a qué parte de la aplicación llega alguien. Nunca qué puede abrir.
Un libro que no se puede editarUna factura emitida es fija. Una corrección es una factura rectificativa.
Versiones de contrato con fechaLas condiciones no se pueden fechar hacia atrás y el historial se queda.
cifrado en reposo · claves guardadas aparte
4 · Almacenamiento y claves Lo que sobrevive a un disco robado Criptografía
Directorio de texto cifradoFuera del almacén de ficheros, fuera de la base de datos, con permisos propios.
La clave maestraEn disco, propiedad de la cuenta del servicio, nunca en la misma copia de seguridad que los datos.
Una segunda clave para las notas de terapiaLa clave ordinaria no las abre, digan lo que digan las reglas.
Registro de auditoría encadenado por hashSolo anexado. La manipulación se detecta, no solo se desaconseja.
09 — Práctica del sector sanitario

Los controles por los que pregunta específicamente un revisor clínico

De cualquier sistema se esperan cortafuegos y cifrado. Los nueve de abajo son los que salen en particular en una revisión de salud mental, y los que un gestor documental de propósito general no puede expresar en absoluto. Cada uno está escrito con la pregunta que responde, porque suele llegar así.

01Relaciones asistenciales

Un vínculo registrado entre un clínico y un paciente, con un tipo, un inicio y un fin. Cuando la relación termina termina también el acceso, tras un periodo de gracia suficiente para terminar las notas pendientes.

Responde a«¿Cómo imponen ustedes el mínimo necesario?»
02Archivar a la dirección

Los incidentes, las quejas y las derivaciones de protección van a la dirección de la clínica y están cerrados tanto para quien los archivó como para aquel sobre quien va la queja.

Responde a«¿Puede un empleado leer la queja sobre sí mismo?»
03Los derechos como flujos de trabajo

Las solicitudes de acceso llevan su plazo legal. Las solicitudes de corrección añaden una versión en lugar de sobrescribir. Las solicitudes de restricción sellan los documentos que abarcan.

Responde a«Enséñeme una solicitud de acceso del interesado de principio a fin»
04Registro de comunicaciones

Qué salió del servicio, a quién y con qué base jurídica. Este es el registro del que una persona tiene derecho a pedir seis años en Estados Unidos.

Responde a«¿Con quién han compartido los datos de esta persona?»
05Anclajes de conservación

El último contacto, la fecha de nacimiento y la fecha de defunción se guardan como fechas desde las que contar, porque una regla escrita en años no significa nada sin un punto de partida.

Responde a«¿Cómo saben cuándo eliminar esto?»
06Perseguir por estado, nunca por contenido

Los informes de sesión atrasados se encuentran por su plazo y su estado. Un gestor puede ver que falta un informe sin abrir uno que no falta.

Responde a«¿Los gestores leen notas clínicas para llevar la clínica?»
07Comprobación de identidad y de edad

Primero una comprobación facial automática, después una cola de revisión humana si hace falta. Los documentos de identidad se cifran mientras se guardan y se borran automáticamente en cuanto termina la comprobación.

Responde a«¿Qué pasa después con el documento de identidad?»
08Firma electrónica clínica

Constancia de capacidad, firma en nombre de un paciente, cofirma del supervisor, y un consentimiento que se puede retirar después en lugar de ser una casilla de una sola vez.

Responde a«¿Cómo se recoge el consentimiento, y se puede retirar?»
09La firma se queda en casa

El servicio de firma corre en sus propios servidores con su propio rastro encadenado por hash. Ningún documento se manda a una empresa externa para firmarse, y no hay factura de proveedor por firma.

Responde a«¿Qué terceros ven nuestros documentos firmados?»
10 — Si algo sale mal

Dos plazos desde un mismo momento, y una exención que hay que ganarse

El cifrado tiene la forma que tiene en gran medida por esta sección. Tanto el RGPD como HIPAA aceptan que un dato debidamente cifrado es ilegible y, por tanto, no es realmente una comunicación. Pero esa exención solo se sostiene si puede demostrar que las claves no se llevaron también. Todo el diseño de custodia de claves existe para que pueda demostrarlo.

Tener conocimiento

Los dos plazos de abajo empiezan en el momento en que usted tiene conocimiento, no en el momento en que ocurrió el incidente. Eso hace que fijar y registrar ese momento sea lo primero que hace, en lugar de algo reconstruido después.

Avisar al regulador

El artículo 33 del RGPD le da 72 horas desde el conocimiento para notificar a la autoridad de control: la ICO en el Reino Unido, la autoridad nacional correspondiente en la Unión Europea. Este plazo se aplica estuvieran o no cifrados los datos.

Avisar a las personas afectadas

El artículo 34 exige avisar también a las personas, salvo que los datos estuvieran cifrados. El artículo 34(3)(a) trata un dato debidamente cifrado como ilegible para quien se lo llevó. HIPAA tiene la misma idea y la llama el puerto seguro.

¿Se llevaron también las claves?

La exención depende por completo de esta única pregunta, así que el sistema la hace expresamente y una pregunta sin responder cuenta en contra de la exención. Cerrar una vulneración como no notificable exige las pruebas, porque una exención alegada sin pruebas es una que se derrumba al examinarla.

Un registro de vulneración, compartido, con las reglas de cada país encima

El propio registro de la vulneración está en el núcleo compartido: cuándo tuvo conocimiento, qué estuvo implicado, a quién afectó, si los datos estaban cifrados y si se llevaron las claves. Cada módulo de jurisdicción añade después sus propios deberes sobre ese mismo registro. El módulo europeo añade el plazo de 72 horas del artículo 33 y la decisión del artículo 34. El módulo estadounidense añade la valoración de riesgo de cuatro factores, el plazo de 60 días para las personas, el umbral de medios por encima de 500 residentes de un estado, y el aviso al Departamento de Salud y Servicios Humanos. Un incidente, valorado una vez, contra las reglas que le apliquen.

El registro de accesos es la investigación

Como cada lectura se registró antes de entregar ningún contenido, la pregunta «¿qué se expuso realmente y a quién?» tiene una respuesta real y no una estimación. Esa es la diferencia entre avisar a once personas y avisar a todas las de la base de datos.

11 — Controles de la plataforma

Las preguntas corrientes, respondidas en un solo sitio

Nada de esta tabla es inusual. Está aquí porque un revisor lo va a preguntar, y porque un proveedor que no puede responder esto rápido normalmente tampoco puede responder lo difícil.

ÁreaQué hay implantadoPor qué se hace así
Inicio de sesiónContraseñas guardadas solo como hash de un solo sentido. Tokens firmados de vida corta que llevan quién es el usuario, cuándo se emitió el token, cuándo caduca y un identificador únicoUn token robado caduca solo, y el hash se puede actualizar sin pedirle a nadie que restablezca su contraseña
Custodia de secretosCada credencial de terceros vive en el servidor. La aplicación móvil solo lleva claves públicasLa aplicación se puede descompilar y no se pierde nada. Rotar una clave surte efecto para todos los usuarios a la vez, sin publicar en la tienda de aplicaciones
TransporteHTTPS en todas partes, incluido el WebSocket usado para el chat, la presencia y la señalización de llamadasUna conexión, una política, y ninguna caída a texto plano
Límite de peticionesLímites en el proxy, más contadores en Redis en las rutas públicas y en las lecturas de documentos del portalContados desde un estado compartido, así que un límite por usuario vale para todos los procesos de servidor y no por proceso
MediosPasan por la pasarela con enlaces firmados que caducan. No se sirve nada desde una ruta adivinableUn dispositivo cliente no se dirige nunca directamente al almacenamiento
Base de datosNo alcanzable desde ningún cliente. La pasarela se conecta al núcleo a través de una cuenta de servicio con solo los derechos que necesitaDos saltos separados entre un teléfono y una fila, cada uno con su propia oportunidad de rechazar
Formularios públicosreCAPTCHA en los formularios del sitio web, y números de teléfono normalizados al introducirseEl correo basura y la entrada mal formada se rechazan antes de convertirse en registros que alguien tenga que limpiar
Adivinar referenciasUn documento que usted no puede ver devuelve «no encontrado», nunca «prohibido»Si no, la diferencia entre las dos respuestas le dice a un atacante qué historias existen
Cuentas de pacientesLos usuarios del portal no tienen ningún acceso al back office. El doble factor viene con la plataforma y se puede hacer obligatorio para todo el personal, o para todo el mundo, con un solo ajuste, y el acceso a documentos del portal se puede poner detrás de élEl peor caso de un acceso de paciente comprometido son los propios datos de ese paciente y, con la puerta del portal activada, ni siquiera eso
Exposición a tercerosLos pagos, la inteligencia artificial, la mensajería y el almacenamiento están cada uno detrás de una interfaz con una versión simulada al otro lado de un interruptorLos proveedores se pueden cambiar. Las demostraciones y las pruebas corren sin ninguna cuenta real de proveedor y sin ningún dato real
Licencias y alojamientoOdoo 19 Community y componentes de código abierto de principio a fin, corriendo sobre su propia infraestructuraSu propio equipo de seguridad puede leer el código en lugar de fiarse de la palabra de un proveedor
12 — Qué puede demostrar

La diferencia entre un control y una promesa

En una auditoría, un concurso o una queja, lo que importa no es qué pretendía. Es qué puede demostrar. Abajo están las seis preguntas que salen más a menudo y lo que el sistema produce como respuesta a cada una.

¿Quién leyó esta historia?Registro de accesos
Una lista completa y encadenada por hash que nadie podría haber editado, incluidos sus propios administradores
¿Se alteró esta historia?Historial de versiones
Las correcciones son versiones nuevas y la anterior queda intacta, así que un cambio se ve en lugar de deducirse
¿Se destruyeron los datos vencidos?Destrucción de la clave
La clave ya no está, y el envoltorio vacío de la historia prueba que el fichero existió y se eliminó en plazo
¿Con quién lo compartimos?Registro de comunicaciones
Qué salió del servicio, a quién y con qué base jurídica, seis años de ello y a petición
¿Pudo haberlo visto un administrador?Modelo de autorización
Cerrado por defecto y sin anulación maestra. Una cuenta de administración no concede nada, y el acceso de emergencia es un evento registrado y revisado
¿Es fiable el libro contable?Controles financieros
Las facturas emitidas no se pueden editar, las líneas de pago llevan la versión de contrato que las valoró, y nada se factura sin que una persona lo confirme
13 — Dónde termina el software

Lo que ninguna plataforma puede hacer por usted

El software no hace que una organización cumpla. Hace que el cumplimiento sea alcanzable y hace posible demostrarlo. Ser franco sobre esa frontera vale más en una revisión que una lista más larga de afirmaciones, así que aquí está la frontera al completo.

Esto no es asesoramiento jurídico, y ningún producto está certificado

Nada de esta página es asesoramiento jurídico. Ningún producto de software está certificado en HIPAA ni en el RGPD, porque ninguna autoridad emite esos certificados para productos. Lo que existe es un conjunto de controles técnicos y organizativos. Esta plataforma implementa los técnicos y soporta los organizativos. El resto corresponde a su organización, y un buen asesor le dirá exactamente lo mismo.

  • Los acuerdos son suyos de firmar. Los business associate agreements en Estados Unidos, los contratos de encargo de tratamiento y las condiciones de subencargo en la UE y el Reino Unido. La plataforma los modela. No los firma por usted.
  • Sus abogados confirman el texto. El aviso de reenvío del 42 CFR Part 2 se genera en lugar de teclearse, precisamente para que no se desvíe con el tiempo. Pero la norma prescribe su contenido, y necesita revisión jurídica antes de que usted arranque.
  • El derecho local va más allá del mínimo. Las leyes estatales estadounidenses —la CMIA de California, y las reglas de Nueva York y Texas entre otras— van más allá de HIPAA. En la UE, el derecho del Estado miembro se suma al RGPD: el §203 StGB y el §630f BGB alemanes son ejemplos. Los plazos de conservación en particular deben confirmarse con abogados de su propio país.
  • El comportamiento del personal no es un control de software. La formación, las altas y las bajas, el procedimiento disciplinario y a quién se le da una relación asistencial para empezar son decisiones que el sistema registra pero no toma.
  • La seguridad física y de infraestructura es del operador. Dónde están los servidores, quién puede acercarse a ellos, cómo se cifran y se guardan fuera de sitio las copias de seguridad, cómo se custodia la clave maestra, y la prueba de recuperación ante desastres que de verdad ejecuta en lugar de la que está en el plan.
  • Las pruebas de penetración y la gestión de vulnerabilidades son un programa, no una función. Todo el conjunto es de código abierto y autoalojado para que su propio equipo o los auditores que contrate puedan examinarlo como es debido. Eso es una invitación, no un sustituto.
  • Las organizaciones que trabajan con el NHS completan el Data Security and Protection Toolkit. Esa evaluación va sobre su organización y su gente, y queda fuera del alcance de cualquier software.
  • Alguien tiene que vigilar el motor de conservación. La conservación y la eliminación corren como tareas programadas. Una tarea programada que deja de ejecutarse en silencio es un problema de cumplimiento que solo sale a la luz en una auditoría, y por eso comprobarlo está en la rutina mensual.
La página entera en un párrafo, para un revisor con prisa

Las historias clínicas se cifran versión a versión, bajo claves guardadas fuera de la base de datos. Se abren solo cuando una regla explícita lo permite, y esa regla sigue a la relación asistencial y no a la antigüedad. Cada lectura se escribe en un registro que nadie puede editar. Las correcciones se añaden como versiones nuevas en lugar de sobrescribir la anterior. Cuando vence la conservación se destruye la clave, lo que hace el contenido ilegible mientras deja la prueba de que existió y de que se eliminó. Sobre ese mismo núcleo, un módulo de jurisdicción añade la maquinaria de derechos y gobernanza de Estados Unidos, la Unión Europea o el Reino Unido. Debajo, el modelo de acceso de cuatro capas de Odoo Community protege los datos ordinarios del negocio, y el servidor está cerrado detrás de un único proxy con TLS, un cortafuegos y límites de peticiones.

14 — Adónde ir ahora

El resto del cuadro

Esta página es la posición de seguridad y cumplimiento. La visión general muestra cómo encajan las piezas, el catálogo lista los módulos en los que viven de verdad estos controles, y el plano de administración cubre la rutina que mantiene ciertas todas estas pruebas mes a mes.

La máquinaVisión general del sistemaCuatro capas, y dónde están de verdad los secretos y las historias. ReferenciaCatálogo de módulosLos módulos de documentos seguros, historias clínicas y firma electrónica al completo. PlanoAdministraciónEl expediente de cumplimiento, las comprobaciones de conservación y la revisión trimestral. PlanoPacienteQué se le cuenta a un paciente sobre sus propias historias, y qué puede pedir.