EPI common mistakes
EPI · Understand the traps and how to avoid them.
Treating performance improvement as a purely technical exercise: writing answers that jump straight to a tool (PDSA, Lean, control chart) without first stating the strategic aim, the governing body that authorized the work, and how success will be reported upward.
Candidates study improvement methods in isolation and rehearse tool names, so under time pressure the tool becomes the answer. They also underestimate how much of the exam frames improvement as a governed, accountable activity rather than an isolated project.
What to do instead
Before choosing any method, write one sentence naming the strategic objective, one naming who owns and sponsors the work, and one naming the reporting line and cadence. Only then pick the tool. Practice by taking five past scenarios and drafting that three-sentence frame in under two minutes each.
Describing governance structures generically ('establish a steering committee') instead of specifying composition, decision rights, escalation thresholds, and how the committee links to the operational improvement teams.
Governance content feels like common sense, so candidates produce plausible-sounding but unspecified answers. They have not practiced articulating who decides what, which is exactly what distinguishes a strong answer.
What to do instead
Build a reusable one-page template: chair, core members, standing attendees, quorum, decisions reserved to the body versus delegated, escalation trigger, and meeting cadence. Fill it out for three different organizational sizes (single site, multi-site, national program) and reuse the structure in answers.
Confusing measures with data sources: proposing 'patient satisfaction' or 'readmission rate' as the measure without defining numerator, denominator, inclusion criteria, collection point, and frequency.
Operational definitions are tedious and candidates assume the reader shares their mental model. Exam scenarios often hinge on ambiguity in the measure definition, and a vague measure cannot be defended.
What to do instead
For every measure you propose, write the operational definition using a fixed template: numerator, denominator, exclusions, data source, collector, frequency, owner, and target. Practice converting five vague measure names into complete definitions.
Selecting only outcome measures and omitting process and balancing measures, then failing to notice when a scenario describes improvement in one area accompanied by deterioration elsewhere.
Outcome measures are the most visible and easiest to recall. Candidates forget that a balanced family of measures is a design requirement, not a nicety, and miss the balancing-measure signal embedded in the scenario.
What to do instead
Memorize the trio: outcome, process, balancing. For any intervention described, force yourself to name one of each before writing the answer, and explicitly state what unintended consequence you would monitor and at what threshold you would act.
Drawing a process map that documents the official procedure rather than the actual flow, and then analyzing the idealized version.
Candidates default to the formally documented pathway because it is what they can recall or infer. Real improvement work depends on observing variation and workarounds, and scenarios frequently plant a discrepancy between policy and practice.
What to do instead
Always state explicitly that the map will be built from direct observation and front-line walkthroughs, note where the map diverges from documented policy, and list the specific observation points (who, where, how many cases). Make 'observed versus documented' a standing line in every process-analysis answer.
Treating root cause analysis as a single technique: applying a fishbone diagram to a problem that requires event-timeline reconstruction, or stopping at the first plausible cause without testing it.
Fishbone and 'five whys' are the most rehearsed tools, so they become the default. Candidates also conflate a retrospective adverse-event investigation with ongoing process variation analysis.
What to do instead
Match the tool to the question: timeline and contributing-factor analysis for a specific event, stratification and Pareto for variation across many cases, and process mapping for design flaws. Always include a step where candidate causes are verified against data before action is taken.
Applying PDSA as a linear checklist with a single large-scale pilot, rather than as rapid, small-scale, iterative cycles with predictions stated in advance.
Textbook descriptions compress the method into four steps, and candidates lose the discipline of prediction, small scale, and iteration. Large pilots feel more rigorous and more 'real world'.
What to do instead
In every answer, state the prediction before the test, justify the deliberately small scale of the first cycle, and describe what would be adapted, adopted, or abandoned based on the result. Include at least two sequential cycles so the iterative character is visible.
Presenting a single improvement methodology as universally applicable and dismissing or ignoring the organization's existing capability and context.
Candidates often specialize in one framework and defend it reflexively. Exam scenarios deliberately include context cues (low maturity, unionized workforce, regulatory constraints) that should change the recommended approach.
What to do instead
Practice writing a short 'context read' before recommending a method: current capability, prior improvement history, regulatory constraints, and available data. Then justify the method choice against those four factors and state what you would do differently if capability were lower.
Treating change management as a communication plan appended at the end, and describing stakeholders only as audiences to be informed rather than as parties with interests, influence, and potential to block.
Communication is familiar and easy to write about, so it crowds out the harder work of stakeholder analysis, resistance diagnosis, and role redesign. Candidates also default to 'send a newsletter' style tactics.
What to do instead
Structure every change answer as: stakeholder analysis (interest, influence, stance), specific engagement actions per group, explicit resistance hypotheses with a test for each, and the structural enablers (roles, incentives, training, leadership behaviors) that make the new way the default. Put communication last, as one tactic among several.
Presenting analysis results without stating the decision they inform, the uncertainty around them, and the limitations of the data, and ignoring the ethical and privacy constraints on using that data.
Candidates equate analytical rigor with statistical technique and forget that the exam tests judgment about use. Scenarios often embed small denominators, missing data, or identifiable patient information that should change the recommendation.
What to do instead
End every analytical answer with three short statements: the decision this informs, the main limitation or source of uncertainty, and the data governance or privacy safeguard applied. Practice spotting small-number and identifiability traps in scenario data before choosing a method.