How we protect your data

Our commitment

A compliance baseline, chosen per deployment

Marble handles some of the most sensitive information a person has — their health record. We build to a jurisdiction-aware compliance baseline from the ground up rather than treating privacy as an afterthought.

• Each deployment selects its regime — Australia (Privacy Act 1988 / the 13 Australian Privacy Principles / Notifiable Data Breaches scheme), the United States (HIPAA Privacy, Security & Breach Notification Rules), or the United Kingdom (UK GDPR / Data Protection Act 2018 / NHS Data Security and Protection Toolkit posture).
• The chosen jurisdiction drives this page’s copy and an in-region data-residency guard on the server; the underlying controls are shared, jurisdiction-neutral mechanisms.
• Each clinic group runs in its own isolated instance — a dedicated container, database and subdomain — so no other clinic’s data ever shares your deployment.

Where your data lives

In-region, by deployment

Your patients’ data stays in its jurisdiction. Marble runs in the region configured for the deployment — the database, file storage, backups, AI processing and email all sit in-region.

• Records, uploads and backups are held on infrastructure in the deployment’s region — Sydney (ap-southeast-2) for Australia, a US region for HIPAA, or London (eu-west-2) for the UK.
• AI-assisted documentation is routed to an in-region model, so patient-identifiable content used to draft notes and letters is not sent overseas.
• Outbound email (referrals, letters) is sent via a mail service configured to the deployment’s region.
• On-device dictation with the Vosk engine can transcribe speech locally in the browser — audio need not leave the device at all.

Who can see it

Least-privilege access, fail-closed

Only authenticated, authorised users reach clinical data — and the database itself refuses to answer without a resolved user, as a defence-in-depth backstop.

• Viewing patient data requires two-factor authentication — a phishing-resistant WebAuthn passkey or authenticator code — so guessing a clinic’s subdomain is never enough to reach a record.
• The application connects to PostgreSQL through a restricted, non-owner role that cannot bypass security policy or rewrite history.
• A fail-closed row-level-security policy means a query that arrives without an authenticated user returns zero rows — never the whole table.
• Every request carries the acting user’s identity through to the database so access is always attributable.

How it’s protected

Encrypted in transit and at the field level

Sensitive identifiers are encrypted individually, so even a raw copy of the database reveals nothing without the keys.

• All traffic is served over HTTPS (TLS) with automatic certificates and strict single-origin checks.
• National identifiers are encrypted field-by-field with AES-256-GCM — Medicare, IHI and DVA numbers today, with the US (SSN, MRN, insurance ID) and UK (NHS number) identifier sets specified and some on the roadmap. A raw database dump shows only ciphertext.
• Encryption keys are held outside the database and are designed to move to a managed key service (KMS) without changing the data.
• Identifiers are never written to logs in plaintext.

Accountability

An immutable trail of access and change

Knowing who did what, and when, is central to both good clinical governance and breach detection.

• Changes to clinical records are captured by the database itself into an append-only audit trail the application can add to but never rewrite.
• Record-level access — viewing a patient’s file — is logged, attributed to the acting user.
• This access-and-change history underpins our posture for detecting and, if ever required, reporting an eligible data breach — under Australia’s NDB scheme, HIPAA’s Breach Notification Rule or the UK’s GDPR breach duties, whichever applies to the deployment.

Retention & deletion

Nothing is destroyed by accident

Clinical data has medico-legal retention obligations, so deletion is deliberate, logged and reversible rather than silent.

• Records are soft-deleted — hidden from normal use while retained — rather than hard-deleted.
• Any purge would be a governed, logged, deliberate process, not an automatic sweep.
• Retention periods are jurisdiction-specific — in Australia, commonly cited as seven years from the last entry for adults and until age 25 for minors — and are treated as provisional, confirmed with a health-privacy professional in the relevant jurisdiction.

Under review. This area carries obligations we are confirming with legal counsel; the controls are in place while the policy detail is finalised.

Healthcare identifiers

National identifiers, handled with extra care

Storing a national healthcare identifier raises the compliance bar beyond the general privacy law of a jurisdiction.

• In Australia, storing an Individual Healthcare Identifier (IHI) brings the Healthcare Identifiers Act 2010 into scope, with stricter rules on collection, use and disclosure of the identifier.
• Equivalent identifier obligations apply in the US (SSN / MRN / insurance ID) and the UK (NHS number); those field sets are specified and some are on the roadmap rather than shipped.
• We build the mechanism — encrypt, restrict and audit access to identifiers — while treating the specific consent and disclosure obligations as under legal review in each jurisdiction.
• Marble does not integrate with My Health Record.

Under review. This area carries obligations we are confirming with legal counsel; the controls are in place while the policy detail is finalised.