This page describes how to request a set of mock eligibility / claim-status scenarios for your test account, using your own production transactions as the source. Once captured, these scenarios are PHI-scrubbed and copied into your test account so you can demo eligibility flows in your EMR with realistic-looking data that always returns the same response.

• You're preparing a demo of your EMR's eligibility integration and want to be sure the same active / inactive / pending / errored responses come back every time.
• You want demo data that mirrors the kinds of payers and member structures your real patients have, without exposing any actual PHI.
• You'd rather pick a handful of meaningful real transactions than build synthetic test data from scratch.

1. You browse your own production Sharp Revenue transactions and pick the ones you'd like turned into demo scenarios.
2. You send ClaimRev a CSV listing each scenario by name, the transaction URL, and the match keys you want (subscriber id, payer number, optional suffix).
3. ClaimRev anonymizes each transaction (cartoon names, scrubbed addresses, scrubbed embedded EDI) and saves it as a mock scenario.
4. The scenarios are copied into your test account. Future eligibility requests against that test account that match a scenario's keys return the canned response — instantly, repeatably, and offline-safe for demos.

In the production portal:

1. Go to Revenue Tools → Transaction Search.
2. Filter by date / payer / patient as needed to narrow down the rows.
3. For each row you want as a demo scenario, click the View icon.
4. Copy the full URL from the browser. It will look like:
   https://portal.claimrev.com/sharprevenue/(revenueToolsOut:view-visit/<TransactionId>/eligibility)
5. Paste that URL into your CSV under the TransactionUrl column.

ScenarioName,TransactionUrl,MatchSubscriberId,MatchPayerNumber,MatchSubscriberSuffix,TargetAccountNumber,Description,Notes
Medicare-Active,https://portal.claimrev.com/sharprevenue/(revenueToolsOut:view-visit/65f2a1b3c4d5e6f7a8b9c0d1/eligibility),W123456789T,00060,,,Active Medicare with deductible,Standard active Medicare with deductible.
BCBS-Active,https://portal.claimrev.com/sharprevenue/(revenueToolsOut:view-visit/65f2a1b3c4d5e6f7a8b9c0d2/eligibility),YPL123456789,00015,,,Active BCBS PPO,Good for showing benefit details.
BCBS-Pending,https://portal.claimrev.com/sharprevenue/(revenueToolsOut:view-visit/65f2a1b3c4d5e6f7a8b9c0d3/eligibility),YPL123456789,00015,-PENDING,,Pending verification variant,Same patient still being verified.
Aetna-Inactive,https://portal.claimrev.com/sharprevenue/(revenueToolsOut:view-visit/65f2a1b3c4d5e6f7a8b9c0d4/eligibility),W987654321,60054,,,Termed coverage,Coverage termed last month.
Aetna-NotFound,https://portal.claimrev.com/sharprevenue/(revenueToolsOut:view-visit/65f2a1b3c4d5e6f7a8b9c0d5/eligibility),NOTREAL999,60054,,,Wrong member id,Shows the no-match flow.

Email the CSV to your ClaimRev contact. Include:

• Which test account the scenarios should land in (account number, e.g. DEMO1).
• Approximate timing — when do you need the demo ready by?

ClaimRev will reply once the scenarios are loaded. From that point on, eligibility requests against your test account that hit the configured match keys will return the captured (anonymized) responses.

Once scenarios are loaded, you can browse and tweak them yourself in Revenue Tools → Admin → Mock Library. The page is gated by one of two scopes:

• practice_admin:sharprevenue-mock-mgmt — for customer admins. You see scenarios filed under your own account, and (read-only) the curated default-library entries that ClaimRev seeds for everyone.
• admin:sharprevenue-mock-mgmt — for ClaimRev staff. Same view plus the ability to edit and delete default-library entries.

Per row you'll see:

• Scenario name + a Source chip (your account number, or “Default” for ClaimRev-seeded entries).
• Endpoint the scenario answers (currently RunTestsJSON for eligibility/coverage discovery, with claim-status to follow).
• Match key summary — Subscriber Id / Payer / Suffix.
• Products — auto-stamped at capture (e.g. Eligibility or Eligibility, Demographics). See Product-Aware Matching above for what subset semantics buy you.
• Description — your own free-text label.
• Created — capture timestamp.

Per row you can:

• Run As Is (▶) — synthesizes a SharpRevenueRequest using the scenario's match keys and posts it through RunSharpRevenue. The response lands in the regular Transaction Search list — useful for confirming the round-trip works end-to-end.
• View Original (⤴) — only shown for scenarios captured from a real transaction in your own account. Default-library entries don't have a source link.
• Edit (✎) — rename the scenario, update the description, adjust match keys (Subscriber Id / Payer / Suffix). Account number, products, and the canned response payload are immutable post-capture.
• Delete (🗑) — only for scenarios you own. ClaimRev admins can also delete default-library entries.

