HIPAA Platform Built in 27 Hours

Anton · CTO & Co-Founder, OneChair

The Challenge — A Founder With a Vision and a Deadline

The founder of WellChild had been working in pediatric healthcare administration for over a decade. She had seen the same problem play out hundreds of times: parents navigating a phone-based scheduling system that booked appointments through a front desk, could not accommodate multiple providers simultaneously, had no online patient portal, and stored records in a combination of practice management software and paper files that no integration layer touched.

Her vision was direct: a platform that allowed parents to book appointments online, see which provider was available at which time, manage their child's records digitally, and receive automated reminders — while giving clinicians a dashboard that showed their schedule, patient history at a glance, and an audit trail that satisfied HIPAA requirements without creating extra administrative work.

She had been quoted by two agencies. The first quoted $180,000 and seven months. The second quoted $220,000 and nine months. Both numbers included a compliance consultant engagement that was billed separately. Neither included ongoing maintenance beyond a 90-day warranty period.

She had the funding. She did not have nine months. Her target provider network had a contract renewal cycle that created a hard window: she needed a working system to demonstrate within eight weeks, or the opportunity would close until the following year.

When she came to OneChair, the conversation was straightforward. We reviewed the requirements, asked the questions that shaped the architecture, and issued a fixed-price quote for the complete system. Build time: 27 working hours from approved plan to production-ready delivery.

Why HIPAA Compliance Usually Takes Months

Before explaining what we did, it is worth understanding why HIPAA compliance genuinely adds timeline in traditional development — and why the specific causes of that timeline are different with AI-orchestrated development.

HIPAA's Security Rule requires specific technical safeguards: encryption of electronic protected health information (ePHI) at rest and in transit, access controls that limit system access to authorized users, audit controls that record activity in systems containing ePHI, and transmission security that protects ePHI moving across networks. These are technical requirements, not policy requirements — they need to be built into the system at the architectural level.

In traditional development, compliance is often addressed as a separate workstream that runs alongside (and frequently in tension with) the feature development workstream. The compliance consultant reviews the architecture and issues findings. The development team addresses those findings, which sometimes requires rework of components that were built without sufficient compliance consideration. The review-rework cycle repeats until the system meets the standard. This cycle is where the months accumulate.

The root cause is that compliance was not designed in from the start. It was validated at the end, after the architectural decisions that created compliance gaps had already been made and built upon.

In AI-orchestrated development, compliance requirements are architectural constraints that the agent team works from the beginning. The encryption is specified in the data model. The access controls are specified in the API contracts. The audit logging is a defined output of every operation that touches ePHI. Agents do not build and then check for compliance — they build to the compliance specification from the first commit. There is no review-rework cycle because the compliance gaps are resolved before any code is written.

How We Built WellChild in 27 Working Hours

The 27 hours is total build time — the time from the start of active agent work (after plan approval) to a production-ready system ready for client review. It does not include the planning phase, which took a separate two days of human architect and engineer time to produce the technical specification and HIPAA compliance architecture that the agents built from.

Hours 1–4: Infrastructure and Data Model

Database schema agents designed the full data model with HIPAA constraints embedded: ePHI fields marked explicitly, encryption annotations on fields containing personal health data, foreign key relationships between patients, providers, appointments, and records. Infrastructure agents provisioned the base environment: PostgreSQL with encryption at rest, Redis for session management, the CI/CD pipeline, and the staging deployment. By hour four, the database was live with seed data and every ePHI field encrypted.

Hours 5–10: Core Backend Services

Backend agents built the service layer in parallel across four service domains: authentication and authorization (multi-role: parent, provider, admin, super-admin), patient management (create, read, update, archive with full audit trail), appointment management (booking, confirmation, cancellation, rescheduling with conflict detection), and provider management (schedules, availability windows, multi-provider routing). Every endpoint wrote audit log entries. Every response to authenticated requests included only the data that the requesting role was authorized to see.

Hours 11–16: Patient-Facing Application

Frontend agents built the parent-facing portal: account creation and verification, child profile management, provider browsing and availability display, appointment booking flow (select provider, select date and time, confirm and receive confirmation number), appointment history, and the notification preferences panel. This is 54 screens in the patient application. Every data input field validated against the data model specification. Every form submission handled loading, error, and success states.

Hours 17–22: Clinical Dashboard

The clinical side required a different interaction model than the patient portal. Providers needed their daily schedule at a glance, patient arrival status, appointment history for context, and the ability to add clinical notes that populated the audit log. Admins needed a broader view: all providers, all appointments, capacity metrics, and the compliance report generation that the practice would need for HIPAA audit purposes. 62 screens across the clinical application, including a reporting module that could generate the audit logs in the format required for HIPAA compliance reviews.

Hours 23–27: Testing, Security Review, and Final Integration

Testing agents ran the full test suite: 847 unit tests, 124 integration tests covering every API endpoint, and 38 end-to-end tests simulating the critical user flows. Security agents ran static analysis against the complete codebase. The human security engineer ran a targeted penetration test against the authentication layer and the ePHI access controls — the two areas where HIPAA violations carry the heaviest consequences. Documentation agents generated the full API documentation and the HIPAA compliance documentation package. Final build: 116 screens, production-ready.

