Sharp Revenue Mock Scenario Intake

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.

Every row must have at least one match dimension so it doesn't catch every request to its endpoint. The available dimensions are:

1. MatchSubscriberId / MatchPayerNumber / MatchSubscriberSuffix — explicit match keys, set in the CSV. Used by Eligibility, Claim Status, and Prior Auth Verification scenarios where the request carries subscriber + payer.
2. Patient identity (cartoon first name + last name + DOB) — auto-stamped at capture time for products that don't carry a subscriber/payer (Insurance Discovery, MBI Finder, Demographics, Advanced Medicaid). You don't fill this in via the CSV — see Patient Identity Match Keys below.

If you leave all three Match* columns blank for an Eligibility / Claim Status / Prior Auth row (which DO carry subscriber+payer in the request), the import is rejected because patient auto-stamp doesn't apply to those products. For no-key products (Insurance Discovery / MBI Finder / Demographics / Advanced Medicaid), leaving the Match* columns blank is normal — the patient auto-stamp gives the row its match dimension.

Important — what happens if you put Match* values on a no-key-product row anyway: the import silently strips them before persisting. Insurance Discovery / MBI Finder / Demographics / Advanced Medicaid requests carry no subscriber id or payer number at runtime, so any Match* values you supply for those rows would never match real traffic. Stripping them lets the patient auto-stamp fire instead and gives the row a usable match key. If you actually want subscriber/payer-keyed matching, capture from a transaction that includes Eligibility (alone or alongside the no-key product) — mixed-product captures preserve your Match* values because the Eligibility component still carries subscriber/payer.

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.
InsuranceDiscovery-Found,https://portal.claimrev.com/sharprevenue/(revenueToolsOut:view-visit/65f2a1b3c4d5e6f7a8b9c0d7/eligibility),,,,,Insurance discovery returns coverage,Patient identity auto-stamps from the cartoon scrub - no Match* columns needed.

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 / Patient name / DOB (whichever are set on the row).
• 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 / Patient name / DOB). 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 + the five match-key dimensions (Subscriber Id, Payer Number, Patient First Name, Patient Last Name, Patient DOB), 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 stored field that is blank matches any request value for that field. When more than one scenario could fire, more-specific wins — fewer blank fields = more specific.
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.

Some Sharp Revenue products don't carry a subscriber id or a payer number in the request — they discover something about a patient from the patient's demographics (name + DOB + SSN). These are:

• Insurance Discovery (product 3) — finds insurance for a patient.
• MBI Finder (product 5) — finds a Medicare MBI for a patient.
• Demographics (product 2) — verifies / supplements demographic data.
• Advanced Medicaid (product 4) — Medicaid-specific eligibility.

For these products, the mock library can't match on subscriber/payer (the request doesn't have them). Instead, patient identity is auto-stamped at capture from the anonymized (cartoon) source patient: First Name, Last Name, and DOB. So a captured Insurance Discovery scenario fires for requests whose patient identity matches the captured cartoon name + DOB.

The capture flow also silently strips any MatchSubscriberId / MatchPayerNumber / MatchSubscriberSuffix the CSV supplied for these rows — those values would never match a real no-key request, so removing them lets the patient auto-stamp give the scenario a usable match key.

Two consequences worth knowing:

• The captured response and the match key stay internally consistent. Mock returns “Mickey Mouse / 1928-11-18” data for a request that asked about “Mickey Mouse / 1928-11-18” — coherent demo, no name mismatch in the EMR's UI.
• Configure your test-EMR demo patients to match the cartoon names stamped on your captured library. The Mock Library page surfaces the cartoon name + DOB you need to set up. Effectively a one-time “create these demo patients in your test EMR” handoff per captured library.

The patient match key is always the anonymized cartoon name + cartoon-shifted DOB. Real patient PHI never lands on the persisted match key.

If you want to capture multiple Insurance Discovery scenarios (e.g. “found insurance” vs “no insurance”), capture from different source transactions — each gets its own cartoon identity, so they discriminate naturally. If you want to override the auto-stamped name (e.g. so it matches a specific test patient your EMR already has set up), edit the scenario in the Mock Library page after capture.

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.
• Auto-stamps the cartoon patient name + DOB onto the persisted MatchKey for no-key products. Real patient PHI never reaches the match-key surface.

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 dimension must end up set on every row. For Eligibility / Claim Status / Prior Auth: at least one of Subscriber Id / Payer Number / Suffix in the CSV. For Insurance Discovery / MBI Finder / Demographics / Advanced Medicaid: leave the Match* columns blank — patient identity auto-stamps from the cartoon scrub. An all-blank row that also can't auto-stamp (malformed source with no patient identity) is rejected.
• Don't bother filling Match* columns on no-key product rows. They're stripped at import. The patient auto-stamp is the sole match dimension for those scenarios.
• 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.
• For no-key products, configure your EMR's demo patients to match the cartoon identities stamped on your captured library. The cartoon names + DOBs are visible in Revenue Tools → Admin → Mock Library.
• 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. The patient match keys auto-stamped onto the persisted MatchKey are the cartoon name + cartoon-shifted DOB only — never real PHI.

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. For no-key products (Insurance Discovery / MBI Finder / Demographics / Advanced Medicaid), check that your EMR's demo patient name + DOB matches the cartoon identity stamped on the scenario — the Mock Library page shows what to use. 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: I put a SubscriberId on my Insurance Discovery / MBI Finder row but my scenario isn't firing — why?
Insurance Discovery / MBI Finder / Demographics / Advanced Medicaid requests carry no subscriber id at runtime, so any value you supply for those rows can't ever match a real request. The import flow strips the Match* columns for no-key product rows and stamps patient identity instead. Open Revenue Tools → Admin → Mock Library to see the cartoon name + DOB the row is keyed on, and configure your test-EMR demo patient to match those.

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: How do I demo multiple Insurance Discovery / MBI Finder scenarios for different patients?
Capture from different source transactions — each one gets its own cartoon patient identity, which becomes the match key. Then configure that many demo patients in your test EMR with names + DOBs that match the cartoons. The Mock Library page shows you exactly which cartoon identity each scenario is keyed on.

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 (Subscriber Id / Payer / Suffix / Patient name / DOB); 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.