Introduction To EDI - EDI Defined Electronic data interchange (EDI) is a business-to-business, computer-to-computer exchange of transaction information, such as Health

Care Claims, Payments, and Benefit Enrollment transactions. Each of these transaction types has a specifically defined, computer-readable format assigned to it. This is referred to as a transaction set, and more than 300 such sets currently exist. For the health care industry there are specifically 9 EDI transactions currently being used: 270 271 276 277 278 837 837 837 835 820 834 Health Care Eligibility Benefit Inquiry and Response - Health Care Eligibility Response - Health Care Claim Status Request - Health Care Claim Status Response - Health Care Services Review - Request for Review and Response - Health Care Claim Institutional - Health Care Claim Dental - Health Care Claim Professional - Health Care Claim Payment / Advice - Payroll Deducted and Other Group Premium Payment for Insurance Products - Benefit Enrollment and Maintenance

EDI has been around for many decades and is a mature technology that is finding everincreasing use as businesses seek ways to streamline their workflow, cut their costs of doing business, and process huge volumes of transaction information on a regional, national, and sometimes global basis. EDI documents are exchanged with other businesses, referred to as trading partners. A trading partner is any outside organization that a company does business with, such as: physicians, hospitals and other medical facilities or suppliers, dentists, and pharmacies. The structure of EDI documents is governed by standards development committees such as ANSI ASC X12 and UN/EDIFACT. We will discuss these organizations in the EDI standards portion of this course. EDI data is designed for efficient computer processing. In its raw form, EDI data is very difficult to read manually. When EDI data needs to be human-readable, we make use of EDI translators, which are software packages that read the EDI data and can, present it in a form and format thats more easily human-readable. Well discuss translators in a later section. EDI data can be transmitted through any communications protocol agreed upon by the trading partners such as Value Added Networks, SFTP, SCP, HTTPS and etc. The EDI Communication options are an extremely important component of the EDI setup and will be discussed in details in the EDI Communication Methods section of the course. EDI is a key business tool in todays highly competitive environment. There are many benefits to be derived from EDI, from cost savings and better workflow to improved customer service and enhanced competitiveness.

Achieving these benefits, however, depends on careful planning and correct implementation of a comprehensive EDI strategy. Well discuss EDI implementation planning in detail in the Strategies for Successful Implementation section of this course. What is NOT EDI In order to understand what EDI is, its important to understand what EDI isnt. EDI is not just a regular method of sending documents electronically via EMAIL or the WEB. EDI documents are standardized (according to a standards development committee) in a machine-readable format intended to be processed by an EDI Translator. For example, emailing a Health Care Claim created in Microsoft Excel or Adobe Acrobat to a payer can not be categorized as an EDI document transfer, because such process is not standardized. The caveat here is that EDI is used for computer-to-computer exchange of transactions without any human involvement. Sending a proprietary-format flat file via FTP to a payer is not standards based EDI. The essence of EDI is the standardized format created and agreed upon by a standards governing body. This is what makes any EDI file readable by any computer thats processing EDI. Standardization is the heart and soul of EDI, and the key to its ability and versatility. EDI is not associated with the use of tools such as diskette transfers, E-mail, tapes, fax, internal customized file transfers, or voice-response systems. EDI is not a programming language or an IT tool. EDI is an industry with specific methods and protocols that are constantly evolving to better serve all users. EDI is not limited to large enterprise organizations like Hospitals and Banks EDI is accessible and is widely used by small and medium-sized organizations that benefit from the cost savings and workflow advantages of EDI. EDI is not just a technical function, and seeing it as that is one of the most frequent and costly EDI implementation mistakes. EDI is about business-to-business interaction and relationships. EDI is about business processes and functionality, and it needs to be understood as that and overseen by executives and managers who fully understand the true role of EDI. Finally, EDI is not new. EDI usage and standards development have been growing and maturing for about 30 years now. Why Standards Exist? Standards are what set EDI apart from other electronic methods of transferring data. Before getting into details about administration of EDI standards such as ANSI ASC X12 or UN/EDIFACT, it is important to understand why standards are used. Organizations such as BlueCross and Aetna deal with thousands of health care providers. Imagine the inefficiencies and challenges these organizations would face if each provider sent a proprietary file. On the provider side, if a provider is billing BlueCross and Aetna and 10 other trading partners, imagine the inefficiencies and challenges the providers

