Privacy Policy

[[TODO: registered legal entity name]] operates Flow Health, software that clinics and practitioners use to document patient encounters and prepare and submit medical billing claims.

The clinic or practitioner using Flow Health is the custodian of the patient information in their workspace. They decide what is collected, why, who may see it, and how long it is kept. We are a service provider: we handle that information on the custodian's instructions and to deliver the service. The one thing we do for ourselves is keep aggregated, de-identified operational statistics — figures that cannot identify a patient, practitioner, or clinic — to operate and improve the service; see “Why we handle it” below. We do not sell personal information, and we do not use patient information to market anything.

If you are a patient, the clinic that treated you is your first point of contact for questions about your record, including requests to see or correct it. This policy explains what we do with that information on the clinic's behalf.

We handle personal information in accordance with Canada's Personal Information Protection and Electronic Documents Act (PIPEDA) and, for clinics in British Columbia, the Personal Information Protection Act (BC PIPA). Clinics also carry their own professional and provincial health-record obligations, which flow down to us through the agreement between us.

What we hold depends on which parts of the service a clinic uses.

Patient and clinical information

• Patient identity and demographics: name, Personal Health Number or similar identifier, date of birth, and the sex or gender information a claim requires.
• Encounter information: the date and time of a visit, the clinical sections a practitioner records, and the notes written or drafted in them.
• Billing information: fee items, diagnostic codes, service dates, claim notes, submission results, and remittance outcomes.
• Documents and images uploaded to support a claim or an encounter, including patient face sheets processed to extract fields.
• Encounter audio recorded through the in-app dictation and scribe features, the transcripts produced from it, and the draft documentation and coding suggestions generated from those transcripts.

Account and workspace information

• Practitioner and staff account details: name, email address, and the practitioner or billing profile a user maintains.
• Workspace membership and role, and the access decisions that follow from them.
• Sign-in and session information, including authentication tokens issued to keep a user signed in.
• Interface settings and preferences.

Operational information

• Audit records of significant actions taken in the service (see audit records).
• Technical logs used to run and troubleshoot the service. These are restricted by an allowlist to non-identifying values such as counts, statuses, and record identifiers.

We handle information to:

• create, review, and manage clinical documentation and billing claims;
• transcribe encounter audio and produce draft documentation and coding suggestions for a practitioner to review;
• extract information from uploaded documents so it does not have to be retyped;
• submit claims to, and retrieve remittance results from, the provincial billing system;
• operate workspaces, accounts, roles, and access control, and provide notifications and service status;
• keep the audit records that let a custodian review who accessed what;
• secure the service, investigate incidents, and provide support;
• produce aggregated, de-identified operational statistics — usage volumes, error rates, and processing times that cannot identify a patient, practitioner, or clinic — to operate and improve the service; and
• meet legal, regulatory, and record-keeping obligations.

We collect only what the service needs for these purposes. Free-text search terms and patient identifiers are never placed in web addresses, so they do not appear in browser history or server request logs.

Canadian data residency is a design requirement of this product, and most of it is enforced in the software itself rather than by policy alone. The following are configured to Canadian regions, and the service is built to check those regions when it starts and to reject a setting that points elsewhere:

• the backend application that handles every read and write of clinical information, and the background jobs it runs — Montréal;
• stored documents, uploaded images, encounter audio, and billing artifacts — Montréal or Toronto;
• AI processing of clinical content and speech-to-text transcription of encounter audio — Montréal.

Two components are not covered by that guarantee, and we would rather say so plainly than claim more than we can support:

• The database and authentication service. The managed database that holds the clinical record, together with the authentication service, runs in [[TODO: confirm managed database and auth region]].
• Web application delivery and sign-in. The hosting provider that serves the web application and processes the sign-in callback is not pinned to a Canadian region, and may run outside Canada. It handles account and session information: session cookies, sign-in codes, and the identity and workspace-membership checks that decide where a signed-in user is sent. Clinical information does not pass through it: the browser sends and receives clinical content directly to and from the Canadian backend.

Account and session information is personal information even though it is not a clinical record, so this is a genuine cross-border transfer. Information stored outside Canada may be accessible to foreign courts and law-enforcement agencies under the laws of that country.

