Política de Privacidad

1. Quiénes somos y qué papel cumple cada parte

For Life es un producto de SCZ Labs LLC, una entidad constituida en el Estado de Wyoming, Estados Unidos de América. Se licencia por suscripción a médicos que ejercen de forma individual; no es un sistema institucional de clínica ni de hospital.

La distinción más importante de todo este documento es quién responde por la historia clínica:

• El médico es el responsable de la historia clínica. Es quien decide qué se registra, quién accede y por cuánto tiempo se conserva, y es sobre él — no sobre nosotros — que pesa el secreto profesional médico en Bolivia (Ley 3131 del Ejercicio Profesional Médico, el Código de Ética y Deontología Médica del Colegio Médico de Bolivia, y el artículo 302 del Código Penal, que sanciona la revelación de secreto profesional).
• SCZ Labs LLC es el proveedor del software. Tratamos los datos de los pacientes por cuenta del médico y siguiendo sus instrucciones, para prestarle el servicio y para nada más. No somos el custodio de la relación médico-paciente, no tomamos decisiones clínicas y no tenemos relación contractual con los pacientes.

En consecuencia, un paciente que quiera consultar, corregir o pedir copia de su historia clínica debe dirigirse a su médico, que es quien la tiene a su cargo. Nosotros no podemos identificar a un paciente ni atender esa solicitud por nuestra cuenta; sí asistimos al médico para que la atienda.

2. Qué datos trata For Life

• Datos de la cuenta del profesional. Nombre completo, correo electrónico, rol y número de matrícula profesional (obligatorio, pues identifica al prescriptor en cada receta conforme al D.S. 25235); opcionalmente especialidad, colegio médico, registro SEDES, teléfono y si autoriza que le escribamos por WhatsApp. La contraseña nunca se guarda: se guarda su derivación criptográfica (scrypt).
• Datos de pacientes, registrados por el médico. Cédula de identidad, nombre, sexo, fecha de nacimiento, teléfono, correo y dirección; tipo de seguro y aseguradora; contacto de emergencia (nombre, parentesco y teléfono de la persona a quien llamar); antecedentes (alergias, enfermedades crónicas, medicación habitual, discapacidades, notas); registro de consentimiento; y por cada consulta: motivo, notas clínicas, diagnóstico, tratamiento, signos vitales, recetas con sus medicamentos, dosis e indicaciones, y fecha de control.
• Registro de auditoría. Cada inicio de sesión, cada lectura y cada modificación de datos clínicos, y cada intento de acceso denegado, quedan asentados con el usuario que actuó, la acción, el identificador del registro afectado y la fecha y hora. Este registro es de sólo agregado: la aplicación no puede modificarlo ni borrarlo, y una regla en la propia base de datos rechaza cualquier intento. No contiene texto clínico ni nombres de pacientes: sólo identificadores.
• Datos técnicos de funcionamiento. Sesiones activas (guardadas como huella criptográfica del testigo de sesión, nunca el testigo mismo), contadores de intentos fallidos de inicio de sesión para frenar ataques de fuerza bruta, y registros técnicos (logs) del servidor. Los logs pasan por un filtro que suprime los campos que podrían contener datos de pacientes.
• Eventos de uso del producto. Registramos, únicamente desde el servidor, hechos como «se registró una consulta» o «se creó un paciente», acompañados sólo del identificador del usuario que actuó y de su rol. No viajan datos de pacientes, ni direcciones visitadas, ni contenido de formularios. No hay ningún código de analítica en el navegador: la aplicación no carga JavaScript de terceros, no instala cookies de analítica ni de publicidad, y no participa en ninguna red publicitaria.
• Archivos adjuntos: desactivados. La versión desplegada hoy no permite subir archivos (radiografías, PDFs, imágenes). El almacenamiento de archivos está apagado en la configuración del despliegue, de modo que no existe ningún archivo de paciente guardado por nosotros.

Todo dato clínico llega a nosotros porque un médico lo escribió. No compramos datos, no los obtenemos de terceros y no los enriquecemos con fuentes externas.

3. Para qué usamos los datos

