1. Name of Standard. Electronic Data Interchange (EDI) (FIPS PUB 161-2).
2. Category of Standard. Electronic Data Interchange.
3.1. Definition and Use of EDI. EDI is the computer-to-computer interchange of strictly formatted messages that represent documents other than monetary instruments. EDI implies a sequence of messages between two parties, either of whom may serve as originator or recipient. The formatted data representing the documents may be transmitted from originator to recipient via telecommunications or physically transported on electronic storage media.
In EDI, the usual processing of received messages is by computer only. Human intervention in the processing of a received message is typically intended only for error conditions, for quality review, and for special situations. For example, the transmission of binary or textual data is not EDI as defined here unless the data are treated as one or more data elements of an EDI message and are not normally intended for human interpretation as part of on-line data processing.
An example of EDI is a set of interchanges between a buyer and a seller. Messages from buyer to seller could include, for example, request for quotation (RFQ), purchase order, receiving advice and payment advice; messages from seller to buyer could include, simi- larly, bid in response to RFQ, purchase order acknowledgment, shipping notice and invoice. These messages may simply provide information, e.g., receiving advice or shipping notice, or they may include data that may be interpreted as a legally binding obligation, e.g., bid in response to RFQ or purchase order.
EDI is being used also for an increasingly diverse set of concerns, for example, for interchanges between healthcare providers and insurers, for travel and hotel bookings, for education administration, and for government regulatory, statistical and tax reporting.
3.2. Standards Required for EDI. From the point of view of the standards needed, EDI may be defined as an interchange between computers of a sequence of standardized messages taken from a predetermined set of message types. Each message is composed, according to a standardized syntax, of a sequence of standardized data elements. It is the standardization of message formats using a standard syntax, and the standardization of data elements within the messages, that makes possible the assembling, disassembling, and processing of the messages by computer.
Implementation of EDI requires the use of a family of interrelated standards. Standards are required for, at minimum: (a) the syntax used to compose the messages and separate the various parts of a message, (b) types and definitions of application data elements, most of variable length, (c) the message types, defined by the identification and sequence of data elements forming each message, and (d) the definitions and sequence of control data elements in message headers and trailers.
Additional standards may define: (e) a set of short sequences of data elements called data segments, (f) the manner in which more than one message may be included in a single transmission, and (g) the manner of adding protective measures for integrity, confidentiality, and authentication into transmitted messages.
3.3. Limited Coverage of this Standard. This FIPS covers only EDI. It does not cover other forms of electronic interchange, for example, systems of interchange that do not consist of messages taken from a predetermined set. Additionally, an interchange application including only one or two predetermined message types using only fixed-length data elements is excluded from coverage of this FIPS. This FIPS also is not intended to cover transmissions from medical, laboratory, or environment-sensing instrumentation.
3.4. The Long-Range Goal for EDI Standards. There are several different EDI standards in use today, but the achievement of a single universally-used family of EDI standards is a long-range goal. A single universally-used family of standards would make use of EDI more efficient and minimize aggregate costs of use. Specifically, it would (a) minimize needs for training of personnel in use and maintenance of EDI standards, (b) eliminate duplication of functionality and the costs of achieving that duplication now existing in different systems of standards, (c) minimize requirements for different kinds of translation software, and (d) allow for a universal set of data elements that would ease the flow of data among different but interconnected applications, and thereby maximize useful information interchange.
This FIPS PUB recognizes the reality that some families of EDI standards were developed to provide solutions to immediate needs, and that inclusion of the goal of universality in their development would have unacceptably delayed their availability. However, a future is envisioned in which the benefits of universality outweigh the sunk costs in specialized solutions, leading first to cooperation among standards developers, then to harmonization of standards, and eventually to a single universally accepted family of EDI standards.
3.5. Adoption of Specific Families of Standards. This FIPS PUB adopts, with specific conditions specified below, the families of EDI standards known as X12, UN/EDIFACT and HL7. This FIPS PUB does not mandate the implementation of EDI systems within the Federal Government; rather it requires the use of the identified families of standards with specified constraints when Federal departments or agencies implement EDI systems.
The UN/EDIFACT standards may be used for any application, domestic or international. The X12 standards may be used for any domestic application. The HL7 standards are adopted as an alternative for certain healthcare applications, specifically for transmission of patient records and of clinical, epidemiological, and regulatory data. HL7 standards are not to be used for healthcare insurance administrative applications, such as for enrollments, claims, and claim payments, or for any aspect of the Government procurement cycle, such as for registration of vendors, RFQ, purchase order, shipping notice, or payment advice.
The cross-use of data elements is encouraged. A data element received through one system of EDI standards, or through a non-EDI interchange, may be re-transmitted as a data element in any of the approved systems of EDI standards.
The adopted standards were developed by the following organizations: the X12 standards by Accredited Standards Committee X12 on Electronic Data Interchange (ASC X12), accredited by the American National Standards Institute (ANSI); the HL7 standards by Health Level Seven, Inc., an ANSI-accredited standards developer; and the UN/EDIFACT standards by the United Nations (UN) Economic Commission for Europe - Working Party (Four) on Facilitation of International Trade Procedures (UN/ECE/WP.4). Technical input from the United States in the development of UN/EDIFACT at the UN is through the Pan American EDIFACT Board (PAEB). The PAEB is separate from ASC X12, and it serves as the coordinating body for national standards organizations of North, Central, and South America.
3.6. Status of this FIPS PUB Revision. FIPS PUB 161-2 supersedes FIPS PUB 161-1 in its entirety. FIPS PUB 161-2 contains editorial changes, updated references to documents and organizations, and new guidance to agencies on the selection of national and international standards and implementation conventions. This guidance is based on recent voluntary industry standards activities and on the Federal Government initiative that commenced with the Presidential Memorandum of October 26, 1993 entitled "Streamlining Procurement Through Electronic Commerce."
4. Approving Authority. Secretary of Commerce.
5. Maintenance Agency. U.S. Department of Commerce, National Institute of Standards and Technology (NIST), Computer Systems Laboratory.
6. Cross Index and Related Documents.
6.1. Cross Index.
7. Objectives. The primary objectives of this standard are:
8.1. Conditions of Application. EDI may be employed with any type of operational data representable as a sequence of data elements that is needed to be transmitted or received on a repetitive basis by a Federal agency in the course of its activities. This standard is applicable to the interchange of such data on a particular subject within a Federal agency, or between a Federal agency and another organization (which may be another Federal agency), if (1) the data are to be transmitted electronically or physically transported between computers using EDI, and (2) the necessary standard messages meeting the data requirements of the Federal agency for the subject of the interchange have been developed and approved, and are acceptable for use under the conditions set forth in this FIPS PUB.
8.2. Subject Matter. Examples of applications (not necessarily the subject of current standards) are:
9.1. Federal EDI Standards Management Coordinating Committee. There is established a Federal EDI Standards Management Coordinating Committee (FESMCC). The FESMCC is established to support the goal of a single face for the Federal Government to its trading partners in the use of EDI.
9.1.1. A responsibility of the FESMCC is the selection of implementation conventions (ICs) to be used with EDI interchanges between the Federal Government and its trading partners. EDI messages (also called transaction sets) are approved by standards committees with allowances for format options, in order to widen the applicability of the standards to different uses. The purpose of ICs is to select specific options in EDI standards so that interchanges are completely determined in format in advance of use.
9.1.2. The basic functions of the FESMCC are:
9.1.4. The FESMCC shall establish a secretariat in order to maintain an official registry of approved and draft ICs, provide controlled access to the registry including electronic remote access capability, provide a point of contact for publicizing draft ICs and receiving comments on them, provide a single point for submission of work requests to standards bodies, and for related functions.
9.1.5. The FESMCC shall establish a charter and operating rules to assist it in carrying out its identified functions.
9.2. Functional Work Groups
9.2.1. The FESMCC may establish Functional Work Groups (FWGs) to consider and recommend ICs in subject areas. Examples of subject areas are procurement, finance, logistics, and healthcare. Requirements for voting membership shall be established by the FESMCC under its charter and operating rules. The voting members shall elect a chair.
9.2.2. Each FWG shall recommend, to the full FESMCC, ICs that it has developed and approved as meeting Federal Government and trading partner business requirements. FWGs should consult with appropriate industry groups in the development of ICs.
9.3. Agency Responsibilities
9.3.1. Agencies shall register ICs that they are using with the FESMCC secretariat.
9.3.2. Agencies using X12, UN/EDIFACT, or HL7 versions and releases for which ICs have been established by the FESMCC shall adopt those ICs. If an IC does not meet business needs, requirements shall be submitted to the FESMCC. ICs shall be classified as Implementer's Agreements pursuant to this FIPS PUB, but are not themselves FIPS PUBs.
9.3.3. Agencies using or planning to use EDI shall designate representatives to the FESMCC and each relevant FWG.
9.3.4. Agencies requiring new EDI standards or changes to existing EDI standards to meet their business needs shall submit their requirements to the appropriate standards bodies and shall simultaneously submit their requirements to the FESMCC and relevant FWGs for coordination. Procedures and forms for submission of new requirements through ASC X12 are specified in Standing Document (SD) 2, Operations Manual, and SD6, Operations Manual for UN/EDIFACT Standards. These manuals are available from Data Interchange Standards Association, Inc. (DISA, Inc.). Procedures and forms for submission of new requirements for UN/EDIFACT standards directly through the PAEB are also available from DISA, Inc. HL7 operating procedures are specified in its bylaws, available from Health Level Seven, Inc.
10. Specifications. Documents are available that define the X12, UN/EDIFACT, and HL7 standards and provide information about the standards organizations and their standards development processes. Developments are continuing in each of these families of standards.
10.1. Source of Documents. Documents concerning both the X12 and UN/EDIFACT families of standards are available from DISA, Inc. or from its named contractor. DISA, Inc. serves as the secretariat for ASC X12 and the PAEB and may be contacted at:
Data Interchange Standards Association, Inc.
1800 Diagonal Road - Suite 200
Alexandria, VA 22314-2852
Phone: (703) 548-7005
A list of available standards publications, as well as descriptive material, prices and ordering procedures, may be found in the most recent DISA, Inc. Publications Catalog.
HL7 documents are available from:
Health Level Seven, Inc.
3300 Washtenaw Avenue, Suite 227
Ann Arbor, MI 48104
Phone: (313) 677-7777
10.2. ASC X12 Documents. X12 standards are published periodically with revisions and updates, and standards included in a publication may have one of two possible statuses:
11.1. Schedule for Adoption. FIPS PUB 161 was effective on September 30, 1991. Federal agencies that are not using EDI for subject matter for which X12, UN/EDIFACT, and HL7 standards have been approved and issued shall utilize only those standards in EDI systems that they procure or develop, subject to the qualifications of Subsections 3.5, 11.3, 11.4 and 11.5. Agencies that are using those standards shall continue to do so, subject to the same qualifications. Agencies that were using other standards on or after September 30, 1991 shall be governed by Subsection 11.6.
11.2. Acceptance of UN/EDIFACT by ASC X12. In January 1995,
ASC X12, by a membership vote, approved the ASC X12 Plan For
To And Administrative Alignment With UN/EDIFACT.
This plan was modified at the February 1995 plenary meeting of ASC
X12. Key features of the modified Alignment Plan are:
11.3.1. Different families of EDI standards are distinct, although performing similar functions; the existence of one does not preclude the others. Equivalent functionality may be obtained in any system by the addition, if required, of new or revised message formats and data elements. Software that assembles and disassembles messages and transaction sets, called translation software, is widely available, often for more than one system in the same package. In selecting a family of standards for domestic applications, agencies should attempt to maximize Government economy and efficiency and to minimize the costs imposed on U.S. businesses.
11.3.2. For any domestic application with a non-Government partner, and for related intra-Government applications, selection of a family of standards shall take into account the prevailing family used in the industry of the interchange partners for the application. However, UN/EDIFACT standards shall be employed for new or significantly upgraded interchanges in the absence of demonstrably higher costs, or at the request of interchange partners providing a significant fraction of interchange traffic. Continued long-term use and maintenance of more than one family of standards is unacceptably inefficient.
11.3.3. For international applications except as specified in Subsection 11.3.4, planning for migration to the UN/EDIFACT family of standards shall commence at this time if that family is not currently being used. A timetable for conversion to UN/EDIFACT of existing international implementations shall be set as applicable standards and software become available. New or signifcantly upgraded interchanges shall employ only standards using UN/ EDIFACT.
11.3.4. The HL7 family of standards may be used for international applications in the fields of public health and health regulatory information, pursuant to agreements of international organizations whose membership includes representation of national or multi-national governmental health agencies. However, users shall coordinate with the developers of UN/EDIFACT, in order to prevent duplication of effort, provide for cross-use of data elements, and provide a path for harmonization and eventual migration or coalescence.
11.4. Use of Category (1) Standards. UN/EDIFACT Status 1 standards, X12 DSTUs, and HL7 standards not yet approved by ANSI are defined as Category (1) standards. UN/EDIFACT Status 2 standards and ANSs submitted by ASC X12 and HL7 are defined as Category (2) standards. Federal agencies shall use only Category (1) or Category (2) standards for EDI implementations. Industry practice is to use Category (1) standards; these represent the latest consensus and are available sooner than the corresponding full standards of Category (2). Consequently, Category (1) standards are preferred, but not mandated at this time. Note: there is a possibility that UN/EDIFACT Status 2 standards will be eliminated by UN/ECE/WP.4. In that case, UN/EDIFACT Status 1 standards would be required when UN/EDIFACT is implemented.
11.5. Continued Use of Existing Approved Implementations. An existing implementation of any version of an approved standard specified in Subsections 3.5, 11.3 and 11.4 may continue to be used as long as it continues to meet the business needs of the using agency and its interchange partners. Significant upgrades of existing implementations shall be to versions and releases for which ICs have been approved by the FESMCC, if any are available.
11.6. Continued Use of Other EDI Standards. Under the initial issue of this FIPS, Federal agencies using "industry-specific" EDI standards were permitted to use those standards for five years from September 30, 1991, i.e., until September 30, 1996. Agencies were permitted to use "industry-specific" EDI standards beyond five years only if no equivalent X12 or UN/EDIFACT standards, as appropriate, were approved and issued by September 30, 1995. If an equivalent and appropriate standard were issued after the latter date, agencies were given one year to convert. These provisions remain in effect for all application areas except healthcare.
For healthcare applications, agencies may use EDI standards other than UN/EDIFACT, X12, or HL7 through September 30, 1997. Other standards may be used beyond that date only if no functionally equivalent standards that meet the conditions of use specified in Subsections 3.5, 11.3 and 11.4 are approved and issued by September 30, 1996. If a Category (1) standard meeting business requirements and allowable conditions of use is first issued after the latter date, agencies have one year to convert following the issuance of the release containing the implementable standard.
Requirements for submission of proposed new or revised standards are specified in Subsection 9.3.4.
11.7. Security and Authentication. Agencies shall employ risk management techniques to determine the appropriate mix of security controls needed to protect specific data and systems. The selection of controls shall take into account procedures required under applicable laws and regulations.
Optional tools and techniques for implementation of security and authentication may be provided by ASC X12 and UN/ECE/WP.4 for use in connection with their respective families of standards. Agencies may utilize these tools and techniques, and/or they may utilize other methods in systems supporting the EDI data interchange. Methods and procedures implemented shall be consistent with applicable FIPS PUBS and guidance documents issued by NIST.
12. Waivers. Under certain exceptional circumstances, the heads of Federal departments and agencies may approve waivers to Federal Information Processing Standards (FIPS). The head of such agency may redelegate such authority only to a senior official designated pursuant to Section 3506(a) of Title 44, U.S. Code.
Waivers shall be granted only when:
In addition, notice of each waiver granted and each delegation of authority to approve waivers shall be sent promptly to the Committee on Government Reform and Oversight of the House of Representatives and the Committee on Governmental Affairs of the Senate and shall be published promptly in the Federal Register.
When the determination on a waiver applies to the procurement of equipment and/or services, a notice of the waiver determination must be published in the Commerce Business Daily as part of the notice of solicitation for offers of an acquisition or, if the waiver determination is made after that notice is published, by amendment to such notice.
A copy of the waiver, any supporting documents, the document approving the waiver and any supporting and accompanying documents, with such deletions as the agency is authorized and decides to make under 5 U.S.C. Sec. 552(b), shall be part of the procurement documentation and retained by the agency.
13. Where to Obtain Copies of NIST Publications. Copies of this
publication and NIST publications referenced in Section 6 are for
sale by the National Technical Information Service (NTIS), U.S.
Department of Commerce, Springfield, VA 22161; phone (703) 487-
4650. When ordering this publication, refer to Federal Information
Processing Standards Publication 161-2 (FIPSPUB161-2), and title.
Payment may be made by check, money order, or NTIS deposit account.
FIPS PUB 161-2
PROCESSING STANDARDS PUBLICATION
1996 April 29
U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology