See also:

• SQL Server as a Staging Environment
• SqlTransactionRepository Class
• Sql Server Functions and Views

Database Schema

You can import your X12 into a SQL Server database by using the OopFactoryX12.ImportX12 console app. This will create the following schema in the database once you have loaded a file:

Table Purpose:

• Container: keeps all Int or BigInt identities for the Interchange, FunctionalGroup, TransactionSet and Loop tables.
• Revision - allows for edits of the X12 and keeping track of comments related to those edits.  A record of 0 is added by default to represent the initial load of all X12.
• Interchange, FunctionalGroup, TransactionSet, Loop, Segment - this is the database realization of the Interchange model into a relational model.  All segments are shown as they were in the x12 message in the Segment column of the Segment table.
• N1, ... - these are the indexed segment tables specified in the IndexedSegment configuration values.  It uses the X12 specification for each segment to define the table.  Because of this, there is the potential that something in the segment was not parsable.  It may either get truncated or was not parsable to the segment specification's data type.  These are errors in the X12, but this will be noted in the log file of the ImportX12 app.  The original segment will always remain as a string in the Segment column of the Segment table.

ImportX12 Configuration

The application has the following application settings.  Just point the connection string to an empty database and all the tables, views and user-defined functions will be created on-the-fly when you import a file.

• schema - schema of the Interchange, FunctionalGroup, TransactionSet, Loop, Segment tables and any indexed segment tables.  If you are using a schema other than "dbo" make sure that you create it first in your target database.  The ImportX12 app will create tables, but will expect the schema to already exist.
• containerSchema - schema of the common tables: Container and Revision
• ThrowExceptionOnSyntaxErrors - indicates whether an exception should be thrown on.  When the value is false an warning will be sent through the ParsingWarning event instead.
  
  • Hierarchical Parent Id references that don't exist, if false, than the HL will be treated as a top level HL without a parent
  • Segments that don't occur in the transaction set's specification, if false, the segment will parsed as a segment of the current loop where it was found.
• IndexedSegments - a comma delimited list of X23 segment IDs that you would like to have as individual tables.  The specification of that segment ID will be used to determine how many element columns to create and of which data type. For example, if you are parsing 837 health claims you would use the list "AMT,BHT,CAS,CL1,CLM,CN1,CR1,CR2,CR3,CR4,CR5,CR6,CR7,CR8,CRC,CTP,CUR,DMG,DN1,DN2,DSB,DTP,FRM,HCP,HI,HL,HSD,III,IMM,K3,LIN,LQ,LUI,LX,MEA,MIA,MOA,N2,N3,N4,NM1,NTE,OI,PAT,PER,PRV,PS1,PWK,QTY,RAS,REF,SBR,SV1,SV2,SV3,SV4,SV5,SV6,SV7,SVD,TOO,UR". See Transaction Set Configuration for a full list.
• ParseDirectory - the directory to search for X12 files
• ParseSearchPattern - the file search pattern to filter files for parsing with the ParseDirectory
• ArchiveDirectory - the directory to move each file the parses and imports successfully.
• FailureDirectory - the directory to move any file that fails to parse or load.  If the Interchange record was written, the HasErrors column will be set to true on failed files.

Schema Configuration

The application allows you to configure the containerSchema separately from the schema so that you can choose to partition your x12.  This can be useful in the following scenarios:

1. You want each client's data in a separate schema so their data will never co-mingle and each client does not suffer performance issues because another client has a large amount of records.
2. You want to separate your X12 into inbound and outbound messages.
3. You want to set separate security on different schemas for different users in your environment so they only access what they need to know, since most X12 contains Personally Identifiable Information.

They system is designed as an INSERT ONLY transactional database.  Updates and Deletes are handled by adding revisions.  The built in user-defined functions take this into account and only show the latest revision of each segment.

Revision Feature

In most cases you won't be doing any revisions, especially if the X12 messages represent TRUE EDI messages that came to you from a trading partner through a clearinghouse.  Mistakes in the X12 should be handled by acknowledgment files that reject bad transactions.  However, there are other use cases of X12 that are not TRUE EDI.  When the transaction came to you in some other format and you have a data entry system that creates X12 so that you have a common process for integrating all incoming transactions, errors may have been introduced.  In this case errors in your X12 may be your responsibility and you might want a process for creating edits of you X12.  In this case you will be able to use the SaveRevision method of the SqlTransactionRepository to make edits that will produce valid X12 for your downstream processes.

See also:

• SQL Server as a Staging Environment
• SqlTransactionRepository Class
• Sql Server Functions and Views

Database Schema

You can import your X12 into a SQL Server database by using the OopFactoryX12.ImportX12 console app. This will create the following schema in the database once you have loaded a file:

Table Purpose:

• Container: keeps all Int or BigInt identities for the Interchange, FunctionalGroup, TransactionSet and Loop tables.
• Revision - allows for edits of the X12 and keeping track of comments related to those edits.  A record of 0 is added by default to represent the initial load of all X12.
• X12CodeList - This will contain the lookup values for any elements in a segment that has been Indexed into a separate table.
• Interchange, FunctionalGroup, TransactionSet, Loop, Segment - this is the database realization of the Interchange model into a relational model.  All segments are shown as they were in the x12 message in the Segment column of the Segment table.
• NM1, N1, N3 ... - these are the indexed segment tables specified in the IndexedSegment configuration values.  It uses the X12 specification for each segment to define the table.  Because of this, there is the potential that something in the segment was not parsable.  It may either get truncated or was not parsable to the segment specification's data type.  These are errors in the X12, but this will be noted in the log file of the ImportX12 app.  The original segment will always remain as a string in the Segment column of the Segment table.
• ParsingError - because the indexed tables are typed into decimal and datetime when relevant, this table will contain any errors translating the target data type or any errors exceeding the max length of a string element.  The errorId will be recorded in the indexed segment table.   The original Segment table will always contain the original value from the x12 file.

ImportX12 Configuration

The application has the following application settings.  Just point the connection string to an empty database and all the tables, views and user-defined functions will be created on-the-fly when you import a file.

