1. Lesson 2 Preparing to Test the 837
Welcome to the second lesson in “Electronics Transactions It’s Easier Than You Think.” This lesson will cover “Preparing to Test the 837”, the second lesson on 837 and 835 Transactions and Code Sets. This lesson will give you an overview of the preparation you need to complete to testing of the At any time, you can click on Next to move forward or Back to review a screen. Click on Main Menu to choose other lessons or click on the Exit block to leave this program.
[Trainer’s Notes]
With a live group, be sure to welcome the participants. If the size of the group is appropriate, give participants an opportunity to introduce themselves. Convey the time expectations for the session. Review housekeeping and safety information: emergency exits, bathrooms, use of cell phones. Remind participants that these lessons follow the same sequence as the electronic newsletters and that supplemental resource information is in the Quick Reference Guide which is included on the interactive CD-ROM and accessible through links on the IHS Electronic Transactions website. Suggest colleagues who could be helpful. Training notes throughout this document are made up of recommendations and/or additional input and suggestions that will help with training. In some cases, the notes section may contain information that is in addition to the bullet points on-screen in the interactive training if information was revised or added after the training was developed.

2. Electronic Data Interchange and Standards What is the 837?
Section 2 Topics
Electronic Data Interchange and Standards
What is the 837?
Software requirements
Implementation Guides
Establish relationship with insurer
This lesson will cover five topics:
Electronic Data Interchange (known as EDI) and Standards
The purpose and structure of the 837
Software requirements
Implementation Guides and Addenda, and
Establishing a working relationship with insurers
[Trainer’s Notes]
This slide will reappear occasionally to orient participants as to what comes next in the presentation.

3. Section 2: Preparing to Test the 837
Electronic Data Interchange and Standards
What is the 837?
Software requirements
Implementation Guides
Establish relationship with insurer
Electronic Data Interchange depends on a precise agreement between the sender and the receiver of data as to the format and content of the interchange.
[Trainer’s Notes]
Emphasize that the transactions require total precision. The testing process will reject data that is almost right. The best and fastest solution is careful collection and assembly of the data.

4. Electronic Data Interchange
What Is EDI?
Electronic Data Interchange
Computer-to-computer exchange of business data between trading partners
In EDI, information is organized according to specified format set by both parties
For the most part, all information contained in EDI transaction sets is same as information on conventionally printed documents
Electronic Data Interchange is the computer-to-computer exchange of business data between trading partners. To achieve speed and efficiency, information is organized according to formats specified by both parties. For the most part, the information contained in EDI transactions is the same as information on a conventionally printed form, but it looks very different.
[Trainer’s Notes]
In effect, the transactions exchange only provides the answers to the questions. The questions and the order in which they are answered are specified in advance by the parties. The EDI format is the encoder for sending and the decoder for receiving the information.

5. What Does It Mean For You?
Lead Business Office Assistant: “Sending paper claims was time consuming.”
Application Coordinator: “And the turn-around could vary from 14 to 30 days.”
In sending paper claims it was time consuming. We always ran out of claim forms. We had problems with printing. Each box carries about a thousand; they were heavy to lift. You always had to have storage space. If you ran out, you were in a bind to try to find another box of, you know, claims from another facility. There was a lot of menial tasks in taking the claim apart. They had perforated edges, and you have to manually tear them apart and you could even tear your own claim apart and then have to go back and reprint those claims. You have to fold it, you have to stuff it, and then you have to mail it off and insurance companies lost your claim, too, and then wait for the turn-around which could vary from 14 to 30 days. Now that we have our transmissions going electronically, we’re assured that they got our batches.

