Platform architecture

How PriorPilot works, step by step.

A technical walkthrough for IT and operations teams: how requirements are checked, how payer policy is read, where evidence comes from in the chart, and how requests reach the payer.

System overview

How the system is put together.

Integration layer

•SMART on FHIR (EHR launch + backend services)
•CDS Hooks service (Da Vinci CRD 2.2.1: order-sign, order-dispatch, appointment-book, …)
•FHIR R4 / US Core reads, Subscriptions
•HL7v2 ADT/ORM feeds where FHIR is unavailable

Intelligence layer

•Coverage resolver (plan, line of business, delegated UM vendor)
•Policy compiler → versioned criteria graphs
•Clinical evidence engine (FHIR + note NLP)
•Grounding verifier & rule checker

Execution layer

•DTR questionnaire auto-population
•Packet builder (LMN, attachments, cover sheets)
•Submission router (PAS · X12 278 · NCPDP · portal · fax)
•Case state machine, pend & appeal workflows

Trust layer

•Tenant-isolated PHI vault, field-level encryption
•Immutable audit log of every read, inference, and edit
•Human review queues with attestation capture
•Offline evaluation & drift monitoring

EHR order→

CDS Hooks→

Coverage resolver→

Policy graph→

Evidence engine→

Verifier→

Clinician review→

Submission router→

Payer→

Case tracker

Stage 1 · Detect

Checking requirements when the order is signed.

PriorPilot registers as a CDS Hooks service. When a clinician signs an order, the EHR sends the draft ServiceRequest or MedicationRequest with prefetched Coverage, Patient, and Condition resources. The coverage resolver maps the member to plan, line of business, and any delegated utilization-management vendor, then evaluates payer rules for the service code and place of service.

→Implements all six CRD 2.2.1 hooks, appointment-book, encounter-start, encounter-discharge, order-dispatch, order-select, and order-sign.
→Payer CRD endpoints are called directly when available; otherwise our rules corpus answers.
→Results return as CDS cards in under a second, with a SMART launch link into the evidence review.
→Orders placed outside CDS Hooks are picked up from FHIR Subscriptions or HL7v2 order feeds.

order-sign request (abridged)

POST /cds-services/priorpilot-order-sign
{
  "hook": "order-sign",
  "hookInstance": "d1577c69-dfbe-44ad-ba6d-3e05e953b2ea",
  "fhirServer": "https://ehr.example.org/fhir/R4",
  "context": {
    "userId": "Practitioner/pr-1042",
    "patientId": "pt-58213",
    "encounterId": "enc-90311",
    "draftOrders": { "resourceType": "Bundle", "entry": [{
      "resource": {
        "resourceType": "ServiceRequest",
        "status": "draft",
        "code": { "coding": [{ "system": "http://www.ama-assn.org/go/cpt", "code": "72148" }] },
        "reasonCode": [{ "coding": [{ "system": "http://hl7.org/fhir/sid/icd-10-cm", "code": "M54.16" }] }],
        "insurance": [{ "reference": "Coverage/cov-7781" }]
      }
    }]}
  },
  "prefetch": { "coverage": "...", "patient": "...", "conditions": "..." }
}

CDS card response

{
  "cards": [{
    "summary": "Prior authorization required, 4 of 4 criteria met in chart",
    "indicator": "warning",
    "source": { "label": "PriorPilot AI" },
    "suggestions": [{
      "label": "Prepare authorization packet",
      "actions": [{ "type": "update", "description": "Annotate order with coverage information" }]
    }],
    "links": [{ "label": "Review evidence & sign", "type": "smart",
                "url": "https://app.priorpilotai.com/launch" }]
  }]
}

compiled policy · criteria graph

policy "advanced-imaging/mri-lumbar" version "2026.3" {
  applies_to   cpt in [72148, 72149, 72158]
  payer        "commercial-ppo"

  criterion red_flags_or_duration {
    any_of {
      condition.code in valueset("red-flag-low-back")      # cauda equina, cancer, infection
      duration(condition.onset, order.date) >= 6 weeks
    }
  }
  criterion conservative_therapy {
    evidence  procedure.code in valueset("physical-therapy") or note.mentions("physical therapy")
    require   total_duration >= 6 weeks within 6 months
  }
  criterion neuro_deficit  { evidence observation in valueset("neuro-exam-abnormal") }
  criterion no_recent_imaging {
    absent    diagnostic_report.code in valueset("lumbar-imaging") within 12 months
  }
  decision = all_of(red_flags_or_duration, conservative_therapy, neuro_deficit, no_recent_imaging)
}

Stage 2 · Interpret

Turning payer policy into checklists.

Medical policies arrive as PDFs and web pages that change without notice. Our policy compiler ingests each revision, uses an LLM with structured outputs to extract criteria, and emits a typed criteria graph, conditions, durations, value sets, exclusions, and the boolean logic that joins them. Each graph is versioned, diffed against its predecessor, and reviewed before release.

→Value sets bind to ICD-10-CM, CPT/HCPCS, LOINC, RxNorm, and SNOMED CT.
→Policy diffs trigger re-evaluation of every open case under that policy.
→Public sources (payer policies, Medicare NCDs and LCDs) are compiled directly; licensed criteria sets are supported where the customer holds a license.

Stage 3 · Ground

Finding the evidence in the chart.

For every criterion, the engine first queries structured FHIR data, Conditions, Observations, Procedures, MedicationRequests, DiagnosticReports. Where the answer lives in narrative text, it retrieves candidate passages from DocumentReferences with hybrid lexical-plus-embedding search, then asks a model to extract a normalized answer with a verbatim quote.

