What is Healthcare EDI Validation? And How to Get Started.
SNIP Validation ensures healthcare EDI documents, such as an X12 HIPAA 834 Benefit Enrollment or an X12 HIPAA 837 Healthcare Claim, are correctly formatted to adhere to the schemas defined in the X12 HIPAA EDI standard.
SNIP Validation uses seven levels, or types — SNIP Type 1 is the least strict and SNIP Type 7 is the most stringent. The types are cumulative, meaning that enforcing SNIP Validation Type 4 also requires enforcing the rules within Types 3, 2, and 1.
Adding SNIP Validation to an EDI processing solution explicitly defines how closely an EDI document (e.g. 835, 270, etc.) must adhere to the schemas defined in the EDI standard. Additionally, higher levels of SNIP Validation can ensure the data contained in the EDI document is valid for use in a sensitive or regulated environment, such as a HIPAA-compliant EDI solution.
SNIP Type 1
SNIP Type 1 validates the basic syntactical integrity of the EDI data in a given document. This includes the requirements that only valid EDI segments appear in the document and that they appear according to the order defined in the EDI schemas.
Type 1 alone does not introduce constraints beyond those imposed by EDI standards, and enforcing these constraints is necessary for successful parsing of the EDI data. Any EDI processing solution, including ArcESB, should support SNIP Type 1 by default.
SNIP Type 2
SNIP Type 2 validates the number of times EDI segments, elements, and qualifiers appear in the document. This includes ensuring that required segments/elements are present, and also that the repeat counts for repeated segments falls within the allowed range.
Type 2, like Type 1, enforces rules defined in the EDI document schemas, but these rules are not necessarily integral to parsing the EDI data. A lenient EDI processing solution might therefore not enforce Type 2 validation by default.
In every ArcESB EDI connector, we include a settings tab for SNIP Validation. Simply enable the SNIP Validation setting in the EDI connector to ensure both Type 2 and Type 3 SNIP Validation.
SNIP Type 3
SNIP Type 3 validates that the sum of each claim line item is equal to the total claim amount. Type 3 is where SNIP Validation progresses from simply validating the structure of the EDI segments against the EDI document schemas to validating the data content within these segments. Ensuring the claim total is correct helps prevent problematic financial discrepancies.
Type 3 is not likely to be supported by EDI processing solutions that do not specifically implement SNIP Validation for the purposes of processing EDI documents subject to HIPAA.
SNIP Type 4
SNIP Type 4 validates inter-segment value relationships: if element A has the value ‘X,' then element B must have the value ‘Y' or ‘Z'. Type 4 validation ensures the data within the EDI document is not only valid according to the EDI schema, but also valid with respect to other values within the same document.
Type 4, like Type 3, requires healthcare-specific data validation that is not likely to be supported in general EDI processing solutions. Additionally, the specific codes and if-then relationships involved in Type 4 validation may differ from document to document and implementation to implementation.
To handle SNIP Type 4 validation, ArcESB provides a dedicated Validate Connector, which can be configured to implement Type 4 logic. Correctly implementing this logic in the Validate Connector requires you to have some understanding of the EDI data involved, but the ArcESB support team is always here to assist with configuration of the Validate Connector.
SNIP Type 5
SNIP Type 5 validates specific code sets for values within the range accepted by HIPAA. Some EDI fields contain a code value, and only a certain set of codes are valid under HIPAA standards. SNIP Type 5 ensures that code-fields contain a code recognized by these standards.
Examples of HIPAA standards that define an accepted set of codes include:
- NDC (National Drug Code) codes
- ICD (International Statistical Classification of Diseases and Related Health Problems) codes
- CPT (Current Procedural Terminology) codes
Type 5 validation requires cross-referencing EDI data with external resources, and thus implementation requires both a knowledge of these external resources and additional configuration to provide these resources to an EDI processing solution.
ArcESB supports Type 5, 6, 7 validation through the Script Connector, which allows you to flexibly and powerfully extend ArcESB.
SNIP Type 6
SNIP Type 6 validates that differences in healthcare services are taken into account when creating claims data records. For example, EDI segments (records) may have different requirements if an EDI document relates to a chiropractic service, rather than a psychiatric service. Type 6 validation ensures the structure of EDI data matches the service for which the EDI document is intended.
Type 6 validation involves more specific data value validation and will require additional work to implement these validation rules in an EDI processing solution.
SNIP Type 7
SNIP Type 7 validates special requirements for certain EDI trading partners:
- Medicare
- Medicaid
- Indian Health
SNIP Type 7 rules are provided in implementation guides offered by these specific trading partners and are not relevant when exchanging EDI documents with other partners, such as private insurers.
ArcESB: Powerful Healthcare EDI Solution
ArcESB comes with complete capabilities for SNIP validation and healthcare EDI. It comprehensively supports the X12 (HIPAA) standard, X12 schemas, and HIPAA EDI documents, as well as every other major EDI standard. With built-in EDI validation inside each EDI connector for Type 2 & Type 3, a dedicated Validate Connector for Type 4, and extensible, intuitive scripting through the Script Connector, ArcESB supports SNIP Validation for every healthcare scenario. In addition, ArcESB is the industry's most trusted, Drummond-Certified AS2 solution for B2B/EDI partner file exchanges.
Download a 30-day free trial of ArcESB to get started today.