You need to send some data to another company, and you're wondering how to do it. Generally, the first time it happens you're dealing with a much larger company, and they know how to do it. You're going to use EDI, and that's the end of the investigation phase.

EDI is the most common automated data transfer method for B2B, and for good reason. EDI has been around since the 1950's, it's a well thought out, very standardized file format and file transfer protocols.

Nobody denies that EDI is complex. The EDI specs book for one version of X12 EDI is 1930 pages. However, it's the detail of the specifications that makes EDI the best choice for automated data transfer. In EDI both partners know exactly what format the data will be in, know which elements will be included in the file, and which elements won't be included.

It may not seem obvious at first, but it's the detail and complexity of EDI that has made it successful. It's quite possible when an EDI transaction set is setup properly, it will send thousands or tens of thousands, of files without any errors. When an outgoing EDI file is setup and mapped from a SQL Query (in many cases) to an EDI file it takes developers fluent in EDI, and each data element needs to be mapped. That attention to detail makes it much more likely that data errors will be caught in the setup process and requires a great deal of thought of how to make the incoming data fit the EDI transaction set.

Why is it so important automated files are perfect? Think about it, your trading partner is relying on that data, and normally the data goes right into their system without anyone ever looking at it. Think about sending a company like GM the list of parts you just loaded onto a truck. Then say your data was wrong, and you actually sent 1200 parts but your EDI file said 1000 parts. GM would accept the list without anyone verifying it. If you had a daily shipment and you mistakenly added 200 parts to each list, by the end of the month you would be short thousands of parts, and GM would be paying you for the parts they actually used. Your company could be in big financial trouble quite quickly. Or, let's assume your part numbers were perfect, but your file isn't. The GM EDI engine would reject your file. If you're not reading the response files, you don't know it. At the end of the month, GM doesn't have the information to pay you, and it might take you weeks or months to get it straightened out. In the meantime, your company is out an entire months' worth of parts. It's important that automated files are perfect, and you read the reply files.

Many of your trading partners will have Chargebacks (also known as “expense-offsets”). They are monetary penalties imposed by retailers for non EDI compliance. Retailers impose chargebacks because supplier noncompliance creates disruption and losses for the retailer. Hence, retailers create “expense offset policies” to help them recuperate the losses they experience when suppliers are non-compliant. Retailers usually deduct chargebacks from the check payment to the supplier. Chargebacks are difficult to control because every trading partner has its own chargeback schedule. Suppliers usually get chargebacks because they have issues keeping up with changes from the retailers (vendor manuals and routing instructions are constantly changing).

Each trading partner will have a different chargeback schedule, some retailers charge as much as $50-$100 per EDI mistake or error. Some trading partner’s chargeback schedules contain hundreds of unclear reasons for chargebacks. You should hire an EDI provider that knows every trading partner’s chargeback schedule and EDI requirements.

Fortunately, the EDI specs and your trading partners companion guide lay out exactly what you need to make sure automating data transfer goes smoothly, and hiring an experienced EDI developer to implement it will be money well spent. EDI can be expensive, but once it's setup and running well, your business will run much smoother.

At EDI Shack we take contracts to fix EDI implementations constantly because the original developer didn't quite understand EDI, and implemented a system that sends a file, but doesn't properly keep track of everything. These poor companies have normally spend hundreds or thousands of hours fixing problems that could have been avoided with a better EDI implementation. It's always cheaper to get it done right the first time.

Addenda – Refers to a version of the HIPAA mandated transaction sets that corrects identified implementation issues noted in the original TR3.

ASC X12N/005010X222– The HIPAA mandated (ANSI) ASC X12N Professional Health Care Claim transaction format.

ASC X12N/005010X222A1 – The Type 1 Errata modifications mandated for use with the ASC X12N/005010X222 837 Professional Health Care Claim transaction format.

BCBSM or FEP Supplemental – BCBSM or FEP is being billed as the secondary payer and the primary payer is original Medicare or any type of Medicare Advantage or Medicare Advantage HMO.

BCBSA – An acronym for Blue Cross Blue Shield Association

BCC – An acronym for Blue Cross Complete of Michigan, a Medicaid managed care plan

BCN – An acronym for Blue Care Network

BlueExchange – A BCBSA process through which non-claim HIPAA transactions for members from all other Blue Cross and/or Blue Shield plans that are governed by the BCBSA can be accepted by a local host plan (the plan that delivers the benefits to a member) and routed to the home plan (the plan that covers the member) for processing.

Data Segment – Corresponds to a record in data processing terminology. Consists of logically related data elements in a defined sequence (defined by X12N). Each segment begins with a segment identifier, which is not a data element and one or more related data elements, which are preceded by a data element separator. Each segment ends with a segment terminator.

Data Element – Corresponds to a field in data processing terminology. Assigned unique reference number. Each element has a name, description, type, minimum length and maximum length. The length of an element is the number of character positions used, except as noted for numeric, decimal and binary elements. Data element types are defined in Appendices B of the TR3.

Delimiter – A character used to separate two data elements (or sub-elements) or to end a segment. They are specified in the interchange header segment (ISA). Once specified in the ISA, they should not be used in the data elsewhere other than as a separator or terminator.

EDI – An acronym for Electronic Data Interchange.

Electronic Data Interchange – The application-to-application transfer of key business information transacted in a standard format using a computer-to-computer communications link. There are typically 6 components used in order to do EDI. They are: an EDI file, a trading partner, an application file/form, translator (mapper), communications and value-added network or value-added service provider.

FEP – Federal Employee Program

Interface – The point at which two systems connect to pass data

Loops – Loops are groups of semantically related segments. Data segment loops may be unbounded or bounded.

Medicare Beneficiary Identifier (MBI) – an eleven-character alpha numeric identification number issued by the Center for Medicare Services, which replaces the Medicare Health Insurance Claim Number (HICN).

NASCO – The National Account Service Company connects several Blue Cross and Blue Shield plans across the country through a common automated system to administer health benefit programs.

Routing – Separation of data based on specific criteria for subsequent transfer to an internal or external system.

Technical Reports Type 3 (TR3s) – Documents that provide standardized data requirements and content as the specifications for consistent implementation of a standard transaction set. The Washington Publishing Company publishes HIPAA TR3s on their web site: http://store.x12.org/store/

Trading partners – Companies/Entities that exchange electronic data files. Agreements are sometimes made between the partners to define the parameters of the data exchange and simplify the implementation process.

Transaction Set – A transaction set is considered one business document which is composed of a transaction set header control segment, one or more data segments, and a transaction set trailer control segment.

X12 - An Accredited Standards Committee commissioned by the American National Standards Institute to develop standards for Electronic Data Interchange

X12N – An Accredited Standards Committee commissioned by the American National Standards Institute to develop standards for Electronic Data Interchange. While X12 indicates EDI, the N identifies the Insurance Subcommittee that is responsible for developing EDI standards for the insurance industry. There is a special health care task group within this subcommittee responsible for the development of health care insurance transactions.