What HIPAA-Compliant Software Development Actually Requires

"HIPAA-compliant software" means software built so a covered entity or business associate can meet the HIPAA rules: administrative, physical and technical safeguards, a signed Business Associate Agreement with every vendor that touches patient data, minimum-necessary access, audit logs, encryption, and breach notice to patients within 60 days. HHS runs no certification, so no software is "HIPAA certified" on its own.

If you would rather have the software built for you, see how RAITHub would build this below.

This is engineering guidance, written for founders and product teams building for US healthcare. It is general information, not legal advice; confirm with your adviser. RAITHub makes no HIPAA compliance claim, holds no certification and does not sign Business Associate Agreements. What it does is build software so patient data stays inside your own BAA-covered cloud account, with synthetic data in development.

Is there such a thing as HIPAA-certified software?

No. Google states it directly: "The U.S. Department of Health and Human Services (HHS) doesn't offer a certification program for HIPAA compliance". Microsoft's Azure documentation says the same, and adds that using Azure "doesn't automatically impart compliance onto your cloud solutions".

HIPAA obligations sit on organisations, not on code. They apply to covered entities (health plans, clearinghouses and providers that bill electronically) and to their business associates, the vendors that create, receive, maintain or transmit protected health information (PHI) on their behalf, as defined in 45 CFR 160.103. If you sell software that stores PHI for clinics, you are probably a business associate, and the compliance programme is yours: policies, training, a risk analysis, contracts and safeguards.

So when a buyer asks for "HIPAA-compliant software", the honest translation is: software whose design lets the covered entity and its business associates meet their duties, and does not quietly undermine them. That is a set of engineering decisions, and most of this page is about them.

What does the HIPAA Security Rule actually require from software?

The HHS summary of the Security Rule groups the requirements into three kinds of safeguard for electronic PHI (ePHI). Each standard has implementation specifications marked either "required" or "addressable". Addressable does not mean optional: you implement it, or document why an equivalent measure is reasonable instead.

• Administrative safeguards (45 CFR 164.308): a security management process starting with risk analysis, defined as "an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information"; a named security official; workforce access controls; training; incident procedures; a contingency plan; periodic evaluation; and business associate contracts.
• Physical safeguards (45 CFR 164.310): facility access, workstation use and security, and device and media controls, including disposal and re-use. In a cloud product most of the data-centre side is the provider's job under its BAA; laptops, phones and exported files are still yours.
• Technical safeguards (45 CFR 164.312): access control with unique user identification (required), emergency access (required), automatic logoff and encryption (addressable); audit controls; integrity; person or entity authentication; and transmission security.

The technical safeguards are where developers do most of the work. Audit controls, for example, are a required standard: "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information".

The rule may tighten. In January 2025 HHS published a proposed Security Rule update that would remove the required/addressable split and make encryption and multi-factor authentication expected, with limited exceptions. Check its current status before you plan; building to the proposed bar now costs little and avoids a retrofit.

What is a Business Associate Agreement, and who has to sign one?

A Business Associate Agreement (BAA) is the contract a covered entity must have with each business associate, and that a business associate must have with each subcontractor that handles PHI. The HHS sample BAA provisions show what it covers: permitted uses and disclosures, safeguards, reporting of breaches and security incidents, flowing the same terms down to subcontractors, giving individuals access to their data, and returning or destroying PHI at the end.

For software teams the BAA chain is a product constraint, not paperwork. Every service that stores or processes PHI needs a BAA with you: hosting, database, file storage, email and SMS, error tracking, logging, analytics, support desk and any AI model provider. HHS's guidance on cloud computing says a cloud provider that stores ePHI is a business associate even if the data is encrypted and the provider holds no key. A vendor that will not sign a BAA cannot see PHI, which usually means scrubbing PHI from logs, error reports and analytics events before they leave your system.

What does "minimum necessary" mean in an app?

The minimum necessary standard requires reasonable efforts "to limit protected health information to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request", in the words of 45 CFR 164.502(b). There are exceptions, notably disclosures to a provider for treatment and disclosures to the patient.

In code, minimum necessary turns into role-based access that limits rows and columns, not just screens. A billing user needs the insurance member ID, not the medication list. A support agent needs a name to find the account, not a diagnosis. API responses should return only the fields the caller's role needs, because hiding a field in the UI still sends it to the browser.

How should audit logs, encryption and breach notification work?

Audit logs. Log reads as well as writes: who viewed which patient, when, and why. Make the log append-only for the application's database user, keep it out of reach of the people it records, and give compliance staff a way to review it. If you are designing one from scratch, the SaaS audit log design guide covers schema and retention.

Encryption. Encrypt ePHI in transit (TLS everywhere, including between internal services) and at rest (encrypted disks, database and backups, with keys in a managed key service). Encryption also matters for breach notification: the duty applies to "unsecured" PHI, and HHS's guidance on rendering PHI unusable treats data encrypted to the NIST-referenced standards, with the key kept separate, as secured.

