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. That permission is a consent held on record for a channel that is not in operation: For Life sends no WhatsApp messages. 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, the member identifier and the policy number; 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, study orders with the name of the study requested, the clinical indication justifying it and whether it is still outstanding, and follow-up date. When the doctor drops a patient from their follow-up list, the reason they write for doing so is also stored, against that patient and the 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); the IP address a sign-in or a password-reset request is made from, held in the clear alongside the failure counter for that address and for the email address used, in order to slow brute-force attacks and abuse of the reset form; and server logs. Logs pass through a filter that suppresses fields capable of carrying patient data.
• Files attached to a consultation. The doctor can attach studies and images to a consultation — ultrasounds, lab results, X-rays, reports — as JPG, PNG or PDF. The files are held in a private Cloudflare R2 bucket restricted to the United States; the database keeps only their description: name, type, size and the consultation they belong to. No public address serves them: opening one requires a signed-in session and permission over that clinical record, and every opening is written to the audit trail.
• Billing data. The plan, the subscription's status and its period; and, where it is a plan granted at no charge by SCZ Labs, who granted it and the internal note justifying it. If the doctor also takes out a paid plan, we keep the identifiers Stripe assigns to the customer, the subscription, the invoice and the charge; the amount, the currency, the invoice number and the links to the invoice hosted at Stripe; for each payment attempt, the card's brand, its last four digits, the country it was issued in and the reason the bank declined it, if it did; and the billing event exactly as Stripe sends it to us, which includes the billing address the doctor typed on Stripe's page. The full card number and its security code are not here, nor anywhere else in For Life: they are entered on a Stripe page and do not pass through our systems. A plan granted at no charge produces none of what Stripe assigns, because it never reaches Stripe.

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. Nor do we measure product usage: there is no analytics of any kind, neither in the browser nor on the server, we set no analytics or advertising cookies, and we take part in no advertising network.

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.
• Contacting the doctor about their account, their subscription or a security incident.
• Charging for and administering the subscription: recording the plan taken out and its status, processing the payment, issuing the invoice, and handling a declined charge.
• Enforcing the limits of the plan: we count, per doctor, the patients registered and the bytes their attached files occupy, and the application refuses an operation that would go past the maximum their plan allows.

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_mfa — the ticket for a sign-in that has cleared the password and is waiting on the second factor. It is issued on every sign-in to an account with two-step verification, is marked httpOnly, covers the whole site, and expires after 10 minutes. It is not a session, and no part of the application accepts it as one.
• 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, and the adapter that talks to Google never logs response bodies.

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 or our logs.

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:

Beyond those providers, whoever operates the system must be counted too. For Life has an administrator role, held by the SCZ Labs engineer who builds and operates the product; it is granted to no one else. From the ordinary application, that role sees the patient list of every doctor and can open their medical records. It is a technical capability inherent in operating the system, not a permission exercised as a matter of course: it is used when operating the service requires it, typically to help a doctor with a problem in their own data, and for no other reason. That access is subject to a duty of confidentiality.

Two things bound it, and both can be checked in the system. Every read by the administrator is written to the audit trail exactly as any other user's is — with their user identifier, the patient concerned and the timestamp — in an append-only trail that they cannot alter or delete either. And the administrator account is required to use two-step verification, with no option to postpone it, where for every other account it is optional.

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

The medical record is not the only thing that leaves Bolivia. Billing data for a paid plan is processed and kept at Stripe, and account email is sent through Resend; both providers operate under United States jurisdiction. The application itself runs on Cloudflare's global network, at the location nearest whoever is using it.

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. At rest, the database provider encrypts data at the storage layer, and attached files are encrypted with AES-256 in the Cloudflare R2 bucket — automatically, with no way to switch it off, metadata included.
• 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 enforced, so the browser refuses any script or origin the site does not declare.
• The only third-party JavaScript the browser loads is Cloudflare Turnstile's anti-bot widget, and only on the two anonymous screens: sign-in and password recovery. There is no analytics, no advertising, and no other external script.
• Two-step verification available on every account: a passkey (fingerprint, face or device PIN) or a code app. It is required for administrator accounts and optional for the rest; the secrets are stored encrypted or as irreversible hashes, never in the clear.

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

• Two-step verification is optional for clinician accounts, so an account that does not turn it on is still protected by its password alone.
• 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.
• Attached files. They follow the rest of the clinical record: exported with it and deleted with it, on the same timetable. The doctor can also delete an attached file from within the application: doing so removes both the file and its record, permanently and with no way to recover it. The deletion is noted in the audit trail — who did it, against which encounter and when — which keeps neither the file's name nor its contents.
• 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.
• Anti-abuse counters. Each row holds one key — the email address used, or the IP address — and its count of failed attempts. It is deleted as soon as a sign-in or a reset completes successfully from that same key. Rows that never reach a success, such as an attacker's or those of a reset request nobody finishes, have no automatic purge: they stay in the table until they are removed by hand. We state no period here because the system applies none.

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”. Exporting their data and deleting their account are handled in writing: they are not features of the application — no button in it performs either — but requests we prepare by hand when the doctor asks at 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