FOREWORD 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 ASC 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: Education Translation Software Telecommunication Implementation Guides Version Control Testing 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 ASC X12N. A series of White Papers was constructed, each paper focusing on one of the six topics listed above. The Implementation Guide 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 818 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 Note: 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. EXECUTIVE SUMMARY There are many key elements in an EDI Initiative including but not limited to Translation Software, Telecommunication facilities, Implementation Guides, Testing, Version Control and Education. These key components can be implemented independently or in conjunction with one another, depending on the business need. It is strongly suggested that the determination of business needs and requirements be the first task in an EDI initiative. 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.. Special Task Group 2 - Upward/Downward Compatibility developed white papers in each of these subject areas.. An Executive Summary and Forward prefaces each white paper. The Executive Summary will outline the scope and recommendation of the respective white paper as well as their relationship to an overall EDI Initiative. This particular executive summary and white paper is specific to Implementation Guides. The scope, recommendation and relationship pertaining to the Implementation Guide White Paper is: Scope The purpose of Implementation Guides relative to transaction sets is to convey the intent or use of a transaction pertaining to a business scenario(s). Implementation guides should be version/ release/ subrelease specific. The scope of this white paper is to outline the use of implementation guides as a necessary tool for rapid mass deployment of standard ASC X12 transaction sets. Recommendation - Create a single unambiguous data dictionary. - Create a single unambiguous implementation guide for each transaction. (Multiple guides when a transaction is used for more than one purpose). - Implementation Guides should provide a definition for implementation compliance. - Guides should be developed to promote transaction acceptance. Relationship Implementation guides become of significant use after the translation software is installed and a transaction is ready to be used in a business scenario. An implementation guide that provides an overview of the entire information exchange process and addresses, in general terms, functions included in telecommunications, testing, version control and translation software phases. 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 818 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 Implementation Guide White Paper _________________________________________________________________ Table of Contents Page I BACKGROUND D2 II CHALLENGE D3-D4 III SCOPE AND OBJECTIVE D5 IV ALTERNATIVES D6-D7 V ISSUES D8 VI RECOMMENDATION D9 I BACKGROUND The American National Standards Institute (ANSI) chartered the Accredited Standards Committee (ASC) X12 to develop uniform standards for the electronic exchange of business transactions. ASC X12 has historically defined transactions with the expectations that each trading (business) partner will agree on the specific details of an implementation. Usually, these details have been specified by one of the business partners in an implementation guide. An implementation guide is a document which specifies format, data content and usage conventions for exchanging standard electronic business transactions between trading (business) partners. Guidelines can also be formulated by industry groups to convey the intent of the industry in the utilization of the respective transaction. Implementation guides are utilized in the deployment of a transaction in a respective user community whether it be between individual business partners, intra-industry or inter-industry. Today there are no standard table of contents for implementation guidelines. Some guidelines contain the absolute minimum amount of information while other guides portray great detail in utilizing a standard transaction. Most business partners create guidelines specific to their needs, while guidelines created by an industry group tend to be more global in nature by addressing the needs of an entire industry. Some industries such as health care are attempting to develop national implementation guides. These guides were initially the product of the Health Care Financing Administration in the deployment of the Claim Payment/ Advice (ASC X12 835) and the Claim (ASC X12 837). The Workgroup for Electronic Data Interchange (WEDI), which was formulated in November of 1992 under Secretary of Health and Human Services Sullivan, has also been instrumental in the formulation of national implementation guides. WEDI's emphasis has been on the four core transactions --- Claim Payment/ Advice (ASC X12 835), Claim (ASC X12 837), Benefit Enrollment and Maintenance (ASC X12 834) and Eligibility (ASC X12 270, 271). The intent of these national implementation guidelines is to promote a uniform and unambiguous implementation of a transaction within the health care industry. Implementation guides may also be user guides since their purpose is to assist the user in the implementation of a specific transaction. Implementation guides can not only assist the technical user but also may define business policies and procedures as well. Thus guidelines can be of both a technical and business nature. I CHALLENGE A challenge pertaining to implementation guides is the proliferation in the development of implementation guides. The publication and distribution of several implementation guides for a single transaction results in great difficulty to be implementation compliant to all of the documents. For example in health care, HCFA became concerned that mass deployment with multiple implementation guides could cause providers significant implementation difficulty and expense. ?ASC X12 has historically defined transaction sets with the expectation that each pair of trading (business) partners will agree on the specific details for implementation. Usually, these details have been specified by one of the trading partners or in some instances an industry group in an "implementation guide". This approach has worked well for large, EDI-capable companies with a limited number of trading partners. This approach may not work well in all industries. In health care, for example, the environment is quite different. Claims can originate from any one of a million or so providers, some of whom have minimal EDI expertise. At the same time, the health care transaction sets are some of the most complex ASC X12 transactions. The health care industry does not have a single data dictionary that unambiguously defines and codifies (in business terms) the entire data content within a transaction. Finally, there has not been a single health care industry group chartered to develop and maintain implementation guides pertaining to standards-based EDI transactions. Mass deployment in this type of environment will be more difficult, costly and time-consuming. In some industries, there is growing legislative support at both the state and national level of "administrative simplification" based on the rapid deployment of standard ASC X12 formats. Trading partners must be able to consistently exchange electronic transactions whether the "electronic" partnership is new or existing. This consistency must be achieved in a clear and unambiguous implementation of the standard. Consistency is critical in mass and rapid deployment environments. The formats and data content must be unequivocally identical. The objective is for every reader to interpret an implementation guide exactly the same way. In this manner, the standard will be standardized. While this is a significant challenge, work has already begun in some industries. In early 1995, several national implementation guide developers in the health care industry recognized the critical value of a single national implementation of a standard and began collaborating to that end. This paper is intended to reinforce the importance of and complements this effort. III SCOPE AND OBJECTIVE The scope of this white paper is to address implementation guides as a tool for rapid mass deployment of ASC X12 transactions for health care. However, while it is recognized that the needs (rapid mass deployment) and complexities (size of transactions, number of trading partner links) of health care are unique, other sectors of insurance and other industries may also find this paper useful. The primary objective of an implementation guide is to "standardize the standard". The guide should be so specific that there should be one and only one correct way to produce a given transaction. One entity using the guide to create and send a transaction should be assured that any other entity receiving the transaction can receive and process it. The guide should prescribe data content, as well as, format. However, an implementation guide is useful in clarifying the business functionality supported by each trading partner. Another objective of an implementation guide is to define the criteria for implementation compliance. These are the criteria that a transaction must satisfy before it can be labeled compliant with the implementation guide. The ability to define, certify, and advertise implementation compliance is crucial for unsophisticated EDI consumers. For example, in health care implementation compliance would allow providers and payers to exchange transactions with any implementation compliant trading partner. Efforts are under way to formulate a single data dictionary for health care. By definition, a data dictionary is a catalog containing the names and structures of all data types. This single data dictionary will be utilized in all implementation guides pertinent to the industry. In this manner an attempt to standardize data content is being made. IV. ALTERNATIVES Alternative I CREATE A SINGLE DATA DICTIONARY WITH A SINGLE IMPLEMENTATION GUIDE FOR EACH TRANSACTION SET (BUSINESS PURPOSE). This is the only alternative that allows each trading partner to implement only one translator mapping. This alternative provides flexibility to forward transactions to additional trading partners (e.g., misrouted claims or claims for secondary payment). A trading partner would not have to be aware of the full transaction routing path when creating a transaction. This alternative allows compliance without individual trading partner negotiation. This alternative is easiest to synchronize with a nationally controlled version plan. Alternative II CREATE A SINGLE DATA DICTIONARY WITH MULTIPLE IMPLEMENTATION GUIDES FOR EACH TRANSACTION SET. This alternative provides standardization of data content, data elements and segments for specific purposes. Trading partners would need to create multiple maps depending on the implementation guide used. This alternative allows more flexibility in the configuration of the transaction for trading partner relationships.. Effective rerouting or forwarding of a transaction, requires that the originator know the full routing path at transaction creation time. Alternative III CREATE MULTIPLE DATA DICTIONARIES WITH MULTIPLE IMPLEMENTATION GUIDES PER TRANSACTION SET. This alternative could be achieved through consensus of smaller groups (rather than the entire health care community). Trading partners would need to create multiple maps depending on the data dictionaries and implementation guides used. Once begun, this alternative would be difficult to standardize to a single implementation. This alternative would create greater difficulty in synchronizing data dictionaries, implementation guides and ASC X12 versions. Alternative IV CREATE NO STANDARD IMPLEMENTATION GUIDES. MAKE ALL AGREEMENTS BETWEEN INDIVIDUAL TRADING PARTNERS. This alternative allows maximum flexibility for individual trading partners. No industry consensus would be needed before use. This alternative would permit hundreds of implementations. No improvement over a multiple proprietary format environment. Once begun, this alternative would be difficult to standardize to a single implementation. This alternative would create greater difficulty in synchronizing data dictionaries, implementation guides and ASC X12 versions. V ISSUES - Development of a single unambiguous data dictionary would need to be developed from multiple sources within an industry. - Consensus by all of the various industry factions involved, would have to be reached on data content and meaning. Involved entities would have to reach a consensus on the exact data to be included in a standard business transaction. This involves standardizing what data is in each transaction. - Consensus would have to be reached by all involved entities on the exact segments, data elements and data content to be conveyed in unique locations within each transaction set. This involves standardizing how the data is conveyed. - Legislation mandating ASC X12 transaction sets has already been passed in several states and proposed in several more. Acceptance of a national implementation guide in these states may be an issue. - National legislation in support of a single implementation would speed deployment and minimize differences. However, legislation which does not recognize the significance of a single unambiguous implementation guide might just add to the confusion. - The distribution of implementation guides is a concern. The media and logistics for mass distribution of the initial guides and periodic updates must be planned. Large quantities may be required, which brings up an issue of production cost. - In order to facilitate mass deployment, the right to reproduce documents must be supported in a cost effective manner. - Maintenance and quality assurance must be consistent with policies and procedures developed by the implementers.. - Entities may need to change their legacy systems to operate with the data in the standard transaction sets. This could make consensus more difficult and delay the ultimate implementation. V RECOMMENDATION For mass deployment situations, as in health care, Alternative I - Create a single data dictionary with a single implementation guide for each transaction set (business purpose) is recommended. A single unambiguous data dictionary will be created and maintained. It will uniquely name and clearly define all health care business data elements in business terms (i.e. these are not ASC X12 data elements such as qualifiers, references numbers and the like; these are the real business items that are transmitted in ASC X12 data elements). This data dictionary will be the basis of all implementation guides and will also be a tool for standards developers. The data dictionary will prescribe the ASC X12 data element, segments and transaction sets that are used to convey each business data element. Additionally, a single unambiguous implementation guide for each transaction set (business purpose; multiple guides when a transaction set is used for more that one business purpose) should be created and maintained. This is the only approach that actually "standardizes the standard" and creates a true national standard. A true national standard is the only way to route transactions between unanticipated trading partners. This is the alternative that minimizes the difficulty of synchronizing and controlling versions of the data dictionary, implementation guides and ASC X12 transactions. While the most difficult alternative for achieving consensus, it is the one that minimizes implementations and cost at each trading partner site. It is further recommended that the implementation guide contain a working definition of implementation compliance as described in section III. A guideline should be developed to promote transaction acceptance by the receiving trading partner. To comply with this requirement the guideline would specify that extraneous information, written in conformance with ASC X12 requirements, would not cause a transaction to be rejected by a receiver. Finally, a single body should have the responsibility for executing these recommendations. For the health care industry, the health care task group of the insurance subcommittee (ASC X12N/TG2) should be the responsible entity for implementing these recommendations.