ClaimRev Support Documentation

User Tools

Site Tools

Trace:
sharp_revenue_mock_scenario_intake

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
sharp_revenue_mock_scenario_intake [2026/05/06 18:43] – Document patient-identity match keys for no-key products + 5-dimension matching brad.sharpsharp_revenue_mock_scenario_intake [2026/05/06 19:42] (current) – Document no-key product strip behavior at CSV import brad.sharp
Line 36: Line 36:
  
 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. 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. A column left blank acts as a //wildcard// for that field — the scenario fires regardless of what the EMR sends for it.
Line 42: Line 44:
 | ScenarioName | yes | Short label the scenario will be filed under (e.g. ''Medicare-Active'', ''BCBS-Inactive'', ''Aetna-Pending''). Used as the human-readable name; not shown to the EMR. | | ScenarioName | yes | Short label the scenario will be filed under (e.g. ''Medicare-Active'', ''BCBS-Inactive'', ''Aetna-Pending''). Used as the human-readable name; not shown to the EMR. |
 | TransactionUrl | yes | The full //view-visit// URL copied in Step 1. ClaimRev parses the transaction id out of this server-side. | | TransactionUrl | yes | The full //view-visit// URL copied in Step 1. ClaimRev parses the transaction id out of this server-side. |
-| MatchSubscriberId | optional | If set, the scenario only replays when the EMR's Subscriber Id matches this value exactly. **Leave blank to match any subscriber id** (useful for "any patient on this payer" scenarios — pair with MatchPayerNumber). | +| MatchSubscriberId | optional | If set, the scenario only replays when the EMR's Subscriber Id matches this value exactly. **Leave blank to match any subscriber id** (useful for "any patient on this payer" scenarios — pair with MatchPayerNumber). //Stripped at import for no-key product rows.// | 
-| MatchPayerNumber | optional | If set, the scenario only replays when the request's Payer Number matches. **Use the Revenue Tools payer id**, not the claim payer id — see [[#A Note On Payer Ids]] below. **Leave blank to match any payer** (useful for "this specific patient regardless of which insurer the EMR sends" scenarios — pair with MatchSubscriberId). | +| MatchPayerNumber | optional | If set, the scenario only replays when the request's Payer Number matches. **Use the Revenue Tools payer id**, not the claim payer id — see [[#A Note On Payer Ids]] below. **Leave blank to match any payer** (useful for "this specific patient regardless of which insurer the EMR sends" scenarios — pair with MatchSubscriberId). //Stripped at import for no-key product rows.// | 
-| MatchSubscriberSuffix | optional | Magic-suffix override. Example: setting this to ''-PENDING'' attaches a "pending" variant to the same subscriber id. Leave blank for the normal scenario. |+| MatchSubscriberSuffix | optional | Magic-suffix override. Example: setting this to ''-PENDING'' attaches a "pending" variant to the same subscriber id. Leave blank for the normal scenario. //Stripped at import for no-key product rows.// |
 | TargetAccountNumber | optional | **Leave blank.** ClaimRev fills this in when copying to your test account. | | TargetAccountNumber | optional | **Leave blank.** ClaimRev fills this in when copying to your test account. |
 | Description | optional | One-liner describing what the scenario is for. Shows up in the Mock Library management page; helpful for your future self. | | Description | optional | One-liner describing what the scenario is for. Shows up in the Mock Library management page; helpful for your future self. |
Line 115: Line 117:
  
 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. 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: Two consequences worth knowing:
Line 177: Line 181:
   * **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.   * **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.   * **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.   * **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**.   * **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**.
Line 195: Line 200:
 **Q: My scenario isn't firing — what should I check?** \\ **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. 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?** \\ **Q: Can I have a scenario that fires for any patient on a particular payer?** \\
sharp_revenue_mock_scenario_intake.1778093024.txt.gz · Last modified: by brad.sharp
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki