| name | m-and-m |
| description | Morbidity & Mortality conference — structured postmortem after an incident, bug, near-miss, or "wait that wasn't supposed to happen." Produces an M&M-style writeup that goes in incident-log/. Use within 72 hours of a Code Blue, a Sev-1, a regression that reached customers, or any case worth learning from. |
Morbidity & Mortality Conference
Thursdays at 0700, auditorium B. Coffee and pastries from the cafeteria (Lou sends the leftover Danish). Dr. Patricia Holloway (CMO) chairs. Dr. Hal Brennan (Chief of Staff) sits in the front row. Dr. Sól (path) is there if anyone died (or if the prod database did).
The point of M&M is not to identify someone to blame. The point is to identify the failure of system, process, or judgment so the next case turns out differently. Holloway will say this at the start of every conference. She will mean it. She will also know who screwed up.
When to convene M&M
- After every Code Blue (severity-1 / production incident).
- After a near-miss that would have been Code Blue but for luck or a backstop catching it.
- After a bouncing patient (regression that re-opened within 30 days of "fix").
- After any case where a senior person says "we should learn from this."
If you're not sure: convene it. Cheap to hold; expensive to skip.
The presentation format
Every case is presented in this exact order. No editorializing in the H&P. Save opinions for the discussion.
M&M CASE — <date>
─────────────────
PRESENTING: <one-line case summary>
CHIEF COMPLAINT
<what was the symptom that brought it to attention>
HISTORY OF PRESENT ILLNESS
<chronological timeline, neutral tone, with timestamps>
<include: when started, when noticed, what was tried, when resolved>
PAST HISTORY
<relevant prior context: was this area recently changed? known fragile?>
<related incidents: have we seen this before?>
EXAM / OBJECTIVE FINDINGS
<metrics, logs, error rates, customer impact, blast radius>
ASSESSMENT
<root cause, stated plainly>
<contributing factors — each as a separate item>
<was this a system failure, a process failure, or a judgment call?>
PLAN
1. <action item — owner — due date>
2. <action item — owner — due date>
...
DISCUSSION
<what did the team learn? what would we do differently?>
<what would we do *the same*? ← this matters; not every action was wrong>
The four-question framework (Holloway will ask all four)
After the presentation, the room walks through:
- What happened? (Just the facts. No interpretation.)
- What did we think was happening at the time? (Often different from #1; that gap is the lesson.)
- What should we have done differently? (System, process, judgment — name which.)
- What do we change? (Concrete, owned, dated. Not "we should be more careful.")
If question 4 is vague, the M&M was a waste. Don't leave the room without owners and dates.
Categorizing the failure
At CGH we use a three-bucket framework:
- System failure — the tooling/infrastructure made the wrong outcome easy or the right outcome hard. Fix the system. (E.g.: dangerous command had no confirmation; alert wasn't wired.)
- Process failure — the procedure existed but wasn't followed, or the procedure didn't exist. Fix the process. (E.g.: rollback runbook was out of date; no on-call rotation defined for this service.)
- Judgment call — given the information available at the time, the call was reasonable; it just didn't work out. Don't fix the human; fix the information they had. (E.g.: chose to push forward instead of rolling back, based on metrics that turned out to be misleading.)
Most real cases are a mix. Name them all.
Anonymization rules
- Patient identifiers removed from the writeup that goes in
incident-log/.
- Clinician names: removed unless the person consented or the case is purely instructional with no fault attribution.
- Customer names: never.
- Internal tool names: keep — that's part of the lesson.
What the writeup looks like
After M&M, the recorder produces a single file in incident-log/ named YYYY-MM-DD-short-slug.md, in exactly the structure above. Linked from incident-log/README.md.
What gets you escorted out of M&M
- Naming a clinician as "the cause" without naming a system or process that made the failure possible.
- Defending yourself by litigating each timeline point. Save it for peer review.
- Bringing a hot take with no evidence ("I bet it was DNS" — Brennan, multiple times, often correct, still gets the look from Holloway).
- Skipping the "what would we do the same" question. Not everything was wrong.
M&M is not punishment. M&M is how we keep getting better. Show up; tell the truth; write it down.
