Synthetic Patient Data for Revenue Cycle Management — Test Your Billing Workflows Without the Risk

The RCM vendor had been careful. Before launching their new claim scrubbing engine, they ran three months of parallel testing using a sanitized set of claims from one of their largest clients. The test data covered 40,000 claims across primary care, internal medicine, and cardiology. The engine passed every validation scenario they built. They went live on a Tuesday.

By Thursday, their client's anesthesia billing team was on the phone. Every anesthesia claim submitted since go-live had been flagged by the scrubber for a modifier error. The engine was rejecting valid qualifying circumstance modifiers — QS, AA, AD — that it had never seen during testing. It was also mishandling anesthesia physical status modifiers P3 and P4, treating them as billable procedure modifiers rather than recognizing them as anesthesia-specific payer-reported qualifiers. The fix took four days of emergency development. The resubmission backlog took three weeks to clear. The client relationship took considerably longer.

"We tested forty thousand claims," the product manager told us afterward. "Not one of them was an anesthesia claim. Anesthesia coding has its own modifier logic, its own unit calculation methodology, its own set of payer rules that differ from every other specialty. We had no idea what we didn't know."

That is the test data problem in revenue cycle management. It is not a technology problem. It is not an engineering problem. It is a coverage problem — and it is almost universal among RCM software vendors, healthcare systems launching new billing platforms, and billing companies onboarding new specialty clients.

This guide walks through the complete revenue cycle workflow, the specific data requirements at each stage, and exactly what test data must contain to surface the failure modes before they reach production claims.

The Full Revenue Cycle: Ten Stages, Ten Distinct Test Data Requirements

The revenue cycle is not a single process. It is a chain of ten interdependent stages, each with its own data requirements, its own failure modes, and its own regulatory requirements. Generic synthetic patient data fails at nearly every stage because it was built for clinical purposes — diagnosis capture, medication tracking, care coordination — not for billing.

Here is what each stage actually requires from test data:

Stage 1: Patient Registration

Registration is where billing errors are born. A transposed digit in a date of birth will generate a Medicare eligibility mismatch that won't surface until the claim rejects weeks later. A patient registered under "Robert Smith" when the insurance card says "Bob R. Smith" may trigger a name mismatch denial from the payer. These are not rare — industry data suggests that demographic errors account for roughly 23% of initial claim denials.

Test data for registration workflows needs realistic demographic variation: patients with hyphenated surnames, patients with name suffixes (Jr., III, MD), patients whose legal name differs from the name on their insurance card, patients with P.O. Box addresses, patients registered without a Social Security Number, and patients with international addresses. Medicare beneficiary identifiers (MBIs) replaced Social Security Numbers on Medicare cards in 2018, but RCM systems still encounter the old HIC number format in legacy data and need to handle both.

Stage 2: Eligibility Verification

Real-time eligibility verification via 270/271 X12 transaction sets is the entry point for payer-specific data requirements. A 271 eligibility response that confirms coverage for primary and secondary payers, describes coordination of benefits order, and specifies copay/coinsurance/deductible amounts looks nothing like a simple "yes, this patient has coverage" flag. Test data needs to represent the full range of coverage scenarios: Medicare as primary with Medicaid as secondary (dual eligible), Medicare as secondary to employer-sponsored coverage (Medicare Secondary Payer rules under Section 1862(b) of the Social Security Act), COBRA coverage that may have lapsed, and Medicare Advantage plans that operate under plan-specific rules rather than traditional Medicare fee-for-service.

Stage 3: Charge Capture

Charge capture is where clinical documentation becomes a billing transaction. The complexity here is immense — and it is specialty-dependent in ways that make generic test data almost useless for charge capture testing.

For professional fee billing (CMS-1500 / 837P), charge capture requires accurate CPT code selection with correct modifier application, the right place of service (POS) code, and valid ICD-10-CM diagnosis codes that support medical necessity for the procedure billed. For institutional billing (UB-04 / 837I), charge capture requires revenue codes that map correctly to HCPCS codes, accurate type of bill (TOB) codes for the claim type and billing sequence, and accommodation codes for inpatient room and board.

