ASC X12 Insurance Subcommittee

Upward/Downward Compatibility
Translation White Paper Part II

(Part I)


Appendix A

EVALUATION PROCESS FOR EDI TRANSLATION SOFTWARE



NOTE: The following EVALUATION PROCESS FOR EDI TRANSLATION SOFTWARE is an example. This process can be utilized as a template and customized to particular business and technical requirements of the respective entity pursuing an EDI initiative.

The following depicts an example of an EVALUATION PROCESS FOR EDI TRANSLATION SOFTWARE. This example was utilized in a health care environment but can be customized/ expounded upon for any industry. This process can be utilized as a template and customized to particular business and technical requirements of the respective entity pursuing an EDI initiative. It is absolutely imperative that both business and technical requirements have been identified and addressed during the evaluation process. This process contains five phases which are outlined as follows:

  1. OVERVIEW
  2. PRE-EVALUATION PHASE
  3. EVALUATION PHASE
  4. SELECTION PROCESS
  5. POST INSTALLATION AUDIT


Details pertaining to each of these phases follow.


I. OVERVIEW

As a result of the health care industry embarking on this era of a paperless environment many new and different needs have surfaced. This migration to a paperless environment involves the employment of standards based transactions especially code sets (formats) in a telecommunication (Computer - Computer) environment. The standards based transactions are created and maintained by the X12N subcommittee of ASC X12. Utilization of ANSI ASC X12 standard transaction formats necessitates computer software to convert from/to a trading partner's application format from/to the X12 standard format. Many commercial EDI translation software (translator) products are available for this task.

The selection of an EDI translation software vendor must be as objective and quantitative as possible. Areas to be evaluated include technical functionality, capability and sophistication. User friendliness is also important but is subjective in nature. As products are evaluated against one another the criteria for user friendliness become more and more objective. Appendix C - Vendor Rating Form provides a list of the various technical functionalities that should be considered when evaluating EDI translation software. Additionally, an evaluation of the company itself as well as the EDI translation software should occur. The selected vendor or company will be your business partner just as those business partners who exchange information. (Reference Appendix C Vendor Rating Form).

There are two phases that typically occur prior to the translator selection process. First the PRE-EVALUATION PHASE addresses those tasks or items that need to be completed prior to the EVALUATION PHASE. These tasks are internal to the corporation and involve the top decision makers of the corporation. Business decisions made during this phase include the timing of the migration to an electronic environment with the business partner(s) and the formulation of a strategy to achieve this migration. Technical decisions include formulation of tactical implementation plans addressing such items as central or distributive telecommunications and EDI translation as well as hardware and software determinations. Typically a Needs Analysis or Assessment is completed addressing the above stipulated areas.

The second phase is the EVALUATION PHASE and involves the formulation of criteria to properly evaluate products to support EDI. Appendix B - Initial Questions for Translator Vendors and Appendix C - Vendor Rating Form are provided as examples. Functions such as telecommunications and translation must be included in this phase. The criteria identifying the business decisions and the evaluation of telecommunication hardware and software are in the TELECOMMUNICATIONS White Paper.

The SELECTION PROCESS specifies the tasks to be performed in selection of a vendor and a translator product. This includes the tasks performed in making the decision regarding the purchase of the translation software.

The SUMMATION is a recapitulation of events within the selection process and should include a POST-EVALUATION AUDIT AND REPORT. All deliverables throughout the project should be addressed in the report. Information gleaned from the POST- EVALUATION AUDIT will be beneficial for future evaluations. (For instance, a corporation may elect to purchase batch translation software first and at some point later purchase interactive translation software. Some corporations implement a PC solution as a short-term solution to their EDI initiative migrating later to a mainframe solution, thus repeating the selection process.)


II. PRE-EVALUATION PHASE

Before focusing on the selection of commercially available EDI translation software, a health care entity must first perform certain business functions that all businesses, not just health care, must conduct in formulation of a business direction and corresponding strategy for the corporation. The first task of an EDI initiative in a corporation is to conduct a Needs Analysis. This Needs Analysis should address but is not limited to the following items:


There are several commercially available EDI translation software packages spanning various hardware platforms. These packages are at various levels of business and technical sophistication and capabilities. Results from the Needs Analysis normally eliminates certain types of EDI translation software and telecommunication techniques because of hardware requirements. This aids in the selection process for the EDI translation software because it excludes hardware specific EDI translation software vendors from consideration.

As with other business studies, consultants (EDI or EC) may be utilized to augment an entity's or corporation's industry or business expertise with technical EDI expertise. Several well known consulting firms devote key individuals or perhaps an entire department to support EDI and EC. Additionally some hardware and software vendors have EDI or EC consultants as part of their staff.


III. EVALUATION PHASE