Breach notification. Under the Breach Notification Rule, a covered entity tells affected individuals "without unreasonable delay and in no case later than 60 calendar days after discovery of a breach" (45 CFR 164.404). A business associate must tell the covered entity on the same 60-day outer limit (164.410). Breaches affecting 500 or more people are reported to HHS at the same time as the individual notices; smaller ones within 60 days of the end of the calendar year (164.408). Your software has to make this possible: the audit log must answer "whose records did this account touch, and between which dates?" in minutes, not weeks.

What does a HIPAA engineering checklist look like?

A working checklist, mapped to the rule. Use it to brief developers and to prepare for a security review, not as proof of compliance.

Area	Rule reference	What the software does
Unique user IDs	164.312(a)(2)(i), required	No shared logins; every action ties to one person or service account
Authentication	164.312(d)	Strong passwords plus multi-factor authentication for staff; short-lived sessions
Automatic logoff	164.312(a)(2)(iii), addressable	Idle sessions end after a set time on shared clinic devices
Emergency access	164.312(a)(2)(ii), required	A documented break-glass role, heavily logged and reviewed after use
Minimum necessary	164.502(b)	Role-based access to rows and columns; API returns only permitted fields
Audit controls	164.312(b)	Append-only log of every PHI read and write, with reason codes
Integrity	164.312(c)	Database constraints, versioned records, no silent overwrites of clinical data
Transmission security	164.312(e)	TLS for all traffic, including internal services and webhooks
Encryption at rest	164.312(a)(2)(iv), addressable	Encrypted database, storage and backups; keys in a managed key service
BAA chain	164.308(b), 164.502(e)	PHI flows only to services under a signed BAA; PHI scrubbed from logs and error reports
Contingency plan	164.308(a)(7)	Tested backups and restore; a written recovery runbook
Breach readiness	164.404 to 164.410	Audit queries that list affected patients by account and date range
Non-production data	Risk analysis, 164.308(a)(1)	Development and staging use synthetic data only; no production copies

What does audit logging with minimum necessary look like in code?

A minimal TypeScript example with node-postgres. Each role reads only its permitted columns, and the read and its audit entry commit in one transaction, so there is no such thing as an unlogged read: if the log insert fails, the read fails too.

// patients/read.ts: role-limited read with a mandatory audit entry
import { Pool } from 'pg'

const pool = new Pool({ connectionString: process.env.DATABASE_URL })

type Role = 'clinician' | 'billing' | 'support'
type Actor = { userId: string; role: Role }

// Minimum necessary: fixed column lists per role (never from user input)
const COLUMNS: Record<Role, string[]> = {
  clinician: ['id', 'full_name', 'date_of_birth', 'allergies', 'medications'],
  billing: ['id', 'full_name', 'insurance_member_id'],
  support: ['id', 'full_name'],
}

export async function readPatient(actor: Actor, patientId: string, reason: string) {
  const client = await pool.connect()
  try {
    await client.query('BEGIN')
    const { rows } = await client.query(
      'SELECT ' + COLUMNS[actor.role].join(', ') + ' FROM patients WHERE id = $1',
      [patientId],
    )
    await client.query(
      'INSERT INTO phi_access_log (actor_id, actor_role, patient_id, action, reason) VALUES ($1, $2, $3, $4, $5)',
      [actor.userId, actor.role, patientId, 'read', reason],
    )
    await client.query('COMMIT')
    return rows[0] ?? null
  } catch (err) {
    await client.query('ROLLBACK')
    throw err
  } finally {
    client.release()
  }
}

And the log table, which the application can add to but never change:

CREATE TABLE phi_access_log (
  id          bigserial PRIMARY KEY,
  actor_id    text        NOT NULL,
  actor_role  text        NOT NULL,
  patient_id  text        NOT NULL,
  action      text        NOT NULL,
  reason      text        NOT NULL,
  at          timestamptz NOT NULL DEFAULT now()
);

-- The app's database user may insert, never edit or erase
REVOKE UPDATE, DELETE, TRUNCATE ON phi_access_log FROM app_user;
GRANT INSERT, SELECT ON phi_access_log TO app_user;

In a multi-tenant product, add row-level security so one clinic can never read another clinic's patients; the Postgres row-level security guide shows the pattern.

Which cloud providers sign a BAA, and how?

All three large clouds offer one, but each covers only listed services, and none makes your application compliant.

Cloud	How you get the BAA	What to watch
AWS	Accept it in AWS Artifact in the console, per the AWS HIPAA page	PHI may go only into HIPAA-eligible services listed by AWS, even inside a designated account
Google Cloud	Review and accept it in the console's privacy compliance settings, per the Google Cloud HIPAA page	Use only covered products; Google calls compliance "a shared responsibility"
Microsoft Azure	Included by default through the Product Terms and Data Protection Addendum, per the Azure HIPAA page	Only in-scope services are covered; Microsoft "doesn't inspect, approve, or monitor" your apps

The same check applies to everything else in the stack: email, SMS, error tracking and AI providers. Some offer a BAA only on higher plans; some not at all.

Buy, build or hire?

Most teams should not build every layer themselves. Prices below are list prices from each vendor's pricing page on 2 October 2026.