would face if they had to accommodate a separate proprietary custom file for each of their trading partners. This would be a costly administrative nightmare. EDI standards are built on the concept of making electronic business documents uniform, without regard to country or place of origin or industry. EDI standards ensure document integrity. The standards provide the controls needed to track the exchanged electronic business documents and confirm that all the data that was sent, was in fact, received and processed by the trading partner. The use of published EDI standards enhances the overall usefulness of the inter-company business transactions. Millions of lines of codes have been written to produce multiple commercial products that translate EDI data according to standards. Hundreds of leaders from different industries have met for more than 30 years to develop and grow EDI standards worldwide. Brief History of EDI & Standards Bodies The roots of EDI can be traced back 19th century use of telegraph for communicating business transactions. There were many experiments and events that eventually lead to the EDI usage that exists today. For example, in the 1950s and 1960s computer paper punch cards were converted to punch tape and transmitted through Telex networks to a trading partner. The trading partner would receive the Telex punch tape and convert it back to a punch card for input into the computer. Some EDI transaction sets that are still in use today were created in 1975 when the TDCC (Transportation Data Coordinating Committee) gathered representatives from the transportation industry to create a first set of formal EDI transaction standards. These transaction sets were primarily created for the transportation industry. TDCC is often referred to as the original publicly published EDI standard. The work did not stop there. The manufacturing, retail and financial industries were all using proprietary means for exchanging business documents electronically; as this usage grew the need for a generic set of standards for transactions such as purchase orders, invoices, and payments became more and more evident. ASC X12 Standards In 1979, the American National Standards Institute (ANSI founded in 1918 to oversee standards development in the United States) chartered the X12 Accredited Standards Committee (ASC X12) to develop national EDI standards. This began to bring order out of disorder, and uniformity out of what had been Balkanization. In the late 1980s, most standards body groups in North America were transitioned to the ASC X12 standards body. In 1989 the TDCC shifted its transportation, warehousing, and retail to ASC X12. The TDCC standards no longer exist and were merged to the transportation transaction sets governed under X12. ASC X12 is the most widely used EDI standard in the United States. DISA (Data Interchange Standards Association) is a term that you will often come across in the EDI industry. DISA is the secretariat to ASC X12 and provides technical and administrative support. The ASC X12 standards contain over 300 transactions. To make more efficient use of them, several industries have used subsets of X12 standards to develop guidelines specific to their industries. For example, the Insurance Industry uses X12N standards as a subset of X12 to indicate which X12 transactions should be used for the insurance industry. The retail apparel industry is different from the grocery industry, therefore, VICS

(Voluntary Inter-Industry Communication Standards) standards are used to define the best guidelines to be used specifically for this industry. Other examples of X12 subcommittees include but are not limited to: X12N X12 Insurance Subcommittee CIDX Chemical Industry Data Exchange EIDX - Electronics Industry Data Exchange Group (CompTIA) PIDX - American Petroleum Institute Each of these industry-specific groups defines a specific subset of the X12 sets; none create a proprietary standard that deviates from the general X12 set. Prior to X12 EDI usage, in the health care industry there was no real standard for exchanging transactions. Each of the private insurers and the blues had their own systems. Medicare used the NSF standards starting with NSF 2.0 in 1991. The Workgroup for Electronic Data Interchange (WEDI) WEDI was founded in 1991 to bring together healthcare industry leaders to identify practical strategies for reducing administrative costs in healthcare through the implementation of EDI. WEDI played a big role in promoting the use of standards in the health care and helped secure the passage of the Health Insurance Portability and Accountability Act (HIPAA) in 1996. WEDIs members are from versatile areas of the Health Care industry, including: Insurance Companies Hybrid Organizations (formerly Mixed Provider/Healthplan) Government Organizations Standards Organizations Vendors Non-Profit Affiliates/Regional Entities Role of HIPAA Regulation In 1996, President Clinton responded to the consumers need for more efficient healthcare services at lower costs by signing into law the Kennedy-Kassebaum Act also known as Health Insurance Portability and Accountability Act (HIPAA), making standards for healthcare EDI the responsibility of the Department of Health. With the establishing of the Workgroup for Electronic Data Interchange (WEDI) in 1991, standards were effectively set for the transfer of healthcare information; and it has since been made official and obligatory for these standards to be met across the healthcare industry. As is to be expected with changes of these size and intricacy, the implementation of these standards has been a gradual process. It was not until about the year 2001 that it that doctors, hospitals, health plans and clearinghouses begin the process of implementing the new EDI standards. In addition, although the new legislation impacts on all data transmission within the healthcare sector, it is in the area of security that the greatest impact has been seen; and the effects of implementing the standards have been felt throughout the entire healthcare industry. It should be noted, however, that the insurance industrys responsibility for realizing these changes will certainly be the greatest, and consequently much focus will be given over the coming years to meeting the new standards in the processing of claims transactions, remittance advices, enrolment and eligibility transactions.