Once it has been determined that a commercially available EDI translation software will be utilized to support the EDI initiative of the corporation, formulation of selection criteria becomes a necessity. The criteria for purchasing other types of software such as accounting systems, patient account systems or claims processing systems is readily known or can be easily acquired through business analysts or consultants. In the health care industry a certain comfort level has been reached with the purchase of these types of application software. On the other hand, the criteria for purchasing EDI translation software is much more technical in nature and requires both strategic business and technical expertise. The intent, here, is to avoid the purchase of a "three wheeled" car. The GUIDELINES in Appendix A - Health Care Industry EDI Translation Software Guidelines can be utilized to assist in this endeavor.

A corporation may elect to create a Core Evaluation Team whose responsibility is to attend all of the presentations and select the successful vendor and product. This team can be composed of both business and technical personnel but should have individuals fluent in EDI and EC. Typically there are various screening steps that occur prior to the creation of the "short list" candidates. The first screening is achieved from the Needs Analysis as indicated above. Further the second screening can be achieved by formulating a few "key" questions (reference Appendix B - Initial Questions for Translator Vendors) to be utilized with the list of candidates. Responses received to these questions can eliminate some candidates. After this further reduction in candidates, presentations or proof of concepts are presented by the vendors. A tool implemented to assist in these presentations is a Vendor Rating Form. (Reference Appendix C - Vendor Rating Form for an example.) The conclusion of the presentation can be the completion of the form by the evaluator(s).


IV. SELECTION PHASE

The information and forms are assimilated into overview and summary documents. A summary form can be utilized to pictorially depict the representative vendors that are considered in this phase. An example of a Vendor Rating Summary Form is located in Appendix D. This information is then analyzed and reviewed. If enough information is present to best fit a vendor/ product to the business requirements then a selection is made. If additional information is necessary then the presentation process may be repeated or the information may be obtained through non- presentation means.

It may be beneficial for the evaluators or the evaluation team to meet and discuss the assimilated information in the decision making process. Site visits of current customers utilizing the translator(s) can provide additional information to make the final decision. The contract with the vendor culminates the selection process. Generally this will be the same as any legal contract but with specifics regarding EDI software.


V. POST INSTALLATION AUDIT

The summation or concluding step of the selection process involves the conduction of a Post Evaluation Audit. Documentation from each of the phases of the selection processes should be accumulated and formulated into one document for future reference. Typical tasks performed as a result of audits should occur, these may include but are not limited to:

tasks that can be repeated in the future tasks that are to be modified to reflect for future implementations perform modification of such tasks identify things to be avoided measurement of the results to the initial goals



Appendix B



INITIAL QUESTIONS FOR TRANSLATOR VENDORS



The following is a list of questions that have been prepared as an initial evaluation tool for evaluating your translation software as well as the associated related services.

  1. Is full compliance checking performed? If yes, what types of compliance checking
    are performed?

  2. Is there a mapping feature that non-programming personnel may utilize to map
    business information to the ANSI ASC X12 transactions? If yes, is this feature
    on-line and dynamic? Can this functionality be performed simultaneously while
    the software is executing?

  3. Is the software table driven? If yes, are the tables maintained on-line? Do they
    have dynamic update capability? Please stipulate what is contained in the trading
    partner table and what information can be modified dynamically? Is there a copy
    capability within the table, for example can a map for one trading partner be
    copied and then modified for another?

  4. Are there trading partner file(s) or table(s)? If yes, is maintenance of the table(s)
    or file(s) an on-line function?

  5. Does the software support the full ANSI ASC X12 transactions sets? If yes, are
    multiple versions of the transaction sets supported concurrently? Can the version
    be stipulated at run time?

  6. Are the health care transaction sets (ANSI ASC X12 --- 834, 835, 837 etc)
    supported?

  7. Are the customized versions of the health care transaction sets supported?

  8. How will your company accommodate U.S. legislative, HCFA, and WEDI
    implementation time frames?

  9. Does the software support EDIFACT? If so, how is this accomplished? Do you
    support Status 0 messages? Do you support the health care messages?

  10. How does error processing occur? Are there capabilities to suspend (place in
    error status) interchanges, functional groups, and documents? Is there an on-line
    function for error correction?

  11. Is the translator compatible with other translators? Please elaborate.

  12. Realizing that a release of a version of ANSI ASC X12 standards is issued after full
    X12 meetings, do you provide these updates to your software? If yes, what is the
    earliest and latest time frame of deployment of the updates after the issue of a
    version release? Are these updates available as part of the maintenance
    contract? Is education a feature of the maintenance contract or the purchase
    contract?

  13. What is the fee associated with this maintenance? What is the frequency of the
    fee?

  14. Is there a "HELP desk" to support questions and/or problems? If yes, are there
    separate "help" desks to support mainframe, personal computer, and
    communication questions/problems?

  15. Do you currently have clients who are utilizing one or more of the health care
    transaction sets? If yes, please provide references. If no, please provide
    references of those clients that may be utilizing transactions such as the ANSI
    ASC X12 820, 830, 850, 856, 861, 864, etc.

  16. Are reports or reporting capabilities provided? If so what types of reports are
    provided? Please provide examples.

  17. What security features are present in the software? Does the software provide
    encryption capabilities? If yes, at what level can encryption be performed...
    interchange, functional group, document...? Does your product interface with
    other security packages?

  18. Are backup and recovery procedures provided? If so, what are they? For IBM
    environments, do you provide the JCL for these procedures as well as the jcl for
    execution of the translator?

  19. What audit and control features are there?

  20. Are there implementation project plans that your company provides for installation
    of the software? Are they customized to the client's needs? Please provide a
    sample plan.





