Your Systems
§164.312 is mostly a vendor-verification chapter. You’re not building audit logs or encryption — your EHR vendor is. Your job is to confirm the capability exists, that it’s turned on where applicable, and that you’ve written down what you learned.
For paper-and-email practices, the §164.312 questions still apply — your email provider, cloud folder, and backup approach handle the same areas your EHR would. The questions will help you confirm what each service provides, document what you find, and note where you need a written procedure (such as emergency access).
Why this chapter exists, in plain English
§164.312 — the Technical Safeguards. The earlier chapters were mostly about things you do: who you have BAAs with, how you handle devices, how you respond to incidents, how you keep the paperwork. This chapter is about things your systems do — specifically, your EHR and any other software that touches patient information.
For a solo or small practice, this is mostly a vendor-verification chapter: you ask your EHR vendor a short list of questions, and you document what they tell you.
Seven topics, each mapping to a §164.312 sub-spec. Four involve addressable implementation specs — if one isn’t reasonable and appropriate for your practice, you can document an equivalent alternative instead. If you have more than one system handling ePHI (for example a separate billing or scheduling tool), run the checklist once per system — your vendor answers may differ.
The seven safeguards
7 questionsUnique accounts and how you log in:
one identifiable account per person, not a shared login
Two related questions: (1) does every person who touches ePHI have their own account on your EHR (no shared logins), and (2) does the system require strong authentication — at minimum a strong password, ideally MFA where the vendor supports it?
For a solo practice, there is just one account; a small office has a handful — but the vendor still needs to support MFA, and everyone needs to be using it.
Emergency access procedure:
How ePHI still reaches the right people when something goes wrong
“Something goes wrong” for a solo or small practice typically means: device lost or stolen, vendor outage, account locked, or you are incapacitated and a covering clinician needs patient records. The rule wants a written procedure.
Two halves: (1) the vendor side — your EHR’s break-glass admin access, their support line, their documented recovery path; (2) the practice side — who covers you, how they reach records, how they prove identity to your vendor.
Auto-logoff:
what happens when you walk away from a logged-in screen
Two layers: the EHR session itself (most healthcare-focused vendors default to around 15 minutes), and the device lock underneath it (covered in Chapter 2). Both count — if the EHR stays open but the device locks after five minutes, a walk-away attacker sees the lock screen, not the chart.
Check your EHR’s session-timeout setting in admin settings (often called “idle timeout” or “session duration”).
Encryption at rest:
making the disk unreadable to anyone who steals the device
This is application-level encryption at the vendor — distinct from the device-level full-disk encryption ( FileVault / BitLocker) covered in Chapter 2. Your EHR vendor should be encrypting their database and backups with AES-256 or equivalent; their BAA or SOC 2 report is where this is documented.
This spec is technically addressable, but OCR treats encryption at rest as de facto required — breach settlements consistently flag unencrypted storage.
Audit logs:
the system records that show who did what to ePHI
Your EHR should log every access to a patient record — who logged in, what they looked at, when. You don’t build this; your vendor does. Your job is to confirm the logs exist, know how to pull them, and review them periodically.
OCR investigations consistently flag audit logs that exist but are never reviewed. The cadence for review belongs in Chapter 7 under your review routine.
Data integrity:
catching when ePHI gets altered or destroyed in error
Two halves. The standard requires that ePHI not be improperly changed or destroyed. The addressable implementation spec asks for a mechanism to detect unauthorized changes (checksums, version history, audit-log review).
For a solo EHR user, this is mostly vendor-provided at the database level. Your practice-level contribution is not letting the EHR be your only copy— which loops into Chapter 6 and the backup plan.
Transmission security:
how ePHI stays protected on its way out of the practice
Two addressable sub-specs — integrity controls and encryption — both effectively delivered by modern TLS. Practical questions: (1) does your EHR use HTTPS everywhere, (2) is patient-related email going through a BAA-covered channel (Chapter 1), (3) if you use any vendor portals, are those also HTTPS?
Endpoint Detection & Response (optional)
Optional, and not required to finish this chapter. If your IT provider or MSP has deployed an EDR (Endpoint Detection & Response) tool, capturing it here pre-fills the EDR row of your Carrier-Mapped Insurance Summary — several carriers (CRC Group, Travelers) require EDR for higher policy limits.
Is an EDR tool deployed across your devices?
Operational hardening (optional)
Optional, and not required to finish this chapter. These two answers pre-fill the patching and network-segmentation rows of your Carrier-Mapped Insurance Summary — both are 2026 HIPAA Security Rule expectations.
Carriers ask thisDo you apply security patches and updates within 30 days of release?
Is your work network separated from guest/patient WiFi?
Where you stand
Not quite there yet
Answer all seven §164.312 sub-specs to see your chapter resolution.