The healthcare industry is, in fact, very much lagging behind when it comes to the utilizing of technologys benefits. Unlike the financial services, retail and logistics industries, which have been reaping the rewards of standardized approaches to data transmission and processing for some time, the healthcare industrys focus on service provision has resulted in a failure to take advantage of the benefits of industry-wide standardization. Technology has hitherto remained an under-used resource in the healthcare industry, made use of only where absolutely necessary, and with processes custom-built to suit the needs of individual organisations. This lack of cohesion or unified principles has resulted in manifold difficulties with communication between healthcare companies, and possibly setbacks for the industry as a whole. It seems, therefore, that the new EDI standards have the potential to revolutionise the way all aspects of the healthcare industry function. Not least in terms of the reduction in unnecessary human resources, i.e. time and bureaucracy. Until now, each area of work required personnel with the time and experience to work with complex and time-intensive systemsincluding an average of 400 different medical form standards. This type of labour not only demands a large of amount of time and training, it also creates an unacceptably high risk of problems arising from human errors. The healthcare industry stands to gain from HIPAA, therefore, in both time, money and overall success. Under HIPAA, health care providers with a staff of 25 or more must use HIPAA- defined transactions must use the ANSI ASC X12N and NCPDP standard formats. Conversely, Medicare mandates that all Medicare claims be submitted using ANSI ASC X12N and NCPDP standard formats. XML and EDI Standards Development Process In Health Care XML an example of when XML is used is in the 275 X12 transaction set for Health Care attachments. In the 275 X12 transaction set an HL7/XML based document is embedded into the BIN segment. XML stands for eXtensible Markup Language. The roots of XML development date back to 1977. It is a subset of SGML (Standard Generalized Markup Language). XML was developed for the use on the internet by the governing body of the Web known as W3C. XML is similar to HTML, but as the name suggests it is extensiblecompanies can define their own document structure with custom tags. XML makes it easy to create a structured file because it lets users define their own tags. The file can then be manipulated, updated or queried through a language called XPATH. Most internet browsers are now capable of reading XML files. XML is most frequently used with a technology know as Web service which provides real time data feeds via the internet-HTTP protocol. For example, a website that uses real-time weather information could subscribe to a Web service data feed that provides real-time weather information. The host would send an XML data feed via the HTTP protocol, and the receiver of the data could use it to display the latest weather information on the website. The same thing could be done if real-time stock quotes were needed. In the late 1990s, with the rapid growth of the internet, there was a great deal of hype that XML will replace EDI because it is more flexible and is free over the internet. EDI is still the most widely used method for business-to-business transaction communication because it is standardized. Components of an EDI Environment