We use a small number of service providers to run Flow Health. Each is bound to handle information only as needed to provide its service.

Claims are submitted to, and remittance results retrieved from, Teleplan, the British Columbia Ministry of Health's billing system. Teleplan is the payer's system rather than our service provider: information sent to it is handled under the Ministry's own rules.

We do not use analytics, advertising, crash-reporting, or product telemetry services. No third-party tracking code runs in the application.

[[TODO: confirm and publish the signed data-processing agreements with each service provider above]]

Flow Health uses automated processing in four places: transcription of encounter audio, drafting of clinical note text from a transcript, suggestion of billing and diagnostic codes, and extraction of fields from uploaded documents.

Everything these features produce is a draft for a person to review. A note becomes part of the record only when a practitioner reviews and signs it, and a claim is submitted only when a person submits it. No clinical or payment outcome is decided automatically.

Transcription and AI processing run in Google Cloud in a Canadian region, using the configuration described above. Content is sent to these services in the form it is needed for the task, which means clinical content and patient identifiers may be included; it is not de-identified beforehand.

[[TODO: confirm and state the AI and speech provider terms covering use of content for model training and provider-side retention]]

On the mobile applications, scanning a patient identification sticker is performed entirely on the device by the operating system. The photograph is not sent to us or to any third party for that step.

While a recording is in progress, short audio fragments are sent for transcription so the transcript keeps pace with the visit. Those fragments are deleted from storage once they have been transcribed. Recordings a practitioner chooses to keep are retained as part of the encounter.

Access control

• All clinical information is read and written through our backend, which checks identity, workspace membership, and role on every request. Browser code never queries clinical tables directly.
• The database independently denies access to every table as a second layer, so a mistake in one layer does not open the other.
• Workspaces are separated structurally: every record carries its workspace, and records are linked by compound keys so a reference across two workspaces cannot be formed.
• Access follows role — workspace owner, practitioner, billing administrator, or staff. Patient charts default to being visible only to the practitioners assigned to them; a workspace owner can widen this to a clinic-wide model, and the change is recorded in the audit trail.

Accounts and sessions

• Accounts are created by invitation only. There is no public sign-up.
• Our production authentication configuration requires passwords of at least twelve characters that combine upper and lower case letters, digits, and symbols.
• The web application signs a user out after thirty minutes of inactivity, with a warning two minutes beforehand.
• Sensitive actions, such as changing billing credentials, require the user to have authenticated within the previous fifteen minutes.
• A user can revoke all of their own active sessions, and our production authentication configuration rotates refresh tokens on use.

Transmission and storage

• All traffic is encrypted with TLS, and both the application and the backend instruct browsers to use HTTPS only.
• Responses carrying clinical information are marked not to be cached, so they are not written to browser or intermediate caches.
• Stored information is encrypted at rest by the managed cloud services described above.
• Credentials are held in a managed secret store, never in application code.
• A Content Security Policy with a per-request token restricts what the application is permitted to load or connect to.
• Live update notifications carry only record identifiers and event types — never names, identifiers such as a Personal Health Number, clinical text, or record contents.

No system can promise absolute security. These are the safeguards we maintain; they are reviewed as the service changes.

The service keeps an audit ledger so a custodian can review who did what. Audit records cannot be edited or deleted — the database rejects any attempt — and they survive the deletion of the workspace they describe.

Each record captures the acting user, their workspace and role, the action, the record it concerned, and when it happened. Audit records are written for:

• opening a patient, an encounter, or a claim, and looking a patient up by Personal Health Number;
• creating, updating, or archiving patients, encounters, and claims;
• uploading a document, issuing a document download, and downloading it;
• playing back encounter audio, viewing a transcript, and generating AI-assisted documentation;
• submitting claims and checking patient eligibility, and requesting or downloading exports;
• denied access attempts, session revocation, and changes to workspace access settings.

To be accurate about the limits: audit coverage is deliberately record-level rather than exhaustive. Opening a record is logged; routine list and search views within a workspace are not logged individually. Audit records do not include IP addresses or browser details.

