Security and data handling
Isolated by design.
C3 assumes it may be a Business Associate of every practice it serves, and the product is built to isolate practice data rather than to de-identify its way out of the responsibility.
The boundary
What we do with practice data, and what we refuse to do.
These are properties of the code, not policy statements. Several of them are enforced by tests that fail the build when they stop being true.
An isolated schema with its own role
Practice outcome data lives in a dedicated database schema. The role that owns it has no privileges on the rest of the platform, and the platform role has none on it.
Aggregate-only egress
Everything that leaves the dental module passes a guard that refuses identifiers, identifier-like values and long free text. Reports, briefs, logs and telemetry all go through it.
No patient model
A matched outcome anchors on an inquiry the practice already captured. The source record is remembered by a keyed one-way hash — reproducible, not reversible, not joinable across practices.
Exports are parsed in memory and discarded
A report you upload is read, matched and summarised. The file itself is never stored, logged, embedded or sent to a model.
Deterministic matching only
Exact normalised phone, exact normalised email, or an explicit confirmation by your team. Ambiguous stays unmatched. There is no fuzzy or time-window matching.
A readiness gate that fails closed
Patient-level imports stay refused until every prerequisite is recorded with a time and a person, and a separate, deliberate switch is thrown. No row means no ingestion.
Access by membership
A user reaches only the practices they are a member of. A URL, an identifier or a cookie can never widen that.
Purge on offboarding
Leaving C3 removes the practice’s dental data through a sweep that is checked in CI for completeness.
The readiness gate
Patient-level data does not enter until every prerequisite is recorded — and someone decides.
Ingestion is permitted only when each prerequisite below is recorded with a time and a person, and a separate, deliberate switch has been thrown. Satisfying the last prerequisite does not open the door by itself. No record means no ingestion; an unreadable record means no ingestion.
- 1Practice agreement signedThe practice authorises C3 to hold its data before anything else is meaningful.
- 2Database processor agreementThe database that would hold patient records must be contractually bound to protect them.
- 3Application processor agreementThe application handling the data in-request is a processor too.
- 4Protected infrastructure enabledProtection cannot be applied retroactively to data that arrived before it.
- 5Isolation re-certifiedEnabling protection restarts the database, which invalidates any earlier certification.
- 6Ingestion deliberately enabledSatisfying the last prerequisite does not open the door by itself. Somebody decides.
Until the gate is open, an upload of a patient-level report is refused with a plain explanation. Marketing and web sources, which carry no patient records, can be connected before then.
In transit and at the edge
Encrypted in transit. Private by default.
All traffic to the product and between the product and its database is encrypted in transit. The application is served only over HTTPS with strict transport security, and the signed-in product is marked not-for-indexing at both the response and the page level.
Access
Every practice behind authentication and membership.
Signing in is required for every product route and every product API. Within the product, a user can reach only the practices they are a member of. C3 staff supporting a practice choose it explicitly, and nothing in a URL, identifier or cookie can widen anyone’s access.
Questions about a specific control, a processor agreement or your own review? Write to support@c3creativeco.com.
Ask us the hard questions on a walkthrough.
We would rather show you the boundary than describe it. The demo runs on a synthetic practice.
We're onboarding a small number of practices.