ASC X12 Insurance Subcommittee

Upward/Downward Compatibility
Testing 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 X12N.

A series of White Papers was constructed, each paper focusing on one 
of the six topics listed above.  The Testing 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 
Fifth Ave. Place                LOC 1-H-3 Meadows East          6802 Hillsdale 
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 Testing. 

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


By definition, a test is a means of examination, trial or proof.  The 
scope of this white paper is to address issues relative to the 
testing of ASC X12 transactions in various scenarios consistent with 
projected use.  Recommendations that best address these issues are 
explored.  An example of formal testing procedures is provided in the 


 Testing occurs prior to the ballot process.

 Testing criteria, scenarios and matricies are the responsibility of 
the respective Task Group of the transaction. The testing matrix 
should be as exhaustive as possible, containing many business 
scenarios.  The testing must be organized, controlled, monitored and 
the results evaluated.

 Testing is mandatory for new transactions.

 Testing for data maintenance is on a case-by-case basis.

 The testing results should be published. General errors and 
solutions need to be conveyed to ASC X12 work/task groups.  
Variations/deviations to the transaction or the implementation should 
be reported and incorporated appropriately.


Testing commences when the information is exchanged and translation 
is completed.  Telecommunication facilities are necessary to either 
retrieve or send information during the testing process.  
Implementation guides provide an overview of the entire information 
exchange process and may also address the testing process for  the 
transaction.  Testing must occur with each update or modification and 
must be addressed in Version Control.

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 
Fifth Ave. Place                LOC 1-H-3 Meadows East          6802 Hillsdale 
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

Table of Contents

 I.     BACKGROUND              F2
 II.    CHALLENGE                       F3-F4                                                                                             
 III.   SCOPE AND OBJECTIVE     F5-F6                                                             
 IV.    ALTERNATIVES            F7-F9                                                     
 V.     ISSUES                  F10                                                                       
 VI.    RECOMMENDATION  F11-F12                                                           
 VII.   APPENDICES                      F13-F18  

Within project life cycles, whether the projects are for product 
development, marketing or data processing, a phase within the project 
must be dedicated to TESTING.  By definition, a test is a means of 
examination, trial or proof. Major tasks that occur in this phase are 
performed in an exhaustive way to gain information concerning a 
potential implementation entailing much larger volumes while at the 
same time eliminating potential problems.  For instance, if a company 
is contemplating the production of a new product they will TEST the 
idea with a few customers.  In data processing, data depicting 
various scenarios is tried (TESTED) prior to an implementation into a 
full production environment.  There are several philosophies and 
mechanisms that are utilized in successfully completing a testing 

Tasks that are uniform amongst several projects are the formulation 
of a testing environment, exhaustive testing of as many variables as 
possible, documenting and evaluating the test results.  Various types 
of testing such as integration testing, stress testing and 
paralleling are commonly included in a comprehensive test plan.  
Results from the testing phase are used for decision making purposes 
to transcend to the implementation phase.

Historically, there have been a vast number of variables in any 
typical health care transaction. This high degree of variability has 
added a layer of complexity in the migration of health care to a 
standards based environment.  Currently there is no testing phase, 
consequently this increased complexity is not effectively addressed.

Details pertaining to recommended testing components and phases are 
located in Appendix A.

The complexity of implementing a standards based environment in 
health care has caused several problems.  For instance, in several 
Medicare implementations of the claim transaction (ASC X12 837) the 
mapping to the proprietary flat file requires multiple passes when 
utilizing commercially available Electronic Data Interchange (EDI) 
software (translator).  With each "pass" a point of failure is 
introduced.  Additionally, their are costs (development, maintenance, 
execution time) associated with these "extra" passes.  This 
particular problem is not unique to a single software vendor but 
spans throughout the vendor market. Many vendors agree that this 
transaction (ASC X12 837) is one of the most difficult transactions 
to map.  More than 700 million Medicare claims are processed 
annually. Further these claims and claim affiliated records tend to 
be of a higher degree of complexity than the traditional EDI 
transactions.  Therefore it is imperative that the translation 
process achieves optimum effectiveness.  The intent is to eventually 
reduce the size of the records, however the migration to a paperless 
environment must accommodate the current as well as the projected 
needs of the health care community because health care entities will 
be at varying stages of EDI/ Electronic Commerce (EC) implementation 
capability and capacity.