Software, hardware and the human factor are the key components of an EDI setup. Software Environment Millions of lines of code have been written for over 30 years to produce EDI related software. It would not be cost effective or efficient to build a home grown EDI translator, mapper or a communications adapter. There are many EDI software vendors available and they can be found by referring to the EDI Vendor Directory distributed with this course. If a company does not outsource their EDI operations and decides to install an in-house EDI solution, there are several key components that every EDI software environment must contain and the software vendors typically sell them in full packaged bundles or as separate adapters. However, the Translator, Mapper, Communications and Scheduling tool should be included as core components of an EDI software package. Additional components such as the database, business application, and the integration bridge will typically be sold separately. Translator & Mapper As received, an EDI transaction set contains all the information about a purchase order or payment, but not in a form that is either human-readable or usable by any other electronic business software. The data must be converted into a different format, and this is the work of the EDI translator. The Mapper is used to create the conversion specifications, once compiled; the map gives instructions to the translator on how to convert the data. The translator converts an EDI standard document such as an X12 or EDIFACT Purchase Order into a human readable format that could be a printed report or even better, into a proprietary or XML format that could be integrated into the Business Application. Communications Tool Most EDI software packages will contain a communications management tool used for sending and receiving trading partner data. This tool will typically support multiple transport protocols such as TCP/IP, FTP, HTTP, SMTP, AS1, AS2 and ETC. Typically FTP and a script to connect to a Value Added Network Service will be included in the standard bundle of the communications component. Since communication set ups can get complicated, sometimes it makes sense to use a communications adapter that is outside of the EDI software package scope. For example, there are software vendors that specialize just in communications portion of the software tool. Scheduling Tool In order to invoke the communications and the translator tools, a scheduler is needed. The scheduler builds the steps to automate the EDI process. The scheduler automates operations in the EDI environment. The scheduling tool should also have trigger or event based processing features. For example, an EDI translation and communications session is instructed to kick off once a file arrives in a certain directory. Database A relational database management system is needed in order for the EDI software package to function and store data. This component needs to be acquired separately from the EDI software package. Most software vendors allow the flexibility of using any standard database tool such as Oracle, MySQL, Microsoft SQL Server or Microsoft Access. Some EDI translators have their own proprietary database. Business Application The business application is certainly an integral part of the EDI environment. Once the machine-readable raw EDI data is translated, it should be integrated into the business

application to reap all the benefits EDI has to offer. A business application can range from a small business package such as QuickBooks to a full blown enterprise resource planning (ERP) system such as SAP or PeopleSoft. The business application may also be homegrown. Integration Bridge Business Applications typically do not allow proprietary translated files to be imported or exported without doing some programming. Sometimes there is a commercial integration bridge tool available that would link the translated EDI file directly into the Business Application. For example, if a map converts an EDI X12 file to a comma delimited or CSV file, the integration bridge tool does the actual work of importing the file into the business application. Additional Components Other software environment components may include (but are not limited to) the following features: Trading Partner setup and maintenance, Audit , Security Encryption/Decryption, Archiving, Fail Over capabilities, Error and Alert Notification, Easy Version Conversion, Document Turnaround, Cross-Reference Tables and others. Hardware & Infrastructure The hardware and infrastructure setup can range from a personal computer with internet access to a mainframe supercomputer depending on the processing requirements. It is important that all EDI software components (e.g. not just the translator) follow the same standards of appropriately selecting hardware and infrastructure environments. In extremely sophisticated EDI implementations, the EDI components may be separated into multiple servers, for example the communications software will reside on a different machine from the translator software. Operating System & Servers Most EDI software packages support multiple operating systems. The most popular environments are: Windows Servers, Unix/Linux, and IBM based mainframes such as the AS/400 and MVS. The operating system of choice should be determined by the companys IT department infrastructure. For example, if a company is a Microsoft shop, and uses Windows servers and network stations and Microsoft SQL Server databases it would not make sense to install an EDI solution based on a UNIX environment.On the other hand, if the companys infrastructure is based on a UNIX environment with an ORACLE database as a backend, it would not make sense to implement EDI in a Microsoft environment. Some software vendors imply that UNIX and Mainframe environments are more dependable for heavy volume data processing. In a large size organization, the EDI solution installation, the EDI software package and its related components will be installed on two or three separate server environments: Development/Sandbox Safe place for creating and testing implementations without affecting the production environment. For example, software patches or upgrades can be tested here before applying them to the test or production servers to check how they will affect the overall EDI environment. QA/Test/Staging The QA server can be used as a safe area to build, compile and test new EDI maps before applying them to production. The QA environment can also be a staging area to test transactions with new trading partners. Production The production environment is where the day-to-day EDI operations are running. This environment should be locked down and no changes should be made to production without going through proper change control and quality assurance methods.

