EDI Standards





ANSI ASC X12 In 1979, the American National Standards Institute (ANSI) chartered the Accredited Standards Committee (ASC) X12 to develop uniform standards for inter-industry electronic exchange of business transactions, namely electronic data interchange. ANSI X12 was originally conceived to support companies across different industry sectors in North America however today there are more than 300,000 companies worldwide using X12 EDI standards in daily business transactions. ASC X12 also contributes to UN/EDIFACT messages that are used widely outside of the United States.
  • Further information about ANSI X12 can be found here »


EANCOM This standard was originally conceived in 1987 by the EAN General Assembly and was to be developed on the then emerging international UN/EDIFACT standard. The EANCOM messages, maintained by GS1, are more detailed in nature compared to the TRADACOMS message set. EANCOM was originally developed for the retail sector and has subsequently grown to become the most widely used UN/EDIFACT subset and is now found in a variety of other industry sectors such as healthcare, construction and publishing.

GS1 EANCOM® is a GS1 subset of the UN/EDIFACT standard (United Nations Electronic Data Interchange for Administration, Commerce and Transport). It contains only the message elements required by business applications and mandated by the syntax. Omitted are optional elements not relevant for GS1 users.

GS1 EANCOM brings together the GS1 standards that identify trade items with logistics units and Global Location Numbers (GLNs) that show information about your trading partners
  • Further information about EANCOM can be found here »


UN/EDIFACT United Nations/Electronic Data Interchange for Administration, Commerce and Transport is the international standard that was developed by the United Nations. The work of maintenance and further development of this standard is done through the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) under the UN Economic Commission for Europe. The EDIFACT standard provides a set of syntax rules to structure, an interactive exchange protocol and provides a set of standard messages which allow multi-country and multi-industry exchange of electronic business documents. EDIFACT is widely used across Europe, mainly due to the fact that many companies adopted it very early on. EDIFACT has seen some adoption in the Asia Pacific region, however, there are currently more XML-based standards being used in this particular region today.
  • Further information about EDIFACT can be found here »


HIPAA The Health Insurance Portability and Accountability Act was enacted by the U.S congress in 1996. A key component of HIPAA is the establishment of national standards for electronic health care transactions and national identifiers for providers, health insurance plans and employers. The standards are meant to improve the efficiency and effectiveness of the North American health care system by encouraging the widespread use of EDI in the U.S health care system. The HIPAA EDI transaction sets are based on X12 and the key message types are described below.
  • Further information about HIPAA can be found here »


ODETTE The Organization for Data Exchange by Tele Transmission in Europe is a group that represents the interests of the automotive industry in Europe. They are the equivalent of the Automotive Industry Action Group (AIAG) in North America. The organization develops tools and recommendations that improve the flow of goods, services product data and business information across the whole automotive value chain. ODETTE has been responsible for developing communications standards such as OFTP and OFTP2.0, constant improvement processes such as Materials Management Operations Guideline / Logistics Evaluation (MMOG/LE) and automotive-specific document standards as defined via the link below.
  • Further information about ODETTE can be found here »


RosettaNet This consists of a consortium of major computer, consumer electronics, semi-conductor manufacturers, telecommunications and logistics companies working together to create and implement industry-wide, open e-business process standards. These standards form a common e-business language, aligning processes between supply chain partners on a global basis. The RosettaNet document standard is based on XML and defines message guidelines, business processes interface and implementation frameworks for interactions between companies. Using RosettaNet Partner Interface Processes (PIPs), business partners of all sizes can connect electronically to process transactions and move information within their extended supply chains. Further information about RosettaNet PIP documents can be found from the link below.
  • Further information about RosettaNet can be found here »


