How to Build Referral Packets MFCUs and CMS Can Actually Use
A section-by-section referral packet outline for enrollment fraud cases: preserved originals, evidence index, reviewer determinations, broker consent records, and chain of custody.
A case left our queue last spring with everything I thought a receiving unit would want: tampered paystub findings, a shared employer string across four unrelated applications, one agent identifier attached to all four, and a consumer complaint about a plan change nobody authorized. It came back with three questions. Which subject is this about? Which agency is supposed to act on the billing allegation buried on page six? And where is the original upload for exhibit C, because the copy in the packet had been re-rendered by our own viewer.
The answer to all three was the same. We had assembled evidence before deciding who was going to use it.
If you want referral packets that get worked instead of returned, decide the destination and the case type first, then assemble only the evidence that destination has authority to act on, with a documented chain from each source artifact to each conclusion. Medicaid Fraud Control Units operate under the HHS OIG framework covering Medicaid provider fraud and patient abuse or neglect [1]. Marketplace eligibility and agent or broker conduct route through CMS channels under the exchange standards [3][6]. Those are different audiences with different authorities, and a single narrative that blends them forces the recipient to unbundle your work before they can start theirs.
What follows is a packet outline you can adapt with your own investigators and program counsel. Intake preferences are set locally and change, so confirm the current format with the specific unit receiving your case.
Classify the Case Before You Assemble Anything
Every enrollment case I have seen fall into rework was misclassified at the start. There are three buckets, and they determine routing more than severity does.
Beneficiary or applicant eligibility misrepresentation covers fabricated income documents, misstated household composition, identity misuse, and false special enrollment period claims. For Medicaid, the agency's program integrity and referral duties sit in the Medicaid program integrity rules at 42 CFR Part 455 [2]. For marketplace coverage, the eligibility and verification obligations sit in the exchange establishment standards at 45 CFR Part 155 [3].
Provider conduct covers billing and service-delivery allegations, along with patient abuse or neglect. That is the MFCU lane described by HHS OIG, and it is the lane where an eligibility-focused packet does the least good [1].
Agent or broker conduct covers unauthorized enrollments, unauthorized plan switching, and consent records that do not match the transaction record. CMS maintains the marketplace agent and broker program, including registration and agreement requirements, and updates program terms each plan year [6].
Two rules keep packets workable. One destination per packet. One subject per packet, which for broker cases means one agent identifier per referral rather than bundling several under a shared pattern narrative. Pattern evidence still belongs in the file, but it supports the single identifier you are referring.
| Case type | Likely destination | Governing authority to cite | Primary evidence class | What stays internal |
|---|---|---|---|---|
| Applicant eligibility misrepresentation (Medicaid) | State Medicaid program integrity unit, then MFCU if it develops into provider conduct | Medicaid program integrity rules [2] | Application history, uploaded income and identity artifacts, verification results | Risk scores, queue priority, model tuning notes |
| Applicant eligibility misrepresentation (marketplace) | Marketplace eligibility and program integrity channels at CMS | Exchange standards and verification process rules [3][4] | Verification path per eligibility element, preserved uploads, reviewer determinations | Draft analyst hypotheses, unrelated household leads |
| Provider fraud or patient abuse and neglect | Medicaid Fraud Control Unit | HHS OIG MFCU framework [1] | Claims and service records, complaint intake, custodian statements | Eligibility triage notes unrelated to the provider |
| Unauthorized agent or broker activity | CMS marketplace agent and broker channels | CMS agent and broker program materials [6] | Consent artifacts, transaction trail, per-identifier activity comparison, consumer complaints | Baseline thresholds and monitoring logic |
| Cross-program duplicate coverage with concealment signals | Program-appropriate channel for each program, separately | Medicaid program integrity rules and exchange eligibility rules [2][8] | Pre-reconciliation snapshots, identifier variance findings | Reconciliation backlog metrics |
The failure mode is predictable. A packet that requires the recipient to sort your allegations into their own authority buckets sits while someone figures out whether it is theirs, and then generates a supplementation request that restarts your clock.
What Belongs on the One-Page Case Summary
The summary is not a story. It is a map from assertion to exhibit.
State the suspected conduct, the program and plan year affected, the identifiers involved, the date range, and the specific evidence items supporting each assertion. Keep inference out of it. Analytic reasoning belongs in a separate, labeled analyst section so the factual record stands on its own if the analysis is later challenged or superseded.
The discipline that changed our return rate most was writing assertions as evidence-linked sentences. Each claim carries an index number pointing to the exhibit that supports it, and any claim that cannot carry one gets cut or moved to the analyst section.
ASSERTION-001 | Applicant reported wages from Employer X for plan year 2026
SUPPORT: EX-003 (uploaded paystub, preserved original)
SUPPORT: EX-004 (application income attestation, extract)
FINDING: EX-003 producer metadata inconsistent with claimed scan origin
REVIEWER: K. Tanaka, 2026-03-11, determination recorded in case field RV-12
ASSERTION-002 | Same file hash appears under three unrelated applicants
SUPPORT: EX-003, EX-011, EX-017 (identical SHA-256)
SUPPORT: EX-020 (reuse query output, capture date and custodian noted)
REVIEWER: K. Tanaka, 2026-03-11, determination recorded in case field RV-13That format copies cleanly into most case systems, and it survives excerpting. When a receiving attorney asks what supports a sentence, the answer is a line number, not a phone call.
The Evidence Index Is the Packet's Backbone
An exhibit without provenance is a screenshot. Every item in the index needs a source system, a capture date, a custodian, and a hash or durable system identifier so the recipient can trace the exhibit back to where it lived.
Preserve uploaded documents exactly as received. This sounds obvious and gets violated constantly, because document viewers, PDF combiners, and case-management attachments quietly re-render or re-compress files. Once that happens, the container attributes a reviewer relied on are gone, and so is your ability to show the file you examined is the file the consumer submitted. Record upload metadata alongside the original rather than inside a merged packet PDF.
For generated files, note container-level attributes including producer and creation metadata, and flag explicitly when a purported scan carries no scanner characteristics. That observation is only useful in a referral if it was recorded as a structured field at review time with the reviewer's identity attached. Reconstructing it six weeks later produces a weaker record and an obvious cross-examination target. Structured findings from document forensics on fabricated paystubs and altered special enrollment letters are worth capturing upstream for this reason, so the index fills in as a byproduct of review rather than as a separate assembly project.
Document the Verification Path for Each Eligibility Element Separately
Income, citizenship or immigration status, identity, and special enrollment period qualification rest on different evidence types under the exchange verification process rules [3][4]. Collapsing them into one "verification completed" field destroys the part a recipient needs, which is what was checked against what.
The NIST identity proofing frame is the cleanest vocabulary I have found for this. Evidence strength and validation are separable concepts: a document can look authentic yet fail validation against an authoritative source, and it can validate while still failing to bind to the person presenting it [5][7]. Borrow that separation even for non-identity elements.
Record three answers per document instead of one composite accept or reject:
- Authenticity. Is the artifact what it claims to be? Container attributes, layout consistency, issuer formatting, reuse across the application population.
- Validation. Does the content validate against an authoritative or declared source? Employer details, pay period math, issuing office identifiers, data source results.
- Binding. Does the artifact tie to this applicant and this household, or only to a name that appears on it?
Then log what the recipient will predictably ask next, per element:
- Income: the preserved paystub or letter, the attestation extract, the data source result, and the reviewer's discrepancy list. Expect a request for the employer verification attempt.
- Citizenship or immigration status: the artifact, the verification result, and the date the inconsistency period opened. Expect a request for the notice history.
- Identity: the evidence presented, the validation outcome, and the binding determination. Expect a request for whether the same identifier appears elsewhere.
- Special enrollment period: the qualifying-event document, the claimed event date, and the enrollment timestamp. Expect a request for the letter's issuer provenance.
Cases where the same Social Security number surfaces under different names or households deserve their own finding lines rather than a summary sentence, and the mechanics of synthetic identity and SSN reuse detection are worth separating from the eligibility narrative so the recipient can see each variance as a discrete observation.
Broker Links, Consent Records, and the Transaction Trail
Broker cases live or die on the consent reconciliation. Match every enrollment or plan change against its consent or authorization record, and treat missing, templated, or post-dated consent as a discrete finding tied to the specific transaction it fails to cover rather than as a general characterization of the agent [6].
Preserve the full transaction trail before any correction or termination alters it: submission timestamps, channel, agent identifier used, and every subsequent change. I have watched a well-intentioned correction overwrite the exact field that showed which identifier submitted the original change. The correction was right for the consumer and fatal for the referral, and the only fix is snapshotting first.
Cross-reference consumer contact details across enrollments attributed to the same identifier. Shared phone numbers, email addresses, or mailing addresses appearing under unrelated applicants are the pattern signal that gives a single complaint context, and per-identifier behavioral comparison is the work that turns scattered complaints into one referable subject. Bring complaint intake into the same case record as the pattern analysis so the package shows reported harm and surrounding behavioral evidence together [10].
Human Review Is What Turns a Flag Into a Referral
An automated signal is a reason to look. It is not a determination, and a packet built on flags alone reads as an algorithm accusing a person.
What a receiving unit can act on is a named reviewer, what they examined, which signal prompted the review, and the reasoned determination they reached. Store those observations as structured case fields with reviewer identity and timestamp so a later packet reproduces the basis for the determination without reconstruction. Keep the division clean in practice: scoring and the case queue prioritize work, reviewers make determinations, and only reviewers appear in the packet as decision makers.
Use this checklist. Program counsel should be able to read the human review record end to end without asking a follow-up question:
- [ ] Named reviewer and role, with timestamp for each determination
- [ ] The specific signal or queue reason that prompted review, stated in plain language
- [ ] Exhibits examined, by index number, including preserved originals
- [ ] Authenticity, validation, and binding answers recorded separately per document [5]
- [ ] Discrepancies listed as observations, with intent inferences confined to the analyst section
- [ ] Any contact with the applicant, broker, or employer, with date and outcome
- [ ] Custodian list for each exhibit, plus transfer log and access history
- [ ] A note on every copy made for the packet, including how the original was preserved
- [ ] The determination itself, in one sentence, and the case field where it lives
Chain of custody is the section reviewers skip and recipients read first. Keep it short and complete: who held each artifact, who moved it, who accessed it, and what was copied for transmittal.
Questions Integrity Teams Ask About Referral Packets
Do MFCUs handle marketplace eligibility fraud? MFCU authority centers on Medicaid provider fraud and patient abuse or neglect under the HHS OIG framework [1]. Exchange eligibility and agent or broker conduct generally route through CMS marketplace channels instead [3][6]. When a case genuinely spans both, send two packets with a cross-reference note, not one blended file.
How much analysis should go in the packet? Enough to explain why you looked, clearly separated from the factual record. Put pattern analysis, scoring rationale, and hypotheses in a labeled analyst section. Keep the summary and evidence index to facts with exhibit numbers.
Should we include our risk scores? Include the reason the case entered review. Keep scoring internals, thresholds, and tuning history internal unless the recipient asks, because those invite a methodology argument in place of the evidence argument.
What if an exhibit was altered by our own systems? Say so, in the index, with what happened and where the original sits. Disclosed handling gaps are manageable. Undisclosed ones end cases.
How do we know the intake format? Ask. Intake formats, cover forms, and delivery channels are set locally and change, so confirm with the specific receiving MFCU or CMS contact before you send [1][6]. Broader program integrity and improper payment reporting from the GAO health care collection is useful background when you brief leadership on why this discipline matters [9].
Confirm Intake, Log the Transmittal, Then Track What Comes Back
Do three things before transmittal. Confirm the intake format, the delivery channel, and any required cover forms with the named contact at the receiving unit. Verify that the packet contains one subject and one destination. Check that every assertion in the summary carries an exhibit index number.
Then log the transmittal in the case record itself, with date, recipient, contents manifest, and contact. Supplementation requests that arrive two months later should attach to the original case, not spawn a parallel file that a different analyst fills from memory.
Here is the concrete action for this week. Pull your last three referrals and test one thing: does every assertion in each summary map to a numbered exhibit with a source system, capture date, and custodian? This takes about half an hour per case and it will tell you whether your problem is evidence collection or evidence organization. In my experience it is almost always organization.
The signal to start tracking is your rework rate: the share of referrals returned with a request for supplementation, and the reason cited. Track the reason codes, not just the count, because "wrong destination" and "missing original file" call for completely different fixes.
That packet that came back with three questions? A properly built evidence index would have answered all three before anyone asked. The subject would have been one applicant or one agent identifier. The billing allegation would have been in a separate packet to a separate unit. And exhibit C would have been the preserved upload, with its hash, its custodian, and the reviewer who examined it, sitting exactly where the index said it was.
References
[1] HHS Office of Inspector General, Medicaid Fraud Control Units. https://oig.hhs.gov/fraud/medicaid-fraud-control-units-mfcu/
[2] eCFR, 42 CFR Part 455 - Program Integrity: Medicaid. https://www.ecfr.gov/current/title-42/chapter-IV/subchapter-C/part-455
[3] eCFR, 45 CFR Part 155 - Exchange Establishment Standards and Related Standards Under the Affordable Care Act. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-B/part-155
[4] eCFR, 45 CFR 155.315 - Verification process related to eligibility for enrollment in a QHP through the Exchange. https://www.ecfr.gov/current/title-45/section-155.315
[5] NIST Special Publication 800-63A, Digital Identity Guidelines: Enrollment and Identity Proofing. https://pages.nist.gov/800-63-3/sp800-63a.html
[6] CMS Health Insurance Marketplace, Agents and Brokers. https://www.cms.gov/marketplace/agents-brokers
[7] NIST Digital Identity Guidelines (SP 800-63 series) project page. https://pages.nist.gov/800-63-3/
[8] eCFR, 45 CFR Part 155 Subpart D - Exchange Functions in the Individual Market: Eligibility Determinations. https://www.ecfr.gov/current/title-45/part-155/subpart-D
[9] U.S. Government Accountability Office, Health Care topic collection. https://www.gao.gov/health-care
[10] HHS Office of Inspector General, Report a Fraud, Waste, or Abuse Complaint. https://oig.hhs.gov/fraud/report-fraud/