Written and maintained by CASRAI Editorial Board
Last updated
Enterprise risk management (ERM) in a hospital is the practice of managing risk across the whole organization under one governance structure and one common taxonomy, instead of managing clinical risk, financial risk, cybersecurity risk, and facilities risk as separate, disconnected programs that each report up a different chain. The American Society for Healthcare Risk Management (ASHRM) is the professional body that has done the most to formalize what ERM means for a hospital or health system, and its risk-domain structure is the reference point most healthcare risk managers use when they build or explain a program.
This guide covers the risk-domain taxonomy ERM organizes around, how it differs from the narrower scope of traditional clinical risk management, and the two practical tools — the risk register and the risk heat map — that connect domain-level risk identification to board-level reporting.
What ERM is, and what it replaces
Before ERM became the standard framing, most hospitals ran risk management as a function focused almost entirely on clinical liability: adverse events, malpractice claims, informed consent, and the insurance/claims process that follows a bad outcome. That work still matters and still exists — it’s the core of what a CPHRM-credentialed risk manager does day to day — but it only covers one slice of what can actually put a hospital’s mission, finances, or license to operate at risk.
ERM widens the aperture. It asks a single governance structure to track risk across every domain that could produce a material loss — not just a bad clinical outcome, but a ransomware attack, a failed bond covenant, a Joint Commission accreditation finding, a key-physician departure, or a burst pipe in an OR suite — and to weigh those risks against each other using one shared scale, so a hospital board isn’t choosing between apples-and-oranges risk reports from six different department heads.
ERM vs. clinical risk management: the scope difference
The distinction that trips people up is that ERM does not replace clinical risk management — it contains it as one domain among several. A hospital’s traditional risk management office, focused on adverse events, claims, and patient-safety-adjacent liability, maps almost entirely onto the Clinical/Patient Safety domain below. ERM is the superset: the same clinical risk data still gets collected and investigated the same way (through root cause analysis for sentinel events and surveillance programs for adverse drug events, for example), but it now sits on a risk register next to a cybersecurity exposure or a bond-covenant risk, scored on the same likelihood/severity scale, and reported to the same committee.
That matters for two practical reasons. First, resource allocation: a board weighing a $2M investment in EHR downtime resilience against a $2M investment in a new fall-prevention program can’t make that call sensibly if one risk lives in an IT report and the other in a quality report that never reach the same table. Second, correlated risk: many real losses cross domain lines — a ransomware attack (technology) that delays surgeries (clinical) and triggers breach-notification costs and regulatory exposure (legal/regulatory) all at once. A program organized strictly around departmental silos tends to catch each piece separately, late, and without anyone owning the combined exposure.
The ERM risk-domain taxonomy
ASHRM’s enterprise risk management guidance for healthcare organizes risk into eight domains. They are not eight separate programs with eight separate leaders — they are eight lenses a single ERM committee uses to make sure nothing falls through the gap between departments’ usual reporting lines.
| Domain | What it covers in a hospital |
|---|---|
| Clinical/Patient Safety | Adverse events, sentinel events, medication errors, HAIs, diagnostic error — the traditional core of hospital risk management. |
| Operational | Staffing shortfalls, supply-chain disruption, patient flow/boarding, credentialing lapses, process breakdowns that don’t necessarily involve a patient-safety event. |
| Strategic | Merger/affiliation risk, service-line decisions, competitive and market position, reputational exposure from a strategic misstep. |
| Financial | Reimbursement changes, payer mix shifts, bond covenants, revenue-cycle exposure, uninsured/self-pay volume. |
| Human Capital | Workforce shortages, burnout and turnover, workplace violence, labor relations, succession gaps in key clinical or leadership roles. |
| Legal/Regulatory | CMS Conditions of Participation, accreditation findings, EMTALA, fraud-and-abuse exposure, employment law, contract risk. |
| Technology | Cybersecurity and ransomware, EHR downtime, medical-device interoperability and cybersecurity, AI/algorithmic tools in clinical use. |
| Hazard | Fire, natural disaster, utility failure, workplace injury exposure — the more traditional “property and casualty” risks an insurance program is built around. |
Two things are worth flagging about this list. It is a lens, not an org chart — the same underlying event can, and often does, touch three or four domains at once, which is exactly the point of scoring it once on a shared register rather than three or four times in separate department reports. And it is not identical to the five domains tested on the CPHRM exam (Health Care Operations, Legal and Regulatory, Risk Financing, Claims and Litigation, and Clinical/Patient Safety) — the CPHRM domains describe the body of knowledge a risk-financing-and-claims professional needs to know, while the eight ERM domains describe how risk gets organized and reported at the enterprise level. They overlap heavily but answer different questions: one is a certification’s content outline, the other is a program’s operating structure.
Building a risk register
The risk register is the working document an ERM program actually runs on — a structured inventory, usually a spreadsheet or a module inside a governance, risk, and compliance (GRC) platform, with one row per identified risk. A workable register captures, at minimum:
- Risk description — specific enough to act on (“aging nurse call system with no vendor support past 2027,” not “equipment risk”).
- Domain — which of the eight domains above it’s tagged to (a risk can carry a secondary domain tag if it’s genuinely cross-cutting).
- Risk owner — the named individual accountable for monitoring and mitigating it, not a department.
- Likelihood and severity scores — typically 1–5 scales, scored consistently across domains using the same rubric, so a “4” in technology means the same thing as a “4” in clinical.
- Current controls — what’s already mitigating the risk today.
- Mitigation plan and target date — what closes the gap between current risk level and acceptable risk level, and by when.
- Review date — registers go stale fast; each entry needs an owner-driven review cadence, not a one-time entry.
The register is the raw data. The heat map is how that data gets presented to people who don’t have time to read forty rows of a spreadsheet: a likelihood-by-severity grid (commonly 5×5) with each risk plotted as a dot or numbered marker, colored from green (low/low) through red (high/high). It compresses the register into one visual a board or executive committee can scan in under a minute to see which risks sit in the top-right, unacceptable-and-untreated corner and demand immediate attention versus which sit in the lower-left corner and just need periodic monitoring.
Connecting ERM to board governance
A risk register that only lives with the risk manager doesn’t change how the organization behaves — the reason ERM programs are built around a formal governance structure is to force regular, structured visibility at the level that actually controls resources. The typical structure looks like this:
- Domain owners (CFO for financial, CISO or CIO for technology, chief medical officer or chief quality officer for clinical, and so on) feed risk data up from their area.
- An ERM committee — often chaired by a chief risk officer where the role exists, or by the risk manager reporting to the CFO or general counsel where it doesn’t — consolidates domain input into one register and one heat map, and prioritizes what needs board attention.
- The board quality/risk committee (sometimes a combined quality-and-risk committee, sometimes two committees with a coordination point) receives the consolidated heat map on a regular cadence — typically quarterly — along with narrative on the top risks, what’s changed since the last report, and what mitigation is underway.
- The full board gets an escalated, summarized version, generally limited to the highest-severity items and anything with material financial or reputational exposure.
This is also the structural link between ERM and a hospital’s broader quality infrastructure: the same board committee that reviews the risk heat map is frequently the one that also receives the hospital’s QAPI plan and PIP reporting, and root-cause-analysis findings from a sentinel event should flow into both the clinical quality reporting line and the clinical/patient-safety row of the enterprise risk register — the same underlying event, reported once through the mechanism designed for it, then reflected (not re-investigated) at the ERM level.
Frequently asked questions
Is ERM the same thing as patient safety?
No. Patient safety and clinical risk management make up one domain — Clinical/Patient Safety — within ERM’s eight-domain structure. ERM is the broader enterprise-wide framework; patient safety work continues exactly as it did before, it’s just now one input into a wider register alongside financial, technology, legal, and other domains.
Does a hospital need a chief risk officer to run ERM?
No. Many hospitals and smaller health systems run ERM without a dedicated CRO title — the function is typically housed under the risk manager (often CPHRM-credentialed), reporting to the CFO, general counsel, or directly to a board risk committee. A named CRO becomes more common at larger systems where the coordination burden across domains justifies a full-time enterprise-level role.
How is a risk heat map different from a risk register?
The register is the complete, detailed inventory of individual risks with owners, scores, and mitigation plans. The heat map is a summarized visualization of that same data — a likelihood-by-severity grid — built for board and executive reporting where a scannable picture matters more than row-level detail.
How does ERM relate to the CPHRM certification?
They’re related but not the same thing. CPHRM is an individual credential built around five exam domains (Health Care Operations, Legal and Regulatory, Risk Financing, Claims and Litigation, Clinical/Patient Safety) that describe what a risk-financing-and-claims professional needs to know. ERM is a program-level framework built around eight domains that describe how an organization structures and reports risk. A CPHRM holder is well-positioned to run an ERM program, but the two are a credential and an operating model, not the same taxonomy.
