The Change Healthcare Lesson. Mapping Concentration Risk Before It Maps You.

One weak link can stop care, stall claims, and drain cash in days. That was the lesson from the Change Healthcare attack: one platform handled about 40% of U.S. medical claims, and when it went down, some hospitals saw revenue fall by up to 17%.

If I had to boil this article down to a few plain points, it would be this:

• Start with services, not vendor names. I’d look first at claims, EHR access, pharmacy flows, imaging, scheduling, and connected devices.
• Map the full chain. That means vendors, products, subcontractors, cloud hosts, data centers, and any shared links behind them.
• Rank what can hurt you fastest. I’d sort dependencies by care impact, outage length, PHI exposure, and how much work runs through one provider.
• Test outages before they happen. If a clearinghouse, EHR, or cloud region fails for 24 to 72 hours, I’d want named fallback steps ready.
• Make this a leadership issue. This is not just an IT task. It touches finance, compliance, clinical teams, and the board.

At the core, the article makes one point: vendor risk questionnaires alone do not show where your single points of failure are. I need a living map of the services my organization cannot lose, the outside parties behind them, and the backup path when one of those links breaks.

Bottom line: I’d treat concentration risk as a map-and-test problem. Find the chokepoints, put a dollar figure on downtime, and make sure fallback plans work before the next outage forces the issue.

Stop Treating Every Vendor the Same: Daniel Liu on the Real Work of Third Party Risk

sbb-itb-535baee

Section 1: Define and locate concentration risk across critical healthcare services

Concentration risk is not standard vendor risk. It’s a different problem. The question is simple: what happens if one shared service, platform, or provider stops working?

A vendor might pass every questionnaire you send over and still leave your organization exposed. If that vendor goes down and you have no backup, you’re dealing with a single point of failure that can stop care or choke off cash flow.

Start with critical services, not just vendors

Begin with the clinical and business services that would shut down care or stop revenue within 72 hours. That usually includes claims processing, eligibility verification, pharmacy transactions, prior authorization, diagnostic imaging, and EHR documentation.

Once you know which services matter most, work backward. Find every vendor, platform, and subcontractor that keeps each service running. That shift matters. A vendor-first review often misses the service underneath it. And that’s where the risk usually sits.

From there, trace how each service works in practice, not just on paper.

Trace the hidden links between workflows, systems, and outside providers

Every critical service runs through a chain of systems, handoffs, and outside providers. Most organizations haven’t mapped that chain all the way through.

Take claims, for example. A single workflow might move from billing software to a clearinghouse to a payment processor. Each step can fail. And the picture gets murkier when fourth parties enter the mix. You may contract with several separate vendors, yet they all depend on the same cloud provider, like AWS or Azure, or the same regional data center. If that shared layer goes down, multiple vendors can fail at the same time.

Under HITECH, HIPAA safeguards must extend to subcontractors, so BAA terms need to flow through the chain ^[1].

Map PHI and payment data from end to end. For each critical service, track:

• which applications touch the data
• which interfaces move it
• which outside providers store or process it

That map often shows dependencies a questionnaire won’t catch.

Spot common healthcare bottlenecks before they fail

The table below shows common concentration-risk bottlenecks in U.S. provider settings. These reflect the dependency patterns that the Change Healthcare disruption exposed at national scale ^[1].

The worst bottlenecks usually have one thing in common: no short-term backup.

If one claims processor handles a big share of your reimbursement volume, a disruption can stall revenue fast. If one EHR dependency supports several workflows at once, one outage can knock out multiple functions in one shot. That’s why concentration risk can hit harder than a normal vendor issue.

The average hospital system works with more than 1,000 vendors ^[1]. But only a small slice of those relationships carries most of the operational weight. That’s the group you need to find first.

These bottlenecks become the input for the dependency inventory and tiering model.

Section 2: Build a concentration risk inventory and tiering model

Build one dependency inventory across vendors, products, and fourth parties

Start by turning those bottlenecks into a single dependency inventory. Most healthcare organizations already keep vendor lists. The problem is that those lists usually don't show the full dependency chain.

A proper concentration risk inventory brings vendors, products, Business Associates, and fourth parties into one view. For each item, track the service it supports, the providers behind it, and the shared infrastructure underneath it. That includes the clinical or business function it supports, whether it handles PHI, how it connects to your systems, where it's hosted, and which subcontractors it depends on.

That last part is where many inventories miss the mark. When you map fourth parties - the vendors behind your vendors - you often find 30–50% more dependencies than your first records show ^[1].

The goal isn't to make the list longer. It's to make it complete. Hidden concentration risk tends to sit in the spaces between separate records.

Tier dependencies by criticality, concentration, and downtime impact

Once the inventory is in place, the next step is to prioritize it. Use the inventory to rank what needs review first. Not every vendor brings the same level of risk, and treating them all the same eats up time and can pull attention away from what matters.

Use four factors to tier dependencies:

• clinical criticality
• workflow concentration
• data sensitivity
• recovery time

A higher tier means a larger operational blast radius. Regulatory duties matter here too. HIPAA BAA requirements and FDA categories for medical devices shape how deeply you need to assess a given dependency ^[1].

The table below maps common vendor categories to tiers, concentration signs, and the level of review each one needs.

Watch for shared infrastructure across tiers. If several Critical-tier vendors run on the same cloud region or regional data center, you've got a concentration cluster. One outage there can knock out several services at the same time ^[1].

Use structured assessment workflows to keep the inventory current

Once tiering is set, keep the inventory active. An inventory that doesn't get updated turns into a history file. The hard part isn't building it. It's keeping it accurate as dependencies shift over time.