• Prestar el servicio: mostrar, buscar, registrar y imprimir historias clínicas y recetas del propio médico.
• Autenticar al usuario, sostener su sesión y permitirle recuperar su contraseña.
• Dejar constancia de quién hizo qué (registro de auditoría), que es a la vez una medida de seguridad y una garantía para el médico.
• Operar y mantener el sistema: diagnosticar fallas, restaurar copias de seguridad, prevenir abusos.
• Entender qué funciones se usan, mediante los eventos de producto descritos arriba, que no contienen datos de pacientes.
• Comunicarnos con el médico sobre su cuenta, su suscripción o un incidente de seguridad.

No vendemos datos. No los cedemos con fines comerciales o publicitarios. No los usamos para entrenar modelos de inteligencia artificial. No perfilamos pacientes.

4. Cookies y almacenamiento en el navegador

For Life usa el mínimo indispensable, y ninguna cookie de analítica, de publicidad o de terceros:

• forlife_session — la sesión iniciada. Es un valor aleatorio, marcado httpOnly, secure y SameSite=Lax; caduca a los 30 días y también tras un período de inactividad. Sin ella no se puede usar la aplicación.
• forlife_sidebar, NEXT_LOCALE — preferencias de presentación: menú lateral contraído o expandido, e idioma elegido.
• forlife_gcal_state — cookie temporal que protege la conexión con Google contra falsificación de petición (CSRF). Se borra en cuanto termina la conexión.
• Almacenamiento local del navegador. El tema claro/oscuro, y borradores de formularios a medio escribir para que una recarga o un corte no le hagan perder una nota clínica. Los borradores viven en el equipo del médico, expiran a las 24 horas, se borran al guardar, al cerrar sesión y cuando otro usuario entra en el mismo navegador. Nunca se envían a nosotros salvo al guardar la consulta.

5. Google Calendar: qué datos de Google usamos

La integración con Google Calendar es opcional, viene desactivada y sólo se activa cuando un médico conecta su propia cuenta de Google y otorga su consentimiento en la pantalla de Google. Cada médico conecta la suya; no hay una cuenta compartida.

Estos son los permisos (scopes) que solicitamos y para qué se usa cada uno. No pedimos ninguno más:

Cómo accedemos a esos datos y qué hacemos con ellos:

• Acceso. Cada vez que el médico abre la pestaña Calendario, el servidor pide a Google los eventos del rango de fechas que está mirando y los muestra. No hay ningún proceso que lea su calendario en segundo plano ni fuera de una petición suya.
• Uso. Únicamente para dibujar esa agenda y para ejecutar las creaciones, ediciones y eliminaciones que el médico solicita. Los datos de Google no se usan para publicidad, no se venden, no se ceden, no alimentan analítica y no se usan para entrenar modelos de inteligencia artificial.
• Almacenamiento. Ningún evento de calendario se guarda en nuestra base de datos: ni su título, ni su descripción, ni su lugar, ni sus horarios. Lo único que guardamos es la credencial de acceso (los testigos OAuth, cifrados con AES-256-GCM bajo una clave que vive fuera de la base de datos), el correo de la cuenta de Google conectada, el identificador y la zona horaria del calendario elegido, los permisos efectivamente concedidos y la fecha de conexión. Cuando el médico agenda un control desde el formulario de consulta, guardamos además el identificador opaco del evento creado — un puntero, no una copia — para poder mover ese mismo evento si la fecha cambia.
• Divulgación. No compartimos datos de Google con nadie. Circulan sólo entre el navegador del médico, nuestro servidor y Google. No los transferimos a ninguna otra aplicación ni a ningún otro proveedor de los listados más abajo.
• Ni el personal humano. Nadie de nuestro equipo lee el calendario de un médico. Los registros de auditoría de esta función guardan el identificador del evento y una descripción fija de la acción, nunca el título, la descripción ni el lugar; el adaptador que habla con Google no registra los cuerpos de respuesta; y nada relacionado con el calendario se envía a la herramienta de eventos de producto.

Hay un dato que debe conocer y que ningún diseño puede evitar: lo que el médico escribe en un evento sí llega a Google, porque eso es lo que es un calendario. En particular, cuando el médico marca la casilla «Agendar en Google Calendar» al guardar una consulta, el evento creado lleva el nombre del paciente en el título y su identificador interno en una propiedad privada del evento. Es una casilla opcional que se decide en cada guardado, y hace exactamente lo mismo que ya hace un médico cuando escribe a mano el nombre de su paciente en su agenda. Ese nombre, aun así, nunca llega a nuestro registro de auditoría, ni a nuestros logs, ni a la herramienta de eventos de producto.

