What is a EDI Trading Partner Agreement?

What is a EDI Trading Partner Agreement?

You may be wondering "How the !#?@ do I even do this EDI stuff?". I know I had a similar vague understanding of what an EDI was when I was first gaining a familiarity with the technology. Luckily, an EDI Trading Partner Agreement contains everything you need to know to create and send documents electronically. You may not know how your document should be formatted, what the contents should be, or what means you will use to send it securely. But an EDI Trading Partner Agreement explains all of that in exact detail, so you can trade documents accurately, efficiently, and with protection from unauthorized access.

Seems simple enough, but we'll go into more detail just so you thoroughly understand.

Both the EDI standards and format used in a trading partner agreement are usually defined by one of two separate entities. The Accredited Standards Committee (ASC) handles the X12 standard, which is used in North America. In contrast, the United Nations/Electronic Data Interchange for Administration: Commerce and Transport governs the EDIFACT standard which is used in Asia and the European Union. These organizations maintain other standards than X12 and EDIFACT, including CICA standards and XML schemas, but the X12 and EDIFACT standards are what we will focus on here. These standards govern the formatting and content of the vast majority of the world's EDI documents. There are different transaction sets for every type of document imaginable. For example, you can send an invoice with an X12 810 transaction set, or you can send a health care claim with an EDIFACT IHCLME. It is important to note that there are different versions and releases of these transaction sets, which one you intend to use must be clarified when constructing a trading partner agreement. To make things simple, a mutually agreed upon standard is used in order to create consistently defined documents that can be understood by both humans and machines. It's important that you understand the standardization of EDI documents before we go further. 

1. 1. Message Format:

   
   
   The message format defines the segment structure format and syntax of electronic messages exchanged between trading partners. This includes specifying the number of data elements in a segment, and what delimiters should be used to separate elements within a segment. To specify the end of a segment, a special character is defined and must be used at the end of every segment. In the X12 standard, segments, the equivalent of a sentence in EDI are ended with an "~". While in an EDIFACT document a segment is ended with an " ' ". Think of these special characters as a period in an EDI sentence. This special set of rules for formatting data ensures interoperability and consistent readability between messages and the computer regardless of content, as long as the syntax and format specified in the standard is used. Think of the message format as the spaces, periods and words in a specific sentence, as we continue we will see just like in English, certain words can be exchanged given the right context (noun for noun, verb for verb) and the sentence will still be syntactically correct. Assuming all rules are followed.

   
   

   2. EDI Content Standards

