Privacy Policy

1. Who we are, and each party's role

For Life is a product of SCZ Labs LLC, an entity organised in the State of Wyoming, United States of America. It is licensed by subscription to individually practising doctors; it is not an institutional clinic or hospital system.

The most important distinction in this whole document is who answers for the medical record:

• The doctor is responsible for the medical record. The doctor decides what is recorded, who may see it and how long it is kept, and it is the doctor — not us — who owes medical confidentiality under Bolivian law (Ley 3131 on the practice of medicine, the Code of Medical Ethics of the Colegio Médico de Bolivia, and article 302 of the Penal Code, which punishes disclosure of professional secrets).
• SCZ Labs LLC is the software vendor. We process patient data on the doctor's behalf and on the doctor's instructions, in order to provide the service and for nothing else. We are not the custodian of the doctor-patient relationship, we make no clinical decisions, and we have no contractual relationship with patients.

It follows that a patient who wishes to see, correct or obtain a copy of their record must approach their doctor, who holds it. We cannot identify a patient or answer such a request on our own; we do assist the doctor in answering it.

2. What data For Life processes

• Professional account data. Full name, email address, role, and professional licence number (matrícula — required, as it identifies the prescriber on every prescription under D.S. 25235); optionally specialty, medical college and SEDES registration, a phone number, and whether we may contact the user on WhatsApp. The password itself is never stored: only its cryptographic derivation (scrypt).
• Patient data, entered by the doctor. National ID (cédula de identidad), name, sex, date of birth, phone, email and address; insurance type and provider; an emergency contact (the name, relationship and phone number of the person to call); background (allergies, chronic conditions, current medication, impairments, notes); a record of consent; and for each encounter: reason, clinical notes, diagnosis, treatment, vital signs, prescriptions with their medications, dosage and instructions, and follow-up date.
• Audit trail. Every sign-in, every read and every change to clinical data, and every denied access attempt, is recorded with the acting user, the action, the identifier of the affected record and the timestamp. The trail is append-only: the application cannot alter or delete it, and a rule in the database itself rejects any attempt. It holds no clinical text and no patient names — only identifiers.
• Operational technical data. Active sessions (stored as a cryptographic fingerprint of the session token, never the token itself), failed sign-in counters that slow brute-force attacks, and server logs. Logs pass through a filter that suppresses fields capable of carrying patient data.
• Product usage events. We record, from the server only, facts such as “an encounter was recorded” or “a patient was created”, together with the acting user's identifier and role and nothing more. No patient data travels with them, no visited addresses, no form content. There is no analytics code in the browser at all: the application loads no third-party JavaScript, sets no analytics or advertising cookies, and takes part in no advertising network.
• File attachments: disabled. The deployment running today does not allow file uploads (X-rays, PDFs, images). File storage is switched off in the deployment configuration, so no patient file is stored by us at all.

Every piece of clinical data reaches us because a doctor typed it. We do not buy data, obtain it from third parties, or enrich it from outside sources.

3. What we use the data for

• Providing the service: displaying, searching, recording and printing the doctor's own records and prescriptions.
• Authenticating the user, maintaining the session and allowing password recovery.
• Recording who did what (the audit trail), which is both a security measure and a protection for the doctor.
• Operating and maintaining the system: diagnosing faults, restoring backups, preventing abuse.
• Understanding which features are used, through the product events described above, which contain no patient data.
• Contacting the doctor about their account, their subscription or a security incident.

We do not sell data. We do not disclose it for commercial or advertising purposes. We do not use it to train artificial-intelligence models. We do not profile patients.

4. Cookies and browser storage

For Life uses the minimum necessary, and no analytics, advertising or third-party cookies:

