As CEO of Netsurit, I've grown our firm to support 300+ clients, including healthcare providers, via HIPAA/GDPR-compliant managed IT from our US offices in New Jersey, Texas, and beyond. For audits, deploy a structured information security policy like our template--detailing CIA triad rules, employee data-handling guidelines, and compliance with HIPAA to prove proactive protection. Justify exceptions using IT audit reports; ours assess infrastructure for risks/compliance gaps, document minimum-scope actions (e.g., targeted security controls), and timestamp recommendations, mirroring how we prep clients for transformations. Good-faith setups like withholding records pending fee payment or court review, as in our PAIA manual, can mimic blocking without audit-backed proof of legal necessity and requester notifications.
Running IT and cybersecurity for businesses in regulated industries since 1993 -- including healthcare-adjacent professional services firms -- I've sat across from clients during government audits and helped them reconstruct documentation they thought they had but couldn't produce fast enough. The biggest audit failure I see isn't bad intent -- it's undocumented intent. If you're claiming the Privacy exception because you required identity verification before releasing EHI, but that verification process lives only in someone's head and not in a written policy with timestamps, you don't have an exception. You have a liability. One specific pattern I've flagged with clients: their IT vendor locked down outbound file transfers as a "security best practice" -- which sounds responsible -- but there was no written carve-out documenting why certain data sharing channels were restricted and what the approved alternatives were. To an auditor, a blanket outbound block with no documented clinical or security rationale is indistinguishable from intentional blocking. Treat each exception claim like an internal audit package before CMS asks for one: the date the decision was made, who made it, what specific EHI was affected, why the restriction was the minimum necessary scope, and when it gets reviewed again. That last part -- the re-review date -- is the one most practices skip, and it's the one that signals to auditors whether you're managing a justified policy or just using an exception as a permanent workaround.
With 20+ years in IT infrastructure design and leading HIPAA compliance audits at Tech Dynamix, I've guided Northeast Ohio healthcare clients through regulatory prep like Ohio HB 96's cybersecurity mandates, directly applicable to CMS information blocking audits. Key in place: A documented cybersecurity program aligned to NIST CSF or CIS Controls, complete with policy reviews, remediation tracking, and annual role-based training logs to prove ongoing compliance. To justify an exception, provide security audit reports quantifying risks--like our findings that 80% of malware is AI-powered--with governance docs detailing the exact controls applied and their budget/right-sized scope. Good-faith pitfalls include rigid network hardening or immutable backups that unintentionally slow EHI exports during recovery tests; mitigate with pre-audited playbooks showing scalable access via cloud-managed Microsoft 365 without compromising resilience.
Twenty years in South Florida IT means I've sat across from medical practice managers who thought their biggest compliance risk was their firewall -- until I showed them their own front desk workflow was the problem. The information blocking rule isn't just an EHR configuration issue; it lives in your operations. The most overlooked audit exposure I see is the gap between what leadership *thinks* the release process looks like and what staff actually do under pressure. One practice I worked with had a perfectly written policy but their front desk was verbally telling patients records "take 30 days" -- that operational disconnect is exactly what an auditor documents. If you're claiming an exception, your weakest point isn't the decision itself -- it's the absence of a paper trail showing that decision was *deliberate and dated*. I've seen practices apply the same exception repeatedly with zero documentation of who reviewed it or when, which transforms a defensible position into an apparent pattern of blocking. From a pure IT infrastructure standpoint: if your systems can't produce a timestamped access log showing *when* a data request came in and *when* it was fulfilled, you have an audit readiness gap before you even get to the exceptions conversation. That's fixable before enforcement pressure arrives.
Good question, and this is exactly the kind of thing that catches healthcare practices off guard. I work directly with providers on HIPAA compliance readiness, including documentation that holds up when regulators come knocking--so let me give you what I actually see in the field. The most overlooked audit vulnerability isn't the exception itself--it's the *paper trail*. If you're claiming the Privacy exception or the Preventing Harm exception, you need contemporaneous documentation showing the clinical or administrative reasoning at the time the access was restricted. A policy written after the fact won't cut it. One practice I worked with had a patient portal throttling EHI exports during off-hours for "system integrity" reasons. Completely reasonable from an IT standpoint--but they had zero written policy linking that decision to a specific, reviewable risk analysis. That's the kind of good-faith protocol that reads as information blocking without supporting documentation. The concrete fix: tie every access restriction directly to a documented risk decision logged in your asset inventory and reviewed annually. Under the 2024 HIPAA NPRM, that annual review is becoming mandatory anyway--so building that habit now covers you on both fronts simultaneously.
I've learned you have to document exactly why you aren't sharing data. Those notes are your only defense during an audit. We keep strict logs whenever we hold information back, like when releasing it might risk patient safety. I always over-document my intent. Extra privacy steps can look like information blocking unless you explain clearly why you're doing them. If you have any questions, feel free to reach out to my personal email
My team handles dental IT, so we write down everything about patient data sharing, especially when we use one of the seven information blocking exceptions. At Medix Dental IT, we keep templates that show our security setup and the exact reason for any access denial. We learned that just explaining things, like why a security upgrade caused a delay, helps a lot during an audit. They really care about your intent. If you have any questions, feel free to reach out to my personal email
When i managed the 'IT checks' thing, keeping record of each and every access request saved us a number of times. We always recorded the person who wanted access, what for and whether or not we granted their request. I used to think writing those down every time was a chore but now I see it as a valuable.2 'safety measure'--without an explanation about why the approval was needed it seems the old 'roadblock' rather than security. If you have any questions, feel free to reach out to my personal email
Chief Operating Officer at Braff Law Car Accident Personal Injury Lawyers
Answered a month ago
For CMS information blocking, you should write down exactly why you are refusing to share data. We helped a clinic log these decisions in real time, and those notes were crucial during their audit. It showed they weren't just hiding things. Even if you block data for privacy reasons, you have to prove it. If you don't document your reasoning, auditors will assume you are breaking the rules. If you have any questions, feel free to reach out to my personal email
On our health-tech platform, we document the logic for every access control, especially the exceptions for safety or privacy. Monthly reviews over the last six months helped us catch small issues like overly restrictive sharing early. Just walk through your actual workflow with your compliance lead. Technical setups often look risky if you don't explain the reasoning behind them. If you have any questions, feel free to reach out to my personal email
In order to validate their use of exceptions in order to defend themselves when audited by the government for the CMS information blocking rule - each exception must be documented with a specific and verifiable action i.e., patient consent, harm prevention. Practices should keep records of all communications with patients that demonstrate that they were compliant with the rules, along with communication agreements and policies. Practices should also be able to provide a rationale for how and why they made that determination that supports the intent of the exception. There are times that protocols, even when done in good faith may still inadvertently create an information block. For example, if your practice has a policy in place that says that you can only share data via a specific format or system this may prevent some patients from accessing their information due to that policy and harm when you're trying to protect someone else's privacy. Regularly review these policies against the guidelines set by CMS. Additionally, you should ensure that there is a standard set of procedures for how you will handle requests from patients, and when it is appropriate to delay or deny a patient access to the information you have.
When I read the question—what should organizations have in place for CMS information blocking compliance, and how can they justify exceptions during an audit—I think about how often "good intentions" get lost without documentation. I've seen teams assume their policies were obvious, but when scrutiny comes, what matters is what you can prove, not what you meant. In practice, every exception claim needs a paper trail: written policies, timestamps, and a clear rationale tied directly to one of the seven allowed exceptions under Centers for Medicare & Medicaid Services rules. I once worked with a partner who delayed data sharing over security concerns, but they hadn't documented their risk assessment process—what felt like caution was nearly interpreted as blocking. Now I always recommend logging decisions in real time, including who made them and why. Another risk is operational friction—things like requiring extra forms, limiting portal access, or slow response workflows. These can be built with good intentions, but if they consistently delay access, they can look like barriers. The safest approach is to audit your own workflows as if you were the regulator: ask, "Would this look like we're discouraging access?" Ultimately, compliance isn't just about having policies—it's about being able to explain, with evidence, that every restriction was necessary, consistent, and applied fairly.
At this point, practices should have established: (1) clearly written policies regarding when they will release EHI and when they will restrict access to EHI; (2) documentation of their decision-making process(es) regarding why they released or restricted access to EHI; and (3) documentation of any refusals to release or delays in releasing EHI, identifying the rationale for the refusal/delay. Practices claiming to have exercised one of the exceptions listed above will be expected to provide a factual basis for the claim and to document (a) who made the decision; (b) when it was made; (c) why the decision was made in such a manner as to restrict access to EHI no more than necessary; and (d) legal, privacy, security and patient safety rationales that supported the decision. This documentation will be important to support the practice's argument that it acted in a good faith manner in exercising the authority to restrict access to EHI under the exceptions. As stated, the HHS final regulations published in late 2023 set forth disincentives for certain providers, and OIG and CMS have already advised that they will be taking necessary action following the effective date of the amended final regulation. OIG's comment that it will concentrate on investigating practices that may have caused patient harm, had a significant impact on the quality of care and have existed for a long duration or resulted in a financial loss sets forth a pretty clear indication of the types of practices that OIG will follow up in an investigation. Consequently, if OIG conducts an investigation of the practice, not only will OIG seek to learn about the practice's intent, but it will also seek to learn about the practice's operational reason(s) for the friction it created with respect to access, exchange and/or use of EHI.