Revenue codes on UB-04 claims are a frequent source of errors that test data needs to surface. Revenue code 0450 (emergency room) billed with CPT 99283 (ED level 3) is a valid combination. Revenue code 0450 billed with CPT 99213 (office visit level 3) is an edit failure — office visit codes are not appropriate in the ED revenue code context. Revenue code 0278 (medical/surgical supplies) requires a HCPCS Level II code in the procedure code field. These are not edge cases. They are routine charge capture rules that claim scrubbers must enforce, and they require test claims that present both compliant and non-compliant pairings to verify that the scrubber fires correctly in both directions.

Stage 4: Coding

Coding bridges clinical documentation and billing. The coding function transforms physician documentation into ICD-10-CM diagnosis codes, CPT procedure codes, and the modifiers that clarify how, where, and by whom those procedures were performed. Errors in coding produce the two failure modes that drive the largest denial volumes in most practices: medical necessity denials (procedure not covered for the billed diagnosis) and procedure-modifier inconsistency denials.

Test data for coder training and audit tools needs to present the full range of coding complexity: principal diagnosis sequencing for inpatient claims, complication and comorbidity (CC) and major complication and comorbidity (MCC) assignment that affects DRG weight under MS-DRG grouping, present on admission (POA) indicators that affect hospital-acquired condition penalties, and the ICD-10-CM coding guidelines that govern sequencing of acute and chronic conditions.

Stage 5: Claim Submission

The 837P and 837I transaction sets are the EDI formats for professional and institutional claims respectively. They are not interchangeable — a hospital that bills both facility fees (UB-04/837I) and employed physician professional fees (CMS-1500/837P) must manage two entirely different claim formats with different loop structures, different required versus situational fields, and different payer routing requirements.

837P professional claims require, among other fields: billing provider NPI and taxonomy code, rendering provider NPI (which may differ from billing provider for group practices), referring provider NPI for services that require a referral, subscriber and patient information loops that differ when the patient is the subscriber versus a dependent, coordination of benefits loops when secondary coverage exists, and claim filing indicator codes that vary by payer type (MA for Medicare Part A, MB for Medicare Part B, MC for Medicaid, CI for commercial).

837I institutional claims add facility NPI requirements, condition codes (box 18-28 on UB-04) that flag special billing circumstances (patient discharge to hospice, Medicare as secondary payer, COBRA, clinical trial participation), occurrence codes and dates, occurrence span codes for specific date ranges relevant to payment, and value codes for coinsurance and other monetary amounts. A claim scrubber that correctly validates 837P claims may have entirely untested logic for 837I institutional claims.

Modifier Complexity: The Most Underrepresented Dimension in Test Data

CPT modifiers are two-character alphanumeric codes appended to procedure codes to provide additional information about how, where, or by whom a service was performed. There are over 100 modifiers in active use, and their interaction with each other, with specific CPT codes, and with payer-specific edit rules is the single most complex dimension of claim validation logic. It is also the dimension most consistently absent from generic test data.

Modifier 22 — Increased Procedural Services

Modifier 22 is appended when the work required to perform a service is substantially greater than typically required. It signals payers that the physician is requesting payment above the standard fee schedule amount. The problem in claim scrubbing is that modifier 22 is frequently abused — attached to routine procedures without documentation support — which causes payers to scrutinize it heavily. Test data needs to present modifier 22 in both valid contexts (complex procedure with documented increased work) and invalid contexts (routine procedure with no complexity indicator) so the scrubber can correctly flag inappropriate use without blocking legitimate claims.

Modifier 25 — Significant, Separately Identifiable E/M Service

Modifier 25 is one of the most frequently denied modifiers in outpatient billing. It is used to identify an E/M service performed on the same day as a procedure, when the E/M is separate and distinct from the procedure itself. The payer logic here is specific: modifier 25 is valid on E/M codes, not on procedure codes. It indicates that the E/M was not merely the pre-procedure evaluation. Many payers apply specific LCD criteria for modifier 25 — Medicare requires documentation that the E/M was for a different condition or a significant new finding beyond the procedure indication.