Option	Example	Choose this when
Off-the-shelf healthcare platform	Medplum: hosted Production plan $2,000 a month, standard BAA on paid plans; free tier has no BAA	You want a FHIR-native backend with compliance tooling and will build your own front end on it
No-code or template	Knack: HIPAA only on Enterprise or its Knack Health offering, price on request	An internal form-and-table tool for a small team, with simple workflows
Custom build on a HIPAA-ready host	Aptible: Production plan from $499 a month plus usage, BAA included	You have developers and want hosting controls and a BAA without running your own cloud account
Custom build in your own cloud account	AWS, Google Cloud or Azure under your BAA	The product is your business, you need full control of data and keys, and buyers will review your architecture

Building the technical safeguards into an existing small web app yourself is roughly 3–6 weeks of engineering for an experienced developer, as a rough planning figure. The main risk is not the code; it is PHI leaking sideways into a log, an error tracker or an analytics event from a vendor with no BAA.

Why RAITHub for this

RAITHub is a founder-led, QA-first software studio, founded in 2024 in Dhaka, Bangladesh, working with clients worldwide in English. It has not shipped a HIPAA-regulated product, and says so. What it can show is the engineering underneath:

• Health-adjacent client work. RAITHub's 8 client projects include a healthcare scheduling app.
• Permissions at scale. Sundor Skin, a B2B wholesale platform, runs on 146 PostgreSQL tables with row-level security, 88 permission codes and 12 staff roles, backed by 530+ tests. Minimum-necessary access is the same kind of problem. See the work page.
• Test-gated releases. TheSkinProof, the founder's own venture rather than a client project, has 217 API endpoints and 750+ automated tests. Access-control rules get tests, so a refactor cannot quietly widen who sees what.
• Your controls, your account. RAITHub signs NDAs and DPAs and works inside your controls. Production and patient data stay in your own BAA-covered cloud account; development uses synthetic data.
• Security reviews. If a hospital sends you a security questionnaire, the guide to a first questionnaire without SOC 2 covers how to answer honestly.

When you don't need us

• A configured product already fits. If an existing practice-management or EHR system with a BAA covers your workflow, configure it.
• You need a vendor that signs your BAA and holds PHI. RAITHub does not sign BAAs and is not set up to be your business associate. Choose a vendor that is.
• You need a compliance programme, not software. Risk analysis, policies and training belong with a HIPAA compliance consultant or counsel.
• Your buyer requires a certified vendor. RAITHub holds no SOC 2, ISO 27001 or HITRUST certification.
• You need a native mobile app. RAITHub builds web apps and PWAs only.

How RAITHub would build this

For a health startup building a patient-facing web app or clinic portal that will hold PHI in production:

• Architecture in your cloud account: deployed to your AWS, Google Cloud or Azure account under your BAA, using only covered services, with keys in your key service.
• Access and audit: role-based, minimum-necessary access to rows and columns, multi-factor authentication for staff, and an append-only access log with breach-scoping queries.
• A clean vendor chain: PHI scrubbing in logs, error tracking and analytics, and a written list of every service that could touch PHI, for your BAA review.
• Synthetic data everywhere below production: seed scripts that refuse to run against production; RAITHub's engineers never need real patient records.
• Evidence for reviewers: a mapped control list like the checklist above, ready for your compliance adviser and your customers' security teams.

Timeline: a fixed-scope MVP or SaaS build takes 4–6 weeks; a backend or API-heavy build, such as one with several integrations, takes 6–12 weeks. See SaaS development and API and backend development, or the HealthTech page and the health software guide for the wider context.

You receive: automated tests and CI, handover docs and runbooks (including restore and access-review procedures), and full IP under NDA.

Next step: book the free 15-minute technical audit, then you get a written fixed quote. Do not send PHI in the first message. Regulatory questions go to your adviser; this page is general information.

Frequently asked questions

Can software be HIPAA certified?

No. HHS runs no certification programme for HIPAA. Compliance belongs to covered entities and their business associates; software can support it with access controls, audit logs and encryption, but cannot provide it on its own.

Do I need a BAA with my cloud provider?

Yes, if the provider stores or processes PHI for you. HHS guidance treats a cloud provider that stores ePHI as a business associate even when the data is encrypted. AWS, Google Cloud and Azure all offer BAAs covering listed services.

Is encryption required under HIPAA?

Under the current Security Rule, encryption at rest and in transit is "addressable": you implement it or document an equivalent measure. In practice you should encrypt, because encrypted PHI to the HHS guidance standard is not "unsecured" for breach notification. A 2025 HHS proposal would make encryption expected.

How fast must a HIPAA breach be reported?

Covered entities notify affected individuals without unreasonable delay and no later than 60 calendar days after discovery. Business associates notify the covered entity within the same outer limit. Breaches of 500 or more people also go to HHS at the same time.

Does RAITHub sign BAAs or build HIPAA-compliant software?

No. RAITHub makes no compliance claim and does not sign BAAs. It builds so production and patient data stay in your own BAA-covered cloud account, uses synthetic data in development, and signs NDAs and DPAs.

What does minimum necessary mean for developers?

Each user and service should get only the PHI its job needs. In software that means role-based limits on rows and columns, and API responses that return only permitted fields rather than hiding them in the interface.