Genflare · Program Design Document

Intake Automation. PDD.

Phase 1: Prior Authorization Patient Intake. Scope, process requirements, and phased build plan — structured so any engineering team can translate directly into buildable work.

Scope
PA intake, Lumara
User stories
22 across 5 phases
Source materials
7 workflow recordings + walkthrough
Status
Engineering-ready spec
Executive Summary

A single intake specialist is the front door to the entire PA pipeline.

The Lumara PA operation is staffed by a team of PA specialists managing the full authorization lifecycle. Before any case reaches a PA specialist, however, every piece of clinical documentation must pass through intake: downloading, sorting, classifying, reviewing, and routing inbound documents.

Today, intake is handled by a single specialist processing approximately 80 documents per day across a fully manual workflow. While the broader PA team is well-staffed for downstream authorization work, the front door to that pipeline is a single point of failure. As patient volume grows, intake becomes the constraint — every document that doesn't get processed on time delays a PA specialist's ability to begin authorization work.

This document defines the product requirements for automating the intake workflow. It is structured as a detailed current-state process description followed by 22 user stories organized into five build phases. Each phase is independently deliverable and testable. Phases 1A and 1B are recommended for the first sprint (highest volume, most mechanical work, easiest to validate). Each user story includes acceptance criteria that define "done."

This document is technology-agnostic. It defines what the automated system must do, not how it should be built. It can be used by any engineering team — internal or external — to scope, estimate, and deliver a solution.

Overview & Scope

What this document covers, and doesn't.

In scope

  • Current-state process: a detailed walkthrough of how intake works today, derived from workflow recordings and a live process walkthrough with the intake specialist
  • Business rules and decision logic: the specific rules, naming conventions, review criteria, and routing logic the automated system must replicate
  • User stories with acceptance criteria: scoped, sequenced work packages (1A through 1E) written so any engineering team can translate directly into buildable work

Out of scope

  • Technology selection or architecture decisions (the engineering team determines the technical approach)
  • PA specialist workflows downstream of handoff (covered in the separate Workflow Deep Analysis document)
  • Vendor evaluation or build-vs-buy analysis
  • Appeal preparation, payer escalation processes, or payer interaction automation
Current State · Volume & Workload

What the intake specialist handles today.

Captured during a live walkthrough with the intake specialist. Volume is cyclical, with end-of-quarter and seasonal peaks driving significantly higher intake.

~80
Documents processed per day
7
Workflows mapped via Scribe
265
Manual steps documented
Current Intake Process

End-to-end, as it operates today.

This section serves as the functional specification for the user stories that follow. Every step, naming convention, and decision point described here must be accounted for in the build.

Step 1

Gmail Inbox Monitoring & Document Download

All inbound documentation arrives in a shared Gmail inbox (the "reimbursement" inbox). Documents come primarily from treatment sites via fax-to-email or direct email, and occasionally from territory managers or sales reps who forward documentation.

Email processing follows a FIFO order under normal conditions. When volume is high, the intake specialist labels emails by document type and prioritizes: approvals first, then pulmonologist evaluations, other insurance communications, and biomarker eval reports last.

Approximately 80–85% of emails in the inbox are actionable intake documents. The remaining 15–20% consists of internal communications, occasional invoices, solicitation emails, and claims questions (auto-forwarded out of the intake queue).

"I always just begin with downloading the PDF to a specific designated file… I have my downloads and then inside downloads, I have a specific folder that all of these go into."
Step 2

Page Sorting & Extraction

Each downloaded PDF is opened in Adobe Acrobat for manual page-level sorting:

  • Cover page handling: ~90% of faxes include a cover page (always first when present). Cover pages may contain useful information (insurance details, scheduling) and are saved separately.
  • Facesheet extraction: If the document contains a facesheet (patient demographics and insurance), it is extracted as a separate PDF using Adobe's Extract Pages function.
  • Quick scan: Rapid visual pass through the remaining pages to confirm document type and verify single-patient content.
Step 3

