Forem: Joe Gellatly

HIPAA Audit Logging Requirements: What to Log, How to Protect It, and Why It Matters in an Investigation

Joe Gellatly — Fri, 03 Apr 2026 16:38:05 +0000

HIPAA's audit control requirement (45 CFR 164.312(b)) is exactly one sentence long: "Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."

That's it. No specifics on what to log, how long to keep it, or what format to use. This is by design -- HIPAA is technology-neutral and scales from solo dental practices to massive hospital networks. But it means the implementation details are on you.

Here's what actually matters when building audit logging for HIPAA-covered systems.

What You Need to Log

Authentication Events

Successful logins (user, timestamp, source IP, device identifier)
Failed login attempts (especially important for detecting brute force attacks)
Password changes and resets
MFA enrollment and verification events
Session creation and termination
Account lockouts

PHI Access Events

This is the most critical category and where most systems fall short:

Record-level access -- Which user accessed which patient's records, when, and from where
What action was taken -- View, create, modify, delete, print, export, download
Search queries -- What search terms were used to find patient records (this catches the employee who searches for a celebrity patient's name)
Bulk operations -- Any export, report generation, or query that returns multiple patient records
Emergency access ("break the glass") -- When someone overrides normal access controls for emergency patient care, log it with extra detail

System Configuration Changes

Access control modifications (role changes, permission grants/revocations)
Encryption setting changes
Audit log configuration changes (meta-logging -- who turned off logging?)
Network security changes (firewall rules, security group modifications)
Backup configuration changes
User account creation, modification, and deactivation

Data Movement

PHI exports (to files, reports, external systems)
Data transfers to business associates
Backup operations
Data destruction/deletion events
Print jobs containing PHI

How to Structure Audit Logs

Every log entry needs these fields at minimum:

{
  "timestamp": "2026-04-03T14:23:17.445Z",
  "event_type": "phi_access",
  "action": "view",
  "user_id": "provider_12345",
  "user_role": "physician",
  "patient_id": "patient_67890",
  "resource": "medical_record",
  "resource_id": "record_11111",
  "source_ip": "10.0.1.45",
  "session_id": "sess_abc123",
  "result": "success",
  "facility": "main_clinic"
}

Key principles:

Use UTC timestamps -- Consistent timezone eliminates confusion during investigations
Include both user and patient identifiers -- You need to answer "who accessed this patient's data?" and "what data did this user access?"
Structured format -- JSON or similar structured format. Free-text logs are nearly impossible to query at scale during an investigation.
Immutable -- Once written, log entries cannot be modified or deleted

Log Protection

This is where many organizations fail. Logs that can be tampered with are worthless in an investigation.

Immutability

Write logs to append-only storage (S3 with Object Lock, WORM storage, immutable database tables)
Separate log storage from application infrastructure -- a compromised application server shouldn't be able to delete its own audit trail
Use a dedicated logging account/project with restricted access

Access Control

Only the security/compliance team should have read access to audit logs
No one should have delete access (enforce through storage-level immutability)
Application service accounts should have write-only access -- they can create log entries but not read or modify them
Log access to the logs (yes, meta-logging is necessary)

Retention

HIPAA requires 6-year retention for compliance documentation. While audit logs aren't explicitly called out in the retention requirement, OCR investigations routinely request historical logs, and organizations that can't produce them face harder scrutiny.

Recommended approach:

Hot storage (searchable, fast query): 90 days to 1 year
Warm storage (archived but retrievable): 1-3 years
Cold storage (compressed, longer retrieval time): 3-6 years

Encryption

Audit logs themselves may contain PHI references (patient IDs, user actions on specific records). Encrypt logs at rest and in transit using the same standards as your ePHI.

Real-Time Monitoring and Alerting

Logging without monitoring is just creating evidence of breaches you didn't catch. Set up alerts for:

Unusual access patterns -- A user accessing significantly more records than their normal baseline
After-hours access -- PHI access outside of normal business hours (especially for roles that shouldn't need it)
Failed authentication spikes -- Potential brute force or credential stuffing attacks
Bulk data exports -- Any export exceeding a threshold should trigger review
Privilege escalation -- Role changes or permission modifications
Geographic anomalies -- Access from unexpected locations
Configuration changes -- Any modification to security controls

Audit Log Review

Having logs isn't enough -- HIPAA expects you to actually review them. Document your review process:

Frequency -- At minimum monthly, with real-time alerting for critical events
Who reviews -- Designated compliance or security team members
What they look for -- Anomalous patterns, policy violations, unauthorized access attempts
Documentation -- Record that reviews occurred, what was found, and what actions were taken
Escalation procedures -- Clear process for when a review identifies a potential incident

Common Audit Logging Failures

Only logging authentication

Many systems log who logged in and out but nothing about what they did once inside. OCR wants to see PHI access logs, not just login records.

Logging too little detail

"User accessed patient record" isn't useful. You need the specific record, what they viewed/modified, and the context.

Mutable log storage

If your logs are in a database table that application admins can modify, they won't hold up under scrutiny. Immutability is non-negotiable.

No log review process

Creating logs and never looking at them is a compliance gap. Document your review procedures and actually follow them.

Short retention

Deleting logs after 90 days means you can't respond to OCR requests about incidents from a year ago.

The Compliance Connection

Your audit logging implementation should be driven by your Security Risk Analysis. The SRA identifies which systems contain ePHI and what threats exist -- audit logging is a key control for detecting and investigating those threats.

For the risk analysis foundation that drives your logging requirements: HIPAA Risk Analysis Tools

And for comprehensive compliance management including audit controls: HIPAA Compliance Solutions

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

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

Joe Gellatly — Thu, 02 Apr 2026 23:48:59 +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 — Thu, 02 Apr 2026 23:47:08 +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 — Thu, 02 Apr 2026 23:18:27 +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 was not compromised, it is 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 did not 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 have 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 are 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 cannot 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 cannot 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 are a BA), who manages the technical response

4. Forensic Readiness

Post-breach investigation is dramatically easier if you have prepared:

Immutable audit logs (cannot be tampered with by an attacker covering their tracks)
Centralized log aggregation (do not 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 dollars 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 — Thu, 02 Apr 2026 23:13:53 +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.

The 2026 HIPAA Compliance Checklist for Developers and IT Teams

Joe Gellatly — Thu, 02 Apr 2026 23:12:29 +0000

If you're building or maintaining software that touches protected health information (PHI), HIPAA compliance isn't something you can hand off to legal and forget about. The technical safeguards are your responsibility.

This checklist covers the requirements that actually matter for development and IT teams in 2026 — not the administrative fluff that compliance consultants pad their reports with.

Access Controls (45 CFR § 164.312(a))

The Security Rule requires unique user identification, emergency access procedures, automatic logoff, and encryption/decryption. Here's what that means in practice:

Unique user IDs for every system user — No shared accounts. Ever. This includes service accounts, database connections, and API keys. Every action touching PHI needs to trace back to an individual.
Role-based access control (RBAC) — Implement the minimum necessary standard. A billing clerk doesn't need access to clinical notes. A developer doesn't need production PHI access for debugging.
Automatic session timeout — Idle sessions must terminate. The specific timeout depends on the risk context — a workstation in a shared nurse's station needs a shorter timeout than a locked server room terminal.
Emergency access procedures — Document and test break-glass procedures for when normal authentication fails during a patient care emergency.
Multi-factor authentication — Not explicitly required by the 2026 rule text, but any risk analysis that concludes MFA isn't necessary for ePHI systems won't survive OCR scrutiny.

Audit Controls (45 CFR § 164.312(b))

Every system containing ePHI needs audit logging:

Who accessed what data
When they accessed it
What they did (read, write, delete, export)
From where (IP address, device identifier)

Your audit logs themselves are compliance artifacts — they need tamper protection, retention policies (minimum 6 years for HIPAA documentation), and regular review processes. Dumping everything to a log file that nobody reads doesn't satisfy the requirement.

Encryption Requirements (45 CFR § 164.312(a)(2)(iv) and (e)(1))

Data at rest — AES-256 for databases, file systems, backups, and removable media containing ePHI. Full-disk encryption on every device that might store PHI, including laptops, phones, and USB drives.
Data in transit — TLS 1.2 minimum (TLS 1.3 preferred) for all ePHI transmission. This includes internal network traffic, not just external-facing APIs. If your microservices communicate PHI over plaintext HTTP internally, that's a finding.
Key management — Documented procedures for key generation, distribution, storage, rotation, and destruction. HSMs or cloud KMS for production environments.

Integrity Controls (45 CFR § 164.312(c)(1))

Mechanisms to confirm ePHI hasn't been altered or destroyed improperly:

Database integrity checks — Checksums, hash verification, or similar mechanisms for critical ePHI stores
Transmission integrity — Message authentication codes or digital signatures for ePHI in transit
Change management — Version control, code review, and deployment pipelines that prevent unauthorized modifications to systems handling PHI

Backup and Disaster Recovery (45 CFR § 164.308(a)(7))

Retrievable exact copies of ePHI — Automated, tested backups with documented recovery procedures
Disaster recovery plan — Document RPO (Recovery Point Objective) and RTO (Recovery Time Objective) for every system containing ePHI
Testing — Actually restore from backups regularly. An untested backup is Schrödinger's backup — it simultaneously works and doesn't work until you try it.
Geographic redundancy — For cloud deployments, ensure backups exist in a separate region/availability zone

Vulnerability Management

Patch management — Document patching timelines. Critical vulnerabilities in ePHI systems should be patched within days, not months.
Penetration testing — At least annual, covering all ePHI-accessible systems
Vulnerability scanning — Automated, continuous scanning of infrastructure and applications
Software composition analysis — Know your dependencies. A vulnerable library in your patient portal is your vulnerability.

Business Associate Requirements

If you're a vendor handling PHI for a covered entity (or a subcontractor of one):

Business Associate Agreement (BAA) — Must be executed before any PHI access. No exceptions, no verbal agreements.
Subcontractor chain — If you use AWS, GCP, or Azure for PHI workloads, you need a BAA with them. Same for any SaaS tools that might touch PHI (logging services, monitoring tools, email providers).
Breach notification obligations — Business associates must report breaches to the covered entity within 60 days. Your incident response plan needs to account for this.

The Risk Analysis Foundation

Every item on this checklist should trace back to your Security Risk Analysis (SRA). The SRA identifies where ePHI lives, what threats exist, and what controls are needed. Without it, you're implementing controls based on guesswork rather than assessed risk.

For a detailed breakdown of how to structure your compliance checklist around assessed risks, this resource covers the full framework: HIPAA Compliance Checklist 2026

Automating Compliance Tracking

Manually tracking all of these requirements across an organization is where compliance programs break down. Spreadsheets get outdated, documentation gaps appear, and remediation items fall through the cracks.

Modern compliance platforms maintain a living view of your compliance posture — tracking which controls are implemented, which have gaps, and what remediation is needed. For an overview of how automated compliance management works in practice: HIPAA Compliance Solutions

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

Building Effective HIPAA Training Programs: What Healthcare Dev Teams Get Wrong

Joe Gellatly — Thu, 02 Apr 2026 23:04:52 +0000

Every healthcare data breach postmortem has the same theme: someone on the team didn't know what they weren't supposed to do.

A receptionist emailed patient records to a personal Gmail account. A developer left PHI in a debug log that shipped to production. A dental office manager shared login credentials across the entire front desk staff. An IT admin disabled encryption on a laptop "temporarily" and forgot to re-enable it.

HIPAA training is supposed to prevent these scenarios. But the way most organizations approach it — a generic annual slideshow followed by a signature on a form — doesn't work. Here's what actually does.

Why Generic Training Fails

HIPAA's training requirement (45 CFR § 164.530(b)) mandates that covered entities train all workforce members on policies and procedures related to PHI. The problem is that HIPAA doesn't prescribe how to train — so most organizations default to the lowest-effort approach.

A 45-minute annual video about "the importance of protecting patient data" teaches a billing coordinator nothing about the specific PHI risks in their daily workflow. A developer building a patient portal has completely different compliance exposure than a front desk receptionist.

Generic training produces generic compliance: people pass the quiz and forget everything by lunch.

What Effective HIPAA Training Actually Covers

For Clinical and Administrative Staff

Clinical teams need training specific to their patient interactions:

Minimum necessary access — Only accessing the PHI you need for the task at hand. Looking up a celebrity patient's records out of curiosity? That's a violation, and it happens more often than anyone admits.
Verbal PHI exposure — Discussing patient information in waiting rooms, elevators, or cafeterias. Physical layout matters: can patients in the waiting area overhear phone conversations at the front desk?
Secure communication — When is it okay to email PHI? (Short answer: only with encryption.) What about texting? Faxing? Each channel has different rules.
Device security — Locking workstations when stepping away, not leaving charts on desks, proper disposal of paper records.

For Development and IT Teams

Technical teams need training that connects HIPAA requirements to their actual work:

PHI in development environments — Never use real patient data in dev/staging. This seems obvious but production database copies end up in development environments constantly.
Logging and monitoring — What can and can't be logged. Patient names and medical record numbers in application logs are PHI and need the same protections as the database.
API security — Authentication, authorization, encryption in transit. If your healthcare API returns more data than the requesting user needs, you're violating the minimum necessary standard.
Incident recognition — Developers are often the first to notice anomalous behavior in systems. They need to know what constitutes a reportable incident and who to escalate to.
Access provisioning/deprovisioning — When someone leaves the organization or changes roles, how quickly are their access rights updated? Orphaned accounts are a top audit finding.

For Dental Practices Specifically

Dental offices face unique training challenges because they're often smaller practices where everyone wears multiple hats:

Staff handling both reception and billing need cross-functional PHI training
Imaging data (X-rays, 3D scans) is PHI and needs the same protections as text records
Patient portals create new PHI exposure points that staff need to understand
Third-party imaging labs and specialists require Business Associate Agreements

For a detailed look at HIPAA training requirements specific to dental practices, this guide breaks down exactly what's needed: HIPAA Training for Dental Offices

The Training Framework That Works

After working with healthcare organizations of all sizes, here's the structure that produces measurable compliance improvement:

1. Role-Based Modules

Split training into role-specific tracks:

\`
Clinical Staff Track
├── PHI identification and handling
├── Patient rights and Notice of Privacy Practices
├── Verbal and physical PHI safeguards
└── Incident reporting procedures

Administrative Staff Track
├── Front desk PHI protocols
├── Insurance and billing data handling
├── Communication channel security
└── Business Associate awareness

Technical Staff Track
├── ePHI system architecture requirements
├── Access control implementation
├── Audit logging requirements
├── Vulnerability management and patching
└── Incident response procedures

Management Track
├── Risk assessment leadership
├── Policy enforcement responsibilities
├── Breach notification requirements
└── Compliance program oversight
`\

2. Scenario-Based Learning

Abstract rules don't stick. Scenarios do:

"A patient calls and asks you to fax their records to their new doctor. What's the correct procedure?"
"You discover your colleague has been looking up records for patients not in their caseload. What do you do?"
"A vendor asks for remote access to troubleshoot your EHR system. What needs to be in place first?"

3. Continuous Reinforcement

Annual training isn't enough. Implement:

Monthly micro-trainings — 5-minute scenarios delivered via email or Slack
Phishing simulations — Healthcare is the #1 phishing target. Test your team regularly.
Policy update briefings — When policies change, train immediately, don't wait for the annual cycle
New hire onboarding — HIPAA training before any PHI access, no exceptions

4. Documentation That Survives an Audit

OCR auditors want to see:

Who completed training (names, roles)
When they completed it (dates and timestamps)
What was covered (specific topics, not just "HIPAA training")
Acknowledgment that they understood the material (signed forms or digital confirmations)
Assessment results — Quiz scores proving comprehension

Measuring Training Effectiveness

The metric that matters isn't completion rate — it's incident reduction. Track:

Phishing click rates before and after training
Policy violation reports per quarter
Time to report potential incidents
Access review findings (inappropriate access attempts)
Audit findings related to workforce behavior

If your training program doesn't move these numbers, it's compliance theater, not a security control.

Building vs. Buying

For organizations evaluating whether to build custom training or use existing platforms:

Build custom if:

You have organization-specific workflows that generic training can't address
Your PHI handling procedures are complex or non-standard
You have dedicated compliance and L&D staff

Use existing platforms if:

You need audit-ready documentation quickly
You want pre-built role-based modules
You need automated tracking and recertification reminders

Either way, the training content needs to be specific to healthcare, not generic security awareness repackaged with a HIPAA label.

The Compliance Connection

Training doesn't exist in isolation — it's one component of your broader HIPAA compliance program. The Security Risk Analysis identifies what risks exist; training addresses the human element of mitigating those risks.

For a comprehensive view of how training fits into the full compliance picture, including risk assessments, policies, and technical safeguards: HIPAA Compliance Solutions

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

What Is a HIPAA Security Risk Analysis? A Developer's Breakdown of the Most Important Compliance Requirement

Joe Gellatly — Thu, 02 Apr 2026 22:59:13 +0000

If you work in healthcare IT — whether you're building EHR integrations, managing cloud infrastructure for a clinic, or developing patient-facing apps — there's one HIPAA requirement that matters more than any other: the Security Risk Analysis (SRA).

It's the #1 finding in OCR (Office for Civil Rights) audits. It's the document regulators ask for first. And it's the requirement most healthcare organizations either skip entirely or do so poorly it wouldn't survive scrutiny.

Here's what it actually is, why it matters, and how technical teams can approach it systematically.

What a Security Risk Analysis Actually Requires

The HIPAA Security Rule (45 CFR § 164.308(a)(1)) requires covered entities and business associates to:

"Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information."

In practice, this means documenting:

Where ePHI lives — every system, database, device, and transmission path that touches electronic protected health information
What threats exist — ransomware, phishing, insider threats, physical theft, natural disasters, vendor compromise
What vulnerabilities are present — unpatched systems, weak access controls, lack of encryption, missing audit logs
What the likelihood and impact of each risk is — a structured scoring methodology
What controls are currently in place — and whether they're adequate
What the remediation plan is — prioritized actions to reduce risk to acceptable levels

This isn't a one-time exercise. HIPAA requires it to be conducted annually and whenever significant changes occur in your environment (new EHR system, cloud migration, office relocation, etc.).

Why Developers Should Care

If you're building software that handles PHI, the SRA directly affects your architecture decisions:

Encryption requirements — The SRA identifies whether data-at-rest and data-in-transit encryption is adequate. If it's not, your development roadmap just got a new priority.
Access control design — Role-based access control (RBAC) isn't optional. The SRA evaluates whether your application enforces minimum necessary access.
Audit logging — HIPAA requires tracking who accessed what PHI and when. Your application needs comprehensive audit trails that the SRA can reference.
Backup and recovery — The SRA assesses whether your backup procedures are sufficient. If your app stores PHI, recovery time objectives (RTOs) matter for compliance, not just uptime SLAs.

The Common Mistakes

Having reviewed hundreds of SRAs across healthcare organizations, here are the patterns that get organizations in trouble:

1. Using a checklist instead of a risk analysis

A checklist asks "Do you have encryption? Yes/No." A proper risk analysis asks "What encryption standards are implemented, on which systems, what's the residual risk for systems where encryption isn't feasible, and what compensating controls exist?" OCR has explicitly stated that checklists alone do not satisfy the requirement.

2. Not inventorying all ePHI locations

Most organizations miss secondary locations: email attachments, shared drives, mobile devices, voicemail systems, fax-to-email services, legacy applications, and vendor-hosted systems. If ePHI touches it, it needs to be in your risk analysis.

3. Treating it as an IT-only exercise

The SRA requires input from clinical staff, administrative personnel, and management — not just the IT department. A developer can identify technical vulnerabilities, but front desk staff know which workflows involve PHI exposure that IT never sees.

4. No remediation tracking

Identifying risks without documenting a remediation plan is almost as bad as not doing the analysis at all. OCR wants to see that you identified risks AND took action to address them, with documented timelines and responsible parties.

How to Structure the Analysis

For development teams that need to contribute to or build SRA tooling, here's the framework:

\`
Asset Inventory
├── Systems (EHR, PM, imaging, lab)
├── Databases (patient records, billing, scheduling)
├── Devices (workstations, mobile, medical devices)
├── Network infrastructure (routers, firewalls, VPN)
└── Third-party services (cloud, SaaS, clearinghouses)

For Each Asset:
├── ePHI types stored/transmitted
├── Threat scenarios (ranked by likelihood)
├── Existing controls
├── Vulnerability assessment
├── Risk score (likelihood × impact)
└── Remediation actions (with owner + deadline)
`\

Automating the Process

The traditional approach — consultants with spreadsheets — doesn't scale and produces documentation that's outdated before the ink dries. Modern approaches use software to:

Maintain a living asset inventory that updates as your infrastructure changes
Map threats to frameworks like NIST 800-30 automatically
Calculate risk scores using consistent methodology across assessments
Track remediation with assignees, deadlines, and completion status
Generate audit-ready documentation that satisfies OCR requirements

If you're evaluating tools for this, look for ones that specifically understand the healthcare compliance context — not generic GRC platforms that require extensive customization. For a detailed breakdown of what to look for in HIPAA risk analysis tools, check out this guide: HIPAA Risk Analysis Tools

The Bottom Line

The Security Risk Analysis isn't just paperwork — it's the diagnostic that tells you where your security program is strong and where it's vulnerable. For developers and IT teams in healthcare, understanding what the SRA requires helps you build systems that are compliant by design rather than retrofitting compliance after the fact.

If you're new to HIPAA or want a deeper understanding of what the Security Risk Analysis entails, this resource provides a thorough overview: What Is a HIPAA Security Risk Analysis?

Joe Gellatly is CEO of Medcurity, a HIPAA compliance platform that helps healthcare organizations automate their Security Risk Analysis and manage compliance programs.

The 2026 HIPAA Compliance Solutions Stack: Tools Every Healthcare Developer Should Know

Joe Gellatly — Thu, 02 Apr 2026 18:39:52 +0000

Building healthcare applications in 2026 means one thing above all else: compliance is not optional. HIPAA (Health Insurance Portability and Accountability Act) regulations govern how we handle protected health information (PHI), and the penalties for non-compliance are steep—up to $1.5 million per violation category annually.

But here's the good news: modern tools have made HIPAA compliance solutions more accessible than ever. As developers, we're no longer asking "how do we comply?" but rather "which tools should we integrate into our stack?"

In this article, I'll walk you through the essential components of a complete HIPAA compliance solutions stack, including real-world tools, code examples, and configurations you can start using today.

Understanding the Core Pillars

A robust HIPAA compliance solutions framework rests on six main pillars:

Data Encryption (in transit and at rest)
Access Control & Authentication
Audit Logging & Monitoring
Risk Assessment & Management
Workforce Training & Documentation
Business Associate Agreements (BAAs)

Let's dive into each.

1. Data Encryption: The Foundation

Encryption is non-negotiable. HIPAA requires encryption for all PHI, whether it's sitting on a server or moving across networks.

In-Transit Encryption

TLS 1.2 or higher is the baseline. Here's how to enforce it on an AWS API Gateway:

# AWS CloudFormation - API Gateway with TLS 1.2 enforcement
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  HealthcareAPI:
    Type: AWS::ApiGateway::RestApi
    Properties:
      Name: HealthcareAPI
      EndpointConfiguration:
        Types:
          - REGIONAL

  APIDeployment:
    Type: AWS::ApiGateway::Deployment
    Properties:
      RestApiId: !Ref HealthcareAPI
      StageName: prod
      StageDescription:
        TlsVersion: TLS_1_2
        SecurityPolicyName: ELBSecurityPolicy-TLS-1-2-2017-01

At-Rest Encryption

For database encryption, use AWS KMS (Key Management Service) or equivalent:

# Python + Boto3 - Encrypt PHI before storing
import boto3
from cryptography.fernet import Fernet

kms_client = boto3.client('kms')

def encrypt_phi(plaintext_phi, key_id):
    """Encrypt PHI using AWS KMS"""
    response = kms_client.encrypt(
        KeyId=key_id,
        Plaintext=plaintext_phi.encode()
    )
    return response['CiphertextBlob']

def decrypt_phi(encrypted_phi, key_id):
    """Decrypt PHI with audit trail"""
    response = kms_client.decrypt(CiphertextBlob=encrypted_phi)
    # Log this decryption attempt (see audit section below)
    return response['Plaintext'].decode()

Consider implementing field-level encryption for highly sensitive data like SSNs and credit card numbers. This adds an extra layer beyond database encryption.

2. Access Control & Authentication

HIPAA's "minimum necessary" principle means users should only access PHI required for their role.

Role-Based Access Control (RBAC)

Implement role-based permissions using solutions like Okta, Auth0, or AWS IAM:

# Flask + Role-Based Access Control
from functools import wraps
from flask import abort, request

ROLE_PERMISSIONS = {
    'doctor': ['view_patient_records', 'edit_patient_records', 'prescribe'],
    'nurse': ['view_patient_records', 'edit_vital_signs'],
    'admin': ['view_patient_records', 'manage_users', 'view_audit_logs'],
    'patient': ['view_own_records']
}

def require_permission(permission):
    def decorator(f):
        @wraps(f)
        def decorated_function(*args, **kwargs):
            user_role = request.headers.get('X-User-Role')
            if permission not in ROLE_PERMISSIONS.get(user_role, []):
                abort(403)  # Forbidden
            return f(*args, **kwargs)
        return decorated_function
    return decorator

@app.route('/api/patient/<patient_id>/records')
@require_permission('view_patient_records')
def get_patient_records(patient_id):
    # Fetch and return patient records
    pass

Multi-Factor Authentication (MFA)

Enforce MFA for all users accessing PHI. Services like Okta and Auth0 handle this seamlessly.

3. Audit Logging & Monitoring

HIPAA requires comprehensive audit trails for all PHI access. Every read, write, and delete must be logged with:

Who accessed the data
What data was accessed
When it was accessed
Why (the user's role/purpose)
Where (IP address, location)

Audit Log Schema

-- PostgreSQL - Audit Log Table
CREATE TABLE audit_logs (
    id BIGSERIAL PRIMARY KEY,
    timestamp TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    user_id UUID NOT NULL,
    user_role VARCHAR(50) NOT NULL,
    action VARCHAR(50) NOT NULL, -- 'CREATE', 'READ', 'UPDATE', 'DELETE'
    entity_type VARCHAR(100) NOT NULL, -- 'patient_record', 'prescription', etc.
    entity_id UUID NOT NULL,
    phi_fields_accessed TEXT[], -- Array of field names
    ip_address INET NOT NULL,
    user_agent TEXT,
    result VARCHAR(20), -- 'SUCCESS', 'FAILURE'
    change_details JSONB, -- For UPDATE/DELETE operations

    INDEX idx_timestamp (timestamp),
    INDEX idx_user_id (user_id),
    INDEX idx_entity_id (entity_id)
);

Real-Time Monitoring

# Python - Log PHI Access
from datetime import datetime
import logging
from pythonjsonlogger import jsonlogger

# Configure JSON logging for centralized collection (e.g., ELK Stack)
logger = logging.getLogger()
logHandler = logging.StreamHandler()
formatter = jsonlogger.JsonFormatter()
logHandler.setFormatter(formatter)
logger.addHandler(logHandler)

def log_phi_access(user_id, user_role, action, entity_type, entity_id,
                   phi_fields, ip_address, result):
    """Log all PHI access attempts"""
    logger.info({
        'timestamp': datetime.utcnow().isoformat(),
        'user_id': user_id,
        'user_role': user_role,
        'action': action,
        'entity_type': entity_type,
        'entity_id': entity_id,
        'phi_fields_accessed': phi_fields,
        'ip_address': ip_address,
        'result': result,
        'severity': 'HIGH' if result == 'FAILURE' else 'INFO'
    })

Use centralized logging services like:

AWS CloudWatch for AWS deployments
DataDog for cross-cloud environments
Splunk for enterprise-grade monitoring
ELK Stack for self-hosted solutions

4. Risk Assessment & Management

Conduct risk assessments regularly. HIPAA's Security Rule requires identifying and mitigating vulnerabilities.

Tools for Risk Assessment

Qualys - Vulnerability scanning and risk management
Rapid7 Nexpose - Continuous risk assessment
Tenable Nessus - Network vulnerability scanning
Snyk - Developer-focused dependency vulnerability scanning

Documentation Template

# Risk Assessment Report - Q2 2026

## Executive Summary
- Total systems assessed: 15
- High-risk vulnerabilities: 2
- Medium-risk vulnerabilities: 8

## Identified Risks
1. **Outdated TLS version on legacy API** (High)
   - Impact: Data in transit not properly encrypted
   - Remediation: Upgrade to TLS 1.2+ (Target: 30 days)

2. **Unencrypted database backups** (High)
   - Impact: PHI exposed if backups are compromised
   - Remediation: Enable encryption for all backups (Target: 14 days)

## Mitigation Plan
[Detailed action items with owners and deadlines]

5. Workforce Training & Documentation

HIPAA compliance requires documented training. Every employee handling PHI must receive annual training and sign acknowledgment forms.

Training Checklist

[ ] HIPAA Privacy Rule overview
[ ] Security Rule technical and administrative safeguards
[ ] Breach notification procedures
[ ] Password management best practices
[ ] Phishing and social engineering awareness
[ ] Incident reporting procedures
[ ] Role-specific PHI handling (for their position)

Use platforms like Coursera, LinkedIn Learning, or Compliance.com to deliver and track training completion.

6. Business Associate Agreements (BAAs)

Every vendor, cloud provider, and third party that touches PHI needs a signed BAA. This includes:

Cloud providers: AWS, GCP, Azure (with HIPAA-compliant regions/services)
Email services: ProtonMail, Microsoft 365 with BAA
Analytics platforms: Segment, Mixpanel (if they collect PHI)
Incident response vendors: CrowdStrike, incident response firms

Checklist for vendor evaluation:

## Vendor BAA Checklist

- [ ] Vendor has executed BAA on file
- [ ] Vendor uses encryption (in transit and at rest)
- [ ] Vendor provides audit logs
- [ ] Vendor has incident response procedures
- [ ] Vendor allows security assessments
- [ ] Vendor conducts regular penetration testing
- [ ] Vendor has data breach insurance
- [ ] Vendor's subcontractors have BAAs

Recommended Tools Stack for 2026

Here's a complete stack that pairs well:

Layer	Tools	Notes
Cloud Infrastructure	AWS (with HIPAA eligible services), GCP Healthcare API	Choose HIPAA-qualified regions
Encryption	AWS KMS, HashiCorp Vault	Key management is critical
Access Control	Okta, Auth0	Multi-factor authentication essential
Audit & Monitoring	DataDog, Splunk, ELK	Centralized logging is non-negotiable
Vulnerability Management	Snyk, Qualys	Continuous assessment
BAA Management	OneTrust, TrustArc	Vendor management and BAA tracking
Documentation	Notion, Confluence	Keep compliance docs living and updated

Implementing a HIPAA Compliance Solutions Checklist for 2026

Ready to build a HIPAA-compliant system? Use this HIPAA compliance checklist for 2026 as your roadmap. For a deeper dive into available HIPAA compliance solutions, I recommend reviewing options tailored to your specific architecture.

Compliance is a Process, Not a Project

Here's what I've learned building healthcare applications: compliance isn't something you "check off" and move on. It's an ongoing process that evolves with your system.

Start with the essentials (encryption, access control, audit logging), document everything, and build a culture where security and compliance are everyone's responsibility—not just the compliance team's.

Your patients' data depends on it.

Key Takeaways

✅ Encrypt PHI in transit (TLS 1.2+) and at rest (KMS or equivalent)
✅ Implement role-based access control with MFA
✅ Log all PHI access with comprehensive audit trails
✅ Conduct regular risk assessments and vulnerability scans
✅ Train all workforce members annually
✅ Obtain and maintain BAAs with all vendors
✅ Review and update your compliance stack annually

About Medcurity

Medcurity helps healthcare organizations and developers build HIPAA-compliant systems with confidence. Our platform provides compliance guidance, risk assessment tools, and best practices specifically designed for healthcare tech teams. Whether you're building from scratch or auditing an existing system, Medcurity's resources help you navigate the complexities of healthcare compliance in 2026 and beyond.

Building HIPAA-Compliant Software for Dental Practices: What Developers Need to Know

Joe Gellatly — Thu, 02 Apr 2026 18:35:49 +0000

When you're building software for healthcare providers, compliance isn't optional—it's fundamental. While HIPAA (Health Insurance Portability and Accountability Act) compliance often feels like a maze of regulations, understanding the specific requirements for dental practices is crucial for developers. In this article, we'll explore the unique challenges of building HIPAA-compliant software for dental offices and provide practical guidance you can implement today.

Why Dental Practices Are Unique HIPAA Challenges

Dental practices might seem less complex than hospitals or large healthcare systems, but they face distinct compliance challenges. Most dental offices operate with limited IT resources, smaller budgets, and often outdated legacy systems. This means your software needs to be not only compliant but also user-friendly enough for office managers and dental hygienists who aren't tech-savvy.

Unlike large healthcare institutions with dedicated compliance teams, dental practices rely on their software vendors to guide them through HIPAA compliance for dental practices. This shifts significant responsibility to developers—you're not just building software; you're a critical part of their compliance strategy.

PHI in Dental Systems: Understanding What You're Protecting

Protected Health Information (PHI) in dental contexts includes more than patient names and SSNs. In your data models, you need to account for:

Patient demographics: Names, addresses, phone numbers, email addresses
Insurance information: Policy numbers, group numbers, subscriber details
Clinical records: Diagnoses, treatment notes, radiographs, and intraoral images
Payment histories: Credit card information, payment plans, billing records
Imaging data: X-rays, 3D cone-beam CT scans, digital photos

Here's the critical part: if your application touches any of this data, HIPAA applies. There's no minimum patient threshold or revenue requirement—even a small solo practice running a custom appointment system needs to comply.

Code Example: Handling Sensitive Data in Appointment Systems

// WRONG: Storing unencrypted PHI
const appointmentData = {
  patientName: "John Doe",
  ssn: "123-45-6789",
  diagnosis: "Root canal treatment",
  timestamp: new Date()
};
localStorage.setItem('appointment', JSON.stringify(appointmentData));

// CORRECT: Encrypt PHI and avoid client-side storage
const crypto = require('crypto');

const encryptPatientData = (data, encryptionKey) => {
  const cipher = crypto.createCipher('aes-256-cbc', encryptionKey);
  let encrypted = cipher.update(JSON.stringify(data), 'utf8', 'hex');
  encrypted += cipher.final('hex');
  return encrypted;
};

// Store only reference IDs on client side
const appointmentRef = {
  appointmentId: "APT-2026-001",
  timestamp: new Date()
};
sessionStorage.setItem('currentAppointment', JSON.stringify(appointmentRef));

Access Controls: The Foundation of HIPAA Compliance

One of the most common compliance gaps in dental software is inadequate access controls. Your system must enforce role-based access control (RBAC) with different permission levels for dentists, hygienists, office managers, and billing staff.

HIPAA's Minimum Necessary Standard requires that users only access the PHI needed for their job function. A dental hygienist scheduling appointments shouldn't have access to patient payment histories. A billing coordinator shouldn't see clinical treatment notes.

Implementing Role-Based Access Control

# Django example for RBAC in a dental practice management system

class PatientRecord(models.Model):
    patient_id = models.UUIDField(primary_key=True)
    name = models.CharField(max_length=255, encrypted=True)
    ssn = models.CharField(max_length=11, encrypted=True)
    created_at = models.DateTimeField(auto_now_add=True)

class AccessLog(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    patient_record = models.ForeignKey(PatientRecord, on_delete=models.CASCADE)
    access_type = models.CharField(max_length=10, choices=[('READ', 'Read'), ('WRITE', 'Write')])
    timestamp = models.DateTimeField(auto_now_add=True)

class DentalUserPermission(models.Model):
    ROLES = [
        ('DENTIST', 'Dentist'),
        ('HYGIENIST', 'Dental Hygienist'),
        ('ADMIN', 'Office Manager'),
        ('BILLING', 'Billing Staff')
    ]

    user = models.OneToOneField(User, on_delete=models.CASCADE)
    role = models.CharField(max_length=20, choices=ROLES)

    def can_access_clinical_notes(self):
        return self.role in ['DENTIST', 'HYGIENIST']

    def can_access_billing(self):
        return self.role in ['BILLING', 'ADMIN', 'DENTIST']

Encryption at Rest and in Transit

HIPAA requires encryption of all PHI, both when it's stored and when it travels across networks. This is non-negotiable.

In Transit: Always use HTTPS/TLS 1.2 or higher. If your dental practice management system integrates with insurance providers or sends patient data anywhere, encrypt that data end-to-end.

At Rest: Encrypt database fields containing PHI. Don't rely on database-level encryption alone—implement field-level encryption in your application code. Use established libraries like:

Python: cryptography library or django-encrypted-model-fields
Node.js: crypto module or NaCl.js
Java: javax.crypto or Spring Security Crypto
.NET: System.Security.Cryptography

Audit Logging: Your Compliance Evidence

HIPAA requires comprehensive audit trails. Every access to PHI must be logged and retained for at least six years. For developers, this means:

Log who accessed what: User ID, timestamp, patient record ID, action (read/write/delete)
Capture context: IP address, application version, access method
Immutable storage: Store logs in append-only fashion where they can't be modified retroactively
Retention policy: Implement automated archival after six years

// Logging PHI access in a dental practice system
const auditLog = async (userId, patientId, action, details) => {
  const logEntry = {
    timestamp: new Date().toISOString(),
    userId: userId,
    patientId: patientId,
    action: action, // 'VIEW', 'EDIT', 'DELETE', 'EXPORT'
    ipAddress: getClientIP(),
    userAgent: getUserAgent(),
    details: details,
    hash: generateHash(userId + patientId + action + timestamp)
  };

  // Store in immutable append-only log
  await AuditLog.create(logEntry);
};

Dental-Specific Compliance Challenges

Imaging Data Security

Dental practices heavily rely on radiographs and images. These are PHI and require special handling:

DICOM standard compliance: If you're handling DICOM imaging files, understand the standard's security requirements
Image encryption: Encrypt images before transmission or storage
Retention policies: Implement automated deletion of images after clinical hold periods
Access restrictions: Only clinical staff should access imaging; never expose raw image URLs

Patient Portal Design

Many modern dental practices now offer patient portals. This creates unique risks:

Implement multi-factor authentication
Never cache PHI in browsers
Use secure session management with timeouts
Log all patient portal activity separately
Ensure password reset flows don't leak information

Integration with Third-Party Services

Dental practices integrate with insurance providers, payment processors, and third-party imaging services. Every integration is an opportunity for HIPAA violations:

Use Business Associate Agreements (BAAs) with all third parties
Encrypt data in transit to third parties
Implement API rate limiting and authentication
Monitor for suspicious data requests
Maintain records of all data shared externally

Breach Notification and Incident Response

Despite best efforts, breaches happen. Your application needs built-in incident response capabilities:

Breach detection: Automated alerting for suspicious access patterns or unusual data queries
Containment: Ability to revoke access, reset credentials, and isolate affected data
Notification system: Tools to help practices notify affected patients within 60 days
Documentation: Automated generation of breach assessment reports

HIPAA for Dental Practices in Development Workflow

Compliance shouldn't be an afterthought. Integrate it into your development process:

Design reviews: Have a compliance-focused review before writing code
Security testing: Include HIPAA-specific security tests in your CI/CD pipeline
Code reviews: Have team members specifically check for unencrypted PHI storage
Documentation: Maintain detailed documentation of how your system handles PHI
Training: Ensure your team understands HIPAA training for dental offices and the technical implications

Choosing HIPAA Compliance Solutions

Building HIPAA-compliant systems is complex. Consider using HIPAA compliance solutions that provide frameworks, libraries, and guidance specifically designed for healthcare applications. These solutions can accelerate development while reducing compliance risk.

Conclusion

Building HIPAA-compliant software for dental practices requires attention to detail, robust security practices, and a deep understanding of how dental workflows interact with sensitive patient data. By implementing proper access controls, encryption, audit logging, and secure development practices, you can create software that dental practices can trust with their patients' information.

The developers who master HIPAA compliance in healthcare will be invaluable to practices navigating an increasingly complex regulatory landscape. Start with the fundamentals covered here, stay current with HIPAA guidance, and always prioritize patient data security in your design decisions.

About

This article was created by Medcurity, a healthcare compliance and security firm specializing in helping dental practices and healthcare providers build and maintain HIPAA-compliant systems. Medcurity provides comprehensive guidance, training, and solutions to ensure healthcare organizations meet their regulatory obligations while delivering excellent patient care.

HIPAA Risk Analysis Tools: A Developer's Guide to Automating Security Assessments

Joe Gellatly — Thu, 02 Apr 2026 18:32:18 +0000

If you're building healthcare applications, you already know that HIPAA compliance isn't optional—it's table stakes. But here's the thing: manually conducting risk assessments is a tedious, error-prone nightmare that drains your engineering bandwidth. That's where HIPAA risk analysis tools come in.

In this guide, we'll explore how developers can leverage automated security assessment tools to streamline compliance workflows, reduce human error, and actually understand what's happening under the hood of your risk analysis process.

Why Manual Risk Analysis Fails (And Why Developers Need Better Tools)

Let's be honest: traditional HIPAA risk analysis is tedious. You're probably conducting these assessments by:

Running through lengthy questionnaires manually
Tracking vulnerabilities in spreadsheets (yikes)
Gathering responses from different team members via email chains
Manually calculating risk scores with inconsistent methodologies
Creating documentation that goes out of date by next month

The result? Incomplete assessments, inconsistent scoring, and compliance drift between evaluations.

For developers, this means time spent on busywork instead of building secure systems. Enter HIPAA security risk analysis automation.

What Modern HIPAA Risk Analysis Tools Actually Do

Contemporary risk analysis platforms go beyond questionnaire forms. They:

Automate data collection from your infrastructure (cloud configs, database logs, network diagrams)
Generate risk scores based on standardized methodologies (NIST, HIPAA Security Rule)
Track remediation workflows with assignment and deadline tracking
Maintain audit trails automatically for regulatory reviews
Integrate with your DevOps stack (GitHub, AWS, Azure, etc.)

Think of them as your compliance CI/CD pipeline. Just like you automate testing for code quality, you can automate testing for security posture.

The Architecture: How Risk Analysis Tools Work

Most enterprise tools follow this pattern:

{
  "assessment": {
    "id": "assessment-2026-q1",
    "scope": "production-healthcare-platform",
    "controlsFramework": "HIPAA_SECURITY_RULE",
    "findings": [
      {
        "controlId": "164.308(a)(1)(i)",
        "threat": "Unauthorized access via unpatched database",
        "likelihood": "high",
        "impact": "critical",
        "riskScore": 8.9,
        "remediation": {
          "action": "Upgrade PostgreSQL and apply patches",
          "owner": "database-team",
          "dueDate": "2026-05-01"
        }
      }
    ]
  }
}

Your assessment engine processes this data to identify threats, evaluate vulnerabilities, calculate risk (Likelihood x Impact = Risk Score), and recommend controls.

Practical Integration: Adding Risk Analysis to Your CI/CD

import requests
import os

def calculate_risk_before_deploy(infrastructure_config):
    response = requests.post(
        "https://api.yourrisktool.io/v1/assessments/quick-eval",
        json={
            "assessment_type": "infrastructure_change",
            "changes": infrastructure_config,
            "baseline_risk": 3.2,
        },
        headers={"Authorization": f"Bearer {os.getenv('RISK_API_KEY')}"}
    )
    assessment = response.json()
    new_risk_score = assessment['projected_risk_score']

    if new_risk_score > 4.5:
        print(f"Deployment blocked. Risk: {new_risk_score}")
        return False

    print(f"Risk acceptable: {new_risk_score}")
    return True

This approach gives you several advantages:

Compliance becomes visible in your normal workflow
Risk assessments inform deployment decisions (not an afterthought)
Remediation tracks alongside code changes
Historical audit trail is automatically generated

Choosing the Right Tool

When evaluating HIPAA risk analysis tools, ask:

Does it integrate with our stack? (AWS, Azure, Kubernetes, GitHub)
Can we automate data collection? (Not just manual forms)
Does it map to our compliance framework? (NIST CSF, HIPAA Security Rule)
What's the learning curve?
Can we customize risk calculations?

The best tool isn't the fanciest—it's the one your team will actually use.

Moving From Compliance Theater to Real Security

Automated risk analysis tools force you to answer hard questions systematically. Instead of "Is our system secure?" you're answering "What are the specific HIPAA-relevant threats, and how likely are they?"

That clarity means you allocate security budget where it matters, explain decisions in concrete terms, detect compliance drift automatically, and continuously improve your security posture.

Final Thoughts

HIPAA compliance will never be "fun," but it doesn't have to be painful. By integrating risk analysis tools into your development workflow, you make compliance part of your normal engineering process.

The healthcare tech space is growing, and the winners will be the companies that build security and compliance into their systems from day one. Automated risk analysis tools help you do exactly that.

Medcurity is an AI-powered HIPAA compliance platform built for healthcare teams. We automate security assessments, track compliance workflows, and maintain audit-ready documentation. Learn more at medcurity.com.