Your Health System Has Outgrown Hospital Incident Command
Over the past several years, I have been brought into health systems to do a range of specific things. Write an emergency operations plan. Design a tabletop exercise. Assess downtime readiness. Build a training program.
The work is different every time. The conversation is not.
Somewhere in the first few weeks, usually in a room holding people from three or four departments who do not often sit together, the same realization surfaces. The organization has grown into an enterprise. Its emergency management structure has not. It is still built, staffed, and governed as a collection of individual buildings.
In most cases, nobody has said it out loud before.
The doctrine stops at the building
The Hospital Incident Command System is a good piece of work. It gives a facility a common language, a defined structure, and role expectations that people can learn and practice. Paired with federal guidance and the accreditation expectations built on top of it, it has measurably improved how individual hospitals respond.
But read it closely and notice what it describes: a hospital. One Incident Commander. One Emergency Operations Center. One set of Command Staff. One building’s worth of resources, staff, and decisions.
That was the right unit of analysis when it was written. It is not the unit most of my clients operate.
What an enterprise actually looks like
You know what your own organization contains. The part that matters here is what it shares: a single electronic health record instance, a common network and IT infrastructure, a single supply chain, medical staff who practice at more than one site, and corporate leadership over it all.
That shared infrastructure is the point. It is what makes the organization a system rather than a holding company. It is also the reason a disruption rarely stays local anymore.
It is worth being clear about how organizations arrived here, because it explains why the gap is so consistent. Very few health systems were designed. They were assembled through mergers, acquisitions, and affiliations, often over a decade or more. Each transaction brought clinical integration onto the priority list. Governance of finance, IT, supply chain, and medical staff was consolidated because the business case was clear and someone owned the work. Emergency management was not consolidated because no one asked the question and no regulator required it. Each acquired facility retained the program it had when acquired.
A ransomware event does not hit one hospital. It hits the shared record. A regional weather event does not close one facility. It degrades staffing across an entire service area. Supply disruptions, workforce actions, and public health surges, by their nature, manifest at the enterprise level.
When the disruption is enterprise-wide, the response has to be as well. That is where the doctrine goes quiet.
The regulation anticipated this. The operational doctrine did not.
CMS saw this coming. Under 42 CFR 482.15(f), a hospital that is part of a system with multiple separately certified facilities may elect to participate in a unified and integrated emergency preparedness program. The conditions are specific. Each facility must actively participate in developing it. It must account for each facility’s unique circumstances, patient populations, and services. Each facility must be able to demonstrate that it actively uses and complies with the program. It must include a unified plan built on both community-wide and individual facility risk assessments, integrated policies and procedures, a coordinated communication plan, and coordinated training and testing.
So the regulatory permission to operate as an enterprise has existed for years.
What does not exist is an operational model for doing it. There is no enterprise equivalent of HICS. No standard structure above the facility. No defined relationship between facility incident commanders and a system-level command. No agreed vocabulary for the layer in between.
The evidence is not hard to find. ASPR TRACIE published a subject matter expert discussion on this exact question. Read the responses and you find experienced systems describing entirely different homemade approaches. One runs local incident command for single-site events and a corporate-level command for multi-entity events. Another stands up a system information resource center and embeds corporate staff inside hospital emergency operations centers. Another keeps its hospitals operating independently with corporate support layered on top. One participant makes the point plainly: you have to separate an integrated system as CMS defines it from how your system actually wants to be integrated.
That variation is the finding. When capable organizations solve the same problem five different ways, the problem does not yet have a standard answer.
Where the gap shows up
Nobody is in charge above the facility
When a disruption crosses facilities, someone has to make decisions no facility incident commander has the authority to make. Which sites divert. Where scarce staff deploy. Which service lines suspend. What the organization says publicly. Whether to pay a ransom.
It is worth separating two things that often get treated as one. Many systems have coordination. They have a standing call, a distribution list, a group of leaders who know each other and will get on a bridge line within the hour. That is genuinely valuable. But coordination is information sharing among peers. Command is the authority to direct action across them. A system can have excellent coordination and still have no one who can tell a facility to stop doing something.
There is a quick test. Ask an executive team who the enterprise incident commander is. If the answer takes more than a few seconds, or if two people give different answers, the structure does not exist.
When the seat is undefined, it does not stay empty. It gets filled by whoever has the most seniority and the most nerve. I watched a senior executive drive to one of their hospitals during an evacuation and personally take control of air evacuation operations. The intent was admirable. The effect was that the one person who could have been running the enterprise was instead running one tactical function inside one building.
I am a clinically active paramedic, and I recognize that failure from the resuscitation bay. It is the team leader who drops to do chest compressions. The compressions are necessary and the person doing them is competent. But now nobody is watching the rhythm, the airway, the drugs, or the clock. The task gets done. The resuscitation loses its brain.
The most telling detail is not why he did it. I do not know why he did it. It is that he still tells the story with pride. In his memory it is a story about leadership, and told that way it is a good one. That is the problem. A failure remembered as heroism produces no after-action finding, no corrective action, and no change to the structure. It gets retold. And the next time the enterprise seat sits empty, someone will remember that story and do the same thing.
The absence of that seat has clinical consequences that are easy to miss until you look for them. In one system, two emergency departments treated patients from the same hazardous materials exposure event under different treatment protocols. Same system, same exposure, different care depending on which door the patient walked through. It was corrected when an improvised central command identified the divergence and issued updated clinical practice guidelines to every emergency department in the area. The correction worked. It arrived after the fact, because the function that should have caught it had to be invented during the event.
The alternative is not theoretical. During H1N1, a pediatric health system I worked in developed clinical practice guidelines defining which symptoms and what temperature threshold should trigger referral to the emergency department, and published them to its affiliated practices. The criteria deliberately differed from the general-population federal guidance, because a pediatric organization applying its own specialty expertise reached a different and better-fitted answer for the patients it served.
Notice what that required. Someone had the standing to set a clinical standard for practices that did not report to them, and the lever was upstream of the problem. Rather than managing emergency department volume in the emergency department, the system managed who arrived at the door. That is enterprise thinking in a single move, and it is the mirror image of the hazardous materials case. One organization set the standard before an event forced it. The other discovered the divergence in the middle of one.
Emergency management programs are federated by accident
The EM function inside a system is rarely designed as a system function. It accumulates. Each facility hires its own emergency manager, at different times, into whatever reporting line was available.
At one facility the emergency manager reports to the Facilities lead and came out of security and engineering. At another facility in the same system, the emergency manager reports to the Chief Nursing Officer and came out of clinical practice.
Both are competent. Both build defensible programs. They build different ones. The security and engineering background produces a program weighted toward physical plant, access control, and utility failure. The clinical background produces one weighted toward surge, patient movement, and clinical continuity. Their hazard vulnerability analyses emphasize different threats. Their drills test different capabilities. Their quality metrics measure different things.
The consequence is not that either program is weak. It is that the enterprise cannot see itself. You cannot aggregate data that was not collected the same way. Leadership has no comparable picture of readiness across facilities, which means it cannot direct resources to the weakest point, because it cannot identify the weakest point.
Stated plainly: most health systems do not know which of their facilities is least prepared.
IT response sits outside the response structure
In most systems I have worked with, IT operates its own incident response. Its own escalation path, its own leadership, its own severity definitions, its own vocabulary. It is usually a well-run function. It is simply not connected to the emergency management structure.
The clearest symptom is a title collision. Technology operations borrowed the term Incident Commander from its own discipline, so the IT major incident lead is often called the Incident Commander. Emergency management uses the identical title for a different role with different authority. During a cyber event, both people are in the building, both hold the title, and when someone reports that the Incident Commander made a decision, nobody is certain which one they mean.
Worse than the confusion is the resolution some organizations reach. Because the disruption is technical in origin, they place the IT major incident lead in the actual Incident Commander seat.
That is the wrong seat for them, and the reason is not disrespect for the discipline. In a healthcare response, decisions that look technical resolve into clinical risk. Restoration sequence is a clinical prioritization question, not a technical one. Which application returns first determines which service line resumes and which patients wait. An Incident Commander who cannot independently evaluate that consequence is dependent on translation, and translation is exactly what fails under stress and time pressure.
During a significant cyber disruption, clinical operations and technical recovery are the same incident being run by two structures that share no command, no common operating picture, and no agreed set of priorities. The clinical side needs to know what will be available and when. The technical side needs to know what to restore first, and that is a question only clinical leadership can answer.
A dedicated IT disaster response team, integrated into the enterprise incident command structure with defined authority and a defined interface to clinical operations, is one answer. The structure matters more than the name. What matters is that technical response reports into the same command as everything else, and that clinical leadership sets restoration priorities. The answer to a cyber event is not handing command to IT. It is giving IT a real seat within the structure rather than a parallel one beside it.
Communications is not owned until it is already a problem
Everyone agrees risk communication matters. Very few organizations have documented who does it, what the vetting and approval process is, and how it functions during a live response.
There is an irony here. The Public Information Officer is a Command Staff position. The doctrine already puts communications at the command table, reporting directly to the Incident Commander. The box is on the chart.
Here is what its absence costs. During the 2024 CrowdStrike outage, a health system’s IT department sent an enterprise-wide email describing the disruption as a cyber attack. It was not a cyber attack. It was a faulty vendor software update, and the distinction is not academic. The two events carry different obligations, different escalations, and very different implications for staff who are being asked to keep working.
The message went out because IT held its own risk communication capability, separate from the enterprise structure, and because there was no vetting or approval cycle involving the enterprise Incident Commander. Nobody in the path was positioned to challenge the characterization before it reached the whole organization.
The result was substantial confusion that the organization then had to manage, in the middle of a disruption already consuming every available hand. The response created a second incident. And correction is not symmetric. Unsending a message that says the organization is under attack is far harder than sending it, because people remember the first version.
In organizations that take this seriously, marketing and communications staff treat risk communication as a primary responsibility. They train for it, they exercise, and they sit at command from the beginning. Elsewhere, communications has no operational role until a message is mishandled, at which point it arrives urgently and operates outside the incident command structure. That is worse than the original gap. The organization now has two decision authorities during a live event, with different reporting lines and different audiences, and command is undermined at the moment command matters most.
What good looks like
Not a maturity model. Seven conditions you can observe directly.
An enterprise coordination structure that exists on paper before an event, with a named role, defined authority, and a clear relationship to facility incident commanders. Not a conference call habit.
An Incident Commander who already holds authority over the operation, and more than one person qualified to fill the seat.
Explicit decision rights. Which decisions belong to the facility, which escalate, and at what triggers.
IT integrated into the same command structure, with clinical leadership setting restoration priorities.
Communications owned in steady state, staffed by people who have trained and exercised, seated at command from the start rather than after the first bad headline. One approval path for any message that leaves the organization.
Common program elements across facilities. A shared hazard assessment methodology, comparable drill design, and a small set of metrics collected identically everywhere.
Data that aggregates. If facility readiness cannot be compared, the enterprise cannot manage it.
The second condition is the one organizations get wrong most often, and it deserves its own treatment. Who should hold the Incident Commander role, and who should not, is the subject of a separate piece.
Where to start
Two questions, answered honestly, tell most systems where they stand.
First: if a disruption affected three of your facilities simultaneously tomorrow morning, who is in charge, and can everyone name that person?
Second: can you compare readiness across your facilities using data you already collect?
If the first answer is uncertain, you have a structural gap. If the second answer is no, you have a program gap. Most organizations have both, and the two are related. The same facility-level framing produced each of them.
The work from there is narrower than people expect. Define the enterprise structure. Establish decision rights and name who can command. Integrate the two functions that currently sit outside it. Standardize the small number of program elements that need to be comparable. Existing facility plans mostly stay as they are. This is not a rewrite of everything you have built. It is the layer you never built because, until recently, nobody told you it was missing.
Mitigant Risk Solutions works with health systems on enterprise emergency management structure, incident command design, and program integration across multi-facility organizations.
Schedule a 30-minute consultation to discuss where your system sits against the two questions above.
Sources
42 CFR 482.15(f), Condition of participation: Emergency preparedness. eCFR.
CMS Emergency Preparedness Rule: Integrated Healthcare Systems Implications. ASPR TRACIE.
Hospital Incident Command System Guidebook, Fifth Edition, 2014.
