Privacy notice

DentEdit — dental claim editing and payment integrity platform · Template revision 2026-08-17 · Applies to: [NAMED DEPLOYMENT]

1. Who is responsible

The payer organisation operating this deployment ([CUSTOMER LEGAL ENTITY]) determines why claim data is processed and is the controller of it. [VENDOR LEGAL ENTITY] supplies the software and processes that data only on the controller's instructions. Contact for privacy questions: [PRIVACY CONTACT]. Data protection officer, where one is required: [DPO / REPRESENTATIVE].

In the United States, dental claim data is protected health information and the relationship above is also a HIPAA covered-entity / business-associate relationship. That requires a signed Business Associate Agreement, which is a separate instrument from this notice and from the data processing agreement.

2. What the platform holds

Read from the canonical claim model and the stored record, not from a description of intent:

Patient and subscriber: Name, date of birth, member identifier, relationship to subscriber, and postal address where submitted (packages/engine/src/model/claim.ts).
Clinical detail: Procedure codes, tooth numbers and surfaces, dates of service, quantities, diagnosis codes, prior-authorisation references, orthodontic case facts, and any narrative text the submitter attached.
Attachments: Radiographs, periodontal charts and other documents, plus their metadata and which patient each belongs to.
Financial detail: Submitted charges, allowed and recommended amounts, patient and payer liability, remittance and payment references.
Provider detail: Billing and treating provider identifiers (NPI), practice name and address.
Eligibility and plan facts: Coverage, benefit maxima, frequency history and plan design — looked up server-side and never taken from the submission.
Operator activity: Usernames, roles, and the decisions reviewers made: edits accepted or overridden, appeals, approvals, and the reasons recorded with them.

3. Why it is processed

To adjudicate a submitted claim against coverage, coding and clinical policy rules.
To route claims that cannot be decided automatically to a human reviewer.
To reconcile payments and remittance against what was recommended.
To detect billing patterns that warrant review — as observations only, never as an automatic accusation or an automatic denial.
To keep the audit record a payer needs to show why a claim was decided as it was.

Lawful basis, where the GDPR or a comparable regime applies: [BASIS PER PURPOSE — e.g. contract, legal obligation, legitimate interests]. Where a special-category basis is needed for health data: [ARTICLE 9 CONDITION].

4. Automated decisions

Factual, from the code: the engine produces recommendations and edits with a disposition of PAY, DENY, PEND, REDUCE or REQUEST_INFO, each carrying the rule that produced it and the facts it relied on. The fraud, waste and abuse layer issues observations with no score, no rank and no disposition, and nothing in it can move a claim. No model is used to decide any claim.

Whether a given deployment lets a recommendation take effect without a human reviewing it is a configuration decision by the controller, and it determines whether Article 22 (or its local equivalent) applies: [STATE WHICH DISPOSITIONS AUTO-FINALISE, IF ANY].

5. Artificial intelligence

Factual, from the code: the AI layer has three modes and ships in off (apps/api/src/ai/deidentify.ts). In off, no capability contacts a provider and nothing leaves the process. In deidentified, free text is redacted whole rather than scrubbed, and the manifest records what was withheld. Only phi-allowed sends unredacted content, and it is documented as unavailable without a Business Associate Agreement. When enabled the provider is Anthropic, model claude-opus-5. The AI layer drafts rules, explains decisions and writes reviewer narratives; it decides nothing.

Before any deployment processes real patient data with AI enabled, the controller must have a BAA in place with the model provider and record it here: [MODEL PROVIDER BAA REFERENCE AND DATE].

6. Who can see it

Factual, from the code: every read is scoped to one payer tenant, derived server-side from the session token and never from anything a request can assert. A request for another tenant's claim is answered 404 Not Found rather than 403, because a 403 would confirm the record exists. The platform content plane, which distributes standard rules, is refused every claim-data route.

Recipients outside the controller: [CLEARINGHOUSES, HOSTING, SUPPORT], each listed with its role in the data processing agreement.

7. Logging of access

Factual, from the code: reads and exports are recorded in an append-only access trail (apps/api/src/audit/accessTrail.ts) holding the actor, the route, the outcome, and which subjects were reached. A refused read is recorded too, because a refusal is the evidence an auditor needs when investigating an enumeration attempt. An export with no stated disclosure purpose is refused outright.

8. Retention

Factual, and a gap: no retention schedule is implemented. The PostgreSQL store does not delete or trim anything on a timer; the file-backed development store keeps the most recent 2,000 events per tenant and drops older ones (json.store.ts). Deleting data on a schedule is therefore an operational task nobody has built, and [RETENTION PERIODS PER CATEGORY] cannot be honoured by configuration today.

9. Deletion and data-subject rights

Factual, and a gap: the platform can withdraw a claim from the corpus when a VOID instruction is processed — a real erasure, applied within one tenant and matched on patient identity rather than on the subscriber alone. There is no self-service mechanism for access, rectification, erasure, restriction, portability or objection. Answering such a request today means an operator working through the API and the audit trail by hand.

Rights available to a data subject, and how to exercise them: [PROCESS, RESPONSE DEADLINE, IDENTITY VERIFICATION]. Complaints may be made to [SUPERVISORY AUTHORITY / OCR].

10. Security

Factual, and stated plainly rather than favourably: access requires a signed session token; there is deliberately no built-in signing secret, so a deployment that sets none gets a random per-process one and every restart invalidates outstanding sessions. Roles gate what an operator may read and do, rule changes require a second person to approve, and the audit trail is append-only. Transport encryption, encryption at rest, backup, key management and network isolation are deployment responsibilities and are not configured by this software. The development configuration serves plain HTTP on localhost.

No SOC 2 report has been issued, no penetration test has been closed out and no disaster-recovery drill has been run against a documented RPO or RTO. Those are stated as outstanding in the project's own exit criteria rather than implied to be complete.

11. International transfers

Hosting location and any transfer mechanism: [REGION, SCCs / DPF / ADEQUACY]. Note that enabling the AI layer sends content to the model provider's infrastructure, which is a transfer that must be covered before phi-allowed is used.

12. Changes

Material changes will be recorded here with a revision date. This template revision is 2026-08-17 and supersedes nothing, because no earlier version was ever in force.