Sandbox Mock Scenarios

Use this guide to test Sandbox mock responses for Real-Time Eligibility.

This page is intentionally about Sandbox-only fake data, not production behavior. The Sandbox always returns canned responses for these mock scenarios. Do not send or use PHI in the Sandbox environment.

Coverage Discovery mock responses are not covered here yet. This guide is currently limited to real-time eligibility. Coverage Discovery mock guidance will be added later.

What This Guide Is For

Use this page when you want predictable Sandbox responses for:

• normalized JSON real-time eligibility requests on POST /rcm/eligibility/v1
• X12 real-time eligibility requests on POST /rcm/eligibility/v1/real-time/x12

Do not use this page for:

• Production requests
• live payer behavior
• PHI testing
• Coverage Discovery mock responses
• general implementation guidance outside Sandbox mocks

Important Sandbox Rules

• All Sandbox mock responses use fake data.
• No PHI can be sent, stored, or used in the Sandbox environment.
• The returned response is canned and will come back the same way for the selected mock scenario.
• The x-optum-rcmelig-mock-scenarios header must be an exact string match.
• The header value is case-sensitive.

If the header value does not exactly match the configured scenario, including letter casing, do not expect the intended canned response.

JSON Real-Time

For normalized JSON real-time requests on POST /rcm/eligibility/v1, use the standard Sandbox request model and the normal Medical Network-supported request values.

JSON Sandbox real-time requests can use the Medical Network-supported values and tradingPartnerServiceId values documented here:

• Sandbox predefined fields and values
• Eligibility Sandbox API values and test responses

Use those references for supported JSON request values such as:

• tradingPartnerServiceId
• Medical Network-supported service and request field values

The payer ids used for Sandbox routing are IMN payer ids. To review additional supported payers, use the Optum Customer Connect payer list. That payer list is also the right reference for internal crosswalking when needed.

This guide does not duplicate the full JSON value catalog. Use the links above as the source of truth for JSON Sandbox request values.

X12 Real-Time

For X12 real-time requests on POST /rcm/eligibility/v1/real-time/x12, use the mock scenario header and the payer id guidance on this page.

Sandbox Header

Send this request header:

x-optum-rcmelig-mock-scenarios: <scenario-value>

Example:

x-optum-rcmelig-mock-scenarios: BCBS-TX-SB900-ELIGIBLE-HMO-DEPENDENT-SPOUSE-RTE-X12

The header string must be an exact match and is case-sensitive.

Important X12 Rule

The request value that must align to the scenario is the payer id in the X12 NM1*PR*2 segment.

Send the payer id in the PI element:

NM1*PR*2*<PAYER NAME>*****PI*<IMN PAYER ID>~

Example for SB900:

NM1*PR*2*TEXAS BLUE CROSS BLUE SHIELD*****PI*SB900~

The payer ids in this guide are IMN payer ids. To review additional supported payers, use the Optum Customer Connect payer list. That payer list can also be used for internal crosswalking when needed.

What Does Not Need To Match

For the current Sandbox mock implementation, the response is canned. Your submitted member and demographic details do not drive the returned patient or benefit story.

These request values do not control the returned subscriber, dependent, or benefit content:

• subscriber first name
• subscriber last name
• subscriber member id
• subscriber DOB
• dependent name
• dependent DOB
• service date
• address values
• most other X12 demographic fields

The selected mock scenario controls the canned outcome.

Expected Member Story For Dependent Scenarios

Even though the Sandbox response is canned, the dependent and spouse scenarios return a fixed fake subscriber/patient story so you know what to expect in the response.

• For spouse scenarios, expect the returned subscriber to be JANEONE DOEONE and the returned spouse/patient to be JOHNTWO DOEONE.
• For dependent child scenarios, expect the returned subscriber to be JANEONE DOEONE and the returned child/patient to be JOHNTWO DOEONE.
• Spouse mock responses use an adult spouse DOB pattern.
• Child mock responses use a younger child DOB pattern.
• These returned names and DOBs are canned fake data. They do not come from the request payload you send.
• These Sandbox-only fake values are not supported for production use. If they are reused in production requests, expect a processing_error rather than the canned Sandbox behavior.
• The payer id in NM1*PR*2 ... PI* still must match the selected scenario.

Request Mapping Note

If you want your test request to read similarly to the canned response, you can send:

• subscriber name: JANEONE DOEONE
• spouse name: JOHNTWO DOEONE
• dependent child name: JOHNTWO DOEONE

This is optional. The response remains canned regardless of the subscriber or dependent values you submit.

AAA76 Cigna Caveat

For CIGNA-CIGNA-REJECTED-DEPENDENT-DUPLICATE-SUBSCRIBER-ID-AAA76-RTE-X12, the request still represents a dependent flow, but the rejection is at the subscriber level. Because of that, the normalized real-time response may not look like a normal successful dependent transaction even though a dependent loop is present in the x12-271.

What To Assert In Sandbox

X12 mock scenarios return the normal real-time eligibility transaction model.

• root transaction fields such as id, correlationId, processedDate, sourceType, and status.value
• nested normalized objects such as patient, subscriber, and payer
• the raw x12-271 when you need to verify AAA codes or dependent-loop structure

How To Use An X12 Scenario

1. Submit POST /rcm/eligibility/v1/real-time/x12.
2. Send x-optum-rcmelig-mock-scenarios with one of the exact values in the table below.
3. Make sure the NM1*PR*2 ... PI* payer id matches the scenario.
4. Expect the canned Sandbox response for that scenario.

Current Supported Real-Time X12 Scenarios

The scenarios below are ordered from the most common happy-path and business-result cases first, then pending and temporary-failure cases, and finally reject-path scenarios.

X12 Request Example

This is a minimal example showing where the payer id belongs.

ISA*00*          *01*SomePwd   *ZZ*TPG00000       *ZZ*IMNDIRECT      *260101*1201*^*00501*900000001*0*T*:~
GS*HS*SUBMITTER*RECEIVER*20260101*1201*900000001*X*005010X279A1~
ST*270*900000001*005010X279A1~
BHT*0022*13*123456789*20260101*120101~
HL*1**20*1~
NM1*PR*2*WELLCARE HEALTH PLANS*****PI*WLLCR~
HL*2*1*21*1~
NM1*1P*2*EXAMPLE PROVIDER*****XX*1234567893~
HL*3*2*22*0~
NM1*IL*1*ANYLAST*ANYFIRST****MI*ANYMEMBERID~
DMG*D8*19900101*F~
DTP*291*D8*20260101~
EQ*30~
SE*12*900000001~
GE*1*900000001~
IEA*1*900000001~

X12 Request Body Example

Send the X12 string in the JSON body:

{
  "x12": "ISA*00*...~IEA*1*900000001~"
}

Sandbox Behavior Summary

The current Sandbox mock scenarios are designed to be predictable, not dynamic.

• JSON real-time can use the supported Sandbox request values documented in the linked Optum references above.
• X12 real-time uses the exact x-optum-rcmelig-mock-scenarios header value plus the payer id in NM1*PR*2 ... PI*.
• The Sandbox returns canned fake-data responses.
• No PHI should be sent or used in Sandbox testing.
• Coverage Discovery mock responses are not included on this page yet.