Emergency department visit levels are assigned on medical decision making and nothing else. Not time, not the length of the history, not how much of the exam was documented. That has been true since the 2023 CPT revision, and it changed the leveling task from counting documented elements to interpreting what the clinician actually did.
That shift matters enormously for automation, because counting is a solved problem and interpretation is not. This page works through the three medical decision making elements one at a time, what automation does well and badly on each, and how to test whether a platform is reaching the right level for the right reason.
One boundary before going further. Everything here concerns the professional claim. Hospital facility levels are assigned under your own institution's criteria rather than the CPT rules, which is a genuinely different problem.
What the 2023 revision actually changed
Four codes map onto the four medical decision making levels: 99282 to straightforward, 99283 to low, 99284 to moderate, 99285 to high. Two of the three MDM elements must meet or exceed a level for that level to be selected.
Code 99281 sits outside that ladder. ACEP describes it as covering encounters that may not require the presence of a physician or other qualified health care professional, which makes it a different kind of code rather than the bottom rung of the same ladder. Automation should treat it as a separate classification decision, not as the default output when confidence is low. A platform that drops uncertain charts to 99281 is not leveling them, it is hiding them.
The removal of history and exam from level selection is the change with the largest automation consequence. Under the old framework, a level was substantially a tally: bullet points of history, systems reviewed, exam elements documented. Tallies automate well. Under the current framework, the level is an inference about clinical reasoning, and an inference has to be explainable to be auditable.
This is why the useful question about a leveling engine is not "what level did it pick" but "which two elements carried it, and why." A platform that outputs a level with no element breakdown has produced a number you cannot defend in an audit. Ask to see the reasoning surfaced per element before you see an accuracy figure, and see what ED coding automation covers for how that fits a wider rollout.
Element one: problems addressed, and the word doing the work
The first element counts the number and complexity of problems addressed during the encounter. The load-bearing word is addressed.
A condition mentioned in the past medical history is not addressed. A chronic condition listed in the record but not evaluated or managed during the visit is not addressed. The distinction is between what the clinician did something about and what happened to appear in the chart.
This is the hardest of the three elements for automation, and the failure mode to test for is problem-list scraping. An ED chart for a patient with diabetes, hypertension and chronic kidney disease who presents with an ankle sprain contains three chronic conditions and one addressed problem. A platform that treats documented conditions as addressed problems inflates this element on comorbidity-heavy charts, which is exactly where auditors look for upcoding patterns first.
The complexity gradations add a second difficulty. Distinguishing an acute uncomplicated illness from an acute illness with systemic symptoms depends on whether the documentation describes systemic involvement, which is a clinical reading of prose rather than a keyword match. Stable chronic illness carries a definitional trap of its own: stability is measured against the patient's treatment goal, so a patient whose condition is unchanged but who has never reached goal is not stable. That is the kind of rule a coder internalises and a model has to be told.
What automation does well here is consistency once the rule is encoded. What it does badly is deciding, unprompted, that a documented condition was not part of this encounter. Design the workflow so that this element is surfaced with the supporting text for each problem it counted, and make disagreement cheap to register.
Element two: data reviewed, where automation genuinely wins
The data element is the one place in ED leveling where a platform will routinely outperform a human coder, and it is worth understanding why.
Data is scored across three categories. The first covers tests ordered, tests reviewed, unique external notes reviewed, and use of an independent historian, with thresholds based on how many distinct elements are present. The second covers independent interpretation of a test that has its own CPT code and for which a report is customary, an EKG read by the emergency physician being the canonical ED example. The third covers discussion with an external physician or other appropriate source, which requires an actual interactive exchange rather than a note sent into the void.
All three are countable. Counting them correctly means reading the entire chart, cross-referencing orders against results, and noticing a one-line interpretation buried in the middle of a note. That is tedious, low-glamour work, and it is where human coders lose the most accuracy in ED leveling. Not through lack of knowledge, but through volume. A model does not get bored on chart 180.
Three automation failure modes to test for specifically:
- Double counting. Ordering a test and reviewing its result is one element, not two. This is the most common arithmetic error in automated data scoring.
- Interpretation without a report. The second category requires that an interpretation or report is customary for that test. A passing mention that the EKG looked normal is not the same as a documented interpretation. Models are generous here.
- Discussion that was not a discussion. A message left for a consultant is not an interactive exchange. Platforms trained to spot consultant names in text will count both.
The upside is real, though. If your current coders are undercounting data, an accurate automated data score will move some charts up a level legitimately. Expect that in the validation results and do not treat it as the platform overcoding until you have checked the documentation.
Element three: risk, and the distinction models get wrong
The third element measures the risk of complications and morbidity arising from patient management. Not the risk posed by the disease. The distinction sounds academic and it is the single most common source of automated leveling error.
A patient with a frightening presenting complaint who is examined, worked up and sent home has a lower management risk than a patient with a mundane complaint who is admitted. Risk attaches to what was decided and done, not to how alarming the chief complaint reads.
Automation gets this wrong in a specific direction. Trained on associations between diagnosis text and level, a model learns that chest pain charts are high-level charts. It then applies high risk to the chest pain patient who was discharged after a negative workup, which is a defensible level reached by indefensible reasoning, and it is exactly the pattern an audit surfaces.
The management decisions that raise this element in the ED are concrete and documentable. A decision regarding hospitalization or escalation of care. Prescription drug management. Parenteral controlled substances. Drug therapy requiring intensive monitoring for toxicity. A decision about emergency major surgery. Each of these is an event recorded in the chart, which means a platform can be built to find the decision rather than infer risk from the diagnosis.
There is also legitimate disagreement inside this element, and a page that pretends otherwise is not useful to a working coder. Whether prescribing an over-the-counter-strength medication constitutes prescription drug management, and how to treat social determinants of health as a limiting factor, are both areas where experienced coders and auditors reach different conclusions in good faith. A platform should expose which interpretation it applied so your team can align it with your own audit position, rather than silently picking one.
A worked example: same complaint, different levels
Two illustrative chest pain charts, scored element by element. These are teaching examples rather than real encounters.
| Chart A | Chart B | |
|---|---|---|
| Presentation | 54-year-old, exertional chest pain, diaphoresis | 24-year-old, chest pain after a gym session, reproducible on palpation |
| Workup | EKG interpreted by the ED physician, troponin, chest radiograph | EKG interpreted by the ED physician |
| Consultation | Discussion with cardiology | None |
| Disposition | Admitted | Discharged with a prescription NSAID |
| Problems addressed | Acute illness posing a threat to life or bodily function: high | Acute uncomplicated illness: low |
| Data reviewed | Three unique tests plus independent EKG interpretation plus external discussion: extensive | One test plus independent EKG interpretation: moderate |
| Risk of management | Decision regarding hospitalization: high | Prescription drug management: moderate |
| Two of three | High, high | Moderate, moderate |
| Level | 99285 | 99284 |
Chart B is the instructive one. The presenting complaint is benign and the patient went home, yet the encounter supports a level four on the data and risk elements alone. A leveling engine that reasons from diagnosis to level will underprice this chart, and a coder working at speed often will too.
Chart B also contains a contestable point. Whether the NSAID prescription counts as prescription drug management is a question reasonable auditors answer differently, particularly where the medication is available over the counter at a lower strength. Settle your institution's position, encode that position, and make sure the platform applies it consistently. The risk is not being wrong, it is being inconsistent.
How to validate an automated leveling engine
Most pilots measure one thing: how often the platform picked the same level as the coder. That is necessary and it is not sufficient.
Score agreement at the element level, not just the level. A model can reach the correct level through the wrong two elements. The level is then right and the reasoning is not, and under audit the reasoning is what gets examined. An engine that reaches 99284 on high problems and low data, where the coder reached 99284 on moderate data and moderate risk, has not agreed with your coder in any meaningful way. Measuring only final-level agreement makes that invisible, and it will stay invisible until an auditor finds it.
Watch your level distribution. The fastest signal that automated leveling has drifted is a change in the shape of your distribution against your own historical baseline. This is not about hitting a national benchmark, because your case mix is your case mix. It is about knowing what your distribution looked like before automation and noticing when it moves. Set that baseline before go-live, because reconstructing it afterwards is much harder.
Know that ED E/M is under active audit. OIG's Work Plan includes audits of Medicare emergency department evaluation and management services, item W-00-24-35877, with reports expected in fiscal year 2026, examining whether these services were medically necessary and paid in accordance with Medicare requirements. Automating leveling while a national audit program is running is not a reason to avoid automation. It is a reason to keep the element-level audit trail.
Set your baseline honestly. Human E/M leveling is not an error-free benchmark. An OIG review of 2010 claims found that 42 percent of E/M claims were incorrectly coded, including both upcoding and downcoding, with 19 percent lacking documentation. That data predates the 2023 rules by more than a decade and says nothing about current rates, so do not quote it as a present-day figure. What it does establish is that leveling has always been hard and error has always run in both directions. Compare automation to your own recent audited accuracy, not to an assumption of perfection. Level distribution also matters on the way out.
Frequently asked questions
Does time ever factor into ED E/M levels?
No. Time was removed as a selection component for 99281 through 99285 in 2023, because ED work is delivered at variable intensity across several patients at once. Time still governs critical care coding, which uses codes 99291 and 99292 and follows entirely separate rules.
Can AI assign ED E/M levels on its own?
It can propose them reliably on straightforward charts and it should show its element-level reasoning on all of them. High-acuity charts are the ones where review pays for itself.
Why did our level distribution change after automation?
Usually the data element. If your coders were undercounting unique tests, independent interpretations or external discussions, an accurate automated score moves some charts up legitimately. Check the documentation on a sample before concluding the platform is overcoding. If the movement is concentrated in charts with long problem lists, suspect the problems element instead.
Is the facility level the same as the professional level?
No, and they frequently differ on the same encounter. Facility levels follow criteria your hospital wrote, not the CPT MDM rules, which is why how an ED facility level is determined is a separate question with a separate answer.
Where can I see the official MDM definitions?
The medical decision making guidelines are published by the AMA in CPT and are reproduced with commentary by ACEP for emergency medicine. This page paraphrases them deliberately rather than reproducing copyrighted text.
This article is educational and does not constitute a coding determination for any specific patient encounter. Level assignment depends on the documentation in the individual record.