Appendix C

Vendor Rating Form




SAMPLE

ELECTRONIC DATA INTERCHANGE (EDI)

VENDOR RATING FORM




Vendor Name: _________________________________      Date: ____________



Use the following scale to rate each vendor issue:

Excellent - 4 Good - 3 Adequate - 2 Poor - 1 Non-existent - 0


General Issues (High Importance) Rating Weight Score
1 Interchange Control Segments   3  
2 Validate Sender/Receiver ID   3  
3 Validate Password   3  
4 Validate Communication ID   3  
5 Compliance Checking - General   3  
6 Compliance Checking - Trans. Set/Message   3  
7 Compliance Checking - Segment   3  
8 Compliance Checking - Data Elements/ Codes   3  
9 Compliance Checking - Composites   3  
10 Conditional Field Editing   3  
11 Duplicate Document Check   3  
12 Parameter Driven Software   3  
13 Report Generation   3  
14 Upgrade Implementation   3  
15 Inherent Security Features   3  
16 Help Desk Capabilities   3  
17 Help Desk - Resolution Time   3  
18 Portion of Software that is Online   3  
19 Portion of Software that is Batch   3  
20 Educational Services   3  
21 Implementation Time Frame   3  
22 VAN Compatibility   3  
23 Accomodation ( ANSI X12, EDIFACT,etc)   3  
24 Company Experience/History   3  
25 Product Cost - Additional Costs   3  
26 Data Compression   3  
27 Customized Implementation   3  
28 Consulting Services/On Site Services   3  
29 Generation of Control Numbers   3  
30 ANSI X12 - 997/Control   3  
31 997 Interchange Reconciliation   3  
32 Online Reconciliation of Overdue 997   3  
33 Full Audit Trail of EDI Process   3  
34 Oldest Version Support   3  
35 Transaction Message Size Limit   3  
36 Documentation Provided/Maintained   3  
37 Benchmarking   3  
38 Proof of Concept   3  


SAMPLE

ELECTRONIC DATA INTERCHANGE (EDI)

VENDOR RATING FORM



Use the following scale to rate each vendor issue:

Excellent - 4 Good - 3 Adequate - 2 Poor - 1 Non-existent - 0


Mapping Issues (High Importance) Rating Weight Score
1 Flow or Level Control   3  
2 Data Positioning Capabilities   3  
3 Reformat Data Sequence   3  
4 Ignore Data Element Capabilities   3  
5 Combine or Separate Field Capabilities   3  
6 Field Flag Capabilities   3  
7 Source/Target Level Capabilities   3  
8 Map Interchange/Functional Group Data   3  
9 Multiple File Access   3  
10 Manipulate Data/Multiple Transactions   3  
11 Boolean Logic and Exit Code Capabilities   3  
12 Share Rules and Data Among Maps   3  
13 Arithmetic Operations   3  
14 Graphical User Interface   3  
15 Table Look-up during Mapping   3  
16 Trading Partner Processing   3  
17 Accessing System Information   3  
18 Mapping Reports/Cross Reference Reports   3  
19 Test to Production Map Migration   3  
20 Version Migration Aids   3  
21 Compliance Checking per Transaction   3  
22 Compliance checking per Trading Partner   3  
23 Availability of Sample Maps   1  


Trading Partner Profile (High Importance) Rating Weight Score
1 Segment Terminator   3  
2 Element Separator   3  
3 Sub-element Separator   3  
4 Functional Acknowledgement - Group Level   3  
5 Functional Acknowledgement - Transaction Level   3  
6 Functional Acknowledgement - Interchange Level   3  
7 Functional Acknowledgement Type   3  
8 Type of Interchange Header / Trailers   3  
9 Respond with TAI Interchange Acknowledgement   3  
10 Control Number Verification - Group Level   3  
11 Control Number Verification - Transaction Level   3  
12 Control Number Verification - Interchange Level   3  
13 Routing to 'Test' files or 'Live' Files   3  
14 Free Form Optional Fields for Misc. Information   3  
15 Unique Trading Partner Functionalities   3  


