A payer request for more facts needs a careful response. Do not send the full chart at once. First, check the request and the claim. Then find the exact records it asks for. Send them through an approved route. Keep proof of each step.
The request is not a final claim result. It does not show that the payer will deny or pay. It also does not let billing staff create clinical facts. The provider stays in charge of all clinical answers.
What should happen when the request arrives?
Save the request, log it, and name an owner. Do this before the team gathers records. One clear log can stop missed work and repeat replies.
Keep the notice in the form received. Add these facts to the log:
- The payer name.
- The patient and claim reference.
- The date the request came in.
- Each item the payer asked for.
- The response route shown on the notice.
- Any due date stated in the notice.
- The staff member who owns the next step.
Next, sort the type of question. Is it about the claim or a record? Is it about benefits or coverage? Does it ask about authorization? Does it concern network terms or payment? These are distinct issues. Keep them distinct in the log.
A request for a note does not prove coverage. It does not set the amount due from the patient. Those points need their own proof.
How should the team check the request?
Check the sender, patient, claim, scope, and send route. A real request should match a real claim. Its details should also match the practice record.
Use an approved payer contact when a notice looks odd. Do not trust a phone number in a suspect message. Find the payer contact through a known source.
Complete these checks before staff open or send files:
- Match more than the patient name.
- Confirm the payer and claim are known.
- Read each request item as written.
- Check who may view the records.
- Check which send routes are allowed.
- Ask for help when the scope is not clear.
Do not change the request text. Save any payer follow-up as a new note. This keeps the source clear.
Who should choose the records to send?
The provider must control each clinical answer. Billing staff may find and sort existing records. They may not add a diagnosis or new care facts. They may not guess what the provider meant.
The dental-to-medical records checklist can help sort the chart. It does not replace the provider's note. It also does not prove that the payer will accept the file.
Match each request item to a real record. The record should be final when required. It should also belong to the right patient and service.
If an item is missing, do not make one. Note the gap in the work log. Send the question to the right provider. The provider can decide if a valid record exists.
Send only the records that answer the checked request. Follow the privacy rules that apply. Extra pages can add risk. They can also hide the useful facts.
How should the reply be built and sent?
Build a short, checked file set and use the approved route. An index can list each file in the set. It can also list the claim and request date.
CMS says claim attachment tools can send support records. It also says a payer may first ask for more facts. See the CMS claim attachment fact sheet. This does not set one route for all payers. It does not set one due date for all claims.
Before sending, have a second person check the set. That person should confirm these points:
- Each file matches the right patient.
- Each file answers a listed request item.
- No file appears twice.
- No unrelated file is in the set.
- The send route is the checked route.
- The cover note adds no new clinical facts.
Use the payer's current rules and the practice's safe tools. Protect the files during the send. Do not use a personal email or an unapproved app.
What proof should be kept after the send?
Keep proof of what went out and what came back. A sent message is not the same as payer receipt. Receipt is not the same as payer review.
Keep the first request and the final file index. Keep the sent files when allowed. Also keep the send date, route, receipt, and reference number. Save later payer notes with them.
Add the next check to the work log. Base it on real payer guidance. Do not invent a standard wait time.
The claim status guide explains later status checks. A status reply is distinct from send proof. Neither one proves payment or the final patient balance.
What does a hypothetical reply look like?
Hypothetical scenario: A payer asks for two signed reports. Both reports relate to one dental-to-medical claim. The intake lead logs the request. She checks it in the known payer portal.
The record lead finds one signed report. The second report is not clear in the chart. She sends that question to the treating provider. The provider points to an existing signed report.
A second staff member checks both files. The names and service facts match. The team sends the set through the stated portal. It saves the receipt and file index. It also names the person who will check status.
This process does not predict the payer's choice. It does show what the team sent. It also protects the provider's role.
Frequently asked questions
These answers explain what the request does not prove.
Does a request for more facts mean a denial?
No. It means the payer seeks more facts. A later written result may approve, deny, or take another action. Read that result on its own.
Should staff send the full chart after a broad request?
Not at once. Check the true scope and the rules that apply. Ask the right privacy or legal owner when needed. Send only an approved response set.
This guide is general administrative information, not legal, medical, clinical, dental, coding, documentation, privacy, security, contract, accounting, financial, patient-billing, or coverage advice, and not a statement that any workflow, record, request, response, claim, payment, adjustment, deadline, decision, or outcome is accurate, complete, compliant, authorized, covered, or payable. Requirements and outcomes vary by payer, program, plan, patient, provider, service, record, agreement, system, jurisdiction, and date.
