PHI Handling and HIPAA-Aligned Architecture

Dental pre-determination is, by nature, PHI-heavy work: patient demographics, clinical narratives, radiographs, provider identifiers, and insurance details all flow through the pipeline. Accord Dental is built so that protected health information is minimized, isolated, and traceable at every stage — with technical controls designed to align with the safeguards described in the HIPAA Security Rule.

An important clarification. This document describes an architecture designed to align with the HIPAA Security Rule's technical safeguards. It is not a statement of HIPAA compliance or certification — there is no official "HIPAA certification," and no software makes an organization compliant on its own. Covered entities remain responsible for their own HIPAA programs, including administrative and physical safeguards and any Business Associate Agreement that applies to their use of a vendor. Where this document notes a control as planned, treat it as roadmap, not a current guarantee.

Principle 1: minimize the PHI that moves at all

The most effective way to protect health information is to handle as little of it as possible, as narrowly as possible. Accord's extraction pipeline is deterministic-first: structured extractors read clinical documents directly, and only documents that fall below a confidence threshold are escalated to an AI extraction step. In practice this means the large majority of PHI is processed by deterministic code and never reaches a general-purpose language model at all — the AI layer sees only the minority of low-confidence cases that require it.

This "least-data-to-AI" design is deliberate. It shrinks the surface where PHI is exposed to a probabilistic component, and it keeps the default path fully deterministic and auditable.

Principle 2: tenant isolation enforced at the database

Multi-tenant systems live or die on isolation. Accord enforces tenant separation at the database layer using PostgreSQL row-level security (RLS) in FORCE mode, scoped by tenant. Every domain table carries a tenant identifier, and the application connects as a non-owner role that cannot bypass RLS. A query that arrives without the correct tenant context returns zero rows — not another tenant's data.

The significance is that isolation isn't a filter the application layer remembers to apply; it's enforced beneath the application, by the database, for every query. A bug in application code cannot leak one practice's patients to another, because the database itself refuses to return cross-tenant rows.

Principle 3: least-privilege access and secrets handling

Access follows least-privilege boundaries. The application runs under a role scoped to its data operations and cannot perform schema changes; privileged operations require a separate administrative role. Database credentials are stored in AWS SSM Parameter Store, not in source code or configuration checked into the repository, and are read at runtime — so secrets are never committed and can be rotated without code changes.

Principle 4: provider screening built into the pipeline

Two provider-integrity checks run as part of processing rather than as afterthoughts:

• NPPES — provider NPI verification against the national registry, so the provider on a submission is real and correctly identified.
• OIG — screening against the exclusion list, so the practice is alerted if a provider appears on a federal exclusion.

These aren't compliance theater; they're the checks a healthcare organization is expected to perform, run automatically at the point the data enters the system.

Principle 5: traceability and data integrity

Every record in Accord is traceable to a source — the platform's design principle is that no data is invented, and each stored value can be traced back to the document, payer rule, or ADA guideline it came from. Coverage decisions are assembled from an explicit decision trace, and every signal Accord produces points to the specific rule behind it. This traceability is what makes a decision reconstructable after the fact, which matters both for clinical defensibility and for any review of how a determination was reached.

Encryption and transport

Traffic to Accord is served over HTTPS/TLS. Data at rest is stored in managed AWS services (RDS and S3).

What this architecture does — and doesn't — do

It's worth being precise about scope. This architecture provides technical controls — isolation, minimization, least-privilege access, provider screening, traceability, and encryption in transit — that align with the HIPAA Security Rule's technical safeguards. It does not, on its own:

• Make a practice HIPAA-compliant. Compliance is an organizational program, not a software feature.
• Replace the administrative and physical safeguards a covered entity is responsible for.
• Substitute for a Business Associate Agreement where one is required between a practice and a vendor.

What it does is give a practice or DSO a platform whose architecture is designed to support, rather than undermine, their own compliance obligations — with PHI minimized, tenant-isolated, access-controlled, and traceable by design.