A claim scrubber testing modifier 25 must verify the modifier appears on an E/M code (99202-99215, 99281-99285, etc.), not on the procedure. It must check that the E/M code and the procedure code are both on the same claim. And for payer-specific rules, it must apply the correct LCD requirements for the payer — which differ between Medicare fee-for-service, Medicare Advantage plans, and commercial payers. Test data needs claims that present modifier 25 correctly, incorrectly (on the procedure code), on an unsupported E/M level, and in the correct combination with a procedure requiring the modifier.

Modifier 51 — Multiple Procedures

When multiple procedures are performed at the same session, modifier 51 signals that the secondary procedure should be reimbursed at a reduced rate (typically 50% of the fee schedule amount). The complexity in testing is that modifier 51 does not apply universally — some CPT codes are modifier 51 exempt (add-on codes, starred procedures, and codes designated as 51-exempt in the CPT codebook). Applying modifier 51 to an add-on code is an edit error. Failing to apply modifier 51 when multiple non-exempt procedures are billed will trigger a bundling edit. Test data needs multi-procedure claims across the range of exempt and non-exempt combinations.

Modifier 59 and the X Modifiers — Distinct Procedural Service

Modifier 59 is used to indicate a distinct procedural service — a service that would normally be bundled under NCCI edits but is separately reportable in specific clinical circumstances. CMS has largely replaced modifier 59 with four more specific modifiers: XE (separate encounter), XS (separate structure), XP (separate practitioner), and XU (unusual non-overlapping service). The question of which modifier is appropriate — 59 or one of the X modifiers — depends on the specific NCCI edit pair and the clinical circumstances.

NCCI (National Correct Coding Initiative) edit pairs are published by CMS and updated quarterly. There are hundreds of thousands of procedure code pairs that trigger NCCI edits. Some of these edits can be overridden with modifier 59/X modifier; some cannot. A claim scrubber must know which edits are modifier-bypassable and which are absolute. Test data must present the full range: NCCI pairs where 59 is valid, NCCI pairs where 59 is not valid, NCCI pairs that require an X modifier rather than 59, and non-NCCI situations where 59 is being used incorrectly.

Anesthesia Modifiers — A Category Unto Themselves

Anesthesia billing uses a modifier framework entirely different from the rest of medicine. Rather than standard CPT procedure codes with standard modifiers, anesthesia claims use anesthesia CPT codes (00100-01999) paired with:

• Physical status modifiers P1-P6 — indicating patient physical condition from P1 (normal healthy patient) through P6 (brain-dead organ donor). These are payer-reported modifiers in some systems, billable in others. Medicare does not pay extra for physical status modifiers. Some commercial payers add relative value units for P3, P4, and P5. The claim scrubber must know which rules apply per payer.
• Qualifying circumstance codes — 99100 (patient under one year or over 70), 99140 (emergency conditions), 99135 (controlled hypotension), 99116 (utilization of total body hypothermia). These are separate CPT add-on codes, not modifiers, but they interact with anesthesia billing logic in ways that non-anesthesia-aware scrubbers consistently mishandle.
• Anesthesia provider modifiers — AA (anesthesiologist performed personally), QX (CRNA with medical direction), QY (medically directing one CRNA), QK (medically directing 2-4 CRNAs), QZ (CRNA without medical direction), AD (medical supervision of more than four concurrent procedures). These modifiers determine which provider type the claim attributes the service to and at what payment rate. An AA claim pays differently than a QX claim. A scrubber that doesn't validate these modifiers against the NPI taxonomy of the billing provider will pass invalid claims and fail valid ones.

Bilateral Procedure Modifiers — 50, RT, LT

