EviCore intelliPath creates a prior-auth case from the order—but the order is not the determination
EviCore says intelliPath can create a case from an order or scheduled activity, submit it for approval or review, and update status. The clinical order, authorization case, review, and determination remain separate records.
Editorial figure by Prior Auth Monitor. Source context: EviCore intelliPath.
Automation can remove re-entry without merging clinical and payer decisions
EviCore presents intelliPath as an automated prior-authorization solution integrated with major electronic health record vendors. Its public page describes a single work queue, automatic case creation from an order or scheduled activity, electronic submission for approval or review, dynamic status updates, and decision logging. That sequence can reduce duplicate entry and give staff a more coherent operating record than separate portal, phone, fax, and spreadsheet work.
The sequence also contains distinct decisions. A clinician's order expresses the requested service in its care context. The authorization case packages that request for a payer or utilization-management workflow. A review applies plan rules and clinical criteria under the relevant arrangement. The determination communicates an outcome, scope, dates, conditions, and reasons. Creating the case from the order should preserve the relationship between them without implying that the order authorized itself.
Status needs source, scope, and time
A status label is useful only when staff can tell which request it describes, which payer or utilization-management organization supplied it, when it was obtained, and whether the underlying response is available. Pending may mean missing information, queued review, outreach in progress, or a technical acknowledgment. Approved may apply to a particular code, unit count, site, provider, date range, or episode. A later modification, cancellation, or new clinical fact can change the operating path.
The handoff should keep request identifiers, patient and coverage match, ordered service, codes, ordering and rendering providers, site, supporting documentation, submission timestamp, transport acknowledgment, questions, added materials, status provenance, determination document, reason, authorization identifier, effective window, conditions, and responsible reviewer connected. Exceptions must remain visible. A dynamically updated case should not overwrite the history that explains why staff acted.
Test the edge cases before trusting the straight-through path
A representative evaluation should start with an EHR order and follow the case through requirement confirmation, submission, request for additional information, resubmission, review, determination, scheduling, and any appeal or change. The team should introduce a duplicate order, changed code, mismatched member, alternate site, partial approval, expired window, and payer response that conflicts with the displayed status. Users should be able to find the controlling source rather than resolve ambiguity from color or shorthand alone.
EviCore's page documents the vendor's described workflow; it does not establish connectivity for every payer, plan, service line, EHR, code, or deployment, and published efficiency or timing statements are provider claims rather than independent findings here. Payers, delegated reviewers, clinicians, authorization specialists, revenue-cycle owners, privacy and security teams, and counsel retain their respective decisions. Authorization is also not a guarantee of medical necessity, coverage in every circumstance, claim payment, or clinical appropriateness.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Prior Auth Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.