XSOLIS Dragonfly supports concurrent authorization; its score is not the payer decision
Predictive insight can prioritize utilization-management work, but it does not replace the request record, medical-necessity review, payer determination, or documented exception path.
Editorial figure by Prior Auth Monitor. Source context: XSOLIS Dragonfly.
The direct answer
XSOLIS Dragonfly supports concurrent utilization-management and authorization work with predictive insight, but its score is not the payer's decision. A model output can identify a case for attention or inform review; it does not establish that a request was complete, that the applicable benefit and medical-necessity criteria were evaluated, or that an authorized reviewer approved or denied services.
This distinction matters because concurrent review occurs while care and documentation continue to evolve. Admission facts, level-of-care evidence, payer requirements, requested dates, attachments, review notes, peer discussion, and determination can change on different timelines. Compressing them into a score or generic authorization state can hide the exact evidence operations teams need.
What XSOLIS publicly describes
The official XSOLIS site presents Dragonfly as a platform for provider and health-plan utilization-management workflows. It describes predictive insights, a medical-necessity score, and collaboration around case review. Those statements establish the provider's public product positioning. They do not establish performance for a particular population, the acceptance of an output by a specific payer, or the validity of a coverage conclusion.
The scope is broader than a simple prospective prior-authorization transaction. Concurrent utilization management can include admission and continued-stay review, documentation exchange, status coordination, physician review, denials, and other case activity. Buyers should map the intended use precisely instead of treating every utilization-management function as the same authorization event.
The evidence chain buyers should require
A useful demonstration begins with the patient's source facts and the applicable request or review episode. It should preserve requested service and dates, payer and plan, criteria version, clinical documents, model input timing, output and confidence or limitation information, reviewer assessment, additional-information requests, peer activity, final determination, reason, effective dates, and later appeal or reconsideration. The record should distinguish provider action from payer action.
Test adverse cases as well as the happy path. Source documentation can be late, a payer can apply a different rule, the model can disagree with the reviewer, and an initially favorable signal can precede a partial or adverse determination. The system should make those differences visible, retain former states, and route exceptions without converting workflow completion into coverage evidence.
Clinical and governance limits
A predictive score depends on its intended use, training and validation context, available data, calibration, monitoring, and the workflow surrounding it. The public site does not disclose enough configuration-specific evidence to determine those matters for a buyer. Organizations should evaluate relevant subgroups, missing and delayed data, overrides, drift, access, privacy, security, and the consequences of false reassurance or unnecessary escalation.
Provider clinical, patient-access, utilization-management, revenue-cycle, payer, model-risk, interoperability, privacy, security, compliance, procurement, and legal owners should define decision rights. Licensed clinicians and authorized payer representatives retain responsibility for their respective judgments. The defensible design links prediction to review evidence while keeping the accountable determination unmistakably separate.
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.