SNIP 4 EDI
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.
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.
The first category of situational rules specifies that sending the specified data item is up to the sender when the condition evaluates to false. For example, in an 837 Professional claim the 2420F service line should specify the referring provider when that physician is distinct from the provider listed in the 2310A claim level loop. From the TR3:
Required when this service line involves a referral and the referring provider differs from that reported at the claim level (loop 2310A). If not required by this implementation guide, may be provided at the sender’s discretion, but cannot be required by the receiver.
The blue text lists the rule condition. The black text indicates whether to send a value if the rule evaluates to false (in this case, the sender can choose to send or not send the data item).
An example of the second category is the PRV segment in the Billing Provider 2000A loop in the 837 Professional transaction. The TR3 guide states that PRV is conditionally required when:
Required when the payer’s adjudication is known to be impacted by the provider taxonomy code.
If not required by this implementation guide, do not send.
In this example, the blue text represents the situational rule statement. The black text indicates whether to send a value if the rule evaluates to false (in this case, do not send).
The categories differ only in terms of compliance when the rule condition is not met.
There are four possible outcomes when testing these situational rules:
- The rule evaluated to true, and the specified item was sent in the message. In both situational categories, the element must be present to comply with SNIP 4.
- The rule evaluated to true, but the specified item was not sent. Conversely, if a situational rule evaluates to true but the related item is not present in the message, this should trigger a SNIP 4 failure. This holds true for both categories of situational rules.
- The rule evaluated to false, and the specified item was sent. This is where the two categories of situational rules diverge. In the first category, inclusion of the loop, segment or element is left to the discretion of the sender when the rule evaluates to false. Therefore, the presence of an item in a transaction set, despite the failure of the rule, should not be considered a violation of SNIP 4. The second category has the opposite requirement – when the situational rule evaluates to false, the item must not be present, otherwise a SNIP 4 violation should be triggered.
- In the final possible case, the rule evaluates to false and the item is not sent. This should be considered valid for both categories of SNIP 4 situational rules.
Validation with T-Connect
The T-Connect EDI Gateway allows administrators to enable and disable SNIP 4 rules on an individual basis. Rules may be enabled globally, or based on transaction type or trading partner.
Visit Caliber Health’s EDI software comparison page to pinpoint the best solution to meet your healthcare data management needs.