Networking & Telecommunications In the not-too-distant past, most EDI transmissions were sent via modems and telephone lines. While some EDI is still done this way, for the most part fiber optic cables and high speed internet have replaced the telephone modem as a means of data transmission. Typically an EDI server will be in some sort of data center facility that has appropriate network infrastructure in place to support the required EDI communication methods. Network routers and switches help direct the path for data travel. Firewalls, VPN gateways and intrusion detection systems ensure the data is secure and protected and can not be spoofed. Data centers can be in-house or co-located depending on the business needs. Fail over, Backup & Disaster Recovery EDI is a mission critical component for most organizations, which means a disaster recovery and a failover plan should be in place. Fail over: would be the method to become operational again, if for example, the hard disk or the CPU motherboard of the EDI server crashes. The speed at which the EDI environment needs to become operational again will dictate the type of fail over requirements. For example, in a just-in-time automotive manufacturing environment, auto parts are being received an hour before they are put on the assembly line. The EDI failover time is zero. To mitigate the risk of a situation like this, parallel live production servers could be set up to mirror each other. If one fails, the other instantly picks up the processing. Not a beat is missed. Backup: Before EDI, business transactions could be placed in file cabinets and stored off site somewhere. With EDI in place it is important that EDI data is backed up frequently. All EDI data formats should be backed up, meaning the machine-readable EDI data, the translated proprietary data, communication logs and obviously the database. Again, the extent to which a company backs up and restores its data is determined by the business requirements. A lot of data backup options exist such as online and on-site, which is the most quickly accessible data. Off-site storage should also be considered. Disaster Recover (DR): If a plane crashes into the data center building, a wellimplemented disaster recover plan would be set in motion. For example, if the EDI server is in Silicon Valley (San Jose, CA) it might make sense to put the second hot-production mirroring server somewhere in a data center in New Jersey. Typically, a well-implemented disaster recovery plan includes all components of the IT environment and not just EDI. For example, the EDI server interacts with the business application server (e.g. SAP or PeopleSoft server). During disaster recovery testing it would make sense to test that in the off-site data center location the DR business application server and the DR EDI server successfully interact with each other. EDI Workforce Personnel from various functional areas will one way or another be involved with EDI. For example, the accounts payable manager or clerk should be familiar with EDI operations if EDI invoicing is in place. The procurement manager or the buyer should be well aware of EDI operations if the purchase orders are transmitted electronically. The IT personnel will be heavily involved with EDI in order to support the infrastructure. The same applies to many other departments such as shipping and logistics, human resources, and finance. However, an EDI coordinator role should exist. The usage of this role varies in organizations. The EDI team can consist of a part time person doing EDI for couple of

hours a week or a 15 person EDI team. This depends on the size of the organization and its use of EDI. Typically, there will be one EDI coordinator or one EDI team as the focal point of contact to support EDI operations. The responsibilities of this team will be to add and maintain trading partners, solve day-to-day issues that arise, and maintain and update the system. The EDI coordinator role should be very well-known and visible throughout the organization. This EDI team will be in almost daily touch with the companys trading partners. Typically the EDI coordinator role, whether its a team or just one part-time person, will be placed under the Information Technology umbrella and will most likely report to the IT manager. EDI Communication Methods Overview In order to be able to send and receive EDI documents a method of electronic communication must exist. There are many different ways that companies have exchanged EDI data over the years. During the 1950s and 1960s, companies could mail mainframe punch cards or data tapes through the United States Postal Service. Then the telecommunications modem came. Then it went. As described in the networking and telecommunications section, most EDI data is now transmitted via high speed broadband internet through fiber optic cables. However, the protocol of choice, the software, and the method for transmitting the data remain varied. Value added networks have served as communications intermediaries for years and continue to be very popular today. With the rise of the internet, a lot of companies in the recent years started connecting directly to their trading partners and by-passing the value added networks or any third parties. These various methods of EDI communication will be discussed in this section. Clearing Houses To increase efficiencies and reduce cost and errors, health plans may decide to accept only electronic transactions. In these cases, if providers want to maintain the business relationship, they must be prepared to implement billing software or use a clearinghouse. . How it works Clearinghouses are third party service providers that take non-EDI data and translate them to EDI data. Clearinghouses can also translate EDI to EDI by taking the received raw data, massaging it, scrubbing it and migrating it to another document. Clearinghouses can also convert paper documents to EDI and vice versa.