The page never shows the canned response payload itself — by design, the management surface only exposes metadata.

When your EMR sends a Sharp Revenue request, the mock looks for a scenario in this order:

1. Suffix override. If the request's Subscriber Id ends with a known magic suffix (e.g. -PENDING), the scenario tagged with that suffix wins — regardless of subscriber/payer.
2. Exact match on Subscriber Id + Payer Number + Products.
3. Default library fallback. If no match was found under your test account, the lookup retries against ClaimRev's curated default library — these are stock scenarios (e.g. a generic Medicare-Active) that work for any account in mock mode. You don't manage these; they're pre-loaded by ClaimRev and live alongside your account-specific captures.
4. No match → loud error. If neither account-specific nor default library scenarios match, the response is a Zoll-shaped error so the EMR sees something obviously wrong rather than stale data.

Each captured scenario is auto-tagged with the products that ran in the original transaction (Eligibility=1, Demographics=2, Insurance Discovery=3, MBI Finder=5, etc.). At lookup time the scenario only fires if the request asks for a superset of those products — so:

• A captured Eligibility-only scenario fires for an Eligibility request, and also for an Eligibility + Demographics combo request.
• A captured Insurance Discovery scenario does not fire for an Eligibility-only request, even when subscriber id and payer number happen to coincide. This prevents a Coverage-Discovery payload from being served when an EMR asked for plain eligibility.
• A captured Eligibility + Demographics scenario only fires when the request asks for both.

You don't need to put anything in the CSV for this — it's stamped automatically from the original transaction. The result is that one production transaction maps cleanly to exactly the request shape it was captured from.

Before any captured transaction is saved, ClaimRev runs it through an anonymization pipeline that:

• Replaces patient and subscriber names with cartoon-character placeholders (consistently — the same source patient gets the same cartoon name across the JSON and the embedded EDI).
• Stamps a fake member id and date of birth.
• Replaces street addresses, cities, phone numbers, and emails with synthetic equivalents.
• Walks the embedded Raw271 / Raw277 EDI strings and rewrites the same fields in place, so the EDI you see in the captured response is structurally valid but PHI-free.
• Replaces the response's ClientId with the test account it's filed under.

The original production record is not modified — anonymization runs on a deep copy.

• Pick scenarios that exercise different code paths — at least one Active, one Inactive, one Not-Found, and one error or pending. That gives a meaningful demo without needing dozens of rows.
• Match keys are optional but recommended. Without them, the only thing distinguishing one captured scenario from another is the order they were inserted; with them, your EMR's request data drives which scenario comes back. Subscriber Id alone is usually enough.
• Use clear scenario names. Medicare-Active, BCBS-Inactive-Termed, and Aetna-Pending-Auth are far easier to discuss than Test1 / Test2.
• Suffix variants let one subscriber demo multiple states. Capturing the same subscriber id under suffixes -PENDING and -ERROR lets your EMR demo “this patient came back pending yesterday but errored today.”
• Capture from the right product run. If you're demoing eligibility, pick an eligibility transaction; if you're demoing coverage discovery, pick a coverage-discovery transaction. The mock won't cross-serve between products.

Q: Will my real patients' information ever appear in the test account?
No. Every captured scenario is anonymized before it's saved, and your real production data is not modified.

Q: Can I update or remove a scenario later?
Yes. Open Revenue Tools → Admin → Mock Library and use the Edit / Delete actions. You can edit the name, description, and match keys; the response payload itself is immutable post-capture.

Q: Do I need a special permission to send this CSV?
No, this is just an email handoff. Capture is done by ClaimRev staff against your test account, not by you in the portal. To browse the library yourself afterwards, your account needs the practice_admin:sharprevenue-mock-mgmt scope.

Q: My EMR sends both Eligibility and Demographics in one call — do I need two separate captures?
No. Capture one transaction that ran both products, and it will fire when your EMR asks for both. If you only ever capture Eligibility-only transactions and your EMR asks for Eligibility + Demographics, the Eligibility-only scenario will still fire (it's a subset of the request).

Q: What happens if I don't have a captured scenario but a stock one exists?
The mock falls back to ClaimRev's curated default library before erroring out. So if you want a generic Medicare-Active scenario “for free” without sending a CSV, ask your ClaimRev rep what's already in the default library.

Q: How is this different from the letter-based mock rules in the API Guide?
The letter-based rules (e.g. “first name starts with H returns Active”) are a generic vendor mock useful for synthetic test data. Captured scenarios let you demo with payloads that look like your production data — same payers, same member-id formats, same benefit details — without any real PHI. Use the letter-based rules when you don't have real data yet; use captured scenarios when you want a polished demo for a stakeholder.