Modifier 50 indicates a bilateral procedure performed during the same operative session. RT (right side) and LT (left side) are used when bilateral procedures are billed on separate lines. The billing rules differ by payer: Medicare accepts modifier 50 on a single line with one unit, and pays at 150% of the unilateral fee schedule. Some commercial payers want two lines with RT and LT on separate lines at 100% each. Others want modifier 50 but with two units. A claim scrubber must validate bilateral modifier use against payer-specific rules, not just against the general CPT convention. Test data needs bilateral procedure claims in both correct and incorrect formats for each payer type.

Global Surgery Period Modifiers

Surgical procedures carry global surgery periods — 0-day, 10-day, or 90-day — during which related services are bundled into the surgical payment and cannot be billed separately. Modifiers 54, 55, and 56 split surgical care among providers: modifier 54 (surgical care only), modifier 55 (postoperative management only), modifier 56 (preoperative care only). Modifiers 57, 58, 78, and 79 govern additional services during the global period: modifier 57 (decision for surgery), modifier 58 (staged or related procedure), modifier 78 (return to OR for related procedure), modifier 79 (unrelated procedure during global period).

The global surgery period logic is one of the richest sources of claim scrubber failures. A scrubber that does not track the global period dates for surgeries — or that does not correctly apply the modifier rules for additional services during the global period — will either deny legitimate claims or pass claims that should be bundled. Testing this logic requires claims that include the index surgery and subsequent services within the global period, with the correct modifier applied based on the clinical scenario.

Modifier AS — Assistant at Surgery

Modifier AS (Physician Assistant, Nurse Practitioner, or Clinical Nurse Specialist assisting at surgery) differs from modifier 80 (assistant surgeon) and modifier 82 (assistant surgeon when qualified resident surgeon is unavailable). Each carries different payment rates and different payer-specific rules about when they are valid. Medicare pays 85% of the physician rate for services billed by nurse practitioners and physician assistants, and modifier AS must appear on those assistant-at-surgery claims. Commercial payers may not recognize modifier AS at all and require modifier 80 regardless of the provider type. A claim scrubber that conflates these modifiers will produce incorrect edit flags for non-physician assistants at surgery.

Payer-Specific Rules: Why "Standard" Test Claims Are Never Standard Enough

The same claim can be valid under Medicare fee-for-service rules and invalid under Medicaid rules and invalid-for-a-different-reason under a specific commercial payer's contract. RCM systems that validate claims against a single universal rule set will miss payer-specific errors. And payer-specific rules are where most of the revenue is actually at risk.

Medicare Fee-for-Service

Medicare is the most rule-dense payer in the United States. National Coverage Determinations (NCDs) and Local Coverage Determinations (LCDs) published by Medicare Administrative Contractors (MACs) define covered services, covered diagnoses, documentation requirements, and frequency limitations for hundreds of procedures. An LCD for a specific MAC jurisdiction may restrict coverage for a procedure to specific ICD-10-CM codes that a physician in that jurisdiction must document to support the claim. Test data for Medicare claim validation must include the correct ICD-10-CM codes to satisfy LCD requirements — and it must also include claims with non-covered diagnoses to verify that the scrubber flags medical necessity mismatches appropriately.

Medicare Physician Fee Schedule (MPFS) Relative Value Units (RVUs) underlie all professional fee reimbursement. Each CPT code has work RVUs, practice expense RVUs, and malpractice RVUs that sum to a total RVU, which is multiplied by the geographic practice cost index (GPCI) for the service location and the annual conversion factor (in 2026, $33.29) to produce the Medicare allowable. A fee schedule analysis tool that does not have claims with the right POS codes and rendering provider ZIP codes cannot correctly calculate expected Medicare reimbursement.

Medicaid

Medicaid rules are state-specific and program-specific in ways that make Medicare look simple. Each state administers its own Medicaid program under a CMS-approved state plan, and each state has its own fee schedule, its own prior authorization requirements, its own covered services list, and its own claim format requirements. In managed Medicaid markets — where the state has contracted with commercial managed care organizations to administer Medicaid benefits — the payer rules are determined by each MCO's contract with the state, which can differ substantially from the state fee-for-service rules.