Services Most Clearing houses provide the following services: Bundling & Unbundling Re-pricing of claims Code-specific conversions Provider network matching / scrubbing

Eligibility Validation Paper-to-EDI / OCR Custom EDI conversion / mapping / development Benefits Faster reimbursement Reduction in rejected claims (Clean Claims) Decrease in time-intensive manual tasks Increase in productivity and efficiency Improvement in cash flow Value Added Networks A Value Added Network (VAN) is a third party intermediary network between trading partners. It serves a role of being a broker and forwarder of EDI data. It can be compared to a traditional post office, but the exchange of mail is done electronically. There is a key difference between Value-Added Networks clearing-houses. Clearinghouses conduct EDI translation they can take a paper claim and turn it into an ANSI 837. The vans simply serve the role of a taxi cab, they just move the data. How it works When a company contracts out to a VAN service provider, the company is assigned a mailbox. First, data is translated by the EDI software package. Then the communications adaptor initiates a connection to that VAN mailbox and uploads the EDI files to the VAN mailbox. The VAN receives the files in the mailbox and forwards the files to the appropriate trading partners. For example, a supplier company needs to send several invoices to several different hospitals, such as Kaiser, Scripps and UCLA Medical Center. Instead of transmitting the invoices to three different places, the invoice is transmitted to one VAN mailbox. The VANs role at this point is to forward the invoices to the VAN mailboxes belonging to those hospitals. A similar process occurs for incoming EDI files. For example, when Kaiser, Scripps and UCLA Medical Center issue purchase orders, they can send the EDI purchase orders to their own VAN mailboxes. The VAN distributes the EDI purchase orders to the suppliercompanys mailbox. The supplier company then connects to their mailbox and downloads the purchase orders created by the three retailers. The VAN looks at the electronic EDI envelope surrounding the files that it receives to determine the appropriate EDI routing instructions. Benefits There is definitely a Value-Add offered by Value Added Network providers. The main benefit of the VAN is that it can be the single point one-stop shop for sending and receiving EDI data. A company does not have to worry about maintaining and supporting multiple connection points. There are many other services that the VAN service provider offers. Here is a partial list: Support for Multiple Protocols The VAN provider is usually flexible about what communications protocol its customer has. It can support almost all of them. For example, one company might use FTP, another company might use EMAIL (SMTP), and another company might still be using dial up. The VAN providers sophisticated infrastructure can support all these transmission methods. Compliance Checking Without accessing the actual content of the EDI file, the VAN can validate the EDI data at the envelope level to ensure it complies with a published EDI standard.

 Various Routing Options For example, carbon copying a duplicate copy of the EDI transaction to additional recipients. Dispute Resolution Since a VAN serves as a third party between trading partners, the trading partner can use transmission logs to determine if mission critical data was actually transmitted. Support Most VANs monitor EDI traffic and provide support 24/7. Although VANs offer support they can not be held liable for misplacing or losing data. EDI Transmission Methods In order to be able to send and receive EDI documents a method of electronic communication must exist. There are many different ways that companies have exchanged EDI data over the years. During the 1950s and 1960s, companies could mail mainframe punch cards or data tapes through the United States Postal Service. Then the telecommunications modem came. Then it went. As described in the networking and telecommunications section, most EDI data is now transmitted via high speed broadband internet through fiber optic cables. However, the protocol of choice, the software, and the method for transmitting the data remain varied. The consensus today with most companies is that the transmission must be secure. FTP FTP is an extremely popular method used for transmitting data directly. Several methods can be used to ensure that the FTP transmission is secure. FTP/S and SFTP provide options for SSL security and are utilized by exchanging keys for point-topoint connections. FTP has been around since the 1980s and is pretty easy and quick to setup compared to other protocols. Plus, its fairly easy to write FTP scripts without needing a lot of programming knowledge. SFTP over SSH SSH (aka SFTP) is security protocol for logging onto a remote server. SSH provides an encrypted session for transferring files and executing server programs. With SSH, Login authentication can be handled using a certificate or password. Some companies SFTP and SCP are both supported. The benefit of using SFTP is that the whole transmission is encrypted, including the user id. Also, with SFTP you can exchange certificates and keys and not have to maintain password. For example you can use X509 certificates or RSA SSH keys. Example of encryption bit strength include 1024 - 2048 FTP with PGP Another method of securing an FTP transmission is by using PGP. Trading partners set up a regular FTP connection (typically on port 21) and encrypt the data using PGP keys. Often with PGP the data is both encrypted and digitally signed with the PGP keys that are exchanged. Example PGP Encryption software: McAfee E-Business Server PGP Desktop from PGP Corporation