6. EDI reduces costs, improves accuracy, and increases productivity
Benefits of EDI
EDI reduces costs, improves accuracy, and increases productivity
Lessens time and costs associated with receiving, processing, and storing documents
Eliminates inefficiencies
Streamlines tasks
EDI benefits both parties to the transaction by:
Reducing the time and costs of receiving, processing, and storing documents
Eliminating inefficiencies, and
Streamlining tasks
[Trainer’s Notes]
Because EDI only transmits the data, it is vastly faster and less expensive to transmit. Because the data arrive formatted for processing, the turn-around time and error rates are reduced. Electronic data can be stored in a fraction of the space of paper documents.

7. EDI Health Care Claims Standards
Developed and maintained by Accredited Standards Committee (ASC) X12
ASC X12 chartered in 1979 by American National Standards Institute (ANSI) to develop uniform standards for inter-industry electronic exchange of business transactions
EDI only works because of consistent standards. A group called the Accredited Standards Committee X12 (referred to as ASC X-twelve) was chartered in 1979 by the American National Standards Institute to develop uniform standards for inter-industry electronic EDI.
[Trainer’s Notes]
The important point here is that there is a specific organization responsible for developing and publishing the standards for EDI, and all parties have agreed to follow those standards.

8. EDI Health Care Claims Standards (cont’d)
ASC X12 Insurance Subcommittee (X12N) developed Implementation Guides originally published in May 2000
Implementation Guides adopted by DHHS Secretary for use under HIPAA
In October 2002, additional guidance was developed
Addenda to X12N Implementation Guides were adopted for use under HIPAA
The Insurance Subcommittee of ASC X12 (called X-twelve-N) published the original set of Implementation Guides in May of 2000, and the Secretary of DHHS adopted the Implementation Guides for use under HIPAA. In October of 2002, additional guidance called Addenda were adopted for use under HIPAA. Each Guide has an Addendum, and the Implementation Guides and Addenda must be used together to be complete.
[Trainer’s Notes]
For convenience, these lessons will often refer to Implementation Guides without mentioning Addenda, but the inclusion is implied, and guides and addenda must always be used together.

9. Section 2: Preparing to Test the 837
Electronic Data Interchange and Standards
What is the 837?
Software requirements
Implementation Guides
Establish relationship with insurer
Before any type of EDI can be put into actual use, both parties must prepare their systems to test the success of that particular transaction. The following section will focus on the 837 transaction.
[Trainer’s Notes]

10. Full name: Health Claims & Equivalent Encounter Information
What Is the 837?
837 format replaces current electronic export modes in RPMS 3rd Party Billing System
Full name: Health Claims & Equivalent Encounter Information
Definition of 837 from 837 Implementation Guide:
“A standardized format designed to expedite the goal of achieving a totally electronic data interchange health encounter/claims processing and payment environment.”
The 837 is short-hand for “Health Claims and Equivalent Encounter Information.” The 837 is a format for transmitting data, not a form for collecting data. It replaces the electronic export modes in RPMS 3rd Party Billing System.
The official definition from the 837 Implementation Guide is “a standardized format designed to expedite the goal of achieving a totally electronic data interchange health encounter/claims processing and payment environment.”
[Trainer’s Notes]
The official definition distills down to a standardized format that should integrate the following:
Health encounter information (data collection and organization)
Claims processing (transmitting to the payer)
Payment information (receiving from the payer)
The current HIPAA compliant version is the ANSII Standard X12N 837 Version 4010 with Addenda (004010x096A1). You can use this reference as an example of why users need to refer to both the Implementation Guide and the Addenda to be certain they have the full set of information.

11. Current HIPAA compliant version
What Is the 837? (cont’d)
Current HIPAA compliant version
ANSI Standard X12N 837 Version 4010 with Addenda (004010X096A1)
The current HIPAA compliant version is the ANSI Standard X12N 837 Version 4010 with Addenda (004010x096A1). This definition is a good example of the need to consult both the Implementation Guide and the Addenda to obtain the full set of information.
[Trainer’s Notes]
Reiterate that the Implementation Guide without the Addenda is incomplete and will certainly lead to errors.

