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. Esa autorización es un consentimiento que queda guardado para un canal que hoy no está en operación: For Life no envía ningún mensaje 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, aseguradora, código de asegurado y número de póliza; 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, órdenes de estudio con el nombre del estudio pedido, la indicación clínica que lo justifica y si sigue pendiente, y fecha de control. Cuando el médico retira a un paciente de su lista de seguimiento, se guarda además el motivo que escribe para hacerlo, asociado a ese paciente y a la fecha.
• 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); la dirección IP desde la que se intenta iniciar sesión o se pide un restablecimiento de contraseña, guardada en claro junto al contador de intentos fallidos de esa dirección y del correo empleado, para frenar ataques de fuerza bruta y el abuso del formulario de restablecimiento; y registros técnicos (logs) del servidor. Los logs pasan por un filtro que suprime los campos que podrían contener datos de pacientes.
• Archivos adjuntos a una consulta. El médico puede adjuntar estudios e imágenes a una consulta — ecografías, laboratorios, radiografías, informes — en formato JPG, PNG o PDF. Los archivos se guardan en un depósito privado de Cloudflare R2 restringido a los Estados Unidos; en la base de datos queda únicamente su descripción: nombre, tipo, tamaño y la consulta a la que pertenecen. No existe ninguna dirección pública que los sirva: para abrir uno hay que tener sesión iniciada y permiso sobre esa historia clínica, y cada apertura queda asentada en el registro de auditoría.
• Datos de facturación. El plan, el estado de la suscripción y su período; y, si es un plan otorgado sin cargo por SCZ Labs, quién lo concedió y la nota interna con la que se justificó. Si además el médico contrata un plan de pago, guardamos los identificadores que Stripe asigna al cliente, a la suscripción, a la factura y al cobro; el importe, la moneda, el número de factura y los enlaces a la factura alojada en Stripe; de cada intento de cobro, la marca de la tarjeta, sus cuatro últimos dígitos, el país donde se emitió y el motivo por el que el banco lo rechazó, si lo hubo; y el evento de facturación tal como Stripe nos lo envía, que incluye la dirección de facturación que el médico escribió en la página de Stripe. El número completo de la tarjeta y su código de seguridad no están aquí ni en ninguna otra parte de For Life: se ingresan en una página de Stripe y no pasan por nuestros sistemas. Un plan otorgado sin cargo no genera nada de lo que Stripe asigna, porque no pasa por Stripe.

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. Tampoco medimos el uso del producto: no hay analítica de ninguna clase, ni en el navegador ni en el servidor, no instalamos cookies de analítica ni de publicidad, y no participamos en ninguna red publicitaria.

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.
• Comunicarnos con el médico sobre su cuenta, su suscripción o un incidente de seguridad.
• Cobrar y administrar la suscripción: registrar el plan contratado y su estado, procesar el pago, emitir la factura y atender un cobro rechazado.
• Aplicar los límites del plan: contamos, por médico, los pacientes registrados y los bytes que ocupan sus archivos adjuntos, y la aplicación rechaza la operación que superaría el máximo que su plan permite.

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_mfa — el resguardo de un inicio de sesión que ya superó la contraseña y espera el segundo factor. Se emite en todo inicio de sesión de una cuenta con verificación en dos pasos, está marcada httpOnly, alcanza a todo el sitio y caduca a los 10 minutos. No es una sesión y ninguna parte de la aplicación la acepta como tal.
• 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, y el adaptador que habla con Google no registra los cuerpos de respuesta.

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.

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 de esos proveedores, hay que contar a quien opera el sistema. For Life tiene un rol de administrador, y lo ocupa el ingeniero de SCZ Labs que construye y opera el producto; no se otorga a nadie más. Desde la aplicación corriente, ese rol ve la lista de pacientes de todos los médicos y puede abrir sus historias clínicas. Es una capacidad técnica inherente a operar el sistema, y no un permiso que se ejerza de rutina: se usa cuando la operación lo exige, típicamente para ayudar a un médico con un problema en sus propios datos, y no para leer historias por ninguna otra razón. Ese acceso está sujeto a deber de confidencialidad.

Dos cosas lo acotan, y ambas son verificables en el sistema. Cada lectura del administrador queda asentada en el registro de auditoría exactamente igual que la de cualquier otro usuario — con su identificador de usuario, el paciente afectado y la fecha y hora —, en un registro de sólo agregado que él tampoco puede modificar ni borrar. Y la cuenta de administración exige verificación en dos pasos de forma obligatoria, sin posibilidad de posponerla, mientras que para el resto de las cuentas es opcional.

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

La historia clínica no es lo único que sale de Bolivia. Los datos de facturación de un plan de pago se tratan y se conservan en Stripe, y los correos de la cuenta se envían a través de Resend; ambos proveedores operan bajo jurisdicción de los Estados Unidos. La aplicación, por su parte, se ejecuta sobre la red global de Cloudflare, en el nodo más cercano a quien la está usando.

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. En reposo, el proveedor de base de datos cifra la información a nivel de almacenamiento, y los archivos adjuntos se cifran con AES-256 en el depósito de Cloudflare R2 — de forma automática y sin que nadie pueda desactivarlo, incluidos sus metadatos.
• 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á en vigor, así que el navegador rechaza cualquier script u origen que el sitio no declare.
• El único JavaScript de terceros que carga el navegador es el widget antibots de Cloudflare Turnstile, y sólo en las dos pantallas anónimas: inicio de sesión y recuperación de contraseña. No hay analítica, ni publicidad, ni ningún otro script externo.
• Verificación en dos pasos disponible para toda cuenta: passkey (huella, rostro o PIN del dispositivo) o aplicación de códigos. Es obligatoria para las cuentas de administración y opcional para el resto; los secretos se guardan cifrados o como resúmenes irreversibles, nunca en claro.

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

• La verificación en dos pasos es opcional para las cuentas médicas, así que una cuenta que no la active sigue protegida sólo por su contraseña.
• 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.
• Archivos adjuntos. Corren la misma suerte que el resto de la historia clínica: se exportan con ella y se eliminan con ella, en los mismos plazos. Además, el médico puede eliminar un archivo adjunto desde la propia aplicación: al hacerlo se borran tanto el archivo como su registro, de forma definitiva y sin posibilidad de recuperarlo. La eliminación queda anotada en el registro de auditoría —quién la hizo, sobre qué consulta y cuándo—, que no conserva el nombre ni el contenido del archivo.
• 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.
• Contadores antiabuso. Cada fila guarda una clave —el correo empleado o la dirección IP— y su cuenta de intentos fallidos. Se borra en cuanto un inicio de sesión o un restablecimiento se completa con éxito desde esa misma clave. Las filas que nunca llegan a un éxito, como las de quien ataca o las de una solicitud de restablecimiento que nadie termina, no tienen purga automática: permanecen en la tabla hasta que se eliminen a mano. No fijamos aquí un plazo porque el sistema no aplica ninguno.

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». La exportación de sus datos y la eliminación de su cuenta se atienden por escrito: no son funciones de la aplicación —no hay en ella ningún botón que las ejecute— sino solicitudes que preparamos a mano cuando el médico las pide 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