Example PGP Key Types: Public keys: Diffie/Hellman-DSS (for PGP), RSA or ElGamal (for GnuPG). Ciphers: 3DES, CAST5, Blowfish, AES, AES192, AES256 and Twofish Hashes: MD5, SHA1 VPN Virtual Private Network Some companies chose to FTP over a VPN. Sending data through the VPN includes the process of encrypting or randomizing the traffic over the Internet so that a third party cannot intercept and make sense of the communication. VPNs are typically more expensive to set up than SFTP or FTP with PGP. In order to implement a VPN connection, both parties must have the right infrastructure in place. Typically file encryption like PGP is not always required with VPN because the whole transmission is encrypted. In addition to hosting an FTP server with VPN you also need VPN routers to set up the VPN tunnel. Below are sample VPN connections between XYZ Corp and its trading partners ACME and ANY Corp EDIINT: AS1, AS2, AS3 EDI over the Internet is a fairly recent technology developed by the Working Group of the Internet Engineering Task Force (formed in 1996). There are three standard protocols used: AS1 via SMTP, AS2 via HTTP and most recently AS3 via FTP. The AS# stands for applicability statement. AS2 usage is the most popular of the three today. Standard: AS1, AS2, AS3 is neither an invention nor replacement of the SMTP, HTTP, and FTP protocols, which have long existed before EDIINT. Companies can still transmit data via HTTP, SMTP or FTP without the use of AS1, AS2, or AS3. The goal of the technology was to standardize the way the message is packaged, secured and sent, so that all trading partners could use a standard way of transmitting the data instead of each of them using their own custom method of SMTP, HTTP or FTP. For example, a VCR can be guaranteed to connect to the television by using RCA cables. EDIINT software may chose to go through interoperability testing process conducted by the Drummond Group, Inc. Some large size hub companies like Wal-Mart did not allow the use of non-certified EDIINT software vendors in the past. Security: According to the IETF. There are several security techniques that could be used for EDIINT. Either Secure MIMEv3 or PGPMIME. AS2 also supports the use of HTTPS (SSL/TLS) for secure channel connections. Documents sent using AS1/AS2/AS3 may use any combination of singing and/or encrypting methods, using standard PKCS#7 functions in a number of vendor libraries. AS2 testing has used up to 1024bit keys for Public Key encryption, 128bit keys for Symmetric encryption, SHA1 and MD5 for hashing and TripleDES (3DES) for encryption. AS2 will support larger keys and other algorithms as they become readily available. Utilizing a certified software vendor guarantees the availability of these security features. Also, the EDIINT software is usually user-friendly enough and makes it easy to select these security options. The process almost always involves the exchanging of certificates with trading partners. The messages sent via AS2 can be signed and/or encrypted depending on the requirements of the trading partner. MDN Technical Overview: MDN stands for Message Disposition Notification. Typically trading partners will want some kind of confirmation that the data transmitted was

successfully sent. Upon the receipt of the data and successful signature or decryption validation an MDN message is sent to the sender for confirmation. This MDN message can be sent back via HTTP/HTTPS immediately via AS2 w/ "Sync" MDNs or at a later time via AS2 w/ "ASync" MDNs. The MDN option maybe turned off if trading partners agree that no such confirmation is required. Also, the MDN maybe sent back via EMAIL which is very rare. The security and EDIINT method of choice is always subject to agreement between the trading partners.