DEV Community: Joe Gellatly

The 2026 HIPAA Security Rule Checklist for Engineers at Small Healthcare Orgs

Joe Gellatly — Wed, 22 Apr 2026 18:13:10 +0000

If you build or run the tech stack for a clinic, FQHC, community health center, critical access hospital, ASC, or any small/mid-size healthcare organization, the 2026 HIPAA Security Rule amendments are the first meaningful update in two decades. Most of the public commentary has been about "encryption is now required" — true, but not the whole story. This is the engineer's version.

The one-paragraph summary

The 2026 amendments promote most previously-"addressable" Security Rule specifications to required. The practical effect: you need encryption everywhere ePHI lives or moves, MFA on every system that touches ePHI, a biannual vulnerability-scanning cadence plus annual penetration testing, a 72-hour breach-reporting pipeline to OCR for any breach affecting 500+ individuals, and a written, current asset inventory that ties every system back to your risk analysis. None of these are revolutionary on their own — but getting all seven right, documented, and defensible is a real engineering effort.

The seven pillars

1. Encryption — everywhere

What's required: ePHI encrypted at rest and in transit, using NIST-recognized cryptographic standards (FIPS 140-3 modules where feasible).

What this actually means:

Databases: TDE on SQL Server/Postgres/MySQL, or equivalent.
Object storage: SSE-KMS for S3, Customer-Managed Keys for Azure Blob, CMEK for GCS.
Endpoints: BitLocker / FileVault / LUKS on every device with potential ePHI access.
Backup: encrypted at rest AND in transit; check your backup tool's actual settings.
Fax / scan-to-email bridges: end-to-end encryption, not just transport TLS.
Archived data: often the biggest miss. Tape archives and legacy backups frequently sit unencrypted.

Engineering gotcha: "encryption in transit" means TLS 1.2+ on every path, including internal East-West traffic in your VPC. If your service mesh has plaintext between pods, that's a finding.

2. MFA — no exceptions

What's required: MFA on any system that creates, receives, maintains, or transmits ePHI.

The breakdown by system class:

EHR / PM / LIS / RIS: MFA mandatory. Most modern vendors support it; the work is enforcement and enrollment tracking.
Remote access: VPN + MFA. No more split-tunnel exception lists.
Cloud admin: IAM with MFA, no console-root users without hardware MFA.
Email: MFA mandatory. O365/Google Workspace conditional access policies.
Shared workstations (nursing stations, pre-op, front desk): this is the hardest part. Most real-world implementations use proximity badges + PIN with short session timeouts. Design this before audit, not during.
Credentialed-but-not-employed clinicians: same MFA standard, even though they're 1099 / credentialed staff.

Engineering gotcha: service accounts that touch ePHI need documented MFA equivalents (key rotation, conditional access, secrets management). "This is a service account so MFA doesn't apply" is not a defensible answer.

3. Biannual vulnerability scanning

What's required: Formal vulnerability scanning at least twice a year, documented, with findings tied back to the risk analysis.

What "formal" means:

Scope includes every ePHI-handling system (apps, infrastructure, and the infrastructure the apps run on).
Authenticated scans where feasible, not just unauthenticated perimeter checks.
Output is a written report with findings, severity, and remediation owner.
Findings get closed out or accepted with documented justification.

Tooling: commercial scanners (Qualys, Tenable, Rapid7) or managed offerings from security vendors. Open-source options (OpenVAS) work if you have the ops discipline.

4. Annual penetration testing

What's required: At least one formal penetration test per year, scoped to cover ePHI-handling systems.

Scope baseline for a small healthcare org: external perimeter, the identity perimeter (O365/Workspace), the EHR and its patient portal, any web applications you own, and the VPN/remote-access infrastructure. For larger orgs, add internal network, cloud, and application-layer testing.

Engineering gotcha: don't conflate vulnerability scanning with penetration testing. A scan enumerates known CVEs. A pen test is a human trying to break in. OCR expects both.

5. 72-hour breach reporting

What's required: For breaches affecting 500+ individuals, OCR notification within 72 hours of discovery (tighter than the pre-2026 60-day rule).

Operational implication: the 72-hour clock starts when the organization discovers the breach, not when investigation concludes. You need:

A monitored intake path for suspected-breach reports.
A triage process that moves from "suspected" to "confirmed" within 24 hours.
Documented legal and PR review in parallel, not sequentially.
A pre-drafted OCR notification template with fillable scope/affected-count fields.

For breaches under 500 individuals, the annual HHS notification rule still applies; the 72-hour accelerant is specific to the large-breach path.

6. Written asset inventory

What's required: A current, written inventory of every system that creates, receives, maintains, or transmits ePHI, tied back to the risk analysis.

What "current" actually means: updated whenever a system is added, removed, or materially changed. Point-in-time CMDB snapshots aren't enough — the inventory has to be maintained.

Minimum inventory fields:

System name
Type (EHR, PM, LIS, RIS, email, file storage, etc.)
Vendor
Owner (technical + business)
Data classification (does it touch ePHI?)
Encryption status (at rest, in transit)
MFA status
Backup / DR arrangement
BAA status (if vendor-hosted)
Last risk-analysis coverage date

7. Documented, up-to-date risk analysis

What's required: A Security Risk Analysis (SRA) that is current (annually at a minimum, plus after material changes) and covers every ePHI-handling system, site, and vendor relationship.

What it isn't: a generic checklist. OCR has repeatedly taken action against organizations whose SRA was templated, stale, or not tied to actual systems and workflows.

What it is:

Scope definition (every ePHI system, every site, every BAA-covered vendor).
Threat and vulnerability analysis.
Likelihood and impact rating per identified risk.
Current controls and residual risk.
A risk management plan with owned, dated remediation steps.
Evidence that the plan is actually being executed.

The 48-hour engineering readiness check

If OCR opened a compliance review tomorrow, could you produce, within 48 hours:

[ ] A current SRA with a risk management plan and dated remediation owners
[ ] An asset inventory showing every ePHI-handling system, its encryption status, and its MFA status
[ ] Evidence of the most recent vulnerability scan (date, tool, scope, findings, remediation)
[ ] Evidence of the most recent penetration test (date, scope, findings, remediation)
[ ] A signed BAA for every vendor in your inventory that touches PHI
[ ] Training records for every current employee, with attestations and dates
[ ] A 72-hour incident-response playbook (triage path, template OCR notification, legal review)

A "no" or "I'm not sure" on any of those is a gap worth closing before Q3 2026.

Where to go deeper

If you want the segment-specific versions of this:

HIPAA compliance for FQHCs — for community health centers.
HIPAA for critical access hospitals — for sub-25-bed rural hospitals.
Best HIPAA risk assessment tools for 2026 — buyer's guide.
HIPAA compliance cost — what the program actually costs.
HIPAA vulnerability scanning requirements and penetration testing requirements — deep dives on two of the pillars above.

If you're the engineer on the hook for making all seven pillars real, pick the weakest one, ship documentation for it this month, and rotate through the others. Don't try to turn the whole ship at once — the SRA is the right anchor, because everything else hangs off it.

Disclosure: I'm the founder/CEO of Medcurity, which builds HIPAA compliance software for small and mid-size healthcare organizations. This post is the engineering-focused version of our written guides and isn't legal advice.

Critical Access Hospital Cybersecurity: Building HIPAA Compliance on a Shoestring Budget

Joe Gellatly — Tue, 21 Apr 2026 04:56:41 +0000

Critical Access Hospital Cybersecurity: Building HIPAA Compliance on a Shoestring Budget

If you're managing IT for a Critical Access Hospital (CAH), you know the struggle is real. You're stretched thin, your budget is tighter than a medical suture, and now the 2026 HIPAA Security Rule updates are knocking on your door with some pretty serious demands. But here's the thing: compliance doesn't have to cost a fortune, and security isn't just possible on a limited budget—it's mandatory.

Let me break down how CAHs can build a robust cybersecurity posture without breaking the bank.

What Makes CAHs Different (And Vulnerable)

Before we dive into compliance mechanics, let's talk about what makes Critical Access Hospitals unique—and why standard healthcare IT approaches don't always fit.

The CAH Definition

The Centers for Medicare & Medicaid Services (CMS) defines CAHs with pretty specific parameters:

25-bed maximum (or 35 beds if you're using 96-hour patient stays)
Average length of stay of 96 hours or less
Swing beds that function as both acute care and long-term care
Located in underserved rural areas

These constraints force CAHs into a different operational reality than larger hospitals. You're not running a 500-bed medical center with a dedicated IT department of 20+ people. You might have one IT director, maybe one tech, and a lot of prayers.

The Budget Reality

Here's what makes CAH cybersecurity particularly challenging: rural hospitals have limited revenue streams. Many serve Medicare/Medicaid-heavy populations, insurance reimbursement rates are often lower, and you're competing for talent with bigger health systems just 30 minutes away. Your IT budget? Let's be honest—it's probably 30-40% of what you'd need for a comparable non-rural facility.

Yet you're handling the exact same Protected Health Information (PHI) as everyone else. You're subject to the same HIPAA requirements. The stakes are identical.

2026 HIPAA Security Rule Changes: What's New?

The updated HIPAA Security Rule isn't just a gentle nudge—it's a significant tightening of requirements. Here's what CAHs need to focus on immediately:

1. Mandatory Encryption (Everywhere)

Previously, encryption was recommended for certain data in transit. Now it's mandatory for:

All data at rest (stored files, databases, backups)
All data in transit (email, file transfers, cloud storage)
Mobile device storage

For CAHs: This means every laptop, every external drive, every cloud backup needs encryption enabled. No exceptions. The good news? Most modern systems have encryption built in. Windows BitLocker, macOS FileVault, and iOS/Android encryption are native—you just need to turn them on and manage the keys.

2. Multi-Factor Authentication (MFA) Requirements

MFA is now essentially non-negotiable for anyone accessing PHI. This includes:

Remote access systems
Electronic health record (EHR) systems
Email and file storage
Administrative systems

For CAHs: With limited IT staff managing access, MFA actually reduces your burden by hardening systems against the most common attack vector—credential compromise. A small investment in an authenticator app or hardware tokens pays dividends.

3. 72-Hour Breach Notification

The reporting timeline has compressed from 60 days to 72 hours. This is aggressive, and it requires:

Incident detection systems
Clear escalation procedures
Documented breach response plans

For CAHs: You need to know when bad stuff happens. That means logging, monitoring, and automated alerts. Sounds expensive, but open-source tools like Wazuh can handle this for smaller organizations at a fraction of commercial SIEM costs.

4. Vulnerability Scanning and Penetration Testing

Regular vulnerability assessments and annual penetration testing are now mandatory compliance requirements. This isn't optional; it's baked into the security rule.

For CAHs: Annual pentesting for a CAH-sized environment runs $3,000-$8,000 from reputable firms (or look for academic partnerships or discounted community health center rates). Automated vulnerability scanning tools can be had for under $1,000/year.

Practical Strategies for Budget-Constrained CAHs

Here's where theory meets reality. Let's talk about building a real cybersecurity program when you're working with actual constraints.

Strategy 1: Risk Assessment First (Not Last)

Before buying anything, you need to know what you're protecting and what could go wrong. A formal risk assessment is required by HIPAA anyway, and it's your roadmap for spending.

Medcurity offers an affordable SRA (Security Risk Assessment) tool starting at just $499/year. For CAHs, this is the single best first investment—it gives you a structured approach to identifying risks without hiring a consultant at $15,000+.

A proper risk assessment will tell you:

What systems actually store/process PHI
Where your biggest vulnerabilities are
What compliance gaps exist
Where to focus limited resources

Get more details on CAH-specific risk assessment approaches.

Strategy 2: Layer Your Defenses (Don't Buy Everything)

With a limited budget, you need to be surgical about what you implement. Here's a prioritized approach:

Tier 1 (Must Have) - Implement Immediately:

Enable encryption on all systems (free/built-in)
Implement MFA on all critical systems
Document your data inventory and access controls
Establish basic logging (most systems have free logging—enable it)

Tier 2 (Should Have) - Within 6 Months:

Automated vulnerability scanning (OpenVAS is free; commercial tools run $1,000-3,000/year)
Basic endpoint detection (Windows Defender for Windows, built-in macOS tools)
Email security enhancements
Documented backup and disaster recovery procedures

Tier 3 (Nice to Have) - Within 12 Months:

Advanced threat detection
User behavior analytics
Network segmentation
Security operations center (SOC) services

Strategy 3: Use Open-Source and Built-In Tools

Your operating systems and software already include significant security features. Use them:

Windows: BitLocker (encryption), Windows Defender (antimalware), Windows Firewall
macOS: FileVault (encryption), XProtect (antimalware)
Linux: Inherent security benefits, iptables/firewalld (firewalls)
Email: Most email providers (Google Workspace, Microsoft 365) include security features—configure them properly
Backups: Don't assume cloud providers handle security. Understand HIPAA encryption requirements for 2026.

Configuration of existing tools often beats purchasing new ones.

Strategy 4: Build a Strong Access Control Foundation

This is where you prevent 90% of breaches with minimal cost:

Principle of Least Privilege: Users only get access to what they need. This takes time to audit initially but prevents lateral movement.
Regular Access Reviews: Quarterly reviews of who has access to what. Yes, it's tedious. Yes, it's essential.
Strong Password Policies: 12+ characters, complexity requirements, no reuse. Enforce this with directory services (Active Directory, Google Workspace).
Privileged Access Management: For critical systems, log and monitor who uses admin accounts. PAM solutions start at $3,000-5,000/year, but open-source options like Guacamole exist.

Strategy 5: Documentation and Training (Costs Nothing)

This sounds boring, but it's where CAHs often fail:

Document your security policies (use templates from HHS/NIST—they're free)
Document your incident response plan
Document your disaster recovery procedures
Train staff annually on HIPAA and security practices
Train on phishing recognition—this is your #1 defense

Most breaches don't happen because of sophisticated zero-days. They happen because someone clicked a phishing link or reused passwords. Train your people.

Strategy 6: Partnering for Pentesting

Annual penetration testing is now mandatory. Full professional pentesting is expensive, but options exist:

Academic Partnerships: Many colleges have cybersecurity programs offering discounted or free pentesting
Community Health Center Networks: Some rural health networks negotiate group rates
Scaled Scope: Use automated tools (Metasploit, Nessus) for ongoing testing, reserve professional pentesting for annual comprehensive assessments

Budget $5,000-8,000 annually for external pentesting. For a CAH, this is often a line item that requires planning, but it's not negotiable.

The Compliance Cost Reality

Understanding the actual cost of HIPAA compliance is crucial for CAH budgeting. The common misconception is that compliance requires a six-figure investment. For CAHs specifically:

Year 1 (Foundation): $8,000-15,000 (risk assessment tool, MFA implementation, documentation, initial training)
Year 2-3 (Maturity): $12,000-20,000 annually (ongoing tools, pentesting, staff training, updates)

This assumes you have internal IT staff. If you're outsourcing entirely, costs increase 3-4x. But if you've got even one competent IT person who understands HIPAA requirements, this is achievable.

Practical Checklist for CAHs

Here's your implementation roadmap:

Month 1-2:

[ ] Complete risk assessment
[ ] Enable encryption on all devices and servers
[ ] Enable MFA on EHR and critical systems
[ ] Document data inventory

Month 3-4:

[ ] Review and restrict access controls
[ ] Deploy vulnerability scanning
[ ] Establish incident response procedures
[ ] Begin staff HIPAA training

Month 5-6:

[ ] Implement backup and disaster recovery
[ ] Configure logging and monitoring
[ ] Conduct first internal vulnerability scan
[ ] Schedule annual penetration test

Month 7-12:

[ ] Complete penetration test
[ ] Remediate findings
[ ] Conduct access control review
[ ] Plan for next year's improvements

The Bottom Line

Building HIPAA compliance as a Critical Access Hospital is genuinely hard. You're under-resourced, under-budgeted, and under tremendous pressure. But here's the reality: the stakes of a breach are catastrophic—not just financially, but for your patients and your community.

The good news? You don't need a six-figure budget to be compliant. You need:

A clear understanding of what you're protecting
Disciplined implementation of foundational security controls
Documentation and accountability
A willingness to invest in the right tools and expertise

The 2026 HIPAA Security Rule changes aren't arbitrary. They reflect real threats. Mandatory encryption, MFA, and regular security testing exist because they work. For CAHs, that means your shoestring budget can go a lot further when it's focused on the right things.

Start with a risk assessment. Get your access controls right. Enable encryption everywhere. Train your people. And plan for annual pentesting as a line-item expense. Everything else builds from that foundation.

Your patients are counting on you to keep their data secure. And honestly? It's more achievable than you think.

Resources:

HIPAA Security for FQHCs: What IT Teams at Community Health Centers Need to Know

Joe Gellatly — Tue, 21 Apr 2026 04:49:22 +0000

HIPAA Security for FQHCs: What IT Teams at Community Health Centers Need to Know

If you're an IT administrator, developer, or sysadmin at a Federally Qualified Health Center (FQHC), you're responsible for securing some of the most sensitive healthcare data in the country — and you're doing it with a fraction of the resources that hospital systems get.

FQHCs serve over 30 million patients across 15,000+ delivery sites. Most operate with IT teams of 1-5 people. And the 2026 HIPAA Security Rule changes just made your job significantly harder.

Here's what you actually need to know — from one IT practitioner to another.

The 2026 Rule Changes That Matter Most for FQHC IT Teams

Mandatory Encryption (Everywhere)

The "addressable" loophole is dead. Every system that stores or transmits ePHI must be encrypted — at rest and in transit. No exceptions, no alternative safeguards, no documenting why it's "not reasonable."

What this means for your infrastructure:

Full-disk encryption on every workstation (BitLocker/FileVault — they're free, just enable them)
TLS 1.2+ on every connection transmitting ePHI
Encrypted email gateway or service for anything containing patient data
Encrypted backups (local and cloud)
Database-level encryption for any custom applications
VPN or encrypted tunnels between sites

The hard part for FQHCs: You probably have legacy systems that can't do modern encryption. That radiology workstation running Windows 7 embedded? That 2012-era lab interface? You need a plan for each one. Network segmentation is your friend here — isolate what you can't encrypt until you can replace it.

Multi-Factor Authentication (MFA)

MFA is now mandatory on every system accessing ePHI. Not optional. Not "recommended." Mandatory.

Implementation approach for multi-site FQHCs:

# Priority order for MFA deployment:
1. Remote access (VPN, RDP, Citrix) — highest risk
2. EHR system logins — most ePHI access
3. Email — common breach vector
4. Administrative systems (AD, firewalls, switches)
5. Cloud services (Azure, AWS, M365 admin)

For FQHCs with spotty cellular coverage at rural sites, push-based MFA apps can fail. Consider:

Hardware tokens (YubiKey/FIDO2) as backup
On-premises MFA servers that don't require internet connectivity
Time-based OTP (TOTP) apps that work offline

Biannual Vulnerability Scanning

You must scan every system handling ePHI at least every 6 months. Here's a practical approach:

# Free/affordable scanning options:
# OpenVAS (free, open-source)
sudo apt-get install openvas
gvm-setup
gvm-start

# Nessus Essentials (free for up to 16 IPs)
# Download from tenable.com/products/nessus/nessus-essentials

# For multi-site: consider a cloud-based scanner
# that can scan each site without deploying hardware

Document everything. OCR wants to see scan dates, findings, severity ratings, remediation actions, and completion dates. A spreadsheet works but a proper vulnerability management platform is better.

Annual Penetration Testing

This is new and will hit FQHC budgets hard. Expect $5,000-$20,000 depending on network complexity.

Pro tips for FQHCs:

Negotiate group rates through your regional health center network
Schedule pen tests during slow periods (if such a thing exists in healthcare)
Ensure your scope covers external AND internal testing
Include social engineering (phishing) testing — it's how most healthcare breaches start
Get remediations done before the next SRA cycle

Multi-Site Architecture Challenges

The average FQHC runs 5-12 sites. Some have 30+. Each site needs its own security posture assessment.

Network Segmentation Strategy

                    ┌─────────────────────┐
                    │   Main Data Center   │
                    │  (EHR, Backups, AD)  │
                    └──────────┬──────────┘
                               │ Encrypted VPN
                    ┌──────────┼──────────┐
              ┌─────┴──┐  ┌───┴────┐  ┌──┴─────┐
              │ Site A  │  │ Site B │  │ Site C │
              │Clinical │  │Clinical│  │Clinical│
              └────┬────┘  └───┬────┘  └───┬────┘
                   │           │           │
         ┌────────┼───┐   ┌───┼────┐   ┌──┼──────┐
         │  VLAN 10   │   │VLAN 10 │   │VLAN 10  │
         │ Clinical   │   │Clinical│   │Clinical │
         ├────────────┤   ├────────┤   ├─────────┤
         │  VLAN 20   │   │VLAN 20 │   │VLAN 20  │
         │ Admin/Bill │   │Admin   │   │Admin    │
         ├────────────┤   ├────────┤   ├─────────┤
         │  VLAN 30   │   │VLAN 30 │   │VLAN 30  │
         │ Guest WiFi │   │Guest   │   │Guest    │
         ├────────────┤   ├────────┤   ├─────────┤
         │  VLAN 40   │   │VLAN 40 │   │VLAN 40  │
         │ IoT/Legacy │   │IoT     │   │IoT      │
         └────────────┘   └────────┘   └─────────┘

Key principles:

Never put medical devices on the same VLAN as clinical workstations
Guest WiFi must be completely isolated from clinical networks
Inter-site traffic must traverse encrypted tunnels
Each site should be able to operate independently if WAN connectivity fails

Centralized Logging

When you're managing 10 sites with 1-3 IT staff, centralized logging isn't optional — it's survival.

# Minimum logging requirements:
- Authentication events (success + failure) across all sites
- EHR access logs
- Firewall logs from all site perimeters
- VPN connection logs
- Privileged account usage
- File access on sensitive shares

Free options: Graylog, ELK stack (Elasticsearch + Logstash + Kibana), Wazuh.
Affordable options: Splunk Free (500MB/day), Datadog, Sumo Logic.

Set up alerts for: failed login spikes, after-hours EHR access, new admin account creation, large data exports, and VPN connections from unexpected locations.

The SRA: Don't Use the ONC Free Tool

I know the ONC Security Risk Assessment Tool is free. I know HRSA mentions it in their guidance. But for a multi-site FQHC, it's inadequate:

No multi-site assessment capability
Not updated for 2026 rule changes
No remediation tracking
No year-over-year comparison
Generates minimal documentation
Designed for solo practitioner complexity, not FQHC complexity

Use a purpose-built platform. Medcurity starts at $499/year and was designed specifically for organizations like FQHCs — multi-site assessment, guided workflow for non-specialists, audit-ready documentation, and remediation tracking that actually works when your "security team" is also your helpdesk.

Incident Response for Lean IT Teams

The 72-hour breach notification window means you need a plan that works when key people are unavailable.

# Incident Response Runbook - FQHC Template
discovery:
  - Isolate affected system(s) immediately
  - Document: what happened, when, who discovered it
  - Preserve logs and evidence (don't reboot/wipe)

assessment (first 12 hours):
  - Scope: what data was potentially exposed?
  - Count: how many patient records affected?
  - Type: was ePHI actually accessed/exfiltrated?

escalation:
  primary: [IT Director name + phone]
  backup: [Backup IT contact + phone]
  executive: [CEO/COO name + phone]
  legal: [Healthcare attorney contact]
  cyber_insurance: [Carrier claim number]
  forensics: [Pre-arranged IR firm contact]

notification (within 72 hours if breach confirmed):
  - OCR breach portal (breaches affecting 500+ individuals)
  - Affected individuals
  - State attorney general (check state-specific requirements)
  - Media (if 500+ individuals affected)

documentation:
  - Timeline of events
  - Actions taken
  - Root cause analysis
  - Remediation steps

Budget Reality Check

Here's what a reasonable FQHC IT security budget looks like:

Item	Annual Cost	Notes
SRA Platform	$499-$2,500	Medcurity, Compliancy Group, etc.
Vulnerability Scanner	$0-$3,000	OpenVAS (free) or Nessus
Penetration Testing	$5,000-$20,000	Annual, external firm
MFA Solution	$1,200-$4,800	Based on user count
Endpoint Protection	$2,000-$8,000	EDR/antivirus across all sites
SIEM/Logging	$0-$5,000	Wazuh (free) or commercial
Backup/DR	$3,000-$12,000	Encrypted, tested, multi-site
Training Platform	$500-$2,000	Annual staff HIPAA training
Total	$12,200-$57,300

Justify every dollar by tying it to specific HIPAA requirements and SRA findings. HRSA grants can cover these costs, and smart budgeting means presenting compliance as a grant-fundable necessity, not a discretionary expense.

TL;DR for the FQHC IT Admin

Encrypt everything. There are no more excuses.
Deploy MFA everywhere. Start with remote access, then EHR, then email.
Scan biannually. OpenVAS is free. Just do it.
Get a real SRA platform. Not the ONC tool. Something that handles multi-site.
Build your IR plan now. Not during a breach.
Document obsessively. If it's not written down, it didn't happen.
Budget for pen testing. It's mandatory now. Negotiate group rates.

Your FQHC serves the patients who need healthcare the most. Keeping their data secure is part of that mission.

Medcurity builds HIPAA compliance tools for community health centers, rural hospitals, and healthcare organizations that need enterprise-grade compliance without enterprise-grade budgets. FQHCs including Community Health Center of Snohomish County, NATIVE HEALTH, Valley Wide Health Systems, and Clinicas de Salud del Pueblo use Medcurity for their SRA and compliance management.

Implementing a HIPAA-Compliant Disaster Recovery Architecture

Joe Gellatly — Tue, 21 Apr 2026 04:41:33 +0000

Your healthcare application is running smoothly. Patient records are being accessed, appointments are being scheduled, prescriptions are flowing through the system. Then a datacenter burns down. Your servers go offline. Your database becomes unavailable.

If you don't have a robust disaster recovery plan, those patients suddenly can't access their medical records. Providers can't see medication history. Pharmacies can't fill prescriptions. It's not just downtime—it's a patient safety issue.

HIPAA regulations require healthcare organizations to have disaster recovery (DR) and business continuity (BC) plans that are tested regularly. For developers, this means building applications with redundancy, geographic distribution, and automated failover baked into the architecture.

This guide walks through the technical implementation of a HIPAA-compliant disaster recovery system.

Understanding Recovery Objectives

Before building your DR architecture, define two critical metrics:

RPO (Recovery Point Objective): Maximum acceptable data loss

RPO of 1 hour = you can afford to lose up to 1 hour of data
RPO of 15 minutes = databases must be synchronized every 15 minutes
RPO of 0 = you need synchronous replication (near-real-time)

RTO (Recovery Time Objective): Maximum acceptable downtime

RTO of 4 hours = users can be down for 4 hours, then service restores
RTO of 15 minutes = service must be restored within 15 minutes
RTO of 0 = zero-downtime failover required

For healthcare applications:

Critical systems (prescription management, lab results): RTO ≤ 15 minutes, RPO ≤ 15 minutes
Important systems (appointment scheduling): RTO ≤ 1 hour, RPO ≤ 1 hour
Supporting systems (patient education): RTO ≤ 4 hours, RPO ≤ 1 day

These objectives drive your architecture decisions and costs.

Architecture Considerations

Building HIPAA-compliant DR requires multi-region deployment, automated failover, encrypted backups, and regular testing. Key components include database replication strategies (synchronous for critical systems, asynchronous for supporting systems), health check configurations, backup encryption with separate key management, and automated failover orchestration.

Every DR architecture decision should trace back to your Security Risk Analysis—the document that identifies which systems contain ePHI, what the acceptable downtime is, and what controls are needed.

Testing Your DR Plan

HIPAA requires regular testing of your disaster recovery procedures. This means quarterly failover drills at minimum, documented results, and updated runbooks. A DR plan that hasn't been tested is just a wish list.

For organizations building or evaluating their disaster recovery programs: HIPAA Compliance Solutions

And the risk analysis that drives your DR architecture decisions: HIPAA Risk Analysis Tools

Joe Gellatly is CEO of Medcurity, a HIPAA compliance platform that helps healthcare organizations manage risk assessments, compliance programs, and security documentation.

Building HIPAA-Compliant APIs: A Developer's Security Checklist

Joe Gellatly — Tue, 21 Apr 2026 04:39:47 +0000

When you're building healthcare applications that handle patient data, you're not just building for users—you're building under the weight of regulatory compliance. The Health Insurance Portability and Accountability Act (HIPAA) isn't just a legal requirement; it's a framework that forces you to think about security at every layer of your API architecture.

As developers, we're accustomed to shipping fast and iterating. But healthcare is different. A vulnerability in your API doesn't just impact uptime metrics—it can expose protected health information (PHI) that affects real patients' lives and exposes your organization to fines up to $50,000 per violation.

This guide walks through the technical implementation details every developer needs to know when building HIPAA-compliant APIs.

Understanding HIPAA's Technical Requirements

HIPAA doesn't prescribe specific technologies—it prescribes outcomes. The Security Rule requires:

Administrative safeguards: Workforce security, information security management
Physical safeguards: Facility access controls, workstation use policies
Technical safeguards: Access controls, audit controls, encryption, transmission security

For API developers, you're primarily responsible for the technical safeguards, but you need to understand how they connect to the broader compliance picture.

1. Authentication and Access Control

Every request to your API must authenticate the user and validate they have permission to access the requested PHI.

Implementation Best Practices

Use OAuth 2.0 with PKCE for client-side applications:

- OAuth 2.0 provides standardized token-based authentication
- PKCE (Proof Key for Code Exchange) prevents authorization code interception
- Short-lived access tokens (15-60 minutes) limit damage from token theft
- Refresh tokens kept in secure, httpOnly cookies

Implement Role-Based Access Control (RBAC):

- Define roles at the application level (Provider, Staff, Patient, Administrator)
- Map roles to specific API endpoints and data scopes
- Enforce least privilege—users only access data required for their role
- Log all access attempts and denials

API Key Management:

- If using API keys for service-to-service communication, store them in secure vaults (AWS Secrets Manager, HashiCorp Vault)
- Never embed keys in code repositories
- Rotate keys regularly (quarterly minimum)
- Implement key expiration and automatic revocation

Code Example: Protecting API Endpoints

// Express.js middleware for access control
const verifyHIPAAAccess = async (req, res, next) => {
  try {
    // 1. Verify JWT token
    const token = req.headers.authorization?.split(' ')[1];
    const decoded = jwt.verify(token, process.env.JWT_SECRET);

    // 2. Check if user has permission for this resource
    const { patientId } = req.params;
    const userRole = decoded.role;
    const allowedRoles = getRequiredRoles(req.path, 'GET');

    if (!allowedRoles.includes(userRole)) {
      return res.status(403).json({ error: 'Insufficient permissions' });
    }

    // 3. Verify user owns/manages this patient data
    const userPatients = await getUserPatientList(decoded.userId);
    if (!userPatients.includes(patientId) && userRole !== 'admin') {
      return res.status(403).json({ error: 'Access denied' });
    }

    req.user = decoded;
    next();
  } catch (error) {
    // Log the failure for audit purposes
    auditLog.record({
      action: 'AUTH_FAILURE',
      endpoint: req.path,
      ip: req.ip,
      timestamp: new Date()
    });
    res.status(401).json({ error: 'Unauthorized' });
  }
};

app.get('/api/patients/:patientId/records', verifyHIPAAAccess, (req, res) => {
  // Handler code
});

2. Encryption: At Rest and In Transit

Encryption is non-negotiable in healthcare APIs.

In Transit: TLS 1.3 Minimum

Configuration Requirements:

- Enforce TLS 1.3 for all connections (TLS 1.2 minimum, but 1.3 recommended)
- Use modern cipher suites (ChaCha20-Poly1305, AES-256-GCM)
- Obtain certificates from trusted CAs
- Implement HSTS (HTTP Strict-Transport-Security) header
- Use perfect forward secrecy (PFS) for key exchange

Nginx Configuration Example:

server {
    listen 443 ssl http2;
    ssl_protocols TLSv1.3 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5:!DSS;
    ssl_prefer_server_ciphers on;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_stapling on;
    ssl_stapling_verify on;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

At Rest: AES-256 Encryption

Database-Level Encrypt)on:

- Enable encrypted storage at the database level (AWS RDS encryption, MongoDB encryption)
- Implement field-level encryption for highly sensitive data (SSN, payment info)
- Use separate encryption keys for different data categories
- Implement key rotation policies (annual minimum)

Field-Level Encryption Example:

const crypto = require('crypto');

class EncryptionService {
  constructor(masterKey) {
    this.masterKey = masterKey; // Stored in vault, never in code
  }

  encryptPHI(plaintext, dataType = 'general') {
    const iv = crypto.randomBytes(16);
    const cipher = crypto.createCipheriv('aes-256-gcm', Buffer.from(this.masterKey), iv);

    let encrypted = cipher.update(plaintext, 'utf8', 'hex');
    encrypted += cipher.final('hex');

    const authTag = cipher.getAuthTag();

    // Store IV and authTag with encrypted data for decryption
    return {
      encrypted,
      iv: iv.toString('hex'),
      authTag: authTag.toString('hex'),
      dataType,
      encryptedAt: new Date()
    };
  }

  decryptPHI(encryptedData) {
    const decipher = crypto.createDecipheriv(
      'aes-256-gcm',
      Buffer.from(this.masterKey),
      Buffer.from(encryptedData.iv, 'hex')
    );

    decipher.setAuthTag(Buffer.from(encryptedData.authTag, 'hex'));

    let decrypted = decipher.update(encryptedData.encrypted, 'hex', 'utf8');
    decrypted += decipher.final('utf8');

    return decrypted;
  }
}

3. Audit Logging and Monitoring

HIPAA requires comprehensive logging of all access to PHI. This isn't just for compliance—it's your detective work for security incidents.

What Must Be Logged

- Who accessed what data (user ID, timestamp)
- When they accessed it (precise timestamps, timezone)
- What they did with it (read, write, delete, export)
- Where they accessed from (IP address, geographic location)
- Whether the access was successful or denied
- Any suspicious patterns or anomalies

Implementation Pattern

class AuditLogger {
  constructor(logService) {
    this.logService = logService;
  }

  async logPHIAccess(context) {
    const logEntry = {
      timestamp: new Date().toISOString(),
      userId: context.userId,
      action: context.action, // 'READ', 'WRITE', 'DELETE', 'EXPORT'
      resourceType: context.resourceType, // 'PATIENT_RECORD', 'PRESCRIPTION', etc
      resourceId: context.resourceId,
      dataClassification: context.classification, // 'PHI', 'PII', 'PUBLIC'
      ipAddress: context.ipAddress,
      userAgent: context.userAgent,
      result: context.result, // 'SUCCESS' or 'FAILURE'
      failureReason: context.failureReason || null,
      sessionId: context.sessionId,
      environment: process.env.NODE_ENV
    };

    // Write to immutable log store (CloudWatch, Splunk, etc)
    await this.logService.write('hipaa-audit-log', logEntry);

    // Trigger alerts for suspicious patterns
    if (context.action === 'EXPORT' || context.result === 'FAILURE') {
      await this.checkForAnomalies(logEntry);
    }
  }

  async checkForAnomalies(logEntry) {
    // Query recent logs for same user
    const recentLogs = await this.logService.query({
      userId: logEntry.userId,
      timeWindow: '1hour'
    });

    // Flag unusual patterns (bulk exports, failed access attempts, off-hours access)
    if (recentLogs.length > 50) {
      await this.alertSecurityTeam({
        type: 'BULK_ACCESS_PATTERN',
        userId: logEntry.userId,
        count: recentLogs.length
      });
    }
  }
}

// Middleware to automatically log API access
const auditMiddleware = (req, res, next) => {
  const originalSend = res.send;

  res.send = function(data) {
    auditLogger.logPHIAccess({
      userId: req.user.id,
      action: mapHTTPMethodToAction(req.method),
      resourceType: extractResourceType(req.path),
      resourceId: req.params.id,
      ipAddress: req.ip,
      userAgent: req.get('user-agent'),
      result: res.statusCode < 400 ? 'SUCCESS' : 'FAILURE',
      failureReason: res.statusCode >= 400 ? `HTTP ${res.statusCode}` : null,
      sessionId: req.sessionID
    });

    return originalSend.call(this, data);
  };

  next();
};

4. Business Associate Agreements with Cloud Providers

If you're using AWS, Azure, Google Cloud, or third-party services to store or process PHI, you need a Business Associate Agreement (BAA).

Critical Questions to Ask Your Vendors

1. Do you have a signed BAA in place?
2. Can you confirm you're using encryption for data at rest and in transit?
3. How do you handle data subpoenas or law enforcement requests?
4. What's your breach notification protocol?
5. Do you allow security audits or penetration testing?
6. What's your data retention and deletion policy?
7. Do you use subcontractors? (They need BAAs too)
8. How do you handle geographic data residency requirements?

Common Vendors That Require BAAs

Cloud Providers: AWS, Azure, Google Cloud, DigitalOcean
Logging/Monitoring: Datadog, New Relic, LogRocket
Analytics: Segment, Mixpanel (requires careful data handling)
Communication: SendGrid (for patient notifications), Twilio
Databases: Atlas MongoDB, Firebase (with restrictions)

Before integrating any third-party service, check their BAA status on their website. If they don't offer BAAs, you can't use them for PHI processing.

5. Request/Response Validation and Data Sanitization

Never trust user input, even from authenticated users.

Input Validation

const validatePatientRecordInput = (data) => {
  const schema = {
    patientId: { type: 'string', regex: /^[a-f0-9-]{36}$/ }, // UUID
    dateOfBirth: { type: 'date', maxAge: 150 },
    ssn: { type: 'string', regex: /^\d{3}-\d{2}-\d{4}$/ },
    medications: { type: 'array', maxLength: 100 },
    notes: { type: 'string', maxLength: 5000 }
  };

  // Validate against schema
  // Reject if contains SQL injection patterns
  // Reject if exceeds expected data types

  return validateAndSanitize(data, schema);
};

// Never expose internal error details
app.use((err, req, res, next) => {
  auditLog.error({
    error: err.message,
    userId: req.user?.id,
    endpoint: req.path
  });

  // Return generic message to client
  res.status(500).json({ error: 'Internal server error' });
});

Response Filtering

// Only return fields the user is authorized to see
const sanitizePatientRecord = (record, userRole) => {
  const allowedFields = {
    patient: ['firstName', 'lastName', 'dateOfBirth', 'medications'],
    provider: ['firstName', 'lastName', 'dateOfBirth', 'medications', 'diagnosisHistory', 'labResults'],
    admin: ['*'] // All fields
  };

  const fields = allowedFields[userRole];
  return fields.includes('*') ? record : pick(record, fields);
};

6. Rate Limiting and DDoS Protection

Brute force attacks against authentication endpoints are common. Implement rate limiting.

const rateLimit = require('express-rate-limit');

const authLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5, // 5 requests per window
  message: 'Too many login attempts, try again later',
  standardHeaders: true,
  legacyHeaders: false,
});

app.post('/api/auth/login', authLimiter, (req, res) => {
  // Login logic
});

7. Security Testing and Penetration Testing

Before going live:

OWASP Top 10 Review: Ensure you're protected against the most common vulnerabilities
Dependency Scanning: Use tools like Snyk or npm audit to find vulnerable packages
Code Review: Have security-conscious peers review your authentication and encryption code
Penetration Testing: Hire ethical hackers to test your API before launch
Compliance Scanning: Use tools to verify you meet HIPAA requirements

8. Incident Response Plan

Despite best efforts, breaches happen. Have a plan:

1. Detection & Analysis: How will you detect unauthorized access?
2. Containment: How will you stop ongoing unauthorized access?
3. Eradication: How will you remove the attacker?
4. Recovery: How will you restore systems to normal?
5. Notification: HIPAA requires breach notification within 60 days

Getting the Compliance Details Right

Building HIPAA-compliant APIs is complex, and the requirements continue to evolve. The checklist above covers the developer-specific aspects, but ensure your entire organization—from product to legal to operations—understands the compliance requirements.

The good news: thoughtful API security practices align almost perfectly with HIPAA's technical requirements. The same practices that keep your users' data safe from attackers also satisfy regulatory auditors.

For a comprehensive guide to all HIPAA requirements—including administrative and physical safeguards your entire team needs to understand—see Medcurity's HIPAA Compliance Solutions guide, which covers the full compliance framework.

Resources

Have a question about HIPAA API security? Drop a comment below—I read them all.

HIPAA Compliance for Software Developers: What You Actually Need to Know

Joe Gellatly — Tue, 21 Apr 2026 04:30:13 +0000

HIPAA Compliance for Software Developers: What You Actually Need to Know

If you're building healthcare software, HIPAA compliance isn't optional—it's a legal requirement. But HIPAA can feel overwhelming with its 68+ pages of regulations and technical jargon. This guide breaks down what you actually need to implement as a developer.

Understanding PHI and What You're Protecting

First, let's clarify what Protected Health Information (PHI) is. Under HIPAA, PHI includes any health information that can identify an individual: names, medical record numbers, dates of birth, Social Security numbers, or any health condition associated with that identifier.

As a developer, you're handling PHI when your application:

Stores patient medical records
Processes appointment data tied to individuals
Handles insurance information
Transmits any identifiable health data

This means HIPAA rules apply—even if you're just building a small piece of a larger healthcare ecosystem.

Technical Safeguards: The Developer's Checklist

HIPAA's "Technical Safeguards" section is where developers come in. Here's what you need to implement:

1. Encryption at Rest

All PHI stored in your database must be encrypted. This isn't optional or "nice-to-have."

What to do:

Use AES-256 encryption for database encryption
Encrypt individual fields containing sensitive PHI (medical record numbers, SSNs)
Use your database platform's built-in encryption (AWS RDS encryption, Azure Transparent Data Encryption, etc.)
Never store passwords in plaintext—use bcrypt, Argon2, or similar modern hashing algorithms
Implement key management: store encryption keys separately from encrypted data

2. Encryption in Transit

Data traveling over networks must be encrypted end-to-end.

What to do:

Enforce HTTPS only (TLS 1.2 minimum, 1.3 preferred)
Configure HSTS headers to prevent downgrade attacks
Use VPNs or secure tunnels for server-to-server communication
Encrypt API calls with mutual TLS if handling sensitive data
Never transmit PHI over unencrypted channels

3. Access Controls

PHI should only be accessible to authorized users and systems.

Implementation steps:

Implement role-based access control (RBAC): define roles like "clinician," "administrator," "billing"
Enforce the "minimum necessary" principle: users only access PHI needed for their job
Use OAuth 2.0 or similar for authentication
Implement strong password policies (minimum 8 characters, complexity requirements)
Enable multi-factor authentication (MFA) for all accounts, especially admin accounts
Log all PHI access for audit trails

Audit Logging and Monitoring

You must track who accesses PHI, when, and what they did.

What to log:

User login/logout events
All PHI access (view, download, export, delete)
Configuration changes
Failed login attempts
Data modifications (who changed what, when, and why)

Where to store logs:

Centralized logging system (CloudWatch, ELK Stack, Splunk)
Separate from the main application database
Retained for at least 6 years per HIPAA
Immutable (cannot be modified or deleted after creation)

API Security Patterns

If you're building APIs that handle PHI:

1. Authentication & Authorization

Use OAuth 2.0 or OpenID Connect, not basic auth
Implement scoped access tokens
Rotate tokens regularly

2. Rate Limiting

Prevent brute force attacks
Limit API calls per user/IP
Monitor for unusual access patterns

3. Input Validation

Validate all inputs (SQL injection, XSS prevention)
Sanitize data before storing or processing
Use parameterized queries

4. CORS and API Boundaries

Restrict CORS origins
Implement API key rotation
Monitor for unauthorized access patterns

Business Associate Agreements (BAAs)

If you're using third-party services (cloud providers, analytics, payment processors), you need Business Associate Agreements.

Services requiring BAAs:

Cloud hosting (AWS, Azure, Google Cloud)
Email providers (if handling PHI)
Analytics platforms
Payment processors
CDN/DDoS protection

Don't assume a service is HIPAA-compliant—ask for their Business Associate Agreement.

Getting Started with Compliance

Building HIPAA-compliant healthcare software is complex, but it's absolutely doable with a solid technical foundation. Start with encryption, access controls, and audit logging.

For a complete guide to HIPAA compliance requirements including organizational and physical safeguards, check out the HIPAA Compliance Solutions guide and HIPAA Compliance Checklist 2026.

Written by the compliance team at Medcurity (medcurity.com) — an AI-powered HIPAA compliance platform for healthcare practices.

Encryption at Rest and In Transit: Meeting HIPAA Technical Safeguards

Joe Gellatly — Tue, 21 Apr 2026 04:27:11 +0000

Data encryption is the cornerstone of healthcare security. It's the technical equivalent of a vault—even if an attacker gains physical access to your servers or intercepts your network traffic, they find only incomprehensible gibberish without the encryption keys.

For developers building healthcare applications, understanding encryption isn't optional. It's the difference between a recoverable security incident and a catastrophic data breach affecting patient privacy.

This guide walks through the cryptographic foundations you need to implement HIPAA-compliant encryption, from transport-layer protocols to database encryption to key management strategies.

Why Encryption Matters in Healthcare

A HIPAA violation involving unencrypted PHI typically results in:

$100-$50,000 per record per violation
FDA enforcement actions
State medical board investigations
Loss of patient trust and reputation damage

Encryption doesn't eliminate the risk of a breach, but it dramatically reduces the consequences. For complete guidance on all HIPAA technical requirements, consult Medcurity's HIPAA compliance checklist and HIPAA Compliance Solutions.

Joe Gellatly is CEO of Medcurity, a HIPAA compliance platform for healthcare organizations.

Building HIPAA-Compliant Applications: A Developer's Checklist

Joe Gellatly — Tue, 21 Apr 2026 04:24:34 +0000

Building HIPAA-Compliant Applications: A Developer's Checklist

You've decided to build healthcare software. Great—there's massive opportunity in healthtech. But there's also a non-negotiable requirement: HIPAA compliance.

The good news? Compliance isn't something you bolt on at the end. It's architectural. This guide walks you through building HIPAA compliance into your application from day one.

Encryption: The Foundation

HIPAA requires encryption at rest and in transit. This isn't optional.

Encryption at Rest

Your most sensitive data—patient medical records—must be encrypted in your database. Use AES-256 encryption. Enable database-level encryption. Store encryption keys separately from encrypted data using a Key Management System (KMS).

Encryption in Transit

All data moving across the network must use HTTPS with TLS 1.2 or higher. Configure HSTS headers. Use mutual TLS for server-to-server communication.

Access Control Implementation

Role-Based Access Control (RBAC) is critical. Define user roles. Assign minimum necessary access per role. Restrict file and record access by role. Enable access logging. Review access controls quarterly.

Example roles:

Clinician: Medical records, vital signs, test results only
Nurse: Vital signs, clinical notes (not financial)
Front Desk: Appointments, contact info, insurance (not clinical)
Billing: Billing records, insurance (not clinical)

Comprehensive Audit Logging

Every API call must be logged. Log who accessed what, when, and why. Store logs in a centralized system separate from application data. Make logs immutable. Retain for at least 6 years.

Business Associate Agreements

Identify all services touching PHI: EHR, cloud backup, email, payment processors, SMS services. Contact each vendor. Request a signed HIPAA Business Associate Agreement. Track BAA expiry dates.

Incident Response Plan

Document what you'd do if there's a breach. Who do you call first? What's the notification timeline? How do you determine breach scope? Have your attorney review. Test it annually.

Practical Implementation Checklist

[ ] Implement AES-256 encryption for sensitive data
[ ] Enable database-level encryption
[ ] Enforce HTTPS only (TLS 1.2+)
[ ] Implement RBAC
[ ] Enable multi-factor authentication
[ ] Set up centralized audit logging
[ ] Collect BAAs from all vendors
[ ] Conduct security testing
[ ] Document your security architecture
[ ] Train team on HIPAA requirements

For detailed guidance on implementing all HIPAA technical safeguards, see HIPAA Business Associate Agreement Requirements and HIPAA Compliance Checklist 2026.

Written by the compliance team at Medcurity (medcurity.com) — an AI-powered HIPAA compliance platform for healthcare practices.

Running HIPAA-Compliant Workloads in the Cloud: An Infrastructure Engineer's Guide

Joe Gellatly — Tue, 21 Apr 2026 04:22:49 +0000

Every major cloud provider will sign a Business Associate Agreement. That's the easy part. The hard part is configuring your cloud environment so it actually meets HIPAA requirements -- because the BAA doesn't make your misconfigured S3 bucket compliant.

The shared responsibility model means your cloud provider secures the infrastructure. You secure everything you build on top of it. Most HIPAA violations in cloud environments are configuration errors, not infrastructure failures.

The Shared Responsibility Reality

Here's what the cloud provider's BAA actually covers versus what's your responsibility:

Cloud Provider Responsibility (covered by their BAA)
-- Physical security of data centers
-- Hardware maintenance and patching
-- Network infrastructure security
-- Hypervisor security
-- Service availability (per SLA)

Your Responsibility (NOT covered by their BAA)
-- Data encryption configuration
-- Access control policies
-- Network security groups and firewall rules
-- Application-level security
-- Audit logging configuration
-- Backup policies and testing
-- Incident response
-- Identity and access management
-- Patch management for your OS and applications

A covered entity can't point to AWS's BAA when OCR asks why their RDS instance was publicly accessible. The BAA establishes that AWS will protect the infrastructure -- but you chose to make the database public.

Encryption Configuration

Data at Rest

Every storage service that holds ePHI needs encryption enabled:

Object storage (S3, GCS, Azure Blob) -- Enable server-side encryption with KMS-managed keys. Default encryption should be enforced at the bucket/container policy level so it's impossible to store unencrypted ePHI.
Block storage (EBS, Persistent Disks, Azure Disks) -- Enable encryption for all volumes. In AWS, you can set account-level defaults to encrypt all new EBS volumes automatically.
Databases (RDS, Cloud SQL, Azure SQL) -- Enable encryption at rest. For RDS, this must be set at instance creation -- you can't encrypt an existing unencrypted instance in place.
File systems (EFS, Filestore, Azure Files) -- Enable encryption. Often overlooked for shared storage used by legacy applications.
Backups and snapshots -- Encrypted automatically if the source is encrypted, but verify this. Cross-region snapshot copies need explicit encryption configuration.

Data in Transit

TLS 1.2 minimum for all connections to ePHI services. Disable TLS 1.0 and 1.1 explicitly.
Internal service communication -- Use service mesh encryption or VPC-internal TLS. Just because traffic stays within your VPC doesn't mean it can be unencrypted.
Database connections -- Enforce SSL/TLS for all database connections. In RDS, use the rds.force_ssl parameter.
API Gateway -- Terminate TLS at the gateway and re-encrypt to backend services. Don't leave the backend leg unencrypted.

Key Management

Use cloud KMS (AWS KMS, GCP KMS, Azure Key Vault) for all encryption keys
Implement key rotation policies -- annual rotation minimum
Separate keys by environment (dev, staging, production)
Restrict key access policies to specific IAM roles
Log all key usage for audit trails

Network Security

VPC Architecture

Design your VPC with ePHI isolation in mind:

Private subnets for ePHI workloads -- Databases, application servers processing PHI, and storage should never be in public subnets
NAT gateways for outbound access -- ePHI workloads that need internet access should route through NAT, never have public IPs
VPC endpoints for AWS services -- Use interface and gateway endpoints so traffic to S3, KMS, and other services stays within the AWS network
Network ACLs and security groups -- Implement both. Security groups for instance-level control, NACLs for subnet-level defense in depth

Segmentation

Separate ePHI workloads from non-ePHI workloads:

Separate VPCs or accounts for HIPAA workloads (AWS Organizations and SCPs are your friend here)
Micro-segmentation -- Security groups that allow only the specific ports and protocols needed between services
No direct database access from the internet -- Ever. Use bastion hosts or AWS Systems Manager Session Manager for administrative access

Access Control and IAM

Principle of Least Privilege

No broad IAM policies -- Action: "*" and Resource: "*" on ePHI resources is a finding waiting to happen
Role-based access -- Define IAM roles for specific functions (application role, DBA role, audit role) with minimum necessary permissions
No long-lived access keys -- Use IAM roles and temporary credentials wherever possible. If access keys are required, rotate them every 90 days maximum.
MFA on all human access -- Console access, CLI access through assumed roles, and any direct access to ePHI systems

Service Accounts

Dedicated service accounts per application -- Don't share service accounts across applications
Scoped permissions -- A service account for your patient portal shouldn't have access to your billing system's ePHI
Rotate credentials -- Automate credential rotation for service accounts

Audit Logging

What to Log

CloudTrail (AWS) / Cloud Audit Logs (GCP) / Azure Activity Log -- Enable for all regions, all services. Send to a centralized, immutable log store.
VPC Flow Logs -- Enable for all VPCs containing ePHI workloads. These show network traffic patterns and are critical for breach investigation.
Database audit logs -- Enable query logging for databases containing ePHI. Know who ran what queries and when.
Application-level audit logs -- Your application should log PHI access at the record level, not just authentication events.

Log Protection

Immutable storage -- Send logs to an S3 bucket with object lock or equivalent. Attackers covering their tracks shouldn't be able to delete audit evidence.
Cross-account log storage -- Store audit logs in a separate AWS account with restricted access
6-year retention -- HIPAA requires documentation retention for 6 years. Configure lifecycle policies accordingly.
Alerting -- Set up CloudWatch alarms or equivalent for suspicious patterns (failed auth attempts, unusual data access, configuration changes to security controls)

Backup and Disaster Recovery

Automated backups with documented RPO and RTO for every ePHI system
Cross-region replication for critical ePHI stores
Regular restore testing -- Quarterly at minimum. Document the results.
Backup encryption -- Verify backups are encrypted, especially cross-region copies
Backup access controls -- Separate IAM policies for backup operations. The application role shouldn't be able to delete backups.

Infrastructure as Code

Treat your HIPAA-compliant configuration as code:

Terraform/CloudFormation/Pulumi for all infrastructure -- No manual console configurations for ePHI resources
Policy as code -- Use tools like OPA, Sentinel, or AWS Config Rules to enforce HIPAA-required configurations automatically
Drift detection -- Alert when infrastructure drifts from the compliant baseline
Code review -- All infrastructure changes go through pull request review, just like application code

The Compliance Connection

Every cloud configuration decision should trace back to your Security Risk Analysis. The SRA identifies which systems contain ePHI, what controls are needed, and what residual risk exists. Your cloud architecture should implement the controls your SRA identifies.

For organizations managing HIPAA compliance across cloud and on-premise environments: HIPAA Compliance Solutions

And the risk analysis foundation that drives your cloud security decisions: HIPAA Risk Analysis Tools

Joe Gellatly is CEO of Medcurity, a HIPAA compliance platform that helps healthcare organizations manage risk assessments, compliance tracking, and security programs across cloud and on-premise environments.

HIPAA Compliance for Telehealth: What Developers Building Virtual Care Platforms Need to Get Right

Joe Gellatly — Tue, 21 Apr 2026 04:18:35 +0000

Telehealth usage exploded during COVID and never came back down. What did come back was regulatory enforcement. The temporary HIPAA enforcement discretion that allowed providers to use consumer-grade video tools ended, and OCR is now actively investigating telehealth-related complaints.

If you're building or maintaining a telehealth platform, the compliance requirements are the same as any system handling ePHI -- but the attack surface is dramatically different.

Why Telehealth Has a Unique Risk Profile

Traditional healthcare IT operates within controlled environments -- hospital networks, on-premise servers, managed workstations. Telehealth breaks all of those assumptions:

Patient endpoints are uncontrolled -- Patients connect from personal devices on home Wi-Fi networks you can't secure
Provider endpoints vary wildly -- A physician might use a hospital workstation, a home laptop, or a tablet between patient rooms
Video and audio streams contain PHI -- The conversation itself is protected health information, not just the data in your database
Session recordings create new PHI stores -- If you record sessions, those recordings need the same protections as any other ePHI
Screen sharing exposes PHI -- A provider sharing their EHR screen during a telehealth visit transmits PHI through your video infrastructure

The Technical Requirements

Encryption -- No Exceptions

Every telehealth session must be encrypted end-to-end:

Video/audio streams -- TLS 1.2+ for signaling, SRTP (Secure Real-time Transport Protocol) for media streams. WebRTC provides this by default if configured correctly, but verify your SRTP implementation.
Chat/messaging -- TLS 1.2+ minimum for any text-based communication during sessions
File sharing -- Any documents, images, or files shared during a session must be encrypted in transit
Session recordings -- AES-256 encryption at rest. If you store recordings, they're ePHI and need the same protection as your patient database.

The HIPAA safe harbor still applies: if a breach occurs but the data was encrypted to NIST standards and the key wasn't compromised, it's not a reportable breach.

Access Controls for Multi-Role Platforms

Telehealth platforms typically serve multiple user types with different access needs:

Provider
-- Can initiate/join sessions with their patients
-- Can view session recordings for their patients
-- Can access clinical notes
-- Cannot access other providers' sessions

Patient
-- Can join sessions they're invited to
-- Can view their own session history
-- Cannot access other patients' data

Administrative Staff
-- Can schedule sessions
-- May see scheduling metadata (time, provider, patient name)
-- Cannot access session content or recordings

Technical Support
-- Can troubleshoot connection issues
-- Should NOT have access to session content
-- Needs access to technical logs (stripped of PHI)

The minimum necessary standard applies: each role should only access the PHI required for their function.

Audit Logging

Every telehealth platform needs comprehensive audit trails:

Session access logs -- Who joined each session, when they joined, when they left
Recording access -- Who viewed or downloaded session recordings
Failed access attempts -- Especially important for detecting unauthorized access to sessions
Configuration changes -- Who modified encryption settings, access controls, or session policies
Data export -- Any bulk export of session data or recordings

These logs need tamper protection, 6-year retention, and regular review. They're your evidence in an OCR investigation.

Business Associate Agreements

Your telehealth infrastructure likely involves multiple third parties:

Video infrastructure provider (Twilio, Vonage, Zoom SDK) -- Need BAA
Cloud hosting (AWS, GCP, Azure) -- Need BAA
CDN for media delivery -- Need BAA if media streams pass through it
Transcription services -- Need BAA (and this is where many platforms slip up)
AI/ML services -- If you're using AI for clinical notes or summaries from session content, you need a BAA with that provider
Analytics platforms -- Need BAA if any session metadata constitutes PHI

The BAA chain must be complete before any PHI flows through these services.

Common Telehealth Compliance Failures

Using consumer video tools without a BAA

FaceTime, standard Zoom (not Zoom for Healthcare), Google Meet (without the healthcare add-on), and WhatsApp video are not HIPAA-compliant for telehealth. The enforcement discretion that allowed this during COVID is over.

Not encrypting session recordings

Some platforms encrypt live streams but store recordings in unencrypted S3 buckets or local storage. Recordings are ePHI and need encryption at rest.

Ignoring the waiting room

Virtual waiting rooms where patients wait for their provider are part of the session. If multiple patients can see each other's names or the fact that they're waiting for a particular specialist, that's a PHI exposure.

No session timeout

A telehealth session left open on a provider's screen in a shared workspace exposes PHI. Implement automatic session termination after inactivity periods appropriate to the clinical context.

Weak patient authentication

Sending a join link via email with no additional authentication means anyone with the link can join a session. Implement identity verification -- even something as simple as requiring patients to enter their date of birth before joining.

Building Compliance Into the Architecture

The most successful telehealth platforms treat HIPAA compliance as an architectural requirement, not a feature bolted on later. This means:

Encrypt by default -- Make it impossible to create an unencrypted session
Least privilege by default -- New roles start with zero access and must be explicitly granted
Log everything -- Build audit logging into every data access path from day one
Automate BAA tracking -- Know which vendors touch PHI and whether their BAAs are current
Test your controls -- Penetration testing specifically targeting telehealth session security

The Compliance Foundation

All of these telehealth-specific requirements should trace back to your Security Risk Analysis. The SRA identifies where ePHI exists in your environment (including telehealth sessions and recordings), what threats apply, and what controls are needed.

For a comprehensive view of how telehealth compliance fits into your broader HIPAA program: HIPAA Compliance Solutions

And the compliance checklist that covers telehealth alongside all other technical safeguards: HIPAA Compliance Checklist 2026

Joe Gellatly is CEO of Medcurity, a HIPAA compliance platform that helps healthcare organizations manage risk assessments, compliance programs, and security documentation.

HIPAA Breach Notification Rules: A Technical Guide to What Triggers Reporting and How Fast You Need to Move

Joe Gellatly — Tue, 21 Apr 2026 04:14:24 +0000

Your monitoring system fires an alert at 2 AM: unauthorized access to a database containing patient records. The next 72 hours will determine whether this becomes a manageable incident or a compliance catastrophe.

HIPAA's Breach Notification Rule has specific requirements for what constitutes a breach, who must be notified, and how quickly. For technical teams, understanding these rules before an incident happens is the difference between a coordinated response and panic.

What Counts as a Breach

Under HIPAA (45 CFR §§ 164.400-414), a breach is any unauthorized acquisition, access, use, or disclosure of unsecured PHI that compromises the security or privacy of the information.

The key word is unsecured. If the compromised data was encrypted to NIST standards and the encryption key wasn't compromised, it's not a reportable breach. This is the single most important technical control you can implement — it transforms a breach into a security incident.

The Four-Factor Risk Assessment

When an incident occurs, you must evaluate whether it constitutes a breach using four factors:

The nature and extent of PHI involved — Types of identifiers, clinical information, financial data
The unauthorized person who used or received the PHI — A curious employee vs. an external attacker carry different risk profiles
Whether PHI was actually acquired or viewed — Access logs showing the data was accessed vs. a misconfigured server that was exposed but never accessed
The extent of risk mitigation — Did you get a signed attestation of destruction? Did the unauthorized recipient confirm they didn't retain copies?

If your assessment concludes low probability that PHI was compromised, you can document that finding and not report. But that assessment needs to be thorough and defensible — OCR will second-guess it if they review the incident later.

Notification Timelines

Once you determine a breach has occurred, the clocks start:

For Covered Entities

Individual notification — Within 60 days of discovering the breach. Written notice to every affected individual via first-class mail (or email if they've consented to electronic communication).
Media notification — If a breach affects 500+ residents of a single state or jurisdiction, you must notify prominent media outlets in that area within 60 days.
HHS notification — Breaches affecting 500+ individuals must be reported to the Department of Health and Human Services within 60 days. Breaches affecting fewer than 500 individuals can be reported annually (within 60 days of the end of the calendar year).

For Business Associates

Report to covered entity — Within 60 days of discovery (though many BAAs negotiate shorter windows — 10 to 30 days is common).
"Discovery" is broadly defined — A breach is considered discovered when any person (not just leadership) within your organization knows or should reasonably have known about it. Your SOC analyst finding evidence at 2 AM starts the clock, not the meeting where they brief the CISO.

What the Notification Must Contain

Individual breach notifications must include:

Description of the breach, including dates
Types of PHI involved (names, SSNs, diagnosis codes, etc.)
Steps individuals should take to protect themselves
What you're doing to investigate and mitigate
Contact information for questions

The Technical Decisions That Matter

1. Encryption as a Safe Harbor

If ePHI is encrypted consistent with NIST Special Publication 800-111 (data at rest) or NIST SP 800-52 (data in transit), and the encryption key was not compromised alongside the data, the data is considered "secured" and the incident is not a reportable breach.

This makes encryption the single highest-ROI security investment for healthcare organizations. A stolen encrypted laptop is a security incident. A stolen unencrypted laptop with patient data is a reportable breach potentially affecting thousands of individuals.

2. Logging Infrastructure

You can't perform the four-factor risk assessment without comprehensive logs:

Access logs — Who accessed the compromised system and when
Data access logs — Which specific records were viewed, exported, or modified
Network logs — What data left your network and where it went
Authentication logs — How the unauthorized access was achieved

Without this data, you can't determine the scope of the incident, which means you may need to assume worst-case and notify everyone whose data was in the compromised system.

3. Incident Response Automation

When the clock is ticking, manual processes fail. Your incident response should include:

Automated containment — Revoke sessions, isolate affected systems, block suspicious IPs
Automated evidence preservation — Snapshot affected systems, preserve logs, capture memory dumps
Pre-built notification templates — Have individual notification letters, media statements, and HHS reporting forms ready to customize
Communication playbooks — Who contacts legal, who contacts the covered entity (if you're a BA), who manages the technical response

4. Forensic Readiness

Post-breach investigation is dramatically easier if you've prepared:

Immutable audit logs (can't be tampered with by an attacker covering their tracks)
Centralized log aggregation (don't rely on logs stored on compromised systems)
Baseline network traffic patterns (so you can identify anomalous data exfiltration)
Data flow documentation (knowing where PHI lives helps scope the incident)

Real Cost of Non-Compliance

HIPAA breach notification failures carry separate penalties from the underlying security failures:

Failure to notify affected individuals — Up to $2.1 million per violation category per year
Failure to notify HHS — Additional penalties on top of breach penalties
State attorney general actions — Many states have parallel notification requirements with their own penalties
OCR investigations — A reported breach triggers an OCR investigation that examines your entire compliance program, not just the breach itself

The Breach Notification Rule is also why your Security Risk Analysis matters so much. If OCR investigates a breach and finds you never conducted an SRA, the penalties multiply. The SRA should have identified the vulnerabilities that led to the breach, and the remediation plan should have addressed them.

For organizations building or improving their incident response capabilities, understanding how breach notification connects to your broader compliance program is critical: HIPAA Compliance Solutions

And the foundation that makes breach response defensible — a thorough, documented risk analysis: HIPAA Risk Analysis Tools

Joe Gellatly is CEO of Medcurity, a HIPAA compliance platform that helps healthcare organizations manage risk assessments, compliance programs, and incident documentation.

HIPAA Business Associate Agreements: What Developers Building Healthcare Integrations Need to Know

Joe Gellatly — Tue, 21 Apr 2026 03:50:28 +0000

You've built a great SaaS product. A hospital wants to use it. Before any data flows, their compliance team sends you a Business Associate Agreement (BAA) and asks you to sign it.

If you don't know what you're signing — or what obligations it creates — you're taking on legal liability that could cost your company millions.

What Makes You a Business Associate

Under HIPAA, a Business Associate is any person or organization that creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity (healthcare providers, health plans, clearinghouses).

For software teams, this means you're a business associate if:

Your application stores patient data for a clinic or hospital
Your API processes, routes, or transforms PHI
Your cloud infrastructure hosts ePHI workloads
Your analytics platform ingests data that includes patient identifiers
Your customer support team can access PHI during troubleshooting
Your backup systems contain copies of ePHI

The key phrase is "on behalf of." If a healthcare provider uses your product and PHI passes through it, you're almost certainly a business associate — even if you never look at the data yourself.

What a BAA Actually Requires

A BAA isn't just a formality. It's a legally binding contract that requires you to:

1. Implement HIPAA Security Safeguards

You must apply the same administrative, physical, and technical safeguards that covered entities are required to implement. That means encryption, access controls, audit logging, workforce training, and a documented security program.

2. Report Breaches

If you discover a breach of unsecured PHI, you must notify the covered entity within 60 days (many BAAs negotiate this down to 10-30 days). "Discovery" includes when any employee or agent of your organization knows about it — not just when leadership finds out.

3. Ensure Subcontractor Compliance

If you use subcontractors who will access PHI (cloud providers, monitoring services, email platforms), you need BAAs with them too. The chain of BAAs must extend to every entity that touches PHI.

4. Make PHI Available for Patient Rights Requests

If a patient requests access to their records and your system holds those records, you need processes to support the covered entity in fulfilling that request within 30 days.

5. Return or Destroy PHI at Contract End

When the relationship ends, you must return all PHI to the covered entity or destroy it — and certify the destruction. This includes backups, logs, cached data, and any derived datasets.

The Subcontractor Chain Problem

This is where most development teams get tripped up. Consider a typical SaaS stack:

Your Healthcare SaaS App
├── AWS (infrastructure) → Need BAA ✓ (AWS offers one)
├── Datadog (monitoring) → Need BAA if logs contain PHI
├── SendGrid (email) → Need BAA if emails contain PHI
├── Stripe (payments) → Usually no PHI, but verify
├── Slack (internal comms) → Need BAA if team discusses PHI
├── Jira (issue tracking) → Need BAA if tickets contain PHI
└── GitHub (code repos) → Need BAA if repos contain PHI

Every tool in your stack that could come into contact with PHI needs a BAA. The major cloud providers (AWS, GCP, Azure) all offer BAAs. Many SaaS tools do not — which means you either need to find alternatives that do, or ensure PHI never touches those systems.

Common BAA Mistakes

Assuming your cloud provider's BAA covers everything

AWS's BAA covers their infrastructure services, but it doesn't make your application compliant. You're still responsible for how you configure and use those services. An S3 bucket without encryption, a publicly accessible RDS instance, or an unencrypted EBS volume are all your problem, not AWS's.

Not having a BAA before data flows

The BAA must be executed before any PHI is created, received, maintained, or transmitted. Retroactive BAAs don't fix the compliance gap during the period without one.

Using personal or non-BAA-covered tools for PHI

A developer SSHs into a production server and copies patient data to their laptop for debugging. That laptop isn't covered by your BAA with the healthcare client. Now you have an uncontrolled PHI exposure.

Ignoring the minimum necessary standard

Your BAA doesn't give you carte blanche to access all PHI. You should only access, use, or disclose the minimum necessary PHI to perform the service specified in the BAA.

Practical Steps for Dev Teams

Inventory your PHI touchpoints — Map every system, service, and workflow where PHI could exist
Audit your vendor stack — Identify which vendors have BAAs available and which don't
Implement technical controls — Encryption, access controls, and audit logging across all PHI-touching systems
Document your security program — You need policies, procedures, and evidence that you're actually following them
Conduct a Security Risk Analysis — Assess the risks to ePHI in your environment and document your remediation plans

Making It Manageable

For SaaS companies entering the healthcare space, the BAA and compliance requirements can feel overwhelming. The key is treating compliance as an engineering problem, not a legal one — build it into your architecture, automate the tracking, and maintain documentation as a living system rather than a point-in-time exercise.

For a comprehensive look at how to manage BAAs and other compliance requirements as part of your broader HIPAA program: HIPAA Compliance Solutions

And if you're starting from the foundation — the Security Risk Analysis that drives your entire compliance program: What Is a HIPAA Security Risk Analysis?

Joe Gellatly is CEO of Medcurity, a HIPAA compliance platform that helps healthcare organizations and their business associates manage risk assessments, BAA tracking, and compliance programs.