HIPAA Compliant Software: What It Actually Requires

Key numbers

• 3 safeguard types required by the HIPAA Security Rule: administrative, physical, and technical
• 45 CFR 164.312(b) is the exact citation for the audit-controls requirement, one of the technical safeguards
• 2 HIPAA-aligned platforms shipped in production under our own build process: a compounding-pharmacy platform and a medical-billing audit platform
• A 7-year immutable audit log built for a compounding-pharmacy network's routing and consent workflows
• 490+ unit tests and a strict typecheck gate verified against numbered requirements before merge on that same build

What "HIPAA compliant software" actually means

HIPAA is a federal law, not a badge. The part of it that governs software is the Security Rule, codified at 45 CFR Part 160 and Subparts A and C of Part 164. It requires covered entities and their business associates to implement administrative, physical, and technical safeguards to protect electronic protected health information, or ePHI. That is the whole cover concept: three safeguard categories, one set of rules, no external stamp of approval.

Nobody at HHS reviews your codebase and hands you a certificate. There is no "HIPAA compliant" seal you buy and post on your homepage. What exists instead is a body of controls you either have in place or do not, and a Business Associate Agreement (BAA) that makes the legal relationship explicit between you and anyone who processes PHI for you. When a vendor says "HIPAA certified," they are either confused about the law or hoping you are. Our security page and FAQ say this directly: there is no such thing as HIPAA certification, and we do not claim one. What we do instead is sign BAAs on request and build to the safeguard requirements, which is the honest and legally meaningful claim.

This matters for evaluating any vendor, not just us. If a proposal or a sales deck uses the phrase "HIPAA certified software," ask what they mean. The correct phrase, and the one to expect from anyone who actually understands the regulation, is "HIPAA-aligned controls" backed by a signed BAA.

The three safeguards the Security Rule actually requires

The Security Rule groups every requirement into three buckets. Miss any one of the three and the system is not compliant, regardless of how strong the other two are.

• Administrative safeguards. Policies, workforce training, access management, incident response procedures, and a designated security official. This is the paperwork and process layer, but it is not optional paperwork. It defines who can touch PHI and under what conditions, and it is the layer auditors check first.
• Physical safeguards. Facility access controls, workstation security, and device and media controls. For a cloud-hosted system, this mostly resolves to your cloud provider's physical security posture (data center access, hardware disposal) plus your own device policies for anyone who can reach the data.
• Technical safeguards. Access control, audit controls, integrity controls, and transmission security, implemented in the code and infrastructure itself. This is where engineering does the actual work: authentication, encryption in transit and at rest, and logging that proves who touched what and when.

A concrete example makes the technical bucket less abstract. Audit controls are required under 45 CFR 164.312(b): "implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." That is not a suggestion to log some events. It is a requirement to record who accessed or altered a record, and to be able to reconstruct that history on demand.

In our own builds, that requirement shows up as audit-log middleware that wraps every read and write against PHI-bearing tables, and as a policy that any schema change touching those tables goes through a reviewed migration, not an ad-hoc alteration. The migration itself is reviewable evidence: what changed, who approved it, when it shipped. On the compounding-pharmacy platform described below, that same principle scaled up to a seven-year immutable audit log across the entire routing and consent workflow, because a missed entry in that log is a compliance failure, not a bug to patch next sprint.

Business Associate Agreements: the part most teams skip

If a vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity, that vendor is a business associate under HIPAA, and the relationship requires a signed BAA. This is not optional paperwork you can substitute with a security questionnaire. It is the legal instrument that makes the vendor contractually responsible for the safeguards above, and it is the first document a compliance-conscious buyer should ask for before any PHI touches a system.

We sign BAAs on request, as stated on our security page. That commitment sits alongside a SOC 2 Type II report available under NDA, and a deployment model where the client's data lives in the client's own cloud account or VPC from week one, not in an environment we control. If we disappeared tomorrow, the system keeps running under the client's own infrastructure, because nothing in it is licensed through us. That separation matters for a BAA conversation: a vendor who wants shared infrastructure or a license-back clause is asking for more control over PHI than the agreement should grant.

How we build to the safeguard requirements

Our general delivery model is described on the pods page and the how it works page: a matched pod starts within five business days of a kickoff session, ships weekly, and works inside the client's own repository from the first commit. For a HIPAA-aligned build, the same process runs with the safeguard requirements folded into the spec before code starts.

1. Spec the requirements as numbered items, not a paragraph of intent. Every safeguard the build needs (access control on a given surface, audit logging on a given table, encryption on a given field) becomes a discrete, checkable requirement.
2. Build against the spec, phase by phase. Each phase is verified against its numbered requirements by a reviewer before it merges, rather than accumulating undocumented shortcuts that get discovered in a later audit.
3. Route AI-assisted code through the same gate as any other code. A pull request in the client's repository, review by the named engineer who owns that surface, typed contracts, and tests in CI. No PHI-adjacent code merges on a model's output alone.
4. Treat schema changes touching PHI as reviewed migrations. This is the mechanism behind the audit-controls requirement in 45 CFR 164.312(b): a record of what the schema looked like, who changed it, and why.
5. Hand over the whole system, including its compliance evidence. Repository, migrations, deploy pipeline, documentation, and the test suite that proves the safeguards hold.

