DEV Community: Joe Gellatly

The independent nurse practitioner's HIPAA guide for 2026

Joe Gellatly — Fri, 08 May 2026 19:41:54 +0000

If you're a nurse practitioner running an independent practice — solo, with one or two staff, possibly part-time alongside another role — HIPAA compliance is one of those topics where the rules don't bend for your size. The 2026 HIPAA Security Rule amendments tightened the technical-controls floor for everyone, and the 25 states with full NP practice authority have been adding their own state-level data-protection layers on top.

This is the practical map I'd hand a friend who just opened their own NP practice in 2026.

You are now a covered entity

The single biggest mental shift for an NP moving from employee to independent practice is that you are now the covered entity. Whatever you used to assume your employer's compliance officer was handling — that's your job now.

Specifically you're personally responsible for:

The Privacy Rule. Notice of Privacy Practices, patient rights, minimum-necessary rules, etc.
The Security Rule. Administrative, physical, and technical safeguards for ePHI.
The Breach Notification Rule. 60-day reporting obligations to affected individuals, OCR, and (for 500+) the media.
HITECH and the 2026 amendments. Annual SRA, MFA on remote access, encryption, asset inventory, BA verification.

The good news: scale changes practical implementation, not the categories.

The 2026 amendments — what changed for small NP practices

The 2026 Security Rule amendments are still in finalization motion, but the directional changes are universally adopted in product roadmaps and audit posture already. The pieces that matter most for a solo or small NP practice:

MFA is the assumed default for remote access. If you log into your EHR from home or on the road, MFA needs to be turned on. Almost every modern EHR offers it — this is a checkbox, not a build.
Encryption at rest and in transit is no longer effectively optional. Cloud-hosted EHRs handle this natively; the gap is usually local devices and removable media.
Asset inventory — for a solo NP this is small, but it has to exist in writing. Laptop(s), phones, any external drives, point-of-care devices.
Annual BA verification. Each vendor that touches PHI — your EHR, billing service, transcription service, telehealth platform — needs annual evidence of continued compliance.
Documented configuration management. Even at NP-practice scale, you need a written record of who has access to what, with last-reviewed dates.

The minimum compliance stack for a solo NP practice

If I'm setting up an independent NP practice today, here's the minimum stack:

1. A HIPAA-compliant EHR with a signed BAA

Almost every cloud EHR aimed at small practices offers a BAA. The friction is asking for it explicitly and storing it. If your EHR vendor will not sign a BAA, that's a deal-breaker — switch.

2. A HIPAA-compliant telehealth platform if you do video visits

Same BAA gate. Most modern dedicated telehealth platforms cleared this years ago; some general-purpose video tools have HIPAA-compliant tiers, others don't.

3. MFA on every account that touches PHI

EHR, billing, telehealth, email if you use it for PHI. The phone-based authenticator app (Authy, Google Authenticator, etc.) is fine. SMS-only MFA is allowed but no longer the recommended default.

4. A device-level encryption posture

Your laptop disk should be encrypted (FileVault on Mac, BitLocker on Windows). Your phone's default encryption is sufficient as long as it's behind a strong passcode and biometric.

5. An annual SRA

This is the legally-required "are you in compliance" check. There's no good way around it. The choice is to use a guided tool, hire a consultant, or use a vendor platform — all are valid; the unfortunate option is "skip it."

6. Notice of Privacy Practices, posted and provided

Patients are entitled to receive your NPP at first encounter. This is a Privacy Rule requirement, not Security Rule, and it's easy to overlook in the technical-controls focus.

7. A breach response plan, even if it's one page

Knowing what you'd do in the first 24 hours of a suspected breach matters more than the document itself. The breach-notification clock starts at discovery, not at confirmation.

The state-level layer

If you practice in a full-practice-authority state, you also have state-level data-protection rules that interact with HIPAA. A few worth knowing:

California: CMIA imposes its own confidentiality and breach-notification regime, sometimes stricter than HIPAA.
Texas: HB 300 expands patient access rights and requires biennial training documentation.
New York: SHIELD Act applies to any business holding NY-resident PI, with overlapping obligations.

