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 in your test account.
4. At runtime, eligibility requests from your test account hit your own captured library first — each EMR's test account has its own private set of scenarios — and fall back to ClaimRev's curated default library if nothing matches.

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.

The three Match* columns are individually optional, but at least one of MatchSubscriberId, MatchPayerNumber, or MatchSubscriberSuffix must be set on every row. A row with all three blank would catch every request to the endpoint and is rejected at import. A column left blank acts as a wildcard for that field — the scenario fires regardless of what the EMR sends for it.

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.
GenericMedicare,https://portal.claimrev.com/sharprevenue/(revenueToolsOut:view-visit/65f2a1b3c4d5e6f7a8b9c0d6/eligibility),,00060,,,Any-subscriber Medicare scenario,Wildcard subscriber - fires for any member id sent against Medicare.

Email the CSV to your ClaimRev contact. Include:

• Which test account the scenarios should land in (account number, e.g. DEMO1). Each EMR's test account gets its own private mock library — your scenarios are not visible to or reachable from any other customer's test account.
• 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 below 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. Match on Account + Endpoint + Subscriber Id + Payer Number, with the products filter (see below) applied on top. The lookup is scoped to your test account — your captured scenarios don't bleed into anyone else's library and vice versa. Match-key fields use wildcard semantics: a scenario whose MatchSubscriberId or MatchPayerNumber is blank matches any request value for that field. When more than one scenario could fire, more-specific wins — a scenario with both Subscriber Id and Payer Number set beats a scenario with only one set, which beats a scenario with neither (which can't be persisted anyway, see Step 2).
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.

The Sharp Revenue API supports two flavors of payer id (see the API Guide for the underlying flag):

• Revenue Tools payer id — ClaimRev's internal payer catalog id (e.g. 00060 for Medicare). Sent with isRevenueToolsPayerId: true.
• Claim payer id — the payer id your EMR uses on outbound 837 claims (e.g. 87726 for UnitedHealthcare). Sent with isRevenueToolsPayerId: false. In production, the API translates this to the corresponding Revenue Tools id internally before contacting the vendor.

The mock pipeline matches on the Revenue Tools payer id only. When ClaimRev captures a scenario, the MatchPayerNumber that gets stamped is the Revenue Tools id, and at runtime MockZollSend looks up scenarios using whatever payer id is on the wire. So:

• If your EMR sends isRevenueToolsPayerId: true with a Revenue Tools id (e.g. 00060), the mock will find a matching scenario tagged with 00060.
• If your EMR sends isRevenueToolsPayerId: false with a claim payer id (e.g. 87726), the mock will look up 87726 as-is — and won't find your 00060 scenario, even though they're the same payer in production.

For mock-mode demos, configure your EMR client to send Revenue Tools payer ids (set isRevenueToolsPayerId: true). Once you switch back to real-mode for production traffic, claim payer ids work normally — the mismatch is mock-pipeline-specific.

Each captured scenario is auto-tagged with the products that ran in the original transaction. Today the recognized product ids are:

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.
• At least one match-key field must be set per row. Subscriber Id alone is usually enough for a per-patient scenario; Payer Number alone is enough for a per-payer catch-all. An all-blank row is rejected at import — the system won't let you persist a scenario that would catch every request to its endpoint.
• Blank match-key fields wildcard. A row with Subscriber Id but no Payer Number fires for that subscriber on any payer; a row with Payer Number but no Subscriber Id fires for any subscriber on that payer. When two scenarios could both match, the more-specific one wins.
• Use Revenue Tools payer ids in match keys — claim payer ids aren't translated by the mock pipeline, so an EMR request that sets isRevenueToolsPayerId: false won't fire a scenario tagged with the Revenue Tools id. See A Note On Payer Ids.
• 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.
• Avoid capturing error-status transactions as scenarios — when an eligibility request errored upstream there's no real 271 envelope to scrub, so the captured response will not have any benefits data to display when replayed.

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: Are my scenarios visible to other customers in their test accounts?
No. Each EMR's test account has its own private mock library. The runtime lookup is scoped to your account — other customers can't see your captures, and you can't see theirs. The only shared bucket is ClaimRev's curated default library, which is read-only for customers.

Q: My scenario isn't firing — what should I check?
Most common cause: payer-id mismatch. The mock matches on the Revenue Tools payer id only, so if your EMR is sending isRevenueToolsPayerId: false with a claim payer id (e.g. 87726), the mock looks up that exact value and won't find your scenario tagged with the Revenue Tools id (e.g. 00060). Switch the EMR client to send Revenue Tools ids for mock-mode demos. See A Note On Payer Ids for the full picture. Other things worth checking: the practice's ZollHost is set to the mock sentinel, the request's Subscriber Id matches your scenario's match key (or your scenario's Subscriber Id is intentionally blank to wildcard), and the request's products are a superset of the scenario's tagged products.

Q: Can I have a scenario that fires for any patient on a particular payer?
Yes. Leave MatchSubscriberId blank and set only MatchPayerNumber. The blank field acts as a wildcard so any subscriber id on that payer matches the scenario. If a more specific scenario (both Subscriber Id and Payer Number set) also matches the same request, the specific one wins.

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.