Audit records themselves are restricted to non-identifying values — counts, statuses, and record identifiers. Names, Personal Health Numbers, dates of birth, contact details, diagnoses, and transcript text are prohibited from them, and the service raises an error rather than writing a value outside that allowlist.

The clinic decides how long its records are kept. Clinical records are subject to professional and provincial record-retention requirements that apply to the custodian, and we keep information for as long as the clinic requires it and our agreement with them remains in force.

We do not automatically delete clinical records or encounter audio. The service maintains per-record disposal controls — a disposal date, a legal-hold flag, and an audited disposal process — and those controls currently run in reporting mode: they report what would be due for disposal without destroying anything. Disposal is carried out on documented instruction, and every disposal writes an audit record.

• Removing a recording, or archiving a patient, marks the record inactive rather than destroying it immediately.
• Short audio fragments used to keep transcription current during a recording are deleted from storage once transcribed.
• Audit records are kept separately from the records they describe and are not deleted.

[[TODO: publish the retention schedule — per-record-class retention periods, derived with counsel against the applicable professional record-retention requirements]]

On termination, records are returned or disposed of as set out in the Terms of Service.

We share information only as follows:

• Within the clinic's workspace, with the users the custodian has authorised, according to their role and the workspace's patient-visibility setting.
• With the service providers listed above, to the extent needed to run the service.
• With the provincial billing system, to submit claims and retrieve remittance results.
• Where the law requires it — to a regulator, court, or law-enforcement body acting under lawful authority. Where we are permitted to do so, we will tell the affected custodian first.
• To professional advisors or incident responders, where needed to protect the service or respond to a legal or security event.

Forms prepared for third-party insurers, such as WorkSafeBC or ICBC forms, are generated for the practitioner to download and are not transmitted to those insurers by us. Sending them is the practitioner's step.

We do not sell personal information, share it for advertising, or use it to build profiles.

Subject to applicable law, you may ask to see the personal information held about you, ask for a correction, ask how it has been used and disclosed, and complain about how it has been handled.

If you are a patient, direct your request to the clinic that treated you. The clinic is the custodian of your record and holds the relationship with you; we assist the clinic in responding but cannot release a clinic's records to a third party on our own initiative.

If you hold a Flow Health account, you may contact us directly about your own account information using the details in contact us. We respond to access requests within thirty days, or tell you why we need more time.

If you are not satisfied with our response, you may complain to the Office of the Privacy Commissioner of Canada, or — for a clinic in British Columbia — to the Office of the Information and Privacy Commissioner for British Columbia.

Flow Health sets no advertising cookies and runs no analytics or tracking code. Two cookies are used, both strictly for operating the application:

• a session cookie that keeps you signed in; and
• a layout preference cookie recording whether the navigation sidebar is expanded.

The application also stores a short, fixed list of interface preferences in your browser: colour theme, list view mode, which panel is open, onboarding progress, and the identifier of the encounter you last had selected. No clinical content is stored in the browser for these purposes, and the application rejects any attempt to store a value under a clinical name.

Flow Health is professional software. Accounts are issued by invitation to clinicians and clinic staff, and are not available to children.

Where a clinic provides care to a child, that child's record is held in the clinic's workspace like any other patient record, and the clinic remains the custodian. We do not collect information directly from patients of any age; information reaches us through the clinic.

If we become aware of a privacy or security incident affecting information in our care, we contain it, investigate what happened, assess whether it creates a real risk of significant harm, and record the incident and our response.

We notify the affected clinic without unreasonable delay so the custodian can meet its own obligations to patients and regulators, and we report to regulators ourselves where the law requires it.

We update this policy when the service, our service providers, or the law change. The date at the top of the page shows when the text was last revised.

For a change that materially affects how information is handled, we notify clinics before it takes effect, so a custodian can assess it against their own obligations.

Questions, access requests, and privacy complaints can be directed to our privacy officer.

Privacy officer

[[TODO: privacy officer name or role]]

Email

[[TODO: privacy contact email]]

Phone

[[TODO: privacy contact phone]]

Mail

[[TODO: registered legal entity name]]
[[TODO: registered business address]]