ASC X12 Insurance Subcommittee

Upward/Downward Compatibility
Translation White Paper Part I

(Part II)


Electronic Data Interchange has been adopted by several industries since the early 1980's. Other industries are just beginning to utilize this technology. The health care industry is in the latter category. The goal in health care is to seamlessly process health care information in an electronic environment. Major issues surface during implementation of EDI transactions. A user base of one-million for a given transaction presents many concerns. Version Control relative to updates/ revisions to the standard for a user base of this size is a key issue. Another issue involves the aggressive time frames which may be mandated by federal and/or state legislation or required by competitive market forces. These are just a sample of the issues facing the health care industry in the attempt to fully exploit EDI.

To address these and other pertinent issues an ad-hoc work group was formed by X12N, the Insurance Sub-Committee of X12. The purpose of this ad-hoc group was to analyze the feasibility of massively deploying EDI transactions in an industry, addressing such key topics as Version Control and Translation Software. During the analysis it soon became apparent that many other factors (areas) significantly influenced the deployment of standards. These factors included Telecommunications, Implementation Guide Development, Testing and Education. The scope of the group expanded to include these six specific areas:

It also became quite apparent that resolutions/ recommendations for these issues would not only benefit the health care industry but may benefit other industries as well. The ad-hoc group became a special task group (Upward/ Downward Compatibility) to X12N.

A series of White Papers was constructed, each paper focusing on one of the six topics listed above. The Translation Software White Paper follows. The White Papers can be used in conjunction with one another to deploy a comprehensive EDI initiative or separately as stand alone documents to aid with specific phases of the initiative. The documents address the subjects from a business perspective. Some technical areas are discussed. Other documents of a more technical nature should be consulted for detailed technical information and preciseness. An Executive Summary is provided in the overview to convey the connectivity of the documents for an EDI initiative.

The Upward/ Downward Compatibility Special Task Group wishes you much success in your EDI endeavors. We welcome your comments and suggestions regarding all or any of the White Papers. Questions regarding specific information in any of the White Papers or other implementation issues can be directed to any of the individuals listed below.

Debra T. Obringer Barbara Redding Bruce Horn
Veritus Inc. HCFA/BPO OPOP DPP The Associated Group
Fifth Ave. Place LOC 1-H-3 Meadows East 6802 Hillsdale Court
Suite 621 6325 Security Blvd. Indianapolis, IN 46250
Pittsburgh, PA 15222 Baltimore, MD 21207 (317) 692-6154
(412) 255-3111 (410) 786-6151 (317) 692-6205 fax
(412) 255-5360 fax (410) 786-4047 fax

These documents were developed by the Upward Downward Compatibility Special Task Group of X12N of ASC X12. Permission is granted to any individual or entity to use, duplicate or redistribute this document so long as it is not modified or sold for profit.

No warranties. These documents are distributed in the hope that they will be useful in facilitating an EDI/ EC environment.

No author or distributor of this document accepts responsibility for the consequences of using it or for whether it serves any particular purpose, unless they state so in writing.

The Upward / Downward Compatibility Special Task Group reserves the right, and accepts the responsibility, to exclusively facilitate all modifications to the data within this document and distribute the revised document to any requesting entity.


There are many key elements in an EDI Initiative including but not limited to Translation Software, Telecommunication, Implementation Guide, Testing, Version Control and Education. These key components can be implemented independently or in conjunction with one another, depending on the business need.

Special Task Group 2 - Upward/Downward Compatibility developed white papers in each of these subject areas.. An Executive Summary and Forward will preface each white paper. Each Executive Summary will outline the scope and recommendation of the respective white paper as well as their relationship to an overall EDI Initiative. This executive summary and white paper is specific to Translation Software.

It is strongly suggested that the determination of business needs and requirements be the first task in an EDI initiative. The analysis to determine the business needs and requirements must assess the current environment as well as those that are anticipated or projected to support business goals and objectives. Once this analysis is completed, any or all of the key components stipulated above can be implemented consistent with the business need. Too often the determination of business needs and requirements is overlooked by organizations formulating an EDI initiative. It is critical that, this analysis be the first task. EDI is not just a technical (information system) function but a total business process. It is imperative that both the business and technical components of an organization partake in an EDI/EC Initiative. A critical factor to this end is the level of commitment from executive management. A significant factor in successful EDI/EC Initiatives is the level of commitment from the highest levels of executive management within the corporation. The connection between the above stipulated key components of an EDI Initiative is illustrated in the Executive Summary of the EDI/EC Initiative, which is a compendium of the above key components..

