HIPAA-compliant dental imaging APIs: security checklist for US healthcare integrations

If you're integrating a dental imaging API into a US-based DSO, group practice or specialty clinic, HIPAA is not a checkbox at the end of the project. It's a design constraint. DICOM files carry PHI in their headers, audit logs are mandatory, and breach notification rules apply to every byte you touch. This checklist captures the ten things any CTO or compliance officer should be able to answer "yes" to before going live.

For background reading, the HHS HIPAA pages are the authoritative source. This article is operational guidance, not legal advice — work with your privacy counsel for anything binding.

The 10-point checklist

1. Encryption at rest and in transit

Every byte of PHI must be encrypted on the wire and on disk. That means TLS 1.2 or higher for all API calls and webhooks, and server-side encryption on the storage layer. CBCTHub serves all traffic over TLS 1.3 and stores DICOM files on Cloudflare R2 with SSE enabled. Verify your own end of the connection too — outdated proxies, custom load balancers and on-prem agents are the usual TLS weak spots.

2. API key rotation policy

Long-lived secrets are a liability. Rotate API keys at least every 90 days, and immediately when an employee with access leaves. Build the rotation into your secret manager (AWS Secrets Manager, Vault, Doppler) so the new key is provisioned and the old one revoked without downtime. CBCTHub lets you have multiple active keys per account so you can roll forward without a maintenance window.

3. HMAC verification on webhooks

If your integration accepts inbound webhooks, every payload must be verified with HMAC SHA-256 before it touches your business logic. Reject any request whose X-CBCTHub-Signature doesn't validate against the shared secret, and use a constant-time comparison (e.g. crypto.timingSafeEqual in Node, hmac.compare_digest in Python) to avoid timing leaks.

4. Audit logs retained for at least six years

HIPAA's general document-retention rule is six years. Your audit trail should record who accessed which exam, when, from what IP, and what action they took. CBCTHub exposes audit logs both through the dashboard and via the /api/account/audit-log endpoint, with CSV export for offline retention. Ship those logs into your SIEM and keep them out of mutable storage.

5. Granular access scoping

The principle of least privilege applies to API keys. Don't issue a single super-key per integration — issue scoped keys for what each system actually needs. CBCTHub keys carry exams:read and exams:write scopes today, with finer-grained scopes on the roadmap. Use sandbox keys (cbct_test_) for QA so developers never see production PHI.

6. Business Associate Agreement (BAA)

Any vendor that creates, receives, maintains or transmits PHI on your behalf is a business associate and must sign a BAA. Don't ship a single production call until the BAA is countersigned. CBCTHub provides a standard BAA on request for Pro plans and above — talk to sales before go-live.

7. Breach notification procedures

If a breach happens, the clock starts immediately. You have 60 days to notify affected individuals and HHS (and a state attorney general, depending on jurisdiction). Document the chain of command, the templates, and the contact list before you need them. CBCTHub's privacy policy includes our breach notification commitments and timeline.

8. Patient access rights (HIPAA Right of Access)

Under HIPAA, patients have the right to access their PHI within 30 days. Your integration should support this end to end — give patients a way to request, receive and download their imaging in a usable format. The CBCTHub patient portal and the /api/account/export-data endpoint cover the technical requirements; the workflow is on you.

9. De-identification for research and ML

If you ever use real exams for product development, research, or ML training, de-identify them following the Safe Harbor method (18 identifiers removed) or the Expert Determination method. CBCTHub supports anonymized embed tokens that strip the patient name from the viewer; combine that with header stripping at the DICOM level for anything leaving production.

10. Secure file deletion

Soft-deletes are convenient for product, dangerous for PHI. When a patient requests deletion or your retention policy says it's time, the bytes must actually go away. Verify your provider deletes from primary storage and all backups within a defined window. CBCTHub purges deleted exams from R2 within 30 days and overwrites database rows.

How CBCTHub meets each item

Item	Status
1. Encryption	TLS 1.3 + R2 SSE
2. Key rotation	Multiple keys per account, instant revocation
3. Webhook HMAC	SHA-256 with per-subscription secret
4. Audit logs	Dashboard + API + CSV export
5. Scoping	read/write scopes, sandbox keys
6. BAA	Available on Pro plan and above
7. Breach notification	Documented in privacy policy
8. Patient access	Portal + export endpoint
9. De-identification	Anonymized embed tokens
10. Secure deletion	Purge from R2 + DB within 30 days

How we compare on compliance

Many legacy dental imaging vendors check the encryption box and stop there. The differentiators we hear from US buyers are signed BAAs without legal friction, audit logs accessible by API instead of through a support ticket, and HMAC-signed webhooks. The work to get those right doesn't show up in a feature comparison, but it's exactly what your security review will dig into.

Where we are on SOC 2

SOC 2 Type II is in progress. We can share our Type I report and our current control list under NDA — reach out to security@cbcthub.com.

Wrap up

HIPAA compliance for a dental imaging integration isn't a project you finish — it's a posture you maintain. The ten items above are the table stakes for a serious US healthcare deployment, and the operational habits behind them (rotation, scoping, audit, deletion) protect you from the next regulation as much as the current one. Build them in from day one and the rest of the integration gets easier.

Request a BAA and our compliance whitepaper · Read the security docs