pstuteville/x12

X12Parser - a library to manipulate X12 structures using native Ruby syntax

= X12Parser - a library to manipulate X12 structures using native Ruby syntax

$Id: README 92 2009-05-13 22:12:10Z ikk $

*WARNING* <tt>The project is in development. Contributors are welcome.</tt>

Project home is at http://rubyforge.org/projects/x12parser/. Please
note, this is a different project from {Chris Parker's port}[http://rubyforge.org/projects/x12-parser/] of
{X12::Parser Perl module}[http://search.cpan.org/~prasad/X12-0.09/lib/X12/Parser.pm].

== The goal

The idea is to access X12 messages directly from Ruby, i.e., using a
syntax like

  message.L1000.L1010[1].AK4.DataElementReferenceNumber

This syntax can be used to get and set any field of an X12 message and
it makes X12 parsing much more straightforward and self-documenting.

== The problem

X12 is a set of "standards" possessing all the elegance of an elephant
designed by committee, and quite literally so, see http://www.x12.org.
X12 defines rough syntax for specifying text messages, but each of
more than 300 specifications defines its own message structure. While
messages themselves are easy to parse with a simple tokenizer, their
semantics is heavily dependent on the domain. For example, this is
X12/997 message conveying "Functional Acknowledgment":

  ST*997*2878~AK1*HS*293328532~AK2*270*307272179~AK3*NM1*8*L1010_0*8~
  AK4*0:0*66*1~AK4*0:1*66*1~AK4*0:2*66*1~AK3*NM1*8*L1010_1*8~AK4*1:0*
  66*1~AK4*1:1*66*1~AK3*NM1*8*L1010_2*8~AK4*2:0*66*1~AK5*R*5~AK9*R*1*
  1*0~SE*8*2878~

I.e., X12 defines an alphabet and somewhat of a dictionary - not a
grammar or semantics for each particular data interchange
conversation. Because of many entrenched implementations and
government mandates, the X12 is not going to die anytime soon,
unfortunately.

The message above can be easily represented in Ruby as a nested array:

 m = [
      ['ST', '997', '2878'],
      ['AK1', 'HS', '293328532'],
      ['AK2', '270', '307272179'],
      ['AK3', 'NM1', '8', 'L1010_0', '8'],
      ['AK4', '0:0', '66', '1'],
      ['AK4', '0:1', '66', '1'],
      ['AK4', '0:2', '66', '1'],
      ['AK3', 'NM1', '8', 'L1010_1', '8'],
      ['AK4', '1:0', '66', '1'],
      ['AK4', '1:1', '66', '1'],
      ['AK3', 'NM1', '8', 'L1010_2', '8'],
      ['AK4', '2:0', '66', '1'],
      ['AK5', 'R', '5'],
      ['AK9', 'R', '1', '1', '0'],
      ['SE', '8', '2878'],
     ]

but it will not help any since, say, segment 'AK4' is ambiguously
defined and its meaning not at all obvious until the message's
structure is interpreted and correct 'AK4' segment is found.

== The solution

=== Message structure

Each participant in EDI has to know the structure of the data coming
across the wire - X12 or no X12. The X12 structures are defined in
so-called Implementation Guides - thick books with all the data pieces
spelled out. There is no other choice, but to invent a
computer-readable definition language that will codify these
books. For familiarity sake we'll use XML. For example, the X12/997
message can be defined as

  <Definition>
    <Loop name="997">
      <Segment name="ST" min="1" max="1"/>
      <Segment name="AK1" min="1" max="1"/>
      <Loop name="L1000" max="999999" required="y">
        <Segment name="AK2" max="1" required="n"/>
        <Loop name="L1010" max="999999" required="n">
          <Segment name="AK3" max="1" required="n"/>
          <Segment name="AK4" max="99" required="n"/>
        </Loop>
        <Segment name="AK5" max="1" required="y"/>
      </Loop>
      <Segment name="AK9" max="1" required="y"/>
      <Segment name="SE"  max="1" required="y"/>
    </Loop>
  </Definition>

Namely, the 997 is a 'loop' containing segments ST (only one), AK1
(also only one), another loop L1000 (zero or many repeats), segments
AK9 and SE. The loop L1000 can contain a segment AK2 (optional) and
another loop L1010 (zero or many), and so on.

The segments' structure can be further defined as, for example,

  <Segment name="AK2">
    <Field name="TransactionSetIdentifierCode" required="y" min="3" max="3" validation="T143"/>
    <Field name="TransactionSetControlNumber"  required="y" min="4" max="9"/>
  </Segment>

which defines a segment AK2 as having two fields:
TransactionSetIdentifierCode and TransactionSetControlNumber. The
field TransactionSetIdentifierCode is defined as having a type of
string (default), being required, having length of minimum 3 and
maximum 3 characters, and being validated against a table T143. The
validation table is defined as

  <Table name="T143">
    <Entry name="100" value="Insurance Plan Description"/>
    <Entry name="101" value="Name and Address Lists"/>
    ...
    <Entry name="997" value="Functional Acknowledgment"/>
    <Entry name="998" value="Set Cancellation"/>
  </Table>

with entries having just names and values.

This message is fully flashed out in an example 'misc/997.xml' file,
copied from the ASC X12N 276/277 (004010X093) "Health Care
Claim Status Request and Response" National Electronic Data
Interchange Transaction Set Implementation Guide.

Now expressions like 

  message.L1000.L1010[1].AK4.DataElementReferenceNumber

start making sense of sorts, overall X12's idiocy notwithstanding - it's
a field called 'DataElementReferenceNumber' of a first of possibly
many segments 'AK4' found in the second repeat of the loop 'L1010'
inside the enclosing loop 'L1000'. The meaning of the value '66' found
in this field is still in the eye of the beholder, but, at least its
location is clearly identified in the message.


=== X12 Structure Definition Language

The syntax of the X12 structure definition language should be apparent
from the '997.xml' file enclosed with the package. A more detailed
description follows in Appendix A.

=== Parsing

Here is how to parse an X12/997 message (the source is in
example/parse.rb):

  require 'x12'

  # Read message definition and create an actual parser
  # by compiling the XML file
  parser = X12::Parser.new('misc/997.xml')

  # Define a test message to parse
  m997='ST*997*2878~AK1*HS*293328532~AK2*270*307272179~'\
  'AK3*NM1*8*L1010_0*8~AK4*0:0*66*1~AK4*0:1*66*1~AK4*0:2*'\
  '66*1~AK3*NM1*8*L1010_1*8~AK4*1:0*66*1~AK4*1:1*66*1~AK3*'\
  'NM1*8*L1010_2*8~AK4*2:0*66*1~AK5*R*5~AK9*R*1*1*0~SE*8*2878~'

  # Parse the message
  r = parser.parse('997', m997)

  # Access components of the message as desired

  # Whole ST segment: -> ST*997*2878~
  puts r.ST

  # One filed, Group Control Number of AK1 -> 293328532
  puts r.AK1.GroupControlNumber

  # Individual loop, namely, third L1010 sub-loop of
  # L1000 loop: -> AK3*NM1*8*L1010_2*8~AK4*2:0*66*1~
  puts r.L1000.L1010[2]

  # First encounter of Data Element Reference Number of the 
  # first L1010 sub-loop of L1000 loop -> 66
  puts r.L1000.L1010.AK4.DataElementReferenceNumber

  # Number of L1010 sub-loops in L1000 loop -> 3
  puts r.L1000.L1010.size

=== Generating

Here is how to perform a reverse operation and generate a well-formed
997 message (the source is in example/factory.rb):

  require 'x12'

  # Read message definition and create an actual parser
  # by compiling .d12 file
  parser = X12::Parser.new('misc/997.xml')

  # Make a new 997 message 
  r = parser.factory('997')

  #
  # Set various fields as desired
  #

  # Set fields directly
  r.ST.TransactionSetIdentifierCode = 997
  r.ST.TransactionSetControlNumber  = '2878'

  # Set fields inside a segment (AK1 in this case)
  r.AK1 { |ak1|
    ak1.FunctionalIdentifierCode = 'HS'
    ak1.GroupControlNumber       = 293328532
  }

  # Set fields deeply inside a segment inside 
  # nested loops (L1000/L1010/AK4 in this case)
  r.L1000.L1010.AK4.DataElementSyntaxErrorCode = 55
  r.L1000.AK2.TransactionSetIdentifierCode     = 270

  # Set nested loops
  r.L1000.L1010 {|l|
    l.AK3 {|s|
      s.SegmentIdCode      = 'NM1'
      s.LoopIdentifierCode = 'L1000D'
    }
    l.AK4 {|s|
      s.CopyOfBadDataElement = 'Bad element'
    }
  }

  # Add loop repeats
  r.L1000.repeat {|l1000|
    (0..1).each {|loop_repeat| # Two repeats of the loop L1010
      l1000.L1010.repeat {|l1010|
        l1010.AK3 {|s|
          s.SegmentIdCode                   = 'DMG'
          s.SegmentPositionInTransactionSet = 0
          s.LoopIdentifierCode              = 'L1010'
          s.SegmentSyntaxErrorCode          = 22
        } if loop_repeat == 0 # AK3 only in the first repeat of L1010
        (0..1).each {|ak4_repeat| # Two repeats of the segment AK4
          l1010.AK4.repeat {|s|
            s.PositionInSegment          = loop_repeat
            s.DataElementSyntaxErrorCode = ak4_repeat
          } # s
        } # ak4_repeat
      } # l1010
    } # loop_repeat

    l1000.AK5{|a|
      a.TransactionSetAcknowledgmentCode = 666
      a.TransactionSetSyntaxErrorCode4   = 999
    } # a
  } # l1000

  # Print the message as a string -> ST*997*2878~AK1*HS*293328532~
  # AK2*270*~AK3*NM1**L1000D~AK4***55*Bad element~AK5*~AK3*DMG*0*
  # L1010*22~AK4*0**0~AK4*0**1~AK4*1**0~AK4*1**1~AK5*666****999~
  # AK9****~SE**~
  puts r.render

== Download

The latest X12 library version can be downloaded from
http://rubyforge.org/frs/?group_id=7297

== Installation

You can install X12 library with the following command.

  % gem install X12

== License

X12 library is released under the Lesser GPL license, see
http://www.gnu.org/licenses/lgpl.txt

== Major deficiencies

* Validation is not implemented.
* Field types and sizes are ignored.
* No access methods for composites' fields.

== Support

Please use the following:

* forums on Rubyforge for general discussions, http://rubyforge.org/forum/?group_id=7297
* trackers to submit bugs or feature requests, http://rubyforge.org/tracker/?group_id=7297
* to contact the author, send mail to prelude rubyforge org

== Acknowledgments

The authors of the project were inspired by the following works:

1. The Perl X12 parser by Prasad Poruporuthan, http://search.cpan.org/~prasad/X12-0.09/lib/X12/Parser.pm
2. The Ruby port of the above by Chris Parker, http://rubyforge.org/projects/x12-parser/

== Appendix A. Structure definition language

The structure definition language uses XML to describe X12 message
format. A message definition can be in a single file or in several. If
the definition parser encounters an element (segment, composite, or
table), which has not been previously defined, it tries to load the
definition from the file with the same name and in the same
directory. For example, if a loop mentions a segment named 'ST' and
this segment is not defined, the parser will try to load and parse a
file called 'ST.xml'. This convention works for any name unless it
conflicts with a Microsoft's device name, see Appendix B.

Each element in a structure definition (except 'Definition') must have
an attribute called 'name'. It is used to set/get respective content
from Ruby. If an element's 'name' attribute cannot be a valid Ruby
identifier (for example, '270'), the parser will prepend the name with
'_' (underscore). I.e., this expression is not valid:

  @r.FG[1].270[1].ST.TransactionSetIdentifierCode

but his one is

  @r.FG[1]._270[1].ST.TransactionSetIdentifierCode

Each XML file has to have a single root element, one of the following:

=== Definition

The 'Definition' element can have nested loops, segments, composites,
and tables. It is used to provide 'artificial' root element for XML
document when several definitions are in one physical file. For
example, this is `misc/997single.xml' (edited for size):

  <Definition>
    <Segment name="ST">
      <Field name="TransactionSetIdentifierCode" min="3" max="3" validation="T143"/>
      <Field name="TransactionSetControlNumber"  min="4" max="9"/>
      <Field name="ImplementationConventionReference" required="y" min="1" max="35"/>
    </Segment>

    <Composite name="C030">
      <Field name="ElementPositionInSegment" type="long" required="n" min="1" max="2"/>
      <Field name="ComponentDataElementPositionInComposite" type="long" required="y" min="1" max="2"/>
      <Field name="RepeatingDataElementPosition" type="long" required="y" min="1" max="4"/>
    </Composite>

    <Segment name="AK1">
      <Field name="FunctionalIdentifierCode" min="2" max="2" validation="T479"/>
      <Field name="GroupControlNumber" type="long" min="1" max="9"/>
    </Segment>

    <Table name="T723">
      <Entry name="1" value="Mandatory data element missing"/>
      <Entry name="2" value="Conditional required data element missing."/>
      <!-- ... other entries -->
      <Entry name="13" value="Too Many Components"/>
    </Table>

    <!-- ... other segments or composites or tables -->

    <Loop name="997">
      <Segment name="ST" min="1" max="1"/>
      <Segment name="AK1" min="1" max="1"/>
      <Loop name="L1000" max="999999" required="y">
        <Segment name="AK2" max="1" required="n"/>
        <Loop name="L1010" max="999999" required="n">
          <Segment name="AK3" max="1" required="n"/>
          <Segment name="AK4" max="99" required="n"/>
        </Loop>
        <Segment name="AK5" max="1" required="y"/>
      </Loop>
      <Segment name="AK9" max="1" required="y"/>
      <Segment name="SE"  max="1" required="y"/>
    </Loop>

  </Definition>

This element does not have any attributes and cannot be addressed from Ruby's API.

=== Loop

The 'Loop' element is a main element to define either loops or whole
messages. Loops can have nested segments and other loops.

Note, that a segment defined inside a loop takes precedence over
previously defined segments. This is convenient if a special version
of a segment is required. For example, this is a general definition of
an 'ST' segment stored in a 'ST.xml' file:

  <Segment name="ST">
    <Field name="TransactionSetIdentifierCode" min="3" max="3" validation="T143"/>
    <Field name="TransactionSetControlNumber" min="4" max="9"/>
    <Field name="ImplementationConventionReference" required="y" min="1" max="35"/>
  </Segment>

If you want the X12 parser to look for a particular message type, say '997', do this:

  <Loop name="997">
    <Segment name="ST"  max="1">
      <Field name="TransactionSetIdentifierCode" const="997"/>
      <Field name="TransactionSetControlNumber" min="4" max="9"/>
    </Segment>
    <Segment name="AK1" max="1"/>
    <!-- ... the rest of the 997 definition -->
  </Loop>

A loop can have the following attributes:
* min - minimal number of repeats allowed, default is 0.
* max - maximum number of repeats allowed, default is 'inf' (infinite).
* required - if the loop is required (boolean), default is false. The true value implies min="1".
* comment - ignored

=== Segment

Segments can only have nested fields. Attributes are as follows:
* min - minimal number of repeats allowed, default is 0. Value min>0 implies required="y".
* max - maximum number of repeats allowed, default is 'inf' (infinite).
* required - if the segment is required (boolean), default is false. The true value implies min="1".
* comment - ignored

All attributed except 'name' are ignored in standalone definitions outside any loop.

=== Composite
Same as a segment.

=== Table

Tables can only have entries defined as name-value pairs. Order is
not important. Only required attribute is 'name'.

=== Field

A field cannot have any nested elements, but its attributes are very important:
* min - minimal number of characters allowed, default is 0. Value min>0 DOES NOT imply required="y" - the field can be missing, but may require a minimum length if present.
* max - maximum number of characters allowed, default is 'inf' (infinite).
* required - if the field is required (boolean), default is false. The true value DOES NOT imply min="1".
* type - one of the 'string' (default), 'integer', 'long', or 'double'. These abbreviations are also valid: 'str', 'int'.
* const - forces the field to have this value, if present.
* validation - the name of a validation table, if any.
* comment - ignored

== Appendix B. Microsoft's device file names

Apparently, in Microsoft's operating systems one cannot create a file
named like 'device_name.whatever', for example, 'CON.xml' is highly
illegal. For such cases, the X12 parser creates an exception and
expects 'CON_.xml' instead.

Here is the full device list according to Microsoft (see
http://support.microsoft.com/kb/74496):

   Name    Function
   ----    --------
   CON     Keyboard and display
   PRN     System list device, usually a parallel port
   AUX     Auxiliary device, usually a serial port
   CLOCK$  System real-time clock
   NUL     Bit-bucket device
   A:-Z:   Drive letters
   COM1    First serial communications port
   LPT1    First parallel printer port
   LPT2    Second parallel printer port
   LPT3    Third parallel printer port
   COM2    Second serial communications port
   COM3    Third serial communications port
   COM4    Fourth serial communications port