Patient Lookup & Folder Management

Before filing, the intake specialist checks whether the patient already exists in both Salesforce and the shared file system:

  • Salesforce search by patient name to find existing Account and Case records. If no record exists, the Account/Case creation process is triggered.
  • Shared drive search by last name first, then by date of birth, to find an existing patient folder.
  • Duplicate prevention: if a matching DOB appears for a different patient, no duplicate is created.

Patient folders organize by state and territory. Each patient gets a root folder with subfolders for ADMIN, CLINICALS, and DNU (Do Not Use / superseded documents).

Step 4

Naming Convention & Filing

Every document is saved using a strict naming convention manually applied via copy-paste: Lastname_Firstname DOB DocType Date.

Clinical documents are uploaded to the patient's Evaluation record in Salesforce. Insurance letters and payer communications are uploaded to the Prior Authorization record. Multi-select upload is used when multiple files are filed for a single patient.

Step 5

Email Organization

After filing, the intake specialist returns to Gmail to organize the source email:

  • Email subject is renamed to match the patient naming convention for future searchability.
  • A label is applied (e.g., "Intake Documentation" or "Insurance Communications").
  • The email is moved to a folder organized by site or territory.
Step 6

Salesforce Data Entry

For new patients, the intake specialist creates an Account and Case in Salesforce with demographics, territory, and insurance information extracted from the facesheet. Fields include patient name, DOB, address, territory, treatment site, carrier, plan type, member ID, and group number.

For leads without a full Account, a Lead Conversion workflow is required — detective work when PHI is incomplete.

Build Phases

22 user stories. Five phases. Sequenced for impact.

The intake automation is broken into five phases. Each phase is independently deliverable and testable. Phases 1A and 1B are the recommended first sprint. Phases 1C–1E are subsequent sprints and will be refined based on learnings from the first.

Each user story is written from the perspective of the people who will use the system. Acceptance criteria (AC) define "done." The Salesforce integration is the foundation layer underlying all phases.

Phase 1A · Sprint 1

Email-to-Document Pipeline

Inbox monitoring, document download, page sorting, document classification.
Current manual steps covered
Biomarker Eval Download (71 steps) — Steps 1–25: Download, open in Adobe, sort pages, extract facesheet
Consult Upload (44 steps) — Steps 1–12: Download and save consult documentation
Insurance Letter Filing (45 steps) — Steps 1–10: Download and identify letter type
US-1A.1

Inbox Monitoring

As the intake specialist, I need the system to continuously watch the shared inbox so that new documents are detected and queued without manual polling.
Acceptance Criteria
  • System polls the shared Gmail inbox at a configurable interval (recommended: every 5 minutes or near-real-time)
  • Emails with PDF attachments are flagged as candidates for processing
  • Emails without attachments, or with only non-PDF attachments (e.g., .png signatures), are skipped
  • System distinguishes clinical intake emails from non-clinical correspondence (internal team emails, vendor communications, automated notifications)
  • Processing queue is visible to the intake specialist so they can see what's pending and override priority if needed
US-1A.2

Document Download & Staging

As the intake specialist, I need every PDF attachment from valid intake emails saved to a staging area so I can review what's been pulled in for processing.
Acceptance Criteria
  • All PDF attachments from identified clinical emails are downloaded automatically
  • Multi-attachment emails have each PDF downloaded as a separate file
  • Original filename is preserved alongside a system-generated processing ID for audit trail
  • Download failures are logged and retried; persistent failures alert the intake specialist
  • Staging area is accessible for manual review if needed
US-1A.3

Page-Level Sorting & Extraction

As the intake specialist, I need multi-page bundled PDFs split into their component documents so that each document type can be filed independently.
Acceptance Criteria
  • Cover pages (fax transmission pages) are identified and saved separately (may contain useful insurance or scheduling information) — target: ≥90% accuracy
  • Facesheets (patient demographics/insurance pages) are extracted as separate documents — target: ≥98% accuracy
  • Remaining clinical content is kept intact as one or more documents based on type boundaries
  • System detects and separates multi-patient documents bundled in a single PDF
  • When splitting is ambiguous, the system flags for manual review rather than guessing