SAMPLE

ELECTRONIC DATA INTERCHANGE (EDI)

VENDOR RATING FORM



Use the following scale to rate each vendor issue:

Excellent - 4 Good - 3 Adequate - 2 Poor - 1 Non-existent - 0


General Issues (Medium Importance) Rating Weight Score
1 Application Interfaces or Overlays   2  
2 Hard and Soft Error Processing Capabilities   2  
3 Specify Return Codes   2  
4 EFT Interface Capabilities/Deferred TX   2  
5 Modular Software Interfaces   2  
6 "Dedicated" Support Capabilities   2  
7 Multiple Product Discounts/Upgrade Discounts   2  
8 Other (Health Care) Installations   2  
9 Company Annual Report   2  
10 Company Businesses/Alliances   2  
11 International Communication/EDIFACT   2  
12 Separate Files for X12 and Proprietary Data   2  
13 Distinct Output Files for Different Locations   2  
14 Create or Customize New Transaction Sets   2  
15 Test to Production Transaction Set Migration   2  
16 User Groups   2  
17 Hardware/Software Prerequisites   2  
18 Maintenance of Transaction Sets   2  
19 Online Viewing/ Printing of Transaction Sets   2  
20 Establish Conversion Tables   2  
21 Establish Validation Tables   2  
22 Post Installation Certification   2  


General Issues (Low Importance) Rating Weight Score
1 Source and Object Code to Client   1  
2 Transmission Software Availability   1  
3 Mailbox Capabilities (If Applicable)   1  
4 "Turn Key" Solution   1  
5 Communication Protocols Support (If Applicable)   1  
6 Direct Dial Capability (If Applicable)   1  
7 Retry Capability (If Applicable)   1  
8 On Demand Transmission (If Applicable)   1  
9 Status Update of Delivery   1  
10 Remote Initiated File Selection   1  
11 Continuous Receive Capability   1  
12 Accounting and Chargeback Information   1  
13 Selection Criteria for Audit Reports   1  
14 Degree of Integration with VAN   3  


SAMPLE

ELECTRONIC DATA INTERCHANGE (EDI)

VENDOR RATING FORM



Use the following scale to rate each vendor issue:

Excellent - 4 Good - 3 Adequate - 2 Poor - 1 Non-existent - 0


Data Storage Features/Support (Medium Importance) Rating Weight Score
1 Online Document Tracking   2  
2 Online Document Control   2  
3 Online Data Display   2  
4 Duplicate Document Checking   2  
5 Multi-Division ID Audit Option   2  
6 Data Archiving   2  
7 Field Level Editing of Application Data   2  
8 Audit Trail of Data Changes   2  
9 Online Document Distribution/Processing   2  


Future Issues (High Importance) Rating Weight Score
1 Event Drive EDI   3  
2 Fast Batch EDI   3  
3 Interactive EDI   3  
4 Conversational EDI   2  
5 EDIFACT Migration   3  
6 Electronic Commerce Capability   2  
7 Magnetic Stripe Reader Capabilities                            1  
8 Bar Code Integration   1  
9 Open EDI   1  


Use the following scale to rate each vendor issue:

Excellent - 4 Good - 3 Adequate - 2 Poor - 1 Non-existent - 0


Name ______________________________________________________




Appendix D

Vendor Rating Summary Form

SAMPLE

ELECTRONIC DATA INTERCHANGE (EDI)

VENDOR RATING SUMMARY FORM



General Issues (High Importance)        
1 Interchange Control Segments        
2 Validate Sender/Receiver ID        
3 Validate Password        
4 Validate Communication ID        
5 Compliance Checking - General        
6 Compliance Checking - Trans. Set/Message        
7 Compliance Checking - Segment        
8 Compliance Checking - Data Elements/ Codes        
9 Compliance Checking - Composites        
10 Conditional Field Editing        
11 Duplicate Document Check        
12 Parameter Driven Software        
13 Report Generation        
14 Upgrade Implementation        
15 Inherent Security Features        
16 Help Desk Capabilities        
17 Help Desk - Resolution Time        
18 Portion of Software that is Online        
19 Portion of Software that is Batch        
20 Educational Services        
21 Implementation Time Frame        
22 VAN Compatibility        
23 Accomodation ( ANSI X12, EDIFACT,etc)        
24 Company Experience/History        
25 Product Cost - Additional Costs        
26 Data Compression        
27 Customized Implementation        
28 Consulting Services/On Site Services        
29 Generation of Control Numbers        
30 ANSI X12 - 997/Control        
31 997 Interchange Reconciliation        
32 Online Reconciliation of Overdue 997        
33 Full Audit Trail of EDI Process        
34 Oldest Version Support        
35 Transaction Message Size Limit        
36 Documentation Provided/Maintained        
37 Benchmarking        
38 Proof of Concept        
0 0 0 0


