Security and data handling
Your trust. Built into the architecture.
Your practice data belongs within your practice. Access follows membership, public pages read no practice records, and patient-level imports stay closed until the required safeguards are recorded.
A Business Associate posture
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.
Encrypted in transit
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.
Private by default
The signed-in product is marked not-for-indexing at both the response and the page level, and the public site reads no practice data at all.
Purposeful separation
A dedicated boundary for practice data.
The role that owns the dental schema has no privileges on the rest of the platform, and the platform role has none on it. Everything that leaves the dental boundary passes a guard that refuses identifiers, identifier-like values and long free text.
Tenant isolation
The right access. For the right practice.
The path a request takes from the public site to a practice-scoped query. There is no step where a URL, an identifier or a cookie can widen what a user sees.
- 01c3dental.orgPublic site. Reads no practice data.
- 02SessionEvery /app route and every product API requires one; the edge redirects or answers 401 without it.
- 03MembershipThe practices this user may operate, from membership rows. Staff see every practice, aggregate-only.
- 04Practice selectionChosen explicitly, validated against that list. A forged cookie or URL selects nothing.
- 05Practice-scoped readsEvery query carries the selected practice’s id. There is no query that does not.
Safeguards
What we do with practice data.
01
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.
02
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.
03
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.
04
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.
05
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.
06
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.
07
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.
08
Purge on offboarding
Leaving C3 removes the practice’s dental data through a sweep that is checked in CI for completeness.
The readiness gate
Safeguards first. Patient data second.
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.
What we do not do
Clear limits on how data is used.
A shorter list than the safeguards, and the one to hold us to.
- No patient model — no patient record, detail page or clinical note exists anywhere in C3.
- No patient-level data on any public route, in page metadata, in a static payload or in search indexing.
- No fuzzy or time-window matching. Ambiguous stays unmatched.
- No cross-tenant enumeration. The practice selector lists only the practices a member belongs to.
- No forecasts and no benchmarks pooled across practices.
- No automatic budget control and no direct write to any practice system.
Questions about a specific control, a processor agreement or your own review? Write to support@c3creativeco.com.
THE NEXT CHAPTER / C3 DENTAL
Confidence deserves a closer look.
Talk with our team about data handling, access controls and the safeguards behind C3. See the product without connecting your practice data.
30-minute walkthrough · No practice data required