The testing of EDI (ASC X12 or EDIFACT) transactions presents a 
precarious situation in that the transactions become available for 
use after the drawing board stage (so to speak).  Transactions after 
successfully completing the ASC X12 voting ballot phase  "Draft 
Standards for Trial Use" (DSTU).  This means that these transactions 
are available for implementation into a business environment without 
evolving through a testing phase.  Even though the transactions go 
through the arduous scrutinization of architecture and technical 
assessment to ensure that the transactions are structurally and 
syntactically correct, no piloting or testing of the transaction 
occurs prior to DSTU status.  Thus the operational effectiveness is 

One of the reasons for this lack of testing is attributable to the 
current ASC X12 protocol. Testing simply is not inherent in the 
process.  Another reason is the reluctance of EDI translation 
software vendors to incorporate a transaction into it's software 
prior to the transaction reaching DSTU status.  This is 
understandable in the fact that it may be cost prohibitive to 
incorporate less stable transactions into the software.  Yet the 
testing of these transactions prior to their mass deployment is 
essential.  Hence a quandary exists.

Some industries have implemented EDI transactions extensively.  But 
no industry has attempted the lengths of a full scale industry wide 
implementation which will be required if legislation is enacted to 
mandate the utilization of standards in the health care community.  
With this magnitude of implementation, testing is a dire necessity. 
An additional business challenge for the health care industry is to 
modify it's business processes to encompass a virtual corporation 
type of environment.  In accomplishing this paradigm shift a 
migration from the current way of doing business to the new way of 
doing business must occur.  The tactical plan to achieve this 
migration will commence with our current processes and transactions, 
evolving to the desired environment.  Thus the vast number of 
variables must be addressed immediately.

Incorporation of the analysis of the business process and a thorough 
understanding of the business needs during the development cycle of 
the transaction or message is necessary so that the developed product 
fulfills the business as well as the data requirements.  "Paper 
Testing" should be incorporated during the development cycle to 
ensure that the business as well as the data needs are met.  Paper 
testing is the manual simulation of the utilization of the developed 
product (transaction or message) through mapping applicable business 
scenarios.  For example, if a transaction is applicable to both 
providers and payors of health care services, a provider and payor 
can separately perform the function of paper testing then exchange 
the scenarios with the appropriate information.  This would be the 
first "testing" performed regarding the transaction or message even 
though it is generally  considered external to the actual system 
development life cycle (SDLC) testing process.  The testing process 
should include both the business process/ functions together with the 
technical document itself, hence, addressing both the business and 
technical needs of the respective transaction or message.   

The scope of this white paper is to address issues relative to the 
testing of ASC X12 transactions and to make a recommendation that 
best addresses these issues.
The objectives of a formal testing phase are listed below.  These 
objectives not only assure a functional and operational transaction 
in a business environment but can also assure a technically 
proficient transaction process that is cost effective. 

         Confirm the ability to map (from the application to ASC X12 
and/ or from ASC X12 to the application) a proposed transaction or 
modification to a transaction.
         Assure translation performance.
         Assure cost effective transmission.
         Provide information for decision making.  (Cost efficiency, 
technical proficiency, business practicality, etc.).
         Provide a more comprehensive, complete product (transaction).
         Identify change impact on prior versions/ releases/ 
  Quantity (Mass deployment)
         Provide a "proof of concept" mechanism prior to deployment.
         Provide information to determine the most feasible tactical 
implementation plan in deployment.
         Validate data dictionary, utilization of code sets, and assure 
unambiguous data content.
         Highlight issues prior to mass deployment. Provides the 
capability to address these issues prior to implementation.
  Business (Industry)
         Assure industry business needs are met.
         Provide an opportunity to work in concert with the various 
entities involved in the implementation.
         Provide an opportunity for translation vendors, value added 
networks and other potential business partners to be an active 
participant with an industry in the deployment of ASC X12 standards.
         Better capability for smoother implementations of transactions.
         Better capability for more expeditious implementations.
         Better probability of less data maintenance to the transaction 
since testing involves real life business scenarios.
 Additionally, the inclusion of testing into the ASC X12 protocol 
provides for consistency with proven system development life cycle 
(SDLC) methodologies.  These widely used methodologies have 
overwhelmingly demonstrated the value of testing prior to 
implementation.  A scenario depicting the phases of the SDLC is 
provided in Appendix B.

Finally the process must assure the environment for the successful 
deployment of ASC X12 standards.  Testing provides an added value in 
that an industry can proactively identify and resolve potential 
problems/ limitations prior to deployment rather than be reactive 
after the transaction is available.

