- Artificial Intelligence
AI Insurance Verification Before the Appointment
AI Insurance Verification Before the Appointment
Case Study: AI and Healthcare Automation
US Healthcare
Industry
Allergy + Derm
Starting Specialties
7 Days
Before Visit - Cost Estimate Delivered
20+
Microservices Built
FHIR + HL7
EHR Integration Standards
Temporal
Workflow Orchestration
01: The Challenge
Insurance Data Existed. It Just Arrived Too Late to Act On.
US specialty clinics run on insurance data, but that data sits scattered across hundreds of insurers, aggregator services, and payer portals. By the time it surfaced, treatment had already been delivered and billing had already closed.
01
Eligibility Confirmed Too Late
Coverage was checked at or after the visit, so clinics found gaps once treatment had already been delivered and could not be undone.
02
Cost Communicated After Billing Closed
Patients waited 15 to 30 days after the appointment to learn what it cost, by which point no alternative treatment path was available.
03
Four Variables, No Single Source
Treatment cost varies by insurer, by clinic, by individual doctor, and by procedure code - and no single system held all four variables together.
04
Pre-Approvals Surfacing at Claim Stage
Insurer prior authorization requirements appeared only at the billing stage, leaving clinics holding unbillable treatment a doctor had already prescribed.
02: The Core Idea
Move Every Decision Point Earlier. Verify Before, Not After.
Each of these failures is a question that can be answered before the event, provided the underlying data is pulled and reconciled in advance. The work moved every decision point earlier in the patient journey and put a verified answer in front of the clinic or the patient at the moment they could still act on it. The system proposes; the clinic or the patient confirms.
03: The Solution
Three Workflow Layers, Each Moving a Decision Earlier
1
Eligibility Confirmed Ahead of the Appointment
Clinic EHR systems hold appointments, documents, and patient history - but they do not resolve insurance status on their own. The platform bridges that gap directly from existing EHR data, approximately one week before each appointment.
Pre-Visit Checklist - Live Platform
Pre-visit checklist view: primary eligibility verified, secondary plan pending, intake complete - all resolved seven days before the appointment.
EHR Integration
Direct integrations with eClinicalWorks and athenahealth via FHIR and HL7 standards - the same protocols the platforms already exchange data through
7-Day Pre-Validation
Coverage validated approximately one week before each appointment, combining aggregator services, insurer APIs, and payer portals
Uncovered Patient Routing
Patients without active coverage are routed to a self-pay conversation before arrival; verified patients move automatically into cost analysis
Combined Plan Handling
Secondary coverage and family plans resolved in the same eligibility pass, not treated as edge cases requiring separate runs
Proof points
eClinicalWorks integration
athenahealth integration
FHIR and HL7 alignment
7-day pre-visit validation
Aggregator and payer API coverage
2
Cost Calculated Before the Visit, Not After It
What a treatment costs depends on which clinic delivers it, which doctor performs it, and which insurer covers it. Change any one of those three and the number changes. The benefit engine resolves all three in a single calculation run.
Benefit Calculation Engine - Live Platform
CPT-level cost breakdown: organization rate, provider rate, and patient estimated share - all resolved before the appointment date.
CPT-Level Calculation
Calculations run on CPT codes - the standard codes US insurers use to price individual procedures - mapped to each clinic's specialty
Rate Hierarchy
Benefits resolve against the clinic group's provider ID first, then the individual doctor's - since insurers contract different rates with each
Patient Share Separated
Patient share is separated from insurer share and delivered before the appointment so patients can accept, question, or request a different treatment path
80% Confidence Threshold
Fields pre-filled where the platform reaches 80 percent confidence; anything below that threshold is left open for staff review rather than guessed
Proof points
CPT-level cost calculation
Organisation and provider rate hierarchy
Combined and dependent plan handling
Patient estimate delivered pre-visit
3
Insurer Pre-Approvals Cleared Before the Claim
Some medications and procedures require prior authorization from the insurer before a clinic can bill for them - even when a doctor has already prescribed the treatment. Every insurer runs its own submission rules across a landscape of hundreds of payers.
Pre-Approval Workflow - Live Platform
Automated pre-approval pipeline: documents assembled, submitted per each insurer's own rules, approval status returned to the pre-visit view.
Automated Document Assembly
Visit history, treatment records, lab reports, and the doctor's recommendation gathered automatically into one submission package
Per-Insurer Logic
Submissions follow each insurer's own requirements - the platform holds per-insurer rules across hundreds of payers, not a single shared template
Pre-Visit Status Return
Approval status is returned to the pre-visit clinic view so clinics know whether a prescribed treatment is billable before the patient arrives
Proof points
Automated document assembly
Per-insurer submission logic
Approval status in pre-visit view
Hundreds of payer rules encoded
04: What Was Built
Named Capabilities
Insurance validation agent reading from clinic EHR systems via FHIR and HL7
Direct integrations with eClinicalWorks and athenahealth
Insurer aggregator service integrations and payer portal connections
Benefit and cost calculation engine resolving at CPT code and individual provider level
Organisation and provider rate hierarchy resolution
Combined and dependent plan handling in a single eligibility pass
Patient cost estimate delivered seven days before the appointment
Pre-approval document assembly with per-insurer submission logic
Approval status workflow surfaced in the pre-visit clinic view
80 percent confidence threshold with staff review queue for lower-confidence fields
Suite of more than 20 microservices supporting the agent architecture
Clearing house integrations and multiple payment gateway connections
05: Business Impact
Decisions Moved from After the Fact to Before the Visit
Cost Clarity
Patients receive a verified cost estimate approximately seven days before the appointment, against a previous wait of 15 to 30 days after the visit had already closed. The decision window moved 37 days earlier.
Coverage Gaps
Clinics identify patients without valid insurance coverage before the appointment rather than after treatment has been delivered. Uncovered patients are routed to a self-pay conversation in time to make a different choice.
Pre-Approvals
Prior authorization status is resolved before the patient arrives, so clinics know whether a prescribed treatment is billable before the visit takes place rather than at the claim stage.
Staff Workload
Staff review pre-filled records where the platform reaches 80 percent confidence. Anything below that threshold is left blank rather than guessed, reducing downstream correction work without removing human oversight.
Platform Scale
The same validation and cost logic carried the platform from allergy into dermatology and further specialties without a rebuild of the core engine. One calculation layer serves multiple specialty types.
06: Technology and Engagement
Built to Hold Long-Running Work Reliably
Coverage checks and benefit calculations call out to hundreds of external systems that fail, rate-limit, and time out independently of each other. The platform was built to handle long-running, multi-day workflows reliably rather than to complete every request in a single pass.
| Category | Technology | Role |
|---|---|---|
| Application Layer | Java + Spring Boot | Primary application layer, structured as a suite of more than 20 microservices |
| Orchestration | Temporal | Coordinates multi-step eligibility, benefit, and pre-approval flows that span multiple days and depend on external responses |
| Database | PostgreSQL | Primary data store for patient, coverage, and workflow state |
| Caching | Redis | Distributed caching for high-frequency insurer and rate data lookups |
| Secrets | GCP Key Store | Holds insurer and aggregator API credentials out of application code |
| EHR Integration | eClinicalWorks + athenahealth | Direct EHR integrations via FHIR and HL7 standards |
| Clearing | Clearing House + Payment Gateways | Clearing house integrations alongside multiple payment gateways for billing workflow completion |
| Engagement | Auriga IT | Built the platform across both original infrastructure and a later revamp, working directly with the client's product team throughout |
Why This Case Matters
Industry Context
For Any Regulated Workflow Where Cost or Approval Is Confirmed After the Fact
Workflows that appear to require human negotiation at every step are often just waiting on data that already exists somewhere in the chain. Where that data can be pulled, reconciled, and validated in advance, the decision moves earlier and the person making it reviews a proposed answer instead of assembling one from scratch. Healthcare insurance verification is one instance of this pattern. The same mechanism applies to any regulated workflow where eligibility, cost, or approval is currently confirmed after the action it was meant to govern - rather than before it.
07: Frequently Asked Questions
Questions About This Engagement
Which EHR systems does the insurance validation agent connect to?
The platform integrates with eClinicalWorks and athenahealth, two of the most widely used EHR platforms in US specialty clinics. Integrations are aligned to the FHIR and HL7 standards these systems exchange data through, making the connection standards-compliant rather than custom-built per clinic.
How does the platform handle hundreds of different insurers with different rules?
Both the coverage validation and pre-approval layers hold per-insurer logic rather than applying a single template. For coverage, the platform calls aggregator services, direct insurer APIs, and payer portals. For pre-approvals, each insurer's own submission requirements are encoded separately. A single template fails across a landscape of hundreds of payers - per-insurer logic is what makes the approach work at scale.
How is the patient cost estimate calculated when so many variables are involved?
The benefit calculation engine resolves cost at the CPT procedure code level, mapped to the clinic's specialty. It then applies rates in order: the clinic group's contracted rate with the insurer first, the individual doctor's contracted rate second. Secondary coverage and family plan variables are handled in the same pass. The result is a patient-share estimate that accounts for deductible position, coinsurance, and copay structure as they stand at that point in the plan year.
What happens when an external system times out or fails mid-workflow?
The platform uses Temporal for workflow orchestration, which is designed specifically for long-running, multi-step processes that depend on external responses. Coverage checks and pre-approval submissions can span multiple days. Temporal holds workflow state durably and retries failed steps without losing progress, so a single payer portal timeout does not cause the entire eligibility check to restart from scratch.
Can the same platform serve multiple clinic specialty types?
Yes. The validation and cost logic is mapped to CPT codes at the specialty level, which means adding a new specialty is a matter of extending the code mapping rather than rebuilding the core engine. The platform launched in allergy clinics and extended into dermatology and further specialties using the same underlying infrastructure without a rebuild.
What does the 80 percent confidence threshold mean in practice?
Where the platform can resolve a field - patient eligibility status, insurer rate, pre-approval requirement - with 80 percent or higher confidence, it pre-fills that field for staff review. Where confidence falls below that threshold, the field is left blank rather than populated with a guess. Staff review a mostly-complete record rather than keying everything from scratch, and uncertain fields are flagged for attention rather than silently filled with potentially incorrect data.
What was Auriga IT's engagement model on this project?
Auriga IT built the platform across both the original infrastructure and a subsequent revamp, working directly with the client's product team throughout rather than delivering against a fixed-scope handover. The engagement was collaborative from initial architecture through platform extension into additional clinic specialties.
Which other industries or workflows could this pattern apply to?
Any regulated workflow where eligibility, cost, or approval is currently confirmed after the fact is a candidate. The mechanism - pulling and reconciling data in advance, moving the decision point earlier, presenting a proposed answer for human review - is not specific to healthcare. Similar approaches apply in manufacturing, distribution, and financial services contexts where compliance or approval gates currently sit downstream of the actions they are meant to govern.
More Related Work
Related Case Studies
Building an Agent Suite Where Regulated Decisions Happen Too Late?
Talk to the team that moved insurance verification from 30 days after the visit to 7 days before it.
Start a ConversationRelated content
Auriga: Leveling Up for Enterprise Growth!
Auriga’s journey began in 2010 crafting products for India’s [...]
