User Guide : Map Connectors : Source and Target Map Connectors : EDI X12 (eDoc)
 
Share this page                  
EDI X12 (eDoc)
EDI, or Electronic Data Interchange, uses standard formats to pass data between the disparate business systems. Third parties provide EDI services that enable organizations with different equipment to connect. Although interactive access may be a part of it, EDI implies direct computer to computer transactions into vendors' databases and ordering systems. The EDI standard is ANSI X12, developed by the Data Interchange Standards Association (DISA). With the EDI X12 connector, Map Designer can read and write EDI X12 data files.
An EDI message contains a string of data elements, each of which represents a singular fact, such as a price, product model number, and so forth, separated by delimiters. The entire string is called a data segment. One or more data segments framed by a header and trailer form a transaction set, which is the EDI unit of transmission (equivalent to a message). A transaction set often consists of what is usually contained in a typical business document or form. The parties who exchange EDI transmissions are referred to as trading partners.
EDI Structure
EDI document structure contains Headers that identify the transaction type. Within the document, Segments and Elements further define the data and its structure.
Eligibility/Coverage/Benefits Inquiry-270
Eligibility/Coverage/Benefit Inquiry 271
Patient Information – 275
Claim Status Inquiry - 276
Claim Status Notification - 277
Health Care Services Review Information- 278
Benefit Enrollment and Maintenance - 834
Health care Claim Payment/Advice - 835
Health Claims or Equivalent Encounter Information
Dental,Professional,Institutional-837
Version Mismatch Errors
The ANSI standards reflect generic supersets designed to address a wide range of data exchange requirements. You may decide to define your own "subset" and develop rules that describe the data you submit. If you elect to develop your own schema, be aware that many errors can be traced to schema "version mismatch". It is important that all trading partners agree on the specific version of the schema to be used in transactions. Addenda schemas especially, should be examined to verify version match with all parties involved in the transaction.
Note:  To verify the version of a schema, open the schema in a text editor. Check the header information. In the header, notice the date created and date (last) modified fields. These fields offer a convenient method to determine precise version match.
Caution!  Changes to, or customization of the schema must be communicated among and mutually agreed upon by all trading partners prior to "live" data exchange. A customized or modified schema should be verified by each partner to ensure version match at each point of exchange within the trading group. Thorough preparation, well ahead of time, is the key to minimize production errors.
Recommended Practices
Begin with schema versions that are standard and current.
Agree with each trading partner on which schema version to use.
Check schema addenda for version match at each point-of-exchange.
Test the data exchange and test it frequently, well ahead of production deadline.
Under HIPAA regulations, the service provider, not the vendor, is responsible for the accuracy and timely submission of claims and other reporting documents. If you are a service provider, make it a point to be conversant in matters related to HIPAA requirements. Participate actively with your vendor to develop solutions that satisfy these requirements with a minimum impact on your professional practice. If you are a vendor, understand that the complicated regulations and documentation can be overwhelming to the service provider, whose focus is on the care and treatment of their patients. Understand the other party’s perspective and you have already initiated a business plan.
Note:  The Compliance Deadline for Electronic Claims Submission is October 16, 2003. Compliance requires that claims must be submitted using ANSI X12 837 v4010A1 commencing with that date. Older versions of ANSI X12 837 and all NSF forms are retired after October 16, 2003. The Centers for Medicare and Medicaid Services has implemented a Contingency Plan to accept Compliant and Non-compliant claims after the deadline. See http://www.cms.hhs.gov for complete and accurate information regarding claims submission regulations.
Limitations
The limitations are:
Invalid EDI - EDI segments with no elements that contain data or mandatory elements that contain no data causes invalid EDI files to be generated. By default, Map Designer collapses data elements that contain no data. If a ClearMapPut Action results in a segment with no elements that contain data, Map Designer writes a segment ID with no supporting elements (invalid EDI). If a mandatory element is mapped from a source field that contains no data, Map Designer writes the empty element to the Target (also invalid EDI). You must ensure that empty segments are not written to the target file and that mandatory elements actually contain data before running transformations.
Real-time Messaging Support - The EDI X12 connector is designed to work with only a discrete set (message) at a time. Files containing two or more separate messages must be split to process them with Map Designer. Each message begins with a MSH segment and the MSH must exist only once in a message as the first segment. EDI was designed to be a real-time messaging interface where discrete messages are generated and routed immediately to their destination. Some users employ a batch mode process, where multiple messages are written to a single file before transport occurs. This is not the intended use for EDI X12; Map Designer provides real-time messaging support (for example, processing one message at a time). Therefore, batch files must first be split into discrete messages for processing.
Connector Properties
You can set the following source and target properties.
Property
ST
Description
Encoding
ST
Type of character encoding to use with source and target files. The default value is OEM.
Shift-JIS encoding is used only in Japanese operating systems.
UCS-2 is no longer considered a valid encoding name, but you may use UCS2. In the data file, change UCS-2 to UCS2.
Note:  This property is not encoding of the database that you connect to, but it is the encoding in which the connector expects to receive SQL query statements that must be sent to the database.
SchemaFile
ST
Schema file for the source or target file. Click within the cell and then click Browse to specify schema file. Click Open to apply the file.
Skip
S
If set to True, the segments that do not match those in the applied schema file are not read. The default value is False. If you are reading large EDI files and have many mismatches, then Map Editor parsing time increases. In this case, it must be set to False.
SegmentTerminator
T
Select a Segment Terminator. For the available options, see Element Separator Options.
ElementSeparator
T
Select the Element Separator. For the available options, see Element Separator Options. In other connectors, such as ASCII (Fixed), this property is called the FieldSeparator.
SubElementSeparator
T
Select a sub element separator. For the available options, see Element Separator Options. The SubElementSeparator property value supersedes any value mapped in the ISA segment. It allows overrides of values from the command line or through the API.
RepetitionSeparator
T
Sets the character used to separate multiple occurrences of a field. Supported HIPAA 5010 schemas.
LineWrap
T
Sets the type of line wrap you want to use in the data file. The default is None.
Some EDI files may consist of a constant stream of data with no line separators. LineWrap forces a temporary line-wrapping behavior. When you attempt to connect to your EDI file and you receive parse error messages, try changing the setting to CR-LF, CR, LF, or LF-CR.
WrapLength
T
Sets the length of line wrap you want to use in your target file. The default is 80.
Element Separator Options
CR-LF
STX (0001)
SOT(0002)
ETX(0003)
EOT(0004)
ENQ(0005)
ACK(0006)
BEL(0007)
BS(0008)
HT(0009)
LF(000A)
VT(000B)
FF(000C)
CR(000D)
SO(000E)
S1(000F)
DLE(0010)
DC1(0011)
DC2(0012)
DC3(0013)
DC4(0014)
NAK(0015)
SYN(0016)
ETB(0017)
CAN(0018)
EM(0019)
SUB(001A)
ESC(001B)
FS(001C)
GS(001D)
RS(001E)
US (001F)
SP(0020)
! (0021)
" (0022)
#(0023)
$(0024)
%(0025)
& (0026)
'(0027)
( (0028)
) (0029)
* (002A)
+ (002B)
, (002C)
- (002D)
. (002E)
/ (002F)
: (003A)
; (003B)
< (003C)
= (003D)
>(003E)
? (003F)
@(0040)
[ (005B)
\ (005C)
] (005D)
^ (005E)
_ (005F)
‘ (0060)
{ (007B)
| (007C)
} (007D)
~ (007E)
DEL (007F)
Supported Output Mode
EDI X12 (eDoc) connector supports the Replace output mode. For information about output modes, see Target Output Modes.
Data Type
The following data types are available:
a
AN
an
B
DT
ID
Loop
n
N0
N1
n10
N11
N12
N13
N14
N15
N16
N17
N18
N19
N2
N20
N3
N4
N5
N6
N7
N8
N9
R
Segment
TM
Note:  The data types that you see under Type in the target schema (Map tab) are EDI data type names. However, these data types are read as Text by Map Designer. To use a DT EDI data type in an expression, you would need to treat the data type as Text that must be converted to a DateTime data type. For more information about converting data types, search for "commonly used functions" in the documentation.