US-1A.4

Document Classification

As the intake specialist, I need each document tagged with its type so downstream filing and routing logic knows where it goes.
Acceptance Criteria
  • Document type correctly classified — target: ≥95% accuracy measured against the intake specialist's manual classification on 100 consecutive documents
  • Supported types: Biomarker Eval, Spirometry/PFT, Pulmonologist Consult, Allergist Eval, Referral, Facesheet, Insurance Letter (sub-classified: Approval, Denial, Notice/Other), Unknown
  • "Unknown" type documents are flagged for manual classification rather than misrouted
  • Classification confidence score is visible to the intake specialist so they can spot-check low-confidence results
Phase 1B · Sprint 1

Filing, Salesforce Write-Back & Email Organization

Naming convention, shared drive filing, Salesforce upload, email organization, account creation.
Current manual steps covered
Biomarker Eval Download (71 steps) — Steps 26–71: Naming, folder creation, save, SF upload, email organization
Consult Upload (44 steps) — Steps 13–44: Save with naming convention, upload to SF
Insurance Letter Filing (45 steps) — Steps 11–45: Save, upload to PA tab, create specialist task
Creating New Account & Case (36 steps); Converting Leads (12 steps); Save Email to Salesforce (8 steps)
US-1B.1

Apply Naming Convention

As the intake specialist, I need every document renamed correctly so that downstream search and audit functions work consistently.
Acceptance Criteria
  • Patient name extracted from document content or matched against Salesforce records
  • DOB formatted as M.DD.YY (e.g., 6.15.92) per convention
  • Document type appended per convention: "Pulm Eval M.DD.YY", "Biomarker Report M.DD.YY", "Facesheet", "Denial letter M.DD.YY", etc.
  • Version numbering applied where applicable (e.g., "v2" on follow-up consults)
  • Naming convention correctly applied — target: ≥98% accuracy on spot-check of 50 documents
US-1B.2

File to Shared Drive

As the intake specialist, I need documents saved to the correct patient folder so the file system stays organized.
Acceptance Criteria
  • Existing patient folders are found by matching patient name and DOB
  • When no folder exists, a new one is created following the convention: CaseNumber Lastname_Firstname DOB
  • Documents routed to correct subfolder: CLINICALS for clinical docs, ADMIN for administrative
  • Unknown territory uses "Unk" folder as default
  • Filing accuracy — target: ≥98% to correct patient folder
US-1B.3

Upload to Salesforce

As the intake specialist, I need documents uploaded to the right Salesforce record so the PA specialists see everything in context.
Acceptance Criteria
  • Clinical documents uploaded to the patient's Evaluation record; insurance letters and payer communications uploaded to the Prior Authorization record
  • Insurance letters uploaded to the Prior Authorizations tab, NOT general documents
  • Upload linked to correct patient Account and Case — target: ≥98% accuracy
  • Upload failures logged and retried; persistent failures alert the intake specialist
US-1B.4

Email Organization & Logging

As the intake specialist, I need the source email organized and logged automatically so I don't have to return to Gmail after every document.
Acceptance Criteria
  • Email subject renamed to match patient naming convention
  • Label applied: "Intake Documentation" for clinical docs, "Insurance Communications" for insurance letters
  • Email moved to the correct site/territory Gmail folder
  • Email logged to Salesforce Activity on the patient's record
  • For emailed documents (not faxes), acknowledgment reply sent to sender confirming receipt
US-1B.5

Account & Case Creation for New Patients

As the intake specialist, I need new patient records created automatically from the facesheet so I'm not retyping demographics into Salesforce.
Acceptance Criteria
  • Patient demographics extracted from facesheet: name, DOB, address, email, phone numbers, and zip code
  • Salesforce Account created with correct fields populated
  • Linked Case record created
  • Insurance information entered from facesheet: primary insurance name and plan type (if known)
  • Account Owner and Case Owner assigned automatically based on patient zip code
  • For ambiguous matches (similar names, missing data), system flags for manual confirmation rather than creating duplicates
