Security and HIPAA-Oriented Architecture Overview

Status: Draft for legal and security review Document key: securityHipaaOverview Version: 2026-05-31

This overview summarizes Happy Light AI's intended security posture for clinic customers and vendor review. It is not a certification, audit report, or legal opinion.

1. Product Scope

Happy Light AI is an AI receptionist SaaS for US dental clinics using Open Dental. It may process call metadata, appointment context, recordings, transcripts, summaries, follow-up status, and branch configuration on behalf of a clinic.

2. HIPAA Role

When Happy Light Tech creates, receives, maintains, or transmits ePHI on behalf of a HIPAA covered entity, Happy Light Tech should operate as a Business Associate under a signed Business Associate Agreement.

3. Vendor Architecture

Production architecture uses or should use BAA-backed or contractually appropriate vendors for workloads that process ePHI, including:

• Google Cloud for hosting, storage, logging, secrets, and infrastructure controls;
• Telnyx as a transmission-focused telecommunications conduit for real-time voice transport, with persistent ePHI storage routed to Happy Light Tech's approved GCP environment rather than maintained in Telnyx;
• OpenAI API workloads covered by Happy Light Tech's executed OpenAI BAA and activated Zero Data Retention where eligible;
• any other AI providers only when configured for equivalent eligible processing and approved for the relevant data class;
• Paubox for secure clinical email, including authorized clinic call summary messages where production sending is verified;
• Resend only as emergency/fallback email infrastructure, not as the active production clinical email provider;
• Stripe for payment processing without storing card numbers in Happy Light systems.

Counsel and security reviewers should verify vendor agreements, conduit assumptions, and service scopes before production ePHI use. If any Telnyx product feature is later used to create, receive, maintain, persist, or store ePHI beyond transient voice transmission, Happy Light Tech should reassess whether a BAA or HIPAA-eligible Telnyx service configuration is required before enabling that feature.

4. Data Protection Principles

Happy Light AI should follow these principles:

• tenant and branch scoping for clinic data;
• role-based access controls;
• least-privilege staff access;
• no PHI in public marketing or referral pages;
• no raw Open Dental CustomerKeys in browser storage or logs;
• no raw payment card storage;
• PHI-aware logging and safe error handling;
• private storage for recordings;
• protected backend proxy URLs for recordings;
• encrypted transport;
• Secret Manager for sensitive credentials;
• audit logging for activation-sensitive actions.

5. AI Processing

AI processing should be configured so patient data is not used to train public models. Happy Light Tech has executed an OpenAI Business Associate Agreement and activated Zero Data Retention for eligible OpenAI API workloads; ePHI should not be routed through non-approved AI workloads. Demo content must be anonymized or synthetic.

6. Recording Storage

Call recordings should be stored in private storage and accessed only through tenant-scoped backend authorization. Raw bucket URLs should not be exposed to the browser.

Telnyx should not be used as the system of record for recordings, transcripts, or persistent call content. Real-time voice media should be streamed or routed into Happy Light Tech's approved GCP storage and processing environment when recording or transcript retention is required.

7. Access Control

Clinic owners or managers should control team access. Permissions may include viewing calls, playing recordings, viewing transcripts, managing follow-ups, managing billing, managing team members, managing schedule settings, and revealing Open Dental keys.

Referral-only users should not access clinic tenant data, PHI, recordings, transcripts, or payment methods for a clinic.

8. Audit Logging

Audit logs should record:

• login and account access;
• PHI access events;
• recording playback access;
• transcript access;
• follow-up status changes;
• Open Dental CustomerKey reveal/copy/connect events;
• phone number request/assignment events;
• clickwrap acceptance events;
• billing changes; and
• super admin overrides.

Audit logs should avoid raw secrets, raw card data, full patient transcripts, raw IP addresses, and unnecessary PHI.

9. Incident Response

Security incidents should be triaged, contained, investigated, documented, and escalated according to the incident response policy. Breach notification obligations should be handled under the BAA and applicable law.

10. Limitations

This document does not replace a SOC 2 report, penetration test, HIPAA risk assessment, BAA, or legal review. It is a product security overview for review and planning.