ASC X12 Insurance Subcommittee

Upward/Downward Compatibility
Implementation Guide 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 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


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

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.


-    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

-    Guides should be developed to promote transaction acceptance.

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


I    BACKGROUND                                   D2

II   CHALLENGE                               D3-D4

III  SCOPE AND OBJECTIVE                          D5

IV   ALTERNATIVES                                 D6-D7

V    ISSUES                                       D8

     VI   RECOMMENDATION                          D9

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.


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. 


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.  


Alternative I


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


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


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


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.


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