Utilization management software is the system a health plan's UM team uses to receive prior authorization and concurrent review requests, apply coverage criteria, record the reviewer's decision, send notices and report on timeliness. Nearly every plan subject to the federal clocks already has one, often with licensed criteria content beside it, so the buying question in 2026 is rarely which platform to buy. It is how to meet a 72-hour expedited and seven-calendar-day standard clock when most of each request's time is spent before and around the platform: in fax queues, in pends, in the wrong reviewer's lane. Botminds' Utilization Management Automation is an agentic layer for that gap. It attaches to the doors and the platform a plan already runs, takes the reading, clocking, chasing and routing, and leaves the case of record and every decision where they are.
The UM stack a plan already runs, and where Utilization Management Automation attaches
Doors
Provider portal, fax lines, UM phone line, mailroom scans; from 2027 the Prior Authorization API
Intake reader: every page read, urgency found, duplicates merged
Clock
Receipt time and the rule for the line of business, usually a field in the case
Clock keeper: clock set from the arrival stamp; queue ranked by time left
UM platform
The case of record: member, service, criteria applied, notes, decision, letters
Chaser and router: pends worked, reviewer chosen; decisions stay in the platform
Criteria content
Medicare rules, NCDs and LCDs, and internal criteria the UM committee approved
Outcome predictor reads the record against them; it never replaces them
Reporting
Audit universes, the 31 March public metrics, the annual criteria submission
Metrics reporter: timestamps written as decisions are made
What is utilization management software?
It is the case-management system for coverage requests: one record per request, holding the member, the service, the clinical file, the criteria applied, the reviewer's notes, the decision and the letters. Around it sit three things the platform rarely owns. The doors through which requests arrive, from portals to fax servers to the phone line. The criteria content: Medicare's own coverage rules and the plan's internal criteria, which Medicare Advantage plans may build with help from commercial criteria products such as InterQual or MCG only within the limits CMS set in 2023 (CMS-4201-F). And reporting, which now includes public metrics and federal submissions.
The platform does the middle well. It is weakest at the edges: a fax arrives as an image the platform cannot read, a pend is a status rather than a chase, and the work queue is sorted by arrival or by team rather than by time left on a federal clock. Those edges are where the hours go.
What does a UM platform already do well, and where the hours still go?
A mature platform records decisions reliably, applies the plan's workflow, generates letters and keeps an audit trail of who touched a case. What it usually does not do is read every page of an unstructured fax, notice a physician's expedite box on page two, merge a portal duplicate into the fax that arrived first, ask the provider for the one missing record within the hour, or show a shift lead which request in any channel will breach next. Those are the waits that decide whether a request meets its clock, and they sit outside the system of record.
CMS's auditors have said what they will look for. Their 2025 enforcement report tells compliance officers that, with the new prior authorization timeframes, they "should be ready to show that their organizations can monitor and validate these updated prior authorization timeframes, identify delayed cases, and confirm that operational workflows, delegated entities, and systems are aligned to meet the new requirements". Identifying delayed cases before they are late is a queue problem, not a record-keeping one.
Where agents attach: five points on the request's path
Agents attach where a request waits without a person deciding anything: arrival, clock, pend, routing and reporting. At each point the agent's output goes into the plan's own platform or to a named person; none of them creates a second system of record for decisions.
Five attachment points, and what stays with the platform and the people
Agent
Intake reader, at the doorsReads each portal form, fax, phone note and letter on every page; finds member, provider, service, codes and urgency markers; matches records to open requests.
Never: downgrades a physician’s request to expedite
Agent
Clock keeper, on the caseSets the clock from the arrival stamp under the plan’s rule for that line of business and ranks the whole queue by time left, across channels.
Never: stops, pauses or extends a clock
Agent
Missing-information chaser, on the pendNames the exact document the decision needs and asks the provider through its own channel, then follows up on cadence.
Never: asks for more than the decision needs
Agent
Outcome predictor and reviewer router, at the queuePredicts the likely outcome against the plan’s criteria and assigns the next free reviewer whose licence, state and skill fit.
Never: decides, or drafts a denial
A person decides
Nurse and physician reviewers, in the platformReview the file and decide; nurses approve, physicians make every partial or full denial. The decision is recorded where it always was.
Agent
Metrics reporter, on the decisionWrites receipt, decision and notice times as each decision is made and drafts the yearly public metrics.
Never: publishes; compliance signs
What data each connection needs
Each attachment point needs a narrow feed: the doors need read access to arrivals with their timestamps, the clock needs the plan's rules by line of business, the router needs the roster, and the predictor needs the criteria the UM committee approved. The table is the integration scope a plan should expect, connection by connection.
The connections Utilization Management Automation needs, and what flows each way
| Connection | What the agents read | What they write back | Owner at the plan |
|---|---|---|---|
| Provider portal | Requests and attachments, with the portal submission time | Messages to the provider asking for a named record | Provider services or digital team |
| Fax lines | Every page of every fax, with the fax server’s arrival stamp | Outbound fax requests for records | UM intake |
| UM phone line | Call notes, with the time of the call | Call scripts for the intake coordinator | UM intake |
| Mailroom scans | Letters, with the mailroom date stamp as receipt | — | Mailroom |
| Shift roster | Reviewers’ licences, states, skills and load | Assignments to the next free reviewer | UM operations manager |
| Medical policies and criteria | The criteria the UM committee approved, by service | — | Medical policy team |
| UM platform | Case status, decisions and notice times | Clock, priority, pend status and timeliness data | UM operations and IT |
Every door in one place: arrivals by channel, read on every page
How does utilization management software handle the CMS Prior Authorization API?
From 1 January 2027 the API is one more door, and the UM platform behind it still makes the decision. CMS-0057-F requires Medicare Advantage organizations, Medicaid and CHIP programs and plans, and Marketplace issuers on the federal exchanges to run a FHIR-based Prior Authorization API that lists the services needing prior authorization, says what documentation each needs, accepts a request, and returns whether the plan approves, denies or needs more information. For Medicare Advantage the API must be able to name every document the plan needs before it can approve a service on the list (42 CFR 422.122(b)), and a denial through it must carry a specific reason. What to ask a vendor about each of those duties is the subject of the guide to the best prior authorization software.
Two consequences matter for UM software. First, a plan that implements an all-FHIR API need not also use the X12 278 standard: HHS announced enforcement discretion for covered entities that "do not use the X12 278 standard as part of their API implementation". Second, the documentation list the API must publish is the same knowledge a missing-information chaser uses to ask for the right record; if it lives only in nurses' heads, both will fail. A 2026 proposal, CMS-0062-P, would extend the API to drugs from 1 October 2027; it is a proposal, not a rule (CMS, April 2026).
Utilization Management Automation does not list the Prior Authorization API among its connections today, so a plan should treat requests from its API as another door feeding the same intake, with the API's timestamp as receipt. The API and the agents solve different problems: the API standardizes how a request arrives; the agents decide what happens to it in the hours before a reviewer opens it.
Can AI work with an existing utilization management system?
Yes, if it is built as a layer that reads from and writes to the platform rather than a second place where decisions are made. The test is simple: after the agents have run, is every decision still recorded in the plan's system of record, by a named reviewer, with the criteria applied? If so, the platform's audit trail, letters and history are untouched, and the agents add timestamps, priorities and requests for records around them.
Two cautions apply. The evidence base is thin: a 2026 systematic review of AI in prior authorization found 16 eligible studies, most reporting model accuracy and few reporting faster decisions or lower cost (J Manag Care Spec Pharm, 2026). A plan should therefore pilot on its own closed requests and measure elapsed time, not model scores. And the rules on individual decisions do not change because software is involved: medical-necessity decisions must still rest on the enrollee's own history, physician recommendations and clinical notes (42 CFR 422.101(c)(1)).
A record matched to its request: the file completed before the reviewer opens it
Should you replace your utilization management platform?
Usually not for the clocks. Replacing a UM platform moves the case of record, the letters, the workflow and the audit history at once, during a period in which the 2026 clocks already apply and the 2027 API is due. The clock failures most plans see come from the doors and the queue, which a new platform tends to reproduce unless the plan also changes how requests are read, chased and routed.
Replacement is the right project in narrower cases: the platform cannot record receipt and notice times separately, cannot hold more than one clock rule by line of business, or cannot export a request-level timeliness universe for an audit. Those are fundamental gaps in the record, not in the work around it. A plan can test for them in a week by trying to rebuild last month's public-metric medians from the platform alone; if the result needs spreadsheets and judgment calls, the record is the problem.
How long does it take to implement utilization management software?
A replacement platform is a multi-quarter program; a layer of agents should be proven in weeks on the plan's own requests before it touches live clocks. The sequence that keeps risk low is the same either way: run the agents on a sample of closed requests, compare their clock starts, expedite findings and record requests with what actually happened, then go live one door and one line of business at a time.
Implementation, in the order that keeps the live clocks safe
- Replay a sample of last quarter’s closed requests
Compare the agents’ receipt times, clock types and missing-record findings against the case history. Every mismatch is either an agent error or a past clock error, and both are worth knowing.
- Write the clock rules down as settings
Clocks by line of business, alarm thresholds, chase cadence and the nurse-lane threshold, each with an owner and a version.
- Connect one door first
The fax line with the most misfiled requests is usually the best first door; its arrival stamps are the clearest test of the clock.
- Run the board beside the existing queue
For a period, shift leads see both; the measure is requests the board flagged before the old queue did.
- Move routing last
Routing changes who sees what, so it goes live after the plan has confirmed predictions against reviewers’ actual decisions on its own requests.
- Reconcile the metrics before 31 March
Rebuild the public metrics from the new timeliness log and the old system for the same months; differences show which clocks were wrong.
Five questions to put to any UM agent layer before you buy
Ask about the rules before the features. A UM product that cannot show where each clock started, cannot keep a possible denial away from a nurse, or cannot reproduce last year's medians is a risk however good its screens look. The questions behind each rule, for platforms, agents and outsourced UM services alike, are set out in utilization management vendors: the questions behind each rule.
For this layer specifically, five questions separate a tool that helps the clock from one that only looks busy. Can it read a faxed request on every page and show where it found an urgency marker? Does the clock start at the arrival stamp, with the source shown? Does any agent ever stop, pause or extend a clock? Can it route a possible denial to a physician first time, and show the factors? And can it rebuild your posted metrics from its own log? Botminds' answers are in the product: it reads every page, starts each clock at the arrival stamp with the source shown, routes possible denials to physicians with the factors, and computes the nine public metrics from its own log, while no agent extends a clock or decides a request. Where it does not fit is equally specific: it does not replace the UM platform, the criteria content, or the clinical review itself; and if a plan's platform cannot record notice times, that gap must be closed in the platform. The 2026 duties the layer serves are summarized in the CMS-0057-F summary.
Questions people ask
What does utilization management software do?
It holds each coverage request as a case, applies the plan's workflow and criteria, records the reviewer's decision, generates notices and keeps an audit trail. Newer layers add reading of unstructured faxes, clock management by time left and automated requests for missing records, which the case system itself rarely does.
What integrations does utilization management software need?
At minimum the request channels (portal, fax, phone notes, mail), the reviewer roster with licences and skills, the criteria the UM committee approved, and the notice and claims systems. From 1 January 2027 plans subject to CMS-0057-F also need the FHIR Prior Authorization API as an additional channel.
Does the Prior Authorization API replace fax and portal requests?
No. The rule requires plans to offer the API from 2027; it does not oblige providers to send requests through it, so faxes, portal submissions and phone requests continue, and each still starts its clock at receipt.
Is UM software the same as criteria content like InterQual or MCG?
No. Criteria products are clinical content a plan licenses; UM software is the workflow system that applies it. In Medicare Advantage, CMS's 2023 rule allows such products only to help build internal criteria where Medicare's own coverage rules are not fully established, and not to change criteria Traditional Medicare already sets.
Can agents send denial letters?
Not in Utilization Management Automation. Agents never decide or draft a denial; any adverse or partial decision is made by a physician with the specific reason, and the plan's own system issues the notice under that reviewer's name.