12. Types of 837 Electronic Claims
837 – Institutional
Called 837I; replaces UB-92
837 – Professional
Called 837P; replaces HCFA-1500
837 – Dental
Called 837D; replaces ADA forms
Different types of the 837 have been developed for specific kinds of claims:
The 837 – Institutional (called the 837-I) replaces the UB-92
The 837 – Professional (called the 837-P) replaces the HCFA-1500), and
The 837 – Dental (called the 837-D) replaces American Dental Association forms
[Trainer’s Notes]
The various versions of the 837 are similar but not interchangeable.

13. Types of 837 Electronic Claims (cont’d)
837 – Coordination of Benefits
Called 837 – COB
Used for sending claims to secondary insurers
Coordination of benefits also called cross-over
Process of determining respective responsibilities of two or more health plans that have some financial responsibility for a medical claim
The Coordination of Benefits (837 – COB) is used to send claims to secondary insurers.
Coordination of Benefits, which is sometimes called “cross-over”, is the process of determining the respective responsibilities of two or more health plans that each has some financial responsibility for a medical claim.
[Trainer’s Notes]

14. Section 2: Preparing to Test the 837
Electronic Data Interchange and Standards
What is the 837?
Software requirements
Implementation Guides
Establish relationship with insurer
The essential place to start preparing to test the 837 is to verify that your claims software is ready to meet the requirements.
[Trainer’s Notes]

15. Software Requirements: Install RPMS Patches
GIS v3.01, p2 & p5 (Optional)
3rd Party Billing, v2.5, p6
Tested and certified by many different insurers
AUT Patch v98.1, p13
For more information and most current releases, contact ITSC Help Desk
Three RPMS patches must be installed to prepare for the 837:
GIS (G-I-S) v3.01, patches 2 and 5
Third Party Billing, v2.5, patch 6
AUT (A-U-T) Patch v98.1, patch 13
The patched RPMS Third Party Billing software has been tested and certified by many different insurers.
For more information and for the most current releases, contact the OIT Help Desk.
[Trainer’s Notes]
Before presenting this lesson, check the OIT Help Desk for the latest patches and distribute the list as notes to this screen. In the citations to the patches, as in the example above, “p2” represents the patch number, not a page number.

16. Section 2: Preparing to Test the 837
Electronic Data Interchange and Standards
What is the 837?
Software requirements
Implementation Guides
Establish relationship with insurer
The Implementation Guides and Addenda are the authoritative support tool for interpreting the 837 and other electronic transactions.
[Trainer’s Notes]

17. Implementation Guides and Addenda
Main support tool for interpreting electronic transactions like the 837
ACS X12 Insurance Subcommittee (X12N) developed Implementation Guides for standards for health care electronic transactions
X12N HIPAA Implementation Guides and Addenda should be your primary reference documents
The ASCx12 Insurance Subcommittee developed Implementation Guides and Addenda for the standards for health care electronic transactions that you should use as your primary reference documents. There are separate Guides and Addenda for each of the four types of 837: Institutional, Professional, Dental, and Coordination of Benefits.
[Trainer’s Notes]
The Implementation Guides and Addenda are the authoritative documents for each type of electronic transaction. No one can do electronic transactions without the right guide.

18. Implementation Guides and Addenda are critical tools
Don’t Cut Corners
Implementation Guides and Addenda are critical tools
You need to have hard copies of them
Each Guide is about 800 pages long so print Guides and Addenda double-sided
Get them and keep them where you use them
The Implementation Guides and Addenda are critical tools in electronic transactions, and they are extremely detailed. You will need to have printed copies in a place where you can refer to them frequently.
Since each Guide is about 800 pages long, you will find it more economical and more convenient to print the Guides and Addenda double-sided.
[Trainer’s Notes]
The Guides and Addenda are not expected to be subject to frequent revision, so printed copies should be usable for the foreseeable future.
Display an example of the hard copy of a Guide with Addenda to make the point about double-sided printing.