Phase 1C · Sprint 2

Clinical Review Assistance

Pre-extract structured clinical findings from biomarker evals and pulmonologist consults so the reviewer focuses on judgment, not data entry.
Current manual steps covered
Biomarker Review Examples 1, 2, and 3 (20–24 steps each) — Full clinical review criteria
Intake specialist live walkthrough — Pulmonologist consult five-point verification
US-1C.1

Extract Biomarker Values

As the reviewer, I need eosinophil count and FeNO values pulled from biomarker eval reports so I can verify eligibility quickly.
Acceptance Criteria
  • Eosinophil count (absolute and/or percentage) correctly extracted — target: ≥90% accuracy on 100 documents
  • FeNO value (ppb) extracted when present
  • IgE level extracted when present
  • Source page number and approximate location provided for verification
  • Common label variants handled: "EOS", "Eos count", "FeNO", "Fractional Exhaled Nitric Oxide"
  • When values are reported in non-standard units, system flags for manual review
US-1C.2

Extract Exacerbation History

As the reviewer, I need exacerbation history extracted from clinical notes so I can assess severity without reading the full chart.
Acceptance Criteria
  • Exacerbation count in past 12 months extracted from narrative when documented
  • Severity characterized when possible (ER visits, hospitalizations, oral corticosteroid bursts)
  • Asthma Control Test (ACT) score extracted when present
  • When exacerbation history is unclear or implied rather than stated, system flags for manual review
  • Exacerbation status correctly identified — target: ≥85% accuracy
US-1C.3

Extract Provider Recommendation

As the reviewer, I need the provider's biologic recommendation extracted so I can confirm the prescriber's intent clearly.
Acceptance Criteria
  • Provider recommendation for Lumara candidacy extracted when explicitly stated
  • When absent, system indicates "not found" (distinct from "negative recommendation")
  • Prior therapy failures flagged when documented (e.g., failed ICS/LABA, failed alternative biologic)
  • Source text quoted so the reviewer can see exactly what the provider wrote
US-1C.4

Five-Point Verification on Pulmonologist Consult

As the reviewer, I need the five required data points extracted from pulmonologist consults so I can confirm eligibility in one view.
Acceptance Criteria
  • Patient age calculated from DOB and verified against label-eligible age
  • Asthma phenotype identified: eosinophilic vs. allergic vs. mixed indicators
  • Date of diagnosis located in narrative
  • Treatment plan statement extracted (Lumara initiation reference)
  • Diagnosis codes extracted when present; flagged as missing when absent
  • All five fields presented in a single structured view matching the team's review template
US-1C.5

Confidence Scoring

As the reviewer, I need confidence levels on every extraction so I know what to trust and what to double-check.
Acceptance Criteria
  • Each extracted field shows High / Medium / Low confidence
  • High confidence: clear, unambiguous extraction from well-formatted text
  • Medium confidence: extracted but from variable formatting, multiple possible values, or partially obscured text
  • Low confidence: best guess from poor-quality scan, ambiguous language, or non-standard format
  • Low-confidence fields are visually highlighted so they stand out during review
US-1C.6

Triage Recommendation

As the reviewer, I need the system to suggest a triage outcome so I can confirm or override with a single click.
Acceptance Criteria
  • Recommended triage matches the reviewer's determination — target: ≥85% agreement
  • Pass: all criteria met with high confidence
  • Pending: one or more criteria missing or low confidence — specific missing items listed
  • Fail: hard-stop criteria triggered (off-label phenotype, severe non-compliance)
  • The reviewer can override the recommendation with one click and a brief note
  • Review time per document reduced — target: ≥50% reduction vs. fully manual review
Phase 1D · Sprint 3

Routing & Specialist Handoff

