Technical White Paper

Abstract

IntakeIQ is an AI-powered dental intake automation platform designed to replace paper-and-clipboard patient onboarding with a secure, intelligent digital workflow. Built on Next.js 14, PostgreSQL, and AWS HIPAA-eligible infrastructure, IntakeIQ enables dental practices to collect patient demographics, medical history, insurance information, and consent signatures through a mobile-first web application — accessed via QR code — while maintaining rigorous compliance with the HIPAA Security Rule.

This document provides a comprehensive technical overview of IntakeIQ's architecture, security controls, data model, deployment infrastructure, and development practices. It is intended for chief technology officers, technical advisors, information security officers, and enterprise compliance reviewers evaluating IntakeIQ for deployment in healthcare environments.

Every layer of the IntakeIQ stack — from field-level AES-256-GCM encryption of Protected Health Information (PHI), to role-based access control, to append-only audit logging with 7-year retention — was engineered with HIPAA's Technical, Administrative, and Physical Safeguards as first-class requirements, not afterthoughts.

1. Introduction

1.1 The Problem

Dental patient intake is fundamentally broken. The majority of dental practices in the United States still rely on paper forms, clipboards, and manual data entry. This creates a cascade of operational failures:

• Data entry errors: Handwriting misinterpretation leads to incorrect patient records, insurance claim rejections, and potential clinical safety issues.
• Time waste: Front desk staff spend 15–20 minutes per patient transcribing paper forms into practice management systems.
• Insurance verification delays: Manual insurance card processing creates bottlenecks that extend check-in times and delay treatment authorization.
• Compliance risk: Paper forms stored in filing cabinets present physical security vulnerabilities. There is no audit trail for who accessed a patient's information.
• Patient friction: Patients arriving 30 minutes early to fill out repetitive paper forms is a poor first impression that no practice wants to deliver.

1.2 The Solution

IntakeIQ replaces the entire paper intake workflow with a digital, AI-assisted process. Patients scan a QR code, complete a guided 7-step intake form on their own device, photograph their insurance card for automatic OCR processing, and sign consent forms digitally. Staff receive completed, validated, pre-structured intake data in their dashboard — ready for review and import into their practice management system.

1.3 Why AI-Powered

IntakeIQ integrates AI at two critical points. First, Anthropic's Claude API assists with intelligent intake processing — interpreting freeform patient responses, flagging potential clinical concerns, and structuring unstructured data. Second, AWS Textract performs optical character recognition (OCR) on insurance cards, extracting carrier name, member ID, group number, and coverage details without manual transcription. AI assists clinical workflows but never replaces clinical judgment — all AI-generated outputs require staff review before becoming part of the patient record.

2. System Architecture

IntakeIQ follows a monolithic-first architecture pattern using Next.js, which provides both the frontend rendering layer and the backend API layer in a single deployable unit. This design minimizes operational complexity, reduces inter-service latency, and simplifies HIPAA compliance auditing — all PHI processing occurs within a single trust boundary.

2.1 Component Overview

3. Technology Stack

4. Data Model

IntakeIQ uses a multi-tenant relational data model where every record is scoped to a Practice. The schema is defined in Prisma and supports both SQLite (development) and PostgreSQL (production). All PHI fields are encrypted at the application layer before database storage.

4.1 Practice

The top-level tenant entity. Every user, patient, form, and intake session belongs to exactly one practice. Stores practice metadata (name, phone, email, address), timezone, subscription plan, and configurable settings as JSON.

4.2 User

Staff members who access the IntakeIQ dashboard. Each user belongs to one practice and has a role (OWNER, ADMIN, DENTIST, HYGIENIST, or FRONT_DESK) that determines their access permissions via RBAC. Passwords are stored as bcrypt hashes. The isActive flag allows soft-disabling accounts without deletion.

4.3 Patient

The core PHI entity. Fields including firstName, lastName, email, phone, dateOfBirth, and ssn are encrypted with AES-256-GCM before storage. Address and emergency contact information are stored as encrypted JSON. Each patient belongs to one practice.

4.4 Form

Customizable intake form templates. Each form has a name, description, version number, and a JSON array of field definitions. Forms are versioned so that completed sessions retain a reference to the exact form version the patient filled out.

4.5 IntakeSession

The central workflow entity. Represents a single patient intake event, tracking the patient, form, current step, all responses (as JSON), flags for clinical review, and the complete lifecycle from PENDING through IN_PROGRESS, COMPLETED, and REVIEWED. Sessions can expire and are linked to the reviewing staff member.

4.6 InsuranceVerification

