logo
Contact Us

844-740-7100

    Colington Consulting

    Helping Organizations Achieve HIPAA Compliance™

    Contact Us

    Category: HIPAA Risk Analysis

    • OCR Fined a Health System $800,000 for Ransomware, Then Published the Fix the Next Day

      OCR Fined a Health System $800,000 for Ransomware, Then Published the Fix the Next Day

      Why Did Lehigh Valley Health Network Pay $800,000, and What Does OCR Expect?

      Quick answer: OCR found that Lehigh Valley Health Network (LVHN) failed to conduct an accurate, thorough risk analysis, did not regularly review information system activity, and notified patients and HHS late after a 2023 ransomware attack exposed the protected health information (PHI) of 248,359 individuals. OCR announced the $800,000 settlement on October 29, 2026. The next day, its October 2026 Cybersecurity Newsletter linked the Cybersecurity and Infrastructure Security Agency’s (CISA) essential steps, including phishing training, multifactor authentication (MFA), logging, backups, and encryption, directly to HIPAA Security Rule requirements. For every covered entity and business associate, the message is the same: these safeguards are already required, and OCR expects them in place before an attack, not after.

      What Happened at Lehigh Valley Health Network

      On February 4, 2023, LVHN, a Pennsylvania health system, detected suspicious activity in its IT system that was later confirmed to be ransomware. LVHN filed a breach report with HHS on May 15, 2023. Attackers exfiltrated PHI and posted it on the dark web; the compromised information included radiation oncology treatment photographs, names, addresses, dates of birth, Social Security numbers, driver’s license numbers, financial information, diagnoses, lab results, medications, and treatment information.

      Under the resolution agreement, LVHN paid $800,000 and agreed to a corrective action plan that OCR will monitor for three years. OCR identified the settlement as its 22nd ransomware enforcement action. OCR Director Paula M. Stannard summarized the agency’s position plainly: “The best defense against cyberattacks is full implementation of the HIPAA Security Rule.”

      What OCR Found

      OCR’s investigation began with LVHN’s breach report and found potential violations of the Privacy, Security, and Breach Notification Rules:

      • No accurate and thorough risk analysis of the potential risks and vulnerabilities to all of its electronic protected health information (ePHI).
      • No procedures to regularly review information system activity, such as audit logs, access reports, and security incident tracking reports.
      • An impermissible disclosure of the PHI of 248,359 individuals.
      • Late notification to affected individuals of a breach of unsecured PHI.
      • Late notification to the Secretary of HHS of the same breach.

      The corrective action plan requires a new risk analysis, a risk management plan, revised policies and procedures, and updated workforce training.

      Three Lessons From the Findings

      1. Enforcement has a long tail

      More than three and a half years passed between discovery of the attack and the settlement. The documentation you have today is what OCR will evaluate years from now; it cannot be rebuilt after the fact.

      2. Logging is only half the control

      The Security Rule separates audit controls, which record system activity, from information system activity review, which requires someone to examine it. OCR cited LVHN for the second. Logs nobody reads will not catch an intruder before data leaves the network.

      3. The breach notification clock does not wait for the investigation

      HIPAA requires notice to affected individuals without unreasonable delay and no later than 60 calendar days after discovery, and notice to HHS within the same window when 500 or more individuals are affected. LVHN’s breach report was filed more than three months after LVHN discovered the suspicious activity, and OCR cited late notice to both individuals and HHS as separate violations. A slow response adds violations on top of the breach itself.

      One Day Later, OCR Published the Roadmap

      OCR’s October 2026 Cybersecurity Newsletter, released for Cybersecurity Awareness Month under the theme “Securing the Next 250,” took the essential steps CISA recommends for critical infrastructure organizations, including the Healthcare and Public Health sector, and tied each one to a specific Security Rule requirement.

      Phishing training maps to security awareness and training; strong passwords and MFA map to person or entity authentication; software updates map to risk analysis and risk management; logging maps to audit controls and information system activity review; backups map to the data backup plan; encryption maps to the encryption specifications for data at rest and in transit; incident response plans map to security incident procedures; and preparing for system disruptions maps to the contingency plan. The one step HIPAA does not require is reporting cyber incidents to CISA, which OCR encourages but does not mandate.

      Where the Settlement and the Newsletter Point to the Same Gaps

      The risk analysis drives everything else. The newsletter ties authentication choices and patching priorities back to the risk analysis, and OCR’s recommendations in the LVHN announcement start with identifying how ePHI enters, flows through, and leaves your systems. Without an accurate and thorough risk analysis, no other security decision is defensible.

      System activity review is a recurring enforcement theme. It is a finding in the LVHN settlement and a core step in the newsletter. If you cannot show who reviews logs, how often, and what happens next, OCR will find that gap.

      Backups must survive the attack. Because some ransomware deletes or disrupts online backups, OCR advises keeping at least some backups offline, reviewing backup logs, and periodically testing restorations.

      Addressable does not mean optional. ePHI must be encrypted at rest and in transit wherever reasonable and appropriate; where it is not, the organization must implement an equivalent alternative, if reasonable and appropriate, and document its rationale.

      Reporting to CISA is not HIPAA breach reporting. A CISA report does not satisfy HIPAA breach notification; individuals, HHS, and, where required, the media must still be notified.

      What to Do Before OCR Asks

      • Complete or update a risk analysis that traces ePHI where it enters, flows through, and leaves every system, vendor, and location.
      • Build a risk management plan that assigns an owner, a safeguard, and a target date to each identified risk.
      • Assign responsibility for regular log and access report review, and document each review.
      • Confirm backups include offline copies, and keep records of successful restoration tests.
      • Document your encryption decisions for ePHI at rest and in transit, including any equivalent alternatives.
      • Base authentication decisions, including where MFA is required, on your risk analysis.
      • Rehearse your incident response plan at least annually with leadership, legal counsel, and technical staff, and confirm it meets HIPAA’s 60 day breach notification deadline.
      • Train every workforce member, including management, on phishing and their role specific responsibilities.

      Frequently Asked Questions

      What was the Lehigh Valley Health Network HIPAA settlement?

      On October 29, 2026, OCR announced that LVHN paid $800,000 and agreed to a corrective action plan monitored for three years, resolving an investigation into a 2023 ransomware attack that affected 248,359 individuals. It was OCR’s 22nd ransomware enforcement action.

      Why would OCR penalize an organization that was the victim of a ransomware attack?

      OCR does not penalize the attack itself; it penalizes the compliance failures uncovered by the investigation. At LVHN, those included a lack of an accurate and thorough risk analysis, no regular review of information system activity, and late breach notification.

      Does HIPAA require multifactor authentication?

      The Security Rule does not prescribe a specific authentication method, but it requires procedures to verify that anyone seeking access to ePHI is who they claim to be. OCR’s October 2026 newsletter explains that the risk analysis should guide the choice and that MFA may be needed to reduce risk for remote access and more sensitive systems.

      Is encryption required under HIPAA?

      Encryption is an addressable specification, meaning regulated entities must encrypt ePHI at rest and in transit wherever reasonable and appropriate. If encryption is not reasonable and appropriate in a specific circumstance, the organization must implement an equivalent alternative measure, if reasonable and appropriate, and document its decision and rationale.

      Don’t Let Your Risk Analysis Become the Finding; Colington Consulting Can Help

      Ransomware settlements keep returning to the same core finding: a lack of accurate, thorough risk analysis. Colington Consulting’s lead consultants have personally conducted more than 1,000 HIPAA risk assessments. We map how ePHI is created, moves, and leaves your organization across every system, vendor, and location; we evaluate the safeguards OCR actively enforces, including system activity review, backup isolation and testing, encryption decisions, authentication, and incident response; and we deliver a documented risk management plan that holds up when OCR requests it.

      Get a free HIPAA Risk Review. We will show you where your organization stands against the findings in the LVHN settlement and the steps in OCR’s October 2026 newsletter, and where to focus first.

      Schedule Your Free HIPAA Risk Review →

      Sources

      U.S. Department of Health and Human Services, Office for Civil Rights, “HHS’ Office for Civil Rights Settles Ransomware Investigation of Lehigh Valley Health Network,” October 29, 2026.

      U.S. Department of Health and Human Services, Office for Civil Rights, October 2026 OCR Cybersecurity Newsletter, “Cybersecurity Awareness Month 2026,” October 30, 2026.

      U.S. Department of Health and Human Services, Office for Civil Rights, October 2022 Cybersecurity Newsletter, “HIPAA Security Rule Security Incident Procedures.”

      Cybersecurity and Infrastructure Security Agency, Cybersecurity Awareness Month Toolkit (2026), cisa.gov.

      45 C.F.R. § 164.308(a)(1), Security Management Process; § 164.308(a)(5), Security Awareness and Training; § 164.308(a)(6), Security Incident Procedures; § 164.308(a)(7), Contingency Plan.

      45 C.F.R. § 164.312(b), Audit Controls; § 164.312(d), Person or Entity Authentication; §§ 164.312(a)(2)(iv) and 164.312(e)(2)(ii), Encryption; § 164.306(d)(3), Addressable Implementation Specifications.

      45 C.F.R. §§ 164.400 through 164.414, Breach Notification Rule.

    • OCR and ONC Just Updated the Free SRA Tool; Here’s Why That Doesn’t Solve Your Risk Analysis Problem

      OCR and ONC Just Updated the Free SRA Tool; Here’s Why That Doesn’t Solve Your Risk Analysis Problem

      Quick answer: On September 10, 2026, OCR and ONC released version 3.7 of the Security Risk Assessment (SRA) Tool, adding new content on remote access, telework, and system activity logging, as well as expanded asset examples and revised reports. The update is genuinely useful, but it doesn’t change what makes the SRA Tool a weak standalone fit for many organizations: it doesn’t stop you from leaving sections incomplete; OCR itself has never confirmed the tool meets its own “accurate and thorough” risk analysis standard; OCR has described the tool as built for smaller organizations without ever defining what that means; and a broad, general questionnaire can’t fully account for how ePHI actually moves through your specific organization. For most practices, the SRA Tool is a reasonable starting point, not a finish line.

      OCR and ONC Just Released SRA Tool Version 3.7

      On September 10, 2026, HHS’s Office for Civil Rights and the Office of the National Coordinator for Health IT announced version 3.7 of the free SRA Tool. According to the release, the update includes:

      • Revised assessment coverage and scope questions and education
      • New remote access and telework questions and education
      • Updated system activity logging language and education
      • Expanded asset examples to reflect newer technology
      • Updated software libraries for bug and vulnerability fixes
      • Report revisions to capture additional details and comments

      OCR and ONC also scheduled webinars on September 15 and 16, 2026, to walk organizations through the new features. All of this is a real improvement over the prior version; it’s also not, on its own, the same as a compliant HIPAA risk analysis, and that gap is where many organizations run into trouble.

      The Tool Lets You Stop Before You’re Finished

      During the September 2026 OCR/NIST “Safeguarding Health Information” conference, Nick Heesters, Senior Advisor for Cybersecurity in OCR’s Health Information Privacy, Data, and Cybersecurity Division, described a pattern OCR has seen play out in real investigations: organizations that used the SRA Tool but left portions of it incomplete. The software doesn’t require every section to be finished before a user can close it out or generate a report; it simply picks back up wherever the user left off, whenever that happens to be.

      That flexibility is convenient for whoever is filling it out. It’s a liability for the organization relying on it, since an incomplete assessment isn’t a defense in an investigation; it’s a finding. If your risk analysis has gaps because the tool allowed those gaps to sit unresolved, OCR treats that the same way it treats any other incomplete risk analysis.

      OCR Has Never Said the SRA Tool Meets Its Own Standard

      Here’s the detail worth sitting with. At past OCR/NIST conferences, Heesters has been asked directly whether OCR considers output from the SRA Tool to be an “accurate and thorough” risk analysis, which is OCR’s own standard under the Security Rule’s Security Management Process provision. He hasn’t given a direct yes or no. His answer has consistently been that the SRA Tool is one of the tools an organization can use as part of a broader risk analysis process, not a guarantee of adequacy on its own.

      The agency that enforces this standard has had multiple chances to say that its own free tool satisfies it, but hasn’t. That’s not a condemnation of the tool; it’s a statement about its limits, and it should shape how much weight any organization places on a completed SRA Tool questionnaire on its own.

      OCR Built This Tool With Smaller Organizations in Mind, and Never Said What “Smaller” Means

      OCR and ONC have described the SRA Tool as designed for small and medium-sized health care providers. Neither agency has defined where that scope actually ends. No stated employee count, revenue threshold, patient volume, or system complexity marks the line between an organization the tool was built for and one that has outgrown it.

      That ambiguity matters because many organizations using the tool don’t actually know which side of that undefined line they’re on. A practice with ten providers and a single EHR is a very different compliance environment than a forty-provider, multi-specialty group running telehealth, a patient portal, and three billing vendors; yet nothing in OCR’s own materials tells either one whether the tool was designed with them in mind. Absent a definition, organizations tend to assume the tool fits them because it’s free and easy to access, not because OCR ever confirmed that it does.

      A Broad Checklist Wasn’t Built Around Your Environment

      OCR’s own guidance, reinforced at the same 2026 conference, describes a risk analysis as an assessment of risk to ePHI at three distinct stages: where it’s created or enters the organization, where it flows internally between systems and departments, and where it leaves the organization entirely. A compliant risk analysis must trace all three stages for your specific systems, your specific vendors, and your specific workforce, not a generalized questionnaire built to apply to every covered entity at once.

      The SRA Tool asks the same structured questions of a practice with five providers, a hospital system, and a school district billing Medicaid. When your organization’s actual ePHI flow doesn’t map cleanly to the tool’s built-in categories, gaps appear, and the tool has no way to flag a misapplied category or a missed system entirely.

      What This Costs Small and Midsize Practices in Practice

      None of this means the SRA Tool has no value; it’s free, and it gives an organization a starting structure. But the real cost shows up when practice staff, who aren’t compliance professionals and aren’t expected to be, spend hours interpreting technical questions about encryption, access controls, and system logging, only to close out a tool that was never confirmed to fit their size or environment in the first place. That’s hours spent and a false sense of security produced, at the same time.

      Why Spend Hours on a Tool OCR Won’t Vouch For?

      A free tool that OCR itself won’t confirm meets its own standard, that was built with an undefined idea of “smaller” in mind, that lets you walk away with unfinished sections, and that treats a five-provider practice the same as a five-hundred-provider health system isn’t a shortcut. It’s a slower path to the same uncertainty you started with.

      Colington Consulting’s lead consultants have personally conducted more than 1,000 HIPAA risk assessments; we work directly with your systems, your vendors, and your staff, and build a documented, defensible risk analysis mapped to how ePHI actually moves through your organization, not a generic questionnaire built to apply to everyone at once.

      Get a free HIPAA Risk Review. We’ll show you where a generic tool would leave gaps and what a thorough, defensible risk analysis looks like for your organization.

      Schedule Your Free HIPAA Risk Review →

      Sources

      U.S. Department of Health and Human Services, Office for Civil Rights, and Office of the National Coordinator for Health IT, “HHS Releases Updated Security Risk Assessment Tool,” September 10, 2026.

      U.S. Department of Health and Human Services, Office for Civil Rights, and National Institute of Standards and Technology, “Safeguarding Health Information: Building Assurance Through HIPAA Security” Conference, September 2 to 3, 2026, NIST Gaithersburg Campus, Gaithersburg, MD.

      U.S. Department of Health and Human Services, Office for Civil Rights, and Office of the National Coordinator for Health IT, Security Risk Assessment (SRA) Tool product documentation and user guide.

      45 C.F.R. § 164.308(a)(1), Security Management Process (Risk Analysis and Risk Management).

      Frequently Asked Questions

      Does using the free HHS SRA Tool satisfy HIPAA’s risk analysis requirement?

      Not necessarily. OCR has repeatedly declined to confirm that output from the SRA Tool meets its own “accurate and thorough” risk analysis standard, describing it instead as one tool that can support a broader risk analysis process.

      Does OCR require organizations to use the SRA Tool?

      No. OCR and ONC offer the SRA Tool as a free resource to help organizations conduct a risk analysis; it isn’t a mandated format, and using it doesn’t by itself guarantee compliance with the Security Rule’s risk analysis requirement.

      Is the SRA Tool meant for organizations of any size?

      OCR and ONC have described the tool as designed for small and medium-sized health care providers, but neither agency has defined what counts as small or medium. Organizations of any size can use it, but there’s no official guidance on where it stops being an appropriate fit.

      Can I leave sections of the SRA Tool incomplete and finish later?

      Yes, and that’s part of the concern. The software allows users to save an incomplete assessment and resume it later, which means an organization may end up relying on a risk analysis that was never completed.

      What did OCR update in SRA Tool version 3.7?

      Version 3.7, released September 10, 2026, added revised assessment coverage and scope questions, new remote access and telework content, updated system activity logging language, expanded asset examples, updated software libraries, and revised reporting.

      What should a practice do instead of relying only on the SRA Tool?

      Use it as a starting point if you choose to, but pair it with, or replace it with, a risk analysis conducted by someone who can map ePHI creation, flow, and exit points specific to your organization, and who can speak to whether the result would hold up under OCR’s own standard.

    • MIPS Security Risk Analysis 2026: The New Risk Management Attestation

      MIPS Security Risk Analysis 2026: The New Risk Management Attestation

      Your 2026 MIPS Attestation Now Covers Risk Management, Not Just Risk Analysis

      Did you know CMS requires a security risk analysis for MIPS? Under the Promoting Interoperability (PI) performance category, clinicians must attest that they conducted or reviewed a security risk analysis as required by the HIPAA Security Rule at 45 CFR 164.308(a)(1). Beginning with the 2026 performance period, CMS added a second required attestation: that the clinician also conducted security risk management activities under the same Security Rule standard. Failing to complete either attestation results in no score for the entire PI category, which accounts for 25 percent of a traditional MIPS final score and directly affects a clinician’s Medicare payment adjustment.

      What CMS Requires for the 2026 Performance Period

      The requirement sits under the PI category’s Protect Patient Health Information objective as the Security Risk Analysis measure (PI_PPHI_1). For 2026, CMS split it into two separate “Yes” attestations:

      • Risk analysis: the clinician, group, or APM Entity conducted or reviewed a security risk analysis in accordance with 45 CFR 164.308(a)(1).
      • Risk management: the clinician, group, or APM Entity conducted security risk management activities as required under the HIPAA Security Rule, implementing security measures sufficient to reduce identified risks and vulnerabilities to a reasonable and appropriate level.

      A few details matter when planning the work. The analysis must be completed or reviewed annually within the calendar year of the performance period, though it need not fall within the PI reporting window. CMS expects it to cover each certified EHR technology (CEHRT) the clinician or group uses. The measure earns no points on its own; it functions as a gatekeeper, so a “No” or an unsupported “Yes” zeroes out the category regardless of how well every other PI measure performs.

      The same objective also includes a separate required attestation for an annual self-assessment using the High Priority Practices SAFER Guide. That measure addresses EHR safety practices; it is not a substitute for a HIPAA risk analysis.

      Why CMS Added Risk Management

      The HIPAA Security Rule has always required both steps. The Security Management Process standard pairs risk analysis at 45 CFR 164.308(a)(1)(ii)(A) with risk management at 164.308(a)(1)(ii)(B); the former identifies the risks, and the latter requires the organization to act on them. CMS finalized the change for clinicians in the Calendar Year 2026 Physician Fee Schedule final rule and made a parallel change for eligible hospitals and critical access hospitals in the FY 2026 IPPS final rule.

      The change also mirrors what OCR told attendees at its September 2026 conference with NIST: a risk analysis that does not feed into a documented risk management program is an incomplete compliance posture. CMS now asks clinicians to attest to both halves, meaning a risk analysis that identified problems and then sat in a folder no longer supports a clean attestation.

      The Attestation Is Only as Strong as the Analysis Behind It

      A “Yes” in the MIPS submission is a representation to CMS that affects Medicare payment, and MIPS submissions are subject to CMS data validation and audit. If a clinician cannot provide documentation supporting the attestation, the PI score and the payment adjustment tied to it can be revised.

      The exposure does not stop with CMS. The HIPAA obligation exists independently of MIPS, and OCR measures a risk analysis against its own standard: an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all electronic protected health information (ePHI) the organization holds. OCR has also been clear that a gap analysis, which compares current practices against a checklist, does not meet that standard. A thin risk analysis therefore creates risk on two fronts: payment under MIPS and enforcement under HIPAA.

      In our experience, the gaps that undermine a MIPS attestation are typically the same ones OCR cites:

      • Scope is limited to the EHR. CMS requests coverage for each CEHRT; HIPAA requires coverage of all ePHI, including email, patient portals, billing systems, remote access, backups, and vendors.
      • Last year’s analysis carried forward. A prior assessment that was never reviewed against new systems, locations, or staff does not reflect the current environment.
      • Findings without follow-through. Risks were identified, but no remediation plan, owner, or target date was ever documented; this now directly contradicts the risk management attestation.
      • Group attestations that exceed the documentation. A group or APM Entity attests for every clinician, while the underlying analysis covers only one site or one system.

      What to Do Before You Attest for 2026

      • Confirm timing and scope. Make sure your risk analysis was completed or reviewed during calendar year 2026 and covers every system, location, and vendor that creates, receives, maintains, or transmits ePHI.
      • Document risk management, not just risk. For each identified risk, record the safeguard selected, who owns it, the target date, and its current status.
      • Assemble an evidence file. Keep the dated risk analysis, the risk management plan, and records of completed remediation together so the attestation can be supported if CMS or OCR requests it.
      • Align group submissions. If you report as a group or APM Entity, confirm the analysis covers every participating clinician’s environment and CEHRT.
      • Separate MIPS status from HIPAA obligations. Some clinicians, including many small practices, may have the PI category reweighted. That changes MIPS scoring; it does not change the HIPAA Security Rule requirement to conduct and act on a risk analysis.

      Attesting “Yes” Should Mean Something; Colington Consulting Makes Sure It Does

      Your 2026 MIPS attestation now asks two questions, and both require documentation that holds up to CMS and OCR. Colington Consulting’s lead consultants have personally conducted more than 1,000 HIPAA risk assessments, and our process is designed to be extensive, accurate, and thorough. We map how ePHI is created, how it moves, and where it leaves your organization across every system, vendor, and location, not just your EHR; we assess and rate each risk specific to your environment; and we deliver a documented risk management plan that supports both your MIPS attestations and the HIPAA Security Rule standard enforced by OCR.

      Get a free HIPAA Risk Review. We will show you where your current risk analysis and risk management documentation stand, and what it will take to attest with confidence.

      Schedule Your Free HIPAA Risk Review →

      Sources

      Centers for Medicare & Medicaid Services, Quality Payment Program, 2026 MIPS Promoting Interoperability Performance Category Measure Specification: Security Risk Analysis (PI_PPHI_1).

      Centers for Medicare & Medicaid Services, Quality Payment Program, 2026 MIPS Promoting Interoperability Performance Category Measure Specification: High Priority Practices SAFER Guide (PI_PPHI_2).

      Centers for Medicare & Medicaid Services, Calendar Year 2026 Physician Fee Schedule final rule, 90 FR 49874.

      Centers for Medicare & Medicaid Services, FY 2026 Hospital Inpatient Prospective Payment System (IPPS) and Long Term Care Hospital PPS final rule, Medicare Promoting Interoperability Program.

      45 C.F.R. § 164.308(a)(1), Security Management Process (Risk Analysis and Risk Management).

      U.S. Department of Health and Human Services, Office for Civil Rights, Guidance on Risk Analysis Requirements under the HIPAA Security Rule, hhs.gov.

      U.S. Department of Health and Human Services, Office for Civil Rights, and National Institute of Standards and Technology, “Safeguarding Health Information: Building Assurance Through HIPAA Security” Conference, September 2 to 3, 2026, Gaithersburg, MD.

      Frequently Asked Questions

      Does MIPS require a security risk analysis?

      Yes. The Security Risk Analysis measure is a required attestation within the MIPS Promoting Interoperability performance category. Without it, the clinician, group, or APM Entity receives no score in the category.

      What changed for the 2026 MIPS performance period?

      CMS added a second required attestation. Clinicians must now attest “Yes” to both conducting or reviewing a security risk analysis and conducting security risk management activities under the HIPAA Security Rule.

      Does the risk analysis have to be done during the PI performance period?

      No. It may be completed or reviewed outside the PI reporting window, but it must occur within the calendar year of the performance period.

      What happens if we attest “Yes” without a supporting risk analysis?

      MIPS submissions are subject to CMS data validation and audit. If the attestation cannot be supported, the PI score and the related payment adjustment may be affected, and the missing analysis is also a HIPAA Security Rule deficiency that OCR can cite independently.

      Is a risk analysis that only covers our EHR enough?

      Not for HIPAA purposes. CMS asks that the analysis cover each CEHRT, but the HIPAA Security Rule requires an accurate and thorough assessment of risk to all ePHI the organization holds, wherever it is created, flows, or leaves.

      If our practice is reweighted out of Promoting Interoperability, do we still need to conduct a risk analysis?

      Yes. Reweighting affects how MIPS calculates your score, but it does not remove the HIPAA Security Rule requirement to conduct a risk analysis and implement risk management.

    Helping healthcare organizations navigate HIPAA requirements, reduce compliance risks, and protect sensitive health information.

    Quick Links

    Our Services

    Specialty Services

    Need Help?

    Facebook X-twitter Linkedin Youtube

    © 2026 Colington Consulting. All rights reserved.