report.object
AI agents for revenue cycle and prior authorization
Expert-reviewed from public records, platform data, primary sources, and private research beyond AI search. Use /api/v1/reports/RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH/sample before purchase, then download PDF, JSON, or Markdown after checkout.
page.markdown
AI agents for revenue cycle and prior authorization.md
# AI agents for revenue cycle and prior authorization
Revenue-cycle agents should close a payer-specific yield loop: policy discovery, chart evidence, submission, status, denial reasons, appeals and cash outcome telemetry feeding the next authorization request.
## Object
| field | value |
| ---------------- | ------------------------------------------------ |
| report_id | RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH |
| schema_version | 2026-05-28 |
| last_updated_at | 2026-06-01 |
| category | AGENTS |
| sector | Healthcare delivery |
| region | GLOBAL |
| confidence_score | 0.86 |
| source_count | 31 |
| evidence_count | 31 |
## Endpoints
| action | endpoint |
| ------------ | --------------------------------------------------------------------------- |
| summary | /api/v1/reports/RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH |
| sample | /api/v1/reports/RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH/sample |
| schema | /api/v1/reports/RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH/schema |
| quote | /api/v1/reports/RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH/quote |
| purchase | /checkout/RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH?view=agent |
| versions | /api/v1/reports/RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH/versions |
| changelog | /api/v1/reports/RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH/changelog |
| monitor | /api/v1/monitors?report_id=RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH |
| mcp_resource | colophon://reports/RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH/sample |
## Coverage
| field | value |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| category | AGENTS |
| sector | Healthcare delivery |
| region | GLOBAL |
| topics | revenue cycle AI, prior authorization, FHIR PAS, claims operations, denial management, medical necessity, utilization management, payer-provider interoperability, CMS-0057-F, appeals |
| source_classes | regulation, proposed_rule, agency_program, implementation_guide, state_guidance, accreditation, industry_survey, agency_comment_guide, agency_faq, independent_policy_analysis, federal_oversight_report, operating_rule_benchmark, administrative_transaction_benchmark, draft_operating_rule, regulatory_model_bulletin, health_it_rule, payer_operational_documentation, vendor_directory |
| update_cadence | Weekly |
## Sample JSON
```json
{
"report_id": "RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH",
"slug": "ai-agents-revenue-cycle-prior-authorization",
"schema_version": "2026-05-28",
"title": "AI agents for revenue cycle and prior authorization",
"abstract": "Revenue-cycle agents should close a payer-specific yield loop: policy discovery, chart evidence, submission, status, denial reasons, appeals and cash outcome telemetry feeding the next authorization request.",
"category": "AGENTS",
"sector": "Healthcare delivery",
"region": "GLOBAL",
"topics": [
"revenue cycle AI",
"prior authorization",
"FHIR PAS",
"claims operations",
"denial management",
"medical necessity",
"utilization management",
"payer-provider interoperability",
"CMS-0057-F",
"appeals"
],
"last_updated_at": "2026-06-01T00:00:00Z",
"source_count": 31,
"evidence_count": 31,
"confidence_score": 0.86,
"web_url": "/r/ai-agents-revenue-cycle-prior-authorization/RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH",
"sample_endpoint": "/api/v1/reports/RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH/sample",
"inventory_endpoint": "/api/v1/reports/RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH/inventory",
"full_endpoint": "/api/v1/reports/RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH/full",
"schema_endpoint": "/api/v1/reports/RPT_HEALTHCARE_DELIVERY_AI_AGENTS_RCM_PRIOR_AUTH/schema",
"redaction": {
"status": "sample",
"paid_sections_redacted": true,
"preview_limits": [
"summary",
"table_of_contents",
"evidence_profile"
]
},
"coverage": {
"category": "AGENTS",
"sector": "Healthcare delivery",
"region": "GLOBAL",
"topics": [
"revenue cycle AI",
"prior authorization",
"FHIR PAS",
"claims operations",
"denial management",
"medical necessity",
"utilization management",
"payer-provider interoperability",
"CMS-0057-F",
"appeals"
],
"source_classes": [
"regulation",
"proposed_rule",
"agency_program",
"implementation_guide",
"state_guidance",
"accreditation",
"industry_survey",
"agency_comment_guide",
"agency_faq",
"independent_policy_analysis",
"federal_oversight_report",
"operating_rule_benchmark",
"administrative_transaction_benchmark",
"draft_operating_rule",
"regulatory_model_bulletin",
"health_it_rule",
"payer_operational_documentation",
"vendor_directory"
]
},
"confidence": {
"overall_confidence": 0.86,
"source_quality": 0.89,
"source_recency": 0.9,
"source_density": 0.84,
"claim_verifiability": 0.87,
"geographic_coverage": 0.76,
"known_gaps": [
"The strongest public requirements are U.S.-specific, but prior-authorization and claims evidence remains useful for any buyer facing payer-provider workflow automation.",
"Vendor claims around denial reduction and staff productivity often lack payer-by-payer denominators.",
"Public evidence now gives Medicare Advantage appeal-overturn and administrative-transaction benchmarks, but buyer-specific economics still require payer mix, service-line volume, appeal filing, recovered revenue and patient-delay data."
]
},
"document": {
"object": "report_document",
"schemaVersion": "2026-05-28",
"title": "AI agents for revenue cycle and prior authorization",
"subtitle": "The margin is in the denial feedback loop, not the draft packet.",
"abstract": "Revenue-cycle agents should close a payer-specific yield loop: policy discovery, chart evidence, submission, status, denial reasons, appeals and cash outcome telemetry feeding the next authorization request.",
"category": "AGENTS",
"sector": "Healthcare delivery",
"region": "GLOBAL",
"topics": [
"revenue cycle AI",
"prior authorization",
"FHIR PAS",
"claims operations",
"denial management",
"medical necessity",
"utilization management",
"payer-provider interoperability",
"CMS-0057-F",
"appeals"
],
"sources": [
{
"id": "S1",
"label": "CMS - Interoperability and Prior Authorization Final Rule CMS-0057-F",
"publisher": "CMS",
"sourceClass": "regulation",
"accessedAt": "2026-06-01",
"status": "verified",
"access": "sample",
"originalUrl": "https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f",
"publicationDate": "2024-01-17",
"transformChain": [],
"url": "https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f"
},
{
"id": "S2",
"label": "CMS - 2026 Interoperability Standards and Prior Authorization for Drugs Proposed Rule",
"publisher": "CMS",
"sourceClass": "proposed_rule",
"accessedAt": "2026-06-01",
"status": "verified",
"access": "sample",
"originalUrl": "https://www.cms.gov/newsroom/fact-sheets/2026-cms-interoperability-standards-prior-authorization-drugs-proposed-rule",
"publicationDate": "2026-04-10",
"transformChain": [],
"provenanceNotes": "Use as workflow or timing evidence; verify final status and local applicability before relying on exact obligations.",
"url": "https://www.cms.gov/newsroom/fact-sheets/2026-cms-interoperability-standards-prior-authorization-drugs-proposed-rule"
},
{
"id": "S3",
"label": "CMS - Electronic prior authorization overview",
"publisher": "CMS",
"sourceClass": "agency_program",
"accessedAt": "2026-06-01",
"status": "verified",
"access": "sample",
"originalUrl": "https://www.cms.gov/priorities/electronic-prior-authorization/overview",
"transformChain": [],
"url": "https://www.cms.gov/priorities/electronic-prior-authorization/overview"
},
{
"id": "S4",
"label": "HL7 Da Vinci - Prior Authorization Support FHIR IG",
"publisher": "HL7",
"sourceClass": "implementation_guide",
"accessedAt": "2026-06-01",
"status": "verified",
"access": "sample",
"originalUrl": "https://hl7.org/fhir/us/davinci-pas/STU2/",
"transformChain": [],
"url": "https://hl7.org/fhir/us/davinci-pas/STU2/"
},
{
"id": "S5",
"label": "CMS - 2024 Medicare Advantage and Part D Final Rule",
"publisher": "CMS",
"sourceClass": "regulation",
"accessedAt": "2026-06-01",
"status": "verified",
"access": "sample",
"originalUrl": "https://www.cms.gov/newsroom/fact-sheets/2024-medicare-advantage-and-part-d-final-rule-cms-4201-f",
"publicationDate": "2023-04-05",
"transformChain": [],
"url": "https://www.cms.gov/newsroom/fact-sheets/2024-medicare-advantage-and-part-d-final-rule-cms-4201-f"
},
{
"id": "S11",
"label": "CMS - CMS-0062-P comment guide",
"publisher": "CMS",
"sourceClass": "agency_comment_guide",
"accessedAt": "2026-06-01",
"status": "verified",
"access": "sample",
"originalUrl": "https://www.cms.gov/files/document/cms-0062-p-comment-guide.pdf-0",
"publicationDate": "2026-04-14",
"transformChain": [],
"url": "https://www.cms.gov/files/document/cms-0062-p-comment-guide.pdf-0"
},
{
"id": "S12",
"label": "CMS - Prior Authorization API FAQ",
"publisher": "CMS",
"sourceClass": "agency_faq",
"accessedAt": "2026-06-01",
"status": "verified",
"access": "sample",
"originalUrl": "https://www.cms.gov/priorities/burden-reduction/overview/interoperability/frequently-asked-questions/prior-authorization-api",
"transformChain": [],
"url": "https://www.cms.gov/priorities/burden-reduction/overview/interoperability/frequently-asked-questions/prior-authorization-api"
},
{
"id": "S13",
"label": "KFF - Medicare Advantage prior authorization determinations in 2024",
"publisher": "KFF",
"sourceClass": "independent_policy_analysis",
"accessedAt": "2026-06-01",
"status": "verified",
"access": "sample",
"originalUrl": "https://www.kff.org/medicare/medicare-advantage-insurers-made-nearly-53-million-prior-authorization-determinations-in-2024/",
"publicationDate": "2026-01-28",
"transformChain": [],
"url": "https://www.kff.org/medicare/medicare-advantage-insurers-made-nearly-53-million-prior-authorization-determinations-in-2024/"
},
{
"id": "S14",
"label": "HHS OIG - Medicare Advantage prior authorization denials",
"publisher": "HHS Office of Inspector General",
"sourceClass": "federal_oversight_report",
"accessedAt": "2026-06-01",
"status": "verified",
"access": "sample",
"originalUrl": "https://oig.hhs.gov/reports/all/2022/some-medicare-advantage-organization-denials-of-prior-authorization-requests-raise-concerns-about-beneficiary-access-to-medically-necessary-care/",
"publicationDate": "2022-04-01",
"transformChain": [],
"url": "https://oig.hhs.gov/reports/all/2022/some-medicare-advantage-organization-denials-of-prior-authorization-requests-raise-concerns-about-beneficiary-access-to-medically-necessary-care/"
},
{
"id": "S15",
"label": "CAQH CORE - Prior authorization priority topics",
"publisher": "CAQH CORE",
"sourceClass": "operating_rule_benchmark",
"accessedAt": "2026-06-01",
"status": "verified",
"access": "sample",
"originalUrl": "https://www.caqh.org/core/priority-topics",
"publicationDate": "2025-01-01",
"transformChain": [],
"url": "https://www.caqh.org/core/priority-topics"
},
{
"id": "S16",
"label": "CAQH - 2024 Index key takeaways",
"publisher": "CAQH",
"sourceClass": "administrative_transaction_benchmark",
"accessedAt": "2026-06-01",
"status": "verified",
"access": "sample",
"originalUrl": "https://www.caqh.org/hubfs/Index/2024%20Index%20Report/CAQH%202024%20Index%20Report%20Key%20Takeaways%20FINAL.pdf",
"transformChain": [],
"url": "https://www.caqh.org/hubfs/Index/2024%20Index%20Report/CAQH%202024%20Index%20Report%20Key%20Takeaways%20FINAL.pdf"
}
],
"evidence": [
{
"id": "E1",
"sourceId": "S1",
"claimIds": [
"C1",
"C2"
],
"summary": "CMS-0057-F requires impacted payers to implement and maintain FHIR APIs, including prior-authorization APIs, with key API compliance dates extending to 1 January 2027 and public prior-authorization metrics beginning in 2026.",
"status": "verified",
"confidence": 0.91,
"access": "sample"
},
{
"id": "E2",
"sourceId": "S2",
"claimIds": [
"C1"
],
"summary": "CMS proposed extending many prior-authorization API requirements to drugs covered under medical and pharmacy benefits and proposed response-time transparency for drug authorizations.",
"status": "monitor",
"confidence": 0.86,
"access": "sample"
},
{
"id": "E3",
"sourceId": "S3",
"claimIds": [
"C1"
],
"summary": "CMS electronic prior-authorization materials consolidate final-rule, proposed-rule and implementation resources for organizations preparing electronic submission workflows.",
"status": "verified",
"confidence": 0.86,
"access": "sample"
},
{
"id": "E4",
"sourceId": "S4",
"claimIds": [
"C2"
],
"summary": "Da Vinci PAS defines a FHIR implementation guide for direct prior-authorization submission, status checks, updates and cancellations. Report inference: PAS conformance should shape buyer acceptance tests for authorization integration.",
"status": "verified",
"confidence": 0.88,
"access": "sample"
},
{
"id": "E5",
"sourceId": "S5",
"claimIds": [],
"summary": "CMS's 2024 MA and Part D rule requires MA plans to maintain utilization-management committees that review prior-authorization policies against Medicare coverage rules.",
"status": "verified",
"confidence": 0.87,
"access": "sample"
},
{
"id": "E11",
"sourceId": "S11",
"claimIds": [
"C1"
],
"summary": "CMS's CMS-0062-P comment guide says the proposed rule was published in the Federal Register on 14 April 2026 and the public comment period closes on 15 June 2026.",
"status": "monitor",
"confidence": 0.88,
"access": "sample"
},
{
"id": "E12",
"sourceId": "S12",
"claimIds": [
"C1"
],
"summary": "CMS prior-authorization API FAQs clarify response-time, decision-response and public-metrics reporting expectations for impacted payers implementing the API requirements.",
"status": "monitor",
"confidence": 0.88,
"access": "sample"
},
{
"id": "E13",
"sourceId": "S13",
"claimIds": [],
"summary": "KFF reports that Medicare Advantage insurers made nearly 53 million prior-authorization determinations in 2024 and that 80.7% of appealed denials were partially or fully overturned. Report inference: appeal filing, appeal overturn and patient-delay telemetry belong in the payer/service-line yield record.",
"status": "verified",
"confidence": 0.9,
"access": "sample"
},
{
"id": "E14",
"sourceId": "S14",
"claimIds": [],
"summary": "HHS OIG found that 13% of prior-authorization requests denied by sampled Medicare Advantage organizations met Medicare coverage rules, with examples including advanced imaging and post-acute facility stays. Report inference: AI-assisted denial and appeal workflows need chart evidence, medical-necessity rationale and reviewer accountability.",
"status": "verified",
"confidence": 0.9,
"access": "sample"
},
{
"id": "E15",
"sourceId": "S15",
"claimIds": [],
"summary": "CAQH CORE says only 35% of medical-industry prior authorizations are conducted fully electronically using the X12 278 transaction and identifies transaction-structure, operating-rule, documentation-infrastructure, vendor-readiness, portal and state-law barriers.",
"status": "verified",
"confidence": 0.88,
"access": "sample"
},
{
"id": "E16",
"sourceId": "S16",
"claimIds": [],
"summary": "CAQH 2024 Index key takeaways estimate $515 million in annual industry savings and 14 minutes saved per authorization from adopting the electronic standard. Report inference: administrative savings are useful private-eval inputs but do not prove denial-yield or appeal improvement.",
"status": "verified",
"confidence": 0.86,
"access": "sample"
}
],
"claims": [
{
"id": "C1",
"statement": "Prior authorization is urgent for AI agents because CMS has turned payer response, API and metrics requirements into a timed operating problem rather than a generic back-office automation idea.",
"confidence": 0.88,
"evidenceIds": [
"E1",
"E2",
"E3",
"E12"
],
"access": "sample"
},
{
"id": "C2",
"statement": "A revenue-cycle agent should be evaluated as a payer-by-payer authorization loop for coverage discovery, documentation, request, status, update and cancellation; denial and appeal support need separate reviewer evidence.",
"confidence": 0.87,
"evidenceIds": [
"E1",
"E4",
"E12"
],
"access": "sample"
}
],
"colophon": {
"checkedAt": "2026-06-01",
"latestRevisionAt": "2026-06-01T00:00:00Z",
"reviewStandard": "expert_human_reviewed",
"kinetics": {
"speed": "fast",
"impact": 0.92,
"momentum": 0.88,
"businessImpact": "Prior-auth agents depend on authorization yield: faster cash and access count only when submissions, status and appeals are measured by payer.",
"rateOfChange": "CMS API dates, public metrics and utilization-management oversight are turning prior authorization into a measurable operating loop.",
"from": "portals, fax queues and generic RCM automation",
"toward": "payer-specific authorization-yield loops with denial feedback and reviewer accountability"
},
"watch": [],
"gapAnalysis": "Payer- and service-line-level revenue-cycle telemetry linking policy discovery, chart evidence, attachment failures, denial reasons, appeal filing, overturn rates, recovered revenue, reviewer time and patient-delay data."
},
"body": {
"sections": [
{
"id": "executive-summary",
"title": "Executive summary",
"access": "sample",
"claimIds": [
"C1",
"C2"
],
"evidenceIds": [
"E1",
"E4",
"E2",
"E13",
"E15",
"E16"
],
"blocks": [
{
"id": "executive-summary-narrative",
"evidenceIds": [
"E1",
"E4",
"E2",
"E13",
"E15",
"E16"
],
"type": "section_narrative",
"lead": "Prior-authorization agents need an authorization-yield ledger: proof, by payer and service line, that AI turns policy, chart evidence and status telemetry into cleaner approvals, clearer denial reasons and stronger appeals without shifting risk to clinicians or patients.",
"body": [
"Revenue-cycle leaders should fund prior-authorization AI where it closes the denial feedback loop. The product requirement is an auditable record of policy version, chart evidence, submission channel, status, denial reason, appeal action, recovered revenue, reviewer minutes and patient delay.",
"CMS-0057-F and Da Vinci PAS make request and status workflow testable [E1, E4]; the 2026 drug proposal extends the question into medication lanes [E2]. Those rules set the test, then local telemetry decides whether clean-submission rate, status cycle time and denial yield improve by payer.",
"Outside the U.S., keep the same yield-loop test but replace CMS/PAS assumptions with local authorization channel, response-clock, appeal and documentation duties before procurement.",
"The trap is front-end speed without back-end learning. KFF's Medicare Advantage data makes the appeal denominator impossible to ignore: most appealed denials were at least partly overturned in 2024, so a system that does not raise appeal filing quality or overturn yield is leaving value and access risk unmeasured [E13].",
"The first production lane should be the revenue or care-delay pocket with observable outcomes: a few payer and service-line pairs measured on clean approval, denial-reason capture, appeal yield, recovered revenue and patient-delay events [E13]. Separately baseline electronic-channel success [E15] and reviewer-minute savings [E16] before accepting ROI claims. Move attachment completeness and reassociation into lane-level acceptance tests [E17]."
],
"detail": [
"Make the ledger a contract deliverable: payer, service line, benefit, policy version, evidence fields, channel, response clock, denial reason, appeal filed, appeal overturn, reviewer action and exportable audit trail.",
"Scale only when net accepted output improves by payer. A vendor that lifts submission volume while raising denials, appeals or hidden clinician work is moving the bottleneck."
]
},
{
"id": "board-decision-table",
"title": "The buying decision",
"evidenceIds": [
"E1",
"E4",
"E2",
"E13",
"E15",
"E16"
],
"type": "table",
"columns": [
{
"key": "question",
"label": "Question",
"align": "left"
},
{
"key": "answer",
"label": "Answer",
"align": "left"
},
{
"key": "move",
"label": "Action",
"align": "left"
}
],
"rows": [
{
"question": "What is the object of approval?",
"answer": "A payer, service-line and request-type yield register.",
"move": "Make source, status, attachment, denial, appeal filing, appeal overturn and telemetry fields contract deliverables before volume expansion."
},
{
"question": "Which lane goes first?",
"answer": "A high-volume payer and service-line pair with avoidable denials or delays and stable policy requirements.",
"move": "Baseline clean-submission rate, status cycle time, denial reasons, appeal yield, reviewer minutes and patient delays."
},
{
"question": "What remains blocked?",
"answer": "Autonomous adverse medical-necessity decisions, stale-policy packet drafting and staffing reductions before accepted-output telemetry.",
"move": "Keep reviewer authority and appeal evidence in place until local metrics prove the expansion."
}
]
}
]
},
{
"id": "what-changed",
"title": "What changed",
"access": "sample",
"dek": "Public evidence is now structured enough to define private approval tests.",
"claimIds": [
"C1",
"C2"
],
"evidenceIds": [
"E1",
"E12",
"E4",
"E2",
"E5",
"E15",
"E16",
"E14",
"E13"
],
"blocks": [
{
"id": "what-changed-narrative",
"evidenceIds": [
"E1",
"E12",
"E4",
"E2",
"E5",
"E15",
"E16",
"E14",
"E13"
],
"type": "section_narrative",
"lead": "The trigger is payer-specific operating proof: endpoint readiness, policy freshness, attachment completeness, denial-reason capture and appeal yield. Treat CMS and drug-rule timing as external pressure, then let payer/service-line telemetry decide spend [E1, E2]. Public appeal data supplies the denominator for the denial-feedback test [E13].",
"body": [
"The value is the payer-by-payer learning loop: which requests become clean approvals, avoidable denials, appeals, delayed care or write-offs. CMS and Da Vinci make submission and status testable [E1, E4]; MA and state evidence keep denial authority and appeal records in a reviewed lane [E5, E7].",
"Start where denied or delayed revenue concentrates: choose a few payer and service-line lanes, baseline clean-submission rate, electronic-channel success, attachment completeness, status-cycle time, denial reason, appeal filing, appeal overturn, reviewer minutes and patient-delay events, then expand only when the agent improves the loop [E13, E15].",
"For high-risk workflows, the approval record has to connect source evidence, accepted output, reviewer action, exception path, outcome signal and retained audit record before volume or staffing claims matter."
]
},
{
"id": "trigger-table",
"title": "Triggers that change approval timing",
"evidenceIds": [
"E1",
"E12",
"E4",
"E2",
"E5",
"E15",
"E16"
],
"type": "table",
"columns": [
{
"key": "trigger",
"label": "Trigger",
"align": "left"
},
{
"key": "why_now",
"label": "Why it matters",
"align": "left"
},
{
"key": "buyer_action",
"label": "Decision use",
"align": "left"
}
],
"rows": [
{
"trigger": "CMS-0057-F API compliance [E1]",
"why_now": "The payer-provider authorization workflow is becoming an API, response-clock and public-metrics requirement [E1, E12].",
"buyer_action": "Map current portal and fax work to CMS response expectations [E12] and PAS request, status, update and cancellation paths [E4]."
},
{
"trigger": "Drug prior-authorization proposal [E2]",
"why_now": "Medication workflows may gain medical-benefit and pharmacy-benefit standards, response-time and transparency obligations [E2].",
"buyer_action": "Separate drug authorization lanes by benefit type, payer channel and decision-time obligation."
},
{
"trigger": "Utilization-management oversight [E5, E6]",
"why_now": "MA rules make UM committees, health-equity analysis and public posting more visible [E5, E6].",
"buyer_action": "Use state human-oversight guidance to keep reviewer accountability, policy evidence and appeal telemetry in the lane [E7]."
},
{
"trigger": "CAQH electronic-adoption gap [E15, E16]",
"why_now": "Prior authorization remains partly manual even as CMS pushes API workflows, so channel mix and attachment handling can decide whether automation reduces work.",
"buyer_action": "Baseline electronic-channel success, portal fallback and reviewer minutes before accepting ROI claims; test attachment completeness separately [E17]."
}
]
}
]
},
{
"id": "decision-map",
"title": "Decision map",
"access": "sample",
"dek": "Workflow approval changes by authority, source boundary and proof burden.",
"claimIds": [
"C1",
"C2"
],
"evidenceIds": [
"E1",
"E4",
"E14"
],
"blocks": [
{
"id": "decision-map-narrative",
"evidenceIds": [
"E1",
"E4",
"E14"
],
"type": "section_narrative",
"lead": "Start with payer-by-payer proof that AI improves clean approvals, denial handling and appeals before staff or cash assumptions move.",
"body": [
"The decision map should start with a payer-by-payer authorization loop from live policy and chart evidence to submission, status, denial reason, appeal outcome and cash or care-delay result: what source record is read, what output is drafted, who approves it, where it is stored and what event forces reapproval.",
"A system can pass a low-risk support test and still fail production work: source evidence, accepted output, integration state, exception handling, reviewer burden and downstream rework have to hold together.",
"The useful vendor question is whether the system can make the named task inspectable, reversible and measurable inside the operating record."
]
},
{
"id": "route-selection-table",
"title": "Workflow selection",
"evidenceIds": [
"E1",
"E4",
"E14"
],
"type": "table",
"columns": [
{
"key": "route",
"label": "Workflow",
"align": "left"
},
{
"key": "accepted_output",
"label": "Accepted work",
"align": "left"
},
{
"key": "gate",
"label": "Approval gate",
"align": "left"
},
{
"key": "buyer_rule",
"label": "Approval rule",
"align": "left"
}
],
"rows": [
{
"route": "Payer-by-payer authorization yield",
"accepted_output": "Clean request, status result, denial reason, appeal filing, appeal overturn or write-off result tied to payer, service line and request type.",
"gate": "Policy source, member context, EHR evidence, payer channel, response clock, attachment record and denial feedback are retained.",
"buyer_rule": "Pilot the lanes with the largest denied or delayed revenue before broad automation."
},
{
"route": "Chart evidence assembly",
"accepted_output": "Chart-backed packet with required fields, attachments and clinical rationale.",
"gate": "EHR source references, missing-data queue and reviewer sign-off.",
"buyer_rule": "Measure accepted requests and rework before staff reduction claims."
},
{
"route": "Electronic submission and status",
"accepted_output": "FHIR or payer-channel submission with status, update and cancellation path [E1, E4].",
"gate": "PAS conformance, payer endpoint, exception fallback and audit log [E4].",
"buyer_rule": "Approve by payer endpoint, not as universal integration."
},
{
"route": "Denial and appeal intelligence",
"accepted_output": "Cited denial reason, appeal draft, next-best evidence list and outcome feedback.",
"gate": "Qualified reviewer, appeal deadline, source citations and medical-necessity standard [E14, E18].",
"buyer_rule": "Keep final adverse-coverage and appeal judgement with accountable clinical reviewers."
}
]
},
{
"id": "workflow-authority-matrix",
"title": "Write authority changes the proof burden",
"caption": "Use the matrix to decide what proof is required before each workflow becomes accepted work.",
"evidenceIds": [
"E1",
"E4",
"E14"
],
"type": "visual_matrix",
"columns": [
"Source path",
"Reviewer gate",
"System action",
"Retest trigger"
],
"rows": [
{
"label": "Payer-by-payer authorization yield",
"note": "Clean request, status result, denial reason, appeal filing, appeal overturn or write-off result tied to payer, service line and request type.",
"cells": [
{
"label": "Source named",
"detail": "Policy source, member context, EHR evidence, payer channel, response clock, attachment record and denial feedback are retained.",
"tone": "info",
"strength": "medium"
},
{
"label": "Human gate",
"detail": "Pilot the lanes with the largest denied or delayed revenue before broad automation.",
"tone": "blocked",
"strength": "gate"
},
{
"label": "Accepted work",
"detail": "Clean request, status result, denial reason, appeal filing, appeal overturn or write-off result tied to payer, service line and request type.",
"tone": "success",
"strength": "high"
},
{
"label": "Reapproval",
"detail": "Retest when policy, workflow, model, data access or system write rights change.",
"tone": "warning",
"strength": "medium"
}
]
},
{
"label": "Chart evidence assembly",
"note": "Chart-backed packet with required fields, attachments and clinical rationale.",
"cells": [
{
"label": "Source named",
"detail": "EHR source references, missing-data queue and reviewer sign-off.",
"tone": "info",
"strength": "medium"
},
{
"label": "Human gate",
"detail": "Measure accepted requests and rework before staff reduction claims.",
"tone": "blocked",
"strength": "gate"
},
{
"label": "Accepted work",
"detail": "Chart-backed packet with required fields, attachments and clinical rationale.",
"tone": "success",
"strength": "high"
},
{
"label": "Reapproval",
"detail": "Retest when policy, workflow, model, data access or system write rights change.",
"tone": "warning",
"strength": "medium"
}
]
},
{
"label": "Electronic submission and status",
"note": "FHIR or payer-channel submission with status, update and cancellation path [E1, E4].",
"cells": [
{
"label": "Source named",
"detail": "PAS conformance, payer endpoint, exception fallback and audit log [E4].",
"tone": "info",
"strength": "medium"
},
{
"label": "Human gate",
"detail": "Approve by payer endpoint, not as universal integration.",
"tone": "blocked",
"strength": "gate"
},
{
"label": "Accepted work",
"detail": "FHIR or payer-channel submission with status, update and cancellation path [E1, E4].",
"tone": "success",
"strength": "high"
},
{
"label": "Reapproval",
"detail": "Retest when policy, workflow, model, data access or system write rights change.",
"tone": "warning",
"strength": "medium"
}
]
},
{
"label": "Denial and appeal intelligence",
"note": "Cited denial reason, appeal draft, next-best evidence list and outcome feedback.",
"cells": [
{
"label": "Source named",
"detail": "Qualified reviewer, appeal deadline, source citations and medical-necessity standard [E14, E18].",
"tone": "info",
"strength": "medium"
},
{
"label": "Human gate",
"detail": "Keep final adverse-coverage and appeal judgement with accountable clinical reviewers.",
"tone": "blocked",
"strength": "gate"
},
{
"label": "Accepted work",
"detail": "Cited denial reason, appeal draft, next-best evidence list and outcome feedback.",
"tone": "success",
"strength": "high"
},
{
"label": "Reapproval",
"detail": "Retest when policy, workflow, model, data access or system write rights change.",
"tone": "warning",
"strength": "medium"
}
]
}
],
"legend": [
{
"label": "Private eval can start here",
"tone": "success",
"strength": "high"
},
{
"label": "Requires named owner or reviewer",
"tone": "warning",
"strength": "medium"
},
{
"label": "Hard approval gate before scale",
"tone": "blocked",
"strength": "gate"
}
]
},
{
"id": "route-definition-callout",
"title": "Route definition",
"evidenceIds": [
"E1",
"E4",
"E14"
],
"type": "callout",
"tone": "neutral",
"body": "Route means the approved path from work to accepted output: the source set, data boundary, model or vendor channel, tools, reviewer, evidence record and reapproval trigger that make an AI result usable."
}
]
},
{
"id": "signature-proof",
"title": "Signature proof",
"access": "locked",
"dek": "The decisive proof is whether the workflow survives evidence, audit and rework.",
"claimIds": [],
"evidenceIds": [],
"blocks": [
{
"id": "signature-proof-locked",
"title": "Locked section",
"evidenceIds": [],
"type": "callout",
"tone": "locked",
"body": "Purchase or subscribe to unlock this section."
}
]
},
{
"id": "provider-workflow-landscape",
"title": "Provider lanes",
"access": "locked",
"dek": "Providers should be compared by workflow authority.",
"claimIds": [],
"evidenceIds": [],
"blocks": [
{
"id": "provider-workflow-landscape-locked",
"title": "Locked section",
"evidenceIds": [],
"type": "callout",
"tone": "locked",
"body": "Purchase or subscribe to unlock this section."
}
]
},
{
"id": "use-case-route-selection",
"title": "Workflow selection",
"access": "locked",
"dek": "Production starts with the lane where output can be accepted or rejected visibly.",
"claimIds": [],
"evidenceIds": [],
"blocks": [
{
"id": "use-case-route-selection-locked",
"title": "Locked section",
"evidenceIds": [],
"type": "callout",
"tone": "locked",
"body": "Purchase or subscribe to unlock this section."
}
]
},
{
"id": "evidence-and-benchmarks",
"title": "Evidence fit",
"access": "locked",
"dek": "Public evidence maps to local accepted work.",
"claimIds": [],
"evidenceIds": [],
"blocks": [
{
"id": "evidence-and-benchmarks-locked",
"title": "Locked section",
"evidenceIds": [],
"type": "callout",
"tone": "locked",
"body": "Purchase or subscribe to unlock this section."
}
]
},
{
"id": "private-eval-design",
"title": "Private eval design",
"access": "locked",
"dek": "Public evidence chooses the tests; local cases decide production.",
"claimIds": [],
"evidenceIds": [],
"blocks": [
{
"id": "private-eval-design-locked",
"title": "Locked section",
"evidenceIds": [],
"type": "callout",
"tone": "locked",
"body": "Purchase or subscribe to unlock this section."
}
]
},
{
"id": "risks-and-controls",
"title": "Risks and controls",
"access": "locked",
"dek": "The main risk is ungoverned action.",
"claimIds": [],
"evidenceIds": [],
"blocks": [
{
"id": "risks-and-controls-locked",
"title": "Locked section",
"evidenceIds": [],
"type": "callout",
"tone": "locked",
"body": "Purchase or subscribe to unlock this section."
}
]
},
{
"id": "operating-model",
"title": "Operating model",
"access": "locked",
"dek": "Production ownership crosses clinical, technical, compliance and finance teams.",
"claimIds": [],
"evidenceIds": [],
"blocks": [
{
"id": "operating-model-locked",
"title": "Locked section",
"evidenceIds": [],
"type": "callout",
"tone": "locked",
"body": "Purchase or subscribe to unlock this section."
}
]
},
{
"id": "economics",
"title": "Economics",
"access": "locked",
"dek": "Price the accepted work.",
"claimIds": [],
"evidenceIds": [],
"blocks": [
{
"id": "economics-locked",
"title": "Locked section",
"evidenceIds": [],
"type": "callout",
"tone": "locked",
"body": "Purchase or subscribe to unlock this section."
}
]
},
{
"id": "implementation-signals",
"title": "Public claim tests",
"access": "locked",
"dek": "Vendor pages seed diligence; local telemetry supplies operating proof.",
"claimIds": [],
"evidenceIds": [],
"blocks": [
{
"id": "implementation-signals-locked",
"title": "Locked section",
"evidenceIds": [],
"type": "callout",
"tone": "locked",
"body": "Purchase or subscribe to unlock this section."
}
]
},
{
"id": "vendor-directory",
"title": "Diligence directory",
"access": "locked",
"dek": "Representative vendors and platform RFI anchors to include in diligence.",
"claimIds": [],
"evidenceIds": [],
"blocks": [
{
"id": "vendor-directory-locked",
"title": "Locked section",
"evidenceIds": [],
"type": "callout",
"tone": "locked",
"body": "Purchase or subscribe to unlock this section."
}
]
},
{
"id": "recommended-next-steps",
"title": "Recommended next steps",
"access": "locked",
"dek": "A practical workflow can be approved in phases without pretending the whole market is ready.",
"claimIds": [],
"evidenceIds": [],
"blocks": [
{
"id": "recommended-next-steps-locked",
"title": "Locked section",
"evidenceIds": [],
"type": "callout",
"tone": "locked",
"body": "Purchase or subscribe to unlock this section."
}
]
},
{
"id": "known-unknowns",
"title": "Known unknowns",
"access": "locked",
"dek": "These gaps should shape diligence rather than delay all buying.",
"claimIds": [],
"evidenceIds": [],
"blocks": [
{
"id": "known-unknowns-locked",
"title": "Locked section",
"evidenceIds": [],
"type": "callout",
"tone": "locked",
"body": "Purchase or subscribe to unlock this section."
}
]
},
{
"id": "source-ledger",
"title": "Source ledger",
"access": "locked",
"dek": "Primary public sources and evidence rows behind the workflow analysis.",
"claimIds": [],
"evidenceIds": [],
"blocks": [
{
"id": "source-ledger-locked",
"title": "Locked section",
"evidenceIds": [],
"type": "callout",
"tone": "locked",
"body": "Purchase or subscribe to unlock this section."
}
]
},
{
"id": "glossary",
"title": "Glossary",
"access": "sample",
"claimIds": [],
"evidenceIds": [],
"blocks": [
{
"id": "glossary-table",
"title": "Terms used in this report",
"caption": "Definitions are reader aids, not separate evidence claims.",
"evidenceIds": [],
"type": "table",
"columns": [
{
"key": "term",
"label": "Term",
"align": "left"
},
{
"key": "meaning",
"label": "Plain meaning",
"align": "left"
}
],
"rows": [
{
"term": "Route",
"meaning": "The approved path from work to accepted output: source set, data boundary, model or vendor channel, tools, reviewer, evidence record and reapproval trigger."
},
{
"term": "API",
"meaning": "Application programming interface: a governed software connection used by an app or workflow to call a model or service."
}
]
}
]
}
]
}
},
"gap_analysis": "Payer- and service-line-level revenue-cycle telemetry linking policy discovery, chart evidence, attachment failures, denial reasons, appeal filing, overturn rates, recovered revenue, reviewer time and patient-delay data.",
"kinetics": {
"speed": "fast",
"impact": 0.92,
"momentum": 0.88,
"businessImpact": "Prior-auth agents depend on authorization yield: faster cash and access count only when submissions, status and appeals are measured by payer.",
"rateOfChange": "CMS API dates, public metrics and utilization-management oversight are turning prior authorization into a measurable operating loop.",
"from": "portals, fax queues and generic RCM automation",
"toward": "payer-specific authorization-yield loops with denial feedback and reviewer accountability"
},
"watch_signals": [],
"sample_findings": [
"Prior-authorization AI is a denial-feedback loop: value comes from learning why requests fail by payer and service line, then improving the next packet."
]
}
```