Prior-authorization assistant

Receive the order (procedure, diagnosis codes, patient), fetch the payer's criteria for that procedure, pull relevant records from the EHR via FHIR, check each criterion against evidence one by one with citations to source documents, flag missing evidence, draft the request packet, and route it to a clinician for review and sign-off before submission.

For every criterion store the decision (met, not met, missing), the exact evidence quote with document ID, date and author, the model's reasoning, and the reviewer's confirmation, so payers and auditors can follow every claim.

Retrieve from the patient's actual records only, require verbatim quotes with document references, verify quotes exist in the source with code, mark criteria as missing rather than inferring, and have clinicians confirm before submission.

Use providers and hosting covered by a BAA, keep only the minimum data needed, encrypt it in transit and at rest, control access by role, audit every access and action, mask data in traces, and keep a clinician responsible for every decision. Follow HIPAA in the US and local equivalents elsewhere.

Each criterion gets its own evidence and a clear met / not met / missing result, which is easier to verify, explain to the payer and evaluate. One overall answer hides which part was weak and invites hallucination.

Payer criteria come from policy documents that change by payer and plan; patient evidence comes from the EHR. Keeping them separate lets you version policies, cite both sources and update one without affecting the other.

Ingest policy documents with version and effective dates, re-extract structured criteria when they change, review extraction with clinical staff, and apply the version in effect on the service date.

Use providers with business associate agreements or equivalent contracts, minimise data sent to models, encrypt data in transit and at rest, log access, restrict roles, avoid using PHI for training, and keep audit trails.

Each criterion with status, highlighted evidence quotes linked to source documents, missing items to address, the drafted letter of medical necessity, and buttons to approve, edit or return with comments.

Compare criterion decisions with clinician-labelled cases, track approval rates and denial reasons from payers, time saved per request, and the share of drafts sent without edits.

Use FHIR APIs (Patient, Condition, Observation, MedicationRequest, DocumentReference) with SMART on FHIR authorisation, and fall back to HL7 v2 feeds or document exports where FHIR is limited.

Chunk notes by section with metadata (date, author, note type), use medical-domain embeddings or hybrid search, and extract findings with structured output tied to note IDs.

Store the request with patient, provider, payer and plan IDs, procedure and diagnosis codes, the policy version used, and one record per criterion with status, cited evidence (document, page, quote) and reviewer decision. Keep the generated packet and submission status linked for audit.

Load code sets and payer policies as versioned reference data with effective dates, select the version valid on the request's service date, re-run criterion extraction when a policy changes, and flag in-flight requests affected by the update.

Fast Healthcare Interoperability Resources: an HL7 standard for exchanging health data through REST APIs, using resources such as Patient, Condition, Observation and MedicationRequest. Most modern EHRs expose FHIR APIs, which lets an agent read records in a standard way.

Mark the criterion as missing, list what is needed (for example six weeks of physical therapy notes), and create a task for staff to obtain it rather than submitting an incomplete request.

Map each payer's submission requirements into templates, generate packets per template, and use payer APIs (such as the emerging FHIR-based prior auth APIs) or portals for submission.

Clinical and legal responsibility stays with licensed staff, models can misread records, and regulations and payer rules require accountable human decisions for medical necessity.

Compare extracted criteria with manually curated lists for a sample of policies, measuring missed and extra criteria, and require review when policies are new.

Store denial reasons, analyse common gaps, and reuse the evidence pipeline to draft appeal letters addressing the stated reason, with clinician review.

Minutes rather than seconds are acceptable for drafting, so the workflow can run asynchronously and notify staff when a packet is ready, using more thorough checks.

Scope the assistant to documentation and criteria matching, keep clinical decisions with clinicians, and filter outputs that recommend treatments.

Use de-identified or synthetic patient records, test with policy documents for real procedures, and run pilots in a sandbox EHR before production.

Detect urgency from the order and clinician input, put the request on a priority queue with a tighter service target, notify the reviewer immediately, and use the payer's expedited submission route and timelines.

Record the submission reference, poll or receive status updates through the payer portal, clearinghouse or API, update the request status, and alert staff on denials or requests for more information with the payer's stated reason.

Pre-fill the packet from structured EHR data, show only the criteria still unresolved, highlight the exact evidence quotes, let reviewers accept or edit with one click, and learn which evidence types each payer usually requires.

Show confidence and missing evidence clearly, require reviewers to open cited evidence for low-confidence criteria, sample decisions for second review, and track how often reviewers change the draft; a rate near zero may mean rubber-stamping.

ICD-10 codes describe diagnoses; CPT (and HCPCS) codes describe procedures and services. Prior authorisation requests pair them to justify medical necessity.

Normalise to text with OCR where needed, keep the original document reference, and translate only for matching while quoting the original.

Who accessed which records, what the system extracted, what was sent externally, and who approved submissions, retained per regulation.

Start with high-volume procedures with clear criteria, train staff on the review screen, measure time saved and accuracy, then expand procedure by procedure.

Track turnaround time from order to submission, first-pass approval rate, denial reasons, staff minutes per request and the share of drafts accepted with no edits, compared with the period before rollout.

1. AA confident summary
2. BThe model's opinion only
3. CNothing
4. DA verbatim evidence quote with document referenceCorrect answer

