Prior Authorization Document Extraction, Field by Field

Prior authorization document extraction means reading the request form and its supporting documents into structured fields: member, provider, service, codes, dates and clinical details. Extract the form section by section, pull the key facts from attached notes and orders, then have a person check codes, dates, member ID and signatures before the request goes to the payer.

Prior authorization request form fields, section by section

Prior authorization request form fields can be grouped into five working sections: member, provider, service, codes and clinical information. The labels and order change from payer to payer, but the job of each section stays the same, which is what makes field-by-field extraction possible across different forms.

Prior authorization is a health plan's decision, before care, that a service is medically necessary. The definition and the people involved are explained in the guide to what prior authorization for insurance means. This post covers the pages, not the process.

The table below is an example layout built from those five sections. Every value is fictional and labelled as an example.

The NPI checks rest on 45 CFR 162.406 on eCFR, which says "The NPI is a 10-position numeric identifier, with a check digit in the 10th position." The code columns use two code sets. The CMS HCPCS page describes Level I, which is CPT, as codes "used primarily to identify medical services and procedures furnished by physicians and other health care professionals", and Level II as codes for products, supplies and services CPT does not cover, such as equipment. The CMS ICD-10 page notes that "The CDC develops and maintains ICD-10-CM", the diagnosis code set. How those same codes appear on claims is covered in the claims and medical bills category.

Which supporting documents go with a prior authorization request?

Supporting documents for a prior authorization request are the clinical pages that prove what the form claims: recent office notes, relevant test results and records of treatment already tried. The payer reads them against its own coverage criteria, so the right attachments are the ones that answer those criteria, not the whole chart.

Office or consult notes. The most recent visit note from the ordering practitioner, showing the history, examination and the reason for the request. Extract the encounter date, the practitioner, the diagnoses discussed and the plan.

Test results. Lab reports, imaging reports or other studies that support the need. Extract the test name, date, result and any abnormal flag. A request for advanced imaging often depends on an earlier, simpler study.

Records of earlier treatment. Many criteria ask what has already been tried: a course of physical therapy, a medication tried and stopped, a less invasive procedure. Extract the treatment, the start and end dates and the stated outcome.

Medication lists and problem lists. Useful for drug requests and for showing the patient's other conditions.

Orders. For equipment and supplies, the written order is a required document in its own right, covered in the next section.

Extraction of supporting documents is less about every field and more about the few facts the payer will look for. A good habit is to write those facts into the request form's clinical summary, with the date and source page of each, so the reviewer at the payer does not have to search.

Schema Care does not read prior authorization request forms, but several of these attachments are document types it does read. Lab reports come back as test names, results, units and abnormal flags, and medical records as encounter dates, problem lists, allergies and vitals, each field with a score and a link to its place on the page. The document types and fields Schema Care reads list the full set.

DME orders and certificates of medical necessity as prior authorization documents

DME orders and certificates of medical necessity are the core documents behind a durable medical equipment request. For Medicare, every DMEPOS item needs a written order from the treating practitioner, and some items also have a certificate of medical necessity (CMN). Both commonly travel between practitioner and supplier by fax.

The CMS Medicare Program Integrity Manual, chapter 5 lists the required elements of a standard written order (SWO): the beneficiary's name or Medicare Beneficiary Identifier, a general description of the item, the quantity to be dispensed if applicable, the order date, the treating practitioner's name or NPI, and the treating practitioner's signature. Those six elements make a short, checkable field list.

The same chapter describes the CMN. It says CMNs contain Sections A through D, that "Sections A and C are completed by the supplier and Sections B and D are completed by the physician", and that the supplier may not complete Section B. It names the current forms, including CMS-484 for oxygen, CMS-846 for pneumatic compression devices, CMS-847 for osteogenesis stimulators, CMS-848 for TENS units and CMS-849 for seat lift mechanisms.

Fax is explicitly allowed. The manual says a supplier must have "a signed original, faxed, photocopied, or electronic CMN or DIF" in its records when it submits a claim. It also says that for claims with dates of service on or after January 1, 2023, suppliers no longer submit CMNs with claims, and claims sent with them attached are rejected. The form stays on file instead.

For extraction, a CMN breaks into four blocks, using the details the manual gives for each:

• Section A (supplier): the supplier's entries, including the "Initial Date", which the manual says is the specific start date on the order or, without one, the date of the order.
• Section B (practitioner): the item's medical question set. The manual allows a nurse practitioner, clinical nurse specialist or physician assistant to complete it when they meet its conditions, but never the supplier.
• Section C (supplier): the narrative description of the items furnished. When it is detailed enough, including quantities and replacement frequency, the manual lets the CMN serve as the detailed written order.
• Section D (practitioner): the signature and the "Signature Date", which can differ from the Initial Date because it records when the practitioner actually signed.

Where Medicare requires prior authorization for an item, the CMS DMEPOS prior authorization page describes the approval as a "condition of payment", so the order and supporting notes go to the reviewer before delivery.

Extracting prior authorization fields from faxed forms

Extracting prior authorization fields from faxed forms follows the same path for every page: identify the document, find each section, read each field, normalize its format, link it to its location on the page, and flag the fields a person must confirm. The output is one structured record per request, with the supporting documents attached and indexed.

A step-by-step version:

1. Split the fax into documents. A single fax often holds the request form, two visit notes, a lab report and a cover sheet. Separate them before reading any field.
2. Classify each document. Request form, office note, test result, written order, CMN or other. The classification decides which fields to look for.
3. Find the sections. On the request form, locate the member, provider, service, codes and clinical blocks by their headings or position.
4. Read each field. Typed fields read cleanly. Handwritten fields, checkboxes and faint fax text are the ones most likely to be misread.
5. Normalize. Dates into one format, NPIs as 10 digits, codes without stray spaces, names as last and first.
6. Link every field to its source. Store the page and position of each value, so a reviewer can see it in place.
7. Cross-check across documents. The member name and date of birth should match on every page. The diagnosis on the form should appear in the notes.
8. Route uncertain fields to a person. Anything the software is unsure of, and every field on the check list below, goes to review before the record is used.

Fax quality affects every step. Low resolution, skewed pages and dark backgrounds make characters harder to read, especially digits. The reasons so much of this paperwork still travels by fax are explored in why healthcare still runs on fax.

A faxed request can also arrive at the wrong office. A page that belongs to another practice's patient should never be extracted into your records. The steps to take are in the guide to what to do with a misdirected medical fax.

What should a person check on an extracted prior authorization?

A person should check four things on every extracted prior authorization before it is submitted: the codes, the dates, the member ID and the signatures. Errors in these fields cause most avoidable pends and denials, and each takes seconds to confirm when the reviewer can see the field beside its place on the original page.

Codes. Confirm each CPT or HCPCS code matches the service description and the order, and each diagnosis code matches a diagnosis in the attached notes. Check every character. A transposed digit produces a valid-looking code for a different service.

Dates. Confirm the requested date range covers the scheduled service, the order date comes before the request, and the supporting notes are recent enough for the payer's criteria. A date of birth read into the date-of-service field, or the reverse, is a common extraction slip.

Member ID. Compare the ID character by character with the patient's insurance card or eligibility response, including any prefix or suffix. Confirm it belongs to the patient, not the subscriber, when the plan issues separate IDs.

Signatures. Confirm the ordering practitioner signed and dated the form, the written order and, for equipment that uses one, Section D of the CMN. A missing or undated signature returns the request.

Two further checks pay off. Confirm the servicing provider's NPI is not a copy of the ordering provider's when they differ. Confirm the urgency box is set on purpose, because a request marked expedited without clinical support may be handled as standard anyway.

Prior authorization forms that differ by payer

Prior authorization forms differ by payer in layout, labels and required fields, even when they ask for the same information. One payer puts the diagnosis codes in the service block, another in a separate codes block, a third leaves room only for a free-text reason. Extraction has to map each layout to the same fields.

The practical approach is to keep one field list, like the table at the top of this post, and map each payer's form onto it. When a form adds a field your list lacks, such as a place-of-service checkbox or a prior treatment section, add it to the list as optional rather than building a separate record type per payer.

Template-driven reading. For payers that send the same form every time, a per-form template that knows where each field sits reads reliably until the payer changes the form.

Layout-independent reading. For forms you see rarely, or forms that change, software that finds fields by their labels rather than their position copes better with new layouts.

Version drift. Payers revise forms. A field that moved or a new required box can leave older templates reading the wrong area. Watch for a sudden rise in fields sent to review from one payer, which often means its form changed.

The structure may also change over time. The CMS fact sheet on the Interoperability and Prior Authorization final rule (CMS-0057-F) requires impacted payers, such as Medicare Advantage organizations and Medicaid programs, to have a Prior Authorization API by January 1, 2027 that identifies documentation requirements and supports requests and responses. Until then, and for payers outside that rule, the forms keep arriving as pages.