EDIBASICS

Task Performance Group

						Search


		A MODULAR COMPONENT MegaDB is a modular component of our core product - MegaXML. It converts SQL database definitions into XML structure definitions and vice versa. It analyzes XSD and dynamically converts it into SQL relational structure by automatically defining, allocating and populating SQL tables and databases.

There are two flavors of EDI: 1) Accredited Standards Committee (ASC) X12 - otherwise known as standard EDI, and 2) UN/EDIFACT which is more commonly referred to as EDIFACT. EDI is the American standard for transaction interchange, while EDIFACT is the acknowledged standard for global applications.

For example, all three major auto manufacturers use EDIFACT, since they order parts from all over the world, including the U.S. But while EDI is typically used for organizations committed to the U.S. domestic marketplace, companies are free to adopt either standard they choose, regardless of their marketplace - global or domestic.

TPG's suite of MegaXML software products, supports both formats. In addition, our MegaExchange product provides an outsourced (hosted) solution that provides customized EDI E-commerce automation solution. This virtually eliminates staff with EDI expertise, thereby reducing cost.

Also discussed here is the Health Insurance Portability & Accountability Act, otherwise known as the HIPAA, and its ramifications on the use of standard EDI transactions within healthcare and medical organizations. In addition, a technical comparison of EDI and EDIFACT is also provided for those interested.

What is EDI?

An acronym for Electronic Data Interchange, EDI is the dominant technical standard for the way in which electronic business information is exchanged between computer systems, essentially between business partners in the U.S. national telecommunications networks using valued added networks (VANs.)

Most EDI applications begin as basic purchase orders and invoices, but eventually evolve into enterprise-wide supply chain management (SCM) solutions. EDI allows you to more quickly and accurately swap information with your trading partners, suppliers and customers, while cutting costs as well.

EDI provides the following standard formats for these buyer-side and seller-side business transactions

• Purchase Orders
• Customs Declaration
• Instruction Message
• Remittance Advice
• Payment Order
• Arrival Notice
• Custom Responses
• Invoices

Understanding EDIFACT

An acronym for EDI For Administration, Commerce and Transport, EDIFACT is the international standard for EDI, and is managed by the United Nations and is otherwise known as UN/CEFACT.

Below are some comments on EDIFACT and its purpose as explained on the UN/CEFACT website at www.unece.org

"EDIFACT is open to participation from Member States, intergovernmental organizations, or sectoral and industry associations recognized by the Economic Social Council of the United Nations. EDIFACT is a growing international standard. In order to bring about the evolution of the EDIFACT standard, the UN has created UN/CEFACT to coordinate this effort.

The Center's objective is to be 'inclusive' and it actively encourages organizations to contribute and help develop its recommendations and standards. It provides an international EDI standard, a set of syntax rules, data elements, segments and codes messages.

Within the United Nations, UN/CEFACT is located in the Economic Commission for Europe (UN/ECE), which is part of the United Nations network of regional commissions. These regional commissions report to the highest United Nations body in the area of economics, trade and development: ECOSOC. This is the ideal location for developing practical recommendations for action because, within various work areas in the United Nations system, the regional commissions have the closest links to national Governments at the expert level."

The Role of HIPAA

Enacted in 1996, the Health Insurance Portability & Accountability Act (HIPAA) is a federal law affecting U.S. health & medical organizations. To comply with HIPAA standards, health providers and insurers will soon be required to implement standard EDI transactions 837, 835, 276, and 277 into daily operations. Although large portions of the HIPAA law pertain to privacy policies, much of the implementation pertains to computer security.

The HIPAA privacy deadline was April of 2004 and the security deadline was April of 2005. In both cases, physicians, dentists, medical insurers, laboratories will be legally compelled to devise backup plans, implement security measures and procedures, audit their network and train employees as needed.

EDI vs. EDIFACT: A TECHNICAL COMPARISON

Although the purpose of both EDI and EDIFACT is generally the same, their implementation routines have fundamentally different design philosophies:

EDI has more than 700 segments where EDIFACT segments are less than 100, EDIFACT segments are much shorter than EDI and highly compressed because of a variable length feature extensively used in all data elements. The most dramatic contrast is in the area of data elements. EDIFACT has a finer granularity within data elements called composites. Although composites were only seldom used in EDI, their usage exceeds more than 100. So those business entities expressed by over 1,100 data elements, are expressed in just over 310 data elements of EDIFACT, obviously resulting in much shorter segments.

EDI Headers

EDIFACT Headers

Similarities Between EDI and EDIFACT

EDI and the EDIFACT standards possess striking similarities such as: - Both are comprised of tagged and delimited ASCII character strings; - Both utilize a data dictionary of standard (global) business data elements and data segments, and - Both contain predefined message types for specific business functions composed of a specified sequence of data segments, which in turn contain combinations of related data elements. Differences between EDI and EDIFACT despite similarities, significant barriers remain that stand in the way of compatibility between the two standards. Currently, the primary barrier between the two standards is the lack of direct semantic equivalence, which is illustrated in the following section.

Although it may seem instinctive to compare EDI transaction sets to UN/EDIFACT messages by selecting particular segments from each standard and simply comparing data elements from one standard to data elements of the other standard, this approach has inherent problems. The problem with this comparison technique is that there is not a direct correspondence of data elements across the two standards. Even attempting to compare the two standards at segment level reveals a lack of direct correspondence across the two standards. This compatibility problem exists for three reasons:

- Differences in design philosophies for standards bodies;

- Differing national and international business requirements, and

- Linguistic differences between North America and other countries.

To better understand the aforementioned compatibility problems, try to visualize the following mapping scenario to compare the EDI purchase order transaction set to the UN/EDIFACT ORDERS message. The mapping comparison begins by identifying and selecting a key part of the purchase order transaction set used for comparison in the ORDERS message. The beginning of the purchase order set (BEG) segment is used in the EDI standard to indicate the beginning of the PO transaction set and transmit its related numbers and dates. This segment is mandatory for every PO transaction. In the following example, an attempt is made to directly map the EDI BEG segment to the corresponding UN/EDIFACT segment.

Data Element Mapping Relationships

DCN/ICN-sponsored by U.S. Department of Defense (DOD).
Copyright © 2004 All Rights Reserved.

When considering respective segments to map to in the UN/EDIFACT standard, the Beginning of Message (BGM) segment, at first glance, appears to be equivalent to EDI BEG segment. The BGM segment is the beginning of message segment, which is used to indicate the type and function of a message and to transmit the identifying number for the message.

But closer analysis reveals that while the BEG segment is only used for the EDI purchase order transaction set, the BGM segment is used more generically and appears in nearly all of the UN/EDIFACT messages. This fundamental message design difference requires three additional segments from within the header section of the ORDERS message to account for all the respective data elements from the purchase order transaction set.

It is also evident from the example above that mapping relationships are not always one-to-one. Consider the data element for date from the EDI standard, which is defined as "the date assigned by the purchaser to Purchase Order." In order to successfully map this one data element (date), three data elements are needed from the UN/EDIFACT standard as illustrated below.

An Example of an Asymmetrical Mapping Relationship

DCN/ICN-sponsored by U.S. Department of Defense (DOD).
Copyright © 2004 All Rights Reserved

This example reveals the more generic and low-level message construction characteristics of the UN/EDIFACT standard - a subtle but important difference, which often leads to one-to-many mapping situations. Notice that using the UN/EDIFACT standard requires two qualifier data elements associated with the date data element. The first qualifier data element is used to indicate the type of date (i.e., qualifier code value = "4" for Purchase Order). The second qualifier data element is used to specify the format for the date (i.e., qualifier code value = "101" for the YYMMDD arrangement).

Although not evident from this example, it is important to mention that the data element attributes, (e.g., the data element types, character lengths, length limits, looping limits, and mandatory/conditional status) are often not identical among respective data elements from each standard.

From the example, it appears that it would be exceedingly complex to map all the elements from the EDI purchase order transaction set directly to the UN/EDIFACT ORDERS message. This is because of the difficulty in maintaining all of the relationships (one-to-many, one-to-none, etc.) for all the elements being mapped, and because mapping is often obscured by the semantic inequalities resulting from contextual (location and sequence) differences between the two standards.