HIPAA EDI Development Suite

EDI Document

Want to create EDI files correctly all the time?

The EDI Library helps by allowing the developer to forget about all the small details of EDI

From the simplest to the most complex, EDIDocument helps you create well-formed EDI files the first time.


Main Features

  • Create any ANSI X12 compliant EDI document
  • Easily create loops, segments, elements, composite and repeating elements
  • Automatically inserts delimiter characters at the appropriate places
  • (Smart Feature) Pads or trims element data to meet minimum and maximum length requirements
  • (Smart Feature) Automatically removes empty trailing data from elements and composite elements
  • (Smart Feature) Automatically keeps track of segment, ST and GS counts and inserts them into the SE, GE and IEA segments
  • Generates easy to read and understand EDI documents
  • Easily convert to XML

Related Tutorials


X12 EDI File Structure

The ANSI X12 standards dictates the structure of X12 EDI files.  The general EDI file structure contains loops, segments, elements and composite elements.  Loops contain segments, a segment contains elements and elements may contain other elements (composite elements).  An example EDI file structure is:


EDIDocument mirrors this parent-child model when creating or loading EDI data.  EDIDocument contain Loop objects which in turn contain DataSegment objects which in turn can contain DataElement objects and so on.  When generating files EDIDocument navigates this parent-child hierarchy and visits each node in order to retrieve their data.

X12 EDI Segment Structure


EDIDocument uses the same terminology described in the implementation guides.  This makes creating EDI files easier.  For example, EDIDocument uses object names like DataSegment, DataElement, Loops, SegmentTerminatorCharacters etc.

Smart Feature: Padding and Trimming

All  EDI elements have a minimum and maximum length.  Violation of this constraint can lead to errors especially in fixed length segments like ISA.  EDI specifications require that both data element and composite data element values stay between a minimum and maximum length.  Failure to adhere to this length constraint may result in an EDI file failing validation and being rejected.  If this is time sensitive data, then the sender may have to regenerate the EDI file and resend it to the receiver wasting considerable time.

EDIDocument has to ability to pad or trim element data to reach minimum and maximum element length requirements.  While generating EDI files, EDIDocument visits each node (both data element and composite data element) and checks the data to verify that they are within the minimum and maximum lengths.  If the data element adheres to these length constraints they are left alone.  On the other hand, if they violate the length constraints, EDIDocument will either pad or trim the element in order the satisfy the constraints.

Smart Feature: Truncation of Empty Elements

While developing EDI files certain elements may be missing or not available.  In this case there is no data to be entered in those elements.  Because each element must be delimited by the Element Terminator Character we will  have a series of empty element values delimited by Element Terminator Characters and then followed by a Segment Terminator Character. For example, if the Element Terminator Character is ‘*’ and the Segment Terminator Character is ‘~’ then we will have the following segment:

Figure 1.

EDIDocument has the ability to locate and remove these empty elements.  One immediate benefit of this is smaller EDI files.  Another benefit is that parsers need not load empty data into memory for loading and validation, wasting valuable processor time.  The property that governs this behavior is TruncateEmptyElements property.  After removal the segment will look like the following:

Figure 2.

Empty element values in the middle of segments are not touched.


EDI files contains a list of segments.  Each segment is delimited by a special character called a Segment Terminator Character.  Segments also contain elements.  Each element is delimited by a special character called an Element Terminator Character. Some elements may contain other elements as well.  These sub-elements are called composite elements.  Composite elements are also delimited  by a special character called a Composite Terminator Character.   Every EDI file contains these special characters that are used to separate data into logical units.


Delimiters are set once and EDIDocument inserts them in their correctly places.  By knowing what these special characters are EDIDocument can correctly create, validate and load EDI files.

EDIDocument can also auto detect delimiters in EDI files

Auto Placement of Number of Segments, Transactions and Functional Headers

One of the bodies that govern some of the EDI specifications is ANSI X12.   These EDI files contain a segment, SE, used to specify the end of a header.  According to the rules,  this segment must contain the total amount of segments used within that specific header.  EDIDocument will automatically keep a count of the number of segments used in the header and goes as far as to actually enter that data in the SE segment.  This feature can also be turned off in cases where developers want to put other data in the SE segment. The property used to toggle this setting is AutoPlaceCorrectNumOfSegments. Additionally the number of ST transactions and GS Functional Groups are also tracked and added to the GE and IEA segments

Segment Separator String

EDI data can become cumbersome to look at visually.  Some parsers may place a return character or a carriage return character so data can be more readable and appear on different lines.  This is perfectly acceptable in the industry.  Aside from placing a Segment Terminator Character at the end of each segment, an extra piece of formatting text can also be placed.  This extra piece of formatting text is called the Segment Separator String.  Developers who use this property can add their own formatting to their EDI files.

