Buyer security brief · Launch pilot

Dental billing HIPAA compliance,
without the compliance theatre.

A plain-language view of the controls and data paths ArcaCirca operates with today, where claims and denials live, and what the Launch pilot BAA covers before a connected clinic sends PHI.

Three questions, one boundary
What a pilot buyer needs to verify.

01 · Current controls

What is protected today.

The current posture is visible in the application boundary and deployment configuration. It is evidence to review—not a certification claim.

Signed-in access, with a separate admin boundary
Better Auth provides the session boundary for signed-in users. Authenticated users can reach some practice and claim workflows. The denial-pattern/search and EOB surfaces additionally check the user’s admin role, so signed-in access is not the same as admin-only access.
Transport and deployment safeguards
The repository’s PostgreSQL connection documentation requires SSL. The app documents HSTS and baseline security headers, and its request proxy applies a strict nonce-based Content Security Policy. These are transport and browser protections, not an attestation.
What this page does not claim
Important limits for a buyer’s diligence review.
The inspected codebase contains no audit-log model or action-log implementation for the claims or denials surfaces, and no application-level at-rest encryption implementation. This page therefore does not claim an immutable audit trail, encrypted at rest, SOC 2 Type II, HIPAA certification, HITRUST, or another attestation. Confirm the Launch terms and evidence with the ArcaCirca team before live PHI is connected.

02 · PHI flow and access

Where claims, denials, and aging data live.

The relational model keeps the connected clinic visible in each downstream billing record, while the access boundary still needs an explicit Launch review.

Practice is the clinic tenant
A Practice represents the clinic. Patient and Claim rows carry practice_id. Denial rows hang off a claim. EOB rows can carry a practice_id, a claim_id, or both.
Structured records, with extraction context
The EOB model stores structured payer, claim, patient, service, payment, and denial fields alongside raw_extract. The AR aging report reads open claims by practice_id. When the appeal draft is sent to the installed AI proxy, the application sends patient initials rather than a full name.
Current readers and the Launch access question
Authenticated users can reach some practice and claim surfaces. Denial-pattern search and EOB routes enforce admin role checks. The repository does not contain a user-to-practice membership field, so this page does not imply that every route is already clinic-membership scoped or that the current code is full tenant isolation. Confirm the Launch access boundary as an operational and legal item before live PHI moves.

03 · Launch pilot BAA

What the clinic signs.

The existing product posture is straightforward: the clinic signs a BAA before PHI moves. The intended covered workflow is the connected clinic’s claims, denials, EOB/aging records, and related pilot support handling.

The Launch BAA defines the specific covered services, responsibilities, and terms for the pilot. This page does not invent retention periods, subprocessors, breach timelines, legal entity names, or additional security commitments. For the exact terms and the access boundary, bring your questions to the pilot call.

Book a pilotNot a certification. Confirm terms in the BAA.
Before PHI moves
A diligence conversation, not a checkbox.

Start with the three questions on this page, then confirm the connected clinic’s users, practices, workflows, and BAA terms with the ArcaCirca team.

See the practical answers in the pilot FAQ or compare the workflow in ArcaCirca vs Crescendo.

Ready to diligence the pilot?

Bring your BAA questions.

Talk through the Launch scope