Why the Same System Fails in One Hospital and Works in Another

I have been thinking about a question that the standard IS adoption frameworks do not answer cleanly: why does the same system, same vendor, same feature set, same implementation methodology, succeed dramatically in one organization and fail quietly in another? TAM tells you about perceived usefulness and ease of use. TOE tells you to look at technology, organization, and environment. But neither of those explains the hospital where the EHR rollout produced measurable improvements in care coordination and the hospital across town where the same EHR produced workarounds, physician complaints, and data quality problems that outlasted the implementation project by years.

The gap is usually culture, and culture operates below the level where most IS implementations are designed.

Edgar Schein, writing in the 1980s, proposed a model of organizational culture that I find more analytically useful than the usual "culture is values and norms" framing. I want to be clear that I did not find Schein in my local study materials, so these claims come from my reading of the broader organizational theory literature and should be taken with that hedge. But Schein's argument, as I understand it, is that culture exists at three levels. The surface level is artifacts: visible things like the physical workspace, the organization's stated mission, the dress code, the jargon people use. Below that are espoused values: the beliefs and rules that members of the organization say they hold, the official answer to "what do we believe here?" Deepest is what Schein called basic assumptions: the taken-for-granted beliefs that operate unconsciously, that shape how people perceive and respond to situations without ever being stated.

IS adoption runs into basic assumptions all the time, and the mismatch is almost never named directly.

The hospital EHR case is the clearest example I know. Hospitals routinely espouse patient data sharing. That is the official value: "we are a collaborative care environment, information follows the patient, we break down silos." But in many hospital cultures, especially among physicians who trained in eras when clinical judgment was the primary currency of professional status, information is power. The attending who knows the patient's history, who has built the relationship, who carries the context of previous decisions, that attending's authority is partly constituted by that information asymmetry. An EHR that makes all of that information immediately available to every provider on the care team, that surfaces a nurse's note alongside a physician's note with no visual hierarchy of authority, is not just a workflow tool. It is a challenge to a basic assumption about how authority and expertise are organized in clinical settings. The physician who resists the EHR is often not resisting the technology. They are defending a basic assumption that the technology threatens.

The national culture dimension adds a layer that IS researchers have worked to document. Hofstede's framework, developed from cross-national survey data, identifies dimensions like power distance (the degree to which less powerful members of an organization accept that power is distributed unequally) and uncertainty avoidance (the degree to which members of a culture feel threatened by ambiguous or unknown situations and try to avoid them). I want to hedge the specific Hofstede claims: I did not find Hofstede in my local study materials, and country-level scores change across editions of the research, so I would not cite specific numbers. But the general pattern that high power distance cultures tend to show different IS adoption behaviors from low power distance cultures is one that IS researchers have found repeatedly, and it makes theoretical sense. A system that flattens reporting hierarchies, that makes subordinate performance data visible to senior leaders in real time, will be received very differently in a high power distance culture than in one where flat hierarchies are the norm. The technical capability is the same. The cultural reception is not.

The practical implication is uncomfortable. If culture operates at the level of basic assumptions that are unconscious and taken for granted, then the standard implementation playbook, stakeholder analysis, change management, training, communication plans, does not reach the layer where resistance lives. You can train physicians on the EHR until they can navigate every menu without thinking. That training does not touch the basic assumption that clinical authority is constituted partly by information control. The gap between the espoused value (we share information) and the basic assumption (information is authority and authority belongs to the attending) will produce workarounds, selective documentation, dual-system behavior, and passive non-compliance that no amount of training addresses.

What does work, at least partially, is when the IS implementation is designed by people who have taken the time to understand what the basic assumptions actually are, as opposed to what the espoused values say they are. This is slower and more expensive than the standard methodology, and it requires a different kind of organizational diagnosis than most IS implementations budget for. It means conducting interviews not just about workflow requirements but about what people actually believe, what they are actually protecting, what they would lose if the system worked the way the designers intended. It means accepting that what people say in a stakeholder meeting and what they actually do when the system goes live are two different things, and that the difference is not dishonesty but the gap between espoused values and basic assumptions.

The success stories I have seen tend to share a few features. First, the implementation team included people who understood the specific professional culture involved, not just the technology. In healthcare, this usually means clinical informatics professionals who have worked in care delivery settings, who understand why physicians resist, and who can distinguish between legitimate workflow objections and cultural resistance to information democratization. Second, the early design process surfaced conflicts between what the system was designed to do and what the organization's basic assumptions would allow it to do, before those conflicts became live implementation failures. Third, the system was adapted to accommodate some basic assumptions while the organization developed processes to address others over time, rather than treating culture as a change management problem that training would resolve.

That last point is the hardest one. Culture cannot be changed by a project. It changes slowly, through accumulated experience, through leadership modeling, through the gradual shift of basic assumptions as the people who hold them are replaced by people who grew up in different environments. A healthcare system that trains its medical students on electronic records from day one is building a different set of basic assumptions about information and authority than one that introduced EHRs to an established clinical culture. The basic assumption problem in IS adoption is, at least in part, a generational one. The question is whether the system can survive long enough for the cultural context to shift.