Cómo revocar el acceso: desde «Mi cuenta → Google Calendar», el botón Desconectar revoca la autorización ante Google y borra de inmediato la fila con las credenciales. También puede revocarla directamente en https://myaccount.google.com/permissions. Los eventos ya creados permanecen en el calendario del médico, porque son suyos.

El uso y la transferencia por parte de For Life de la información recibida de las API de Google se ajustará a la Política de Datos de Usuario de los Servicios de API de Google, incluidos los requisitos de Uso Limitado (Limited Use).

En el texto original en inglés, tal como lo exige Google: «For Life's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements». La política puede consultarse en https://developers.google.com/terms/api-services-user-data-policy

6. Dónde se guardan los datos y quién más interviene

No decimos que no compartimos datos con terceros, porque no sería cierto: para prestar el servicio nos apoyamos en los proveedores de infraestructura que se listan a continuación, cada uno con un papel acotado. Ésta es la lista completa:

Además, las personas técnicas de SCZ Labs pueden acceder a los sistemas cuando es necesario para operarlos, corregir una falla o restaurar una copia de seguridad. Ese acceso está sujeto a deber de confidencialidad, es excepcional y no es un acceso rutinario a historias clínicas.

Publicaremos en esta página cualquier cambio en la lista de proveedores antes de que empiece a tratar datos de pacientes.

7. Los historiales se guardan fuera de Bolivia

Las historias clínicas registradas en For Life se almacenan en servidores ubicados en los Estados Unidos de América (Oregón), no en Bolivia. Es un hecho material y el médico debería informarlo a sus pacientes.

Para facilitarlo publicamos un aviso breve, en lenguaje llano, que el médico puede imprimir, mostrar o adaptar: https://forlife.sczlabs.dev/patient-notice

Como consecuencia de esa ubicación, los datos quedan sujetos a la legislación estadounidense, incluida la posibilidad de que una autoridad competente de ese país los requiera mediante orden válida. Si recibiéramos un requerimiento de ese tipo, y salvo prohibición legal de informar, lo notificaríamos al médico afectado.

8. Marco legal aplicable, y lo que no afirmamos

A la fecha de esta política, Bolivia no cuenta con una ley general de protección de datos personales en vigor. El marco aplicable es el derecho constitucional a la privacidad y la acción de protección de privacidad (habeas data) del artículo 130 de la Constitución Política del Estado, junto con las normas sectoriales sobre historia clínica y secreto médico ya citadas.

Preferimos decir con precisión lo que no somos:

• No declaramos cumplimiento de HIPAA. HIPAA es una norma estadounidense que obliga a entidades cubiertas de ese país; un médico que ejerce en Bolivia no lo es, y no firmamos acuerdos de asociado comercial (BAA).
• No declaramos cumplimiento del RGPD europeo ni de la LGPD brasileña. No dirigimos el servicio a titulares en la Unión Europea ni en Brasil. Si eso cambiara, adecuaríamos el servicio y esta política antes de hacerlo.
• No tenemos certificaciones de seguridad. No estamos certificados en ISO 27001, no tenemos informe SOC 2 y no hemos realizado todavía una prueba de intrusión independiente.

Decimos esto porque una afirmación de cumplimiento falsa sería en sí misma una infracción, y porque un médico merece saber exactamente qué garantías tiene y cuáles no.

9. Medidas de seguridad, y sus límites

Lo que está implementado hoy:

• Todo el tráfico viaja cifrado con TLS, con HSTS activo. El proveedor de base de datos cifra la información en reposo a nivel de almacenamiento.
• Aislamiento por médico: cada caso de uso comprueba, en el servidor, que el usuario tenga derecho sobre el paciente antes de leer o escribir; un identificador adivinado no da acceso.
• La aplicación se conecta a la base de datos con un rol de mínimo privilegio, que no puede alterar la estructura ni borrar registros de auditoría. Todas las tablas tienen seguridad a nivel de fila denegada por defecto para la API automática del proveedor.
• Registro de auditoría de sólo agregado, garantizado por una regla en la propia base de datos.
• Contraseñas derivadas con scrypt con parámetros versionados; testigos de sesión y de restablecimiento guardados sólo como HMAC, de modo que un volcado de la base de datos no permite iniciar sesión ni restablecer una contraseña.
• Testigos OAuth de Google cifrados con AES-256-GCM, con la clave fuera de la base de datos.
• Limitación de intentos de inicio de sesión y de solicitudes de restablecimiento de contraseña.
• Cabeceras de seguridad en cada respuesta: HSTS, nosniff, sin referente, y prohibición de enmarcado del sitio. La política de contenido (CSP) está desplegada en modo de sólo reporte mientras completamos su despliegue, por lo que hoy observa y registra pero no bloquea.
• La aplicación no carga JavaScript de terceros en el navegador.

Lo que todavía no está, y conviene que sepa:

• No hay todavía autenticación de segundo factor (2FA).
• No hay cifrado a nivel de campo del texto clínico: la protección en reposo es la del proveedor de base de datos.
• No hay todavía prueba de intrusión externa ni certificación de terceros.

Ninguna medida hace un sistema invulnerable, y no prometemos que lo sea. Si llegara a producirse un incidente de seguridad que afecte a datos de pacientes, lo notificaremos al médico afectado sin demora indebida, con lo que sepamos y lo que estemos haciendo, para que pueda cumplir sus propios deberes profesionales.

10. Conservación, exportación y eliminación

• Mientras la suscripción esté vigente, conservamos la historia clínica completa. El médico está sujeto a los plazos de conservación que le impone la normativa boliviana sobre historia clínica, y es él quien decide qué conservar.
• Al terminar la suscripción, el médico puede pedirnos una exportación de sus datos en formato legible por máquina. Mantenemos los datos disponibles durante 30 días desde la terminación para permitir esa exportación, y los eliminamos de los sistemas activos dentro de los 60 días siguientes, salvo que la ley exija conservarlos.
• Copias de seguridad. Los datos eliminados desaparecen de las copias de seguridad a medida que éstas se rotan según su ciclo normal; no las editamos retroactivamente.
• Registro de auditoría. Se conserva por ser de sólo agregado. No contiene texto clínico ni nombres: sólo identificadores, acciones y fechas.
• Sesiones y testigos. Las sesiones caducan a los 30 días o antes por inactividad; los enlaces de restablecimiento de contraseña caducan a los 30 minutos y se eliminan al usarse.

11. Derechos de los pacientes y de los médicos

El paciente ejerce sus derechos — acceder a su historia, pedir copia, solicitar corrección — ante su médico tratante, que es quien tiene la historia a su cargo y quien puede identificarlo. La Constitución boliviana reconoce además la acción de protección de privacidad (habeas data) del artículo 130.

El médico puede, en cualquier momento, acceder y corregir los datos de su cuenta desde «Mi cuenta», exportar sus datos y pedir la eliminación de su cuenta escribiendo a enrique@sczlabs.dev. Atenderemos también las solicitudes que nos traslade en nombre de un paciente suyo.

12. Datos de menores de edad

For Life no está dirigido a menores de edad como usuarios: la cuenta es siempre de un profesional. Sí puede contener historias clínicas de pacientes menores, registradas por su médico. La base legal de ese registro y la relación con quienes ejercen la tutela son responsabilidad del médico tratante, y esos datos reciben exactamente el mismo tratamiento que los de cualquier otro paciente.

13. Cambios en esta política

Podemos actualizar esta política. La fecha de última actualización encabeza la página. Cuando el cambio sea sustancial — un proveedor nuevo, una finalidad nueva, un tipo de dato nuevo — avisaremos al médico por correo electrónico o dentro de la aplicación antes de que entre en vigor.

14. Contacto

Escriba a enrique@sczlabs.dev para cualquier consulta sobre esta política, para ejercer un derecho o para reportar un problema de seguridad. Responsable: SCZ Labs LLC. Domicilio: 30 North Gould Street, Suite R, Sheridan, Wyoming 82801, United States of America. Servicio: https://forlife.sczlabs.dev