HTM Benchmarking and Failure Cause Codes: The List Is Standardized. The Click Is Not.
Every benchmark you care about starts with a click.
A technician finishes a repair, opens the closeout screen, and picks a failure code from a dropdown. Use error. Component failure. No problem found. Five seconds, usually at the end of the shift, and every failure rate, repeat repair count and "how do we compare" chart is built on it.
HTM benchmarking on failure cause codes is not a bad idea. It is the best idea the field has. The question is whether the code was right when it was picked, because nothing downstream can fix a code that went wrong upstream.
What do failure cause codes do for HTM benchmarking?
They make work comparable. Free text does not.
The AAMI HTM Benchmarking Guide, 2nd Edition, by Ted Cohen, Frank Painter, Matt Baretich and David Braeutigam, proposes a short list of performance metrics beyond PM completion, which it notes is the only indicator many hospitals use because surveyors ask for it. The first metric is failures per device per year. It comes in a gross version, which counts every unscheduled work order, and a filtered version, which uses the failure root cause field to leave out use errors, facility problems and IT problems. The filtered number is the one that tells you whether your equipment is actually failing, and it exists only if the code is right.
The industry knows this. In 2020, six competing CMMS vendors agreed on a standardized failure cause code list in an AAMI-sponsored white paper. Matt Baretich, who co-facilitated it, said the difference this time was that the people who build the tools had agreed. The goal was consistent data, so programs could benchmark internally and eventually answer the executive's question: how do we compare to others?
That was a real step. It standardized the list. It did nothing about the click.
Where does the proof that codes work come from?
From Binseng Wang, more than anyone. His evidence-based maintenance studies tracked more than 40,000 devices across eight hospitals with a small set of failure cause codes. With fewer than 100 work orders per equipment type, the failure pattern settled into a stable shape that matched from hospital to hospital. That is the strongest evidence anywhere that coded records can be compared across programs.
Read the fine print, though. Wang wrote in 24x7 that adopting codes is not easy. The technician is no longer recording the problem found and the parts replaced. They are deciding the root cause, sometimes among several, and picking the most serious one. His teams were trained and supervised, and leadership reviewed the assigned codes for signs of misuse, like the same code on every record.
The proof that codes work came from programs that worked at it. It did not come from a dropdown.
Why does a failure code go wrong?
Not because technicians are careless. Because the code is a judgment made under three pressures at once.
Time. The pick happens at closeout, hours after the work, from memory, on the way to the next job.
Ambiguity. Wang himself says some codes cannot be decided at closeout at all. Whether a service-induced failure was a servicer mistake or a part with high infant mortality takes a dozen similar failures to tell, so that call belongs to the manager later. "No problem found" is the same: a use error, or an intermittent fault that will be back next week.
Self-protection. Wang told a story about this in a public LinkedIn exchange this August. When his ISO first trained technicians on failure cause codes, the first choice on the list was "I am an idiot." Nobody picks that one. Not because people are dishonest, but because when a code list contains blame, tired people reach for the safe code.
Here is why that matters for benchmarking. Averages over thousands of work orders cancel out random mistakes. That is the Law of Large Numbers, and Wang is right to lean on it. But averages do nothing to a systematic lean: the same safe code, picked the same way, by the same people, every day. That error survives any sample size, and Wang conceded the point publicly. A benchmark built on a systematic lean is precise and wrong.
What does a wrong code do to the numbers?
It does not show up as a blank. It shows up as a good-looking number.
If "use error" is the socially cheapest code, because it blames neither the device nor the servicer, your filtered failure rate looks better than your fleet is. Your AEM justification sits on that rate.
If a "no problem found" was really an intermittent fault, the device that came back three times shows up as one repair and two non-events. Your repeat repair count misses it.
Across multi-site systems, leaders describe regions reporting numbers that cannot be put side by side, because each region codes and records its own way. The AAMI guide says the same about programs in general: two teams using the same tool will still define and record their data differently, and without consistent collection there is no benchmark against peers. A standardized list narrows that gap. It does not close it, because the list is not the decision.
And if a replacement review runs on counted corrective work orders, does a "no problem found" count the same as a failed board? Usually it does. That is a capital decision resting on a click.
One precedent is worth knowing. Wang's 2012 follow-up on productivity and staffing concluded that worked hours self-entered by technicians are subject to misuse and should be avoided for benchmarking. Hours are a self-reported field. So is a failure code. Nobody has run that study on codes yet.
Can you benchmark without trusting the codes? Only bluntly. Gross counts, turnaround and response time come from timestamps. The moment you want to say "our devices fail less," you are back to the code. You cannot route around it. You can only make it easier to get right.
What makes a failure cause code trustworthy?
Three things, all from Wang's playbook, not ours.
Fewer codes. He used eleven, on a single level, because too many codes confuse staff and spread the data too thin.
Codes that get reviewed. Leadership looking at assigned codes periodically for the patterns that signal misuse.
Codes that get used. His teams embraced coding once the results came back and changed their own PM plans.
Every one of those depends on something the code list cannot supply: the account of what actually happened on the job. You cannot review a code against a note that says "good to go," the pattern Monty Gonzales named in AAMI News. You cannot tell what "no problem found" meant unless the record says what was checked.
A failure code is a summary, and a summary is only as good as what it summarizes. When the record is thin, the code is a memory of the job, made at the end of the shift. When the record is rich and made at the bench, the code is a reading of the evidence, and a manager reviewing it a month later can see whether it fits.
That is the part Leera AI works on. The technician describes the repair out loud while doing it, Leera AI writes the record, the technician reviews and owns it, and it syncs to your CMMS via API. We do not pick the code for anyone. We make sure the evidence behind the code exists when the technician is choosing it, not at the end of the day.
FAQ
What are failure cause codes in HTM? A short list of categories a technician assigns to a work order to say why the equipment failed: unpreventable component failure, preventable or predictable failure, use-related damage, service-induced failure, no problem found. They let programs count and compare failures by type, which free text cannot.
Can you benchmark an HTM program without failure codes? Only coarsely. Gross failure counts, turnaround time and response time come from work order dates and counts alone. Any metric that separates device failures from use errors, or maintenance-related failures from random ones, depends on a correctly assigned failure code.
Why are failure cause codes unreliable? Because each one is a judgment made under time pressure, often from memory at the end of a shift, sometimes about a cause that cannot be determined from one work order. Random mistakes average out across many records. Systematic ones, like always reaching for the code that blames nobody, do not.
How many failure cause codes should an HTM program use? Binseng Wang's evidence-based maintenance work used eleven codes on a single level, and he has argued that more codes confuse staff and spread data too thin. The 2020 AAMI-sponsored CMMS Collaborative white paper offers a standardized list. Whichever list you use, reviewing the assigned codes matters more than its length.
Dima Okhrimchuk is the founder of Leera AI, which builds voice-first documentation for HTM teams. Leera AI is built in the field with HTM teams at major US health systems.