EDI Validator

SNIP Validation Levels ( 1-7 ) Support

Type 1: EDI Standards Integrity Testing

1. Valid Segments
2. Valid element data types
3. X12 element syntax
4. Semantic Rules

Data Formats

Element data formats can be specified.  If an element’s value is not in the correct format EDIValidator will output a warning.  This can be used for validating correct dates, times, phone numbers, social security numbers, EIN numbers, countries, codes, IDs, or any related format. EDIValidator goes one step further and validates the format of a data element based on the value of other data elements.  This is used in 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

1. Repeat counts of segments and loops
2. Used/Not Used, Recommended/Not Recommended segments/elements
3. Valid code values
4. Intra-segment testing
5. HL parent/child relationships
6. HL, LX, ENT sequences

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 document match data in the footers segments.  EDIValidator checks that transaction data is consistent. 

Type 3: Implementation Guide Requirement Testing

1. Balance fields testing
2. 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 documents 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

1. 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.

RDPScript Language

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

Creating validation rules is simple

Type 5: External Code Set Testing

1. Ability to test for code values.  For example, ICD, CPT, Zip Codes, States, 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

1.  Ensures that the segments (records) of data that differ based on certain healthcare services are properly created and processed into claims data formats

Type 7: Trading Partner Specific Testing

1. 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

EDI Data is loaded after validation

EDIValidator loads all EDI data into an EDI document after validation.  The document can be used to display or consume data

Access EDI data with an API

After validation EDI data can be accessed like an API with methods like GetLoop(‘loopname’), GetSegment(‘SEG’), GetLastLoop(), GetLoopCollection(“LoopName”) and GetSegmentCollection(‘REF’). The EDI data is in an tree-like hierarchy structure