The pattern is visible in the compounding-pharmacy build described in more detail on the pharmacy routing and audit log post: product-level pharmacy routing with failover, dual prescriber paths, consent and e-signature, KYC, and a seven-year immutable audit log, built spec-first across clinic, patient, and platform-admin surfaces. Eleven epics shipped behind that spec gate, with 490+ unit tests, a strict TypeScript typecheck held green throughout, and patient-facing screens passing WCAG 2.1 AA. None of that is a claim in a deck. It is a set of tests that either pass in CI or the build does not merge.

The same discipline runs on a second production system: a Medicare/Medicaid medical-billing audit platform, also built and shipped HIPAA-aligned. Two live systems, not a hypothetical.

What HIPAA compliant software costs

There is no separate "HIPAA pricing tier." The safeguard requirements add engineering discipline (more review gates, more logging, more test coverage on PHI-adjacent code), not a different pricing model. Here is how our published pricing maps against the alternative of hiring the safeguard work in-house.

Option	Monthly cost	Team on the build	Fit for a HIPAA-aligned build
Builder Pod	$5,000/month	Pod lead + 2-engineer bench, one build track	Single HIPAA-aligned surface (a patient portal, a billing module)
Growth Pod	$10,000/month	Pod lead + 3-engineer bench, two build tracks	Two concurrent surfaces (clinic-facing and patient-facing at once)
Enterprise Pod	Custom	Senior lead + 3-8 engineers, 3+ build tracks	Multi-surface platforms across departments, architecture ownership
In-house senior hire	~$250,000+/year, fully loaded*	One engineer, ramping over months	Works, but safeguard expertise has to already exist on the team, or be learned on the job

*An estimate for a fully loaded US senior engineer, not a fixed figure. It varies by role, region, and benefits structure, and it does not include the 3-6 months a hiring cycle typically takes before the person starts shipping.

All three pods are month-to-month with a 30-day cancellation notice, billed on capacity rather than hours, with no statements of work and no change orders for ongoing work. Full detail lives on the pricing page.

When a pod fits a HIPAA build, and when it doesn't

A pod fits when the work is defined enough to spec against numbered requirements and the team needs senior engineers who have already built PHI-adjacent systems rather than learning the safeguard requirements for the first time in production. It also fits when the timeline does not allow for a 3-6 month hire cycle before a compliance-sensitive build even starts.

The safeguard categories apply regardless of the size of the practice. A dental office replacing its patient intake and scheduling system carries the same three safeguard obligations as a hospital system, just at a smaller surface area, and often with a smaller in-house team to carry them. Our guide to dental IT services covers what that looks like in practice, from patient portals to imaging pipelines.

A pod is the wrong tool when the organization needs a full-time compliance officer embedded in daily operations, or when the safeguard gap is entirely administrative (policy documents, workforce training programs, a HIPAA risk assessment) rather than a build problem. Those are real and necessary, but they are not engineering work, and no engineering team, ours included, should be the vendor for a workforce-training policy. If the gap is purely administrative, the right move is a compliance consultant or a dedicated privacy officer, not a build team.

A pod is also the wrong tool for a one-off audit of an existing system with no build attached. If nothing is shipping, a pod's weekly-ship cadence has nothing to ship.

A pre-build checklist for HIPAA compliant software

Before any PHI touches a new system, confirm each of the following:

• A signed BAA exists between you and every vendor that will create, receive, maintain, or transmit PHI, including your engineering vendor.
• Administrative safeguards are documented: who has access, how access is granted and revoked, and who is the designated security official.
• Physical safeguards are covered by your cloud provider's data center controls, plus your own device and workstation policy for anyone with access.
• Technical safeguards are specified per surface: access control on each PHI-bearing table, audit logging per 45 CFR 164.312(b), encryption in transit and at rest, and a defined transmission-security approach.
• Schema changes touching PHI go through a reviewed migration process, not direct database edits.
• AI-assisted code, if used anywhere in the build, goes through the same PR review, typed contracts, and CI test gate as any other code, and no PHI is used to train a model unless that is explicitly requested and agreed.
• The build deploys into your own cloud account or VPC, with your organization owning the code, data, and IP outright.
• A SOC 2 Type II report (yours or your vendor's) is available under NDA if a customer or auditor asks for it.

Is ChatGPT HIPAA compliant

Short answer: not by default, and not on its own. OpenAI's Help Center states that ChatGPT Free, Plus, Pro, Team, and self-serve Business are not eligible for a Business Associate Agreement, and that BAA eligibility runs through the API platform and sales-managed Enterprise or Edu accounts (OpenAI Help Center, accessed August 2026). So PHI should not be entered into a consumer tier at all. And even where a BAA is available, "the model has a BAA" is not the same as "the system built around it is compliant." Logging, access control, retention, and audit trails on the application layer around the model still have to meet the same three safeguard categories described above. A longer walkthrough of what changes and what doesn't lives at is ChatGPT HIPAA compliant.

The short version

There is no HIPAA certification to buy, only a Security Rule with three safeguard types (administrative, physical, technical) and a BAA requirement for anyone touching PHI on your behalf. Audit controls under 45 CFR 164.312(b) are a specific, checkable technical requirement, not a general logging suggestion. We sign BAAs on request, deploy into the client's own cloud account, and have shipped two HIPAA-aligned production platforms, a compounding-pharmacy system with a seven-year immutable audit log and 490+ unit tests, and a Medicare/Medicaid medical-billing audit platform, both built spec-first against numbered requirements before any code merged.