SAMPLE

ELECTRONIC DATA INTERCHANGE (EDI)

VENDOR RATING SUMMARY FORM



Mapping Issues (High Importance)        
1 Flow or Level Control        
2 Data Positioning Capabilities        
3 Reformat Data Sequence        
4 Ignore Data Element Capabilities        
5 Combine or Separate Field Capabilities        
6 Field Flag Capabilities        
7 Source/Target Level Capabilities        
8 Map Interchange/Functional Group Data        
9 Multiple File Access        
10 Manipulate Data/Multiple Transactions        
11 Boolean Logic and Exit Code Capabilities        
12 Share Rules and Data Among Maps        
13 Arithmetic Operations        
14 Graphical User Interface        
15 Table Look-up during Mapping        
16 Trading Partner Processing        
17 Accessing System Information        
18 Mapping Reports/Cross Reference Reports        
19 Test to Production Map Migration        
20 Version Migration Aids        
21 Compliance Checking per Transaction        
22 Compliance checking per Trading Partner        
23 Availability of Sample Maps        
0 0 0 0


Trading Partner Profile (High Importance)        
1 Segment Terminator        
2 Element Separator        
3 Sub-element Separator        
4 Functional Acknowledgement - Group Level        
5 Functional Acknowledgement - Transaction Level        
6 Functional Acknowledgement - Interchange Level        
7 Functional Acknowledgement Type        
8 Type of Interchange Header / Trailers        
9 Respond with TAI Interchange Acknowledgement        
10 Control Number Verification - Group Level        
11 Control Number Verification - Transaction Level        
12 Control Number Verification - Interchange Level        
13 Routing to 'Test' files or 'Live' Files        
14 Free Form Optional Fields for Misc. Information        
15 Unique Trading Partner Functionalities        
0 0 0 0


SAMPLE

ELECTRONIC DATA INTERCHANGE (EDI)

VENDOR RATING SUMMARY FORM



General Issues (Medium Importance)        
1 Application Interfaces or Overlays        
2 Hard and Soft Error Processing Capabilities        
3 Specify Return Codes        
4 EFT Interface Capabilities/Deferred TX        
5 Modular Software Interfaces        
6 "Dedicated" Support Capabilities        
7 Multiple Product Discounts/Upgrade Discounts        
8 Other (Health Care) Installations        
9 Company Annual Report        
10 Company Businesses/Alliances        
11 International Communication/EDIFACT        
12 Separate Files for X12 and Proprietary Data        
13 Distinct Output Files for Different Locations        
14 Create or Customize New Transaction Sets        
15 Test to Production Transaction Set Migration        
16 User Groups        
17 Hardware/Software Prerequisites        
18 Maintenance of Transaction Sets        
19 Online Viewing/ Printing of Transaction Sets        
20 Establish Conversion Tables        
21 Establish Validation Tables        
22 Post Installation Certification        
0 0 0 0


General Issues (Low Importance)        
1 Source and Object Code to Client        
2 Transmission Software Availability        
3 Mailbox Capabilities (If Applicable)        
4 "Turn Key" Solution        
5 Communication Protocols Support (If Applicable)        
6 Direct Dial Capability (If Applicable)        
7 Retry Capability (If Applicable)        
8 On Demand Transmission (If Applicable)        
9 Status Update of Delivery        
10 Remote Initiated File Selection        
11 Continuous Receive Capability        
12 Accounting and Chargeback Information        
13 Selection Criteria for Audit Reports        
14 Degree of Integration with VAN        
0 0 0 0


SAMPLE

ELECTRONIC DATA INTERCHANGE (EDI)

VENDOR RATING SUMMARY FORM



Data Storage Features/Support (Medium Importance)        
1 Online Document Tracking        
2 Online Document Control        
3 Online Data Display        
4 Duplicate Document Checking        
5 Multi-Division ID Audit Option        
6 Data Archiving        
7 Field Level Editing of Application Data        
8 Audit Trail of Data Changes        
9 Online Document Distribution/Processing        
0 0 0 0


Future Issues (High Importance)        
1 Event Drive EDI        
2 Fast Batch EDI        
3 Interactive EDI        
4 Conversational EDI        
5 EDIFACT Migration        
6 Electronic Commerce Capability        
7 Magnetic Stripe Reader Capabilities        
8 Bar Code Integration        
9 Open EDI        
0 0 0 0


Grand Total All Issues        
0 0 0 0