Retrieval

Structured-first FHIR queries; hybrid passage retrieval over notes, scoped by encounter and date window.

Extraction

Schema-constrained output: status, normalized values, quote, character offsets.

Verification

Quote must exist verbatim at the cited offsets; dates, durations, codes, and thresholds re-checked deterministically.

Abstention

Ambiguous or conflicting evidence becomes 'needs review' with the competing spans attached.

criterion result

{
  "criterion": "conservative_therapy",
  "status": "met",                       // met | not_met | needs_review
  "confidence": 0.96,
  "evidence": [{
    "resource": "DocumentReference/40217",
    "span": { "start": 412, "end": 488 },
    "quote": "completed 7 weeks of PT with no meaningful relief of radicular symptoms",
    "normalized": { "therapy": "physical therapy", "duration_weeks": 7 }
  }],
  "checks": [
    { "rule": "quote_in_source",  "pass": true },
    { "rule": "duration>=6w",     "pass": true },
    { "rule": "within_6_months",  "pass": true }
  ]
}

Stage 4 · Assemble

Filling in the payer's questions.

When a payer publishes Da Vinci DTR (2.2.0) questionnaires, PriorPilot retrieves the FHIR Questionnaire and its CQL, pre-populates answers from the evidence graph, and presents only the unanswered items to staff. For payers without DTR, the same evidence fills payer-specific forms and drafts a letter of medical necessity in which every sentence carries a citation.

FHIR Questionnaire / SDCCQL pre-populationQuestionnaireResponseLMN draftingAttachment selection

Stage 5 · Submit

Sending the request.

The router picks the best channel each payer supports and normalizes responses back into one case model.

Channel	Standard	Used when
FHIR API	Da Vinci PAS 2.2.1 · Claim/$submit	Payer exposes a Prior Authorization API
EDI	X12 278 005010X217 (+275)	Via clearinghouse connection
Pharmacy	NCPDP SCRIPT ePA	Medication benefits
Portal	Supervised browser agent	Payer-only web portals
Fax	Structured cover + OCR intake	Last resort; responses parsed back

Da Vinci PAS · prior authorization request bundle (abridged)

POST [payer-base]/Claim/$submit
{
  "resourceType": "Bundle",
  "type": "collection",
  "entry": [
    { "resource": { "resourceType": "Claim",
        "use": "preauthorization",
        "status": "active",
        "priority": { "coding": [{ "code": "normal" }] },
        "insurance": [{ "sequence": 1, "focal": true, "coverage": { "reference": "Coverage/cov-7781" } }],
        "diagnosis": [{ "sequence": 1, "diagnosisCodeableConcept": { "coding": [{ "code": "M54.16" }] } }],
        "item": [{ "sequence": 1, "productOrService": { "coding": [{ "code": "72148" }] } }],
        "supportingInfo": [{ "sequence": 1, "category": { "coding": [{ "code": "additionalInformation" }] },
                             "valueReference": { "reference": "QuestionnaireResponse/qr-5512" } }]
    }},
    { "resource": { "resourceType": "Patient", "...": "..." } },
    { "resource": { "resourceType": "Coverage", "...": "..." } },
    { "resource": { "resourceType": "QuestionnaireResponse", "...": "DTR answers + evidence links" } }
  ]
}

Stage 6 · Resolve

Following each request to a decision.

Every authorization is a durable workflow with timers, retries, and escalation, so pends, requests for information, and denials get handled before they become write-offs.

01
DETECTED
Requirement found at order-sign or from payer rules
02
GATHERING
Evidence engine resolving criteria; gaps routed to care team
03
READY
Packet assembled, all claims grounded
04
ATTESTED
Licensed reviewer signed off
05
SUBMITTED
Sent via best available channel; tracking ID stored
06
PENDED
Payer requested information; RFI task created and auto-answered where possible
07
APPROVED / DENIED
Determination captured with reason codes; denials enter the appeal workflow

Pend handling

Status is polled via PAS $inquire or X12 278 inquiry, or received through FHIR Subscriptions; RFIs are answered from the evidence graph where possible.

Denial intelligence

Denial reason codes are mapped to the failing criterion; the model drafts a targeted appeal with new citations and suggests peer-to-peer talking points.

Feedback loop

Every determination updates per-payer, per-policy priors used to predict RFIs and denials on future cases.

AI model stack

Which models do what.

Each task gets the cheapest model that meets its quality bar, measured on our evaluation sets, not a single prompt doing everything.

Classifiers

Requirement detection and routing: gradient-boosted and fine-tuned encoder models over codes, payer, and order context.

Retrieval

Clinical embeddings plus BM25 over note passages, with structured FHIR queries first.

Extraction LLMs

Schema-constrained extraction of criterion status and normalized values, run in batches with cached prompts.

Generation LLMs

Letters of medical necessity and appeals, constrained to cited evidence and checked by the verifier.

Evaluation	Metric	Why it matters
Requirement detection	Recall on 'auth required' against payer-confirmed outcomes	Missed requirements cause denials, weighted most heavily
Criterion classification	Per-criterion precision / recall vs. reviewer labels	Separate tracking for 'needs review' abstentions
Grounding	% of generated claims with verified source spans	Release gate: ungrounded claims must be 0
Packet completeness	First-pass acceptance without RFI	Measured per payer and service line
Turnaround	Order-sign → submission; submission → determination	Tracked against CMS-0057-F timeframes: 72 h expedited, 7 calendar days standard

Want the integration details for your EHR?

We'll walk your team through SMART launch, CDS Hooks registration, scopes, and data flows.

Talk to engineering