The scope, recommendation and relationship pertaining to the Translation Software White Paper is:


The primary objective of EDI translation software is to convert ASC X12 formats from/ to application formats for integration into an application system or business process. The scope of this white paper is to address issues relative to EDI translation software and provide insight to the selection/ formulation process of EDI translation software for ASC X12 standards. An example of forms utilized in an Evaluation Process for EDI Translation Software as well as the Health Care Industry Guidelines for EDI Translation Software are included.


- There should be adherence to pre-determined industry-wide guidelines for developing or purchasing EDI translation software.

- Consistent specific evaluation criteria should be formulated and utilized.

- Benchmarking should be a task in the evaluation process. Benchmarking should address such issues as but not be limited to fulfillment of evaluation criteria, fulfillment of business needs, projection of EDI support,throughput capabilities, software functionality, and ease of use.


Mapping is one of the key functions of translation software. Implementation Guides provide insight into the "mapping" from/ to the standards from/ to the application formats. Testing of the standard (transaction) occurs after the transaction has been created by the translation software. The transport or the exchange of information/data using the X12 standards created from EDI translation software is accomplished through Telecommunications. Version Control is particularly significant to translation software since the software must accommodate updates/ release of the transactions. Most vendors of translation software provide formal training sessions on their product.

Comments and suggestions regarding this white paper are encouraged. Questions regarding specific information or other implementation issues can be directed to any of the individuals listed below.

Debra T. Obringer Barbara Redding Bruce Horn
Veritus Inc. HCFA/BPO OPOP DPP The Associated Group
Fifth Ave. Place LOC 1-H-3 Meadows East 6802 Hillsdale Court
Suite 621 6325 Security Blvd. Indianapolis, IN 46250
Pittsburgh, PA 15222 Baltimore, MD 21207 (317) 692-6154
(412) 255-3111 (410) 786-6151 (317) 692-6205 fax
(412) 255-5360 fax (410) 786-4047 fax

Table of Contents


I. BACKGROUND. . . . . . . . . . . . . . . . .B2-B3

II. CHALLENGE . . . . . . . . . . . . . . . . . .B4-B5

III. SCOPE AND OBJECTIVE . . . . . . . . . .B6

IV. ALTERNATIVES. . . . . . . . . . . . . .B7-B11

V. ISSUES. . . . . . . . . . . . . . . . . . . . . . . . . B12

VI. RECOMMENDATION. . . . . . . . B13-B14

The following appendices can be utilized with this document or external to this document (as a snap out) for the purpose of assisting a purchaser/ developer in the purchase/ development of EDI translation software. Regardless of the alternative selected by a particular business entity certain appendices may or may not apply. Hence, the appendices can be used separate from this White Paper. Appendices A through D are examples and should be customized to the respective business need(s) of the implementing entity.




Many industries have implemented initiatives to automate their routine business processes. Among the techniques employed to achieve this metamorphosis of a new business process is automated information exchange. A technology to facilitate the exchange of business information is Electronic Data Interchange (EDI).

For many years, companies have exchanged with their business partners proprietary formats containing pertinent business information. Some refer to this type of exchange as "lower case EDI". Due to the lack of standardization in this type of EDI, many companies and industries have endorsed and implemented standardized formats. These standards are developed and maintained by the X12 organization within the Accredited Standards Committee (ASC) of the American National Standards Institute (ANSI). Utilization of this type of EDI is often referred to as "upper case EDI" or just EDI. Use of standards based EDI has proliferated over the past several years and is growing at an exponential rate. The most recent sectors of the economy utilizing EDI are health care, insurance and government. As these sectors accelerate migration to this type of information exchange the rate of growth in the utilization of standards based EDI will increase substantially.

There are two major functions involved in EDI, transmission and translation. Business partners can implement these independent of one another or coupled together. This White Paper addresses translation software or "translators". Transmission is addressed in the Telecommunication White Paper. The implementation process associated with EDI includes the actual testing phase, which follows the translation task. The testing process is outlined in the Testing White Paper.

Migration to a paperless environment involves the employment of standards based transaction formats in an electronic (Computer-to-Computer) environment. Transmitting information, electronically, enables companies to obtain and utilize information in a more timely manner. This is the transmission portion of EDI.

