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,Notes
Medicare-Active,https://portal.claimrev.com/sharprevenue/(revenueToolsOut:view-visit/65f2a1b3c4d5e6f7a8b9c0d1/eligibility),W123456789T,00060,,,Standard active Medicare with deductible.
BCBS-Active,https://portal.claimrev.com/sharprevenue/(revenueToolsOut:view-visit/65f2a1b3c4d5e6f7a8b9c0d2/eligibility),YPL123456789,00015,,,BCBS PPO with copay - good for showing benefit details.
BCBS-Pending,https://portal.claimrev.com/sharprevenue/(revenueToolsOut:view-visit/65f2a1b3c4d5e6f7a8b9c0d3/eligibility),YPL123456789,00015,-PENDING,,Same patient still being verified.
Aetna-Inactive,https://portal.claimrev.com/sharprevenue/(revenueToolsOut:view-visit/65f2a1b3c4d5e6f7a8b9c0d4/eligibility),W987654321,60054,,,Coverage termed last month - shows an inactive flow.
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.

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.”

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. Send the ClaimRev rep a list of scenario names to remove, or a CSV of replacements. There is currently no self-service screen for managing the captured library.

Q: Do I need a special permission to send this CSV?
No, this is just an email handoff. Capture and load are done by ClaimRev staff against your test account, not by you in the portal.

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.