Test data for Medicaid billing workflows must represent this variety. A payer mix that includes 20% Medicaid but tests only against one Medicaid fee schedule has not tested its Medicaid logic — it has tested one state's fee schedule against one program type.

Commercial Payers and Payer-Specific LCDs

Commercial payers publish their own coverage policies — sometimes called clinical payment and coding policies — that may differ significantly from Medicare NCDs and LCDs. A commercial payer may cover a service that Medicare does not, or may impose documentation requirements that are stricter than Medicare's. Payer-specific prior authorization requirements add another layer: a procedure that requires no auth for Medicare may require auth for every commercial plan, and the specific procedures that require auth vary by plan, by employer group, and in some cases by the specific plan benefit design elected by the employer.

Denial Management: Testing the Workflow That Recovers Revenue

The industry average denial rate is approximately 5-10% of submitted claims, and the average cost to rework a denied claim is $25-$118 depending on complexity. For a practice submitting $10 million in claims per year with a 7% denial rate, that is $700,000 in denied claims — plus the labor cost of working them. Denial management is not a back-office function. It is a revenue recovery operation, and the workflows that support it need as much rigorous testing as the claim submission workflows upstream.

Testing a denial management module requires a realistic denial mix across the claim adjustment reason codes (CARCs) and remittance advice remark codes (RARCs) that constitute the actual denial language of the 835 ERA transaction. The most important denial codes to represent in test data are:

• CO-4 — "The procedure code is inconsistent with the modifier used or a required modifier is missing." This fires when modifier 25 appears on a procedure code instead of an E/M code, when an anesthesia modifier is applied to a non-anesthesia code, or when a required modifier (such as LT or RT on a bilateral-specific procedure) is absent. Test data should present both sides: claims that fire CO-4 legitimately, and claims that are incorrectly flagging CO-4 due to scrubber logic errors.
• CO-11 — "The diagnosis is inconsistent with the procedure." This is the medical necessity denial. A colonoscopy billed for a diagnosis of acute URI will generate CO-11 from most payers. Test data that pairs procedures with the wrong diagnoses — and the right diagnoses — allows denial management workflows to correctly categorize and route these denials for appeal versus write-off.
• CO-16 — "Claim/service lacks information or has submission/billing error(s)." This is a catch-all for missing required data elements. Missing rendering provider NPI, missing referring provider when required by the payer, missing prior authorization number when auth was required — all generate CO-16. Denial management workflows need to parse CO-16 denials down to the specific missing element, which requires the associated RARC codes (N56, N264, N30, N382, etc.) to route the work to the correct correction queue.
• PR-1, PR-2, PR-3 — Patient responsibility codes for deductible (PR-1), coinsurance (PR-2), and copay (PR-3). These are not denials — they are payment reductions attributable to patient cost-sharing. But denial management systems must correctly classify them to avoid treating patient responsibility as a payer underpayment and generating incorrect appeals. Test data must include claims with realistic patient responsibility amounts that reflect the actual cost-sharing structure of the patient's plan — which requires test patients with realistic insurance plans, not just placeholder payer IDs.

The 835 ERA: What Remittance Processing Actually Requires

The ANSI X12 835 Health Care Claim Payment/Advice transaction is how payers communicate payment decisions back to providers. An 835 ERA contains, for each claim in the remittance batch: the claim payment amount, the claim adjustment segments that explain the difference between the billed amount and the paid amount, the line-level adjudication detail for each service line, and the check or EFT information for the payment itself.

The 835 transaction uses claim adjustment reason codes (CARCs) and remittance advice remark codes (RARCs) to explain every dollar of adjustment. A single claim payment might contain a CO-45 (charges exceed fee schedule) adjustment at the claim level, a CO-97 (service was included in a previously adjudicated service) adjustment at the line level for a bundled procedure, and a PR-1 (deductible) adjustment reducing the paid amount to zero on a line where the patient's deductible hasn't been met.