APPENDIX - E

Health Care Industry EDI Translation Software Guidelines




EDI STANDARDS CONVENTIONS

The Health Care industry will adopt only official versions/releases of standards developed by national standards-setting bodies. To date, the Health Care industry has adopted only American National Standard Institute (ANSI) Accredited Standards Committee (ASC) X12 standards. Health Care Industry participants typically are required to support the most recent American National Standard version and at a minimum the two most recent ASC X12 releases of these standards.

Business needs inclusive of but not limited to government mandates, legislation or market pressures will dictate when other Health Care participants must support these releases. A copy of the Release document is available by writing to or calling:

ASC Xl2 Secretariat
Data Interchange Standards Association, Inc.
1800 Diagonal Road, Suite 355
Alexandria, Virginia 22314-2852
(703) 548-7005

The following supporting standards documents are necessary to properly use the transaction set standards:

ASC Xl2.3 Data Element Dictionary
ASC Xl2.6 Application Control Structure
ASC Xl2.22 Data Segment Directory

The Data Element Dictionary and Data Segment Directory relative to the transaction to be implemented are included with the publication available from DISA. The Application Control Structure is also available through DISA. Health Care industry participants should acquire documents relative to the version and release of implementation.


HEALTH CARE INDUSTRY IMPLEMENTATIONS

The Health Care Industry will utilize the National Implementation Guides for each transaction. Currently these guides have been synthesized by the Workgroup for Electronic Data Interchange (WEDI) Committee(s) respective to the transactions. The intent of these National Implementation Guides is to promote uniform implementations of the transaction sets amongst the various entities in the health care industry. The National Implementation Guides are based on specific version/ release/ sub-release of the standards but for the most part are easily adapted to other version/releases. Be aware that there may be some major differences between the releases especially in content and/or structure.


HEALTH CARE INDUSTRY APPROVED DEVIATIONS FROM STANDARDS

Health Care published conventions may deviate occasionally from the official version/release of standards. By policy, the Health Care Industry will deviate only when a needed maintenance action has been approved by the body responsible for maintaining the standard, but the change has not yet appeared in the official version/release of the standard. This deviation should be limited to instances where an early install program is required. There are no approved deviations from any of the version/releases of the endorsed ASC X12 standards listed in the "Standards Supported" section of this document. This is particularly significant in instances of government legislation.

ENVELOPING REQUIREMENTS

The Electronic Data Interchange structure provides the user of the standards with multiple levels of control to ensure data transaction integrity and routing. This is accomplished by using header and trailer control segments, or envelopes, designed to identity uniquely the start and end of interchanges, functional groups, and transaction sets.

INTERCHANGE CONTROL

The Health Care industry requires the use of an envelope at the interchange level and has adopted the Interchange Control Header/Trailer (ISA/IEA) for control and audit information. An important function of the Interchange Control envelope is to identify uniquely the sender and receiver for delivery purposes. To date, the Health Care industry has been utilizing the provider number, payor number or agent identifiers for identification purposes. The ISA/IEA envelope also provides key control information such as a control number and a date/time stamp. It is recommended that a perpetually incremented control number assigned by the sender be utilized for audit and control purposes. For recommended usage of ISA/IEA data element values consult the National Implementation Guides.

FUNCTIONAL GROUP CONTROL

The Functional Group Header/Trailer (GS/GE) allows similar transaction sets to be grouped together. Each GS/GE contains its own control number for audit and error recovery purposes. It is recommended that this control number be perpetually incremented based upon sender/receiver/functional group combination. Another important function of the GS Header is to group together transaction sets destined for the same physical location and/or computer system. It is recommended that the GSO2/GS03 sender/receiver codes uniquely identify the final locations sending and receiving the functional group.



The Functional Group envelope also identifies the Version/Release of the standards to which the transaction sets conform. Typically for health care industry groups using the ANSI ASC X12 standards, the following convention will be used to denote the Version/Release in the Functional Group Header (GSO8):

Position Content
1-4 Major Version Number
5 Release Level of Version
6 Sub-release level of Version
7-12 Industry-assigned Code

ASC X12 assigns codes in positions 1-6. For more information consult Data Element 480 Version/Release/Industry Identifier Code in the X12 standards manual.



APPLICATION LEVEL ACKNOWLEDGEMENTS

ASC X12.20 FUNCTIONAL ACKNOWLEDGEMENT (997)

The ANSI ASC Xl2 997 transaction set has been designed to allow trading partners to establish a comprehensive control function as a part of their business exchange process. This acknowledgement process between trading partners facilitates control of multiple interchanges (batches) amongst multiple trading partners. There are many EDI implementations that have incorporated the acknowledgement process, for control purposes, in all of their electronic communications.