Why: Auditors must verify every claim.

1. AThe payer
2. BThe patient
3. CA licensed clinicianCorrect answer
4. DThe model

Why: Responsibility stays with clinicians.

1. ASubmit anyway
2. BDelete the criterion
3. CMark it missing and request itCorrect answer
4. DInfer it

Why: Incomplete requests get denied.

1. ASOAP 1.0 only
2. BSMTP
3. CFHIRCorrect answer
4. DGraphQL only

Why: FHIR is the HL7 standard for healthcare data exchange over REST.

1. ANobody
2. BThe clinicianCorrect answer
3. CThe vector store
4. DThe patient's employer

Why: Clinical responsibility stays with the clinician; the agent only drafts.

1. ASMTP
2. BCSV
3. CSOAP only
4. DFHIRCorrect answer

Why: With SMART on FHIR auth.

1. AThe version in effect on the service dateCorrect answer
2. BThe newest always
3. CThe oldest
4. DAny version

Why: Policies change over time.

1. ATrusting the model
2. BCode verifies quotes exist in the sourceCorrect answer
3. CHigher temperature
4. DLonger prompts

Why: Exact matching against records.

1. ACode licences
2. BHandling of patient data by vendorsCorrect answer
3. CMarketing rights
4. DServer colours

Why: Required for PHI processing.

1. ANumber of tokens
2. BServer CPU
3. CPrompt length
4. DShare sent without editsCorrect answer

Why: Plus payer approval rates.

1. ARandom lines
2. BWhole patient history
3. CSection with date and author metadataCorrect answer
4. DFixed bytes

Why: Keeps citations precise.

1. AStatus, cited evidence and the reviewer's decisionCorrect answer
2. BOnly a yes or no
3. CThe model's temperature
4. DThe patient's photo

Why: Auditors need the evidence and who decided.

1. AThe oldest on file
2. BWhichever the model prefers
3. CThe one in effect on the service dateCorrect answer
4. DAlways the newest

Why: Coverage rules are tied to dates.

1. AAsk the clinic for itCorrect answer
2. BMark the criterion as met
3. CSkip the request
4. DInfer it from similar patients

Why: Guessing clinical facts is unsafe; it should request the missing documentation.

1. AZIP codes
2. BSKU codes
3. CCPT and HCPCSCorrect answer
4. DICD-10

Why: ICD-10 describes diagnoses.

1. AThey come from different, versioned sourcesCorrect answer
2. BTo save memory
3. CModels require it
4. DIt is faster to type

Why: Update one without the other.

1. AA new model
2. BThe CDN
3. CThe evidence pipeline with denial reasonsCorrect answer
4. DNothing

Why: Draft appeal letters with review.

1. ARandom text
2. BDe-identified or synthetic recordsCorrect answer
3. CReal patient data in staging
4. DSocial media

Why: Protect privacy in testing.

1. ACiting documents
2. BListing missing items
3. CDrafting packets
4. DRecommending treatmentsCorrect answer

Why: Clinical decisions stay human.

1. ADays
2. BExactly one second
3. CMinutes, running asynchronouslyCorrect answer
4. DUnder 10 ms

Why: Thoroughness beats speed here.

1. ANothing
2. BRecord access, extractions and approvalsCorrect answer
3. COnly errors
4. DOnly logins

Why: Required by regulation.

1. AWith versions and effective datesCorrect answer
2. BWithout dates
3. COnce ever
4. DFrom memory

Why: Apply the right version.

1. AHandled after routine ones
2. BSubmitted without review
3. CIgnored until morning
4. DPlaced on a priority queue with tighter targetsCorrect answer

Why: Urgent care cannot wait for the normal queue.

1. ATrack the payer's status and reasonsCorrect answer
2. BDelete the packet
3. CAssume approval
4. DEmail the patient the full record

Why: Denials and information requests need fast follow-up.

1. ARubber-stamping from automation biasCorrect answer
2. BA perfect model
3. CNetwork problems
4. DToo many reviewers

Why: Some edits are expected if reviewers are reading closely.

1. APre-filling from EHR data and highlighting evidenceCorrect answer
2. BLonger forms
3. CRemoving citations
4. DAdding more approval steps

Why: Reviewers focus only on unresolved criteria.

1. ARare cases first
2. BNowhere
3. CHigh-volume procedures with clear criteriaCorrect answer
4. DEvery procedure at once

Why: Measure, then expand.

1. ABilling data only
2. BThe minimum data necessaryCorrect answer
3. CThe full hospital database
4. DPasswords

Why: Data minimisation protects privacy.

1. ADeleting
2. BOCR with the original reference keptCorrect answer
3. CTo be ignored
4. DManual retyping only

Why: Quote the original source.

1. APractitioner
2. BDocumentReferenceCorrect answer
3. CPatient only
4. DBundle only

Why: Points to notes and reports.

1. AMarketing
2. BIgnoring payers
3. CNothing
4. DFixing evidence gaps in future requestsCorrect answer

Why: Each denial teaches what to fix.

1. AServer CPU
2. BPage views
3. CFirst-pass approval rateCorrect answer
4. DNumber of logins

Why: Fewer resubmissions mean better packets.