19. Washington Publishing Company
Publishes X12N Implementation Guides and Addenda adopted for use under HIPAA
Free to download:
All Implementation Guides (May 2000)
All corresponding Addenda (October 2002)
Can purchase:
Book or CD
Version that integrates Addenda into Implementation Guide
The Implementation Guides and Addenda are readily available. You can download free electronic copies of the Implementation Guides and the Addenda from the Washington Publishing Company website. Be sure to get the appropriate Guide and corresponding Addenda.
You can also purchase each of the Guides and Addenda in book or CD form. When you purchase the book or CD, the Addenda are fully integrated into the Implementation Guide.
[Trainer’s Notes]
The combined Guide and Addenda will be significant labor savers compared to working with two separate documents.

20. Washington Publishing Company (cont’d)
Click on Products/Publications/PDF Download (Free)
Or call
Three 837 Implementation Guides and Addenda
837: HIPAA Claim: Dental
837: HIPAA Claim: Institutional
837: HIPAA Claim: Professional
You can download the Implementation Guides and Addenda by going to on the Internet. Click on Products, then Publications to bring up the catalog. Be sure to obtain both the correct Guide and the Addenda. The Addenda available for download from Washington Publishing Company will always be the most current version.
[Trainer’s Notes]

21. Understanding 837 Implementation Guides (IGs)
Implementation Guide contains key terms
Testing coordination staff must understand terms
Software developers may use terms
To assist sites
To work with insurers
The Implementation Guides contain and define key terms that you must understand as you prepare and test the Software developers may also use these terms to assist the user sites and as they work with insurers.
[Trainer’s Notes]
Again, since this process is very literal, knowing the definitions of key terms is absolutely essential. Terms may have different meanings than they do in plain English.

22. Data element Data segment Control segment Delimiter Loop
List of Key Basic Terms
Data element
Data segment
Control segment
Delimiter
Loop
Transaction set
Header and Trailer
Seven terms are absolutely essential to understand the 837 electronic transactions format. You need to understand these definitions well before you will be able to perform electronic transactions successfully.
[Trainer’s Notes]
The terms make it sound more complicated than it is. If you think in terms of English grammar, data elements are words, and delimiters are spaces between words. Data segments are sentences. The difference is that the electronic grammar has to be perfect or it doesn’t work.

23. Data element is smallest named item in ASC X12 standard
Data element corresponds to a data field in data processing terminology
Data element is smallest named item in ASC X12 standard
The data element is the basic unit of information in an electronic transaction and the smallest named item in ASCx12. In data processing terminology it would be called a data field.
The example on the screen points out four examples of data elements.
[Trainer’s Notes]
Point out that data elements can contain periods or spaces.

24. Mandatory data element
Types of Data Elements
Mandatory data element
Data is required to be populated or entire batch will not pass initial submission
Situational data element
Dependant upon facility
Can be populated if data element applies
Data elements may be mandatory or situational.
All mandatory data elements must always be populated, or filled-in. If one mandatory element is omitted, the entire batch will not pass its initial submission.
Situational data elements are populated depending on the facility, the insurer, and whether the data element applies. They may be required sometimes, but not always.
[Trainer’s Notes]
The Implementation Guides and Addenda will identify which elements are mandatory. Situational does not mean optional; there are no data elements that are optional.

25. Data segment corresponds to a record in data processing terminology
Data segment contains related data elements
Sequence of data elements within one segment is specified by ASC X12 standard
All of this is a data segment:
A data segment contains related data elements and corresponds to a data record in data processing terminology. The data elements must be entered in the sequence specified by the ASCx12 standard for that segment.
The screen shows an example of one complete data segment.
[Trainer’s Notes]
Anyone dealing with the 837 or other electronic transactions will need to learn to look for the asterisks because they separate the data elements.