Testing remittance processing requires 835 transaction data that accurately represents this structure. A test 835 with only claim-level adjustments and no line-level detail will not exercise the remittance posting logic that handles multi-line claims with different adjustment reasons on different service lines. A test 835 that only includes CO and PR adjustments and no OA (other adjustment) adjustments will miss the coordination of benefits adjustments (OA-23, OA-94, OA-25) that apply when a secondary payer is processing after primary adjudication.

Secondary Billing Logic

When a patient has both primary and secondary coverage, the secondary claim must include the primary payer's adjudication information from the 835. The secondary 837 claim includes the primary paid amount, the primary adjustment reason codes, and the remaining balance — calculated correctly as the difference between the primary allowed amount and the primary paid amount, not the difference between the billed amount and the primary paid amount.

This calculation is consistently one of the most error-prone aspects of RCM systems, and it is almost universally undertested because test data for secondary billing requires the existence of a primary EOB/ERA that preceded the secondary claim. Building a test data package for secondary billing logic means constructing realistic primary 835 transactions and then building the corresponding secondary 837 claims that reference them correctly.

Prior Authorization: Testing the Gate That Controls Claim Approval

Prior authorization requirements have expanded dramatically over the past decade. A 2022 AMA survey found that physicians reported an average of 45 prior authorization requests per physician per week — and that 35% of physicians reported that prior authorization delays had led to a serious adverse event for a patient. For RCM systems, prior authorization is both a clinical workflow touchpoint and a billing workflow dependency: a claim for a service that required prior authorization but lacked one will deny, and the retro-authorization process to recover that revenue is time-consuming and often unsuccessful.

Testing prior authorization automation requires test data that represents:

• Procedures that always require auth for a given payer (inpatient admissions, many surgical procedures, high-cost imaging like PET scans, certain specialty drugs)
• Procedures that require auth for some diagnoses but not others (MRI coverage varies by clinical indication for many payers)
• Procedures where auth was obtained but the auth number was not included on the claim — triggering CO-15 (payment adjusted because the authorization number listed on the claim was invalid or authorization was not received)
• Procedures where the auth was for a different date of service than the procedure was performed
• Retro-authorization scenarios: auth obtained after the service, with payer-specific rules about whether retro-auth is permitted and within what timeframe
• Auth denials that flow back into the denial management workflow with appropriate CO-197 (benefit could not be determined; authorization denied) coding

HCC Risk Adjustment for Medicare Advantage

Medicare Advantage (MA) plans pay their contracted providers on a fee-for-service basis but are themselves reimbursed by CMS based on the risk adjustment scores of their enrolled members. Hierarchical Condition Categories (HCCs) are groupings of ICD-10-CM diagnosis codes that represent chronic conditions with significant impact on healthcare resource utilization. A member with diabetes (HCC 19), chronic kidney disease stage 3 (HCC 137), and congestive heart failure (HCC 85) generates a risk adjustment factor (RAF) score considerably higher than a healthy member — and CMS pays the MA plan accordingly.

The clinical documentation and coding implications for RCM are significant. An MA plan has a financial interest in ensuring that all of a member's active HCC conditions are documented and coded at least once per year. If a patient has diabetes with peripheral neuropathy (E11.40, mapping to HCC 18) but the neuropathy is not documented and coded at the annual wellness visit, the MA plan is under-compensated for that patient's risk. RCM systems that support MA billing must track HCC capture across the year, flag encounters where recapture is possible, and generate appropriate coding suggestions.

Test data for HCC-aware RCM platforms requires patient populations with realistic chronic condition distributions — not random diagnosis assignments, but clinically coherent comorbidity patterns that reflect real disease relationships. A 72-year-old Medicare patient with type 2 diabetes should also plausibly have hypertension, chronic kidney disease, and cardiovascular disease. A patient whose only HCC is heart failure but who has no prior history of any cardiac disease or risk factors is a clinically implausible test patient that will not surface the HCC recapture logic that a real-world patient population demands.

What RCM Test Data Commonly Gets Wrong: The Field-Level Details

