How to Build a Program Integrity Scoring Worksheet That Holds Up
A transparent scoring worksheet for enrollment review: six scored dimensions, weights your team sets, documented exceptions, and clear rules for routing uncertain cases to people.
The same flagged application crossed three desks during one open enrollment week. Reviewer A cleared it: the pay stub arithmetic worked, the plan selection looked ordinary. Reviewer B sent a document request because the employer letterhead looked reused. Reviewer C escalated it to program integrity because the attached agent credential had touched a lot of households that month.
None of them were wrong on the facts. They were weighting the same facts differently, using rules that lived in their heads and nowhere else. That is the problem a scoring worksheet solves.
A program integrity scoring worksheet is a written rubric for enrollment review. It scores each verification dimension independently, applies weights the program sets and publishes, bands the total into a required action, routes defined conditions to a human regardless of score, and logs every override with a reason and an approver. Below is the artifact: six scored dimensions, a weighting method, banded dispositions, an exception log design, and a human-routing rule set you can copy and adapt.
Score the Dimensions Separately or the Worksheet Lies to You
Six dimensions carry most enrollment review work: identity evidence strength, income documentation consistency, citizenship or immigration evidence, special enrollment period triggering event and timing, submitter or broker provenance, and cross-program duplicate coverage. Keep them independently scorable. The moment you collapse them into one number, you lose the ability to explain a disposition.
Independence matters because collapsed scores let strong evidence in one dimension rescue a case that fails in another. A perfectly validated employer letter does not fix an SSN that does not associate with the claimed name and date of birth. A messy self-employment ledger from a genuine household should not outweigh clean identity binding and a verified triggering event. When the dimensions stay separate, the reviewer can say "this case escalates on identity binding, not on income," which is a sentence another reader can follow.
Each dimension needs a stated basis written into the worksheet, not a personal threshold. Marketplace eligibility verification contemplates electronic data sources first, with documentary evidence used when those sources are unavailable or produce inconsistencies [1]. Special enrollment claims carry their own triggering-event and timing conditions, so SEP scoring should test the claimed event against the enrollment date rather than just confirming a document exists [2]. Identity work separates resolving an identity, validating the evidence, and verifying that the evidence belongs to the person presenting it [5]. Write those bases into the worksheet so the score has a reference, not a vibe.
On every uploaded document, split the scoring three ways: is this an acceptable evidence type for the inconsistency being resolved [3], does the content validate internally and against the issuer or data match, and does the evidence bind to this applicant and this household. Record all three sub-scores. Most contested cases fail exactly one of them, and knowing which one determines the follow-up request.
| Dimension | What it scores | Primary evidence basis | Score owner |
|---|---|---|---|
| Identity evidence strength | Resolution to one individual, evidence validation, binding to the applicant | Identity proofing sequence [5] | Eligibility reviewer |
| Income documentation consistency | Pay period, frequency, annualized figure, and self-attested amount agreement | Data source first, documents as fallback [1] | Eligibility reviewer |
| Citizenship or immigration evidence | Acceptable evidence type and successful source validation | Verification process requirements [1] | Eligibility reviewer |
| SEP triggering event and timing | Claimed event, documented date, and enrollment window alignment | Special enrollment period conditions [2] | Eligibility reviewer |
| Submitter or broker provenance | Credential pattern, change type, consumer recognition, template reuse | Agent and broker participation requirements [7] | Program integrity analyst |
| Cross-program duplicate coverage | Concurrent enrollment across programs or states after identity is bound | Program data matching pathways [6] | Program integrity analyst |
Weights Belong to the Program, Not the Vendor
A tool that hides its weights cannot produce a disposition a reviewer explains line by line to an oversight body. If your scoring engine returns "risk: 78" and no one on staff can say which dimension contributed what, you do not have a worksheet. You have a number you will eventually have to defend in front of an inspector general or an auditor, with nothing behind it.
Set weights with a method, not an argument. Start with equal weights across the six dimensions. Run the worksheet against a corpus of already-closed cases. Compare the band the worksheet produces to the disposition the reviewer actually reached. Adjust weights only where the worksheet and the reviewer disagreed, and write down why you adjusted. Equal weights are a defensible starting point precisely because no one invented them to produce a preferred outcome.
Version the worksheet and stamp every case with the version used. A decision made in March under worksheet v1.2 must stay interpretable in November when v1.5 is live and someone reopens the file. Without a version stamp, the case record says a score that the current rubric would never produce, and you cannot reconstruct the reasoning.
Watch for score inflation from correlated signals. Shared employer, shared mailing address, and an identical upload template across three applications can be one finding about a single submission cluster, not three independent findings each adding weight. Collapse correlated signals into a single scored observation before weighting, and note in the worksheet which signals you treat as correlated. Otherwise the same underlying fact triples a score and a reviewer escalates a case that only ever had one problem.
Provenance and Submission Patterns Are a Dimension, Not a Footnote
Provenance scoring looks at the submission, not the applicant. Repeated document templates across unrelated households, reused employer letterheads, identical income figures appearing in different applications, shared upload metadata, and applications tied to an agent credential the consumer does not recognize all belong in this dimension. These are the signals a single-case review structurally cannot see.
Build a credential-centric view alongside the consumer-centric one. Group every application and change by the agent or broker identifier attached to it, with timestamps, change type, and the specific consumer-facing fields altered. Contact email and phone substitution, household composition edits that shift subsidy amounts, and plan switches with no corresponding consumer contact record are the patterns worth scoring. Agent and broker participation in the Exchanges carries specific requirements and disclosure obligations, so note which requirement each observed behavior appears to touch rather than describing the conduct in general terms [7][8].
Consider two cases. One consumer calls to say their plan changed without permission, the agent name on the record is unfamiliar, and nothing else is unusual. That reads as a service dispute, resolved at the consumer level. Now take the same single change and discover the credential behind it replaced the contact email on many households inside a short window. Same individual act, different case entirely, and the referral is built around the credential rather than one consumer [4].
Cross-case comparison outranks any single-document flaw. A slightly odd font on one pay stub is a question; the same template structure across unrelated applications is a finding. Our write-ups on document forensics for fabricated pay stubs and SEP letters and broker ring detection with graph analytics cover how those comparisons get built and recorded.
One sequencing rule: test duplicate or concurrent coverage across programs and states after identity is resolved and bound, never before [5][6]. Coverage overlap computed on an unresolved identity generates noise, because two records that look like the same person may be two people or one person entered twice.
Banded Dispositions and the Exception Log
Four bands cover enrollment review cleanly: clear, request additional documentation, hold in the outstanding verification queue, and escalate for program integrity review. Each band carries a required action, so the score produces work rather than an opinion.
Require the reviewer to name the dimension that drove the band. "Escalated on identity binding failure with corroborating submission pattern" is reviewable. "Score 81" is not. This single field does more for case quality than any weighting refinement, because it converts a number into a sentence.
| Score band | Required action | Documentation required | Review owner | Timing expectation |
|---|---|---|---|---|
| Clear | Proceed with eligibility determination | Dimension sub-scores and data source used [1] | Eligibility reviewer | Same-day disposition |
| Request documentation | Issue a specific evidence request naming the unresolved element | Request text, acceptable evidence types listed [3] | Eligibility reviewer | Within the program's notice cycle |
| Hold in verification queue | Keep case open pending source match or applicant response | Open findings and what would resolve each | Queue lead | Re-review at each queue cycle |
| Escalate | Route to program integrity with named driving dimension | Sub-scores, basis per dimension, resolution attempts made [4] | Program integrity analyst | Escalation logged on the day it is raised |
The exception log is the part teams skip and later regret. Five fields are enough: override direction (up or down), dimension overridden, stated reason, approver, and date. Those five turn overrides into tuning data. Without a log, overrides become invisible drift, and six months later your published weights describe a worksheet nobody actually follows.
When the Worksheet Should Stop and Hand the Case to a Person
Some conditions force human review no matter what the total score says. Identity binding failure. Suspected document fabrication. Credential-level patterns spanning multiple households. Conflicting dimensions, where one is strong and another fails outright. And any total inside the uncertainty band you define around your escalation threshold.
route(case):
if case.identity.binding == FAIL: return HUMAN("identity binding")
if case.document.fabrication_suspected: return HUMAN("suspected fabrication")
if case.provenance.credential_cluster: return HUMAN("credential pattern")
if case.dimensions.conflict_detected: return HUMAN("conflicting dimensions")
if abs(case.total - ESCALATE_THRESHOLD) <= UNCERTAINTY_BAND:
return HUMAN("uncertainty band")
return BAND(case.total) # clear | request docs | hold | escalateAt handoff, the reviewer should see four things: the sub-scores, the stated basis for each, the specific unresolved question, and what evidence would resolve it. That last field is what prevents a case from cycling through the queue three times collecting generic document requests. "SSN does not associate with claimed name and date of birth; a Social Security card or a source match would resolve it" tells the next person exactly what to do.
Detectory scores these dimensions and routes the forced-review conditions to a case queue, where a person makes the call before any adverse action and the sub-scores and basis statements carry into the referral packet. The related guides on referral-grade evidence and audit trails and outstanding verification queue triage show what those records look like in practice, including how resolution attempts get documented before anything is sent onward [9].
Pilot It on Closed Cases Before It Touches a Live Queue
Backtest first. Run the worksheet against cases that are already closed, compare the band it produces to the disposition the reviewer reached, and catalogue every disagreement. You are not looking for agreement; you are looking for the shape of the disagreements.
Sort each disagreement into one of three buckets. The worksheet was too aggressive, escalating cases reviewers resolved with a document request. The worksheet was too permissive, clearing cases reviewers escalated for reasons the dimensions did not capture. Or the original reviewer decision was never documented well enough to compare, which is a finding about your case records rather than your worksheet.
Set the acceptance rule before the pilot starts. Decide in advance what level of band agreement, and what pattern of disagreement, means the worksheet is ready. Otherwise tuning becomes rationalizing: you will adjust weights until the output matches your expectations and call that validation.
Run a second pass with a different reviewer pair on the same cases. The question is not only whether the worksheet matches human judgment but whether it narrowed the spread between two humans reviewing the same file. That spread is the problem you set out to fix. Record the pilot findings, including the disagreements you chose not to resolve, as the first entry in the worksheet's version history.
Questions Teams Ask Before Launch
Does a scoring worksheet replace eligibility rules? No. It organizes review of the verification work the rules already require, including the preference for electronic data sources before documentary evidence [1].
Should weights differ by program? Often yes. SEP timing carries more weight in a marketplace queue than in a Medicaid renewal queue. Keep one worksheet per program context and version each separately.
How many dimensions is too many? Six is manageable. Past eight, reviewers stop scoring and start guessing, and correlated signals multiply. Add a dimension only when an escalation reason will not fit in the existing six.
What belongs in a referral built from a high score? The sub-scores, the basis for each, the exact mismatched elements, the resolution attempts already made, and a plain chronology a receiving program integrity or enforcement reader can follow [4][9]. Improper payment risk in large benefit programs stays on federal oversight agendas, so referral quality carries weight beyond your own queue [10].
The One Thing to Build This Week
Write the six dimension definitions, each with its stated rule or standard basis, on one page. Do that before you touch weights. Teams that start with weights spend weeks arguing about numbers that describe dimensions nobody has defined yet, and this drafting step takes about an afternoon.
Then start tracking one signal: the override rate per dimension. It shows you exactly where the worksheet and your reviewers still disagree, and it is the input you will need when you revisit weights.
Launch prerequisites, all six:
- Dimension definitions with stated rule or standard basis
- Published weight table with the approver named
- Band actions with required documentation per band
- Exception log with direction, dimension, reason, approver, date
- Human-routing rules that override total score
- Version stamp written onto every scored case
Those three reviewers from open enrollment still see the same application differently. The difference now is that they land in the same band, and when one of them does not, the exception log says which dimension they overrode and why. That record is the whole point. For the surrounding architecture, see our guide on front-door enrollment fraud detection.
References
[1] 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
[2] eCFR, 45 CFR 155.420 - Special enrollment periods. https://www.ecfr.gov/current/title-45/section-155.420
[3] HealthCare.gov - Submit documents to confirm your eligibility. https://www.healthcare.gov/verify-information/
[4] CMS - Marketplace Private Health Insurance Program Integrity. https://www.cms.gov/marketplace/private-health-insurance/program-integrity
[5] NIST SP 800-63A, Digital Identity Guidelines: Enrollment and Identity Proofing. https://pages.nist.gov/800-63-3/sp800-63a.html
[6] Medicaid.gov - Medicaid Program Integrity. https://www.medicaid.gov/medicaid/program-integrity/index.html
[7] eCFR, 45 CFR 155.220 - Ability of States to permit agents and brokers to assist qualified individuals, qualified employers, or qualified employees enrolling in QHPs. https://www.ecfr.gov/current/title-45/section-155.220
[8] CMS - Agents and Brokers in the Health Insurance Marketplace. https://www.cms.gov/marketplace/agents-brokers
[9] HHS Office of Inspector General - Report Fraud. https://oig.hhs.gov/fraud/report-fraud/
[10] U.S. Government Accountability Office - High-Risk List Overview. https://www.gao.gov/highrisk/overview