Utilization of ANSI ASC X12 standard transaction formats necessitates computer software to convert from/to a trading partner's application format from/to the X12 standard format. This is referred to as translation. Translation software is either developed (also known as "home grown" or "in house") by the trading (business) partner(s) or can be purchased. There are many commercial EDI software (translator) products available to accomplish this task. Some industries have developed "guidelines" to assist in evaluating and selecting commercially available software.

Additionally, in some business partner scenarios EDI transmission and translation becomes the integral part of virtual corporation application to application processing. This process is initiated at the sending trading partner's site where application to EDI translation and transmission integration occurs. An interim step may involve a value added network if applicable. The process loop is closed at the receiving trading partner's site where EDI transmission, translation, application integration and the issuing of the acknowledgement occurs. Hence, the EDI business process commences in the application system at the sending trading partner site and terminates at the application system of the receiving trading partner.


The selection of an EDI translation software vendor must be as objective and quantitative as possible. Criteria should be developed to assist in the evaluation. Some areas to be evaluated include technical functionality, capability and sophistication. User friendliness is also important but is somewhat subjective in nature. As products are evaluated against one another, the use of criteria will assure that all of these areas are properly assessed.

Since translation involves X12 formats, an understanding of X12 is necessary to properly evaluate the technical functionality of the product. The degree of understanding by the evaluation staff has a direct correlation to the effective assessment of the software and assuring the best fit to the business need. Additionally, there are terms associated with EDI translation software functions that can be ambiguous. For instance, X12 compliance can mean different things to different people. Translators are X12 compliant at various levels within the X12 transaction. Ambiguities such as these add a level of complexity to the evaluation and selection of translator products. These ambiguities become particularly significant as an industry strives to achieve uniformity and consistency in the mass deployment/ distribution of an X12 transaction. For example, the Health Care Financing Administration (HCFA) has deployed two transactions (ASC X12 835 and ASC X12 837) through out their user community. This user base encompasses many Medicare contractors as well as many providers of health care services for Medicare patients. Uniform distribution of a transaction to a user base of this magnitude is essential to successful deployment in the industry.

An advantage of having EDI translation software external to application systems is that the EDI translation software is isolated from application system modifications as well as the application being isolated with modifications pertaining to trading partner relationships and X12 versions/ releases/ subreleases. Additionally, the effectiveness and efficiencies of translators tend to be site specific due to architecture as well as other business and technical variables such as CPU utilization, resource management and unique business needs. However, certain efficiencies can be applicable in an inter/ intra industry capacity where commonalities exist. An example of an intra industry commonality is highlighted in the health care industry by utilizing the same "map" within the translation software for the HCFA flat file to the ASC X12 835 (Claim Payment/ Advice). Maps should be portable and easy to use. The HCFA flat file is utilized by one sector of the health care industry. Since this is for a portion of the industry it does not predispose the need for a standard to be utilized by the entire industry. An example of an inter industry commonality would be the necessity to possess the capability of supporting multiple versions of a transaction or all of the X12 transactions. This would be a necessity regardless of the industry. To insure flexibility and maintainability, translation software must support multiple versions of the X12 transaction sets.

Another factor that affects some industries is the need to be responsive to government legislation in a time frame conducive to the distribution required by the law. Modification of translation software must conform to legislation as well as to the time frames of the institutions (ie. HCFA, Customs, etc) that must be in compliance with these laws. Transaction software development and maintenance that may be affiliated with these laws must be responsive to time frames in a matter such that adequate time is provided for analysis, testing and other phases of a system development life cycle. This assures that the process can be comprehensive and complete.

In summation, the challenge is to effectively utilize translation software in the uniform deployment of standards. The results from these translators must be consistent so that a uniform deployment is achievable. This is an essential part in "standardizing the standard".


The scope of this white paper is to address issues relative to EDI translation software and to provide insight to the selection/ formulation process of EDI translation software for X12 standards.

The primary objective of translation software is to convert X12 formats from/to application formats. This conversion must satisfy the overall business needs of the trading partner relative to the exchange of information. Functionalities must be assessed to ensure that the translation software will support these needs. Guidelines for acquisition of EDI translation software can assist the purchaser/ developer of such software in providing functionalities that are generic to EDI and not necessarily industry specific.

As stipulated earlier, ambiguous terms such as X12 compliance need to be universally defined as to promote a clear understanding of the concept. For instance, X12 compliance can occur at various levels relative to the transaction. The simplest way to define X12 compliance is relative to the version/ release/ subrelease of the X12 standard from the transaction level through value codes as stipulated in the internal lists for data elements. Hence specifically, compliance would be at all levels --- transaction, segment, data element and value codes of the data element relative to a version/ release/ subrelease.