State laws don't replace HIPAA; they layer on top. The practical answer is to comply with whichever rule is stricter on each issue.

Where most NP practices actually fail audits

Anecdotally, the most common gaps in small NP practice audits aren't the dramatic ones. They're:

No documented annual SRA. The legal foundation; missing it cascades.
No BA list. No record of which vendors have BAAs and when they were last reviewed.
NPP not visibly provided. Not posted, no acknowledgment captured.
Email containing PHI sent through non-compliant providers.
MFA off on EHR remote-login accounts.

None of these are technical engineering problems. They're operational rhythm problems.

Practical sequencing for a new NP practice

If I were standing one up tomorrow:

Day 1: pick HIPAA-compliant EHR + telehealth platform; sign BAAs.
Week 1: enable MFA on every PHI account; encrypt every device.
Month 1: complete first SRA; write NPP and breach response plan; build BA list.
Quarterly: BA verification rhythm; access review; backup verification.
Annually: SRA refresh; NPP review; staff training (even if "staff" is one MA).

The cadence is what makes the system survive. Compliance done as one big push and then ignored becomes the audit gap two years later.

For a deeper dive on the 2026 HIPAA Security Rule and how independent NP practices are scoping these controls, see Medcurity's HIPAA compliance for small practices, the HIPAA Security Rule 2026 explainer, the BAA template page, and the best HIPAA SRA software comparison for 2026.

Telehealth HIPAA after the Cures Act: what changed for engineers in 2026

Joe Gellatly — Tue, 05 May 2026 02:49:29 +0000

If you wrote your telehealth platform's HIPAA story before 2025, the rules you compiled it against don't all hold anymore.