• schema - schema of the Interchange, FunctionalGroup, TransactionSet, Loop, Segment tables and any indexed segment tables.  If you are using a schema other than "dbo" make sure that you create it first in your target database.  The ImportX12 app will create tables, but will expect the schema to already exist.
• containerSchema - schema of the common tables: Container and Revision
• ThrowExceptionOnSyntaxErrors - indicates whether an exception should be thrown on.  When the value is false an warning will be sent through the ParsingWarning event instead.
  
  • Hierarchical Parent Id references that don't exist, if false, than the HL will be treated as a top level HL without a parent
  • Segments that don't occur in the transaction set's specification, if false, the segment will parsed as a segment of the current loop where it was found.
• IndexedSegments - a comma delimited list of X23 segment IDs that you would like to have as individual tables.  The specification of that segment ID will be used to determine how many element columns to create and of which data type. For example, if you are parsing 837 health claims you would use the list "AMT,BHT,CAS,CL1,CLM,CN1,CR1,CR2,CR3,CR4,CR5,CR6,CR7,CR8,CRC,CTP,CUR,DMG,DN1,DN2,DSB,DTP,FRM,HCP,HI,HL,HSD,III,IMM,K3,LIN,LQ,LUI,LX,MEA,MIA,MOA,N2,N3,N4,NM1,NTE,OI,PAT,PER,PRV,PS1,PWK,QTY,RAS,REF,SBR,SV1,SV2,SV3,SV4,SV5,SV6,SV7,SVD,TOO,UR". See Transaction Set Configuration for a full list.
• ParseDirectory - the directory to search for X12 files
• ParseSearchPattern - the file search pattern to filter files for parsing with the ParseDirectory
• ArchiveDirectory - the directory to move each file the parses and imports successfully.
• FailureDirectory - the directory to move any file that fails to parse or load.  If the Interchange record was written, the HasErrors column will be set to true on failed files.

Schema Configuration

The application allows you to configure the containerSchema separately from the schema so that you can choose to partition your x12.  This can be useful in the following scenarios:

1. You want each client's data in a separate schema so their data will never co-mingle and each client does not suffer performance issues because another client has a large amount of records.
2. You want to separate your X12 into inbound and outbound messages.
3. You want to set separate security on different schemas for different users in your environment so they only access what they need to know, since most X12 contains Personally Identifiable Information.

They system is designed as an INSERT ONLY transactional database.  Updates and Deletes are handled by adding revisions.  The built in user-defined functions take this into account and only show the latest revision of each segment.

Revision Feature

In most cases you won't be doing any revisions, especially if the X12 messages represent TRUE EDI messages that came to you from a trading partner through a clearinghouse.  Mistakes in the X12 should be handled by acknowledgment files that reject bad transactions.  However, there are other use cases of X12 that are not TRUE EDI.  When the transaction came to you in some other format and you have a data entry system that creates X12 so that you have a common process for integrating all incoming transactions, errors may have been introduced.  In this case errors in your X12 may be your responsibility and you might want a process for creating edits of you X12.  In this case you will be able to use the SaveRevision method of the SqlTransactionRepository to make edits that will produce valid X12 for your downstream processes.

The SqlTransactionRepository class can be used for additional control over the import of X12 into a SQL Server database.  In most cases you can use the OopFactory.X12.ImportX12 console app out-of-the-box and will only need to work with the SqlReadOnlyTransactionRepository class.

SqlTransactionRepository Class Diagram

These two classes are split apart because their a quite a number of constructor arguments you need when you are importing data that aren't needed when you are reading data.  If you are not using the Revision feature, all you need outside of the OopFactory.X12.ImportX12 app is to use the SqlReadOnlyTransactionRepository.

These classes have been created as generics so that you choose between using SQL's int, bigint or uniqueidentifier as your table identities, by using the class with int, long or Guid for T.

The Container table will hold the identities for interchanges, function groups, transaction sets and for loops, so it will fill up quick, but will probably still be sufficient to use Int in many cases.

SqlReadOnlyTransactionRepository Methods

GetTransactionSets

GetTransactionSetSegments

GetTransactionSetSegments accepts the following arguments:

• transactionSetID = the Id from the TransactionSet table, this can also be obtained by searching for transactions using the GetTransactionSets method and specifying filter criteria with the RepoTransactionSetSearchCriteria.
• revisionId - the revisionId of the the transaction, use Int32.MaxValue to get the latest revision.
• includeControlSegments - will add the ISA,GS,GE and IEA segments to the segments returned.

It will return a List<RepoSegment<T>> which is shown below:

GetLoops

GetTransactionSegments

A transaction is defined differently for each transaction set.  The SqlTransactionRepository allows you to treat any loop in your transact set as a transaction.

For example, an 837 health care claim would use SpecLoopId = "2300" to define a claim as a transaction.  When you call GetTransactionSegments, it will unbundle the segments related to that transaction (ancestor loops and their related segments, and all child segments).  This is similare to the UnbundleX12 console app.

The data structure returned is a list of RepoSegments with a Segment property.

To rebuild an unbundled X12 message, call GetTransactionSegments with includeControlSegments = true, and concatenate the Segment.SegmentString with Segment.Delimiters.SegmentTerminator for the segments returned.  This will give you a valid X12 message that you can then use existing transformations to work with. See Claim Parser for some claim transformations.

SqlTransactionRepository Methods

Save

The Save methods accepts an Interchange object which is the output of the X12Parser's PareMultiple method.  You can send this directly to the Save method and it will return the Id value from the Interchange table.  If you intend to do any post processing, this Id can be sent to the GetTransactionSets or GetLoops method to identify the newly created elements that you may want to act upon.

Database Creation

When you call the Save method for the first time, the class will check for the expected database tables and automatically and create the necessary table, views and user-defined functions depending on your values for schema, commonSchema, and indexedSegments.  This is useful to get you started right away, but it does this check on every save.

To bypass this, you can create a derived class with no implementation for EnsureSchema.  You can use the default implementation in development to create your database objects, and then turn off EnsureSchema once you've moved to production so that it doesn't incur the extra database hit.

SaveRevision

