Testing - Medical and Dental Claims

Testing may be performed by making calls to the sandbox system, sandbox.services.apexedi.com, instead of the production system.

When submitting test transactions, please do not submit protected health information (PHI).

When submitting claims, one or more claims may be submitted per call. After submitting a claim to the sandbox system, claim status will be available within a few minutes.

Test claims go through the same initial validation process as live claims but are handled by a simulated payer. The default behavior of the simulated payer is to return a Claim Status resposne (277), acknowledging the receipt of the claim or claims. A short time later a remittance advice response (835) is generated in which all claims appear and all of the service lines are paid. 80% of the submitted amount for each service line is paid, and the other 20% is identified as patient responsibility. When a remittance advice document is generated, it hides any earlier claim status document received since only the most recent response document is available. In order to test the handling of claim status documents, the field F01A_InsuredId can be set to 2001. This will suppress the creation of the remittance advice document for the associated claim. This simulates the behavior of submitting a claim and receiving only a claim status response from the payer. (Presumably the payer would generate a remittance advice document on a subsequent day, but when 2001 is submitted as the value of F01A_InsuredId in the sandbox system, no remittance advice document is ever generated.)

In a similar manner, when the value of 2002 is submitted for F01A_InsuredId, the claim status document generated will be a rejection. In this case, no remittance advice document will ever be generated, just as would be the case with a live payer.

The following is a summary of alternative simulated behaviors determined by specific subscriber IDs (F01A_InsuredId) used in test claims:

• 2001. The receipt of the claim is acknowledged in the 277, but the claim does not appear in an 835. (Suppress835)
• 2002. The claim is rejected in the 277. The claim will not appear in an 835. (Rejection277)
• 2003. Not used.
• 2004. The claim is rejected in the 277. The first service line in the claim is mentioned in loop 2220D of the 277 where a reason for the rejection is given. (ServiceLineRejection277)
• 2005. The claim is rejected in a 999. The error is reported to be a syntax error. (This error is generated even if no actual syntax error was present in the claim.) (Rejection999)
• 2006. Multiple STC segments are generated for the claim in the 277. (MultipleStcsIn277)
• 2007. A claim with this subscriber ID should have multiple service lines. The claim is split. The first service line is denied in the 835. The other service lines are omitted as if they would appear in a subsequent 835, but no subsequent 835 is generated. (SplitEobDenyFirstServiceLine)
• 2008. A claim with this subscriber ID should have multiple service lines. The claim is split. The first service line is omitted from the 835, as if it had appeared in a previous 835 (although no previous 835 is actually generated). The other service lines are paid. (SplitEobPaySubsequentServiceLines)