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