Truncation of  Empty Composite Elements for Smaller Files and Faster Processing

As with regular elements certain composite elements may be missing or not available.   Because each composite element must be delimited by the Composite Element Terminator Character, if there is no data in one or more composite data element there will be a series of Composite Element Terminator Characters followed by an Element Terminator Character. For example, if the Element Terminator Character is ‘*’ and the Segment Terminator Character is ‘~’ and the Composite Element Terminator is ‘:’ then we will have the following segment:

Figure 3.

EDIDocument has the ability to locate and remove these empty composite elements.  One immediate benefit of this is smaller EDI files.  Another is the EDI files will not get rejected.  The property that governs this is TruncateEmptyCompositeElements property.  After removal the segment will look like the following:

Figure 4.

Empty composite element values in the middle of segments are not touched.

Graphical Generation of EDI Tree Structure With Data

After generating a new EDI file, EDIDocument has the ability to generate a graphical tree representation of the entire EDI file.  The graphical tree contains the entire EDI file schema as well as element data.  Users can click on the nodes to view and drill down into its contents.  An example of the hierarchical tree is:


EDI File Generation Directly To Memory

The EDI file generation process often ends with an EDI file being generated on the file system.  It can then be retrieved and sent to an EDI receiver.  This process, straight forward as it may seem, requires data to first be written to the file system only to be read in again.  This simple delay can add up considerably when generating hundreds or even thousands of EDI files.

EDI Document has to ability to generate an EDI file directly into memory.  This is a one step process that avoids writing and reading to and from the file system.  The newly created EDI data in memory can then be used immediately.

File Buffer Size and Performance

EDIDocument uses an internal buffer to enable it to quickly create EDI files.  It does not put a limit on the size of EDI files that can be created.  A limit is imposed by the environment.  The limit is approximately 2 billion characters. This length is more space than is required for any EDI file.  Because EDI files can be very large, generating EDI files can consume a lot of memory and effect performance.  Speed improvement is attained by specifying an approximate length of the EDI file being created in terms of the amount of characters.  The internal buffers will not need to recreate itself with more space if this limit has not been reached.  By default the file buffer size is set to 2000 characters.  This limit should be change while generating an EDI file larger than 2000 characters (which is most likely the case).

XML File Generation

EDI data can be converted to XML.  Applications can be written to parse the XML EDI data in any fashion imaginable. An example of the XML generated is displayed below.  The names of the loop, segment, and element tags can also be customized for smaller XML files.

Figure 7.


// Instantiate an instance of EDIDocument and set the name of the file to be created
EDIDocument sampleEDIFile = new EDIDocument("C:\\My837EDIFile.txt");

// Place the correct counts of segment, headers and functional groups
sampleEDIFile.AutoPlaceCorrectNumOfSegments = true;
sampleEDIFile.AutoPlaceCorrectNumOfST = true;
sampleEDIFile.AutoPlaceCorrectNumOfGT = true;

// Create an interchange loop. This loop will contain all other loops in the EDI structure
Loop interchangeHeaderLoop = new Loop("Interchange Header");

// Create an ISA segment in the interchange loop
DataSegment isa = interchangeHeaderLoop.CreateSegment("ISA");

// Add elements with data to the ISA segment

// Now create the function header loop
Loop functionalHeaderLoop = interchangeHeaderLoop.CreateLoop("Functional Header Loop");

// Add a GS segment to it
DataSegment gs = functionalHeaderLoop.CreateSegment("GS");

// Set its elements and their values

// Create a transaction header loop
Loop transactionLoop = functionalHeaderLoop.CreateLoop("Transaction Header");

// Add an ST segment to the transaction header loop
DataSegment st =transactionLoop.CreateSegment("ST");

// Set its elements and their values

// Add an ST segment to the transaction header loop
DataSegment bht = transactionLoop.CreateSegment("BHT");

// Create the end of the transaction (SE segment). This must be done in a loop.
Loop endOfTransactionLoop = transactionLoop.CreateLoop("End Of Transaction");
DataSegment se = endOfTransactionLoop.CreateSegment("SE");
se.Elements.Add(DataSegment.NumberCreated.ToString(), "Segment Count");

// Create the end of the functional group (GE segment). This must be done in a loop.
Loop endOfFunctionalGroupLoop = functionalHeaderLoop.CreateLoop("End Functional Group");
DataSegment ge = endOfFunctionalGroupLoop.CreateSegment("GE");

// Finally create the end of the interchange loop (IEA segment). This must be done in a loop.
Loop endInterchangeLoop = interchangeHeaderLoop.CreateLoop("End Interchange");
DataSegment iea = endInterchangeLoop.CreateSegment("IEA");

// Add the interchange loop to the EDI document

// Generate the EDI file

Take Charge Of HIPAA

RDPCrystal EDI Library