ASF Standards · Hospital · Standard 17
Standard 17 — Enterprise & Multi-Site Governance
Criteria in this standard
17.1 — Governance Structure Defines Authority Between Central and Site-Level Leadership
17.2 — Incident Learning Is Genuinely Shared Across Sites, Not Siloed
17.3 — Clinical Policy Is Standardized Across Sites, With Any Local Variation Explicitly Justified
17.4 — Credentialing and Privileging Are Centrally Verified and Consistently Recognized
17.5 — Central Resource and Staffing Decisions Are Evaluated for Site-Level Patient Safety Impact
17.6 — Site-Level Quality Data Is Genuinely Reviewed by Central Governance
17.2 — Incident Learning Is Genuinely Shared Across Sites, Not Siloed
17.3 — Clinical Policy Is Standardized Across Sites, With Any Local Variation Explicitly Justified
17.4 — Credentialing and Privileging Are Centrally Verified and Consistently Recognized
17.5 — Central Resource and Staffing Decisions Are Evaluated for Site-Level Patient Safety Impact
17.6 — Site-Level Quality Data Is Genuinely Reviewed by Central Governance
17.1
Governance Structure Defines Authority Between Central and Site-Level Leadership
Non-Negotiable
For an organization operating multiple sites, explicit, documented governance defines which decisions belong to central/corporate leadership and which belong to site-level leadership, with no genuine ambiguity about who holds authority for a given decision — not an informal or assumed division that leaves real gaps when a decision actually needs to be made.
In plain terms: It’s written down, clearly, who decides what between the head office and each hospital — not an unwritten understanding that falls apart the moment a real decision needs making quickly.
| Applicability | Scope |
|---|---|
| Applies to | Organizations operating two or more hospital sites under shared governance |
Why this matters
An informal or assumed division of authority between central and site-level leadership can function adequately during routine operations, but genuinely breaks down exactly when it matters most — during an urgent decision where different people hold different assumptions about who actually has the authority to decide. A documented structure that site leadership can articulate clearly, rather than one that exists only as a policy document rarely consulted, provides considerably more real protection against the specific risk of a decision stalling, or being made by the wrong party, during a genuine time-sensitive situation.
What good looks like
- The division of authority is explicitly documented, not assumed or informal.
- Site leadership can clearly identify who holds authority for a specific decision type.
- A defined escalation path exists for genuinely unclear decision ownership.
Common failure modes
- Authority division exists informally, understood differently by different people.
- Site leadership can’t confidently identify decision ownership when asked directly.
- No defined escalation path exists for a genuinely ambiguous decision.
Worked example
In practice
A multi-site hospital network reviewing its governance clarity.
BeforeSite leadership generally understood that major capital decisions sat with central leadership, but the actual boundary — what counted as “major” versus a decision site leadership could make independently — existed only as an informal shared understanding, interpreted differently across sites.
ActionThe network built an explicit, documented decision-rights matrix specifying exactly which decision types sit with central leadership, which sit with site leadership, and a defined escalation path for genuinely unclear cases.
AfterThe Monitor asked site leadership at two different locations to describe who held authority for a specific decision type, and received consistent, confident answers matching the documented matrix. Criterion verified.
If you are starting from zero — do this first
- Document an explicit decision-rights matrix between central and site-level leadership.
- Test whether site leadership can confidently articulate the division when asked.
- Build a defined escalation path for genuinely ambiguous decision ownership.
The most common mistake: Relying on an informal, shared understanding of decision authority that’s actually interpreted differently across different sites, rather than an explicit, documented structure everyone can consistently reference.
Self-assessment questions
1. Is the division of authority between central and site-level leadership explicitly documented, not assumed or informal? — A written, specific division, not an unwritten understanding that can be interpreted differently by different people.
Evidence: Decision-rights matrix
Evidence: Decision-rights matrix
2. Can site leadership clearly identify who holds authority for a specific type of decision when asked? — A genuine test of whether the documented structure actually translates into practical clarity for the people who need it.
Evidence: Site leadership interview
Evidence: Site leadership interview
3. Is there a defined escalation path when a decision’s ownership is genuinely unclear? — Even a well-documented structure can encounter an edge case; a defined path for resolving ambiguity matters.
Evidence: Escalation path documentation
Evidence: Escalation path documentation
Common reasons for a PARTIAL answer
- A matrix exists but hasn’t been actively communicated to all site leadership.
- Most decision types are covered but an escalation path for edge cases is missing.
Implementation plan
| When | What |
|---|---|
| Week 1 | Draft an explicit decision-rights matrix across major decision categories. |
| Week 2 | Communicate and verify understanding with site leadership. |
| Week 3 | Build a defined escalation path for ambiguous cases. |
| Ongoing | Review and update the matrix as the organization evolves. |
How the Monitor verifies this
| Method | What | Detail |
|---|---|---|
| ASK | Site leadership interview | Asks site leadership at more than one location to describe who holds authority for a specific decision type, checking for consistent answers. |
Evidence base
Institute for Healthcare Improvement. Framework for Effective Board Governance of Health System Quality. Boston: IHI; 2018.
17.2
Incident Learning Is Genuinely Shared Across Sites, Not Siloed
Core
A serious incident identified at one site triggers a genuine review and dissemination process reaching every other site under the same governance structure, with lessons learned actually reaching relevant staff elsewhere in the network — not confined to the originating site as though it carries no relevance to the rest of the organization.
In plain terms: When something serious goes wrong at one hospital, the lesson genuinely reaches the other hospitals too — not stuck at the site where it happened as if the rest of the network has nothing to learn from it.
| Applicability | Scope |
|---|---|
| Applies to | Organizations operating two or more hospital sites under shared governance |
Why this matters
A multi-site network’s genuine advantage lies partly in the ability to learn once and apply that learning everywhere — an incident confined to the originating site, with no real process for reaching other locations, forfeits that advantage and leaves other sites exposed to a risk already identified and understood elsewhere in the same organization. A pattern that’s invisible when each site’s incidents are viewed in isolation can become genuinely visible once incidents are actually aggregated and reviewed at the network level, which is a distinct and additional value beyond single-site incident review.
What good looks like
- A defined process genuinely moves a serious incident’s lessons to other sites.
- Staff at other sites actually receive and register relevant incident learning.
- A pattern across multiple sites’ incidents gets identified and addressed network-wide.
Common failure modes
- Incident review and learning stay confined to the originating site.
- Learning is technically distributed but not genuinely received or absorbed elsewhere.
- Cross-site patterns go unidentified because incidents are reviewed only in isolation.
Worked example
In practice
A network reviewing its cross-site incident learning process.
BeforeA serious medication error at one site triggered a thorough root-cause review at that location, but the findings and resulting process change were never actually communicated to the other sites in the network, which continued operating under the same vulnerable process.
ActionThe network built a defined cross-site incident learning process, with serious incidents reviewed at the network level and relevant findings actively disseminated to clinical leadership at every other site, with confirmation of receipt tracked.
AfterThe Monitor asked clinical leadership at a different site about a recent serious incident elsewhere in the network, and received a genuine, specific description of the learning that had reached them. Criterion verified.
If you are starting from zero — do this first
- Build a defined process for a serious incident to trigger network-wide review.
- Build an active dissemination step with confirmation of receipt at other sites.
- Build a periodic cross-site pattern review at the network level.
The most common mistake: Treating incident review and learning as a single-site activity, with findings and process changes never actually reaching other sites that face the identical underlying risk.
Self-assessment questions
1. Is there a defined process for a serious incident at one site to genuinely reach other sites in the network? — A real, functioning cross-site process, not an assumption that lessons will somehow travel informally.
Evidence: Cross-site incident learning process documentation
Evidence: Cross-site incident learning process documentation
2. Do staff at other sites actually receive and register relevant incident learning, not merely have it technically distributed? — Genuine receipt and understanding, not just an email sent with no confirmation it was read or absorbed.
Evidence: Site leadership interview
Evidence: Site leadership interview
3. Does a pattern across multiple sites’ incidents get identified and addressed at the network level? — A pattern invisible at any single site may only become visible when incidents are genuinely aggregated across the network.
Evidence: Network-level pattern review record
Evidence: Network-level pattern review record
Common reasons for a PARTIAL answer
- Dissemination happens but receipt confirmation isn’t consistently tracked.
- Individual incidents are shared but a genuine pattern-level review doesn’t happen regularly.
Implementation plan
| When | What |
|---|---|
| Week 1 | Review current practice for cross-site incident communication. |
| Week 2 | Build a defined network-wide dissemination process with receipt tracking. |
| Week 3 | Build a periodic cross-site pattern review. |
| Ongoing | Apply the process to each new serious incident. |
How the Monitor verifies this
| Method | What | Detail |
|---|---|---|
| ASK | Cross-site interview | Asks clinical leadership at a site other than where an incident occurred to describe the learning that reached them, checking for genuine specificity. |
Evidence base
World Health Organization. Patient Safety Incident Reporting and Learning Systems. Geneva: WHO; 2020.
17.3
Clinical Policy Is Standardized Across Sites, With Any Local Variation Explicitly Justified
Core
Core clinical policies are standardized across every site in the network, with any permitted local variation explicitly documented and specifically justified — not silent, unexplained drift between sites that leaves patients receiving genuinely different standards of care depending on which site they visit.
In plain terms: The core rules for clinical care are genuinely the same across every hospital in the network — and if one site genuinely needs to do something differently, that’s written down and explained, not a quiet, unexplained gap from what the policy actually says.
| Applicability | Scope |
|---|---|
| Applies to | Organizations operating two or more hospital sites under shared governance |
Why this matters
A patient’s standard of care shouldn’t genuinely depend on which site within the same organization they happen to visit — unexplained drift between sites, where core clinical policy is nominally shared but actually followed differently at different locations, undermines the basic premise that a network provides a consistent standard. Permitted local variation can be entirely legitimate, reflecting genuine differences in site capability or patient population, but the critical distinction is between a documented, justified variation and silent, unexplained drift that nobody has actually examined or approved.
What good looks like
- Core clinical policies are genuinely standardized across sites.
- Any permitted local variation is explicitly documented and specifically justified.
- A periodic process checks that sites genuinely still follow the standardized policy.
Common failure modes
- Sites independently drift from shared policy without documentation or review.
- Variation exists but isn’t explicitly justified or formally approved.
- Standardization is assumed to persist without any periodic verification.
Worked example
In practice
A network reviewing clinical policy consistency across sites.
BeforeA core infection control policy was nominally shared network-wide, but an audit found one site had quietly modified its actual practice over time in response to local supply constraints, with the variation never documented, reviewed, or approved at the network level.
ActionThe network built a formal variation-request process requiring any site-level deviation from core policy to be explicitly documented and approved, alongside a periodic audit comparing actual practice at each site against the standardized policy.
AfterThe Monitor reviewed the periodic audit findings and confirmed any variation found was documented and formally approved, with no unexplained drift remaining. Criterion verified.
If you are starting from zero — do this first
- Confirm core clinical policies are genuinely shared and current across sites.
- Build a formal variation-request process for any site-level deviation.
- Build a periodic audit comparing actual site practice against standardized policy.
The most common mistake: Assuming that a policy shared on paper across the network is actually being followed identically at every site, without a periodic audit that would reveal quiet, unexplained drift that’s crept in over time.
Self-assessment questions
1. Are core clinical policies genuinely standardized across sites, not left to independently drift at each location? — A shared baseline, not each site quietly developing its own version over time.
Evidence: Policy comparison across sites
Evidence: Policy comparison across sites
2. Is any permitted local variation explicitly documented and specifically justified, not simply tolerated without explanation? — A genuine, documented reason for variation, not an unexplained gap between what’s written and what’s actually practiced at a given site.
Evidence: Variation-request record
Evidence: Variation-request record
3. Is there a periodic process for checking that sites genuinely still follow the standardized policy, not assumed to remain aligned indefinitely? — Standardization can erode over time without active checking.
Evidence: Periodic audit record
Evidence: Periodic audit record
Common reasons for a PARTIAL answer
- A variation process exists but isn’t consistently used by every site.
- Periodic audits happen but aren’t consistently followed up when drift is found.
Implementation plan
| When | What |
|---|---|
| Week 1 | Compare current practice across sites for core clinical policies. |
| Week 2 | Build a formal variation-request and approval process. |
| Week 3 | Build a periodic cross-site policy adherence audit. |
| Ongoing | Apply the audit on a defined schedule and follow up on findings. |
How the Monitor verifies this
| Method | What | Detail |
|---|---|---|
| DOCUMENT | Cross-site policy comparison | Compares actual clinical practice at two or more sites against the standardized core policy for unexplained variation. |
Evidence base
Institute for Healthcare Improvement. Framework for Effective Board Governance of Health System Quality. Boston: IHI; 2018.
17.4
Credentialing and Privileging Are Centrally Verified and Consistently Recognized
Non-Negotiable
A clinician’s credentials and clinical privileges are verified through a single, central process and consistently recognized across every site where that clinician practices, with no site allowing a clinician to practice without their current credentials and privileges actually being confirmed for that specific site.
In plain terms: A clinician’s credentials are checked once, centrally, done properly — and every site actually confirms, before that clinician practices there, that their credentials and privileges are current, rather than just assuming the central check automatically covers everywhere.
| Applicability | Scope |
|---|---|
| Applies to | Organizations operating two or more hospital sites under shared governance |
Why this matters
A single, centralized credentialing process, done properly, is considerably more reliable than independent, inconsistent verification repeated differently at each site — but centralization alone isn’t sufficient without each specific site also confirming current privileges before a clinician practices there, closing the real gap that can otherwise occur between central records and what’s actually happening at a given location. A privilege suspension at one site that fails to genuinely propagate to every other site where that clinician practices represents a serious, specific risk this criterion exists to prevent.
What good looks like
- Credentialing verification is genuinely centralized, not inconsistently repeated.
- Every site confirms a clinician’s current privileges before they practice there.
- A privilege change or suspension at one site genuinely propagates to all sites.
Common failure modes
- Credentialing is inconsistently verified or skipped at some sites.
- A site assumes central verification automatically covers their specific location.
- A privilege suspension at one site fails to reach other sites where the clinician practices.
Worked example
In practice
A network reviewing its credentialing process across sites.
BeforeA clinician’s privileges were suspended at one site following a disciplinary review, but no reliable process existed to propagate that suspension to other sites where the clinician also practiced, creating a genuine gap.
ActionThe network built a centralized credentialing database with real-time visibility across all sites, requiring every site to confirm current status against that central record before a clinician practices, with any status change automatically flagged network-wide.
AfterThe Monitor tested the system by checking whether a simulated status change at one site was genuinely visible and actionable at another site. Criterion verified.
If you are starting from zero — do this first
- Build or confirm a single, centralized credentialing verification process.
- Require every site to confirm current status before a clinician practices there.
- Build a real-time propagation mechanism for any privilege status change.
The most common mistake: Assuming a centralized credentialing process automatically covers every site, without a specific, confirmed mechanism ensuring a status change — particularly a suspension — genuinely reaches and is acted upon at every site where that clinician practices.
Self-assessment questions
1. Is credentialing verification genuinely centralized, not independently and inconsistently repeated or skipped at each site? — A single, reliable verification process, not a patchwork where sites verify differently or not at all.
Evidence: Credentialing process documentation
Evidence: Credentialing process documentation
2. Does every site confirm a clinician’s current privileges before they practice there, not assume central verification covers every site automatically? — A specific, site-level confirmation step, even within a centralized system, closes a genuine potential gap.
Evidence: Site-level confirmation record
Evidence: Site-level confirmation record
3. Is there a reliable process for a privilege change or suspension at one site to genuinely propagate to all sites where that clinician practices? — A suspension that doesn’t actually reach every site where the clinician practices creates a real, serious gap.
Evidence: Propagation test record
Evidence: Propagation test record
Common reasons for a PARTIAL answer
- Centralized verification exists but site-level confirmation isn’t consistently performed.
- Propagation of a status change relies on manual notification rather than a reliable system.
Implementation plan
| When | What |
|---|---|
| Week 1 | Review current credentialing consistency across all sites. |
| Week 2 | Build or confirm a centralized credentialing verification process. |
| Week 3 | Build a site-level confirmation requirement and propagation mechanism. |
| Ongoing | Test propagation periodically to confirm genuine function. |
How the Monitor verifies this
| Method | What | Detail |
|---|---|---|
| DOCUMENT | Credentialing system test | Tests whether a status change at one site is genuinely visible and actionable at another site in the network. |
Evidence base
Joint Commission International. Accreditation Standards for Hospitals. 7th ed. Oak Brook, IL: JCI; 2020.
17.5
Central Resource and Staffing Decisions Are Evaluated for Site-Level Patient Safety Impact
Core
A central decision affecting staffing, equipment, or resource allocation at a specific site is evaluated for its patient safety impact at that site before being finalized, with a documented process for that evaluation — not a purely network-level financial or operational decision made without genuine consideration of site-level patient safety consequences.
In plain terms: Before the head office makes a decision affecting staffing or resources at a specific hospital, the actual patient safety impact at that hospital is genuinely considered — not a purely financial or operational decision made with no real input from the people who’d see the consequences.
| Applicability | Scope |
|---|---|
| Applies to | Organizations operating two or more hospital sites under shared governance |
Why this matters
A central resource decision made purely on network-level financial or operational grounds, without genuine consideration of the specific patient safety impact at an individual site, risks optimizing for the network as a whole while creating a real, serious gap at a specific location. Site-level clinical leadership holds genuine, specific knowledge about what a given resource reduction or reallocation would actually mean for patient safety at their site — knowledge that’s lost if that leadership is only informed after the decision has already been finalized, rather than having a real voice before it’s made.
What good looks like
- A documented process evaluates patient safety impact before a central decision is finalized.
- Site-level clinical leadership has a genuine voice in that evaluation beforehand.
- A real mechanism exists for a site to flag a concern and have it genuinely reconsidered.
Common failure modes
- Resource decisions are made on purely financial or operational grounds.
- Site leadership is informed of a decision only after it’s already finalized.
- A site’s flagged safety concern has no real avenue for reconsideration.
Worked example
In practice
A network considering a staffing reduction at one site.
BeforeA staffing reduction at one site was decided centrally based on network-level financial targets, with site clinical leadership notified of the decision after it had already been finalized, with no genuine opportunity to flag a specific patient safety concern beforehand.
ActionThe network built a required patient safety impact evaluation step, genuinely completed before a central resource decision affecting a specific site is finalized, with site clinical leadership formally consulted as part of that evaluation.
AfterThe Monitor reviewed a recent resource decision and found a documented patient safety evaluation genuinely completed beforehand, with site leadership input recorded. Criterion verified.
If you are starting from zero — do this first
- Build a required patient safety impact evaluation step for central resource decisions.
- Build a formal site clinical leadership consultation step before finalization.
- Build a real escalation mechanism for a flagged safety concern.
The most common mistake: Making a central resource decision on purely financial or operational grounds, notifying site leadership only after the decision is already finalized, rather than genuinely consulting them and evaluating patient safety impact beforehand.
Self-assessment questions
1. Is there a documented process for evaluating patient safety impact before a central resource decision affecting a specific site is finalized? — A genuine evaluation step, not a decision made purely on network-level financial or operational grounds.
Evidence: Patient safety impact evaluation record
Evidence: Patient safety impact evaluation record
2. Does site-level clinical leadership have a genuine voice in that evaluation, not merely informed after the decision is already made? — Real input before the decision, not notification after the fact.
Evidence: Consultation record
Evidence: Consultation record
3. Is there a mechanism for a site to flag a safety concern about a central resource decision and have it genuinely reconsidered? — A real, functioning escalation path, not a theoretical right with no actual avenue for reconsideration.
Evidence: Escalation record
Evidence: Escalation record
Common reasons for a PARTIAL answer
- An evaluation process exists but isn’t consistently applied to every central decision.
- Site leadership is consulted but the consultation often happens too late to genuinely influence the outcome.
Implementation plan
| When | What |
|---|---|
| Week 1 | Review current practice for site input on central resource decisions. |
| Week 2 | Build a required patient safety impact evaluation step. |
| Week 3 | Build a formal, timely site consultation and escalation mechanism. |
| Ongoing | Apply the evaluation to every central resource decision affecting a site. |
How the Monitor verifies this
| Method | What | Detail |
|---|---|---|
| DOCUMENT | Resource decision review | Reviews a recent central resource decision affecting a site for documented patient safety evaluation and site consultation before finalization. |
Evidence base
World Health Organization. Global Patient Safety Action Plan 2021–2030. Geneva: WHO; 2021.
17.6
Site-Level Quality Data Is Genuinely Reviewed by Central Governance
Standard
Quality and safety metrics reported upward from each site are genuinely reviewed by central governance, with real follow-through action when a metric indicates a problem — not merely collected and filed as a reporting formality with no actual review or consequence.
In plain terms: Quality data from each hospital genuinely gets looked at by the people running the network, and when something looks wrong, something actually happens about it — not data flowing upward into a file nobody really examines.
| Applicability | Scope |
|---|---|
| Applies to | Organizations operating two or more hospital sites under shared governance |
Why this matters
Site-level quality data that flows upward into a central repository, but isn’t genuinely reviewed by anyone with authority to act on it, provides the appearance of oversight without the substance — the reporting requirement is technically satisfied, but the protective value central governance oversight is meant to provide doesn’t actually materialize. A concerning metric that goes unaddressed, because the review that would have caught it never genuinely happened, represents a specific, serious gap between what a network’s governance structure claims to provide and what it actually delivers for patients at an individual site.
What good looks like
- Site-level quality data is genuinely reviewed by central governance, not just archived.
- A concerning metric from a specific site triggers a genuine follow-through action.
- Central governance can cite a specific, recent example of acting on site-level data.
Common failure modes
- Quality data is collected and filed without a genuine review process.
- A concerning metric is noted but no actual follow-through action occurs.
- Central governance can’t cite a concrete, recent example of acting on site data.
Worked example
In practice
A network reviewing how central governance engages with site-level quality data.
BeforeEach site submitted monthly quality metrics to a central dashboard, but review of the dashboard by central governance was inconsistent, and a sustained decline in one metric at a specific site had gone unaddressed for several reporting cycles.
ActionThe network built a defined, scheduled central governance review of site-level quality data, with a required documented action for any metric crossing a defined concerning threshold, tracked to resolution.
AfterThe Monitor asked central governance for a specific, recent example of acting on site-level quality data and received a concrete, documented example. Criterion verified.
If you are starting from zero — do this first
- Build a defined, scheduled central governance review of site-level quality data.
- Set defined thresholds that require a documented follow-through action.
- Track follow-through actions to resolution, not just to initial acknowledgment.
The most common mistake: Treating a central quality dashboard as oversight in itself, without a genuine, scheduled review process and a required follow-through action when a metric actually indicates a problem.
Self-assessment questions
1. Is site-level quality data genuinely reviewed by central governance, not simply collected and archived? — A real review process, not data flowing upward into a repository nobody actually examines.
Evidence: Governance review schedule and minutes
Evidence: Governance review schedule and minutes
2. Does a concerning metric from a specific site trigger a genuine follow-through action, not go unaddressed? — Detection without a real response provides limited protective value for patients at that site.
Evidence: Follow-through action record
Evidence: Follow-through action record
3. Can central governance identify, when asked, a specific recent example of acting on site-level quality data? — A concrete, recent example suggests genuine, ongoing practice rather than a theoretical process.
Evidence: Governance interview
Evidence: Governance interview
Common reasons for a PARTIAL answer
- A review schedule exists but isn’t consistently followed in practice.
- Follow-through actions are initiated but not consistently tracked to resolution.
Implementation plan
| When | What |
|---|---|
| Week 1 | Review current central governance engagement with site-level quality data. |
| Week 2 | Build a defined, scheduled review process with concerning-metric thresholds. |
| Week 3 | Build a follow-through action tracking process through to resolution. |
| Ongoing | Apply the review on schedule and track outcomes. |
How the Monitor verifies this
| Method | What | Detail |
|---|---|---|
| ASK | Governance interview | Asks central governance for a specific, recent example of reviewing and acting on site-level quality data. |
Evidence base
Institute for Healthcare Improvement. Framework for Effective Board Governance of Health System Quality. Boston: IHI; 2018.