SWIFT The Society of Worldwide Interbank Financial Telecommunication was formed in 1973 and is headquartered in Brussels. SWIFT operates a worldwide financial messaging network which exchanges messages between banks and financial institutions. SWIFT also markets software and services to financial institutions, much of it for use on the SWIFTNet Network. SWIFTNet is the infrastructure used to exchange these documents and FIN, InterAct and FileAct are used to encode the SWIFT documents for transmission. The majority of interbank messages use the SWIFT network. As of November 2008, SWIFT linked 8740 financial institutions across 209 countries. The SWIFT document standard is split into four areas, Payments, Trade Services, Securities and Trading.
  • Further information about SWIFT can be found here »


Tradacoms

From 1 July 2017 GS1 UK will no longer provide any support for the TRADACOMS EDI messaging standard



This is an early standard for EDI and was primarily used in the UK retail sector. It was originally introduced in 1982 as an implementation of the UN/GTDI syntax, one of the precursors of EDIFACT, and was maintained and extended by the UK Article Numbering Association, now called GS1 UK.

TRADACOMS was first developed back in the early 1980s as an EDI (Electronic Data Interchange) standard for retailers and wholesalers to process orders and invoices with their mainly UK-based suppliers. Since 1998 existing users have only received basic TRADACOMS support from GS1 UK for current applications and there has been no development of any new message types.

During this time, new EDI users have been advised to adopt the EANCOM standard with their trading partners wherever possible. EANCOM is the most widely used GS1 global standard for EDI. GS1 XML is another alternative that is used globally. Both are actively developed and supported in response to our members’ needs.

Although GS1 UK has provided some level of support for the TRADACOMS standard since 1998, it has been agreed that considering the increasing unsuitability of TRADACOMS for today’s trading, and the fact that it is not a GS1 global standard for EDI, GS1 UK will, as of 1 July 2017, only support the recognised GS1 EDI standards EANCOM, GS1 XML and the GS1 UN/CEFACT XML profile.

VDA This organization develops standards and best practices to serve the needs of companies within the German automotive industry. The VDA has developed over thirty messages to meet the need of companies such as VW, Audi, Bosch, Continental and Daimler AG. Further information about these messages can be found via the link below.
  • Further information about VDA can be found here »


PEPPOL PEPPOL is a set of artifacts and specifications enabling cross-border eProcurement. The use of PEPPOL is governed by a multi-lateral agreement structure which is owned and maintained by OpenPEPPOL. PEPPOL is not an e-Procurement platform but instead provides a set of technical specifications that can be implemented in existing eProcurement solutions and eBusiness exchange services to make them interoperable between disparate systems across Europe.

PEPPOL enables trading partners to exchange standards-based electronic documents over the PEPPOL network (based on a 4-corner model). These documents include e-Orders, e-Advance Shipping Notes, eInvoices, eCatalogues, Message Level Responses, etc.

PEPPOL Access Points connect users to the PEPPOL network and exchange electronic documents based on the PEPPOL specifications. Buyers and suppliers are free to choose their preferred single Access Point provider to connect to all PEPPOL participants already on the network. (‘Connect once, connect to all’).
  • Further information about PEPPOL can be found here »


OAGIS Founded in 1994, The Open Applications Group Inc. (the OAGi) is organized to promote business process interoperability for both inter & intra enterprise business processes and to encourage the creation of and/or create and endorse one or more standards to assist organizations in achieving connectivity and multiple-source integration of inter & intra enterprise business processes.

The Open Applications Group Interface Specification (OAGIS) is a widely accepted standard within the supply chain domain which specifies a standard way of passing data in and out of applications using an XML format.  Under the OAGIS standard, related information is bundled into a structure called a Business Object Document (BOD). There are over 120 BODs published.

The Open Applications Group is a non-profit consortium focusing on best practices and process based XML content for eBusiness and Application Integration.  Major vendors of ERP software and some large users of such software are among the members of OAGIS.
  • Further information about OAGIS can be found here »


EDIGAS In 1983 Distrigas in Belgium, Gaz de France in France, Ruhrgas in Germany and Gasunie in the Netherlands signed a document on a standard way of sending and receiving operational data and messages between the dispatching centres. This document was called the GASNET-Protocol. Today, beside the four “owners” of the protocol, another 10 companies, national and international, are using this protocol for their data exchange.

