Network administrators & TPAs

Specialized capability inside the operation you already run.

AVC takes the dental case material an administrator already receives, structures it, applies documented rules, and hands a reviewer an organized case with every flag traced back to the document it came from. It is a layer, not a platform replacement.

AVC prepares the decision. Humans make it.

Positioning

A Specialized Authorization Intelligence Layer for Dental Administration

Administrators serving VA Community Care operate substantial technology, and the people running utilization management in dental are not short of systems. Nothing on this page is an argument that anything is missing from your stack.

The argument is narrower than that, and we would rather state it precisely than dress it up:

A specialized dental authorization-intelligence layer may improve or accelerate administrator workflows without requiring every specialized authorization capability to be built internally.

May is doing real work in that sentence, and we are leaving it there. Dental authorization has its own evidence types, its own anatomy, its own scope questions and its own failure modes. Building for that specifically is a decision about focus, not a judgment about anyone else’s capability. Whether the focus is worth integrating is the open question, and it is the question we would like to work through with an administrator rather than assert on a website.

Architecture

Where AVC sits.

One position in an existing chain. Case material arrives from the administrator platform, AVC structures it and applies documented rules, and the organized case goes to clinical and utilization-management review before it enters the VA decision workflow.

AVC does not sit at either end of that chain, and it is not designed to move.

Who owns what

AVC
The authorization-intelligence layer: structuring, rule application, explainability, case assembly.
Administrator
Network operations: routing, provider relationships, processing and the platform of record.
Clinician
Clinical judgment. AVC produces no diagnosis and no clinical conclusion.
VA
Final authorization authority. AVC has no relationship with VA and no role in the decision itself.
Flow diagramCase material passes from the administrator platform into the AVC authorization-intelligence layer; the organized case then goes to clinical and utilization-management review; the reviewed case then enters the VA decision workflow. Four stages, in that order.
  1. Administrator

    Administrator Platform

    Case material enters from the systems already in operation.

  2. AVC

    AVC Authorization Intelligence

    Structuring, documented rule application, classification, source linking.

  3. Clinician / reviewer

    Clinical / Utilization Management Review

    A person reviews the organized case and records a disposition on each flag.

  4. VA

    VA Decision Workflow

    Final authorization authority rests here, outside the product.

The two people it has to serve

A reviewer opening a case, and the operation behind them.

These are the objectives we heard described. They are what the product is built toward, not effects we have observed.

A utilization-management reviewer wants to

  • Review organized evidence rather than a document pile
  • See what the system flagged, and why it flagged it
  • Verify the policy context behind each flag
  • Record a human disposition on the case
  • Avoid reconstructing the case manually

An administrator is optimizing for

  • Case readiness at the point of review
  • Standardized processing across submitting organizations
  • Less unnecessary rework in the queue
  • Review efficiency without loss of rigor
  • Explainability that survives an audit
  • Integration into existing infrastructure

Operating principles

Five commitments the product is designed around.

  1. 01

    Integration

    AVC is designed to fit an existing chain of systems. It assumes it is one component among many, and that it is not the system of record.

  2. 02

    Standardization

    Cases arriving from many submitting organizations are structured into one consistent shape, so a reviewer reads the same layout every time.

  3. 03

    Explainability

    Every material flag carries its source document, the rule that produced it, and the version of that rule. Nothing surfaces without a reason attached.

  4. 04

    Human oversight

    A disposition is recorded by a person. Where confidence or complexity prevents resolution, AVC routes to a human rather than resolving it.

  5. 05

    Case readiness

    The output is a case prepared for review: what is requested, what supports it, what is unresolved, what still needs a person.

Integration

A direction, not a capability.

AVC is designed so that integration is possible in several directions. None of them are shipped, and we are not going to describe a roadmap as if it were a connector list.

What a first engagement realistically looks like is a structured case exchange scoped to a pilot, agreed with your technical team, inside whatever boundary your security review sets.

What we do not promise

We do not promise integration with HSRM or any VA system. That would require technical access, contractual permission, satisfied security requirements and verified workflow requirements. AVC has none of the four, and claiming otherwise would be the fastest way to waste your time.

Possible integration surfaces

Directions under consideration. Not available today.

  • Administrator platforms
  • Claims systems
  • Clearinghouses
  • Practice-management software
  • Imaging systems
  • EDI transactions
  • Application programming interfaces

Security posture

Controls we build. Certifications we do not have.

AVC is preparing for federal-grade security requirements. It has not completed any third-party security certification or federal authorization, and it does not describe itself as though it had.

You will run a security review before anything else happens. This is what there is to review today.

Security & governance detail

  • Encryption in transit
  • Encryption at rest
  • Multi-factor authentication
  • Role-based access control
  • Tenant isolation
  • Access logging
  • Secrets management
  • Key rotation
  • Encrypted backups
  • Audit history

Where AVC stops

AVC prepares the decision. Humans make it.

The boundary is not a disclaimer bolted onto the product. It is the reason the product can be integrated at all: AVC organizes evidence and applies documented rules, and it is built so that it cannot exercise clinical or benefits judgment.

A technical failure never becomes an authorization conclusion. Where confidence is insufficient, the case is routed to a person and labelled as such.

AVC does not

  • Determine Veteran eligibility
  • Diagnose dental disease
  • Approve or deny treatment
  • Replace a licensed clinician
  • Submit a request without a human

Request a pilot

The realistic first step is a workflow conversation.

We are not asking for a procurement decision. We are asking for time with the people who see dental authorization volume: where the queue actually slows, what a reviewer has to rebuild by hand, and which parts of this a specialized layer has no business touching.

If that conversation says AVC is solving a problem you do not have, that is a useful answer and we would rather hear it now.