An EHR platform is not a single piece of software. It is a decade or more of accreted decisions, connected to a long list of satellite systems — lab interfaces, imaging modalities, pharmacy robots, patient portals, payer clearinghouses, state immunization registries. Each of those connections is code, and most of that code is open source. Epic's Hyperspace client, Oracle Health's Millennium, Meditech Expanse, and Athenahealth's cloud platform all differ in important ways, but they share a common reality: the dependency graph is vast, the upgrade cadence is slow, and the number of people in any single hospital who can tell you what version of log4j is running on a specific integration engine is usually zero.
This is a governance problem more than a scanning problem. Scanners find CVEs; governance decides what to do about them when the vendor says a patch is eight months out and the compliance officer says the ePHI cannot sit offline for a weekend.
The dependency reality inside a production EHR
When Change Healthcare disclosed the breach that began 21 February 2024, the details that emerged over the following weeks were a case study in what EHR ecosystem dependency looks like in practice. Change, a UnitedHealth subsidiary, was not itself an EHR. It was one of the largest claims clearinghouses in the United States — a piece of infrastructure that sat between thousands of provider organizations and hundreds of payer organizations. Its compromise meant that prescriptions could not be filled, claims could not be submitted, and eligibility could not be verified across a substantial fraction of the US healthcare system. The dependency that mattered was not a library. It was an organizational dependency on a SaaS vendor whose software had been permitted to sit in the critical path.
The lesson is that dependency governance for EHR systems cannot stop at the npm or Maven level. It has to include the integration engines, the interface modules, the third-party clearinghouses, and the SaaS vendors whose APIs your clinical workflows assume are available. HL7 FHIR endpoints depend on OAuth libraries. Those libraries depend on cryptographic libraries. A vulnerability in one of those libraries — like CVE-2024-2511, the OpenSSL session cache memory growth issue from April 2024 — affects every integration that terminates TLS.
What regulators expect
The HHS Office for Civil Rights published the Notice of Proposed Rulemaking to modify the HIPAA Security Rule on 27 December 2024. The proposed updates are the first substantial revision since 2013, and the language around technology asset inventory and patching is the part that matters most for dependency governance. Under the NPRM, covered entities and business associates would be required to maintain a written inventory of technology assets, assess the risk introduced by each, and document the patching and vulnerability management activity applied to each.
The proposed rule does not say "produce a CycloneDX SBOM for your EHR," but it gets close. The inventory requirement, combined with the existing risk analysis obligation under §164.308(a)(1)(ii)(A), is a de facto requirement for dependency visibility. A risk analysis that ignores the open-source library versions running inside the EHR's web application tier is not a credible risk analysis, and OCR's pattern of enforcement actions makes clear that "we trusted the vendor" is not a defense.
The three-tier governance model
The governance model that has emerged at larger health systems over 2024 looks roughly like this.
At the first tier is the EHR vendor itself. Epic, Oracle Health, and Meditech each publish some form of software composition information to their customers — the level of detail varies widely. Epic publishes advisories for its Hyperspace and Bridges interfaces. Oracle has been more opaque about Cerner Millennium's internals but has been pushed toward greater disclosure by large customers since the UHG breach. Governance at this tier means negotiating, as part of the contract, a right to receive SBOMs and vulnerability disclosures on a defined schedule.
At the second tier is the hospital's integration layer. Mirth Connect, Corepoint, Rhapsody, and InterSystems Ensemble are the engines most US hospitals run. These engines themselves have dependencies, and the hospital's IT organization — not the EHR vendor — owns them. CVE-2023-43208, the NextGen Mirth Connect authentication bypass disclosed in October 2023 and actively exploited through 2024, sat squarely at this tier. Hospitals that had good governance at the integration layer patched quickly. Hospitals that had treated Mirth as someone else's problem did not.
At the third tier is the long tail of ancillary applications — the lab systems, the pharmacy software, the medical device middleware, the patient portal customizations. These are often written by small vendors, sometimes by local developers, and their dependency hygiene is variable. This tier is where dependency governance tends to fail because there is no single owner.
A practical workflow
The health systems that are doing this well have converged on a workflow that looks similar across organizations.
They maintain a central inventory of every software system that touches ePHI, keyed by vendor and version. They require SBOMs or equivalent dependency disclosures from every vendor above a defined materiality threshold, and they store those SBOMs in a system that can be queried when a new CVE lands. When a vulnerability is disclosed — log4shell in December 2021, Spring4Shell in March 2022, the MOVEit Transfer exploitation that Cl0p ran in mid-2023, the Apache Struts RCE in CVE-2023-50164, and the regr_cache.c issue from CVE-2024-4577 PHP CGI in June 2024 — the security team can determine within hours which systems are affected rather than spending days on discovery.
They also maintain a patching cadence expectation per tier. The EHR core is expected to patch on the vendor's quarterly cycle. The integration layer is expected to patch within thirty days of a high-severity disclosure. The ancillary applications are expected to patch within ninety days, with compensating controls required if the vendor cannot meet that window.
The compensating-control problem
Not every dependency can be patched on the clinically tolerable timeline. A lab interface that has been running for twelve years on a vendor who went out of business cannot simply be upgraded. The compensating control is usually network segmentation — placing the system behind an internal firewall that limits what it can talk to — combined with enhanced monitoring. Governance means documenting the compensating control, reviewing it periodically, and having a plan to retire the dependency.
How Safeguard Helps
Safeguard builds the technology asset inventory that the proposed HIPAA Security Rule update will require, with reachability analysis that separates the vulnerabilities that are actually callable in your EHR integration code from the noise of the unreachable majority. Griffin AI correlates new CVE disclosures against your SBOM corpus so the security team can answer "are we affected?" in minutes rather than days. Our SBOM ingest handles the mixed-format reality of healthcare — vendor-supplied CycloneDX from Epic, SPDX from open-source engines, and hand-curated lists for legacy ancillary systems. The TPRM module tracks your clearinghouses, lab vendors, and integration engine maintainers with a clinical-risk overlay, and policy gates block deployments that would introduce unpatched high-severity issues into ePHI-adjacent systems.