At the end of 1995 one of the users, Statoil Norway, who experienced first problems raised by a lot of messages to handle, initiated to look for a more international standard for communication.

In May 1996 a Workgroup was formed, in which Statoil and each of the owners was represented by one member. The first goal of this Workgroup was to make an inventory of all the messages used, to gather them and to choose an international EDI standard.

The result of this inventory and bundling are the so called message-groups. Each message-group being a collection of a number of messages of the same type, e.g. all the request messages. For each message-group a matrix was developed containing all the fields of the messages in that group.

This matrix then made it possible to define all the messages within a message-group.

At the end of 1996 EDIFACT was chosen as the international standard to be used in the future. The Workgroup, in the meantime also joined by SNAM in Italy, selected EDS as an EDI consultant to provide support in its task to migrate the telex-based messages into EDI messages.

Currently the messages have been defined and the Workgroup members have started to use them for their daily operational requirements. testing and implementation phase.

Other companies have also expressed their intention to implement the standard for their business requirements.

  • Further information about EDIGAS can be found here »


HL7 Founded in 1987, Health Level Seven International (HL7) is a not-for-profit, ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. HL7 is supported by more than 1,600 members from over 50 countries, including 500+ corporate members representing healthcare providers, government stakeholders, payers, pharmaceutical companies, vendors/suppliers, and consulting firms. Watch a quick overview of Why HL7? Learn more about HL7 by viewing the Introduction to HL7
  • Further information about HL7 can be found here »


IATA Cargo Cargo-IMP Standard-  The predessor standard by IATA to the Cargo-XML standard and used for specifications regarding space allocation, air waybill, flight manifest, accounting, status, discrepancy, embargo, customs, CASS billing, dangerous goods, allotments, and surface transportation. IATA stopped supporting this standard in 2014 but still widely used. Cargo-XML Standards- The IATA Cargo-XML messaging is emerging as a preferred standard for the electronic communication between airlines and other air cargo stakeholders such as shippers, freight forwarders, ground-handling agents, and regulators, as well as customs and security agencies. This new standard is based on multimodal and cross-border messaging.
  • Further information about IATA can be found here »


FHIR The FHIR (Fast Healthcare Interoperability Resources) Specification is a standard for exchanging healthcare information electronically. Healthcare records are increasingly becoming digitized. As patients move around the healthcare ecosystem, their electronic health records must be available, discoverable, and understandable. Further, to support automated clinical decision support and other machine-based processing, the data must also be structured and standardized. (See Coming digital challenges in healthcare)

HL7  has been addressing these challenges by producing healthcare data exchange and information modeling standards for over 20 years. FHIR is a new specification based on emerging industry approaches, but informed by years of lessons around requirements, successes and challenges gained through defining and implementing HL7 v2 HL7 v3  and the RIM, and CDA . FHIR can be used as a stand-alone data exchange standard, but can and will also be used in partnership with existing widely used standards. (See Comparing FHIR to other HL7 standards)

FHIR aims to simplify implementation without sacrificing information integrity. It leverages existing logical and theoretical models to provide a consistent, easy to implement, and rigorous mechanism for exchanging data between healthcare applications. FHIR has built-in mechanisms for traceability to the HL7 RIM and other important content models. This ensures alignment to HL7’s previously defined patterns and best practices without requiring the implementer to have intimate knowledge of the RIM or any HL7 v3  derivations. (See Comparing FHIR to other HL7 standards)
  • Further information about FHIR can be found here




Protocols

EDIINT AS1 (EDI over the Internet – Applicability Statement 1)
  • The Applicability Statement (AS1). Also Known as EDIINT AS1. A protocol developed by the IETF to implement secure and reliable messaging over SMTP and S/MIME. It was the first AS protocol to be developed and uses signing, encryption and MDN conventions. (MDN refers to Message Disposition Notifications or the ability to provide “Return Receipts”). As with any AS file transfer, AS1 file transfers typically require both sides of the exchange to trade SSL certificates and specific business partner names before any transfers can take place.