The SaveRevision methods accepts an IList<RepoSegment<T>> that it expects you got from the GetTransactionSetSegments or GetTransactionSegments methods.

Once you have made the updates to the segments you can send it to the SaveRevision method.  The save revision will insert new database entries for the segments that have actually changed.  Subsequent calls to GetTransactionSetSegments and GetTransactionSegments will only get the latest revision that is less than the RevisionId sent to either of those methods.

Database Concurrency

The SaveRevision method will check concurrency at the segment level.  Before saving a segment change it will make sure that the RevisionID at the time that the RepoSegment was retrieved has not changed.  If it has changed, it will rollback all changes in the revision.  This will cause the Revision table to skip some ID values.

The following table shows the segments used in each X12 transaction. This list can be used to configure which segments to index into tables for SQL Server integration

Out-of-the-Box Usage:

X12Parser is a collection of simple command line console applications for transforming an X12 file.

X12Parser.exe

X12Parser transforms an X12 file into a more domain easily readable xml file.

The 2 arguments to the command line are input filename and output filename.  Only the input filename is required. If the second argument (output filename) is not present, X12Parser will use the input filename and add a ".xml" to create the output filename.

Example:
X12Parser "D:\Test.clm" "D:\Test.xml"

See Parsing an 834 Transaction or Parsing an 837 Transaction to see an example of what the output will resemble and how to write more code to output to html or back to a formatted x12.

UnbundleX12.exe

UnbundleX12 separates an X12 file into multiple valid X12 files at a specified X12 loop ID. When loops are separated their header information (parent loop or segment) is retained. The SE transaction trailer segment and GE function group segment, however, is updated to correctly reflect the number of segments in the transaction and the number of transactions in the function group so the resulting x12 is still valid.

The 5 arguments to the command line are input filename, X12 loop ID, output directory, output filename format and include whitespace. The first 3 arguments are required. If the fourth argument is not present, UnbundleX12 will use the input filename and add a 3 digit incrementing counter to create the output filename.  If the fourth argument is specified it can use the following special tokens:

The fifth argument will toggle on or off the include whitespace option when creating the X12 file.  If not specified it is set to "true". If set to "true", this option adds carriage returns and indentation to the loop structure to make it more human readable. Note that adding whitespace may make the file unreadable with some EDI applications.

3 argument example:

UnbundleX12 "D:\837Test.clm" "2300" "D:\Output"

If the 837 input file had 2 claims in it, then "837Test.clm_001.clm" and "837Test.clm_002.clm" would be created in the D:\Output directory.

4 argument example:

UnbundleX12 "D:\837Test.clm" "2300" "D:\837Unbundle" "{0}\{1}_Output_{2:000}{3}"

If the 837 input file had 2 claims in it, then "837Test.clm_Output_001.clm" and "837Test.clm_Output_002.clm" would be created in the D:\Output directory.

5 argument example:

UnbundleX12 "D:\837Test.clm" "2300" "D:\837Unbundle" "{0}\{1}_Output_{2:000}{3}" "true"

If the 837 input file had 2 claims in it, then "837Test.clm_Output_001.clm" and "837Test.clm_Output_002.clm" would be created in the D:\Output directory formatted with whitespace indentation.

Unbundling Tips:

• To unbundle 837 files into individual claims, use loop ID 2300
• To unbundle 835 files into individual remittance EOBs, use loop ID 2100
• If the resulting X12 file is "unreadable" by an EDI application try turning off the whitespace option (see fifth argument)

For further technical explanation of the unbundle feature, see Unbundling an X12 file by Loop ID.

Usage as development tool:

• The most common use case of this parser is to transform the XML into a flat representation to be pushed into a database or into flat files to be consumed by other applications.  See Creating a flat file or Excel file from the X12 xml using XSLT and XslCompiled Transform to see how to create a flattened version of the x12 transaction.
• Other transaction sets can be parse by creating and injecting your own specification file. SeeInjecting your own X12 Specification.

Supported Transaction Sets:

See a full list of supported transactions here: https://x12parser.codeplex.com/wikipage?title=Transaction%20Set%20Configuration.

To request another transaction set, please add an issue to the issue tracker http://x12parser.codeplex.com/WorkItem/Create.

Other Discussions

• Comparing Open Source EDI Software, prepared by contributornth
• About the X12 Parser

Other Useful Tools