26. Control segment has the same structure as data segment Uses
To transfer control information (e.g., start, stop) rather than application information
To group data elements
A control segment has the same structure as a data segment, but its purpose is different. A control segment transfers control information (for instance, start or stop) rather than application information. Control segments are also used to group data elements.
[Trainer’s Notes]
Control segments carry instructions; data elements carry data. One analogy would be the difference between s Stop sign and a street sign.

27. Delimiter is character used to:
Separate two data elements
Terminate a segment
Delimiters are integral part of data
ISA* 00* * 01* SECRET....* ZZ* SUBMITTERS.ID..* ZZ* RECEIVERS.ID...* * 1253* U* 00401* * 1* T* :~
Delimiters
A delimiter can separate two data elements or terminate a data segment. There are many different kinds of delimiters, and the delimiter used indicates its purpose – they are not interchangeable. In the example on the screen, each asterisk separates two data elements. The last symbol in the example is a tilde (~), and it terminates (or delimits) the data segment.
[Trainer’s Notes]
One character delimits data; a different character delimits segments. In prose, a space is a delimiter between words; a period is a delimiter between sentences. In currency, the decimal point is a delimiter between dollars and cents.

28. Loop is group of related data segments
Loops are specified by each Implementation Guide
Importance of loops
Some segments repeat
Example: address line
Loop identifies which address it is
Example: Billing Office, subscriber, insurer
A loop is simply a group of related data segments. Loops are specified in each Implementation Guide, and you must refer to the Guide for each one. In a loop, some segments repeat, for example, the address segment. The loop specification identifies which address it is – the billing office, subscriber, or insurer.
[Trainer’s Notes]
You cannot guess the specification for one loop by studying a different loop. You must always refer to the Implementation Guide and Addenda for that specific loop.
Several elements make a segment; several segments make a loop.

29. Transaction set contains data segments
Transaction set is a grouping of data records
For instance, a group of benefit enrollments sent from sponsor to insurer is considered a transaction set
Sequence of data segments within one transaction set is specified by ASC X12 standard
A transaction set is a grouping of control segments and data segments, or records. The data segments in the transaction set are related in some way. For example, a group of benefit enrollments sent from sponsor to insurer would be considered a transaction set. Typically, that set would not also include specific claims information.
The ASCx12 standard, as found in the Implementation Guides, specifies the sequence of data segments within one transaction set.
[Trainer’s Notes]
There is a detailed annotated example in the “Understanding Implementation Guide Terms” table in the Quick Reference Guide in the section on Preparing to Test the 837.

30. For example, a transaction set has:
Headers and Trailers
Header is the start segment for transaction set or functional group or interchange
Trailer is the end segment for transaction set or functional group or interchange
For example, a transaction set has:
A transaction set header control segment
One or more data segments
A transaction set trailer control segment
Headers and trailers are both control segments. The header control segment marks the start of a transaction set, and the trailer segment marks the end of the set. Each transaction set begins with a header control segment, which is followed by one or more data segments and concludes with a trailer control segment.
[Trainer’s Notes]
To continue the analogy with English grammar, a new paragraph usually begins with an indented first line (header segment) which is followed by sentences (data segments) and is terminated by a blank line before the next paragraph (trailer segment).

31. A Data Stream
datadatadataaparagraphisatransactionsettheindentedlineistheheadersegmentspacesdelimitwordsperiodsdelimitsentencestheblanklineattheendisthetrailersegmentdatadatadata
If you don’t understand the components of the data stream, it can be very difficult to decipher the meaning, just as it’s almost impossible to read this paragraph.
[Trainer’s Notes]

32. Data Stream with Delimited Elements
data data data a paragraph is a transaction set the indented line is the header spaces delimit words periods delimit sentences the blank line at the end is the trailer data data data
In written English, words are the data elements and spaces are the delimiters. When the elements are delimited, you can begin to make some sense out of the data stream.
[Trainer’s Notes]
This slide shows how effective delimiters (spaces in this case) are in converting gibberish to data.

