ASC X12 Insurance Subcommittee

Upward/Downward Compatibility
Version Control White Paper


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:


              Translation Software


              Implementation Guides

              Version Control


 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

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


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.


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:


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.


-    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

-    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. 


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
                        VERSION CONTROL WHITE PAPER

                             Table of Contents


I    BACKGROUND                                   E2

II   CHALLENGE                               E3-E4

III  SCOPE AND OBJECTIVE                          E5

IV   ALTERNATIVES                                 E6-E10

V    ISSUES                                       E11-E12

VI   RECOMMENDATION                          E13-E14


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. 


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.

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


Alternative I


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


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


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

Alternative IV


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

Alternative V


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.


     - 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

     - Frequency of change.

     - Alternatives to changing versions.

     - A precise definition of ASC X12N Task Group 2 compliance and what are the

     - Determination of the consequences of not being ASC X12N Task Group 2

     - 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
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.