EDIINT AS2 (EDI over the Internet – Applicability Statement 2) The Applicability Statement (AS2). Also Known as EDIINT AS2. A protocol developed by the IETF to implement secure and reliable messaging over HTTP. Allows data to be sent over the Internet using the HTTP protocol. AS2 uses the same signing, encryption, and MDN conventions used in the original AS1 protocol. AS2 messages are usually sent across the internet using the HTTP or HTTPS protocol. AS2 has been widely deployed as a point-to-point connectivity method. AS2 offers many advantages over standard HTTP, including increased verification, and security achieved through the use of receipts and digital signatures. AS2 transactions and acknowledgements also occur in real-time, increasing the efficiency of document exchanges. Walmart was one of the first companies to help drive the adoption of AS2 across the retail sector. How Does AS2 work? To establish an AS2 connection you need two computers, a server and a client. Both connect to the Internet via a point-to-point connection. In order to transmit the desired data, AS2 creates an envelope that enables secure transmission using digital certificates and encryption. How Is an AS2 MDN? A MDN (Message Disposition Notification) is an electronic acknowledgement of receipt that is sent to the sender via AS2 after an electronic message has been sent. This acknowledgement confirms that the message has been transmitted successfully. The MDN checks two things:
  1.  Whether the AS2 transfer was sucessfully completed
  2.  The message arrived at the desired recipient without change
The process of establishing an AS2 MDN connection is as follows:
  1.  The sender sends an encrypted EDI message with digital signature to the desired recipient
  2.  Transmission of the EDI message over the Internet via AS2
  3.  Message is decrypted by the recipient and the digital signature of the sender is verified
  4.  Recipient prepares the requested MDN and applies a digital signature. It is then sent back to the sender
  5.  Sender receives the MDN and verifies the digital signature of the recipient

What do you need for AS2?

  1.  AS2 Capable Software
  2.  AS2 identifier (AS2 Name) and one certificate per partner
  3.  Public keys of all certificates used by your AS2 partners
