Helpdesk: 877-693-3071

Testing Types Explained

Testing electronic transactions usually involves WEDI/SNIP testing types at some point. These types describe different ways to validate that an electronic transaction is correct. Although compliance with some types are commonly required by all payers, other types are required by some payers and not by others.

5010 Testing Note: Most payers only require that claims be compliant with types 1 & 2 (explained below). However, Altius, Regence BlueCross BlueShield and Medicare require compliance with types 1-4. Please take the more rigorous requirements into account when testing directly with these three payers.

 

The following information is an Excerpt from a 2002 white paper of the Strategic National Implementation Process. You can view the full document on the WEDI website.


In the past this white paper had referred to these types of testing as “levels”. However, the word “level” gave the incorrect impression that these types of testing built on each other in some manner, and that the testing could be stopped at a certain level. In order to try to correct this misperception, we are now calling them “types” of testing, more clearly conveying the notion that they are independent of each other. We recommend that all of these types of testing be completed for HIPAA compliance.

Recommended Types of Testing:


Type 1: EDI syntax integrity testing – Testing of the EDI file for valid segments, segment order, element attributes, testing for numeric values in numeric data elements, validation of X12 or NCPDP syntax, and compliance with X12 and NCPDP rules. This will validate the basic syntactical integrity of the EDI submission.

Type 2: HIPAA syntactical requirement testing – Testing for HIPAA Implementation Guide-specific syntax requirements, such as limits on repeat counts, used and not used qualifiers, codes, elements and segments. Also included in this type is testing for HIPAA required or intra-segment situational data elements, testing for non-medical code sets as laid out in the Implementation Guide, and values and codes noted in the Implementation Guide via an X12 code list or table.

Type 3: Balancing – Testing the transaction for balanced field totals, financial balancing of claims or remittance advice, and balancing of summary fields, if appropriate. An example of this includes items such as all claim line item amounts equal the total claim amount. (See pages 19-22, Healthcare Claim Payment/Advice –835 Implementation Guide for balancing requirements of the 835 transaction.)

Type 4: Situation testing – The testing of specific inter-segment situations described in the HIPAA Implementation Guides, such that: If A occurs then B must be populated. This is considered to include the validation of situational fields given values or situations present elsewhere in the file. Example: if the claim is for an accident, the accident date must be present.

Type 5: External code set testing – Testing for valid Implementation Guide-specific code set values and other code sets adopted as HIPAA standards. This level of testing will not only validate the code sets but also make sure the usage is appropriate for any particular transaction and appropriate with the coding guidelines that apply to the specific code set. Validates external code sets and tables such as CPT, ICD9, CDT, NDC, status codes, adjustment reason codes, and their appropriate use for the transaction.

Type 6: Product types or line of services – This testing type is required to ensure that the segments/records of data that differ based on certain healthcare services are properly created and processed into claims data formats. These specific requirements are described in the Implementation Guides for the different product types or lines of service. For example, ambulance, chiropractic, podiatry, home health, parenteral and enteral nutrition, durable medical equipment, psychiatry, and other specialized services have specific requirements in the Implementation Guide that must be tested before putting the transaction in production. This type of testing only applies to a trading partner candidate that conducts transactions for the specific line of business or product type.

Type 7: Implementation Guide-Specific Trading Partners – The Implementation Guides contain some HIPAA requirements that are specific to Medicare, Medicaid, and Indian Health. Compliance or testing with these payer specific requirements is not required from all trading partners. If the trading partner candidate intends to exchange transactions with one of these Implementation Guide special payers, this type of testing is required. When a certification service certifies a trading partner for compliance, the certification service must indicate whether these payer specific requirements were met during the certification process. Other payers and trading partners may have their own specific business requirements; but, unless they are listed in the HIPAA Implementation Guides, they are not HIPAA requirements. These non-HIPAA trading partner specific requirements must be tested as part of the business-to-business testing. For further information on business-to-business testing and for further information on testing trading partner rules that are not contained in the Implementation Guides, please see the Business-To-Business Testing White Paper developed by this sub-workgroup.