Policies don’t create structure. Systems do.

Ask almost any health care organization how things work, from a two-provider concierge clinic to a regional group, and the answer arrives as a binder, a shared drive, or an intranet full of policies. HIPAA. Cal/OSHA. Coding. Credentialing. Incident reporting. The shelf is heavy.

Then ask a frontline team member how a specific thing gets done, such as what happens when a new patient calls to schedule. The answer comes from memory and experience. The gap between what is written and what is done is where operational health lives, and it is one of the most overlooked sources of cost and risk in health care.

A policy describes what should happen. A system makes it happen by default.

Policy and system are different tools

A policy is a statement of intent. It is necessary and it is not sufficient. A system is the machinery that produces the outcome the policy describes, reliably, regardless of who is on shift: the workflows, defaults, tools, checks, and handoffs. The policy says every patient receives a follow-up call within forty eight hours of discharge. The system decides whether that call happens for the patient discharged Friday afternoon while the usual coordinator is out.

Human factors research supports this distinction. When expectations are built into the work system itself, through structured tools, checklists, and design, reliability improves more than when they are stated in documents alone.^1,2

Health care organizations accumulate policies for good reasons. Regulators require them, accreditors review them, and counsel recommends them. California adds its own layer. Cal/OSHA requires covered health care settings to maintain a written workplace violence prevention plan, train on it, and keep a violent incident log, and most other California employers now have a similar obligation.³ The written plan is reviewed. Whether the escalation it describes happens on a short-staffed Tuesday depends on the system underneath.

The three question test

1. Who owns it? A named role, not a name. “Usually Sarah” is a person, not an owner.
2. What triggers it? A defined event, date, or status change. “When someone remembers” is not a trigger.
3. What happens if it does not occur? A visible signal and an escalation path, well before an audit.

Two examples

Why policy-rich organizations plateau

Up to a certain size, usually one location with long-tenured staff, the gap between the binder and the day is closed by people who know what to do. Then something shifts. A second location opens, a long-time manager moves on, or volume outgrows memory. The policies, which were never doing the work, are exposed. Adding more policies and meetings rarely closes the gap, because the need was structure.

Four elements of a system

1. An owner a role with a backup
2. A trigger defined in advance
3. A path documented at point of use
4. A signal visible before the audit

Anything short of these four is intent. With them, it becomes infrastructure.

Starting points

Five ways to put a system underneath every policy.

1. Pick your five most important policies. The ones that protect patients, revenue, or licensure.
2. Apply the three question test to each. Owner, trigger, and what happens if it does not occur.
3. Build one missing system. Choose the policy with the weakest answers and add an owner, trigger, path, and signal.
4. Review your workplace violence plan. Confirm training is current, the incident log is kept, and staff know where to find the plan.
5. Retire what nobody uses. Consolidate duplicate or outdated policies so the binder reflects the practice.

Resources