• Deidentifier for removing PII and PHI (http://etasoft.com/ot.htm) especially for creating test files.
• If you are new to EDI this a good place to start: http://www.xtranslator.com/prod/beginguidex12.pdf.  This is a pretty decent product too if you have a few thousand dollars to spare.
• FO Processor for transforming FO-XML into PDF http://fonet.codeplex.com.

This is a temporary post that was not deleted. Please delete this manually. (2699eb23-2039-4185-ac4d-c4593fafe12c - 3bfe001a-32de-4114-a6b4-4005b770f6d7)

X12 Interchange Model

The X12 Parser is designed around a set of objects that get loaded with the help of an X12Parser object. Once loaded, the Interchange object can operate without any further assistance from the X12Parser.

You can use these objects to:

1. Read an existing X12 file without the use of the XML transformations.
2. Load an existing X12 file and make modifications without disturbing any segments that you do not explicit change.
3. Create a new X12 document using a built in or custom transaction specification.

An X12 envelop starts with an Interchange surrounding a set of Function Groups surrounding a set of Transactions.
The transactions can hold individual segments, loops or hierarchical loops. The following domain model represents these objects with the least repetition of their common characteristics.



Let's look at how to use these objects with some code samples to work with the following 270 Eligibility Inquiry x12:

Reading an existing X12 file

The following code sample shows loading an Interchange object from an existing X12 string.

It then demonstrates traversing the object model to test specific elements against the expected values.

privatestring inquiry = @"ISA*00*          *00*          *01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*1*T*:~
    GS*HS*901234572000*908887732000*20070816*1615*31*X*005010X279~
    ST*270*1234*005010X279~
    BHT*0022*13*10001234*20060501*1319~
    HL*1**20*1~
    NM1*PR*2*ABC COMPANY*****PI*842610001~
    HL*2*1*21*1~
    NM1*1P*2*BONE AND JOINT CLINIC*****SV*2000035~
    HL*3*2*22*0~
    TRN*1*93175-012547*9877281234~
    NM1*IL*1*SMITH*ROBERT****MI*11122333301~
    DMG*D8*19430519~
    DTP*291*D8*20060501~
    EQ*30~
    SE*13*1234~
    GE*1*31~
    IEA*1*000000031~";

[TestMethod]
publicvoid Read270Test()
{
    X12Parser parser = newX12Parser();
    Interchange interchange = parser.Parse(newMemoryStream(Encoding.ASCII.GetBytes(inquiry)));
    Assert.AreEqual("9088877320000  ", interchange.InterchangeReceiverId);

Transaction transaction = interchange.FunctionGroups.First().Transactions.First();
    Segment bht = transaction.Segments.First();

Assert.AreEqual("10001234", bht.GetElement(3));

    HierarchicalLoop subscriberLoop = transaction.FindHLoop("3");

    Loop subscriberNameLoop = subscriberLoop.Loops.First();

    Assert.AreEqual("SMITH", subscriberNameLoop.GetElement(3), "Subscriber last name not expected.");
    Assert.AreEqual("11122333301", subscriberNameLoop.GetElement(9), "Subscriber member id not expected.");

}

Modifying an existing X12 file

See the test  ParseModifyAndTransformBackToX12 for an example of code to modify an existing file.

Creating a new X12 document

Some suggested reading for understanding the X12 format in general: http://docs.oracle.com/cd/E19398-01/820-1275/agdaw/index.html

Some suggested reading for understanding the 270 format: http://www.anthem.com/edi/noapplication/f3/s1/t0/pw_ad086850.pdf

Starting with an outlined version of a 270 file (This code will be included in the testCreate270Test in the next release with the test code given above -Read270Test)

First you need to create the interchange (The ISA line above).

The following code creates this: ISA*00*          *00*          *01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*0*T*:~ (Along with its ending code in IEA)

Once the interchange is created, you need to add the Function Group to it. (This is the second line in the above example 270 text starting with GS)

This section of code creates this: GS*HS*901234572000*908887732000*20070816*1615*31*X*00501X092A1~(Along with its ending code in GE)

The next step is adding an actual transaction to the message. This is done by creating a transaction and a BHT – the header for the group of HL levels below.

This section of code creates this: ST*270*1234~BHT*0022*13*10001234*20070816*1319*00~(Along with its ending code in SE)

Now you will be adding the information for the HL levels to the BHT created above. There are 4 levels to a 270 request:

HL1 – The information source level

HL2 – The information receiver level

HL3 – The subscriber level

HL4 – The dependent level (Optional)

To create the HL1 level (Information Source):

To create the HL2 level (Information Receiver)

For the HL3 Level (Member/Subscriber):

And the same process would be used for creating an HL4 (Dependent) record addition to the 270.

Basically what you are doing is building up the document with each added hierarchal level or loop until the document is complete.

X12 Interchange Model

The X12 Parser is designed around a set of objects that get loaded with the help of an X12Parser object. Once loaded, the Interchange object can operate without any further assistance from the X12Parser.

You can use these objects to:

1. Read an existing X12 file without the use of the XML transformations.
2. Load an existing X12 file and make modifications without disturbing any segments that you do not explicit change.
3. Create a new X12 document using a built in or custom transaction specification.

An X12 envelop starts with an Interchange surrounding a set of Function Groups surrounding a set of Transactions.
The transactions can hold individual segments, loops or hierarchical loops. The following domain model represents these objects with the least repetition of their common characteristics.



Let's look at how to use these objects with some code samples to work with the following 270 Eligibility Inquiry x12:

Reading an existing X12 file

The following code sample shows loading an Interchange object from an existing X12 string.

It then demonstrates traversing the object model to test specific elements against the expected values.

privatestring inquiry = @"ISA*00*          *00*          *01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*1*T*:~
    GS*HS*901234572000*908887732000*20070816*1615*31*X*005010X279~
    ST*270*1234*005010X279~
    BHT*0022*13*10001234*20060501*1319~
    HL*1**20*1~
    NM1*PR*2*ABC COMPANY*****PI*842610001~
    HL*2*1*21*1~
    NM1*1P*2*BONE AND JOINT CLINIC*****SV*2000035~
    HL*3*2*22*0~
    TRN*1*93175-012547*9877281234~
    NM1*IL*1*SMITH*ROBERT****MI*11122333301~
    DMG*D8*19430519~
    DTP*291*D8*20060501~
    EQ*30~
    SE*13*1234~
    GE*1*31~
    IEA*1*000000031~";

[TestMethod]
publicvoid Read270Test()
{
    X12Parser parser = newX12Parser();
    Interchange interchange = parser.Parse(newMemoryStream(Encoding.ASCII.GetBytes(inquiry)));
    Assert.AreEqual("9088877320000  ", interchange.InterchangeReceiverId);

Transaction transaction = interchange.FunctionGroups.First().Transactions.First();
    Segment bht = transaction.Segments.First();

Assert.AreEqual("10001234", bht.GetElement(3));

    HierarchicalLoop subscriberLoop = transaction.FindHLoop("3");

    Loop subscriberNameLoop = subscriberLoop.Loops.First();

    Assert.AreEqual("SMITH", subscriberNameLoop.GetElement(3), "Subscriber last name not expected.");
    Assert.AreEqual("11122333301", subscriberNameLoop.GetElement(9), "Subscriber member id not expected.");

}

Modifying an existing X12 file

See the test  ParseModifyAndTransformBackToX12 for an example of code to modify an existing file.

Creating a new X12 document

Some suggested reading for understanding the X12 format in general: http://docs.oracle.com/cd/E19398-01/820-1275/agdaw/index.html

Some suggested reading for understanding the 270 format: http://www.anthem.com/edi/noapplication/f3/s1/t0/pw_ad086850.pdf

Starting with an outlined version of a 270 file (This code will be included in the testCreate270Test in the next release with the test code given above -Read270Test)

First you need to create the interchange (The ISA line above).

The following code creates this: ISA*00*          *00*          *01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*0*T*:~ (Along with its ending code in IEA)

Once the interchange is created, you need to add the Function Group to it. (This is the second line in the above example 270 text starting with GS)

This section of code creates this: GS*HS*901234572000*908887732000*20070816*1615*31*X*00501X092A1~(Along with its ending code in GE)

The next step is adding an actual transaction to the message. This is done by creating a transaction and a BHT – the header for the group of HL levels below.

This section of code creates this: ST*270*1234~BHT*0022*13*10001234*20070816*1319*00~(Along with its ending code in SE)

Now you will be adding the information for the HL levels to the BHT created above. There are 4 levels to a 270 request:

HL1 – The information source level

HL2 – The information receiver level

HL3 – The subscriber level

HL4 – The dependent level (Optional)

To create the HL1 level (Information Source):

To create the HL2 level (Information Receiver)

For the HL3 Level (Member/Subscriber):

And the same process would be used for creating an HL4 (Dependent) record addition to the 270.

Basically what you are doing is building up the document with each added hierarchal level or loop until the document is complete.

X12 Interchange Model

The X12 Parser is designed around a set of objects that get loaded with the help of an X12Parser object. Once loaded, the Interchange object can operate without any further assistance from the X12Parser.

You can use these objects to:

1. Read an existing X12 file without the use of the XML transformations.
2. Load an existing X12 file and make modifications without disturbing any segments that you do not explicit change.
3. Create a new X12 document using a built in or custom transaction specification.

An X12 envelop starts with an Interchange surrounding a set of Function Groups surrounding a set of Transactions.
The transactions can hold individual segments, loops or hierarchical loops. The following domain model represents these objects with the least repetition of their common characteristics.



Let's look at how to use these objects with some code samples to work with the following 270 Eligibility Inquiry x12:

Reading an existing X12 file

The following code sample shows loading an Interchange object from an existing X12 string.

It then demonstrates traversing the object model to test specific elements against the expected values.

privatestring inquiry = @"ISA*00*          *00*          *01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*1*T*:~
    GS*HS*901234572000*908887732000*20070816*1615*31*X*005010X279~
    ST*270*1234*005010X279~
    BHT*0022*13*10001234*20060501*1319~
    HL*1**20*1~
    NM1*PR*2*ABC COMPANY*****PI*842610001~
    HL*2*1*21*1~
    NM1*1P*2*BONE AND JOINT CLINIC*****SV*2000035~
    HL*3*2*22*0~
    TRN*1*93175-012547*9877281234~
    NM1*IL*1*SMITH*ROBERT****MI*11122333301~
    DMG*D8*19430519~
    DTP*291*D8*20060501~
    EQ*30~
    SE*13*1234~
    GE*1*31~
    IEA*1*000000031~";

[TestMethod]
publicvoid Read270Test()
{
    X12Parser parser = newX12Parser();
    Interchange interchange = parser.Parse(newMemoryStream(Encoding.ASCII.GetBytes(inquiry)));
    Assert.AreEqual("9088877320000  ", interchange.InterchangeReceiverId);

Transaction transaction = interchange.FunctionGroups.First().Transactions.First();
    Segment bht = transaction.Segments.First();

Assert.AreEqual("10001234", bht.GetElement(3));

    HierarchicalLoop subscriberLoop = transaction.FindHLoop("3");

    Loop subscriberNameLoop = subscriberLoop.Loops.First();

    Assert.AreEqual("SMITH", subscriberNameLoop.GetElement(3), "Subscriber last name not expected.");
    Assert.AreEqual("11122333301", subscriberNameLoop.GetElement(9), "Subscriber member id not expected.");

}

Modifying an existing X12 file

See the test  ParseModifyAndTransformBackToX12 for an example of code to modify an existing file.

Creating a new X12 document

Some suggested reading for understanding the X12 format in general: http://docs.oracle.com/cd/E19398-01/820-1275/agdaw/index.html

Some suggested reading for understanding the 270 format: http://www.anthem.com/edi/noapplication/f3/s1/t0/pw_ad086850.pdf

Starting with an outlined version of a 270 file (This code will be included in the testCreate270Test in the next release with the test code given above -Read270Test)

First you need to create the interchange (The ISA line above).

The following code creates this: ISA*00*          *00*          *01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*0*T*:~ (Along with its ending code in IEA)

Once the interchange is created, you need to add the Function Group to it. (This is the second line in the above example 270 text starting with GS)

This section of code creates this: GS*HS*901234572000*908887732000*20070816*1615*31*X*00501X092A1~(Along with its ending code in GE)

The next step is adding an actual transaction to the message. This is done by creating a transaction and a BHT – the header for the group of HL levels below.

This section of code creates this: ST*270*1234~BHT*0022*13*10001234*20070816*1319*00~(Along with its ending code in SE)

Now you will be adding the information for the HL levels to the BHT created above. There are 4 levels to a 270 request:

HL1 – The information source level

HL2 – The information receiver level

HL3 – The subscriber level

HL4 – The dependent level (Optional)

To create the HL1 level (Information Source):

To create the HL2 level (Information Receiver)

For the HL3 Level (Member/Subscriber):

And the same process would be used for creating an HL4 (Dependent) record addition to the 270.

Basically what you are doing is building up the document with each added hierarchal level or loop until the document is complete.

X12 Interchange Model

The X12 Parser is designed around a set of objects that get loaded with the help of an X12Parser object. Once loaded, the Interchange object can operate without any further assistance from the X12Parser.

You can use these objects to:

1. Read an existing X12 file without the use of the XML transformations.
2. Load an existing X12 file and make modifications without disturbing any segments that you do not explicit change.
3. Create a new X12 document using a built in or custom transaction specification.

An X12 envelop starts with an Interchange surrounding a set of Function Groups surrounding a set of Transactions.
The transactions can hold individual segments, loops or hierarchical loops. The following domain model represents these objects with the least repetition of their common characteristics.



Let's look at how to use these objects with some code samples to work with the following 270 Eligibility Inquiry x12:

Reading an existing X12 file

The following code sample shows loading an Interchange object from an existing X12 string.

It then demonstrates traversing the object model to test specific elements against the expected values.

privatestring inquiry = @"ISA*00*          *00*          *01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*1*T*:~
    GS*HS*901234572000*908887732000*20070816*1615*31*X*005010X279~
    ST*270*1234*005010X279~
    BHT*0022*13*10001234*20060501*1319~
    HL*1**20*1~
    NM1*PR*2*ABC COMPANY*****PI*842610001~
    HL*2*1*21*1~
    NM1*1P*2*BONE AND JOINT CLINIC*****SV*2000035~
    HL*3*2*22*0~
    TRN*1*93175-012547*9877281234~
    NM1*IL*1*SMITH*ROBERT****MI*11122333301~
    DMG*D8*19430519~
    DTP*291*D8*20060501~
    EQ*30~
    SE*13*1234~
    GE*1*31~
    IEA*1*000000031~";

[TestMethod]
publicvoid Read270Test()
{
    X12Parser parser = newX12Parser();
    Interchange interchange = parser.Parse(newMemoryStream(Encoding.ASCII.GetBytes(inquiry)));
    Assert.AreEqual("9088877320000  ", interchange.InterchangeReceiverId);

Transaction transaction = interchange.FunctionGroups.First().Transactions.First();
    Segment bht = transaction.Segments.First();

Assert.AreEqual("10001234", bht.GetElement(3));

    HierarchicalLoop subscriberLoop = transaction.FindHLoop("3");

    Loop subscriberNameLoop = subscriberLoop.Loops.First();

    Assert.AreEqual("SMITH", subscriberNameLoop.GetElement(3), "Subscriber last name not expected.");
    Assert.AreEqual("11122333301", subscriberNameLoop.GetElement(9), "Subscriber member id not expected.");

}

Modifying an existing X12 file

See the test  ParseModifyAndTransformBackToX12 for an example of code to modify an existing file.

Creating a new X12 document

Some suggested reading for understanding the X12 format in general: http://docs.oracle.com/cd/E19398-01/820-1275/agdaw/index.html

Some suggested reading for understanding the 270 format: http://www.anthem.com/edi/noapplication/f3/s1/t0/pw_ad086850.pdf

Starting with an outlined version of a 270 file (This code will be included in the testCreate270Test in the next release with the test code given above -Read270Test)

First you need to create the interchange (The ISA line above).

The following code creates this: ISA*00*          *00*          *01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*0*T*:~ (Along with its ending code in IEA)

Once the interchange is created, you need to add the Function Group to it. (This is the second line in the above example 270 text starting with GS)

This section of code creates this: GS*HS*901234572000*908887732000*20070816*1615*31*X*00501X092A1~(Along with its ending code in GE)

The next step is adding an actual transaction to the message. This is done by creating a transaction and a BHT – the header for the group of HL levels below.

This section of code creates this: ST*270*1234~BHT*0022*13*10001234*20070816*1319*00~(Along with its ending code in SE)

Now you will be adding the information for the HL levels to the BHT created above. There are 4 levels to a 270 request:

HL1 – The information source level

HL2 – The information receiver level

HL3 – The subscriber level

HL4 – The dependent level (Optional)

To create the HL1 level (Information Source):

To create the HL2 level (Information Receiver)

For the HL3 Level (Member/Subscriber):

And the same process would be used for creating an HL4 (Dependent) record addition to the 270.

Basically what you are doing is building up the document with each added hierarchal level or loop until the document is complete.

X12 Interchange Model

The X12 Parser is designed around a set of objects that get loaded with the help of an X12Parser object. Once loaded, the Interchange object can operate without any further assistance from the X12Parser.

You can use these objects to:

1. Read an existing X12 file without the use of the XML transformations.
2. Load an existing X12 file and make modifications without disturbing any segments that you do not explicit change.
3. Create a new X12 document using a built in or custom transaction specification.

An X12 envelop starts with an Interchange surrounding a set of Function Groups surrounding a set of Transactions.
The transactions can hold individual segments, loops or hierarchical loops. The following domain model represents these objects with the least repetition of their common characteristics.



Let's look at how to use these objects with some code samples to work with the following 270 Eligibility Inquiry x12:

Reading an existing X12 file

The following code sample shows loading an Interchange object from an existing X12 string.

It then demonstrates traversing the object model to test specific elements against the expected values.

privatestring inquiry = @"ISA*00*          *00*          *01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*0*T*:~
                                              GS*HS*901234572000*908887732000*20070816*1615*31*X*00501X092A1~
                                                ST*270*1234~
                                                  BHT*0022*13*10001234*20070816*1319*00~
                                                  HL*1**20*1~
                                                    NM1*PR*2*ABC BILLING SERVICE*****PI*842610001~
                                                    HL*2*1*21*1~
                                                      NM1*1P*2*BONE AND JOINT CLINIC*****SV*2000035~
                                                      HL*3*2*22*0~
                                                        TRN*1*93175-012547*9877281234~
                                                        NM1*IL*1*SMITH*ROBERT*MI****11122333301~
                                                          DMG*D8*19430519~
                                                          DTP*291*D8*20060501~
                                                          EQ*30~
                                                SE*13*1234~
                                              GE*1*31~
                                            IEA*1*000000031~";

[TestMethod]
publicvoid Read270Test()
{
    X12Parser parser = newX12Parser();
    Interchange interchange = parser.Parse(newMemoryStream(Encoding.ASCII.GetBytes(inquiry)));
    Assert.AreEqual("9088877320000  ", interchange.InterchangeReceiverId);

Transaction transaction = interchange.FunctionGroups.First().Transactions.First();
    Segment bht = transaction.Segments.First();

Assert.AreEqual("10001234", bht.GetElement(3));

    HierarchicalLoop subscriberLoop = transaction.FindHLoop("3");

    Loop subscriberNameLoop = subscriberLoop.Loops.First();

    Assert.AreEqual("SMITH", subscriberNameLoop.GetElement(3), "Subscriber last name not expected.");
    Assert.AreEqual("11122333301", subscriberNameLoop.GetElement(9), "Subscriber member id not expected.");

}

Modifying an existing X12 file

See the test  ParseModifyAndTransformBackToX12 for an example of code to modify an existing file.

Creating a new X12 document

Some suggested reading for understanding the X12 format in general: http://docs.oracle.com/cd/E19398-01/820-1275/agdaw/index.html

Some suggested reading for understanding the 270 format: http://www.anthem.com/edi/noapplication/f3/s1/t0/pw_ad086850.pdf

Starting with an outlined version of a 270 file (This code will be included in the testCreate270Test in the next release with the test code given above -Read270Test)

First you need to create the interchange (The ISA line above).

The following code creates this: ISA*00*          *00*          *01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*0*T*:~ (Along with its ending code in IEA)

Once the interchange is created, you need to add the Function Group to it. (This is the second line in the above example 270 text starting with GS)

This section of code creates this: GS*HS*901234572000*908887732000*20070816*1615*31*X*00501X092A1~(Along with its ending code in GE)

The next step is adding an actual transaction to the message. This is done by creating a transaction and a BHT – the header for the group of HL levels below.

This section of code creates this: ST*270*1234~BHT*0022*13*10001234*20070816*1319*00~(Along with its ending code in SE)

Now you will be adding the information for the HL levels to the BHT created above. There are 4 levels to a 270 request:

HL1 – The information source level

HL2 – The information receiver level

HL3 – The subscriber level

HL4 – The dependent level (Optional)

To create the HL1 level (Information Source):

To create the HL2 level (Information Receiver)

For the HL3 Level (Member/Subscriber):

And the same process would be used for creating an HL4 (Dependent) record addition to the 270.

Basically what you are doing is building up the document with each added hierarchal level or loop until the document is complete.

X12 Interchange Model

The X12 Parser is designed around a set of objects that get loaded with the help of an X12Parser object. Once loaded, the Interchange object can operate without any further assistance from the X12Parser.

You can use these objects to:

1. Read an existing X12 file without the use of the XML transformations.
2. Load an existing X12 file and make modifications without disturbing any segments that you do not explicit change.
3. Create a new X12 document using a built in or custom transaction specification.

An X12 envelop starts with an Interchange surrounding a set of Function Groups surrounding a set of Transactions.
The transactions can hold individual segments, loops or hierarchical loops. The following domain model represents these objects with the least repetition of their common characteristics.



Let's look at how to use these objects with some code samples to work with the following 270 Eligibility Inquiry x12:

Reading an existing X12 file

The following code sample shows loading an Interchange object from an existing X12 string.

It then demonstrates traversing the object model to test specific elements against the expected values.

privatestring inquiry = @"ISA*00*          *00*          						*01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*0*T*:~
                                              GS*HS*901234572000*908887732000*20070816*1615*31*X*00501X092A1~
                                                ST*270*1234~
                                                  BHT*0022*13*10001234*20070816*1319*00~
                                                  HL*1**20*1~
                                                    NM1*PR*2*ABC BILLING SERVICE*****PI*842610001~
                                                    HL*2*1*21*1~
                                                      NM1*1P*2*BONE AND JOINT CLINIC*****SV*2000035~
                                                      HL*3*2*22*0~
                                                        TRN*1*93175-012547*9877281234~
                                                        NM1*IL*1*SMITH*ROBERT*MI****11122333301~
                                                          DMG*D8*19430519~
                                                          DTP*291*D8*20060501~
                                                          EQ*30~
                                                SE*13*1234~
                                              GE*1*31~
                                            IEA*1*000000031~";

[TestMethod]
publicvoid Read270Test()
{
    X12Parser parser = newX12Parser();
    Interchange interchange = parser.Parse(newMemoryStream(Encoding.ASCII.GetBytes(inquiry)));
    Assert.AreEqual("9088877320000  ", interchange.InterchangeReceiverId);

Transaction transaction = interchange.FunctionGroups.First().Transactions.First();
    Segment bht = transaction.Segments.First();

Assert.AreEqual("10001234", bht.GetElement(3));

    HierarchicalLoop subscriberLoop = transaction.FindHLoop("3");

    Loop subscriberNameLoop = subscriberLoop.Loops.First();

    Assert.AreEqual("SMITH", subscriberNameLoop.GetElement(3), "Subscriber last name not expected.");
    Assert.AreEqual("11122333301", subscriberNameLoop.GetElement(9), "Subscriber member id not expected.");

}

Modifying an existing X12 file

See the test  ParseModifyAndTransformBackToX12 for an example of code to modify an existing file.

Creating a new X12 document

Some suggested reading for understanding the X12 format in general: http://docs.oracle.com/cd/E19398-01/820-1275/agdaw/index.html

Some suggested reading for understanding the 270 format: http://www.anthem.com/edi/noapplication/f3/s1/t0/pw_ad086850.pdf

Starting with an outlined version of a 270 file (This code will be included in the testCreate270Test in the next release with the test code given above -Read270Test)

privatestring inquiry = @"ISA*00*          *00*          						*01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*0*T*:~
                                              GS*HS*901234572000*908887732000*20070816*1615*31*X*00501X092A1~
                                                ST*270*1234~
                                                  BHT*0022*13*10001234*20070816*1319*00~
                                                  HL*1**20*1~
                                                    NM1*PR*2*ABC BILLING SERVICE*****PI*842610001~
                                                    HL*2*1*21*1~
                                                      NM1*1P*2*BONE AND JOINT CLINIC*****SV*2000035~
                                                      HL*3*2*22*0~
                                                        TRN*1*93175-012547*9877281234~
                                                        NM1*IL*1*SMITH*ROBERT*MI****11122333301~
                                                          DMG*D8*19430519~
                                                          DTP*291*D8*20060501~
                                                          EQ*30~
                                                SE*13*1234~
                                              GE*1*31~
                                            IEA*1*000000031~";
 
First you need to create the interchange (The ISA line above). 
The following code creates this: ISA*00*          *00*          *01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*0*T*:~ (Along with its ending code in IEA)
 
Once the interchange is created, you need to add the Function Group to it. (This is the second line in the above example 270 text starting with GS)
This section of code creates this: GS*HS*901234572000*908887732000*20070816*1615*31*X*00501X092A1~(Along with its ending code in GE)
 
The next step is adding an actual transaction to the message. This is done by creating a transaction and a BHT – the header for the group of HL levels below.
This section of code creates this: ST*270*1234~BHT*0022*13*10001234*20070816*1319*00~(Along with its ending code in SE)
 
Now you will be adding the information for the HL levels to the BHT created above. There are 4 levels to a 270 request:
HL1 – The information source level
HL2 – The information receiver level
HL3 – The subscriber level
HL4 – The dependent level (Optional)
To create the HL1 level (Information Source):
 
To create the HL2 level (Information Receiver)
 
For the HL3 Level (Member/Subscriber):
 
And the same process would be used for creating an HL4 (Dependent) record addition to the 270.
Basically what you are doing is building up the document with each added hierarchal level or loop until the document is complete. 

X12 Interchange Model

The X12 Parser is designed around a set of objects that get loaded with the help of an X12Parser object. Once loaded, the Interchange object can operate without any further assistance from the X12Parser.

You can use these objects to:

1. Read an existing X12 file without the use of the XML transformations.
2. Load an existing X12 file and make modifications without disturbing any segments that you do not explicit change.
3. Create a new X12 document using a built in or custom transaction specification.

An X12 envelop starts with an Interchange surrounding a set of Function Groups surrounding a set of Transactions.
The transactions can hold individual segments, loops or hierarchical loops. The following domain model represents these objects with the least repetition of their common characteristics.



Let's look at how to use these objects with some code samples to work with the following 270 Eligibility Inquiry x12:

Reading an existing X12 file

The following code sample shows loading an Interchange object from an existing X12 string.

It then demonstrates traversing the object model to test specific elements against the expected values.

privatestring inquiry = @"ISA*00*          *00*          						*01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*0*T*:~
                                              GS*HS*901234572000*908887732000*20070816*1615*31*X*00501X092A1~
                                                ST*270*1234~
                                                  BHT*0022*13*10001234*20070816*1319*00~
                                                  HL*1**20*1~
                                                    NM1*PR*2*ABC BILLING SERVICE*****PI*842610001~
                                                    HL*2*1*21*1~
                                                      NM1*1P*2*BONE AND JOINT CLINIC*****SV*2000035~
                                                      HL*3*2*22*0~
                                                        TRN*1*93175-012547*9877281234~
                                                        NM1*IL*1*SMITH*ROBERT*MI****11122333301~
                                                          DMG*D8*19430519~
                                                          DTP*291*D8*20060501~
                                                          EQ*30~
                                                SE*13*1234~
                                              GE*1*31~
                                            IEA*1*000000031~";

[TestMethod]
publicvoid Read270Test()
{
    X12Parser parser = newX12Parser();
    Interchange interchange = parser.Parse(newMemoryStream(Encoding.ASCII.GetBytes(inquiry)));
    Assert.AreEqual("9088877320000  ", interchange.InterchangeReceiverId);

Transaction transaction = interchange.FunctionGroups.First().Transactions.First();
    Segment bht = transaction.Segments.First();

Assert.AreEqual("10001234", bht.GetElement(3));

    HierarchicalLoop subscriberLoop = transaction.FindHLoop("3");

    Loop subscriberNameLoop = subscriberLoop.Loops.First();

    Assert.AreEqual("SMITH", subscriberNameLoop.GetElement(3), "Subscriber last name not expected.");
    Assert.AreEqual("11122333301", subscriberNameLoop.GetElement(9), "Subscriber member id not expected.");

}

Modifying an existing X12 file

See the test  ParseModifyAndTransformBackToX12 for an example of code to modify an existing file.

Creating a new X12 document

Some suggested reading for understanding the X12 format in general: http://docs.oracle.com/cd/E19398-01/820-1275/agdaw/index.html

Some suggested reading for understanding the 270 format: http://www.anthem.com/edi/noapplication/f3/s1/t0/pw_ad086850.pdf

Starting with an outlined version of a 270 file (This code will be included in the testCreate270Test in the next release with the test code given above -Read270Test)

privatestring inquiry = @"ISA*00*          *00*        	                                                *01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*0*T*:~
                                              GS*HS*901234572000*908887732000*20070816*1615*31*X*00501X092A1~
                                                ST*270*1234~
                                                  BHT*0022*13*10001234*20070816*1319*00~
                                                  HL*1**20*1~
                                                    NM1*PR*2*ABC BILLING SERVICE*****PI*842610001~
                                                    HL*2*1*21*1~
                                                      NM1*1P*2*BONE AND JOINT CLINIC*****SV*2000035~
                                                      HL*3*2*22*0~
                                                        TRN*1*93175-012547*9877281234~
                                                        NM1*IL*1*SMITH*ROBERT*MI****11122333301~
                                                          DMG*D8*19430519~
                                                          DTP*291*D8*20060501~
                                                          EQ*30~
                                                SE*13*1234~
                                              GE*1*31~
                                            IEA*1*000000031~";

First you need to create the interchange (The ISA line above).

The following code creates this: ISA*00*          *00*          *01*9012345720000  *01*9088877320000  *020816*1144*U*00401*000000031*0*T*:~ (Along with its ending code in IEA)

Once the interchange is created, you need to add the Function Group to it. (This is the second line in the above example 270 text starting with GS)

This section of code creates this: GS*HS*901234572000*908887732000*20070816*1615*31*X*00501X092A1~(Along with its ending code in GE)

The next step is adding an actual transaction to the message. This is done by creating a transaction and a BHT – the header for the group of HL levels below.

This section of code creates this: ST*270*1234~BHT*0022*13*10001234*20070816*1319*00~(Along with its ending code in SE)

Now you will be adding the information for the HL levels to the BHT created above. There are 4 levels to a 270 request:

HL1 – The information source level

HL2 – The information receiver level

HL3 – The subscriber level

HL4 – The dependent level (Optional)

To create the HL1 level (Information Source):

To create the HL2 level (Information Receiver)

For the HL3 Level (Member/Subscriber):

And the same process would be used for creating an HL4 (Dependent) record addition to the 270.

Basically what you are doing is building up the document with each added hierarchal level or loop until the document is complete.