33. With Delimited Elements and Segments
data data data. A paragraph is a transaction set. The indented line is the header. Spaces delimit words. Periods delimit sentences. The blank line at the end is the trailer. Data data data
A sentence in English corresponds to a data segment in the With the segments delimited, you can tell where one thought ends and a new one begins.
[Trainer’s Notes]
Even with the data delimited by spaces, it was hard to sort out what the message was. The periods delimit the data segments (sentences).

34. A Data Stream with Control Segments
data data data.
A paragraph is a transaction set. The indented line is the header. Spaces delimit words. Periods delimit sentences. The blank line at the end is the trailer.
Data data data
Once you understand the parts and how they go together, a confusing stream of characters suddenly becomes information that makes sense.
[Trainer’s Notes]
We understand the message because we know the rules. All the raw data is the same; it’s just been formatted to match our understanding of the rules.

35. Review
Take a moment to review the schematic illustration on the screen. The transaction set begins with the transaction header control segment. The set includes two data loops with groups of data segments. After the last loop, the set is terminated by a transaction trailer control segment.
Once you learn the functions of the components and how to recognize them in the 837 data stream, preparing and correcting the 837 will be much easier.
[Trainer’s Notes]
Refer back to the “Understanding Implementation Guide Terms” table in the Quick Reference Guide.

36. What Does It Mean For You?
Compliance/Privacy Officer: “It’s forced them to put more attention on the staff.”
Accounting Technician: “There was a little stage fright.”
Financial Management Officer: “We’ve done all the groundwork”
Assistant Site Manager: “It’s gotten easier along the way.”
With the transaction code sets part of HIPAA, it’s really forced organizations to look at that process and standardized it and forced them to put more attention on the staff that do those jobs.
Well, I don’t know if I really want to change this because this is a long process, and how long is it going to take for me to learn this new process? So there was kind of like a little stage fright in it. I guess when you start working with the Internet and you start knowing the Internet more, and that’s what this electronic posting’s about, it has to do a lot of just, you know, click and go.
So it’s been a… about a two year struggle but now that we’ve done all the groundwork, it should be a whole lot easier for everybody because there are examples, there are sets that we have that we can use for everybody. There was a lot of work involved in getting it going initially but it’s gotten a lot easier along the way.

37. Section 2: Preparing to Test the 837
Electronic Data Interchange and Standards
What is the 837?
Software requirements
Implementation Guides
Establish relationship with insurer
One of the key steps to preparing to test the 837 is to establish a good working relationship with insurers.
[Trainer’s Notes]
Refer back to topics already covered as review.

38. Get to Know Health Plans and Insurers
Open communication channels
Identify person you will be working with
Establish relationship with that person
Determine that health plan/insurer is ready for HIPAA compliance
If so, determine what their expectations are of your facility
The 837 may be an electronic transaction, but you will still be dealing with people. Especially during the testing phase, your job will be easier and success will come more quickly if you open communications channels with the insurer. Identify a specific person you will be working with and establish a working relationship before you have a problem.
Any working relationship is easier with good communication. If you have a problem, you want to be able to pick up the phone and talk to the individual who can work it out. This is easiest to do if you and that person already have a good working relationship.
Find out if that health plan or insurer is ready for HIPAA compliance. If they are, learn what they expect of your facility.
[Trainer’s Notes]
Establishing the relationship with the insurer is one of those things best done as soon as possible, because good communication will prevent problems as well as help solve them.

