The HIPAA Risk Analysis That Holds Up Under OCR Review

Most EMS agencies have a HIPAA risk analysis on file. Most of them would not survive an OCR review.

The ones that fail usually look the same. A checklist of yes-no questions. A generic template pulled from a state association website. A document that was written once three years ago and has not been touched since. If you are the EMS director or the IT lead who signed that document, you are carrying more risk than you think.

This article walks through what 45 CFR 164.308(a)(1)(ii)(A) actually requires, where most EMS risk assessments fall short, and how to build an analysis that maps threats and vulnerabilities to the systems your agency actually operates.

What the Security Rule Requires for HIPAA Risk Analysis in EMS

The regulation is short. 45 CFR 164.308(a)(1)(ii)(A) says the covered entity must:

> Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity.

Three things in that sentence matter more than most people realize.

The assessment must be accurate and thorough. That means it has to reflect your actual environment. Not a wish-list version of your network or a generic EMS profile from a vendor's brochure. The specific tablets and servers and workstations that touch ePHI in your agency.

It also has to cover risks and vulnerabilities. A compliance checklist that confirms you have a firewall is not a vulnerability analysis. The real question is what happens when that firewall is misconfigured or unpatched, or when a staff member plugs a personal device into the internal network because their work tablet battery died.

Third, the analysis has to address confidentiality and integrity and availability. EMS agencies tend to focus on confidentiality because that is what breach notifications are about. But availability is the bigger operational threat. A ransomware attack that locks your CAD system is an ePHI availability failure. OCR will ask about your risk analysis and whether it accounted for that threat.

Why Most EMS Risk Assessments Fail Under OCR Review

I have looked at risk assessments from about a dozen EMS agencies over the last few years. The patterns repeat.

The vendor promise problem. An agency buys an ePCR system and signs a BAA, then assumes the vendor handles all the compliance work. But shared responsibility does not work that way. The vendor secures the software while the agency secures the implementation. If your medics share passwords or leave tablets unlocked in the cab, the vendor's compliance does not protect you. OCR will look at your controls, not your BAA.

The clinical-technical gap. A clinical director writes the risk assessment and misses the technical vulnerabilities, while an IT person writes it and misses the clinical workflow. A defensible risk analysis needs both perspectives. Scene photos sent over SMS and patient notes dictated into a personal phone and crews emailing run data to finish charts at home all share the same problem: they never show up in a checklist.

I wrote about this last year in Vendor Risk Management for Small EMS Agencies Without a CISO. The principle applies here. A BAA is a legal contract, not a security control. It reassigns legal liability for certain failures, but your operational risk stays with you.

The one-and-done document. The risk analysis gets written for a grant application or a certification audit and never gets updated. OCR looks for a living document. Changes that trigger an update include a new tablet model added to the fleet, a switch to a different ePCR vendor, or a security incident that reveals a gap you did not account for.

How to Conduct a HIPAA Risk Analysis for ePCR Systems

A defensible risk analysis follows a logical chain. Each threat source connects to a vulnerability, and that vulnerability creates a risk to ePHI that gets scored and mitigated.

Here is the sequence OCR expects:

1. Identify the ePHI. Map every system that creates, receives, stores, or transmits ePHI. That means the ePCR application and the CAD system and the billing software. The email accounts where PDFs get attached. The backup drives and USB sticks. The personal phones used for shift communication.

2. Identify threat sources. Natural events, human error, malicious actors, system failures. Each one needs to be listed for each ePHI touchpoint.

3. Identify vulnerabilities. Every threat source needs a matching vulnerability. Ransomware needs an unpatched system. A lost tablet needs weak device encryption. An insider threat needs broad access permissions.

4. Determine impact and likelihood. Use a three-level matrix. Impact times probability equals risk level.

5. Document mitigations. This is the step most agencies skip. For each identified risk, list the control you have in place, the control you plan to add, the person responsible, and the deadline.

Here is a concrete example for an EMS agency:

Threat: Ransomware encrypts the CAD dispatch server.

Vulnerability: The server runs Windows 7 and is not in the patch cycle.

Impact: High. Loss of CAD availability means delayed dispatch and lost patient tracking.

Likelihood: Moderate, because ransomware targeting healthcare is active and growing.

