HIPAA EDI Development Suite

EDI Validator

Tired of having EDI files rejected?  Need to add custom validation rules for your line of business?

If you are creating EDI files then the EDI Validation component alone is worth the price of the package

Validate EDI data.  Works hand-in-hand with  EDI Rules File and the EDI Rules Formats for superior validation



Main Features

  • Supports HIPAA 4010 and 5010 validation rules
  • Supports all 7 Snip Validation Levels
  • Use .Net to Validate EDI with Code Conditions
  • Displays the exact line of errors and warnings
  • Validates loop, segment and element usage
  • Supports custom, internal and external code lists like CPT, ICD, NDC, CAS, zip codes, states, countries, etc. for superior validation
  • Validates element length and data type constraints
  • Validates element relationship constraints
  • Use regular expressions for superior validation
  • Handles Repeating Elements and Composite Elements
  • Access loaded EDI data after validation
  • Use EDI Rules Creator Studio to create custom validation rules

Related Tutorials

Supports highly customized validation scenarios

Use .Net to Validate EDI with Code Conditions

SNIP 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

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

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

Type 3: HIPAA 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 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

  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


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 very simple:


Type 5: External Code Set Testing

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

  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.  In a matter of minutes data can be extracted and displayed


// 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";

// Validate

// Check if the EDI file passed
if (validator.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());

Take Charge Of HIPAA

RDPCrystal EDI Library