The ANSI ASC X12 997 transaction is typically utilized as a functional acknowledgement to a previously received interchange. Many translators can automatically generate this transaction set through parameter settings. Additionally translators will automatically reconcile acknowledgements to interchanges. The benefit to this process is that the sending trading partner can determine what the receiving trading partner has received. Reports are generated by the translator software to monitor this reconciliation process. An ANSI ASC X12 997 acknowledgement indicates only that the received interchange was syntactically correct/incorrect. This distinguishes them from an application acknowledgement which addresses the data content and network acknowledgement which provides the indication of the status of the transmission.

With any information flow an acknowledgement process is essential. An "automatic" acknowledgement process is recommended between trading partners and it is recommended that the ANSI ASC X12 997 be utilized. The report functionality within the translator software should also be utilized to monitor this activity.



HEALTH CARE

TRANSLATION SOFTWARE GUIDELINES


The following translation software guidelines have been formulated for the Health Care Industry:

Administrative Support
X12 Standards Support
Customer Support
Operational Support
Future Considerations

Those guidelines denoted by an asterisk (*) are strongly recommended. The items listed should be considered during the EDI translation software evaluation process and contract negotiations.

HEALTH CARE INDUSTRY

EDI TRANSLATION SOFTWARE GUIDELINES



ADMINISTRATIVE SUPPORT


  1. * PUBLISHED CAPABILITIES MUST BE MET.

    The "delivered" software must meet the "published" software capabilities.

  2. TRANSLATION SOFTWARE PRODUCTION RELEASE CREDITS.

    When delivered software does not meet the minimum operational and functional expectations, the receiver of the software should be given a rebate equal to the cost of correcting the faulty software. This does not imply a rebate for minor software fixes supplied by the vendor.

  3. TRANSMISSION STATISTICAL INFORMATION.

    The software should provide appropriate control management and statistical reporting by trading partners. This functionality would include but not be limited to the number of documents by document type, total characters by document type, and total transmitted characters for third party invoice reconciliation.

  4. MULTI-SITE PRICING DISCOUNTS.

    The software vendor should offer pricing discounts if the software is resident at various locations in the enterprise.

  5. UPGRADE DISCOUNTS.

    The software vendor should offer pricing discounts for the software upgrades to cover their translation software modifications/ enhancements and to support new structural features within the standards.

  6. * SOFTWARE MAINTENANCE OPTION.

    The software vendor should offer an optional software maintenance contract. ANSI ASC X12 versions and releases should be covered by the maintenance contract. Reference the Version Control White Paper.

  7. SOURCE CODE PLACED IN ESCROW.

    This would be for software vendors only providing software object code. If future viability of the product/vendor is uncertain, a copy of the software source code must be placed in escrow, preferably with a third party entity.

  8. * IMPLEMENTATION OF TRANSLATION SOFTWARE

    The translation software vendor should provide a tactical implementation plan for implementation of their translation software.

  9. SOFTWARE TRIAL PERIOD.

    The software should be available for a mutually agreeable evaluation period at no cost.



X12 STANDARDS SUPPORT


  1. * BROAD RANGE CAPABILITIES.

    The software should support the ASC X12 standards tat support both directly and indirectly the current and future health care business needs as well as applicable general business needs.

  2. * TIMELY MAINTENANCE.

    Software upgrades, versions and releases should be distributed in a time frame conducive to the health care environment with special considerations for legislative and Health Care Financing Administrative (HCFA) mandates supporting an early install time frame. Reference the Version Control White Paper for additional information.

  3. * FLEXIBILITY.

    TABLE DRIVEN.

    Variable data and associated system functions should be table driven. The software should only change when Xl2 syntax changes. Tables should be readily accessible by the user in an on-line fashion and contain the ability to be easily customized to the customers specific EDI requirements.

    PARAMEIER DRIVEN.

    The software should be able to accept parameters to provide added flexibility in utilization.

  4. * Xl2 COMPLIANT.

    The software must ensure that the data adheres to the ANSI ASC X12 standards at the document, segment, data element, and loop level. The enveloping structure should also be verified. Typically this verification is referred to as compliance checking.

  5. * FUNCTIONAL ACKNOWLEDGEMENTS.

    The software should automatically generate a functional acknowledgement to acknowledge inbound transactions. Functional acknowledgement reconciliation should be done automatically within the software.

  6. * MAPPING.

    The mapping from the application format to the ANSI ASC Xl2 formats should be provided in an on-line mode. Customization should be available through user friendly screens. Many to many mapping is preferred. Mapping functions that support proprietary to proprietary mapping may also be beneficial. Where appropriate, execution of the translation software and mapping maintenance should be able to occur simultaneously.

  7. * ERROR PROCESSING.

    Transactions that are not compliant should be suspended to permit continued processing of the compliant transactions. On-line accessibility to the suspense file for error resolution is preferable.