Risk Level: High.

Mitigation: Replace the CAD server with a supported OS within 90 days. Assign to IT lead. Interim step: isolate the server behind a restricted network segment.

Threat: Tablet is stolen from an unlocked rig.

Vulnerability: Tablets use PIN-based access with no remote wipe capability.

Impact: High. Potential exposure of ePHI for every patient encounter on that device.

Likelihood: High. Multiple reported incidents of equipment theft from parked ambulances in the service area.

Risk Level: High.

Mitigation: Enable device encryption and deploy MDM with remote wipe within 30 days. Assign to IT lead.

The Difference Between a Compliance Checklist and a Real Risk Analysis

A compliance checklist asks yes or no. Do you have a firewall in place? Is antivirus running on every workstation? Has a password policy been adopted? Those are all reasonable questions, but they are not a risk analysis.

A real risk analysis asks what happens when those controls fail. The firewall is configured correctly today. What happens when a vendor technician plugs a laptop into the internal network without scanning it first? The password policy exists on paper. What happens when a medic writes the password on a sticky note attached to the monitor?

The checklist gives you a warm feeling and no actionable information. The risk analysis gives you a list of specific gaps you can close. OCR knows the difference. If your risk analysis is a checklist, they will treat it as no analysis at all.

Earlier this year I wrote about related gaps in The 60-Day Clock: HIPAA Breach When the Medic Loses the Phone. The same principle applies to the risk analysis itself.

Building the Defensible Template

A risk analysis that holds up under review has five sections.

Section 1: Asset Inventory. Every piece of hardware and software and network connection that touches ePHI. Include make and model and location for each item, plus the person responsible for it.

Section 2: Threat and Vulnerability Matrix. A table with columns for threat source and vulnerability and ePHI impact, plus likelihood and current controls. This is the core of the analysis.

Section 3: Risk Scoring. Use a consistent method. I recommend a three-level scale that maps to action: low means monitor, medium means plan to mitigate, high means mitigate immediately.

Section 4: Mitigation Plan. Each high and medium risk gets a specific action, a deadline, and an owner. This is the document that gets reviewed at quarterly leadership meetings.

Section 5: Review Schedule. Define when the analysis gets updated with annual minimums plus triggers for new systems, vendor changes, or security incidents that reveal new gaps.

Frequently Asked Questions

Does using the HHS Security Risk Assessment Tool make me compliant?

The SRA Tool is a questionnaire, not a risk analysis. It asks about controls you have in place but it does not walk through the threat-vulnerability-impact chain OCR expects to see. Use it as a starting point for identifying gaps, but do not submit it as your risk analysis.

How often do I need to update my HIPAA risk analysis?

The rule says the analysis must be conducted regularly. In practice that means annual updates at minimum. You should also update it whenever you make a significant change to your technology environment. A new ePCR vendor or a new mobile device fleet or a new billing system each triggers an update.

If my ePCR vendor says they are HIPAA compliant, why do I still need a risk analysis?

The vendor is responsible for the security of their platform. You are responsible for how your people use it. Weak passwords and shared logins and workflow workarounds that bypass security controls are your problem. OCR will hold you accountable for them, not the vendor.

What happens if OCR investigates and I do not have a current risk analysis?

OCR does not need to prove a breach occurred to cite you. The absence of a thorough risk analysis is itself a violation of the Security Rule. Fines for noncompliance start at $100 per violation and can reach $50,000 per violation for willful neglect. More importantly, a missing or weak risk analysis signals to OCR that your whole compliance program is paper-thin.

How do I handle field realities like tablets left in ambulances?

A defensible risk analysis accounts for real operations, not ideal ones. Document the threat of theft from an unlocked vehicle and the vulnerability of no remote wipe or device encryption. Then document the remediation. OCR will treat an acknowledged gap with a plan as better than a blank spot or a lie.

Closing

A risk analysis is not a document you file away for the next audit. It is the operational map that tells you where your ePHI lives and what could go wrong. Build it the way OCR expects and it becomes a planning tool instead of a liability. Leave it as a checklist and it becomes the first thing OCR pulls in an investigation.

Start with the asset inventory. Map the threats to the vulnerabilities. Write down what you are going to do about them. Then review it again next year.

-- Steven