It is anticipated that for each of the following alternatives, 
expanded tutorials (implementation guides) with data dictionaries be 
formulated and readily available; thereby standardizing data content 
as well as the transactions themselves.  These documents should be 
complete, terse, succinct and unambiguous.

Alternatives I and II below depict variations of the current ASC X12 
protocol.  The current ASC X12 protocol in terse and succinct terms 

 1.     Design the transaction.
 2.     Vote (Membership ballot).
 3.     Formulate Type I tutorial.
 4.     Formulate Type II tutorial (if appropriate).
 5.     Implement.
Alternative I


With this alternative, the transaction development process would 
acquire/ reposition/ redefine steps as indicated below:

 1.     Design the transaction (current process but include paper 
testing).  Note: Also included is data maintenance.
 2.     Develop/ Revise expanded tutorials.
 3.     Develop/Revise national implementation guides( inclusive of data 
 4.     Test.
 5.     Vote (Membership ballot). 
 6.     Implement.
As indicated the tutorials are expanded and can become implementation 
guides.  Formulation of a data dictionary becomes an inherent step in 
the process.  Specifically, a data dictionary will assist the health 
care industry in standardizing the data content.  Testing also 
becomes an inherent step, occurring prior to the ballot process.  In 
this manner the completion of the testing phase becomes a pre-
requisite to the vote, thereby assuring the functionality and 
operability of the transaction.

 Alternative II


This alternative will add testing and the formulation of 
implementation guides (WEDI or otherwise) as suffixes to the current 
ASC X12 protocol.  Also added to the process is a transaction walk-
thru step where an ad-hoc group of industry and EDI experts review 
the pending transaction prior to the vote to evaluate the 
effectiveness and the efficiency of the transaction from both an 
industry and EDI perspective.  Currently the transaction is reviewed 
by architecture and technical assessment.  This alternative proposes 
that prior to the review of these groups, this ad-hoc group (in the 
case of health care perhaps Work Group 11) will review the 
transaction for the above stipulated qualities.
The suffix or addendum pertaining to testing and implementation 
guides can or can not be used by an industry.  The emphasis here is 
if lack of testing is perceived to be an obstacle in the mass 
deployment of the use of the transaction then a testing phase will be 
included in the tactical implementation plan for that deployment.  
The formulation of implementation guides becomes an inherent step in 
the process. The tutorials may be utilized as the basic foundation 
and expanded upon for the implementation guide formulation.  Time 
will need to be allocated within the industry tactical plan for these 
steps.  In this manner the ASC X12 protocol remains basically intact 
and the deployment becomes industry specific.  The protocol for this 
alternative is:

 1.     Design the transaction.
 2.     Transaction walk-thru.
 3.     Vote (Membership ballot).
 4.     Formulate Type I tutorial.
 5.     Formulate Type II tutorial (if appropriate).
 6.     Test.
 7.     Formulate Implementation Guide(s).
 8.     Implement.

 Alternative III


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.  Problems found while testing a transaction AFTER it 
reaches this status undergoes a time consuming process for 
         The efficiency and effectiveness of the transaction relative to 
industry use as well as EDI needs to be paramount along with syntax.
         Guidelines need to be formulated to be utilized during the 
developmental phase of the transaction.
         Formulation of an ad-hoc or core group of expertise to create 
these guidelines and to become part of the review process.
         An opportunity to re-engineer the businesses processes exists 
within health care.  EDI and the formulation of transactions to 
assist in this endeavor should be maximized.  EDI/ EC coupled with 
efficiencies need to support this shift in business process.
         As new functional areas within industries (managed care for 
example) appear, the developmental process for transactions to 
support these new areas need to be cognizant of the opportunities to 
create/ alter business processes by maximizing EDI/ EC.  

After evaluation of each of the alternatives described above, it is 
recommended that Alternative I INCORPORATE A TESTING PHASE PRIOR TO 
THE BALLOT PROCESS be the alternative implemented in resolving this 
dilemma.  Alternative I was selected because testing occurs prior to 
the vote.  In this manner the item in consideration for vote has 
already been proven to be functional and operational in the business 
environment.  Testing prior to the voting ballot will provide the 
opportunity to resolve many issues, questions, and concerns currently 
identified in the ballot process or the post ballot phase.  Thus this 
alternative also offers the potential for a reduction in the number 
of reballots necessary to achieve DSTU status.  Transactions can be 
initially presented to the voting community with a much higher level 
of confidence.  Typically in a system development life cycle (SDLC) 
one or many testing phases occur prior to implementation.  
Alternative I follows this proven protocol.  Reference Appendix B for 
a scenario depicting testing in a SDLC.

Testing prior to vote ensures that the product presented for vote is 
a proven product.  This recommendation advocates a business 
philosophy that has been utilized for years and that is ...... the 
deliverable (transaction/ maintenance) be a proven (tested) product 
prior to mass marketing (deployment).  Most businesses would accept 
nothing less.  

Prior to the commencement of the testing phase, the work group 
developing or maintaining the transaction should work closely with 
Architecture Review to assure the best product to test.  Once the 
work group decides that the transaction is ready to test, normal X12 
protocol would be conducted until final approval from Technical 
Assessment.  Testing criteria, scenarios and matrices can be 
formulated by any group or organization such as HCFA, AHA, or the 
respective ASC X12 work group responsible for the transaction or 
message.  The testing phase must be organized, controlled, monitored, 
and the results evaluated.  Any variations/ deviations to the 
transaction set or message and implementation guide are to be 
communicated in writing to the appropriate responsible entities (ie. 
ASC X12 work group, WEDI, etc).  General errors that occurred during 
the testing phase with their respective solution should be conveyed 
to work groups undergoing the transaction development process to 
avert the creation of the same or similar errors.  Publication of 
testing results should be inherent in the respective implementation 
guide pertaining to the transaction.  Testing would be mandatory for 
new transactions, while testing with respect to data maintenance can 
be conducted on a case by case basis.

The ideal testing environment would include the most exhaustive 
testing matrix possible.  Addressed in the matrix would be various 
and many business scenarios.  The final product from the testing 
process would assure optimal performance of the transaction for mass 
deployment by an industry while being cognizant of individual 
business partner site considerations.

 Ultimately commercially available software should be able to be 
purchased by a technically unsophisticated person (non Electronic 
Data Processing (EDP) buyer) with the knowledge that the product has 
been verified to perform the desired functionality.  This process 
inclusive of testing, implementation guides and data dictionary can 
allow the software to be ASC X12 compliant but be ASC X12 industry 
compliant.  For instance some software producers have referred to the 
ASC X12 835 Claim/ Payment Advice as the 835 as well as the HCFA 835, 
the abbreviated 835, etc..  Each of these connotes a different 
utilization of the 835.  These variances must be accommodated and 
delivered in such a fashion to the purchasing entity that a "turn 
key" solution is achieved.              

 Appendix A



Trading partner responsibilities with respect to testing shall be the 
completion of the testing phases outlined below as well as the 
communication and coordination of those activities encompassed in 
these tasks.


Paper testing is the manual simulation of the utilization of the 
developed product (transaction or message) through mapping applicable 
business scenarios.  This would involve cross referencing application 
data to/ from respective transactions or messages.  Historically this 
was done on paper, thus paper testing.  However with today's various 
technologies, this testing can be conducted in a more automated 

Site testing shall be defined as testing that occurs at the business 
partner's site that is pertinent to the project (transaction).  Site 
testing shall be the responsibility of the respective business 
partner, however in an effort to promote project harmony business 
partner personnel at each location should work in concert with one 
another.  Areas where this team concept has been especially 
successful are in project initiations and problem resolutions.  As 
with all projects, internal or external to a corporation, 
communication is critical.  An EDI project has both internal and 
external components whose success level of interface and 
communication directly relates to the success of the overall project 
and implementation.  Ultimately the success of each of these site 
projects becomes an intricate factor in the successful deployment of 
the transaction in the health care industry.  


Unit testing is testing that has a focus to a specific unit of work.  
For example, the unit test of a map for an ASC X12 transaction would 
entail utilizing the map to convert application flat file information 
to an ASC X12 format.  Another example of unit testing would be the 
execution of the EDI translation software in editing and converting 
transactions from/ to ASC X12 and application flat file formats.   
Unit testing should be complete prior to integration (system) 


Integration testing relative to EDI involves the execution of the 
pertinent application system in conjunction with the EDI system.  For 
example, a claim payment application system would produce a file 
containing remittance and payment information that would serve as 
input to the EDI system that produces the ASC X12 835 (Claim Payment/ 
Advice).  Integration testing at each respective site should be 
conducted autonomous to the other business partner(s).  Integration 
testing between EDI and the application system at the site should be 
conducted prior to or be in it's final stages when communication 
testing commences.  Integration testing should be considered a 
distinct step in the process.


Connectivity testing is a test of the physical network and includes 
those tasks that tests the telecommunications aspects of the exchange 
of information between business partners.  Some of the major tasks 
include but are not limited to installation/ use of modems or 
communication lines, utilization of a mutually agreed upon 
communications protocol and the verification of bi-directional 
electronic transmissions.  This test is be a pre-requisite to end to 
end testing.


End to end testing typically refers to the application to application 
test involving the exchange of information between trading partners.  
The end to end test commences at the sending trading partner's 
application system and terminates upon successful processing at the 
receiving trading partner's application system.  This test 
constitutes integration testing at each business partner site as well 
as the test of telecommunications between/ amongst trading partners.  
For example, the Human Resource system at the company site generates 
a change in enrollment of an employee; the change is converted to the 
ASC X12 834 format; the ASC X12 834 is electronically transmitted to 
the receiving trading partner (or a VAN); the receiving trading 
partner receives the ASC X12 834, interprets the change, issues an 
acknowledgement and integrates the change into an enrollment 
application system.  Hence completing the application to application 
cycle.  A mutually agreed upon number of end to end tests should be 
successfully performed prior to the production implementation.


Parallel testing shall encompass the production simulation of the 
transaction to be implemented in conjunction with the actual current 
production environment. The time frame of the parallel should be 
mutually agreed upon between the business partners.  The intent of 
the parallel is to ensure that through simulation the proposed 
production environment will produce the desired or anticipated 
results.  The parallel test(s) constitutes several end to end tests.  
Parallel testing may also be utilized for a minimal time period after 
the implementation of the transaction into a production environment.  
This action and time frame should be mutually agreed upon between the 
business partners and stipulated in a trading partner agreement.


The testing associated with modifications or enhancements to a 
transaction should follow the same testing phases stipulated above.  
A project schedule for the proposed change/ enhancement should be 
formulated inclusive of testing criterion.  The proposed project 
schedule should be mutually agreed upon between business partners.  
Testing an enhancement or modification prior to production 
implementation should be mandatory.

 Appendix B

The scenario depicted below employs phases that are included in most 
system development methodologies.  A hypothetical project has been 
stipulated.  Each of the SDLC phases have been identified in the 
first column.  The second column contains a sample list of activities 
that are performed within the respective phase of the life cycle.  
The third column indicates activities that are performed in order to 
fulfill the stipulated project.


 HCFA has directed that a claim edit be added to both the batch and 
on-line portions of the Medicare system.


 Identify request.  - 
Perform feasibility 
study if applicable.
 Review and obtain a 
clear understanding 
of the HCFA request.

Preliminary Analysis 
and Definition
 Survey effected 
 Determine extent of 
change (ie. within 
the company, external 
to the company, 

 Identify Business 
 Identify Technical 
 Determine effected 
business functions/ 
processes within the 
company as well as 
effected business 
partners (ie. claim 
acquisition, claim 
storage, claim 
adjudication, etc.).
 Determine technical 
requirements (ie. 
batch, on-line, both, 

 Perform General 
Systems Design.
 Perform Detailed 
Systems Design.
 Complete Program 
 Complete program 
specifications to 
incorporate the new 
edit into the system.

 Create software.
 Code new edit into 
the software.



 Formulate test plans 
and matrices.
 Perform any and all 
testing as 
 Conduct unit 
 Conduct system 
integration testing.
 Conduct acceptance 

 Establish a 
 Conduct training.
 Migrate from a test 
environment to a 
 Update system and 
user documentation.
 Issue provider 
documentation for 
move to production.
 Install edit into 

Post Implementation 
 Analyze projected 
time frames and costs 
relative actuals. 
 Identify issues.
 Identify impacts.
 Idenitfy future 
 Document and 
communicate results.
 Assimilate audit 
 Conduct post 
implementation audit.

 Testing is an integral part of the SDLC.  It is performed prior to 
implementation into the production environment.  In this manner any 
potential problems or impacts can be identified and addressed in the 
test environment; thus causing the least amount of impact to all 
effected areas as well as to the overall business. 

Testing White Paper

Testing White Paper


Testing White Paper


Testing White Paper


Testing White Paper


Testing White Paper