Censinet RiskOps™ centralizes vendor inventories, product catalogs, evidence, and dependency data in one place, while Censinet AI™ speeds questionnaire completion and surfaces fourth-party exposure. That matters when the average hospital system manages more than 1,000 vendors simultaneously ^[1] and 90% of serious healthcare data breaches involve a third party ^[1].

Treat the inventory like a living record. Structured workflows help keep it current and defensible.

Section 3: Test outage scenarios and reduce blast radius

Run scenarios for clearinghouse, EHR, and shared-cloud outages

An inventory by itself doesn't tell you much. The hard truth shows up when you run outage scenarios and see what fails first. Once the inventory is tiered, test the highest-concentration clusters first. That includes the clearinghouses, EHR connections, cloud regions, and other dependency clusters already flagged in the inventory.

A lot of healthcare organizations find out they're not prepared for outages that last more than 72 hours ^[1]. That's where testing needs to go. Push past that point and see where manual work starts to break down, where cash flow gets squeezed, and where compliance problems start to show.

The outage types below are the ones most likely to expose concentration risk in healthcare operations right now.

These tests don't mean much unless every failure point has a named fallback. If a clearinghouse goes down, who takes over? If a cloud region fails, what shifts where? If the answer is "we'd figure it out", that's a warning sign.

Put fallback options in place before the next disruption

Scenario mapping only helps if fallback options are already in place before anything goes wrong. Start with the services that would stop claims, prescriptions, documentation, or access to care. For claims processing, that means setting up at least one alternate clearinghouse before you need it, not after your primary provider goes dark. For payments, it means spreading banking and payment processing across more than one relationship so one vendor failure doesn't choke off cash flow.

Manual fallback procedures also need to exist for pharmacy, registration, and documentation. And no, having them written down isn't enough. If staff haven't practiced them in the last year, they aren't ready. Drills turn a binder on a shelf into something people can actually use.

Dallas Federal Reserve research found that automated vendor risk assessment solutions and questionnaire-based programs do not protect critical vendor relationships ^[1].

Backups need the same level of scrutiny. It's not enough to have backups sitting somewhere. They need to be segmented, and teams need to test whether restoration works. Each plan should also include clear decision triggers, with set time thresholds such as 24 hours or 72 hours. That way, teams switch to fallback vendors or manual processes based on a preset rule, not a panicked debate in the middle of an outage.

Assign ownership and oversight at the enterprise level

Once controls are set, give each critical dependency and fallback path a clear owner. If one dependency can knock out several services at the same time, oversight can't sit with one department alone. It has to live at the enterprise level.

Concentration risk isn't just an IT problem. It's a board, finance, clinical, and compliance problem too. Those groups should be looking at the same supplier map and the same concentration hot spots. Board-level visibility into critical supplier maps is required. Executive teams should review concentration hot spots on a regular basis, especially clusters of Critical-tier vendors sharing the same infrastructure or single platforms carrying too much transaction volume.

Those reviews should feed straight into HIPAA contingency planning requirements and line up with NIST-based supply chain risk management frameworks, so compliance work and resilience planning move together instead of in separate tracks.

Conclusion: A working model for concentration risk management in healthcare

The Change Healthcare breach showed, in plain terms, how one third-party failure can bring core operations to a halt across a healthcare enterprise. When the company went down, hospitals reported revenue declines of up to 17% in the weeks that followed ^[1]. This is a concentration risk issue, and it sits with the full leadership team, not just IT.

Start with the services that would interrupt care or cash flow first. Then work backward from each service to the shared provider, platform, or cloud region behind it. That’s usually where single points of failure are hiding. And that’s where the risk is most exposed.

Once those critical services are clear, put a dollar figure on the outage. Downtime hits from several angles at once: delayed claims, interrupted cash flow, care disruption, and HIPAA/HITECH liability ^[1]. When you translate IT risk into operational and financial terms, board attention follows. That’s what moves concentration risk from a technical issue to an executive one.

After that, keep the inventory managed in one governed workflow. That way, owners, tiers, and hot spots stay current instead of drifting out of date.

Questionnaire-based programs, on their own, don’t go far enough for critical vendor relationships. The next move has to be operational, not theoretical: start with critical services, find the single points of failure, quantify downtime, and keep the map current.

FAQs

How do we find hidden fourth-party dependencies?

Go beyond static lists and map each clinical and operational workflow that matters - like stroke care or pharmacy verification - back to the systems, data feeds, and vendors behind it.

Review API logs, outbound traffic, and authentication activity for shared services. On top of that, require vendors to disclose major subprocessors and infrastructure dependencies. Use SBOMs to identify embedded components, and use automated risk mapping to spot shared choke points.

What should we map first if resources are limited?

Start with the highest-risk vendors based on spend, PHI exposure, and clinical reliance. Go after the shared choke points first, like cloud regions, identity providers, clearinghouses, and pharmacy automation platforms. If one of those goes down, the impact can ripple across the whole enterprise.

Then build a workflow-based risk map that ties critical clinical and operational functions to the vendors, systems, and data flows behind them.

How often should we test outage fallback plans?

Use a risk-based cadence. Run quarterly tabletop exercises to spot weak points, and hold annual full-scale simulations to test end-to-end processes and communications under pressure.

You should also retest after major changes or significant incidents. That way, recovery procedures stay aligned with current dependencies and failure modes, including claims clearinghouses, EHR integrations, and identity systems.

Related Blog Posts

• When One Point of Failure Becomes a Global Healthcare Disruption
• Healthcare’s Technology Ecosystem Is More Fragile Than It Looks
• What Nation-State Attacks Reveal About Healthcare’s Digital Dependencies
• The Hidden Cost of Healthcare’s Interconnected Risk Landscape