SNIP Levels ( 1-7 )
Sample output from the EDIValidator
Type 1: EDI Standards Integrity Testing
- Valid Segments – Are segment names valid for the specific type of message. Are element and composite elements created correctly
- Valid element data types – Are data elements of the right type. For example, string, number, date, time, Id
- X12 element syntax – Are you using the proper delimiter characters. For example, the element, segment and composite element character
- Semantic Rules- Are elements used properly. Maybe some elements are not required when other elements are present
Data Formats
The format of any element can be specified. If the value in an element is not in the correct format EDIValidator will warn. This can be used for validating correct dates, times, phone numbers, social security numbers, EIN numbers, countries, codes, IDs, or any format you choose. EDIValidator goes one step further and validates the format of a data element based on the value of another data element. This is for situations where the format of an element changes based on the value of another element in the same segment.
Custom data types can also be created using regular expressions
Minimum and Maximum Data Lengths
Violation of the minimum or maximum length of an element can cause EDI files to be rejected. EDIValidator automatically warns of this.
Type 2: Implementation Guide Requirement Testing
- Repeat counts of segments and loops – Do segment or loops repeat the minimum amount of times or do they exceed that
- Used/Not Used, Recommended/Not Recommended segments/elements – Are segments used/not used when they are supposed to be
- Valid code values – Do data elements have the right values, or Ids?
- Intra-Segment testing – See the ‘Self Rules’ section below
- HL parent/child relationships – Are parent/child hierarchy levels created properly. For example the HL segments in the 837 Professional nested properly
- HL, LX, ENT sequences – LX segments, for example, when used in loop 2400 in 837 Professional must have an increasing number starting from 1. For example
LX*1~SV1*HC:97530*174*UN*3***1:2~DTP*472*D8*20120327~REF*6R*1681465~LX*2~SV1*HC:87070*15*UN*1***1~DTP*472*D8*20061003~LX*3~SV1*HC:99214*35*UN*1***2~DTP*472*D8*20061010~LX*4~If an element has an incorrect value, EDIValidator will show the location of the error and what the accepted value or values should be.
Inter-Segment Rules (Self Rules)
Segment data element relationship requirements are an extremely useful feature of the EDIValidator. However they enforce element usage regardless of element values. With segment Self Rules the usage of elements in a segment can be governed by the value of an element in the same segment.
EDIValidator checks for Self Rules. An example of a Self Rule is the NM1 segments in the X12 EDI format. Certain elements are required when the entity is a person and certain elements are required when the entity is a company while other elements are not used. There can be a Self Rule stating that if the value of data element 2 has a value of 1 (Person) then element 3 is required while elements 4 and 5 are not used.
Element Relationship Constraints Supported
-Element Pairs
If a certain element is used then all elements in a specified group are required.
Example: P060708. If any of the elements 06, 07, or 08 are present, then all are required.
-Required Data Element Pairs
At least one of the elements in a specified group is required.
Example: R0708R0910. At least one of element 07 and 08 is required, and at least one of
09 and 10 is required.
-Conditional Data Element Pairs
If a certain element(s) is used then another specified element(s) is required.
Example: C0102. If element 1 is present then element 2 is required
-List Conditional Pairs
If a certain element is used then at least one element from a specified group is required.
Example: L060810. If element 06 is present, then at least one of 08 or 10 is required.
-Exclusion Data Element Pairs
Only one element in a specified group of elements can be used.
Example: E060810. Only one of 06, 08, or 10 may be present.
Developers can configure which relationship applies to which segment and a segment can have more than one relationship (relationships can be chained).
Segments can have more any number of relationship constraints.
Line Counters
When a loop occurs more than once there is usually a segment in the loop that contain an element whose value must be equal to the current repetition count. These elements are usually used for line counters. An example of a line counter segment is the LX segment in the 837 health care claims transaction set. EDIValidator makes sure the the line counters elements contain the correct values. If not it will display what the value should be
Equality Elements
Equality Elements are used to make sure that data in the header segments of an EDI file match data in the footers segments. EDIValidator checks that transaction data is consistent.
Type 3: HIPAA Implementation Guide Requirement Testing
- Balance fields testing – Do service level amounts add up to claim level amounts as in the 837 Professional CLM segment
- Balancing for summary fields
Summary fields are elements that contain the sum of other elements’ values. This is a great feature if you are checking EDI files that deal with finance. EDIValidator will check if the sum values are correct. If it is not EDIValidator display what the values should be.
Type 4: Inter-Segment Situation Testing
- For example, if segment 1 is present then segment 2 is required
Create complex validation rules. Change the usage of segments based on the existence of other segments and the values of elements in other segments. Change the accepted values of given element based on the existence of previous segments or values of other elements. EDIValidator will also warn when a loop, segment or element is used when it should not be. It also checks if the item’s usage is dependent on the usage of other loops, segments, or elements. Conditional loops, segments, and data elements are also checked.
EDI rules are a very powerful feature of the EDIValidator. Rules can be used in the following way, for example:
- If segment 23 element 2’s value is NOT EQUAL to 18 then segment 149 element 2 usage is REQUIRED else NOT USED
- If segment 23 element 2’s value is EQUAL to 18 or 19 then segment 149 element 2 accepted values are 2,3,4,5,6 else the default accepted values are 7,8,9,10
Condition operators include: EXISTS, NOT EXISTS, LESS THAN, LESS THAN OR EQUAL TO, GREATER THAN, GREATER THAN OR EQUAL TO, EQUAL TO.
Example 1 -General Rules
+SegPos[27] = if (SegPos[26:2] == "18") then Usage[OPTIONAL] else Usage[NOTUSED] end
+SegPos[31] = if (SegPos[26:2] == "18") then Usage[REQUIRED] else Usage[OPTIONAL] end
+SegPos[40] = if (SegPos[26:2] == "18") then Usage[REQUIRED] else Usage[NOTUSED] end
+SegPos[146] = if ((SegPos[140:1] == "R") or (SegPos[140:1] == "S")) then Usage[REQUIRED] else Usage[OPTIONAL] end
+SegPos[207] = if (SegPos[26:2] != "18") then Usage[REQUIRED] else Usage[NOTUSED] end
+SegPos[322] = if ((SegPos[316:1] == "R") or (SegPos[316:1] == "S")) then Usage[REQUIRED] else Usage[OPTIONAL] end
Example 2 – Create your own errors based on rules
+SegPos[135:5] = if (SegPos[135:5] == SegPos[40:5:1]) then Error[ElementHasWrongValue,"SV105 must be different from 2300 CLM05-01"] end
+SegPos[104:9] = if ((SegPos[26:9] != "") and (SegPos[104:9] != "")) then Error[ElementHasWrongValue,"SBR09 is used It should not be used after National PlanID is mandated"] end
Type 5: External Code Set Testing
- Ability to test for HIPAA code values. For example, ICD, CPT, Zip Codes, etc
The power of the EDIValidator extends into the file system. Element values can be checked against zip codes, states, CPT code (Healthcare), ICD codes (Healthcare), NDC codes (Healthcare), CAS code, any list at all. Codes lists can be in the same file as the EDI rules or exist separately. Custom code lists can also be created.
Type 6: Product Type and Type of Service Testing
- Ensures that the segments (records) of data that differ based on certain healthcare services are properly created and processed into claims data formats
This falls under the category of custom rules that can be added to the EDIValidator. For example
Type 7: Trading Partner Specific Testing
- 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, Type 7 testing is required
Well that’s what SNIP is all about. Just making sure that your system create HIPAA files correctly and check for specific conditions. Now go out there and spread the news!
Take Charge Of EDI
