Security, Subpoena and Law-Enforcement Notice

Version 2026-09-03 · effective 2026-09-03 · generated facts · prose awaiting counsel

How data is protected, and what we commit to do when someone compels us to produce it.

If someone compels us to produce your information

Subpoena, court order, warrant or other compulsory demand

When we receive a subpoena, court order, warrant or other compulsory demand for information that identifies you, we commit to notifying you within three business days, unless we are legally prohibited from telling you. The same three-business-day notice applies if we make identifiable information available to law enforcement.

The notice is intended to reach you in time to act on it. It tells you:

  • That a demand was received, and what it asks for
  • That you may object, seek a protective order, or pursue another remedy
  • How long you have before we would otherwise produce

Awaiting counsel. TODO(counsel): Confirm the notice wording, the handling of gag orders and sealed process, and the escalation path to counsel. Every demand is routed through counsel; the clock must not depend on someone remembering.

Transparency reporting

Awaiting counsel. TODO(counsel): Publish counts by request type, counts complied with and counts challenged, on a fixed cadence. This section becomes the report; until the first reporting period closes there is nothing to state.

How the platform is protected

Controls that are live in this build:

  • Transport security headers on every route, with framing refused outside the client portal
  • The camera is requested only on the identity-verification screen, and only at the moment of use; contacts and photo library are never requested anywhere
  • Staff sessions expire on idle, and privileged roles are bound to a device
  • Row-level security on data tables, with access decided server-side rather than in the browser
  • An append-only audit trail for access to sensitive records

Awaiting counsel. TODO(counsel): Review this list against the current state of the system before publishing, and remove anything that describes an obligation rather than an implemented control. Do not add certifications, audit reports or assurances that have not been completed.

Health information networks and TEFCA

Medical records reach us only where the individual has authorised the retrieval, and only from the providers and networks they connect themselves. TEFCA exchange is switched off in this build: every TEFCA and identity-proofing code path is unreachable unless the feature flag is explicitly enabled, and this platform makes no claim of Individual Access Services Provider or QHIN status.

Awaiting counsel. TODO(counsel): Before the TEFCA flag is turned on, publish the Individual Access Services disclosure here and in the plaintiff portal — including whether the service is request-only, and what an individual can and cannot do with it. Confirm the required wording and placement against the applicable TEFCA exchange requirements; a request-only service that reads as bidirectional is a misstatement to the individual.

Reporting a vulnerability

Awaiting counsel. TODO(counsel): Give the reporting address, the safe-harbour statement for good-faith research, and the response-time commitment.

If something goes wrong

Awaiting counsel. TODO(counsel): State the breach-notification commitment: who is told, in what time, and through what channel. Align it with the deadlines in each applicable statute.

Other legal documents

Consumer Health Data Privacy Policy

Privacy choices: 0 of 3 optional technologies enabled.