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 Version Control 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 1099 North MeridanSuite1100 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 firstname.lastname@example.org email@example.com 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. Modifications to this document can be submitted by any X12 member and will be processed in accordance to X12N and X12N Task Group 2 operating policies and procedures. 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 Version Control. The scope, recommendation and relationship pertaining to the Version Control White Paper is: Scope Version Control, relative to EDI, addresses the management of the migration of a business environment from one version/ release of a transaction to a subsequent version/ release of the transaction. The scope of this white paper is to address version control relative to the development of ASC X12 transactions via the ASC X12 process especially to support mass deployment of transactions. Recommendation - Version/release/subrelease of standards should be implemented by consensus in an industry fashion no more frequently than once per year. - Version control should be synchronized with national implementation guide distribution. - At a minimum the current place holder minus two standardized implementations should be supported. - Obsolescence by transaction by consensus. - Provisions should be made for emergency releases to accommodate legislation. - No modifications are necessary to the ASC X12 data maintenance process. Relationship Translation software must be able to accommodate the new releases/ versions of the transactions within a reasonable period of time. Testing is of particular significance since new versions/ releases of transactions require a trail period of use prior to implementation. Typically implementation guides will correspond to a specific version/ release of a transaction and are issued in conjunction with the release. 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 firstname.lastname@example.org email@example.com VERSION CONTROL WHITE PAPER _________________________________________________________________ Table of Contents Page I BACKGROUND E2 II CHALLENGE E3-E4 III SCOPE AND OBJECTIVE E5 IV ALTERNATIVES E6-E10 V ISSUES E11-E12 VI RECOMMENDATION E13-E14 I BACKGROUND Version control relative to proprietary or lower case EDI has traditionally been determined between business partners along with any other involved entities. Hence the typical scale of implementation has been localized to participating entities rather than industry wide. The exception to this type of implementation is Health Care. The Health Care industry is different because most health care entities have implemented a proprietary formats (UB92) simultaneously for their entire client base which encompasses thousands of providers, numerous payors and associates. Historically the health care community in both the public and private sector has utilized the same release of a national format (UB92, NSF, etc.) thus minimizing the need for version control. Another example of mass implementation within health care is the pharmaceutical area of the industry. Pharmacies are implementing and utilizing the National Council for Prescription Drug Programs (NCPDP) formats. Both Medicare and pharmacy implementations have targeted the health care specific functionalities within a health care entity. With standards based EDI, a health care entity or affiliate will address germane health care needs and general administrative business needs as well. Version control relative to the transaction(s) influencing these various functions within a corporation can be accommodated technically (as indicated above). However, in current EDI implementations, strategic business directions and other management issues influence the migration to a more recent version/ release/ subrelease of the ASC X12 standards on a per trading partner basis. As a result there is a potential of multiple versions of a standard across the spectrum of one's business partners. Version management in standards based EDI has been accommodated within the business strategy/ direction of the affected business (trading) partners. Compliance and editing relative to a specific version of a transaction is inherent in most commercially available translators. For the most part, this technical upward/ downward compatibility functionality has worked and continues to work quite well. This freedom results in a need for version control. Consequently, version control becomes more of a business/ management issue rather than a technical one. II CHALLENGE Version control is not new to the business arena. Many industries have struggled with version control management for years. Standards based EDI requires a different look at version control since maintenance of the transactions, issuance of versions/ releases/ subreleases and applicability to various lines of business and business partners is external to the entity disseminating the change/ enhancement. The maintenance of the transactions and the issuance of versions/ releases/ subreleases is accomplished through the ASC X12 process and requires adherence to ASC X12 procedures. Timing relative to both development and maintenance of ASC X12 standards is directly affected by the time frames within the ASC X12 protocol but generally not synchronized with a specific business and its respective business partners. For instance, in health care this timing becomes significant, even critical, in the management of the mass deployment of a standard as a required by a federal directive or other government legislation. Adding complexity to the formulation of a mass deployment strategy is the fact that there exists various levels of EDI expertise in the health care business arena. This variance directly affects the level of coordination and support required and the ability to/ reality of massively deploying a transaction(s). Some industries have been utilizing standards based EDI for a number of years and have achieved a certain level of expertise and fluency. To other industries such as health care, standards based EDI is relatively new. In addition, the use of a transaction by multiple business partners (Coordination Of Benefit claims) can further complicate the process. Also, the transaction revision is often the result of new or expanded code sets. The necessary level of EDI fluency has not been reached yet. While education is an important factor in any deployment strategy formal control of migration is critical to a deployment strategy of this magnitude. Many industries tend to be purchase order, production, ship, and invoice oriented. Many service industries seem to be of the same philosophy. However, health care businesses or affiliates have two major emphasis of business --- health care services which is germane and general business which often becomes secondary, somewhat peripheral. General business for health care entities encompasses the typical functional areas of any business that are necessary as a mere fact of being a business (i.e. purchase orders for supplies, shipments, invoices, accounts payable, accounts receivable etc). All of these areas have standards based EDI transactions that can be utilized. The utilization of these transactions along with the version implemented becomes a strategic business decision as well as a question of resource management. The challenge becomes addressing version control relative to mass deployment of a transaction(s) while considering the issues depicted above. The major question becomes how to implement EDI in health care since the skill level or a government mandate in the industry may warrant mass deployment by version rather than by individual business need. Additionally the problems, concerns, and issues resulting from mass implementations by version must be addressed and managed. Hence, the actual change is one task and the distribution of the change to a mass user base with user (trading partner) satisfaction is another. III SCOPE AND OBJECTIVE The scope of this white paper is to address version control relative to the development of ASC X12 transactions via the ASC X12 process in conjunction with the mass deployment of the transactions. Other situations, conditions will be addressed as the need arises. The primary objective for version control is to minimize the amount of negative impact to the business environment of those entities implementing a standard (transaction). This is especially critical in instances of industry wide (mass) deployment of a standard. A secondary objective is to control the frequency of change so that levels of stability are achieved. Another objective is to determine the most pragmatic, tactical way to support deployment of standards in an industry in a time frame that is conducive to the business need or in a time frame that has been imposed (legislated). The ultimate goal is to promote standardization (successfully implement national standards) in a manner that is least disruptive to the operational environment but is achievable in an expeditious and economical manner. This implementation needs to achieve uniformity, that is all involved entities are utilizing the same transactions with the same results. A major benefit to this standardization is reduction in administrative cost. The more quickly, organized, tactical and planned manner of deployment, the more likely a successful initial industry wide implementation can be achieved and benefits realized. Additionally this implementation strategy should provide for an industry the ability to subsequently migrate to a more current version of a standard. Version control is the means to the accomplishment of these objectives. In summary, business partners electronically exchanging information must know the business as well as the technical requirements so that there is a complete understanding in expectations among all business partners. In short, in the case of the health care industry, providers and payors must know what and when they must place in this exchange of information (transaction and envelop) so that it is understood by all ASC X12 players. IV ALTERNATIVES Alternative I VOLUNTARY IMPLEMENTATION, SYNCHRONIZE VERSION CONTROL WITH NATIONAL IMPLEMENTATION GUIDE DISTRIBUTION. With this alternative health care entities can elect to implement the health care transactions in concert with the National Implementation Guides. Coordinating implementation of the standards with the guides can insure uniformity in the version of the transaction that is implemented at a certain point in time. Utilization of the segments and data elements inherent to the transaction will be in accordance to the respective National Implementation Guide. New versions of the transactions will necessitate issuance of a corresponding national implementation guide. This alternative implies that not only do national implementation guides be created with a release of a transaction but that it needs to be all encompassing to the various business needs of the health care entities that will be utilizing the transaction. Mass deployment of a standard or transaction relative to this alternative could be accomplished as long as ASC X12N Task Group 2 compliance is clearly and unambiguously defined. Additionally businesses would need to perceive the achieved benefits of conforming to the ASC X12N Task Group 2 standards/ implementation guides as necessary and of high priority to their business environment. Mass deployment necessitates this realization be simultaneous within the industry. Consensus within the industry must be achieved prior to mass deployment. Alternative II FEDERAL REGULATIONS INITIALLY IN SYNCHRONIZATION WITH NATIONAL IMPLEMENTATION GUIDES, ULTIMATELY BY BUSINESS NEED. This alternative requires that federal regulations be issued to mandate the use of the transaction as well as a specific version/ release/ subrelease of a standard. Upon the first few federal regulations the formulation of a respective national implementation guide will be required to assure uniformity in implementation. Compliance shall be in accordance to the respective national implementation guide. This implies that with the first few regulations the national implementation guide needs to be all encompassing to the various business needs of the health care entities that will be utilizing the transaction. Once a certain level of EDI expertise is achieved in the health care community, implementation upgrades to the transactions can be on individual business need basis. For example, initial and subsequent issuance of federal regulations for a specific federal agency such as the Health Care Financing Administration (HCFA) would stipulate the specific version/ release/ subrelease as well as the respective national implementation guide that would be utilized by their health care domain. Federal regulations, however, are only applicable to a certain domain of the entire health care community. Hence this alternative would be applicable only to that sector. Other sectors of the health care community would need to voluntarily follow suit. Historically this has been the case however this diversity has significant adverse implications to version control and mass deployment of standards. Version control relative to the mass deployment of the standards under this alternative is achievable but applicable to only the sector of the health care community that is under this jurisdiction. All other health care entities and any other affiliated business partners would be under voluntary. Version control in the remaining sectors would again be somewhat unmanageable since various levels of standards may be utilized at implementation time. Alternative III FEDERAL LEGISLATION INITIALLY IN SYNCHRONIZATION WITH NATIONAL IMPLEMENTATION GUIDES, ULTIMATELY BY BUSINESS NEED. This alternative necessitates enactment of federal legislation by Congress. It requires specific verbiage in the bill to denote a specific version/ release/ subrelease that is to be enacted. In the initial bill to legislate these standards utilization of the corresponding national implementation guide would also need to be stipulated. This would require the formulation/ existence of a national implementation guide that addresses the business needs of the entire health care community. Once a certain level of EDI expertise has been achieved in the health care community, implementation upgrades to the transactions can be on a business need basis. Subsequent federal legislation can stipulate adherence to a specific version/ release/ subrelease of a standard. These federal laws must supersede state law and encompass the entire health care community and affiliated business partners (as appropriate). For example, WEDI has recommended federal legislation for the four core health care transactions, namely the ASC X12 834 Benefit Enrollment and Maintenance, the ASC X12 835 Claim Payment/ Advice, the ASC X12 837 Health Care Claim, and the ASC X12 270/ 271 Health Care Eligibility/ Benefit Inquiry/ Information. If the WEDI National Implementation Guides were all for the same version/ release/ subrelease then the federal legislation could stipulate mandating the use of the transaction and national implementation guide at that specific level for the entire health care community. Additionally, some industries are affected by laws that are regulated by various federal government departments. For example, the health care industry through the growing Medicare and Medicaid programs is primarily regulated by the Department of Health and Human Services. However, Employee Retirement Income Security Act (ERISA) laws are regulated by the Department of Labor. ERISA allows employers the option of: 1) obtaining health insurance through a state regulated carrier; or, 2) developing their own self insurance plan. As the number of self-insured plans continue to grow there are problems with ERISA plans trying to comply with certain types of insurance practices. While states regulate the insurance purchased by employers, the employers who opt for self-insured ERISA plans are not bound by the same state and medical laws. Consequently, states may have to pass laws which explicitly stipulate how ERISA plans should comply with certain types of insurance practices. This legislation can also include administrative data collection and application processes. There is a need to establish and specify the same administrative base-line criteria and time frames that would require state ERISA plans to implement and enforce as they would for other insurance practices. However, a law passed by Congress (preemptive legislation) could require states to enforce the same laws for employers regulating the health insurance requirements with those of self-insured ERISA plans. Similar to the ERISA dilemma are the differing state approaches to data collection and reporting of health care information. These differing approaches can often impede the use of more efficient electronic exchange of information. In some instances, significant problems occur when dealing with a multitude of states because of this variety. As a result expensive customization occurs in the handling and reporting of information to meet individual state requirements. A uniform and consistent data collection process along with a well defined mechanism for the exchange of information would simplify the transition to the electronic world of information exchange. Coordinating state requirements at a national level (via federal legislation) for data collection and exchange would ease the administrative burden. In the absence of national legislation, it may behoove an industry to define a series of guidelines for states to follow. Since this alternative directly effects the entire health care community specifically, it provides for the most manageability over version control relative to the mass deployment of the standard in the health care industry. Providing that federal legislation spans the entire health care community this alternative addresses the entire health care environment. Alternative IV VERSION CONTROL WILL BE ESTABLISHED AND MONITORED THROUGH A TECHNICAL ADVISORY GROUP (TAG) Inherent in many of the Health Care Reform bills that are currently before Congress is the formulation of a Technical Advisory Group (TAG). This group, whether it be formulated as a resultant of federal legislation or the by-product of an industry business need, could be empowered to establish and monitor the implementation of standards with version control encompassed in the process. This jurisdiction would span the entire health care community and it's affiliates. The group can additionally monitored the production of implementation guides to support the mass deployment of the standards. Education can be utilized by this group as an avenue to initially promote the awareness of EDI while formulating an electronic infrastructure for the industry. Composition of the TAG should entail all of the key players in health care including but not limited to: Health Care Financing Administration (HCFA), American Medical Association (AMA), American Hospital Association (AHA), National Council Prescription Drug Programs (NCPDP), American Dental Association (ADA), the Blue Cross Blue Shield Association (BCBSA), and commercial insurers. As with the other alternatives, the deployment of the standards can be done in concert with national implementation guides. The production of these implementation guides to correspond with the various versions of the standards can be a deliverable from this group. Alternative V VOLUNTARY IMPLEMENTATION, VERSION CONTROL WILL BE PERFORMED ON AN INFORMAL BASIS. (STATUS QUO) As stipulated earlier in the Challenge section of this document a dilemma definitely does exist. A successful mass deployment of standardized formats in the health care industry is predicated upon resolving this dilemma. V ISSUES - The time consuming process for data maintenance to a draft standard. - Achievement of a level of EDI expertise in the health care community commensurate to the effort involved. - Enactment of federal legislation and federal regulations are external to ASC X12 and other associative organizations. - Level of cooperation and communication between ASC X12, WEDI, federal agencies and other associative organizations. - Time requirements for federal regulations and legislation. - Limitation of the span of federal regulations to a single sector of the health care community. - Frequency of change. - Alternatives to changing versions. - A precise definition of ASC X12N Task Group 2 compliance and what are the consequences. - Determination of the consequences of not being ASC X12N Task Group 2 compliant. - An unambiguous definition of standards (ASC X12N Task Group 2) detailing the difference between industry flexibility and standardization. - Formulation of Implementation Guides and an industry Data Dictionary. - Some industries are affected by laws that are regulated by various federal government departments. These laws would need the ability to coincide and be duly applicable. - Many states are legislating standardization in the absence of federal legislation. Entities dealing with a variety of states will need to accommodate and manage the various requirements of each of the states. - Defintion of industry consensus.VI RECOMMENDATION After evaluation of each of the alternatives described above, it is recommended that Alternative I VOLUNTARY IMPLEMENTATION, SYNCHRONIZE VERSION CONTROL WITH NATIONAL IMPLEMENTATION GUIDE DISTRIBUTION be the alternative implemented to address version control. Alternative I provides a coordinated effort between voluntary implementation which may result from prudent business decisions and/ or market pressures as well as a mechanism (implementation guide) for an industry to control this implementation. This alternative was selected because it involved no external entities to an industry. Other alternatives (Alternatives II and III) contained involvement of branches of the federal government. Alternative II effected a portion of the industry thus leaving a large portion of the industry at status quo. If federal legislation is enacted then Alternative III becomes viable. Alternative IV required empowerment of a technical advisory group. If legislation or regulation empowers an entity then this alternative becomes viable. If this empowerment occurs then this document can be revisited at the appropriate time. Alternative V was not selected because it promotes status quo. It is further recommended that versions/releases/ subreleases of the standards be implemented in an industry fashion, such as health care, no more frequently than once per year. This may be a calendar or fiscal year, whichever is mutually agreeable between the involved entities in the industry. Some industries may urge their business entities to support at a minimum the current version of the standards as well as a mutually defined number of other versions. For instance the health care industry may require that their respective business entities support the version 3 release 7 subrelease 0 of the standards. Thereafter, an annual review by the business entities in the industry will determine the necessity and migration to the next standardized industry implementation. (Review to occur at a major trimester meeting and through annual letter ballot). As industry consensus is achieved for the implementation of subsequent versions/releases/subreleases definition of obsolescence must also be determined. Hence, obsolescence for each transaction is determined by consensus (review to occur at a major trimester meeting and through annual letter ballot), industry implementation is by version/release/subrelease. It is recommended that at a minimum the current place holder minus two standardized implementations be supported. Other versions may continue to be supported but not exclusively. Imperative to this philosophy is the clear, concise, and unambiguous definitions of ASC X12N Task Group 2 standards and ASC X12N Task Group 2 compliance. (Reference Translation Software White Paper). These definitions, compliance and obsolescence, will be defined by the Implementation Group of X12N Task Group 2 (Health Care). Data maintenance pertaining to the transactions would still occur as it currently does, however an industry can decide to implement a specific version/ release/ subrelease on an annual or otherwise timely basis. Migrating an entire industry or a vast number of business partners to a single version/ release/ subrelease can be a rather ambitious task relative to synchronization, organization and management. The cost effectiveness of version control is evident by evaluating the effectiveness and efficiency of migrating from a single base then migrating from multiple bases. For example, Medicare currently has implemented version 3051 of the ASC X12 835 (Claim Payment/ Advice) for their contractors and their health care providers. This implementation base can eventually well exceed 800,000. In the event that HCFA directs their constituency to migrate to another version of the ASC X12 835 (version 3070 for instance) the synchronization, organization and management of this migration is more easily achieved due to a common starting base (version 3051). Migration from an uncommon starting base adds various levels of complexity in the synchronization, organization and management of this process. Provisions will need to be made for emergency releases, especially regarding legislative actions that reference specific versions of the ASC X12N Task Group 2 standards. The ASC X12 protocol as well as version control will need to accommodate the time requirements of such situations. The version control protocol should accommodate emergency releases in addition to annual release since the only differentiation is in regards to time. Changes or upgrades relative to versions, releases, sub-releases need to have some predictability for industries such as health care, where mass deployment is required. There should be a window of time during which the industry would upgrade. In health care, for instance, most insurers would probably be willing to support two versions of the standard(s) ---- the current and the most previous. There would be no version/ release/ sub-release changes in the interim absent business need. This recommendation is relative to mass deployment situations only. It does not mean to preclude individual business relationships where the business environment necessitates version upgrades to conduct business.