Beyond the structural issues of claim type coverage and modifier representation, there are specific data field errors that appear consistently in inadequate RCM test data:

NPI and Taxonomy Code Mismatches

The National Provider Identifier (NPI) is a 10-digit number assigned by CMS to individual providers (Type 1 NPI) and organizations (Type 2 NPI). On a claim, the rendering provider NPI should correspond to the individual who performed the service. The billing provider NPI may be a group or organization NPI. The taxonomy code associated with the NPI must match the type of service billed — a physical therapy service billed under an NPI with a primary care taxonomy will trigger an edit.

Test data that uses placeholder NPIs — or real NPIs pulled from the NPI Registry without verifying that the taxonomy codes match the services billed — will not surface taxonomy mismatch errors. A claim scrubber needs to see taxonomy mismatches to verify it correctly flags them. This requires test NPIs that have been assigned plausible taxonomy codes that match the specialty of the services billed.

Missing Referring Provider Information

Many payer contracts and some Medicare rules require a referring provider NPI on claims for consultation services, specialist referrals, and services ordered by a physician (such as labs and imaging). A missing referring provider NPI generates CO-16 denials from payers that require it. Generic test data frequently lacks the referring provider loop (Loop 2310F in the 837P transaction) entirely, meaning that claim scrubbers tested against that data will not validate referring provider requirements.

Invalid Admission Type and Source Codes on UB-04 Claims

UB-04 institutional claims require admission type codes (field locator 14) and admission source codes (field locator 15). Admission type 1 is emergency; type 2 is urgent; type 3 is elective; type 4 is newborn; type 5 is trauma. Admission source 1 is physician referral; source 7 is emergency room. These codes interact with the type of bill code and the principal diagnosis in ways that claim scrubbers must validate. An elective admission (type 3) for a principal diagnosis of acute MI (I21.09) is a clinical implausibility that a scrubber should flag. Test data that uses admission type 1 for all institutional claims will never exercise the logic that validates admission type against clinical context.

Incorrect Place of Service Codes for Telehealth

During the COVID-19 public health emergency, CMS temporarily authorized POS code 11 (office) for telehealth services to allow providers to be paid at the in-person rate. When the PHE ended, telehealth POS rules varied by payer — some continued to pay POS 02 (telehealth provided other than in patient's home) or POS 10 (telehealth provided in patient's home) at parity with in-person, while others reverted to pre-PHE telehealth rates. Test data that uses a single telehealth POS code across all payers will not surface the payer-specific telehealth billing rules that remain in flux across the commercial market.

Implementation Scenario Walk-Throughs

"I'm building a claim scrubber"

A claim scrubber needs test claims that fire every edit rule the scrubber is designed to enforce — and test claims that correctly pass every edit rule when the claim is compliant. For modifier rules alone, this means constructing claims with: modifier on the wrong code type, modifier on a modifier-exempt code, missing required modifier, conflicting modifiers (59 and 91 on the same line, or 25 on a non-E/M code), anesthesia modifiers on non-anesthesia codes, bilateral modifiers without correct laterality, and global period modifiers in the wrong post-surgical context. Multiply this by the 100+ modifiers in active use and by the payer-specific variations in modifier policy, and the test data requirement runs to tens of thousands of claim scenarios — far beyond what any test team will construct manually.

"I'm testing a denial management module"

A denial management module needs 835 ERA transactions that present realistic denial distributions. A real payer remittance will contain a mix of paid claims (no adjustment or minor contractual adjustments only), denied claims (CO codes with clinical or billing explanations), patient-responsibility reductions (PR codes), and coordination of benefits adjustments (OA codes). The denial mix should reflect realistic denial rates by denial type: in most practices, contractual adjustments (CO-45) are the most frequent, followed by eligibility and authorization denials, followed by clinical/medical necessity denials, followed by billing and coding errors. A denial test dataset that has 80% CO-11 medical necessity denials does not reflect reality and will produce a module that is tuned for an atypical denial distribution.

"I'm implementing an RCM platform for a new specialty"