2. EDI content standards govern the actual information and material of the EDI document. EDI content standards dictate the data that should be entered to each element, such as the receiving and sending party identification, the total in an invoice, and the destination in a shipping order, or the identity of a patient in a medical document. While the format dictates the spacing elements and ending characters, the content standards in contrast inform you as to what data to put inside of the document and where. To use a metaphor,  the color in the sentence "The house is blue" states the color of a house. The content standard would dictate: "The fourth word of the sentence defines the color of the house". That color could be any color imaginable, red, purple, gold, silver, green, orange, and it would make sense. Similarly in an EDI content standard the elements of the document will be defined. "The fourth element defines the color of the house". Or more likely in an EDI Document, "The fourth element defines the number of items in an order". 

   
   

   
   

   
   

   3. Transfer Protocol 

   
   

   Once you've established the format and content of the EDI document, the document is ready to be transferred. There are a variety of transfer protocols. The two main ways to transfer an EDI document are with an Applicability Statement Protocol (Mainly AS2), File Transfer Protocol (FTP). Secure File Transfer protocol (SFPT) is often preferred to FTP because at the name implies, it offers enhanced security. Respectively, AS2 transfers over Hypertext Transfer Protocol (HTTP), and most prefer Hypertext Transfer Protocol Secure (HTTPS) for it's enhanced security. We will go into more detail about security in just a bit. All of your trading partners must agree on a transfer protocol in your trading partner agreement. Both AS2 and SFTP servers can be enabled to complete functions like creation, deletion, sending, and receiving automatically with a program through an API. It is easy to be confused and think an API is a "third protocol", but what an API does is add programability to an SFTP server or a server that manages AS2 transactions. Hence, "Application Programing Interface". The application here is the server, and programming interface is generated by the code within the API. At the end of the day, all of these protocols and interfaces do one thing, manage EDI documents. If your trading partner is using an API, it's strongly suggested to create a solution or to modify an existing solution so that it can program against the API. One thing that should be just as important to you as the file being transferred, is the security of the transfer. Files can be intercepted by a third party in a process known as a "Man in the Middle Attack". This is when someone impersonates your trading partner, takes your files, reads them, then sends them to your trading partner, effectively tapping into your line of communication with both parties being none the wiser. While there are other types of attacks regarding transfer protocols, most of them boil down to various strategies of getting in the middle of the communication. To prevent these attacks, it's important to enable Transport Layer Security (TLS) when using AS2 (Also known as HTTPS or SSL), and Secure Shell (SSH) when using FTP. These protocols utilize the Diffie-Hellman algorithm to ensure end to end encryption, generating a shared key that is never exposed over the internet. Due to the fact the key is never transferred over the internet, there is no opportunity for a man in the middle to steal the key and decrypt the data. But that's not the only method TLS and SSH use. They also use certificates and digital signatures to identify the trading partners on first interaction, using a trusted third party authority to authenticate identity. Then, generate a pair of private and public keys to ensure security going forward. It's important to note that keys are the data needed to encrypt and decrypt files. With the public keys available to the public, anyone can encrypt a file and send it to the private key holder. However, only the private key holder can decrypt the file and see it. Meaning When transmitted the file is essentially hidden, while only the intended recipient can read it. This goes both ways.  Additionally data is often encrypted again or in conjunction with previous security protocols using Rivest-Shamir-Adleman encryption (RSA), Elliptic curve encryption (ECC), and AES. These are by no means the only encryption methods, just some of the most common. RSA and ECC encryption use a concept called modular arithmetic to say, spin a clock hour-hand a certain number of hours around a clock. The concept in it's most basic form presents the fact that, you can't know the original hour or how many times the clock hand has spun around the clock based on the hands final position on the clock. That is impossible. ECC does this but rather than a "clock" an elliptic curve is used as the reference object, due to the way a point moves on an elliptic curve is calculated it is also impossible to know how many movements have been performed to get to the point, or where the original position was. The value that gets you back to the original point is the "key", which decrypts the message. Elliptic curve movement is less resource intensive to calculate than the "movement" on RSA encryption. That makes ECC more efficient than RSA, but as the newest encryption method it has a shorter track record and is not as widely adopted. AES takes data and puts it in a grid and jumbles it about so that it is impossible to read. All of these methods of encryption can be applied to the EDI Document, or to encrypt the keys or "passwords" to access the files in the first place. Despite how foolproof these methods are, they are technically hackable. So you must make a decision as to if you want your RSA, ECC, and AES encryption to use more resources and be more secure, or if you want it to be less secure but take up fewer resources. Even the lowest settings for RSA, ECC, and AES encryption are incredibly difficult to crack, but it is smart to use the highest settings your resource pool allows for in order to get the best security. When connecting over HTTPS or SFTP, correctly configured machines will go through a process of identifying what security will be used mutually to communicate. There is something known as a cipher which determines this value, and in some software like webpages there is a cipher string that details every single encryption method used in order to send a file.  Look into that if you're curious as to exactly what security methods are being used by a software that communicates over the internet. Whew. That was a lot. Hopefully now you understand the important topic of what EDI transfer protocols are used to transfer EDI Documents and how encryption and cybersecurity is used to prevent would be attackers from getting your data!

3. 
   

   You did it!

4. You now understand the technical aspects of a TPA, with this information you now have a firm grasp the theory behind the technical aspects of an EDI Trading Partner Agreement. When this theory is applied to practice, you will be successfully and securely transmiting EDI documents!  

   
   

   That's not all...