What are AS2 Certificates? As2 certificates enable the secure data exchange and security standards. Senders can generate and sign certificates, or preferably use certificates issued and verified by a trusted certificate authority.  There public certificates are exchanged in advance with the partner. Non-Repudiation of Origin (NRO) –  Non-repudiation is the assurance that someone cannot successfully deny the validity of something. If a trading partner has received a successful MDN, the sender cannot repudiate the fact they sent the As2 transaction. Non-Repudiation of Receipt (NRR) –  With sender non-repudiation, the originator of a data exchange is provided with a proof of receipt(POR), in the AS2 case a MDN which proves that the recipient received the data. EDIINT AS3 (EDI over the Internet – Applicability Statement 3) The Applicability Statement (AS3). Also Known as EDIINT AS3. The most recent protocol developed by the IETF to implement secure and reliable messaging over FTP. AS3 is based upon the secure version of the FTP protocol, rather than HTTP. AS3 transport is S/MIME over FTP and operates a client/server model like FTP, as opposed to the peer-to-peer approach used by AS2. AS3 also uses MDN’s (receipt notifications) like AS2. AS3 is a push/pull protocol and the client side AS3 does not require a listener to be always aware of inbound traffic (whereas AS2 always requires a persistent connection for the listener). AS3 may be especially well suited for banking and other industries where there are heavy investments in FTP scripting, applications and security. EDIINT AS4 (EDI over the Internet – Applicability Statement 4) Applicability Statement (AS4). Also Known as EDIINT AS4. Offers secure B2B document exchange using web services. AS4 offers secure B2B document exchange using web services and was developed by the sub-committee of the OASIS ebXML messaging services technical committee. AS4 is still in its draft definition format. The AS4 profile provides the market place with an entry level solution that allows companies to begin utilizing their internal SOA based platforms for external B2B messaging while at the same time taking on some of the more complicated aspects of web services. The European Aerospace industry is proposing to use AS4 as its communication standard for sending ebXML related B2B documents between business partners AS4 was developed by the sub-committee of the OASIS ebXML. SFTP Server SFTP (SSH File Transfer Protocol, also known as Secure FTP) is a popular method for securely transferring files over remote systems. SFTP was designed as an extension of the Secure Shell protocol (SSH) version 2.0 to enhance secure file transfer capabilities. … Ordinary FTP clients cannot be used with SFTP servers. SFTP runs over an SSH session, usually on TCP port 22. SFTP Client Software that initiates connections to sftp servers that initiate the “put” or “get” of data files via sftp. The SFTP client can run automatically on sftp infrastructure or initiated from software on an end users computer. ebXML Messaging Service (EBMS) The secure, reliable method of transmitting electronic data defined as part of the ebXML specifications. It can use a variety of low level transmission protocols including HTTP and SMTP. ebXML Messaging Service offers a secure and reliable SOAP/Web Services based packaging, routing and transport protocol as defined by the ebXML specifications. The ebMS is an open standard and as such is communication protocol neutral although the most common underlying protocols are HTTP and SMTP. ebMS essentially offers a way to exchange ebXML based B2B documents between different business applications using SOAP/Web services. SOAP Server (Simple Object Access Protocol) SOAP is a a lightweight XML based protocol for exchanging structured information in a de-centralized, distributed environment, defined by the W3C. SOAP Server is an infrastructure that can handle and support SOAP Messaging Protocol layer of a web services protocol stack for web services HTTP/HTTPS HTTP is a protocol used to request and transmit files, especially web pages and web page components, over the internet or other computer network. HTTPS is a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol to provide encryption and secure identification of the server. HTTPS connections are often used for payment type transactions across the internet and for the exchange of sensitive information between corporate business systems. REST (REpresentational State Protocol) An architectural style for providing standards and interoperability between computer systems on the web, making it easier for systems to communicate with each other. REST-compliant systems, often called RESTful systems, are characterized by how they are stateless and separate the concerns of client and server. A RESTFul API is an application program interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. A RESTful API — also referred to as a RESTful web service — is based on representational state transfer (REST) technology, an architectural style and approach to communications often used in web services development. FTP A standard method of transmitting files from one computer to another over the internet. File Transfer Protocol is a standard network protocol used to exchange and manipulate files over a TCP/IP based network such as the internet. FTP is built on a client-server architecture and utilizes separate control and data connections between the client and server applications. FTP is also often used as an application component to automatically transfer files for internal functions within programs. FTP can be used with user-based password authentication or with anonymous user access. FTPS is an extension of FTP which adds support for the Transport Layer Security (TLS) and the Secure Sockets Layer (SSL) cryptographic protocols. FTPS should not be confused with SFTP, an incompatible secure file transfer subsystem for the Secure Shell (SSH) protocol. It is also different from Secure FTP, the practice of tunneling FTP through an SSH connection SMTP Simple Mail Transfer Protocol. The protocol that is most commonly used for transferring email between servers over the internet. SMTP is not a secure protocol RNIF (RosettaNet Integration Framework) The RosettaNet Implementation Framework (RNIF) provides the packaging, routing, and transport of RosettaNet PIP messages and business signals. The RNIF provides implementation guidelines for creating interoperable software applications components that facilitate the execution of Partner Interface Processes (PIPs). MQTT (Message Queuing Telemetry Transport) One of the most commonly used protocols in IoT projects. It stands for Message Queuing Telemetry Transport. In addition, it is designed as a lightweight messaging protocol that uses publish/subscribe operations to exchange data between clients and the server JMS (Java Message Service) A messaging service based on API that provides the facility to create, send and read messages. It provides loosely coupled, reliable and asynchronous communication. Message Queueing The process of queue of messages sent between applications. It includes a sequence of work objects that are waiting to be processed. A message is the data transported between the sender and the receiver application; it’s essentially a byte array with some headers on top