The blank letter is the easy part. The hard part is proving that every sentence points back to the current payer rule and the patient’s dated record.
A generic letter of medical necessity template can organize that proof. It cannot decide which benefit applies, invent missing documentation, or turn a clinician’s conclusion into sufficient evidence by itself. The useful template is an evidence spine: criterion, patient fact, source record, and requested service in one traceable line.
Start with the request instructions
Before drafting, save the payer’s current request instructions and the coverage material that applies to the patient’s plan, item, or service. Record where the rule came from and when staff retrieved it.
Coverage requirements can vary by payer and can change. For Medicare, national and local coverage materials can be searched through the Medicare Coverage Database. A commercial or Medicaid plan may use a different source and submission path. Staff should not reuse a prior patient’s checklist without checking the current request.
Create a short control block:
| Control | Value to record |
|---|---|
| Payer and plan | Exact entity and product named in the record |
| Requested item or service | Plain-language name plus required code, if applicable |
| Policy | Title, identifier, version or effective date, and URL or saved copy |
| Submission rule | Required form, channel, attachments, signature, and deadline |
| Owner | Person responsible for submission and response tracking |
If staff cannot identify the governing material, that is a workflow exception. Do not hide it by drafting more forceful prose.
Map each criterion to a chart location
Read the coverage criteria before opening the letter. Build a private worksheet that the clinician can verify.
| Payer criterion | Patient-specific fact | Record location | Status |
|---|---|---|---|
| Criterion text or faithful summary | Documented patient fact | Note or report, author, and date | Met, not met, or unclear |
| Criterion text or faithful summary | Documented patient fact | Note or report, author, and date | Met, not met, or unclear |
This table is not a place to stretch the record. “Unclear” means the reviewer needs clarification or the request packet is not ready. A missing fact should not become a confident statement because the template has an empty field.
CMS documentation guidance illustrates the larger principle. For evaluation and management services, CMS tells clinicians to document the reason for the encounter, relevant history and findings, assessment, rationale for ancillary services, plan, date, and clinician identity (CMS E/M guidance). The exact requirements for a medical-necessity request depend on its own policy, but the signed record remains the source of patient facts.
Use the template as a controlled draft
Replace every bracketed instruction. Delete sections that do not apply instead of filling them with boilerplate.
PRACTICE LETTERHEAD
DATE: ____________________
To: ____________________
Patient full name: ____________________
DOB: ____________________
Member ID: ____________________
Request or reference number: ____________________
REQUESTED ITEM OR SERVICE
Item or service: ____________________
Dose, quantity, frequency, duration, or setting when required:
________________________________________________________________
CLINICAL CONDITION AND CURRENT EFFECT
Verified diagnosis or clinical problem: ____________________
Onset and dated course: ____________________
Functional effect and pertinent findings: ____________________
Source notes and test dates: ____________________
APPLICABLE COVERAGE CRITERIA
Policy title and identifier: ____________________
Version or effective date: ____________________
Relevant criterion: ____________________
Patient fact supporting the criterion: ____________________
Source, author, and date: ____________________
PRIOR CARE AND RESPONSE
Treatment or conservative measures, dates, and duration: ____________________
Documented response, intolerance, contraindication, or reason a step did not apply:
________________________________________________________________
RATIONALE FOR THIS REQUEST
Patient-specific clinical reasoning connecting the current condition and
evidence to the requested item or service:
________________________________________________________________
SUPPORTING RECORDS
Named notes, orders, reports, imaging, results, treatment logs, and payer forms:
________________________________________________________________
REQUESTED REVIEW
Policy or benefit for review: ____________________
Approved clinical contact and channel: ____________________
Sincerely,
Clinician name, credentials, and required identifiers: ____________________
Signature and date: ____________________This is a drafting aid, not legal, billing, or coverage advice. The clinician and revenue-cycle team should adapt it to the actual payer process.
Write chronology instead of adjectives
“Severe,” “failed,” and “necessary” are conclusions. A reviewer needs the observations underneath them.
Prefer a dated sequence:
- symptom or functional change and when it began;
- examination, test, or assessment findings with dates;
- prior treatment, dose or duration when relevant, and observed response;
- contraindication or intolerance supported by the record; and
- the present effect on function, care, or risk as documented by the clinician.
Do not turn “patient did not return” into “treatment failed.” Do not turn “medication discussed” into “medication trial completed.” Those substitutions make the letter cleaner and the evidence worse.
Attach the record the letter cites
For some Medicare DMEPOS claims, CMS states that a physician order, certificate, supplier-prepared statement, or physician attestation by itself does not provide sufficient documentation of medical necessity, even when signed (CMS Article A55426). That example should not be generalized into one rule for every payer or service. It does show why a letter cannot be treated as a replacement for the underlying record.
Name each attachment in the letter and in the submission checklist. Use dates and document types. If the payer asks for a physical-therapy note, send the required note through the approved channel rather than copying one sentence from it and assuming the summary will suffice.
Before submission, reconcile the letter against the attachments. A stale medication list, changed diagnosis, mismatched laterality, unsupported duration, or wrong policy date can break the chain.
Keep codes subordinate to evidence
Codes can route a request and express the service or diagnosis in a standard field. They do not prove that a coverage criterion is met.
Verify that every submitted code matches the current code set, the requested service, the payer instruction, and the signed record. If software suggests an ICD-10 code, keep it in suggestion status until a qualified reviewer confirms it. Do not add a more specific diagnosis merely to fit a form.
For a deeper prior-authorization workflow, see Prior Authorization Documentation: Build a Submission Packet That Survives Review. The letter is one artifact inside that packet, not the whole process.
Control version, signature, and submission
Treat the draft as a controlled clinical document.
The clinician should see the exact version being signed. After approval, prevent silent edits or require a new review. Preserve the author, reviewer, signature time, attachments, destination, transmission evidence, and payer response under the organization’s retention policy.
Do not place a signature image into a regenerated letter and call that clinician review. The approval event needs to bind the clinician to the actual content submitted.
CMS’s documentation fact sheet points practices to service-specific guidance because requirements differ across items and services (CMS MLN909160). The workflow should therefore record the requirement source for each request, rather than maintaining one undated master checklist.
Test the process with one returned request
Choose a de-identified or synthetic case modeled on a recent request for more information. Ask a staff member who did not prepare it to reconstruct:
- which policy version governed the request;
- where each criterion appeared in the record;
- which attachments were sent;
- what the clinician approved; and
- what the payer returned and who handled it.
If reconstruction requires searching email, a fax console, the EHR, and a shared drive with no common identifier, the letter template is not the bottleneck. Fix the packet index and status ownership.
CMS’s prior-authorization API guidance describes coverage-requirement discovery as a way for an impacted workflow to identify whether authorization is required and what documentation is needed; the discovery response alone is not the authorization request (CMS Prior Authorization API FAQ). The same separation helps manual workflows: discovering requirements, assembling evidence, submitting, and receiving a decision are distinct events.
The Patient Square boundary
Patient Square’s public US pricing describes review-ready SOAP notes, ICD-10 suggestions, eRx drafts, and EHR-ready exports (Patient Square pricing). It does not claim payer-policy interpretation, automatic coverage determination, autonomous coding, claim submission, or insurer approval.
A reviewed note draft may help staff locate current clinical facts. The letter still needs the payer-specific rule, required attachments, clinician judgment, signature, and controlled submission path.
Review the published product scope.
The strongest letter of medical necessity is not the one with the most emphatic language. It is the one in which a reviewer can move from criterion to patient fact to dated record without guessing.