EDI (X12)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.
If you make changes to the default EDI schema, make sure you adhere to the following EDI schema rules to prevent the updated schema from becoming invalid.
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.
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 Parts
Connector parts are the fields you configure to connect with a data source or target.
The settings that are available depend on the connector you select.
For a list of all parts for source connectors, see Specifying Connector, Parts, and Properties.
For a list of all parts for target connectors, see Specifying Connector, Parts, and Properties.
Property Options
Property | ST | Description |
|---|---|---|
Skip | S | When the Skip property is set to true, segments that do not match those in the applied schema file are not read. The default is false. If you are reading large EDI files and have many mismatches, then Map Designer parsing time increases – in which case, keep the default setting. |
CodeSetFile | ST | This is the file containing the definition of allowed code set values for fields, used mainly for validation. Click the ellipsis , browse to your file, and click Open to apply the schema file. |
QualifiedFieldNames | ST | This is the name path of the parents of the segment parents in the schema tree. If QualifiedFieldNames is true, Qualified Name is put before a field name. The default is false. |
SchemaFile | ST | Allows you to choose a schema file for your source or target file. Click the ellipsis , browse to your schema file and click Open to apply the schema file. |
Validation | ST | None is the default setting. Click the arrow for a list of the following validation methods: • Composite/Element – Validate maxuse, requirement, min/max length and default value. • Loop/Segment – Validate maxuse and requirement. • Composite/Element+Loop/Segment – Validate both composite/element and loop segment. This property works differently on source and target files. Validation on the source side occurs when you select the Apply button in Source Properties. On the target side, validation occurs at run time. If validation is successful, this is indicated in the log file and if there are errors, error messages are logged to the log file. On source-side validation, the first error is recorded in the log file and then the transformation stops before any other errors are recorded. On the target side, all errors are recorded to the log file, since validation occurs at run time. |
SegmentTerminator | T | In this property, you may select a Segment Terminator from the list. See the ElementSeparator list for your options. |
ElementSeparator | T | In other connectors, such as ASCII (Fixed), this property is called the FieldSeparator. Here is a list of element separators from which you can choose: • 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) | ||
LineWrap | T | Sets the type of line wrap you want to use in your 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. |
SubElementSeparator | T | In this property, you can select a subelement separator from the list. See ElementSeparator above for the complete list of separators. The SubElementSeparator property value supersedes any value mapped in the ISA segment. 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 for HIPAA 5010 schemas. |
Supported 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.
Last modified date: 02/01/2024