Stores insurance card processing results. Linked 1:1 to an intake session. Contains carrier name, member ID, group number, subscriber name (all encrypted PHI), coverage type, copay, deductible, and annual maximum. Tracks verification status: PENDING, VERIFIED, FAILED, or MANUAL_REVIEW. Insurance card image URLs reference S3 objects.

4.7 AuditLog

An append-only table for HIPAA compliance. Every access to PHI — views, creates, updates, deletes, exports, and prints — is recorded with the acting user, their role, the resource accessed, the action taken, IP address, user agent, timestamp, and success/failure status. Audit logs must be retained for a minimum of 7 years per HIPAA requirements.

5. Security Architecture

IntakeIQ's security architecture is designed to satisfy HIPAA's Technical Safeguards across all four categories: Access Controls, Audit Controls, Integrity Controls, and Transmission Security. Security is not a bolt-on feature; it is woven into every layer of the stack.

5.1 Encryption at Rest — AES-256-GCM Field-Level PHI Encryption

IntakeIQ implements field-level encryption for all PHI using AES-256-GCM (Galois/Counter Mode). Unlike whole-disk or whole-database encryption, field-level encryption ensures that individual PHI values are encrypted before they leave the application layer. Even a compromised database dump reveals only ciphertext.

Encryption Implementation

import { randomBytes, createCipheriv, createDecipheriv } from "crypto";

const ALGORITHM = "aes-256-gcm";
const IV_LENGTH = 12;   // GCM recommended IV length
const AUTH_TAG_LENGTH = 16;

export function encryptPHI(plaintext: string): string {
  const key = getEncryptionKey();
  const iv = randomBytes(IV_LENGTH);
  const cipher = createCipheriv(ALGORITHM, key, iv, {
    authTagLength: AUTH_TAG_LENGTH,
  });

  const encrypted = Buffer.concat([
    cipher.update(plaintext, "utf8"),
    cipher.final(),
  ]);
  const authTag = cipher.getAuthTag();

  // Pack: IV (12) + AuthTag (16) + Ciphertext
  const packed = Buffer.concat([iv, authTag, encrypted]);
  return packed.toString("base64");
}

Encrypted PHI Fields

Additionally, the RDS PostgreSQL instance uses AWS KMS-managed storage encryption, and the S3 bucket for insurance card images uses SSE-KMS with a dedicated PHI encryption key. This provides defense-in-depth: application-layer encryption plus infrastructure-layer encryption.

5.2 Encryption in Transit — TLS 1.3

All data in transit is protected by TLS 1.3. The Application Load Balancer enforces the ELBSecurityPolicy-TLS13-1-2-2021-06 SSL policy, which requires TLS 1.2 minimum and prefers TLS 1.3. HTTP requests on port 80 receive a 301 redirect to HTTPS. HSTS headers with a 1-year max-age, includeSubDomains, and preload are set on every response.

5.3 Authentication — JWT Sessions

IntakeIQ uses stateless JWT-based sessions with server-side verification. Sessions are created on login, stored in HTTP-only cookies, and verified on every authenticated request.

const SESSION_MAX_AGE = 60 * 15; // 15 minutes (HIPAA automatic logoff)

const token = await new SignJWT({
  sub: user.id,
  email: user.email,
  role: user.role,
  practiceId: user.practiceId,
})
  .setProtectedHeader({ alg: "HS256" })
  .setIssuedAt()
  .setExpirationTime(`${SESSION_MAX_AGE}s`)
  .sign(getSecret());

5.4 Authorization — Role-Based Access Control (RBAC)

IntakeIQ implements a hierarchical RBAC system with five roles. Each role inherits the permissions of all roles below it in the hierarchy.

const ROLE_HIERARCHY: Record<string, number> = {
  OWNER: 100,  ADMIN: 80,  DENTIST: 60,  HYGIENIST: 40,  FRONT_DESK: 20,
};

export function hasRole(userRole: string, requiredRole: string): boolean {
  return (ROLE_HIERARCHY[userRole] ?? 0) >= (ROLE_HIERARCHY[requiredRole] ?? 0);
}

5.5 Input Validation — Zod Schemas

Every API endpoint validates incoming data against Zod schemas before any processing occurs. This prevents injection attacks, malformed data from reaching the database, and provides clear error messages to API consumers.

export const createPatientSchema = z.object({
  firstName: z.string().min(1).max(100),
  lastName:  z.string().min(1).max(100),
  email:     z.email().optional(),
  phone:     z.string().max(20).optional(),
  dateOfBirth: z.string().optional(),
  gender:    z.string().max(20).optional(),
  address:   z.record(z.string(), z.any()).optional(),
  emergencyContact: z.record(z.string(), z.any()).optional(),
});