39. Gather Important Information on Testing Process
How will claims be submitted? By website or messaging?
Is there a minimum number of claims to be included in each batch?
How will site receive confirmation reports that batch has been accepted by insurer?
In what format will Error Reports be provided?
What is process for correcting and resubmitting batch files?
What information will insurer need from site to ensure resubmitted batch is not a duplicate batch?
Before you call your contact at the insurer, make good use of their time and yours by preparing a list of questions that you need to have answered before you can prepare to test the 837.
Will claims be submitted by website or messaging?
Is there a minimum number of claims per batch?
How will you receive reports that the insurer accepted the batch?
In what format will Error Reports be provided?
What is the process for correcting and resubmitting batch files?
What information will the insurer need to ensure that a resubmitted batch is not a duplicate?
[Trainer’s Notes]
There are many questions that could be asked. It’s worth taking a few moments to list the questions, even to write them down before making the call.

40. Gather Other Important Information
Will software be certified or will insurer require each site to test individually?
Will insurer allow parallel testing or will they require a “hard switch”?
Will insurer continue to support software or systems provided by insurer to conduct transactions?
Does insurer have a Companion Guide that must be reviewed by facility and OIT?
Does insurer have a Trading Partner Agreement that must be submitted?
Is there an EDI (Electronic Data Interchange) form that must be submitted?
Will software be certified or will the insurer require each site to test individually?
Will the insurer allow parallel testing or require a “hard switch”?
Will the insurer continue to support software or systems they had provided to conduct transactions?
Does the insurer have a Companion Guide that must be reviewed?
Does the insurer have a Trading Partner Agreement that must be submitted?
Does an EDI form have to be submitted?
[Trainer’s Notes]
These questions will elicit detailed information, so taking notes is essential It’s a good idea to send an back confirming the answers.

41. Complete EDI Forms
Insurer may require you to complete Electronic Data Interchange (EDI) forms in order to begin testing and transmitting electronic transactions
Each EDI form should be detailed down to transaction level that you will be testing with that insurer
Insurer will assign EDI submitter ID number based on completion of these forms
Insurers may require you to complete Electronic Data Interchange (EDI) forms before you begin testing and transmitting electronic transactions. Each EDI form should be detailed down to the transaction level that you will be testing with that insurer.
Once you have completed the EDI form, the insurer will assign you a submitter ID number.
[Trainer’s Notes]

42. Testing process occurs in two phases
Two Levels of Testing
Testing process occurs in two phases
You must pass Level 1 before you can test for Level 2
Level 1 verifies that:
Your software is HIPAA compatible
You and insurer can communicate on coding and transaction requirements that are specifically required by HIPAA
Level 2 verifies that:
You are meeting insurer's coding and transaction requirements that are not specifically determined by HIPAA
Testing the 837 occurs in two phases: Level 1 and Level 2. You must pass Level 1 successfully before you can test for Level 2.
Level 1 verifies that your software is HIPAA compatible, and that you and insurer can communicate on the coding and transaction requirements that are specifically required by HIPAA.
Level 2 verifies that you are meeting the insurer's coding and transaction requirements that are not specifically determined by HIPAA.
[Trainer’s Notes]

43. Insurer’s operating guide to electronic transactions
Companion Guide
Insurer’s operating guide to electronic transactions
Specifies how HIPAA compliance testing and certification are to be accomplished (Level 1)
Transmission methods
Volume
Timelines
Many insurers provide a Companion Guide that is their operating guide to electronic transactions. The Companion Guide specifies how HIPAA Level 1 compliance and certification are to be accomplished, such as:
The transmission methods to be used
The volume of transactions, and
The timelines for submitting electronic transactions.
[Trainer’s Notes]
If possible, bring an example of one or more Companion Guides to show the group.

44. Companion Guide (cont’d)
Specifies insurer’s coding and transaction requirements that are not specifically determined by HIPAA (Level 2)
Insurer may not require data elements for all fields
Insurer may include data elements that are specific to insurer, e.g., local codes
The Companion Guide addresses Level 2 testing by specifying the insurer’s coding and transaction requirements that are not specifically determined by HIPAA. For example, an insurer may not require data elements for all fields or may include data elements that are specific to that insurer.
[Trainer’s Notes]
This is another case where there is no “big picture” – experience with one insurer cannot be generalized safely to another. Consult the Companion Guide.