CUSTOMER SUPPORT

  1. * HELP DESK CONCEPT.

    There should be a technically qualified customer service contact available for problem discussion and resolution at all times. Each contact/problem should be prioritized and assigned an identifier by the EDI translation software vendor for tracking and feedback Under normal circumstances feedback should be within 60 minutes.

  2. * PROBLEM RESOLUTION.

    The resolution of problems should be timely and under normal circumstances should be available within 24 hours. The resolution may involve both short term and long term action.

  3. * DOCUMENTATION.

    The documentation should be readable and comprehensive and in a format which allows for easy insertion of updates. It should cover the following areas:
                - installation
                - releases
                - day to day usage
                - error recovery

  4. * TRAINING.

    The EDI translation software vendor should provide seminars, conferences, courses, work sessions, classes, etc. through various media. Such training emphasizing the installation and operation of the translation software should be inherent in the purchase. In order to promote an understanding of their software as well as a comprehensive view of EDI/EC, part of this training should include a discussion of the comprehensive use of EDI to enhance business processes. The translation software itself should provide HELP features to aid in the use and understanding of the product.

  5. * USER GROUPS.

    There should be an EDI translation software user group comprised of the vendor's customers/clients. This user group should develop and prioritize customer service request/modifications to the vendor's EDI translation software. Attendance at user groups by prospective customers can provide a valuable evaluation mechanism of the translation software.



OPERATIONAL SUPPORT



  1. * SUPPORT SENDER/RECEIVER APPLICATION CODE ELEMENTS.

    Allow the software user to specify values for GS02 (application sender's code) different from those In the ISA header in data sent to allow Identification of the "source" of a document system, business unit, etc.

    Allow the software user to specify values for GS03 (application receiver's code) different from those in the ISA header in data sent to allow distribution of documents by the receiver.

    Support use of GS03 for distribution of documents received.

  2. * PARTNER INFORMATION.

    Allow the software user to maintain the following information at the trading partner/transaction set I.D. level:

    This information should be easy to maintain in a batch and on-line mode. It should be used by the software to validate data upon receipt and to create partner-specific data during generation. Reporting of transaction sets that are rejected during validation against this information must be supported, with an optional archiving and purging facility.

  3. * CONTROL AND STATUS INFORMATION.

    The software must be able to maintain control and status information for each transaction set, showing the date and time of the following:

    For transaction sets SENT:


    For transaction sets RECEIVED:

    The software must allow the user to add additional status codes as needed. The user must be able to inquire on individual transaction sets in a given status.

    Functional Acknowledgements:

    For transaction sets sent, a functional acknowledgement should be received within a time frame that is mutually agreed upon by the business partners. The software must support this convention accounting for weekends and holidays. A report of overdue functional acknowledgements must be available, showing the control numbers, user document numbers, date and time sent, and primary and secondary contact information for each transaction set sent. On-line access to functional acknowledgement monitoring and reconciliation is preferable.

  4. PROPRIETARY INTERFACES.

    The ability to define proprietary data formats with non-standard organizations should be supported.

  5. * THIRD PARTY NETWORK INTERFACE.

    The translation software should be independent of network affiliation. If the software is bundled then the communication software should communicate with ALL MAJOR third party networks and with MULTIPLE third party networks.

  6. * ERROR HANDLING

    Messages accurately reporting all exceptional and error conditions are expected to be descriptive in nature sufficient to correct or resolve the condition.

  7. * CONTROLLED "ABEND" PROCESSING.

    Any "abend" situation should terminate any system or program execution in a controlled manner with respect to pertinent error messages, file integrity, condition codes and any other area necessary for system recovery.

  8. * DATA DRIVEN PROCESS FLOW.

    Incoming or outgoing data should be processed in an unbroken stream from start to finish. The data itself should direct the process without outside (manual) intervention. The data should be seamlessly and electronically integrated into the receiving application system.

  9. * AUDIT TRAIL

    The software should contain inherent audit and control capabilities to provide the ability to "track" an interchange from receipt to integration into the application system. There should be on-line access to audit and control information.

  10. APPLICATION FILE/TABLE INTERFACE.

    The software should be able to have on-line access to application file(s)/table(s).

  11. * REPORTING.

    The software should have reports depicting statistical, audit and control, security, trading partner and mapping information.




FUTURE CONSIDERATIONS

  1. * EDIFACT.

  2. CLENT/SERVER.

  3. ELECTRONIC MAIL.

  4. GRAPHICS.

  5. IMAGING.

  6. INTERACTIVE EDI.

  7. CONVERSATIONAL EDI.

  8. BULLETIN BOARDS.

  9. IDENTIFICATION CARD INTERFACE.