When we started building Coral, the first question we had to answer concretely was: what does a referral fax actually contain, and what does an intake coordinator need from it to file a prior authorization? That question drove us through a lot of document review before we wrote the first line of extraction code.
The answer is that a referral fax typically carries nine distinct clinical fields that a coordinator needs to initiate an authorization request. Some of those fields appear explicitly as labeled data. Others have to be inferred from clinical context. All nine need to be correct for a submitted authorization to be processed without a deficiency notice from the payer.
Here is what those nine fields are, what makes each one hard to extract reliably, and how Coral approaches each of them.
Patient Name and Date of Birth
These two fields sound straightforward, but fax transmission quality and document layout variation create real problems. Patient names appear in different formats across documents: first-last, last-first, with or without middle names, sometimes with prefixes or suffixes that get garbled in transmission. Date of birth format varies too, from MM/DD/YYYY to spelled-out month formats to occasional two-digit year abbreviations in older document templates.
Coral normalizes both fields to a standard format as part of extraction. When a name appears in a non-standard order, we use contextual cues in the surrounding document structure to resolve ambiguity. When a date appears in an ambiguous format (06/07/1972: is that June 7 or July 6?), we flag it for coordinator review rather than guessing.
ICD-10 Diagnosis Code
The ICD-10 code is the field that causes the most trouble in referral documents. It can appear in three or four different places in the same document type. In a physician's clinical note, it may be in the assessment and plan section. In a referral order, it may be on the order line. In a benefits verification form, it may be in a dedicated diagnosis field. And in some documents, the code appears only as a textual description, requiring us to map the described condition to the correct ICD-10 code.
Code accuracy matters because prior authorization requests are indexed by diagnosis code, and some payers have very narrow code-specific authorization pathways. A request submitted under a code that is one level too general, or under a code that does not match the payer's coverage policy, will either fail or require manual correction before the payer will process it.
Coral extracts the ICD-10 code from whichever location in the document it appears, validates it against the current ICD-10-CM code set, and flags any code that has been inactivated or that is a non-billable header code rather than a specific diagnosis. This is a validation step that manual transcription does not always catch, because coordinators are reading for transcription, not necessarily checking code validity.
Referring Physician NPI
The referring physician's National Provider Identifier is required by nearly all payer auth forms, but it is often absent from the referral document itself. Some referring practices consistently include the NPI on their documents. Others do not. When the NPI is present, it appears in different locations: the letter header, a signature block, a separate cover sheet, or a pre-printed practice form.
When the NPI is absent from the document, Coral cannot extract what is not there. In those cases, we flag the field as requiring manual entry and indicate the physician's name and practice information so the coordinator can look up the NPI in the NPPES registry directly. This is the correct behavior. Generating a plausible-looking NPI for a physician whose NPI is not in the document would be a fabrication error with real downstream consequences.
Requested Medication or Therapy and J-Code
For infusion therapy, the requested medication or biologic is usually explicit in the referral order. The J-code that corresponds to that medication is less often explicit. Payers typically want the HCPCS J-code on the authorization form, not the drug name, but referring physicians often write the drug name rather than the code.
Coral maintains a mapping between commonly referred infusion medications and their primary J-codes. When a medication name appears in the referral and no J-code is present, we suggest the appropriate J-code for coordinator confirmation. When a medication has multiple J-codes depending on route of administration or concentration, we surface the options rather than selecting one unilaterally, because that selection has billing implications that belong with the coordinator.
Quantity and Frequency
Dosage and frequency are expressed in natural language in most referral documents: "infuse 500mg IV every four weeks" or "weekly administration for six cycles." Authorization forms typically require these expressed as discrete fields: quantity per session, frequency (weekly/monthly/etc.), number of sessions, or total duration.
Converting natural language dosage instructions to structured auth form fields is a parsing problem. Coral reads the dosage instructions and populates the structured fields, flagging cases where the instructions are ambiguous (for example, "as needed" or instructions that conflict across different pages of the same document).
Payer Name, Member ID, and Group Number
These three fields together identify the patient's insurance and are required on every prior authorization request. They typically appear either on a copy of the insurance card included in the fax, in a benefits verification section of a referral summary form, or in both places.
Insurance card images transmitted by fax are among the lower-quality images Coral processes. Print quality, fax transmission quality, and card age all affect readability. For partially legible fields, Coral reports a lower confidence score rather than a best-guess extract. The coordinator sees the low confidence flag and can verify against the original insurance information in the patient record rather than filing with a potentially incorrect member ID.
Confidence Scoring and Where It Applies
Every field Coral extracts carries a confidence indicator. High confidence means the field value was found in a clearly labeled context, validated against a reference (ICD-10 code set, NPPES, etc.), and consistent with contextual information elsewhere in the document. Lower confidence means one or more of those conditions was not met.
The purpose of the confidence score is not to tell the coordinator which fields to trust and which to distrust arbitrarily. It is to tell them where their review time is best spent. A coordinator reviewing a 20-field auth form pre-filled by Coral should spend their attention on the three fields marked for review, not re-reading all 20. That is the practical design: Coral reads the routine cases cleanly and surfaces the edge cases explicitly.
We do not claim Coral extracts all nine fields correctly from every referral document. Some documents are genuinely too poor in quality to extract reliably. Some referring practices use document layouts that create extraction ambiguity we have not yet seen in volume. When Coral cannot extract a field with reasonable confidence, it says so. The coordinator enters it manually. That is not a failure mode; that is the appropriate fallback for a document automation tool operating in the real world of fax-transmitted clinical paperwork.
What This Changes in Practice
The nine-field extraction changes the coordinator's relationship to the referral document. Instead of reading a multi-page fax to find and transcribe each field, the coordinator reviews a pre-populated authorization form with source annotations showing where each field came from in the original document. For straightforward referrals from familiar practices with clean documentation, this review takes a few minutes. For complex or poorly documented referrals, the coordinator still does the full work, but Coral has at least identified which fields need attention.
Building reliable extraction for nine specific fields in a real-world fax document environment took significantly more development work than building an extraction pipeline for cleanly structured digital documents. The challenge is not the extraction algorithm in isolation. The challenge is extraction that degrades gracefully when document quality is low, that is honest about its confidence, and that fails safely rather than silently. That combination of properties is what we have spent the most time on.