• forlife_session — the signed-in session. A random value marked httpOnly, secure and SameSite=Lax; it expires after 30 days and also after a period of inactivity. The application cannot be used without it.
• forlife_sidebar, NEXT_LOCALE — presentation preferences: sidebar collapsed or expanded, and chosen language.
• forlife_gcal_state — a short-lived cookie that protects the Google connection against cross-site request forgery. It is deleted as soon as the connection completes.
• Browser local storage. The light/dark theme, and drafts of half-written forms so that a reload or a crash does not cost a doctor a clinical note. Drafts live on the doctor's own device, expire after 24 hours, and are deleted on save, on sign-out, and when a different user signs in on the same browser. They are never sent to us except when the encounter is saved.

5. Google Calendar: what Google user data we use

The Google Calendar integration is optional, ships disabled, and only becomes active when a doctor connects their own Google account and grants consent on Google's screen. Each doctor connects their own; there is no shared account.

These are the scopes we request and what each one is used for. We request no others:

How we access that data, and what we do with it:

• Access. Each time the doctor opens the Calendar tab, the server asks Google for the events in the date range being viewed and displays them. No process reads the calendar in the background or outside a request the doctor made.
• Use. Solely to draw that agenda and to carry out the creations, edits and deletions the doctor requests. Google user data is not used for advertising, is not sold, is not disclosed, does not feed analytics, and is not used to train artificial-intelligence models.
• Storage. No calendar event is stored in our database: not its title, description, location or times. All we store is the access credential (the OAuth tokens, encrypted with AES-256-GCM under a key held outside the database), the connected Google account's email address, the identifier and time zone of the chosen calendar, the scopes actually granted, and the connection date. When the doctor books a follow-up from the encounter form we additionally store the opaque identifier of the created event — a pointer, not a copy — so that the same event can be moved if the date changes.
• Disclosure. We share Google user data with no one. It travels only between the doctor's browser, our server and Google. We transfer it to no other app and to none of the providers listed below.
• Not even to our own people. Nobody on our team reads a doctor's calendar. This feature's audit records store the event identifier and a fixed description of the action, never the title, description or location; the adapter that talks to Google never logs response bodies; and nothing calendar-related is sent to the product-events tool.

There is one fact you should know that no design can avoid: what the doctor types into an event does go to Google, because that is what a calendar is. In particular, when the doctor ticks “Book in Google Calendar” while saving an encounter, the created event carries the patient's name in its title and the patient's internal identifier in a private property of the event. It is an optional checkbox decided at each save, and it does exactly what a doctor already does when writing a patient's name into their own diary by hand. Even so, that name never reaches our audit trail, our logs, or the product-events tool.

How to revoke access: under “My account → Google Calendar”, the Disconnect button revokes the grant with Google and immediately deletes the row holding the credentials. Access can also be revoked directly at https://myaccount.google.com/permissions. Events already created stay in the doctor's calendar, because they belong to the doctor.

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.

The policy referred to above is published at https://developers.google.com/terms/api-services-user-data-policy

6. Where the data is stored, and who else is involved

We do not claim that we never share data with third parties, because that would not be true: providing the service relies on the infrastructure providers listed below, each with a narrow role. This is the complete list:

In addition, SCZ Labs technical personnel may access the systems where necessary to operate them, fix a fault or restore a backup. That access is subject to a duty of confidentiality, is exceptional, and is not routine access to medical records.

Any change to this list of providers will be published on this page before that provider begins processing patient data.

7. Records are stored outside Bolivia

Medical records entered into For Life are stored on servers located in the United States of America (Oregon), not in Bolivia. This is a material fact and the doctor should tell their patients.

To make that easy we publish a short plain-language notice the doctor can print, display or adapt: https://forlife.sczlabs.dev/en/patient-notice

As a consequence of that location, the data is subject to United States law, including the possibility that a competent authority of that country compels its production by valid order. Should we receive such a demand, and unless we are legally forbidden to say so, we would notify the affected doctor.

8. Applicable legal framework, and what we do not claim

As at the date of this policy, Bolivia has no comprehensive data protection statute in force. The applicable framework is the constitutional right to privacy and the privacy protection action (habeas data) of article 130 of the Constitution, together with the sector rules on medical records and medical secrecy cited above.

We would rather be precise about what we are not:

