A Familiar Conversation in Dutchess County
A few months ago I sat down with the clinical director of a substance use disorder treatment center in Poughkeepsie. They had rolled out telehealth sessions during the pandemic, kept them running because patients in Sullivan and Ulster counties preferred the convenience, and had recently signed with a new cloud-based EHR. When I asked about their HIPAA Security Rule compliance program, the director gestured at the EHR login screen and said, "Our vendor told us they're HIPAA compliant. We're covered."
They were not covered. Not even close. The vendor's BAA shifted nearly every security obligation back to the practice. Nobody on staff had performed a risk analysis since 2021. The telehealth platform ran on clinicians' personal laptops with no disk encryption and no automatic session timeout. Workforce training consisted of a single PDF emailed during onboarding two years earlier. If OCR had come knocking, this practice—a dedicated, well-intentioned group of clinicians serving some of the Hudson Valley's most vulnerable patients—would have had almost nothing to show for its compliance efforts.
This is not unusual. Across the Hudson Valley, from Kingston to Beacon to Middletown, small behavioral health practices and SUD treatment centers operate under the same dangerous assumption: that technology vendors absorb their HIPAA obligations. They do not. The Security Rule places compliance squarely on the covered entity. Your vendor is a business associate with its own obligations, but you remain the one OCR will audit, fine, and name in a public breach report.
How the Security Rule Actually Works
The HIPAA Security Rule (45 CFR Part 160 and Subparts A and C of Part 164) protects electronic protected health information, or ePHI. It organizes its requirements into three categories of safeguards: administrative, physical, and technical. Within each category, the Rule defines standards (broad objectives you must meet) and implementation specifications (the specific steps for meeting them).
Each implementation specification is classified as either required or addressable. The required specifications are straightforward: you must implement them exactly as described. The addressable specifications are where most small practices get into trouble, because the word "addressable" sounds a lot like "optional." It is not.
The 18 Addressable Specifications: A Practical Walk-Through
There are 18 addressable implementation specifications across the three safeguard categories. For a small behavioral health or telehealth practice in the Hudson Valley, here is what each one demands in plain terms.
Administrative Safeguards (8 Addressable Specifications)
1. Authorization and/or Supervision (§164.308(a)(3)(ii)(A)). Every workforce member who touches ePHI needs a defined reporting structure. In a five-clinician SUD practice, this might mean the practice manager formally authorizes each clinician's access level and reviews it quarterly. Document who approved what, and when.
2. Workforce Clearance Procedure (§164.308(a)(3)(ii)(B)). Before granting access to ePHI, you verify that the person should have it. For a telehealth practice, this means background checks on new hires and a documented process for confirming that a contractor, intern, or billing specialist actually needs the access they are requesting.
3. Termination Procedures (§164.308(a)(3)(ii)(C)). When a clinician leaves or an intern's rotation ends, their EHR credentials, VPN tokens, and building access must be revoked the same day. A practice in New Paltz learned this the hard way when a former employee accessed patient records three weeks after separation. Maintain a termination checklist and log every deactivation.
4. Security Reminders (§164.308(a)(5)(ii)(A)). Ongoing awareness training, not just an annual slide deck. Quarterly email reminders about phishing, password hygiene, and proper telehealth session handling count. The key is documentation: save the emails, record attendance at any huddles, and note the date and topic.
5. Protection from Malicious Software (§164.308(a)(5)(ii)(B)). Install and maintain endpoint protection on every device that accesses ePHI. If your clinicians conduct telehealth from home, their personal laptops need managed antivirus. "I told them to install something" does not satisfy this specification.
6. Log-in Monitoring (§164.308(a)(5)(ii)(C)). Review login attempts to systems containing ePHI. Most cloud EHRs generate these logs. Your obligation is to actually look at them. A monthly review of failed login reports, with a notation that you reviewed them and what you found, is a defensible practice.
7. Password Management (§164.308(a)(5)(ii)(D)). Establish and enforce password policies. For a small practice, this means a written policy requiring minimum length, complexity, and expiration—plus enforcement through your EHR and device management settings. Telling staff to "use strong passwords" without technical controls is insufficient.
8. Testing and Revision Procedures (§164.310(a)(2)(iv)). Your physical security measures need periodic testing. If you have an alarm system at your Newburgh office, test it. If you use badge access, audit the access list. Document each test and any corrective actions.
Physical Safeguards (3 Addressable Specifications)
9. Contingency Operations (§164.310(a)(2)(i)). If your office floods, burns, or loses power, how do your authorized staff access ePHI to continue patient care? For a telehealth-heavy practice, this might mean ensuring clinicians can securely access the cloud EHR from a secondary location. Document the plan and test it once a year.
10. Facility Security Plan (§164.310(a)(2)(ii)). A written description of how you protect the physical spaces where ePHI is accessed or stored. For a small practice on Main Street in Beacon, this includes locking the server closet, positioning monitors away from public view, and controlling who has keys. For telehealth-from-home, it extends to requiring clinicians to work from a private room with a closed door during sessions.
11. Access Control and Validation Procedures (§164.310(a)(2)(iii)). Control physical access to hardware and software based on each person's role. The front desk receptionist does not need access to the server room. The billing contractor does not need a key to the file storage area. Map roles to physical access rights and review annually.
Technical Safeguards (7 Addressable Specifications)
12. Unique User Identification (§164.312(a)(2)(i)). Every person gets their own login. No shared accounts, no "clinic iPad" that is permanently logged into the EHR. This is required, not merely addressable, for audit trail integrity. If your telehealth platform allows shared credentials, that is a problem you must fix today.
13. Emergency Access Procedure (§164.312(a)(2)(ii)). Define how you will access ePHI in an emergency. If your EHR goes down during a psychiatric crisis, what is the backup? A documented procedure—even if it is "call the vendor's emergency line and access records through the backup portal"—satisfies this, as long as it is written, communicated, and tested.
14. Automatic Logoff (§164.312(a)(2)(iii)). Sessions must terminate after a period of inactivity. For telehealth workstations, fifteen minutes is a reasonable threshold. Configure this at the operating system level and in the EHR application. A clinician who steps away from a telehealth session on an open laptop in a shared household is an ePHI exposure waiting to happen.
15. Encryption and Decryption (§164.312(a)(2)(iv)). Encrypt ePHI at rest. Full disk encryption on every laptop and workstation that accesses patient data. BitLocker on Windows, FileVault on Mac. If a clinician's laptop is stolen from their car in a Walmart parking lot in Wallkill—and this happens more often than you might expect—encryption is the difference between a reportable breach and a non-event.
16. Integrity Controls (§164.312(c)(2)). Implement mechanisms to verify that ePHI has not been improperly altered or destroyed. Audit logs in your EHR that track record modifications, checksums on backup files, or version control on clinical documents all serve this purpose.
17. Mechanism to Authenticate ePHI (§164.312(c)(2)). Confirm that ePHI received or retrieved is exactly what was sent or stored. For practices exchanging records via health information exchanges or direct messaging, this means using systems with built-in message integrity verification. For most small telehealth practices, your EHR's native data validation handles this, but you should confirm that with the vendor in writing.
18. Transmission Security — Encryption (§164.312(e)(2)(ii)). Encrypt ePHI in transit. TLS 1.2 or higher for all web-based EHR access. End-to-end encryption for telehealth video sessions. If your clinicians are emailing patient information, that email must be encrypted. Standard Gmail or Outlook without encryption add-ons does not meet this specification.
The Risk Analysis: What HHS Actually Expects
Every one of those 18 specifications—and the required specifications alongside them—must be evaluated through a formal risk analysis. This is not a checkbox exercise. HHS expects a thorough, documented assessment that identifies every place ePHI lives in your environment, catalogs the threats to each location, estimates the likelihood and impact of each threat, and assigns a risk level.
What most Hudson Valley practices actually do is far less rigorous: a brief questionnaire from their EHR vendor, completed once, filed in a drawer, and never revisited. OCR has made risk analysis failures the single most common finding in enforcement actions. Between 2016 and 2025, insufficient risk analysis appeared in over 80% of resolution agreements published on HHS's breach portal.
A defensible risk analysis for a small telehealth practice does not need to be 200 pages. It needs to be honest, comprehensive, and current. Identify your assets (EHR, telehealth platform, email, laptops, smartphones, paper records if any). Identify the threats (theft, ransomware, unauthorized access, improper disposal, vendor breach). Assess the likelihood and impact. Assign risk ratings. Document your mitigation decisions. Review and update it annually or whenever your environment changes—adding a new telehealth platform, opening a second office in Goshen, or switching EHR vendors all trigger a reassessment.
BAA Negotiation: What to Push Back On
Your Business Associate Agreement with your EHR vendor, telehealth platform, billing clearinghouse, and IT support company is not a formality. It is a contract that allocates security responsibilities. Read it carefully, because many vendor-drafted BAAs are written to minimize the vendor's obligations.
Push back on vague breach notification timelines. The HIPAA Breach Notification Rule requires notification without unreasonable delay, no later than 60 days after discovery. If your vendor's BAA says they will notify you "promptly" or "as soon as practicable" without a hard deadline, negotiate a specific number of days—30 is reasonable and gives you time to meet your own 60-day obligation to HHS.
Push back on broad limitations of liability. Some vendor BAAs cap liability at the fees you paid in the prior 12 months. For a small practice paying $400 per month for an EHR, that means a $4,800 cap on damages for a breach that could cost you hundreds of thousands in OCR penalties, patient notification, credit monitoring, and legal fees.
Push back on indemnification clauses that require you to indemnify the vendor for breaches caused by the vendor's own negligence.
Accept reasonable provisions around the vendor's right to use de-identified data for product improvement, as long as the de-identification method meets the Safe Harbor or Expert Determination standards under §164.514.
Red flags: A vendor who refuses to sign a BAA at all. A vendor whose BAA does not mention the Security Rule's specific safeguard requirements. A vendor who claims their "Terms of Service" substitute for a BAA. Walk away.
Your Evidence Pack: What to Have Ready for an OCR Audit
If OCR contacts your practice—following a patient complaint, a reported breach, or a random audit—you will need to produce documentation quickly. The following table outlines the core evidence artifacts, what each should contain, and a realistic update frequency for a small practice.
| Artifact | What It Contains | Update Frequency |
|---|---|---|
| Risk Analysis Report | Asset inventory, threat identification, vulnerability assessment, risk ratings, mitigation decisions with responsible parties and target dates. | Annually, or upon significant environment change |
| Risk Management Plan | Prioritized list of risks from the analysis, selected controls, implementation timeline, residual risk acceptance statements signed by practice leadership. | Annually, aligned with risk analysis |
| BAA Review Checklist | Inventory of all business associates, BAA execution dates, key terms summary (breach notification timeline, liability caps, termination provisions), next review date. | At each vendor onboarding or contract renewal |
| Workforce Training Log | Employee name, training date, topics covered, training method (live, recorded, written), attestation signature or electronic confirmation. | At hire, then annually with quarterly security reminders logged |
| Access Audit Report | List of all users with ePHI access, their roles, access levels, date of last access review, any modifications or terminations since last audit. | Quarterly |
| Contingency Plan | Data backup procedures, disaster recovery steps, emergency mode operations plan, testing results, roles and responsibilities during an outage or incident. | Annually, with tabletop test documented |
| Incident Response Log | Date of incident, description, individuals involved, investigation steps, root cause, corrective actions, breach determination analysis (reportable or not), notification records if applicable. | Per incident, reviewed quarterly |
| Policy and Procedure Manual | Written policies covering all Security Rule standards, version history, approval signatures, distribution records confirming workforce received copies. | Annually, or upon regulatory or operational change |
OCR Enforcement: Where the Scrutiny Falls
OCR has signaled its enforcement priorities clearly. For small healthcare providers—and behavioral health practices in particular, given the sensitivity of SUD and mental health records—three areas draw the most attention.
Risk analysis failures. As noted above, this is the number one finding. If you have nothing else in order, get your risk analysis done first. It is the foundation for every other compliance decision.
Right of access violations. Patients have a right to their records. OCR launched a formal Right of Access Initiative in 2019 and has settled dozens of cases since then, many involving small providers. If a patient in Kingston requests their telehealth session notes, you have 30 days to provide them. Delays, excessive fees, or outright refusals will draw an investigation.
Lack of encryption on portable devices. Every year, OCR publishes breach reports involving stolen laptops and lost phones containing unencrypted ePHI. For a telehealth practice where clinicians work from home, on the road, or from coffee shops in Rhinebeck, device encryption is not optional. It is the single most cost-effective safeguard you can implement.
OCR has also increased its focus on recognized security practices under the 2021 HITECH amendment (Public Law 116-321), which directs HHS to consider whether an entity had "recognized security practices" in place for at least the prior 12 months when determining fines and audit outcomes. Adopting a framework such as NIST CSF or the NIST SP 800-66 guidance specifically written for HIPAA can work in your favor if things go wrong.
Where to Start
If your Hudson Valley behavioral health or telehealth practice has been operating under the assumption that your vendor handles HIPAA, start by accepting that they do not. Then take three steps this month: pull your BAAs and read them, run a genuine risk analysis that inventories every system and device touching ePHI, and turn on full disk encryption across every endpoint. Those three actions will not make you fully compliant, but they will close the largest gaps and give you a foundation to build on.
The 18 addressable specifications are not optional checkboxes. They are decisions you must make, document, and defend. A five-clinician SUD practice in Middletown has the same legal obligations under the Security Rule as a hospital system in Manhattan. The scale of your compliance program can be proportionate to your size, but the obligation to have one is absolute.