Supports highly customized validation scenarios
SNIP Levels ( 1-7 ) Support
Type 1: EDI Standards Integrity Testing
- Valid Segments
- Valid element data types
- X12 element syntax
- Semantic Rules
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
- Repeat counts of segments and loops
- Used/Not Used, Recommended/Not Recommended segments/elements
- Valid code values
- Intra-segment testing
- HL parent/child relationships
- 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
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.
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 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: HIPAA Implementation Guide Requirement Testing
- Balance fields testing
- 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
- 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 = if (SegPos[26:2] == "18") then Usage[OPTIONAL] else Usage[NOTUSED] end
+SegPos = if (SegPos[26:2] == "18") then Usage[REQUIRED] else Usage[OPTIONAL] end
+SegPos = if (SegPos[26:2] == "18") then Usage[REQUIRED] else Usage[NOTUSED] end
+SegPos = if ((SegPos[140:1] == "R") or (SegPos[140:1] == "S")) then Usage[REQUIRED] else Usage[OPTIONAL] end
+SegPos = if (SegPos[26:2] != "18") then Usage[REQUIRED] else Usage[NOTUSED] end
+SegPos = 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 very simple:
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
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
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 HIPAA EDI data with an API
After validation HIPAA 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.
// Create an instance of the EDIValidator object
EDIValidator validator = new EDIValidator();
validator.AutoDetectDelimiters = true;
// Set the type of EDI file that you are about the validate
validator.EDIFileType = FileType.X12; //Or FileType.EDIFACT
// Set the source of EDI data, whether you are validating from an in-memory string or a file
validator.EDISource = EDISource.File; // Or EDISource.DataString
// Set the EDI rules file
validator.EDIRulesFile = "C:\\EDIFile.Rules";
// Set the EDI file to validate
validator.EDIFile = "C:\\EDIFile.txt";
// Check if the EDI file passed
//Get the EDI file just parsed
EDILightWeightDocument file = validator.EDILightWeightDocument;
// Display all errors
foreach (EDIError error in ediValidator.Errors)
Console.WriteLine(error.LineNumber.ToString() + " " + error.Loop + " " + error.Segment + " " + error.Message.ToString());