Also referenced earlier was the need for software in response to government legislation. Updates to accommodate situations of this nature should be available at a preset price. Additionally the level of vendor support necessary to provide these type of updates should be addressed during the evaluation phase.

Very important is the ease of implementation of EDI translation software. This ease of use directly relates to the cost of implementing as well as maintaining the software. In many instances, personnel installing the software will be novices to the X12 formats as well as the X12 process. Hence complete, logical and fully explanatory documentation of the installation process is essential, particularly in instances where the user base is of great magnitude (ie. health care implementations, insurance implementations).

When industries have to uniformly implement transactions to a large user base as a result of a mandate or legislation etc., the satisfaction level relative to this user base is extremely important. In the instance that standards based EDI use is dictated to the customer, the customer must have its own business requirements addressed by the translation software product.


The alternatives that follow outline ways to accomplish the translation of application formats into/ from X12 standard formats. Regardless of which alternative is selected by the business partner, pre-determined guidelines (industry wide) should be adhered to and consistent criteria utilized in evaluating translation software. The Health Care Translation Software Guidelines are provided as an example in Appendix E. Evaluation criteria and matrices that have been utilized in a health care environment are located in Appendix A.

As stated previously in this document, testing is the next phase after translation. (Reference the Testing White Paper for information regarding the testing process.) Testing assures the information from the translation phase can be used by the application. Translators purchased or developed consistent with these guidelines will facilitate the application of effective test procedures.

Version Control is applicable to translation in that translators should accommodate all versions/ releases/ subreleases of all of the standards. This accommodation is normally achieved through a Maintenance Agreement with a vendor if the translation software is purchased. Reference the Version Control White Paper for further details. Additionally implementation guides will be utilized in conjunction with the implementation of the transactions to depict specific and precise details relative to the value codes for date elements, data elements within segments, segments within a transaction, etc. Reference the Implementation Guide White Paper for further details.

A benchmark is a controlled test methodology using a pre-determined standard of performance. Benchmarking has been utilized extensively in evaluating hardware and software performance. An example of benchmarking in an EDI environment relative to the health care industry would be to receive a transmission of claim transactions (ASC X12 837), which would be the control group, and create the target application flat file respective to this transmission. Benchmarking should be utilized as one of the determinants in the selection process for the following alternatives.. Benchmarking includes but is not limited to:

Alternative I

Translation software developed by the business partner.

This type of translation software is referred to as "in house" or "home grown". This software is often written in languages that are native to the platforms on which they reside. Systems of this nature typically undergo the same system development life cycle that any computer application system would undergo. Hence the same time frames associated with the development and maintenance of application systems are applicable to EDI translation software as well.

With this alternative, maintenance may become a significant effort since the software may need to be modified for each version/ release/ subrelease of the EDI standard when it is issued and is utilized by the business partner. ANSI ASC X12 versions are issued every five years, while releases are annual and subreleases are issued twice per year. Since companies desire to continually add business partners to their EDI environment to achieve further economies of scale and new trading partners typically elect the most recent version of the standard, maintenance in this scenario can become cost prohibitive due to the demand presented by this type of maintenance.

Alternative II

Commercially available EDI translation software.

Commercially available EDI translation software products are offered by vendors to convert transactions from/ to X12 formats as well as the value codes that are associated with X12 and the application. The software is written for and is generally associated with a particular computer platform. For instance, some translation software executes on personal computers while others execute on mainframes. Newer translation software may be portable to various platforms.

In addition to X12 -- application conversion, several other functionalities are available. These functionalities include but are not limited to:

To properly evaluate commercially available EDI translation software, industry guidelines should be designed and consulted. Additionally, an evaluation matrix depicting the evaluation criteria should be formulated. An example of such a matrix that was utilized in a health care environment is provided in Appendix A - EVALUATION PROCESS FOR EDI TRANSLATION SOFTWARE. An example of an industry guideline is located in Appendix E - HEALTH CARE INDUSTRY GUIDELINES.

Translation software products vary in price according to the platform and functionalities provided. Software for personal computers is generally less expensive than software for mid-range or larger platforms. Most important, purchasers must determine their business needs and then select the platform and software consistent with these needs.

Alternative III

"Bundled software". Commercially available EDI translation software bundled with either transmission software or application software.