export const loginSchema = z.object({
  email:    z.email(),
  password: z.string().min(1),
});

5.6 Rate Limiting

IntakeIQ enforces per-endpoint rate limits to prevent brute force attacks and API abuse. The rate limiter runs in-process with an in-memory store (upgrading to Redis for multi-instance deployments).

Rate-limited responses return HTTP 429 with Retry-After and X-RateLimit-Reset headers, conforming to RFC 6585.

5.7 Audit Logging

IntakeIQ maintains an append-only audit log of every PHI access event. The audit system captures who (user ID, role), what (resource type, resource ID, action), when (ISO 8601 timestamp), where (IP address, user agent), and outcome (success/failure). Audit logs are persisted to both the database and structured JSON output for CloudWatch ingestion.

Tracked Actions (Partial List)

5.8 Session Management and Security Headers

The Next.js middleware enforces security headers on every response and manages session lifecycle for authenticated routes.

For authenticated /app/* routes, the middleware implements a sliding window session: on every request, the session cookie is re-issued with a fresh 15-minute maxAge. If 15 minutes pass without activity, the cookie expires and the user is redirected to the login page — satisfying HIPAA's automatic logoff requirement.

6. Patient Intake Flow

The patient intake process is designed for zero-friction, mobile-first completion. The entire flow is accessible without app installation or account creation.

7. AI Integration

7.1 Claude API — Intelligent Intake Processing

IntakeIQ integrates Anthropic's Claude API to add intelligence to the intake process. Claude is used for:

• Data structuring: Converting freeform patient responses into structured, clinically useful data.
• Clinical flag generation: Identifying potential concerns in medical history (e.g., drug interactions, contraindicated conditions) that staff should review.
• Completeness checking: Identifying missing or potentially incorrect information in patient submissions.

7.2 AWS Textract — Insurance Card OCR

When a patient uploads an insurance card image, IntakeIQ sends it to AWS Textract for optical character recognition. The OCR pipeline:

1. Receives the uploaded image via the /api/insurance/ocr endpoint (rate-limited to 10 requests/minute).
2. Stores the image in the KMS-encrypted S3 bucket.
3. Calls AWS Textract to extract text regions from the card.
4. Parses extracted text to identify carrier name, member ID, group number, subscriber name, and group details.
5. Creates or updates an InsuranceVerification record with encrypted PHI fields.
6. Returns structured data to the patient for confirmation and correction if needed.

Textract is a HIPAA-eligible AWS service, and all data is transmitted via TLS. Insurance card images are retained in S3 with lifecycle rules that transition them to Infrequent Access storage after 90 days for cost optimization.

7.3 Future AI Capabilities

• Intelligent form adaptation: Dynamically adjusting follow-up questions based on patient responses.
• Pre-visit risk assessment: Analyzing medical history to generate pre-appointment clinical summaries.
• Natural language intake: Conversational intake experience powered by Claude, replacing rigid form fields.

8. Infrastructure

IntakeIQ's production infrastructure runs entirely on HIPAA-eligible AWS services, provisioned via a single CloudFormation template for reproducible, auditable deployments.

8.1 Network Architecture

8.2 AWS Services

8.3 Security Groups

Security groups implement a strict least-privilege network policy:

• ALB Security Group: Accepts TCP 80 and 443 from 0.0.0.0/0 (internet-facing).
• ECS Security Group: Accepts TCP 3000 only from the ALB Security Group. No direct internet access to containers.
• RDS Security Group: Accepts TCP 5432 only from the ECS Security Group. Database is unreachable from the internet or from any service other than the application.

8.4 Secrets Management

All secrets are stored in AWS Systems Manager Parameter Store and injected into ECS task definitions at runtime. Secrets never appear in source code, Docker images, or CloudFormation templates (the template stores placeholder values that must be updated post-deploy via the AWS Console).

9. HIPAA Compliance Matrix

The following matrix maps HIPAA Security Rule requirements to their implementations within IntakeIQ.

10. API Design

IntakeIQ exposes a RESTful API through Next.js API Routes. All endpoints return JSON and follow consistent patterns for authentication, validation, error handling, and audit logging.

10.1 API Routes

* Insurance OCR is called from the patient intake flow (no staff auth), but is rate-limited and scoped to active sessions.

10.2 Authentication Flow

// 1. Login request
POST /api/auth/login
{ "email": "user@practice.com", "password": "..." }

// 2. Server validates credentials, creates JWT, sets cookie
Set-Cookie: intakeiq-session=<jwt>; HttpOnly; Secure; SameSite=Lax; Max-Age=900

// 3. Subsequent requests include cookie automatically
GET /api/patients
Cookie: intakeiq-session=<jwt>

// 4. Middleware verifies JWT and refreshes cookie (sliding window)
// 5. After 15 min inactivity, cookie expires → redirect to /login

10.3 Error Handling

All API errors follow a consistent JSON structure:

{
  "error": "Human-readable error message",
  "code": "VALIDATION_ERROR",   // Machine-readable error code
  "details": [...]              // Optional: Zod validation errors
}

11. Performance & Scalability

11.1 Current Capacity

11.2 Scaling Strategy

• Horizontal (Fargate): ECS service DesiredCount can be increased from 1 to N. The ALB distributes traffic across tasks. Session state is in JWTs (stateless), so any task can serve any request.
• Vertical (RDS): Upgrade from db.t4g.micro to db.t4g.small or db.t4g.medium with zero-downtime Multi-AZ failover.
• Rate Limiting: Current in-memory rate limiter works for single-instance. Redis-backed rate limiting will be required for multi-instance deployments.
• Database Optimization: Strategic indexes on practiceId, patientId, status, and timestamp columns are already in place. Read replicas can be added when query load justifies it.

11.3 Cost Optimization Decisions

12. Development Practices

12.1 TypeScript Strict Mode

IntakeIQ is written in TypeScript with strict mode enabled. This provides compile-time guarantees around null safety, type correctness, and exhaustive pattern matching — critical when handling PHI where a mistyped field name could lead to data leakage or corruption.

12.2 Prisma ORM — SQL Injection Prevention

All database access goes through the Prisma client, which uses parameterized queries exclusively. There are zero raw SQL queries in the codebase. The Prisma schema is the single source of truth for the data model, and the generated client provides type-safe access that is validated at compile time.

12.3 Input Validation Strategy

IntakeIQ implements a defense-in-depth validation strategy:

1. Client-side (React): Form-level validation for immediate user feedback. Never trusted by the server.
2. API layer (Zod): Every API route validates its input against a Zod schema before any processing. Invalid input is rejected with a 400 status and detailed validation errors.
3. Database layer (Prisma): The Prisma schema enforces types, constraints, and relationships at the ORM level.
4. Database layer (PostgreSQL): Column types and constraints provide a final safety net.

12.4 Error Boundaries

The application uses error boundaries at multiple levels to prevent a single error from cascading:

• React Error Boundaries catch rendering errors in the frontend without crashing the entire application.
• API routes wrap all handlers in try/catch to return structured error responses rather than stack traces.
• Audit log writes are isolated so that a logging failure never blocks a patient-facing request.
• PHI decryption failures (e.g., during encryption key rotation) gracefully fall back rather than corrupting data.

12.5 Security-First Dependency Choices

PHI encryption uses only the Node.js native crypto module — zero external dependencies for the most security-critical code path. The JWT library (jose) is a widely-audited, standards-compliant implementation. Dependencies are kept minimal to reduce the attack surface.

13. Deployment Pipeline

13.1 Docker Build Process

IntakeIQ uses a multi-stage Docker build that produces a minimal production image:

# Stage 1: Install production dependencies only
FROM node:20-alpine AS deps
COPY package.json package-lock.json* ./
RUN npm ci --omit=dev

# Stage 2: Build the Next.js application
FROM node:20-alpine AS builder
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npx prisma generate
RUN npm run build

# Stage 3: Production runtime (minimal)
FROM node:20-alpine AS runner
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
USER nextjs   # Non-root execution
CMD ["node", "server.js"]

13.2 Deployment Flow

14. Future Roadmap

15. Conclusion

IntakeIQ represents a purpose-built, HIPAA-compliant approach to dental patient intake automation. Every architectural decision — from the choice of AES-256-GCM for field-level PHI encryption to the 15-minute sliding window session timeout to the append-only audit log with 7-year retention — was made with healthcare regulatory requirements as a primary design constraint, not an afterthought.

The platform's technology choices (Next.js, TypeScript strict mode, Prisma ORM, Zod validation, AWS HIPAA-eligible infrastructure) reflect a deliberate balance between developer velocity and security rigor. The monolithic-first architecture keeps the compliance surface area small while supporting clear scaling paths through horizontal ECS scaling and managed AWS services.

IntakeIQ's AI integrations — Claude for intelligent intake processing and Textract for insurance card OCR — demonstrate how AI can meaningfully reduce administrative burden in dental practices without compromising patient safety or data security. The platform's governance model ensures that AI always assists rather than replaces clinical and administrative judgment.

For technical questions, security reviews, or to request a detailed architecture walkthrough, please contact the IntakeIQ engineering team.