• We do not claim HIPAA compliance. HIPAA is a United States statute binding covered entities in that country; a doctor practising in Bolivia is not one, and we do not sign business associate agreements (BAAs).
• We do not claim compliance with the EU GDPR or Brazil's LGPD. We do not direct the service at data subjects in the European Union or Brazil. Were that to change, we would adapt the service and this policy before doing so.
• We hold no security certifications. We are not ISO 27001 certified, we have no SOC 2 report, and we have not yet had an independent penetration test.

We say this because a false compliance claim would itself be the violation, and because a doctor deserves to know exactly which assurances they have and which they do not.

9. Security measures, and their limits

What is in place today:

• All traffic is encrypted with TLS, with HSTS enabled. The database provider encrypts data at rest at the storage layer.
• Per-doctor isolation: every use case checks on the server that the user has rights over the patient before reading or writing; a guessed identifier grants nothing.
• The application connects to the database as a least-privilege role that cannot alter the schema or delete audit records. Every table has row-level security denied by default for the provider's automatic data API.
• An append-only audit trail, guaranteed by a rule inside the database itself.
• Passwords derived with scrypt under versioned parameters; session and password-reset tokens stored only as HMACs, so a database dump cannot be turned into a working sign-in or a working reset link.
• Google OAuth tokens encrypted with AES-256-GCM, with the key held outside the database.
• Rate limiting on sign-in attempts and on password-reset requests.
• Security headers on every response: HSTS, nosniff, no referrer, and a ban on framing the site. The content security policy (CSP) is deployed in report-only mode while we finish rolling it out, so today it observes and reports rather than blocks.
• The application loads no third-party JavaScript in the browser.

What is not there yet, and you should know it:

• There is no second-factor authentication (2FA) yet.
• There is no field-level encryption of clinical text: protection at rest is the database provider's.
• There has been no external penetration test and no third-party certification yet.

No set of measures makes a system invulnerable, and we do not promise that it is. Should a security incident affecting patient data occur, we will notify the affected doctor without undue delay, with what we know and what we are doing about it, so that they can meet their own professional duties.

10. Retention, export and deletion

• While the subscription is active, we keep the complete medical record. The doctor is subject to the retention periods Bolivian rules on medical records impose on them, and it is the doctor who decides what to keep.
• On termination of the subscription, the doctor may ask us for an export of their data in a machine-readable format. We keep the data available for 30 days from termination so that export can be requested, and delete it from active systems within the following 60 days, unless the law requires us to keep it.
• Backups. Deleted data disappears from backups as those backups rotate on their normal cycle; we do not edit backups retroactively.
• Audit trail. It is retained, being append-only. It contains no clinical text and no names — only identifiers, actions and timestamps.
• Sessions and tokens. Sessions expire after 30 days, or sooner through inactivity; password-reset links expire after 30 minutes and are deleted once used.

11. Patients' and doctors' rights

A patient exercises their rights — to see their record, obtain a copy, request a correction — with their treating doctor, who holds the record and can identify them. The Bolivian Constitution additionally recognises the privacy protection action (habeas data) of article 130.

The doctor may at any time see and correct their account data under “My account”, export their data, and request deletion of their account by writing to enrique@sczlabs.dev. We will also act on requests the doctor passes to us on behalf of one of their patients.

12. Data concerning minors

For Life is not directed at minors as users: an account always belongs to a professional. It may of course contain the records of patients who are minors, entered by their doctor. The legal basis for that record and the relationship with those holding parental authority are the treating doctor's responsibility, and such data receives exactly the same treatment as any other patient's.

13. Changes to this policy

We may update this policy. The date of last update heads the page. Where a change is material — a new provider, a new purpose, a new category of data — we will tell the doctor by email or inside the application before it takes effect.

14. Contact

Write to enrique@sczlabs.dev with any question about this policy, to exercise a right, or to report a security problem. Controller: SCZ Labs LLC. Registered address: 30 North Gould Street, Suite R, Sheridan, Wyoming 82801, United States of America. Service: https://forlife.sczlabs.dev