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

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

EDIFACT Headers

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

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:

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.