AccessGraph

About the project Prior authorization can slow down care when clinical teams have to search through charts, payer policies, and documentation requirements manually. We built AccessGraph to make that process clearer before a case is submitted. Our inspiration came from the administrative burden placed on surgeons, PAs, nurses, and prior-authorization coordinators. They often know the patient needs care, but delays happen because a required note, exam, or treatment history is not immediately visible. We wanted to turn that uncertainty into a simple, transparent readiness workflow. AccessGraph is an AI-powered prior-authorization intelligence layer for clinical teams. For our synthetic ACL reconstruction case, it:

Extracts clinical evidence from patient records.
Extracts criteria from payer policy documents.
Matches evidence against requirements.
Flags missing documentation and next actions.
Shows a synthetic patient cost estimate.
Provides source-backed explanations for every criterion.
Displays trusted-agent verification status.
Includes a Case Guide side agent for questions about the current case. Rather than claiming an insurer will approve a case, AccessGraph presents authorization readiness. This distinction was important to us: the product supports clinical judgment and preparation, but never replaces payer review or guarantees coverage. How we built it We built AccessGraph as a modular monorepo so separate team members could work in parallel without breaking integration. The HCP-facing React frontend communicates only with a FastAPI Orchestrator through shared JSON contracts. The Orchestrator coordinates deterministic synthetic clinical evidence, policy requirements, matching, cost estimates, and agent verification. The frontend turns the final AuthorizationResult into a guided workflow with readiness cards, criteria checklists, missing-evidence actions, source drawers, and a side-panel Case Guide. For the demo case, the system identifies that the ACL case is not fully ready because functional instability needs clinician confirmation and the documented physical therapy duration is short. Once those gaps are resolved in the synthetic workflow, the case becomes ready for human review. What we learned We learned that explainability is as important as automation in healthcare workflows. A score alone is not useful unless a clinician can see:
Which requirement is missing.
Which source supports a finding.
What action should happen next.
What the system does and does not know. We also learned the value of strict shared contracts when multiple people build services in parallel. Keeping the frontend dependent only on the Orchestrator made the experience more stable and easier to test. Challenges we faced Our biggest challenge was integrating multiple modules while keeping the experience simple. Clinical records, payer policies, readiness logic, cost estimates, and identity verification can quickly become overwhelming. We addressed this by keeping technical details secondary and making the next best action immediately visible. Another challenge was avoiding misleading language. We deliberately designed the product around “criteria match” and “authorization readiness,” not guaranteed approval probabilities. That made the product more responsible, transparent, and aligned with real clinical workflows.