Territory lookup, PA packet assembly, and Salesforce task creation that gets approved cases into a PA specialist's queue without manual coordination.
Current manual steps covered
Documentation Review Complete Process (49 steps) — PA packet assembly, territory lookup, task creation
Creating a Task (12 steps) — Task creation mechanics in Salesforce
US-1D.1

Territory-to-Specialist Routing

As the intake specialist, I need the correct PA specialist identified automatically so I'm not manually checking a spreadsheet for every handoff.
Acceptance Criteria
  • Patient territory retrieved from Salesforce profile
  • Territory mapped to PA specialist using the routing table
  • Correct specialist assigned — target: ≥98% accuracy against 50 consecutive handoffs
  • When mapping is ambiguous or territory is not in the table, system flags for manual assignment
  • Routing table is maintainable by the team (admin-editable config, not hardcoded)
US-1D.2

PA Packet Assembly

As the PA specialist, I need the complete PA packet assembled before the case lands in my queue so I can begin authorization work immediately.
Acceptance Criteria
  • PA Packet includes: Biomarker Eval + Pulmonologist Consult + supporting documentation, in defined order
  • Packet saved to patient's CLINICALS subfolder
  • Packet naming follows patient naming convention
  • Packet correctly assembled — target: ≥95% (all required documents included, correct order)
US-1D.3

Specialist Task Creation

As the PA specialist, I need a new task created in my Salesforce queue so I know exactly which cases are ready for authorization.
Acceptance Criteria
  • Task created in Salesforce with subject "***DOCUMENTATION RVW COMPLETE***"
  • Task assigned to correct PA specialist (from US-1D.1)
  • Task linked to the patient's Case record
  • Task appears in the specialist's task queue immediately
  • Task creation succeeds 100% of the time for pass cases
Phase 1E · Sprint 4

Exception Handling & Correction Loops

When documentation is incomplete, the system drafts a correction request to the territory manager and keeps the case on a follow-up clock.
Current manual steps covered
How to Request Updates/Edits on Documentation (66 steps) — Full correction request workflow
When Updates Are Needed for Documentation (66 steps) — Trigger criteria and examples
US-1E.1

Draft Correction Request

As the intake specialist, I need correction request emails drafted automatically so I can send them with a quick review rather than starting from scratch each time.
Acceptance Criteria
  • Correct correction category identified from review findings — target: ≥90% accuracy
  • Categories: missing diagnosis, off-label phenotype unclear, missing biomarker confirmation, missing exacerbation history, eosinophil count below threshold
  • Email draft includes: patient name (hyperlinked to Salesforce Evaluation record), specific missing items, what is needed from the territory manager/site
  • Email language matches the tone and specificity of the existing templates
  • Draft presented for the intake specialist's review before sending (human-in-the-loop for v1)
US-1E.2

Identify & Route to Territory Manager

As the intake specialist, I need the correct territory manager identified automatically so the correction request goes to the right person without manual lookup.
Acceptance Criteria
  • Territory Manager identified from the facility's Salesforce account record
  • Email addressed to Territory Manager (not to the treatment site directly)
  • Correct recipient — target: ≥98% accuracy against Salesforce facility records
  • When Territory Manager is not found or ambiguous, system flags for manual entry
US-1E.3

Create Follow-Up Task

As the intake specialist, I need a follow-up task created automatically so no pending correction request falls through the cracks.
Acceptance Criteria
  • Follow-up task created in Salesforce, assigned to the intake specialist who handled the case
  • Task due date set to 1 week from the correction request date
  • Task includes context: which correction was requested, which TM was contacted
  • 100% of pending cases have a follow-up task — no exceptions
US-1E.4

Template Management & Audit

As the PA operations lead, I need email templates editable by the team so language can evolve without engineering work, and every sent email logged for audit.
Acceptance Criteria
  • Email content reviewed and approved by the PA operations lead before template is activated
  • Templates are editable by the team (not hardcoded) so language can be updated without engineering work
  • Sent emails are logged to Salesforce Activity on the patient's Evaluation record for audit trail