An RCM platform being implemented for the first time in a specialty it has never served — say, a cardiothoracic surgery practice — needs test data that reflects that specialty's billing patterns before go-live. Cardiothoracic surgery billing involves complex global surgery period management (90-day globals for open heart procedures), assistant-at-surgery claims, split-care scenarios where the surgeon performs the procedure and the cardiologist handles postoperative management, and ICD-10-PCS procedure codes for inpatient cardiac procedures that require institutional billing expertise distinct from professional fee billing. A generic test dataset will not have a single cardiothoracic surgery claim. The RCM team implementing the platform will discover this on day one — unless they source specialty-specific test data before implementation begins.

The OIG Compliance Dimension: Why Bad Test Data Is a Regulatory Risk

The Office of Inspector General (OIG) Work Plan identifies billing patterns and claim types that are subject to audit review each year. The Recovery Audit Contractor (RAC) program, established under Section 1893 of the Social Security Act, allows for-profit contractors to audit Medicare claims and demand repayment of identified overpayments — plus interest. In fiscal year 2023, the RAC program identified more than $500 million in improper payments.

The connection to test data is this: RCM systems that are inadequately tested are more likely to pass claims that should be denied, and more likely to generate the billing patterns that OIG and RAC auditors target. An anesthesia billing module that was never tested against valid physical status modifier rules may be systematically overcoding anesthesia time units or physical status levels — creating an audit risk that exists in production before the billing team is even aware of the pattern.

OIG compliance programs for physician practices — recommended in the OIG's Compliance Program Guidance for Individual and Small Group Physician Practices — include routine claim audit and billing review processes. Those audit processes need test data to validate before being deployed to review real claims. A compliance audit tool tested on 500 claims from internal medicine will not correctly flag anesthesia overbilling, radiology ordering pattern anomalies, or E/M upcoding in surgical specialties — because the test data that trained its logic contained none of those patterns.

What a Complete RCM Test Data Package Requires

Based on the preceding analysis, a comprehensive RCM test data package must include:

• Claim volume by payer type — realistic distribution across Medicare fee-for-service, Medicare Advantage, Medicaid (multiple state programs), and commercial payers; not a uniform distribution but one weighted toward the payer mix that the RCM system's client population will actually submit
• 837P and 837I formatted claims — not just claim data elements but properly structured EDI transactions with correct loop hierarchy, required and situational segments populated appropriately, and payer-specific field variations
• Modifier populations by specialty — anesthesia modifiers with unit calculations, surgical modifiers with global period dates, bilateral modifiers with correct laterality, and E/M modifiers with correct application to the E/M code rather than the procedure
• Denial scenario sets by CARC/RARC combination — covering the major denial categories with realistic relative frequency, including CO-4, CO-11, CO-16, CO-97, CO-197, PR-1 through PR-3, and OA coordination of benefits codes
• 835 ERA remittance examples — for both primary adjudication and secondary adjudication, with realistic adjustment segment structures that include line-level detail
• Clinically coherent comorbidity patterns — not random diagnosis assignments, but diagnosis combinations that reflect real disease relationships and HCC groupings that support risk adjustment testing
• Prior authorization scenarios — procedures with and without required auth, claims with missing auth numbers, retro-auth situations, and auth denials flowing into denial management
• Realistic patient demographics — including age distributions that generate Medicare eligibility, income distributions that generate Medicaid eligibility, and demographic diversity that produces realistic name, address, and identification field variations

The anesthesia claims will come. The DME claims will come. The behavioral health claims with their telehealth modifiers and HCPCS Level II psychotherapy add-on codes will come. The MA patients whose HCCs need annual recapture will come. The dual-eligible patients with Medicare as primary and Medicaid as secondary will come. The surgical claims with 90-day global periods and a return to the OR on day 47 that needs modifier 78 will come.

The question — the only question that matters in RCM test data — is whether your system encounters them for the first time in testing, where the cost of failure is a bug report and a sprint to fix, or whether production is where they introduce themselves, with three weeks of claim backlog and a client relationship on the line.