Some commercially available EDI translation products (reference Alternative II) are bundled with transmission software. (Reference the Telecommunication White Paper for details pertaining to transmission). This bundling provides for both EDI translation and transmission in a single product. Bundled EDI translation and transmission packages may be associated with a specific value added network (VAN) as an optional package for purchase, thereby providing a "whole" package --- translation, transmission and a value added network.

In some instances the translation software is coupled with application software so as to physically as well as logically create a seamless interface from/ to the translation from/to the application. Regardless of whether the translation software is coupled or autonomous, the evaluation of the product pertaining to the conversion functionalities should be the same as stipulated in Alternative II above. However since in bundling additional needs are to be addressed (such as transmission or application), an evaluation of the functionalities to fulfill these needs should also be conducted. Further, consideration should be given to the efficacy of a seamless process for business partner interaction.

The relationship between the functions of EDI, the application system and the communication network is depicted in the chart below:

Application Systems

EDI Translations Software

Telecommunications Software

Telecommunications Network

A product addressing one or more of these areas may have different levels of efficiencies relative to the desired business needs. For instance, when evaluated separately the best transmission, translation and application software can be selected, then modularly linked together to establish the desired scenario. However, by definition bundled products contain multiple products. Coupled together these products may or may not meet the desired business needs. In illustrating this point, a bundled product may contain the best EDI translation software but less than adequate transmission software for a particular business need. Evaluation of all areas of the bundled product becomes tremendously important when making prudent business decisions.

Alternative IV

"Tool kit". Generally a "tool kit" contains one or more (a subset of) transaction sets that are offered in the other commercially available EDI translation software.

Tool kit packages are commercially available from many of the same vendors that offer full EDI translation software packages. The functionalities that are available in the tool kits should be evaluated in accordance to the criteria stipulated in Appendix A with the realization that tool kits are geared to a specific transaction(s) or industries.

Tool kits are often utilized by business partners to provide low cost software to their business partners and to promote the migration of exchanging information via a limited transaction set and utilizing X12 standards. This is done to facilitate a specific business need. Companies may utilize one tool kit, develop an alliance with a particular vendor or merely have a "recommendedv list of tool kit vendors to promote the use of standards based EDI to their business partner. The tool kit would be an alternative to implementing a full EDI initiative. An example of a tool kit would be software that is executed on a personal computer, interprets an application format into an X12 format (UB92 claim format to an ASC X12 837 (Health Care Claim)), transmits the ASC X12 837 to the payer, and receives an ANSI ASC X12 997 (Functional Acknowledgement). This may have advantage in a one-to-many business partner scenario. Mass distribution of updates could be easily generated in response to legislation, etc..

Tool kits or personal computer EDI translation software are sometimes utilized by larger companies prior to implementing an Electronic Commerce (EC)/ EDI Initiative at the corporation. This may also be referred to as quick EDI because the implementation of tool kits or EDI on a personal computer requires a shorter time frame than implementing an EC/EDI initiative or EDI on other platforms.



Depending on the business need, any one of the alternatives depicted in the Alternative section may be applicable. Hence, the recommendation made here is applicable to all of the alternatives discussed above. This recommendation is: Regardless of the alternative selected, pre-determined guidelines (industry wide) for developing or purchasing EDI translation software should be adhered to and consistent criteria utilized in evaluating this software. Reference Appendix E - Health Care Industry Guidelines for an example of specific industry guidelines. Reference Appendices A through D for examples of evaluation criteria and process.

In further support of this recommendation, there are some industries, health care for instance, that this becomes particularly significant. Due to the volume of the transactions as well as the magnitude of the potential implementation base (especially in instances of government legislation), these guidelines and evaluation criteria are critical. Health care is the retail trade of the electronic data interchange industry. For that reason, the functionalities and characteristics of translation software addressed in guidelines and evaluation criteria should be very specific -- something easily understood by a retail customer.

It is further recommended that "benchmarking" be conducted during the evaluation process regarding EDI translation software. (Reference the Alternatives section of this white paper for a more detailed explanation of benchmarking.)

In the event that a translator is bundled with telecommunication software adherence should be given to the pre-determined guidelines, and evaluation criteria. The coupled software should include but not be limited to the following capabilities:

In the event that a translator is bundled with application software, adherence should also be given to the pre-determined guidelines, and evaluation criteria. Additionally, criteria to evaluate the respective application relative to the particular business needs of the respective corporation should be formulated. All of these factors together should be considered instrumental in the decision making process.

The pre-determined guidelines and evaluation criteria must be reviewed and revised periodically to incorporate newer functionalities and capabilities. In this manner these documents are kept current with technology.