The Technical Architecture

WellChild runs on a modern, maintainable stack with no exotic dependencies:

• Frontend: Next.js 14 with TypeScript, server-side rendering for the patient portal to improve initial load performance on mobile networks, client-side rendering for the clinical dashboard where real-time updates matter more than initial load speed.
• Backend: NestJS with TypeScript, organized into domain modules (patients, providers, appointments, notifications, reports) with clear service boundaries and no cross-module database access.
• Database: PostgreSQL with row-level security policies that enforce data access at the database layer, not only at the application layer. Even a compromised application server cannot read ePHI for providers or patients outside the authorized scope.
• Encryption: AES-256 encryption for ePHI fields at rest using a key management service. TLS 1.3 for all data in transit. Encrypted backups with separate key management from the production encryption keys.
• Authentication: JWT-based authentication with short-lived access tokens (15 minutes) and longer-lived refresh tokens (7 days) stored in HttpOnly cookies. Multi-factor authentication required for clinical users.
• Audit Logging: Every operation that creates, reads, updates, or deletes ePHI writes a structured audit log entry including the user identity, the action, the data accessed (by record type and ID, not by value), the timestamp, and the IP address. Audit logs are write-only — they cannot be modified or deleted through the application.
• Notifications: Email (AWS SES) and SMS (Twilio) for appointment confirmations and reminders. Notification preferences managed at the patient account level. All notification content reviewed for ePHI minimization.

HIPAA Compliance — What We Implemented

HIPAA has three rules that affect software systems: the Privacy Rule (what you can collect and how you can use it), the Security Rule (technical and physical safeguards for ePHI), and the Breach Notification Rule (what you do when something goes wrong). WellChild's architecture addresses all three.

Encryption

All ePHI is encrypted at rest using AES-256. All data in transit is encrypted using TLS 1.3. Encryption keys are managed separately from the data they protect, using a dedicated key management service. Key rotation is automated and the rotation schedule is configurable from the admin dashboard. Encrypted backups run nightly to a geographically separate storage location.

Access Controls

Role-based access control with four roles: patient (can view and manage their own records), provider (can view records for their own patients), admin (can manage the practice's data and generate compliance reports), and super-admin (system configuration only, no access to patient ePHI). Roles are enforced at three layers: the API middleware, the service layer, and the database row-level security policies. Access to any ePHI requires an authenticated session with an unexpired access token.

Audit Trails

Every access to ePHI generates an audit log entry. The log captures who accessed the data (authenticated user identity), what action was performed (read, create, update, archive), which records were involved (by type and ID), when it happened (UTC timestamp), and where the request originated (IP address and user agent). The audit log is append-only and stored in a separate, read-only database role from the application database user. HIPAA requires audit logs to be retained for a minimum of six years — WellChild's implementation retains them for seven, configurable from the admin panel.

Business Associate Agreement

OneChair executes a Business Associate Agreement (BAA) with every healthcare client. The BAA defines how OneChair handles ePHI during the development process and what obligations apply when the system is handed over. This is a legal requirement for any entity that creates, receives, maintains, or transmits ePHI on behalf of a HIPAA-covered entity. The BAA template we use has been reviewed by a healthcare compliance attorney.

The Results

WellChild launched into the provider network on schedule. The founder had her working demo within the window that the contract renewal cycle required.

• 97% faster than the nine-month timeline quoted by the second agency
• 116 screens across the patient-facing portal and clinical dashboard
• Full HIPAA compliance with encryption, access controls, audit trails, and BAA documentation
• Production-ready from delivery — no post-launch rework for compliance gaps
• Complete code ownership — the client owns the full source code with no ongoing dependency on OneChair

The compliance documentation package delivered with the system included the technical specification for each HIPAA safeguard implemented, the audit log schema and retention policy, the encryption key management documentation, the penetration test report summary, and the completed Security Rule checklist. This package is what a HIPAA auditor would request. It was generated as part of the build, not assembled separately afterward.

Lessons Learned

The WellChild build confirmed several things we had theorized but not tested at this scope. HIPAA compliance does not require a separate compliance workstream when it is treated as an architectural constraint from the beginning. The audit log and encryption requirements add complexity to the data model — but they are deterministic complexity, which means agents handle it systematically. The review-rework cycle that inflates traditional HIPAA timelines is a consequence of late compliance review, not of compliance itself.

The planning phase matters more on regulated projects than on standard builds. Two days of human architect time spent defining the compliance architecture before the agents started produced a foundation that the entire 27-hour build stood on. A gap in the compliance specification at the planning stage would have required agent rework mid-build — the equivalent of discovering an architectural flaw after the walls are framed.

The penetration test revealed one finding: a rate-limiting gap on the appointment booking endpoint that could have been used to enumerate provider availability in ways that exposed information about provider schedules. It was patched in a 45-minute remediation cycle before delivery. This is exactly the category of finding that automated security scanning misses — it required a human tester thinking adversarially about the specific use case, not running a generic vulnerability scan.

For the complete case study with screenshots and technical detail, see the WellChild project page. If you are building a healthcare application or need HIPAA-compliant software, the free audit is the right starting point — see our custom software service for more context on how the process works. To understand why the methodology makes this timeline possible, see What Is AI-Orchestrated Development?