Tallan's Blog

Tallan’s Experts Share Their Knowledge on Technology, Trends and Solutions to Business Challenges

Posts Tagged "SNIP"

SNIP 6 – Line of Service or Product

What are HIPAA SNIP types? We get this question a lot, so we’ve been blogging about the different categories WEDI has defined to validate healthcare EDI transactions. Thus far, we’ve covered:

SNIP 1 & 2 Integrity and Requirement Testing
SNIP 3 Claim Balancing
SNIP 3 Remittance Advice Balancing
SNIP 4 Intersegment Situational Testing
SNIP 5 External Code Set Testing

These rules are sometimes referred to as SNIP levels – although that may wrongly imply that each type builds upon the previous category. In actuality, each SNIP type is a standalone set of validations rules.
In this article, we’ll focus on SNIP 6.
Type 6
SNIP 6 enforces situational rules specific to service lines and products. While SNIP 4 also focuses on situational rules that analyze the relationships between loops, segments and elements, SNIP 6 differs in that the rules apply to subsets within the transaction sets.
For example, within an 837…

SNIP 4 – EDI Intersegment Situational Rules

WEDI SNIP Types define sets of rules for validating EDI transactions such as 837 claims, 834 enrollments or 835 Remittance Advice.
Previously, we’ve blogged about:

SNIP 1 & 2 Integrity and Requirement Testing
SNIP 3 Claim Balancing
SNIP 3 Remittance Advice Balancing
SNIP 5 External Code Set Testing

This article focus on SNIP 4, which test situational rules spanning separate loops, segments, or elements. What differentiates these rules from Type 2 is that the situational tests span distinct segments, while Type 2 is considered intrasegment testing. Intrasegment tests validate the presence of elements within the same segment based on syntax rules.
Type 4
SNIP 4 situational rules break into two categories. Both categories consist of a condition statement, then a data item (loop, segment, or element) which should (or should not) be present based on the rule evaluation.
Category 1
The first category of situational rules specifies that sending the specified data item is up…

SNIP 5 – HIPAA External Code Set Testing

The HIPAA X12 EDI specification allows for the inclusion of code values that may be pertinent to the transaction set, such as a claim or encounter. These code values can represent a data point as widespread as a postal or zip code, or as complex as diagnosis and procedure codes.
WEDI describes seven types of validation, referred to as SNIP 1-7, as covered in some of our previous blog posts on SNIP 3 Balancing of Claims and Payments. SNIP 5 – HIPAA External Code Set Testing is the validation of code values against the external code sets they represent.
SNIP 5
As previously stated, SNIP 5 validates that code value exists within an external code list. For example, if a postal (zip) code is present in a subscriber’s address, then it should align with an actual postal code in as determined by the USPS, the…

Claim Balancing – SNIP 3 for 837s and Post-Adjudicated Encounters

Ensuring that 837 EDI transactions meet validity checks is critical to improving auto-adjudication and encounter submission acceptance rates. SNIP Type 3 describes the rules for balancing header and detail levels of the Claim, Premium Payment and Remittance Advice transaction sets. Previously, our blog covered the logic required to balance 835 transactions. Now we’ll look at the steps necessary to balance claims with service lines, including Coordination of Benefits loops in multiple payer scenarios.
Claims and encounters may be represented by a variety of X12 transaction types: 837 Professional, Institutional and Dental, as well as their corresponding post-adjudicated variants (298, 299, 300), intended for submission to All-Payer Claims Databases. The following logic applies to all versions of the 837 equally, with a few caveats noted below.
Rule 1 – Balancing Claim Charge Amounts
The first claim balancing rule is straightforward: given the parent-child relationship of 2300 claim loops to their 2400 service…

Edit and Resubmit X12 HIPAA EDI with the T-Connect Management Suite

An EDI software’s ability to identify and respond to invalid X12 HIPAA EDI transactions is a major contributor to the effectiveness of EDI dependent organizations. Many healthcare companies appoint a business unit as stewards of the tens of thousands of transactions that are transmitted between payers, providers, and trading partners providing auxiliary services. These business units are often hard-pressed to respond to the quantity of incorrect claims, enrollments and payments received within their current EDI solutions or products.
The T-Connect EDI Management Suite is Tallan’s healthcare EDI product, providing actionable insight, alerting, and painless mechanisms to respond to invalid X12 EDI transactions flowing in and out of the organization. The following is a brief introduction into some of these capabilities.
The EDI solution consists of several components working in unison to introduce, augment or replace an EDI processing system.
· The T-Connect Management Portal,…

SNIP 3 835 Balancing

835 and 837 EDI transactions have transformed the adjudication cycle for providers and health plans over the last two decades, but challenges remain in reconciling payments with claims. Recently, we’ve broken down the requirements for SNIP 3 claim balancing. Today we’ll focus on the 835 Claim Payment/Remittance Advice. Health plans submit 835s to providers (or their intermediaries) to explain which claims are being paid, and any reductions to the submitted amount and the reasoning for the adjustment. This is an important function – a significant pain point experienced by providers is the reconciliation of their income against claims submitted.
Before this valuable information can be loaded in practice management software, the 835 should pass validation checks. Common issues affecting 835s are balancing errors between the header and detail payment amounts. Imbalanced 835s lower the quality of reporting and can lead to billing…

\\\