45. Get Your Companion Guide
Don’t Start Testing Without It!
Just as the Implementation Guides and Addenda are the most authoritative source for HIPAA information, the insurer’s Companion Guide is essential for successful testing.
Don’t start testing without it.
[Trainer’s Notes]

46. TPA and BAA
Agreements that formalize relationships with entities or persons with whom you will be doing HIPAA compliance testing and production
Trading Partner Agreement (TPA) is established with external entity or insurer (e.g., Trailblazers) with whom you will be doing business
Business Associate Agreement (BAA) is established with person or organization that performs function or activity on your behalf but is not part of your workforce
Two kinds of agreements could be used to formalize the relationship with entities or persons with whom you will be testing and completing HIPAA compliant electronic transactions.
A Trading Partner Agreement (TPA) is established with an external entity or insurer with whom you will do business (for instance, Trailblazers).
A Business Associate Agreement (BAA) is established with a person or organization that will perform a function or activity on your behalf, but that is not part of your workforce.
[Trainer’s Notes]
Whichever relationship is appropriate in any given situation, it must be documented by the appropriate written and signed agreement.
Samples of each type of agreement are available through links on the Electronic Transactions website.

47. Assures you are a priority to do HIPAA testing
Benefits of a TPA
Assures you are a priority to do HIPAA testing
May provide access to insurer’s online systems
Means you get paid at higher rate because you are a contract provider
A TPA offers benefits you should know about.
It assures that you receive priority to do HIPAA testing.
It may provide access to the insurer’s online systems.
As a contract provider, you will be paid at a higher rate.
[Trainer’s Notes]
For most people, the issue will be to get the right kind of agreement in place and follow it, not to decide which type of agreement is right.

48. What does insurer cover? Which procedures are billable or not?
Contents of a TPA
What does insurer cover?
Which procedures are billable or not?
Who is covered, who is not?
Is preauthorization required? For what?
For sample agreements, go to:
A TPA will vary from one insurer to another, but it should always explain:
What the insurer covers
Which procedures are billable
Who is covered, and
Whether and for what preauthorization is required.
A sample TPA that meets HIPAA requirements is available though links on the IHS HIPAA Electronic Transactions website.
[Trainer’s Notes]
Each TPA is different so it is essential to have a copy of the TPA for that insurer.

49. Agreement requires signatures
TPA Tips
Agreement requires signatures
Allow enough time to get all the signatures
Don’t complete this agreement until you are ready to begin testing
Agreement may stipulate dates for beginning and completing testing
To complete the TPA, you must obtain trading partner ID number from insurer
Here are three useful tips for completing a TPA:
A TPA is a legal document that must be reviewed, and time must be allowed to get all the necessary signatures.
However, don’t complete the TPA until you are ready to begin testing because the agreement may stipulate dates for beginning and completing testing.
To complete the TPA, you must first obtain a trading partner ID number from the insurer.
[Trainer’s Notes]
Regardless of whether someone has the particular responsibility for executing the TPA, everyone needs to know that the TPA has been executed and what to do to comply with the terms of it.

50. Obtain and install required software patches
Lessons Learned
Obtain and install required software patches
Obtain all 837 Implementation Guides and Addenda
Contact health plan/insurer
Obtain and review Companion Guide
Complete and submit Trading Partner Agreement
To review, the preparation for testing the 837 electronic transaction must happen in the right order.
Obtain and install the required software patches
Obtain all 837 Implementation Guides and Addenda.
Establish a relationship with the health plan or insurer.
Find a contact person
Obtain and review the Companion Guide, and
Complete and submit a Trading Partner Agreement
This completes Lesson 2: “Preparing to Test the 837”.
At this point, you may return to the Main Menu. You can click on Back to review, Next to begin the next lesson or click on the Exit symbol to end this session.
[Trainer’s Notes]
Ask for and address any questions members of the group might have. Thank the group for their participation.