Endocrinology practices should evaluate fax routing software on four things: how deeply its document taxonomy covers diabetes technology paperwork, whether it extracts the specific clinical fields payers require, how accurately it matches documents to patients and open orders, and whether it can hand a completed packet into a prior authorization workflow instead of just filing it. The last one separates a filing tool from a labor-saving one. Software that neatly files a CGM authorization form still leaves a coordinator re-keying HbA1c values and testing frequency into a payer portal by hand.
Why generic document tools fall short on diabetes paperwork
Most fax automation products were built for a general ambulatory document mix — referrals, records requests, hospital notes, insurance correspondence. That mix exists in your practice too. It just isn't the part that hurts.
An endocrinology practice's pain concentrates in a document family that generic platforms barely recognize: CGM authorization requests and renewals, insulin pump and supply orders, DME supplier forms, pharmacy benefit denials, formulary exception paperwork, and payer-specific fax cover sheets that each demand slightly different fields.
A generic classifier looks at all of that and produces one label: insurance. Technically correct. Operationally useless. Your authorization coordinator still opens every one, figures out what it is, finds the patient, hunts for the clinical values, and types them into a portal.
The American Diabetes Association's coverage work has documented how prior authorization requirements, mid-year formulary switching, and fail-first policies delay CGM access and load administrative work onto practices. Research on CGM implementation consistently names time-consuming prior authorization and extensive documentation requirements among the top barriers. That's the workload you're buying software to reduce — so evaluate against it specifically rather than against a generic demo.
Criterion one: taxonomy coverage for diabetes technology documents
Ask the vendor for their full document type list before the demo, not during it.
What you're checking is whether these appear as distinct types with their own routing rules:
- CGM prior authorization request, approval, denial, and renewal — four different work items, not one
- Insulin pump orders, supply reorders, and warranty replacements
- DME supplier documentation requests and delivery confirmations
- Pharmacy benefit denials and formulary exception responses
- Payer requests for additional clinical information
- Peer-to-peer review scheduling notices
If the list bottoms out at "prior authorization" as a single category, the software will file correctly and route poorly. A denial and an approval need to reach different people with different urgency, and a request for more information is the single most time-sensitive document in the stack — it usually carries a deadline.
Ask what happens when a document type isn't in the taxonomy. The honest answer is that you can define custom types, and it takes some tuning. A vendor claiming their out-of-box taxonomy covers everything hasn't looked at your fax line.
One practical way to run this check: pull two weeks of your actual inbound faxes, sort them by hand into the categories your staff already think in, and count the volume in each. Most endocrinology practices find their diabetes technology and payer paperwork concentrated in six to ten recurring senders with stable form layouts. Bring that list to the demo and ask the vendor to classify against it. A taxonomy conversation grounded in your own distribution goes very differently than one driven by the vendor's slide.
Criterion two: does it extract the fields payers actually demand?
This is where filing software and useful software diverge, and it's the criterion buyers most often skip.
Payers reviewing a CGM or pump authorization want specific things: diagnosis and type, recent HbA1c with date, testing or monitoring frequency, insulin regimen, documented hypoglycemic events, and a clinical justification narrative. Those requirements sit on the payer's fax form, and a coordinator currently reads them off one screen and types them into another.
Software that extracts these as structured data changes the work. Software that stores a searchable PDF does not.
During evaluation, hand the vendor five real authorization forms from your three highest-volume payers — redacted if you prefer — and ask them to show you the extracted field output. Not a screenshot of their extraction UI on a sample document. Yours.
Two follow-up questions worth asking:
Can it pull the clinical values from the chart rather than just from the fax? The HbA1c the payer wants is in your EHR, not on their form. A system that reads the request and assembles the answer from your own data is doing meaningfully more work than one that only reads the inbound page.
What's the extraction accuracy on degraded scans? Payer fax forms are frequently multi-generation copies. Ask for accuracy measured on real-world image quality, not clean PDFs.
Criterion three: patient, order, and authorization matching
Classification tells you what a document is. Matching tells you what it belongs to. Endocrinology has a third layer most specialties don't.
Patient matching is table stakes — name, date of birth, MRN. It should run at a stricter confidence threshold than classification, because a misfiled document is a documentation incident. A 97% match rate at 200 documents a day means six wrong charts daily.
Order matching is what makes lab results usable. A thyroid panel needs to reconcile against the order that generated it, or your staff still has to figure out which physician is waiting on it.
Authorization matching is the endocrinology-specific one. When a payer response arrives, the system should connect it to the open authorization request it answers — closing that loop rather than filing an approval that nobody notices for four days while a patient waits on a sensor shipment.
Ask specifically: when a payer approval comes back by fax, does your software know which of our open requests it belongs to, and does it update that request's status? Many products cannot do this. It's worth knowing before you sign.
Criterion four: does it hand off to a prior authorization workflow?
The single most useful question in an evaluation: after your software files this CGM authorization form, what happens next?
There are three possible answers, and they represent very different products.
It appears in a queue for staff to work. This is a filing tool. Your labor savings come from the classification and matching steps only — real, but modest.
It appears in a queue with the extracted fields pre-populated. Better. The coordinator confirms rather than transcribes.
It flows into an authorization workflow that assembles the packet, submits it, and tracks status. This is where the labor actually goes away, because submission and follow-up — not filing — are where the hours sit.
This handoff is exactly why Honey Health runs fax triage and prior authorization as connected agents rather than separate products. The triage agent reads, classifies, extracts, and matches the inbound document; authorization paperwork moves to the prior authorization agent, which assembles the clinical packet from the chart and handles submission and status tracking. Filing turns into completed work rather than a better-sorted inbox.
Whatever vendor you evaluate, get the handoff diagrammed. "We integrate with PA workflows" is a sentence that survives contact with almost any architecture.
Worth pricing this honestly before you compare quotes. The filing step is maybe two to four minutes of staff time per document. Assembling and submitting an authorization packet, then following up on it, runs far longer — and it repeats for every request for additional information and every denial appeal. If a vendor's product stops at filing, you're automating the cheaper half of the work. That doesn't make it a bad purchase, but it should change what you're willing to pay and what you promise your partners about recovered capacity.
Criterion five: security posture and the questions to ask on the call
A vendor processing inbound patient documents is a business associate under HIPAA. That's not a differentiator — it's the floor. What varies is how seriously they've built for it.
Ask for the BAA before the pilot, not after. Confirm encryption in transit and at rest. Ask whether every access and filing decision is logged, and whether you can pull that log yourself. SOC 2 Type II or HITRUST certification is a reasonable bar for a vendor handling this volume of PHI.
Then close the evaluation call with these:
- Show me your document type list. Which of these six diabetes technology types are distinct categories?
- Run these five real payer forms through extraction and show me the field output.
- When a payer approval arrives, does it connect to our open request and update its status?
- What are your classification, extraction, and patient-match accuracy rates — measured separately, on our documents, during a pilot?
- What share of our volume will file with no human touch, and what does the exception queue look like at month three?
- Who pays our EHR vendor's interface fee?
A vendor who answers all six directly is worth a pilot. A vendor who redirects to a case study on question two is telling you something.
Frequently Asked Questions
Will fax routing software submit CGM prior authorizations for us?
Filing software will not — it routes the form to a person. Some platforms extend into authorization workflows that assemble the clinical packet and submit it, which is where the labor savings concentrate. Ask the vendor to walk through what happens after the document files, and get the answer specific rather than architectural.
How do we test extraction accuracy before buying?
Give the vendor a sample of your own documents at real-world image quality — five to ten forms from your highest-volume payers and DME suppliers — and ask for field-level output. Compare it against what a staff member would pull manually. A vendor unwilling to run your documents during evaluation is a meaningful signal.
Does it need to integrate with our EHR to be useful?
For filing and patient matching, yes. For assembling authorization packets, absolutely — the clinical values payers want live in the chart, not on the inbound fax. Ask which integration mechanism they use, what they write, and who pays any interface fee your EHR vendor charges.
What about peer-to-peer review requests?
These should be their own document type with immediate escalation, because they typically carry a scheduling deadline. Ask specifically whether the taxonomy separates them from general payer correspondence. Many platforms don't, and a missed peer-to-peer window usually means starting the authorization over.
Is a specialty-tuned platform worth paying more for?
It depends on what share of your volume is diabetes technology paperwork. If it's a small slice, a generalist platform with custom types will do. If CGM, pump, and DME documents dominate your authorization workload, taxonomy depth and payer-field extraction are where the return actually comes from — and that's worth comparing carefully.