The 21st Century Cures Act (and ONC's information-blocking rule that operationalizes it) reshaped what providers and their telehealth vendors are required to do with patient data. The 2026 HIPAA Security Rule amendments then layered new technical controls on top. Together they pushed telehealth from a "build a secure pipe and you're fine" posture toward something closer to "build a secure pipe, log every byte, prove access on demand, and never delay a legitimate data request."

This is the engineer-and-architect's version of what changed and what it means for a platform you're shipping today.

What the Cures Act actually requires of telehealth

The Cures Act's information-blocking provisions apply to providers and their health-IT actors — and most modern telehealth vendors qualify as one or the other. The shorthand most engineers carry around is "patients have a right to their data," but the operational shape is more pointed:

A patient (or their designated app) requests access to USCDI data — including notes, results, and demographics.
You must respond unless one of eight specific exceptions applies.
"Unable to comply" answers, throttling, opaque error messages, and queue delays can all be construed as information blocking if they look like friction-by-design.

For telehealth platforms this lands hardest on three surfaces:

Patient-facing portal exports. Pre-Cures Act, "we'll mail it on a CD" was technically compliant. Post-Cures Act, friction is the violation.
Third-party app integrations. A patient pointing a personal app at your FHIR endpoint has a right to that data. Your auth flow can't quietly block it.
EHR / partner integrations. If you white-label to a hospital, their obligations flow through your APIs.

What the 2026 HIPAA Security Rule changed in this same surface

The 2026 amendments are still in regulatory motion at the time of writing — finalization status remains the part to watch — but the directional changes are clear and almost universally adopted in product roadmaps already:

MFA on remote-administrative access is now assumed, not optional.
Encryption at rest and in transit is no longer "addressable" for most categories.
Asset inventory is a first-class control, not a paperwork exercise.
Annual Business Associate verification is now required (previously a one-time-at-onboarding check).
Configuration-management evidence has to be producible on demand.

Pair these with the Cures Act's "don't quietly drop the request" posture, and the design implications stack quickly.

Five things engineering teams I talked to actually changed

Here's what I see in real codebases since the start of 2025.

1. Idempotent, audited export endpoints

Pre-Cures, export was a feature. Post-Cures, export is a system. Teams added:

A dedicated /export API path with strict rate limits but no quiet deny — every refusal returns a documented 1-of-8 exception code, not a 429-and-retry-later.
Server-side audit log entries for every export call (who, what, when, scope, exception-or-success).
Background-job pattern with a status URL the patient/app can poll, so "the export is taking 6 minutes" is observable rather than mysterious.

2. Real third-party app onboarding (not just OAuth-and-pray)

Patient app developers don't go through your sales team. They register, get a token, and pull data. The old approach — friction every step of the way — now reads as deliberate blocking.

Most teams I talked to moved to:

A self-serve developer portal with a sandbox.
Public docs covering all USCDI v3 elements your platform exposes.
Token-issuance latency budgeted under 24 hours of human review (above that and you start looking like you're stalling).

3. Asset inventory as an actual data store

The 2026 Security Rule asset-inventory requirement is the one that bit teams hardest in early audits. The "spreadsheet of laptops" approach doesn't pass anymore. Production platforms moved to:

A live asset registry (CMDB or equivalent) populated by your provisioning pipeline.
Per-asset linkage to the data classifications it touches.
A weekly reconciliation job that surfaces drift.

It's not a HIPAA-specific tool — most teams use whatever they already use for SOC 2 — but the coverage expectation jumped.

4. Logging that survives a subpoena

Telehealth logs always collected the basics. What changed is that "the basics" expanded:

Every PHI read/write/export — not just write.
Authentication events including failed attempts and MFA challenge outcomes.
Configuration changes with a diff and an actor.
6-year retention is the practical floor.

The volume increase is real. Most teams either shipped to a SIEM or to a partitioned data lake with cold-tier rules tuned for 6+ year retention.

5. BAA verification as a quarterly rhythm

Annual BA verification is the under-the-radar 2026 change. Engineering ends up owning chunks of this when:

Your platform is the BA in the customer's contract — they are verifying you.
Your platform has sub-BAs (cloud, observability, transcription, etc.) — you are verifying them.

The clean implementation is a quarterly job that fans out a verification questionnaire to each BA partner and surfaces the responses to your compliance team.

Where this leaves a 2026 telehealth roadmap

If you're prioritizing what to build next, this is the rough order I'd push:

Audit-grade export endpoints with documented exception responses.
A self-serve third-party-app developer portal with a sandbox.
Live asset inventory wired to provisioning.
PHI access logs unified into a single retention-controlled stream.
Quarterly BA verification job.

None of these is a Cures Act item or a 2026 Security Rule item in isolation — they're both, layered. That's the lens that makes the work tractable.

For more on the 2026 HIPAA Security Rule and the engineering-side controls telehealth platforms are scoping, see Medcurity's HIPAA Security Rule 2026 explainer, the best HIPAA SRA software comparison for 2026, the HIPAA penetration testing requirements guide, and the HIPAA vulnerability scanning requirements guide.

What 3 Recent OCR Enforcement Actions Against FQHCs Tell Developers About 2026 HIPAA Reality

Joe Gellatly — Tue, 28 Apr 2026 18:18:06 +0000

If you're a developer or security engineer at a community health center, the three OCR enforcement actions from the past 18 months against FQHCs are the clearest picture you'll get of how the 2026 HIPAA Security Rule will actually be enforced in your org. Not the press releases. Not the blog posts from vendors pitching tools. The Resolution Agreements. They read like architecture reviews — and most of the findings map to stuff that lives in your issue tracker on a Tuesday.

The three cases (anonymized + paraphrased where the original Medium piece named them)

Case 1 — Mobile device inventory failure. A multi-site FQHC settled after an unencrypted laptop with ~18K patient records walked out of a dental clinic. The finding wasn't the theft. It was the absence of a complete, current IT asset inventory. The device didn't exist on the inventory the health center provided OCR during the investigation.

Dev lesson: your asset inventory is a compliance artifact, not an IT hygiene nice-to-have. Build the automation now so the list is current without a quarterly ceremony.

Case 2 — Access control drift. A CHC settled after a workforce member accessed a high-profile patient's record 47 times over 6 months without a treatment relationship. OCR's finding: the access control model was documented but not enforced — the EHR audit logs showed the accesses, but the monitoring that would have flagged them wasn't wired up.

Dev lesson: documented controls ≠ enforced controls. If your EHR audit logs aren't being aggregated into a signal you actually review, you've built a liability, not a defense.

Case 3 — BAA gap. A CHC settled after a breach traced to a third-party appointment-reminder vendor. The BAA with that vendor had expired 11 months earlier. Nobody noticed because the BAA was a PDF in a SharePoint folder, not a tracked object in the compliance stack.

Dev lesson: treat your BAA inventory like you'd treat a secrets inventory — with expiration alerts, auto-renewal workflows, and ownership.

What this means for 2026 HIPAA Security Rule work

The 2026 revisions tightened expectations around encryption, MFA, asset inventory, and 72-hour incident assessment. All three of these OCR cases would have been caught earlier by the 2026 rule's explicit requirements. The gap isn't the rule — it's the operational glue.

Three engineering moves FQHCs should make now:

Wire asset inventory to CMDB + MDM events, not a spreadsheet. Every enrolled laptop, iPad, or dental-cart device flows into the compliance inventory automatically.
Aggregate EHR access logs into a SIEM with monitoring rules for high-profile patient access patterns. Write the rules before the breach.
Put BAAs behind expiration alerts with auto-escalation to a named owner 90 days out.

Why this matters for FQHCs specifically

FQHCs carry HRSA grant conditions and FTCA deeming on top of HIPAA. An OCR enforcement action against an FQHC cascades — it shows up at the next HRSA Operational Site Visit and in the FTCA redeeming package. The operational spend to prevent all three cases above is a fraction of the compliance debt they create.

If you're building or buying the compliance tooling that catches these before OCR does, start here:

The Community Health Center Security Risk Assessment is what OCR expects to see during any investigation of a CHC or FQHC.
HIPAA compliance for rural health clinics and small rural hospitals covers the RHC/CAH-side of most FQHC network arrangements.
The 2026 HIPAA Security Rule explainer walks the new clauses clause-by-clause.
HIPAA compliance cost breakdown if you're pricing the build-vs-buy.
Best HIPAA risk assessment tools 2026 compares the vendors that can actually produce audit-ready artifacts.
HIPAA compliance for FQHCs — the HRSA + FTCA + OSHA + HIPAA alignment page.

Closing

OCR enforcement actions against FQHCs read like post-mortems. If yours isn't the next one, the work is in the automation — inventory, access monitoring, BAA lifecycle. The 2026 rule makes the expectation explicit. The question is whether your stack reflects it.

HIPAA Security Risk Analysis at 90 Days: What the 2026 Rule Actually Changed in Practice

Joe Gellatly — Sat, 25 Apr 2026 00:53:35 +0000

It has been 90 days since the 2026 HIPAA Security Rule update took effect. Long enough for the initial "wait, does this apply to us?" panic to settle, short enough that most healthcare orgs haven't finished their first post-rule Security Risk Analysis (SRA).

I've spent the last quarter watching how small and mid-market healthcare organizations — FQHCs, critical access hospitals, multi-location dental groups, specialty practices, a handful of telehealth startups — actually implement the new SRA requirements in the wild. Here is what's changed in practice, separated cleanly from what hasn't.

The SRA itself: still the cornerstone, but the evidence bar moved

The 2026 update didn't invent the Security Risk Analysis. HIPAA has required one since 2005. What changed is the evidence standard. Under the old rule, a one-page risk summary signed by a compliance officer was, in practice, defensible against an OCR audit if nothing bad happened. Under the 2026 rule, OCR investigators now routinely ask for four specific artifacts:

A current asset inventory with PHI touch-points marked explicitly
A threat model that references the specific EHR, communication stack, and backup vendors the org actually uses
A vulnerability treatment plan with remediation dates, owners, and evidence of execution
A documented risk-acceptance log for anything left unremediated, signed by a named executive

If you can't produce all four during an audit, your SRA is treated as incomplete. This is the biggest real-world delta from the pre-2026 posture.

MFA and encryption: finally mandatory, with exceptions that are narrower than people think

The 2026 rule moved multi-factor authentication and encryption for PHI at rest from "addressable" to effectively required. The headlines all covered this. What the headlines missed: the exception window is narrower than practitioners assume.

The narrow path to claiming an exception still requires:

A documented reason the safeguard is not reasonable or appropriate
A documented alternative safeguard that achieves equivalent protection
A documented review cycle (at minimum annually) for when the condition changes

In practice, most small practices and FQHCs I've worked with discovered during their Q1 SRA that their existing IT stack already supports MFA and disk encryption — they just hadn't turned it on. The 2026 rule effectively closed the "we can't afford it" argument for anyone on a modern EHR or Microsoft 365 deployment.

Business Associate Agreements got teeth

The old BAA review pattern was: collect the signed agreement at vendor onboarding, put it in a folder, never look at it again. The 2026 rule adds an annual BAA verification step — you have to confirm the Business Associate is still meeting its obligations, not just that the contract exists.

The clean way to satisfy this: an annual questionnaire to each BA that captures (a) any security incidents in the past 12 months, (b) changes to their subcontractor list, (c) changes to their breach notification process, (d) confirmation that their own SRA is current. Any BA that refuses to respond — or responds with "no changes" to everything for multiple years — is a risk signal that the annual review is supposed to surface.

Most small practices have between 15 and 40 Business Associates once you count telehealth platforms, billing services, cloud backup, EHR hosting, messaging vendors, and ancillary service providers. That's 15–40 annual verifications, which is not zero work but is also not impossible to systematize.

Contingency plan testing: OCR asks for the run log now

The pre-2026 requirement was that you have a contingency plan. The 2026 update requires you to test it annually AND retain the run log. In practice this means a yearly tabletop exercise with:

A documented scenario (ransomware hitting the EHR, for example)
A roster of who participated
A log of what decisions got made during the simulated incident
A list of what broke or was unclear
A revision of the plan based on what was learned

An untested contingency plan that looks great on paper is, post-2026, treated roughly the same as not having one at all.

What didn't change: the SRA is still annual + after significant change

A persistent myth is that the 2026 rule changed the SRA cadence. It didn't. The cadence is still: at least annually, AND after any significant change in operations, technology, staff, or threat environment. "Significant change" includes EHR migrations, new service lines, acquisitions, ransomware incidents in your sector, and — per OCR's latest guidance — major workforce turnover in privacy or security roles.

What also didn't change: there is no OCR-blessed SRA template that works for every org. The rule still describes an approach; each covered entity is still responsible for tailoring it to its own risk posture.

What small practices and FQHCs are getting wrong 90 days in

Three recurring failure patterns I've seen during Q1 post-2026 SRAs:

Copying someone else's asset inventory. The asset inventory is where most orgs try to cut corners, reusing a list from a peer org or from an old NIST CSF assessment. OCR investigators notice when the asset list doesn't match the EHR+stack the org actually operates. Build the inventory from scratch.
Treating MFA as purely an admin-user requirement. The 2026 rule effectively applies MFA to any account that can access PHI, not just admin accounts. That includes clinicians, nurses, billing staff, and — critically — vendor accounts used by BAs to connect into your systems. Most orgs miss the vendor-account leg.
Skipping the risk-acceptance log. If a finding from the SRA isn't remediated, the 2026 rule requires a documented decision that someone with authority accepts the residual risk. A finding left in the "open" column of a spreadsheet without an acceptance memo is not the same thing.

The upshot

If you did a solid SRA under the pre-2026 rule, you're 70 percent of the way to a solid SRA under the 2026 rule — plus the four artifacts, plus MFA closure, plus the BAA annual verification, plus the contingency-plan run log. That's a week of work for most small practices and a month for mid-sized FQHCs with more BAs and more complex stacks.

If you haven't started, start with the asset inventory. Every other artifact depends on it.

Medcurity builds HIPAA compliance software for small and mid-market healthcare organizations that need the artifacts the 2026 rule requires, without the enterprise-tier sticker shock. If you're scoping your first post-2026 SRA, our pillar on the best HIPAA SRA software for 2026 is the next read.

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.