TL;DR: Fax triage software classifies each inbound page into a document type — prior authorization determination, referral, pathology result, records request — extracts the identifying fields for that type, and routes it to the queue and person who owns that workflow. For a dermatology clinic, that means a biologic PA denial reaches your PA coordinator on a short clock while a referral packet reaches intake, instead of both sitting in one inbox waiting for someone to open them. Classification is the leverage point: once a fax is typed and matched to a patient, everything downstream becomes automatable.
Why the mixed queue is the actual problem
The complaint most dermatology operations leads have isn't fax volume. It's that the volume is undifferentiated.
Prior authorization determinations for biologics carry deadlines. Referrals carry revenue that goes stale. Pathology results carry clinical urgency. Records requests carry regulatory clocks. All four arrive at the same number, in the same queue, and the only sorting mechanism is a person opening PDFs one at a time until the queue is empty — which, on a busy week, it isn't.
The PA half of that pile is not small. The 2025 AMA prior authorization physician survey found physicians completing an average of 39 prior authorizations a week and spending about 13 hours on the process, with 31% saying requests are often or always denied and 74% reporting denials have increased over five years. Dermatology carries an outsized share of that because biologics for psoriasis, atopic dermatitis, and hidradenitis suppurativa sit squarely in specialty-pharmacy PA territory.
Every one of those determinations comes back on paper, into the same queue as everything else. The cost isn't the reading. It's that nobody knows a denial arrived until someone gets to it.
There's a compounding effect worth naming. The same AMA survey found 93% of physicians reporting that prior authorization delays patient care and 89% saying it contributes to burnout. Some of that is the payer process itself, which no software fixes. But a meaningful slice is self-inflicted queue latency — the hours between a determination arriving and anyone knowing it did. That part is a document-routing problem, and it's the part a practice can actually change.
The four document classes worth separating in dermatology
Classification is only useful if the categories map to different owners and different clocks. In a dermatology practice, four do.
Prior authorization determinations. Approvals and denials from commercial payers and specialty pharmacy benefit managers, covering biologics, Mohs, phototherapy, and select procedures. Fields worth extracting: payer, member ID, authorization number, the drug or service authorized, determination outcome, effective and expiration dates, and any stated appeal deadline. Approvals and denials look nearly identical on the page — classification has to read the outcome line, not the letterhead.
Referrals. Inbound from primary care, urgent care, and occasionally an ER, usually as packets. Fields: patient demographics, referring provider and NPI, reason for referral, urgency indicator, insurance, and whether prior records are attached. The referral is the time-sensitive piece; the attachments can file in parallel.
Pathology and lab results. Biopsy and Mohs reports from outside labs. Fields: patient identifiers, accession number, collection date, specimen site, submitting provider, and diagnosis. These need their own escalation path when the diagnosis is malignant.
Records and forms requests. From attorneys, insurers, disability programs, and other practices. Fields: requester, patient, date range requested, and authorization validity. Not clinical, entirely regulatory, and they should never share a queue with results.
Five document types is where most dermatology practices actually land once you add pharmacy step-therapy paperwork. A routing scheme keyed on sender can't separate them, because one hospital system sends you three of the five.
Why denials need different handling from approvals
This is the routing decision with the most money attached, and most practices treat both outcomes identically because the documents look the same.
An approval is an unblock. It should reach whoever is holding the patient's treatment plan, get logged against the request, and close the loop. Delay costs a day.
A denial is a clock. Appeal windows are often short and payer-specific, and the AMA survey data suggests the volume is going the wrong direction — 74% of physicians report denials rising over five years, while only 20% always appeal, and 67% of non-appealers say they skip it because past experience suggests failure. A denial that sits unrouted for four days is a claim outcome with a dollar value, and unlike a records request nobody notices it's missing until the appeal window has closed.
What good routing looks like on a determination:
- Outcome drives the destination. Denials go to the appeals owner, approvals to the treatment coordinator. Two lanes, not one.
- Appeal deadlines get extracted and tracked. If the letter states a date, that date should land in a work queue with the document, not stay buried in a PDF.
- Pended and additional-information-requested outcomes get their own lane. These are the ones that quietly expire, because they don't read as urgent and they aren't a final answer.
- Unacknowledged denials escalate. Anything sitting past a defined window surfaces to a supervisor automatically.
How does routing change across a multi-location group?
Single-location practices can route everything to one queue and let proximity solve the rest. Multi-location dermatology groups can't, and this is where configuration gets real.
Three routing dimensions have to be decided explicitly:
- By location. A referral for a patient who'll be seen at your north-side office shouldn't land in the central queue and get manually forwarded. Extract the referring provider's geography or the requested location and route accordingly.
- By function, where the function is centralized. Most groups centralize prior authorization and billing while keeping intake local. That means PA determinations should route past location entirely to the central PA team, while referrals route by site.
- By provider. Pathology results follow the ordering dermatologist, who may work at two sites. Provider routing has to be independent of location routing, or results end up chasing a schedule.
Getting this wrong produces a specific failure: a centralized queue that receives everything and a coordinator who spends the recovered time forwarding documents. That's the manual sorting problem relocated, not solved. Write the routing matrix down before configuration, with a named owner in every cell.
Where fax triage and prior authorization automation connect
Classification is upstream of everything. Once a document is typed and matched to a patient, the workflow it belongs to can pick it up automatically — which is why fax triage and PA automation are the same project viewed from two ends.
A determination that's been classified, matched, and had its authorization number and outcome extracted can update the PA record without anyone rekeying it. A referral that's been classified and had demographics and insurance extracted can start eligibility verification before a human touches it. Neither is possible while the document is an unread PDF in a shared inbox.
Honey Health runs both sides of that: the Fax Triage agent classifies and extracts inbound documents and files them into the EHR with the task attached, and the Prior Authorization agent picks up determinations from there — logging outcomes against open requests and surfacing denials with their appeal windows. Because the extraction happens once, the PA workflow inherits structured data instead of starting from a scan.
The evaluation question stays the same regardless of vendor: what does the system do with a determination letter after it classifies it? A product that files it accurately and stops has automated half the job.
One more thing this connection buys: visibility. When determinations are classified and logged automatically, "how many PAs are outstanding and how old are they" becomes a number you can pull rather than a question your coordinator answers from memory. Practices that have never had that number are usually surprised by it, and the surprise is the point — you can't manage a backlog you can't see.
What to test before you commit
Vendor demos run on clean documents from cooperative senders. Your queue isn't that.
- Hand over twenty real PA determinations, mixed approvals and denials from at least three payers. Check whether outcome classification is right on every one. A system that reads approvals well and misses denials is worse than no automation, because it creates false confidence.
- Test a twelve-page referral packet. Does it split into the referral letter plus attachments, or file as one artifact? Splitting is the capability that makes referral routing useful.
- Include payer correspondence with identifiers in a header block. Patient identifiers on payer letters sit where a human skims past them and a template-matching system doesn't look.
- Check what happens with no match. A determination for a patient whose chart uses a maiden name should stop and flag, not guess.
- Ask for the exception rate by document type. A blended number hides poor performance on the hard categories behind good performance on the easy ones.
Frequently Asked Questions
Can the software tell an approval from a denial?
A well-built system reads the determination outcome from the letter body rather than inferring it from the payer or letterhead, and that's the capability to verify directly during evaluation. Test it with a mixed set of at least twenty real determinations from several payers, because outcome language varies and misreading a denial as an approval is the costliest error in this workflow.
What fields should it extract from a referral?
Patient name and date of birth, referring provider and NPI, reason for referral, any urgency indicator, insurance information, and whether supporting records are attached. Those fields are what let downstream steps — eligibility verification, scheduling outreach, and chart creation — start without a person rekeying the packet.
Does this replace our prior authorization staff?
No. It removes the finding, sorting, and filing work and hands your coordinator a structured queue instead of a stack of PDFs. Submitting appeals, arguing peer-to-peer, and working payer portals stay human. What changes is how much of the day goes to locating documents rather than acting on them.
How does it handle payer letters that cover multiple services?
That's a document-splitting question, and worth testing with your own examples. Some determinations cover a single authorization, others bundle several. Confirm whether the system extracts each authorization as a separate record or files the letter once, because the difference matters when you're tracking authorizations individually.
Can it flag appeal deadlines automatically?
If the letter states a deadline, a capable system extracts it and attaches it to the work item. Not all payers state one clearly, so a practical setup also applies your own default clock based on payer and plan type. Ask vendors specifically whether extracted dates create trackable tasks or just sit in a field.
What if a referral arrives for a patient we've never seen?
It should route to intake as a new-patient referral rather than failing a chart match. This is the highest-value document in the queue — an unworked referral is lost revenue and a patient who goes elsewhere — so confirm the system treats "no chart exists" as a distinct outcome with its own destination.
