HIPAAMagic Tutorial/Quick Start Guide HIPAAMagic Tutorial/Quick Start Guide
Tutorial and Quick Start Guide
Empire Medical Review Services, Inc.
11357 North Port Washington Road
Mequon, WI 53092
262-240-9700Introduction
This document serves as a tutorial and quick start guide for HIPAAMagic NSF to ANSI Translator software.
You can select a topic to read from the Table of Contents in the lefthand frame.
Displaying the Index allows you look up a subject of interest and jump to it by clicking on the displayed page number.
Each topic in the tutorial provides a description of how to use a different part of the software. In addition, there are movies throughout the tutorial that illustrate the topics. To play a movie, select the yellow Show Me button:
The movies require the Macromedia Flash plugin that is included with most browsers.
At the bottom of the movie window, there is a control bar that allows you to pause the movie or jump forward or backward through it.
When you point the cursor at a button on the toolbar, a popup tag will appear to describe its function. Of particular interest, the pause button ( || ) allows you to pause the movie if you need more time to look at something. The back button ( << ) allows you to move backward through the movie to repeat parts you have seen. The forward button ( >> ) allows you to jump ahead.
Installation
In order to implement Electroniclaim's HIPAAMagic NSF to ANSI professional claims translator you must first install the software. You can download the software from the internet at http://www.electroniclaim.com or install it from a CD purchased directly from Electroniclaim or one of its authorized resellers.
Install the NSF to 4010 software. This can be done by double clicking on the file that was downloaded from the internet or running the setup program from the installation CD.
Run the software. Select the program from the Windows Program Start Menu. The program is in a program group called Electroniclaim. The HIPAAMagic menu item has a description that reads: Electroniclaim NSF 3.0 to ANSI 837 4010 Conversion.
The first time the program is run it will ask for a registration key. Type the registration key in exactly as it is listed on the sticker on the CD cover or in the email you received after downloading the software from the internet. The registration keys are case sensitive.
When the program is run, it opens a window that is shown in Figure 1:
Find Claim Files
In order to translate National Standard Format claim files, you will need to find them. Start with the National Standard Format electronic claim file that you normally submit to your Medicare Carrier. Your practice management vendor should be able to tell you its name and location on your hard drive.
If you are unable to find the NSF file, you may use the computer to help you. National Standard Format files have record identification characters at the beginning of each line. The first line of an NSF file always begins with the characters `AA0' (0 = zero). The last line of the NSF file always begins with the characters `ZA0.' If you open the Windows Explorer or double click on My Computer, you will see that there is a search option available to you. If you search for `A Word or a Phrase' in the file, you may search for all files which contain the character string `ZA0.' The system will report the location of all files that contain this character string. These files are then used as the input to the file translator. Under Microsoft Windows XP the search looks like Figure 2:
The NSF file(s) are used as the input for the pre-processor and also the main translator program. Write down the location of these files. They must be copied to the Input Folder of the Electroniclaim NSF to ANSI 4010 translator (see the following section).
Program Setup
The default location of the Input Folder is
C:\Electroniclaim\HIPAAMagic_8\data\input. You can find or change this folder or directory by selecting Data from the Main Menu and then Program Setup from the drop down menu that appears under Data.
The Data > Program Setup drop down menu appears in Figure 3.
Now check the information contained in the Setup Form, which is shown in figure 4.
The New File Name field is incremented automatically by the system. You should not need to make any changes to it. The naming convention for files is shown in the New File name field. Each file is given a unique name when it is translated. The file names are of the form: A0000001.NSF and A0000001.X12. The last character of the name is incremented through 0 through 9 and then A through Z, and then the second to last character is incremented by one and so on.
The Import Path is where the NSF files that are to be converted to the ANSI format are to be placed. This is where the system will look for files when the user selects Convert Files from the Claims option of the Main Menu.
The Output Path is where the converted files in the ANSI format will be placed after the conversion process. When the conversion process is completed for each file in the import path folder, the original input file is copied to the Archive Path folder and erased from the Import Folder. Files which are placed in the Archive folder are given unique names from the New File name field, using the naming convention from above. Each file in the Output Path folder will have a corresponding file in the Archive folder with a different extension on the name. E.g., A0000001.NSF in the archive folder is the NSF file which was used as the input file and A0000001.X12 is an ANSI 837 transaction set file which was created from the input file. This is done since many billing systems create a claim file of the same name each time they create NSF files. If the files were not renamed, they would be replaced by the next incoming file.
Pre-Processor Path Setup
Included with the installation of the NSF to ANSI 4010 translator is the NSF Pre-processor. This powerful tool allows users to edit NSF files before they are run through the NSF to ANSI 4010 translator. These Pre-Processor fields are provided in the Setup Form.
The Pre Process Input path is where files to be pre-processed should be copied. This may be thought of as the first input folder used at the start of the translation or conversion process.
The Pre Process Output path is where the system will create preprocessed NSF files. To optimize the system, it is recommended that this path should be the same as the NSF to ANSI Import Path. This way, when a file is finished with preprocessing, it will already be in the correct folder for translation into the ANSI format.
The Pre Process Junk path is where non-NSF files found in the Pre Process Input path will be copied. These files are then erased from the Pre Process Input path. All of these folders are set to be correct if there have been no changes made to the default installation folder. If a different folder was selected for installation, then these settings will have to be changed to reflect the user selected folder.
The other fields on the form are:
Run Validation. This should be checked in order to have the system create meaningful error messages. Once you have passed testing with all of the payers to whom you are sending claims, you may wish to turn off the validation. This will increase the system translation performance.
Add CR LF After Each Segment: This should normally be blank. If the system adds a carriage return and line feed after each segment, the ANSI message can be read more easily by people. Absent a CR/LF after each segment, an ANSI message is a single long string of characters. This is the requirement of the specifications. The design of the ANSI message is intended to minimize the number of characters transmitted.
Keep Filename Same: This allows the user to keep the input file name as the output file name and concatenate the new ANSI file as a text string added onto the existing file contents. This allows users who have submission scripts to continue to use them.
Segment Terminator: This is the segment terminator character. It is usually a tilde character, ~.
Element Separator: This is the Data Element Separator. It is usually the asterisk character, *.
Sub Element Separator: This is the sub element separator used in composite data elements. It is usually the caret character, ^.
Allowable values for delimiters in ANSI messages may be found in Appendix A of the implementation guide, page A4. The delimiters in this table will be used as default values for each new Trading Partner table entry. Clicking on the OK at the bottom of the form causes any changes made to be saved. Clicking on the Cancel button causes any changes made to the fields on the form to be discarded.
Lookup Tables
Now you must enter some data, which will be used to facilitate the translation process. With each new iteration of electronic claim formats there has always been somewhat more data than was previously required. For this reason it is strongly suggested that you fill in some information on tables that will be used to help the translator do its job. These tables are found by selecting the Data menu. See Figure 5.
The data in each of the tables represented by the menu in Figure 5 may be edited by the user by opening the form associated with the menu entry. Once the form has been opened the data in the table may be navigated through the use of the Tool Bar. The Tool Bar is shown in Figure 6.
As the user places a mouse pointer over each control or icon in the Tool Bar a Tool Tip indication its function is displayed. Starting with the Magnifying Glass at left the functions are: Find, Locate, List, Filter, Order, Print. The VCR control is Top, Back, Forward, Bottom. These controls all have to do with locating the correct record, in a table, prior to its contents being changed. The next group of controls are: New to add a new record, Copy to Copy the data from a record and add another record with the same data, Delete, Group Delete, Save and Add New, Save, Revert or Cancel changes, and Close the Form.
The Tool Bar applies to the Active Form Window. If more than one form is open within the application, the form which has focus is the one on which the Tool Bar functions will be applied. This is usually the form on top. Once the correct record has been located it may be edited. When the user has finished editing the record the changes must be saved.
Remember: Find the record. Edit or Update the Record. Save the Record.
As part of the program setup the User will need to make entries in the following tables:
Trading Partner / Submitter, Provider, Facility, Payer, Receiver.
Trading Partner
When the Trading Partner / Submitter option is selected from the Data menu, a form will open on the screen for data entry. See Figure 7.
In order to add a new record to the table you must click on the NEW icon on the Tool Bar that opens with the Form window. The NEW icon looks like a blank white sheet of paper.
When you place your mouse pointer over the icon the word "NEW" will appear under the mouse pointer. Notice that when the Trading Partner / Submitter form is open and you click on the NEW icon that there are a large number of fields filled in for you. These are standard default entries that may be changed if required, but they will probably be fine, just the way they are. Notice that when you move your mouse pointer over an entry on the form that a tool tip opens up with a brief description of the contents of that field. The Submitter form contains what is called a page frame. This means that there are two pages to the form. This is done since it was not possible to fit all of the data required on a single screen. When the user clicks on the tab at the top of the form which reads `Page 2' , the second page of the page frame will be visible. An organization name or person's name, identification number and contact information are required. When this information has been filled in correctly the data may be saved by clicking on the Save icon on the tool bar. The Save icon looks like a floppy disk.
The data in the TP/Submitter table is trading partner data which is normally used to populate the envelope structure of an ANSI message. The ISA segment of an ANSI message contains data which identifies the Submitter of a message, the intended Receiver of the message and the delimiters used in the message. It also contains message counters and control numbers along with message dates and other information. The GS segment identifies the start of a functional group of transaction sets. It contains information which may or may not be redundant to some of the data contained in the ISA segment. Think of the ISA segment as an outer envelope which contains one or more inner envelopes which contain claims. The inner envelope is represented by the GS segment, whose data is also contained in the TP table.
Remember: Find the record. Edit or Update the Record. Save the Record.
Some of the data which must be entered into the TP table can be found in the first few records of the NSF file.
Gap Analysis or Viewing the NSF file:
At this point you should be able to view the contents of an NSF file you wish to translate to ANSI. This should be done with an editor that does not automatically word wrap the 320 character long lines of an NSF file. Windows NOTEPAD or the shareware program Editeur may also be used. Double click on the file once you have located it with Windows Explorer or MY Computer. Many claims receivers will publish a booklet called a COMPANION DOCUMENT. The companion document contains values for most of the data elements of fields in the ISA and GS segments. The data on the form should be filled in as follows:
Header ID: The Identification number assigned to you as the Submitter of an NSF file to a Receiving entity. This is the number that is found in the NSF AA0 record in field 2, from positions 4 though 19. It may be a maximum of 16 characters long, but is usually shorter. This is the ID that will be used when reading the NSF file to find the correct record to be used to fill in data on the ANSI output file.
Authorization Information Qualifier: This is a code to identify the type of information in the authorization information. It may have a value of `00' (zero, zero) or `03', zero three. If it has a value of `00' it means that there is no meaningful information contained in ISA02, the Authorization information.
Authorization Information: Information used for additional identification or authorization of the interchange message. This is the kind of information declared in the qualifier.
Security Information Qualifier: This is a code used to identify the type of information in the Security information. A value of `00', zero, indicates that there is no security information present. A value of `01' indicates that a file password is contained in the Security Information data element.
Security Information: This is used for identifying the security information about the message sender or the data in the message. The type of information is determined by the Security Information Qualifier.
Interchange ID Qualifier: This is a code to identify the type of identification number contained in the interchange sender ID. Choices range from `01' meaning D&B number to `ZZ' meaning mutually agreed upon. Clicking on the down arrow icon next to the field on the form will cause a drop down display of possible choices.
Interchange Sender ID: The Individual or entity that transmits a file to a recipient is known as the Submitter or Transmitter. This is the data that will be used by the recipient of the file to identify the sender. It May be the same as the Submitter ID in the NSF file, but it does not have to be the same. It will be placed in the ISA segment, position 6. It identifies the sender of the entire ANSI message.
Interchange ID Qualifier: This is a code to identify the type of identification number contained in the interchange receiver ID. Choices range from `01' meaning D&B number to `ZZ' meaning mutually agreed upon. Clicking on the down arrow icon next to the field on the form will cause a drop down display of possible choices.
Interchange Receiver ID: The individual or entity that is the recipient of a file from a transmitter or submitter is called the Receiver. This is the data that will be used by the sender of the file to identify the recipient. It May be the same as the Receiver ID in the NSF file, but it does not have to be the same. It will be placed in the ISA segment, position 8. It identifies the receiver of the entire ANSI message.
Interchange Control Standards Identifier: This is a code used to identify the agency responsible for the control standard used by the message which is contained by the interchange control header and trailer segments. A `U' is the only valid value at this time. It indicates that the X12 committee of the American National Standards Institute is responsible for this standard. This is not to be confused with CMS who published the Implementation Guide which is mandated by HIPAA.
Interchange Control Version Number: This is the version of the ANSI standard which is used to control the creation of these messages. The default value is 00401. It is referred to in the industry as `Forty Ten.' It means version 4 release one point zero.
Acknowledgement Requested: This is a code indicating whether or not the submitter of this interchange or message requests a formal 997 acknowledgment file to be returned to them on receipt of this message. A 997 acknowledgment file is simply the equivalent of a return receipt from the post office for registered mail. While the 997 may contain error messages it does not mean that the claims contained in the file will be acted on in any fashion. It may indicate rejection of parts or the entire message, in which case the claims will most definitely not be paid. The 997 is just a receipt. Possible values for this field are a `0' zero or a `1' one. Zero means no acknowledgment requested. A one means a 997 is requested.
Interchange Control Number: This field is updated automatically by the system if necessary. If there is a message or file control number in the header, or AA0, record of the NSF file. It will be used by the system. If there is no message control number in the NSF file, this number will be incremented and placed in the outgoing message.
Usage Indicator: This is a code indicating whether the transmission is to be considered live production data or a test. Values are `T' or `P.'
Segment Terminator, Element Separator and Sub-Element Separator: These are the delimiter characters which will be used to create messages between the submitter and receiver trading partners represented in this TP record. When a new record is added, the values for these fields in the Program Setup section are the characters which will be filled in here by default. Allowable characters are listed in Appendix A of the implementation guide.
The next several fields on the form are those which are used to populate the GS or group start segment. Similar transaction sets are contained within the GS and GE, or group start and group end envelope within an ANSI interchange or message. Many of them are the same as similar fields in the ISA segment. They do not have to be the same as the ISA segment values, so they are included in the TP table. If in doubt, use the same values in the gs as their counterpart data elements in the ISA segment. They are as follows:
Functional Identifier Code: This is a code indicating a group of application related transaction sets. The allowed value is `HC' for health care.
Application Sender's Code: This also identifies the Individual or entity that transmits a file to a recipient. It will also be placed in the GS segment in position 2. It will normally be the same value as that which is placed in the Interchange Sender ID.
Group Control Number: This identifies the group contained within the GS GE envelope. It is analogous to a batch number within the NSF file. This will be updated automatically by the system if necessary.
Application Receiver's Code: This identifies the entity determined to be the intended recipient of the ANSI message. This ID is assigned by the recipient. In cases of Medicare it is the Carrier ID and will be placed in both the ISA segment position 8 and the GS segment position 3. This normally comes from the NSF record AA0 field 17.
Responsible Agency Code: It indicates that the X12 committee of the American National Standards Institute is responsible for this standard. This is not to be confused with CMS who published the Implementation Guide which is mandated by HIPAA.
Notice at the bottom of the form there is a box which has three radio buttons in it labeled Information, Use it, Slam it. These radio buttons are interpreted by the system in different ways. If the Information button is selected, the system will not use any of the information in the table during the translation process. The data in the table is used for Information only. If the Use it button is selected the program will use the information only when it needs to fill in Submitter data which is missing in the NSF file. If the Slam it button is selected, the data in the NSF file will be overwritten with the values stored in the lookup table.
The second page of the form (select the Page 2 tab) allows you to enter information about the company including company name and contact name.
Once data has been entered into these fields you must save it by clicking on the Save icon with the mouse. The Save icon looks like a picture of a floppy disk.
Now that you have finished with the Trading Partner / Submitter form you may close the form by clicking on the toolbar icon that looks like a door, two icons to the right of the Save icon. This is the form Close icon.
Provider Table
The next lookup table to be filled in is the Provider Table. Open the Provider form by selecting the Data menu and then the Provider option. See Figure 8.
In order to add new provider information, the user must click on the New icon on the tool bar. If you wish to update data that has already been entered, you must first find the correct record and then update and save the data. You may scroll through the records in the provider table by using the VCR buttons on the toolbar or by clicking on the List or Locate icons. Remember: Find the record. Edit or Update the Record. Save the Record.
The Provider form contains what is called a page frame. This means that there are four pages to the form. This was done since it was not possible to fit all of the data required on a single screen. When the user clicks on the tab at the top of the form, which reads `Billing Provider IDs', the second page of the page frame will become visible. This is where information pertaining to the identification numbers of the Billing Provider is entered or updated. The third page of the form contains the Pay To Provider Information. This allows the user to differentiate between locations where services are performed and where the payer of the claim is to send the reimbursement or payment. The Fourth page of the form is labeled Pay to Provider IDs. This is where identification numbers are stored which may be different than those stored in the Billing Provider IDs page frame.
The ID Code in the first page frame is what the system used to find the Billing Provider from the NSF BA0 record, field 2, from position 4 through 18. Once the billing provider record is found the user may enter data that will help the translator to fill in data elements that are required by the ANSI specifications that may not exist in the NSF file, such as an address for service location and one for payment location. This page frame contains a number of fields which are required by the implementation guide. Among the most important fields are the ID Code Qualifier and ID Code. If the user fills in the Organization name, the Individual's name will not be used by the translator. The system looks for an organization name first, then an individual name.
A note about NPI: The acronym NPI stands for National Provider ID. This is an initiative begun by Medicare prior to the year 2000. When Y2k came along this initiative was shelved for redesign of EDI standards to allow for eight character dates. Even though the Medicare ID is defined in NSF version 3.01 as being an NPI and there are NPI references in the ANSI specifications, the NPI has never been mandated by CMS. For this reason the NPI and its qualifier of `XX' are not yet allowed in Medicare claims. Therefore when filling in the Provider ID code and code qualifier, it is important to use the Organization's Federal Tax ID with a qualifier of 24 or the individual providers' social security number with a qualifier of 36. Other ID's may be found in the practice management system that created the NSF file or in the NSF file itself. The BA0 records contain the following billing provider ID's: See Figure 9.
BA0_24 State License Number 15 characters from position 234 through 248
BA0_14 Provider Blue Shield No 15 characters from position 105 through 119
BA0_12 Provider Medicaid ID 15 characters from position 75 through 89
BA0_13 Provider CHAMPUS ID 15 characters from position 90 through 104
BA0_06 Employers Tax ID 9 characters from position 32 through 40
BA0_08 Tax ID Type 1 characters from position 47 through 47
BA0_15 Provider's Commercial Number 15 characters from position 120 through 134
BA0_09 Medicare ID (NPI) 15 characters from position 48 through 62
BA0_10 Provider Upin ID 6 characters from position 63 through 68
The other identification numbers on the form may be filled in if required by specific payers. Normally the ones which are going to be required are the EMPLOYERS ID, MEDICARE ID and UPIN.
The standards require that the Billing Providers' Address be provided. In as much as this data is rarely included in NSF files, the user should fill in the provider forms as completely as possible. The Provider Specialty Code is also a required field. The Provider form has the same sort of tool tip information as the other forms in the system. If you hold the mouse pointer over a field the ANSI destination for the data will be shown. When the ANSI translation is performed, the ID code and code qualifier will be placed in the NM1 segment, positions 8 and 9. The other ID codes from the billing provider page frame and pay to provider page frames will be included in the claims in subsequent REF segments with the appropriate qualifiers. Some systems will implement the maximum number of REF segments to be five.
Notice at the bottom of the form there is a box which has three radio buttons in it labeled Information, Use it, Slam it. These radio buttons are interpreted by the system in different ways. If the Information button is selected, the system will not use any of the information in the table during the translation process. The data in the table is used for Information only. If the Use it button is selected the program will use the information only when it needs to fill in Submitter data which is missing in the NSF file. If the Slam it button is selected, the data in the NSF file will be overwritten with the values stored in the lookup table.
The provider table also has some check boxes at the bottom of the first page frame. These boxes are to be checked if the table is to be used to fill in information about Referring Providers, Rendering Providers, Purchased Service Providers, Supervising Providers, and Ordering Providers at both the claim level and the line item detail level.
The ANSI specifications implementation guide allows a maximum of 5 additional ID numbers beyond those included in the NM1 segments. This means that there may not be more than 5 REF segments with ID numbers in them. Do not fill in more ID numbers in the Provider table than are absolutely required. A Medicare ID, UPIN and one or two others should be sufficient. Fill in too many and your files may be rejected. Electroniclaim has made a conscious decision not to impose a limit to the number of ref segments in the translator.
The Provider table allows the use of both billing provider definitions as well as pay to provider definitions. This allows the payer to determine where services were rendered and to send payment to a different location, such as a bank lock box. The second two page frames are designed to contain the provider pay to information.
Once the data has been entered and saved the form is closed by clicking on the Close icon with the mouse. The close icon on the tool bar looks like a door being closed.
For more information, see the Appendix - HIPAAMagic Billing, Rendering and Referring Provider Lookups at the end of this document.
Facility Table
The next lookup table to be filled in is the Facility Table. Open the Facility form by selecting the Data menu and then the Facility option. You can scroll through the records in the Facility table by using the VCR buttons on the toolbar or by clicking on the List or Locate icons. Remember: Find the record. Edit or Update the Record. Save the Record. See Figure 10.
Click on the New icon on the tool bar and observe the blank facility form. If the facility information is to be used, it must be complete. The Facility Name is found in the NSF file in the EA0 record field 39, from position 209 through 241. The Facility Medicare ID is found in the EA1 record field 04, positions 23 through 37. The NSF documentation lists this as the Facility NPI. As we have mentioned before, the NPI program has not been implemented by CMS. For this reason you may not use the NPI qualifier of `XX' with a Medicare ID. This is also why we strongly suggest that the ID qualifier in line two of the form be a `24' and that you endeavor to find the tax ID numbers of the facilities at which services are performed. The place of service codes in the FA0 record determine where services were rendered and often times the information in the EA0 and EA1 records is redundant or incomplete. The only time that the facility information is required is when services are performed at other than the patient's home or the provider's office. The Facility address is found in the EA1 record in the fields 6 through field 10. In summary the fields are:
EA0_39 Facility Name, 33 characters from position 209 through 241
EA1_04 Facility Medicare ID (NPI), 15 characters from 23 through 37
EA1_06 Facility / Lab Address 1, 30 characters from position 53 through 82
EA1_07 Facility / Lab Address 2, 30 characters from position 83 through 112
EA1_08 Facility / Lab City, 20 characters from position 113 through 132
EA1_09 Facility/ Lab State, 2 characters from position 133 through 134
EA1_10 Facility / Lab Zip Code, 9 characters from position 135 through 143
There has been some special processing built into the system based upon Electroniclaim's experience with NSF files. In the event that the Facility Name field, EA0 field 39, is not blank and the Facility ID, EA1 field 4 is blank or non-existent, we use the name to attempt to find the Facility record in the Facility table. In order to find a Facility by name in the Facility table, the spellings must match exactly. Case does not matter however.
Notice at the bottom of the form there is a box which has three radio buttons in it labeled Information, Use it, Slam it. These radio buttons are interpreted by the system in different ways. If the Information button is selected, the system will not use any of the information in the table during the translation process. The data in the table is used for Information only. If the Use it button is selected the program will use the information only when it needs to fill in Submitter data which is missing in the NSF file. If the Slam it button is selected, the data in the NSF file will be overwritten with the values stored in the lookup table.
Now that you have finished with the Facility form you may close the form by clicking on the toolbar icon that looks like a door, two icons to the right from the Save icon. This is the form Close icon.
Payer Table
The next lookup table to be filled in is the Payer Table. Open the Payer form by selecting the Data menu and then the Payer option. You may scroll through the records in the Payer table by using the VCR buttons on the toolbar or by clicking on the List or Locate icons. Remember: Find the record. Edit or Update the Record. Save the Record. See Figure 11.
In order to add a new record to the table you must click on the New icon on the tool bar that opens with the Form window. The New icon looks like a blank white sheet of paper.
The Payer ID is found in the NSF DA0 record in the DA0_07 and DA0_08 fields, which are in positions 27 through 35. The Payer Name is found in the NSF DA0 record field 9, in positions 36 through 68.
There has been some special processing built into the system based upon Electroniclaim's experience with NSF files. In the event that the Payer Name field, DA0 field 9, is not blank and the Payer ID, DA0 fields 7 & 8 are blank, we use the payer name to attempt to find the correct Payer record in the Payer table. In order to find a Payer by name in the Payer table, the spellings must match exactly. Case does not matter however.
If the NSF file Payer ID in the DA0 record, fields 7 & 8 are blank and the Payer name, DA0 field 9 is also blank in the NSF file, the translator will use the Receiver ID found in the AA0 record, field 17 in positions 227 through 242 for the Payer ID. If the AA0 record field 17 is blank also, the system will use the Receiver ID from the Submitter / Trading Partner file to search the Payer file. This is only done for the first DA0 record in a claim. The payer name and ID number are required fields in the ANSI file but many Medicare carriers required them to be blank in NSF files.
Notice at the bottom of the form there is a box which has three radio buttons in it labeled Information, Use it, Slam it. These radio buttons are interpreted by the system in different ways. If the Information button is selected, the system will not use any of the information in the table during the translation process. The data in the table is used for Information only. If the Use it button is selected the program will use the information only when it needs to fill in Submitter data which is missing in the NSF file. If the Slam it button is selected, the data in the NSF file will be overwritten with the values stored in the lookup table.
Now that you have finished with the Payer form you may close the form by clicking on the toolbar icon that looks like a door, two icons to the right from the Save icon. This is the form Close icon.
Receiver Table
The next lookup table to be filled in is the Receiver Table. The Receiver form is opened by selecting the Data menu and then the Receiver option. The receiver is the entity to whom claim files are sent immediately when they leave the submitters system. The User may scroll through the records in the Receiver table by using the VCR buttons on the toolbar or by clicking on the List or Locate icons. Remember: Find the record. Edit or Update the Record. Save the Record. See Figure 12:
In order to add a new record to the table you must click on the New icon on the tool bar that opens with the Form window. The New icon looks like a blank white sheet of paper.
The Receiver ID is found in the NSF AA0 record in the AA0_17 field, which is contained in positions 227 through 242. The Receiver Organization Name is used in the 1000B loop, NM1 segment. The Receiver ID code and code qualifier are normally used in the ISA segment, element 8, and the GS Segment Element 3, as the Receiver ID. The Receiver ID numbers are self-assigned by the Receiver of the file. The ID qualifier in the NM1 segment, element 8 of the 1000B loop is 46, ETIN, electronic transmitter identification number.
There is no Receiver Name in an NSF file. The ANSI file requires a receiver name, which must come from the Receiver table. This means that there must be an entry in the receiver table for each recipient of claim files. If the Receiver field in the NSF AA0 record, field 17 is blank, the program gets the Receiver ID from the Submitter / Trading Partner table, submitter record, which is found using the Submitter ID, from the AA0 record field 2.
Notice at the bottom of the form there is a box which has three radio buttons in it labeled Information, Use it, Slam it. These radio buttons are interpreted by the system in different ways. If the Information button is selected, the system will not use any of the information in the table during the translation process. The data in the table is used for Information only. If the Use it button is selected the program will use the information only when it needs to fill in Submitter data which is missing in the NSF file. If the Slam it button is selected, the data in the NSF file will be overwritten with the values stored in the lookup table.
Now that you have finished with the Receiver form you may close the form by clicking on the toolbar icon that looks like a door, two icons to the right from the SAVE icon. This is the form Close icon.
Test the System
Now you are ready to test the system.
Find an NSF file. Copy it into the Pre-Processor input folder as found in the system setup form under the data menu.
Pre-Process the NSF file by selecting Pre-Process Claims under the Claims menu. The resulting file of the same name as the input file will be placed in the Pre-Processor output folder, which should be the same as the translator input folder.
Translate the claims from NSF to ANSI 837 transaction set files by selecting Convert from NSF to ANSI 4010 from the Claims menu. Note the name of the output file when displayed on the screen at the completion or processing. Write it down.
Print the ANSI output file by selecting the 837 Claim File Segment Report from the Reports menu. Select the most recently created file from the file selection window. This is the file name which was noted above.
Validate the ANSI output file by selecting the Validate ANSI 4010 File from the Claims menu. Print the validation report when it is previewed on the screen. This is the same report obtained from the Message Log Report if the validation is turned on during processing, which can be done in the program setup.
Read the Validation report. It displays errors. Any error number which is greater than 100 is an error. If the error number is less than 100 it is a warning. Note that the error report references the pages in the implementation guide published for CMS by Washington Publishing Inc., which is named the Health Care Claim:Professional 837 ASC X12 837 (004010X098). This implementation Guide can be obtained from Washington publishing at http://www.wpc-edi.com/hipaa/HIPAA_40.asp . The implementation guide references the NSF fields from which the ANSI claim file data is obtained. In this way the user may determine what NSF data caused the errors to have been created.
Production
Now that the tables have been filled in correctly, you are now ready to convert files from NSF to ANSI X12 837 transaction sets in version 4010 according to implementation guide 004010X098. (The program has been updated to include the first set of addenda to the implementation guide)
The process is simple. Copy the file(s) that were identified above as being, the NSF files that were to be converted, into the Input folder specified by the Import Path in Figure 4, above. This can be done using the Windows Explorer or My Computer from the Windows desktop. Then return to the application and select the Claims option from the Main Menu. Then select the Convert Claims from NSF to 4010 option from the drop down menu on the Claims Menu selection. Selection of this menu item will cause the system to convert any and all of the claim files which are in the input directory and place the ANSI claim output files into the output folder represented in the output path from Figure 4.
Multi-User Considerations
If the software is being used in a multi-user environment, along with a multi-user license, each work station that processes claim files will grab a file and process it, while at the same time preventing others from processing the same file.
In the event that the program fails for some reason during claim file processing, the file name may be left marked as in process. This can occur in either the pre-processor phase or the conversion phase of processing. If you try to pre-process or convert a file which the system thinks is already in process it will not do anything with the file. There are two tables used by the system to keep track of the multi user processing. The files are called Importpre.dbf and Import.dbf respectively. The Import table may be accessed by the Main Menu Data option and selection of the Import table form. The user may use the VCR buttons on the tool bar to scroll through the files that have been processed or the List icon between the binoculars and the funnel on the tool bar. When the correct file name and process date and time are found the Import table form has a radio button box in which the options are Processing or Processed. Change the Processing to Processed. Click the Save icon on the tool bar, and the system will again allow you to process files with that file name. See Figure 13.
The Importpre.dbf table has similar functionality for the Pre-Processor. This table may only be accessed through the Admin option of the main menu. Select the Data Manager sub-option and proceed as follows: Click on the Free Tables option of the Databases page frame of the Data Manager window. Click on the Tables / Views Page frame of the Data Manager. Scroll down to the file named IMPORTPRE.DBF. With this file highlighted, click on the Utilities tab of the page frame. Select the BROWSE button of the utilities. A Browse window will open with the caption "Data Manager Browse - Importpre.dbf" The user may scroll down to the name of the file which the system will not process. Use the right and left arrow keys to scroll to the right and find a column labeled "Process". If the value of the Process field is other than "2", The system will not process this file. Change it to "2" and close the browse window by clicking on the Red "X: in the upper right corner of the window. Close the Data Manager window in the same way and the system will now processed the locked file.
Claim File Validation
Selection of the Validate ANSI 4010 file option from the Claims option of the Main Menu allows the user to validate a specific file for compliance with the format specifications of the implementation guide. Messages are given several levels of importance. A message code of less than 100 is informational. Messages with codes of greater than 100 are error messages. The error messages reference the segment number of the ANSI message and the page number of that segment within the implementation guide. It also lists the loop within the message in which the segment is found. The loop structure may be though of as an index to the implementation guide. It is found on page 51 of the implementation guide. The output of the Validation option under the Claims option of the main menu produces an error report. This error report may be created for any ANSI 837 claim file. The ANSI claim file does not have to have been created by the HIPAAMagic software. When this option is selected the user will be shown a file search window. Remember that files created by the translator are placed in the output path of the translator, whose default folder is: C:\ELECTRONICLAIM\HIPAAMAGIC_8\DATA\OUTPUT\. The user may select the file which is to be validated and the report will be shown on the screen with the user being given an option to print it out..
Claim file validation occurs during translation automatically if the validation is turned on in the program setup. See Figure 4. When this option is selected the errors are placed in the error log table. This table may be accessed by running the Message Log Form. Errors are captured in the message log when they are created. The Message log may be searched by clicking on the list icon on the tool bar, between the funnel and the binoculars.
Reports
The user may create several different reports of the ANSI claim file by selection of the Reports option of the Main Menu.
The Report Manager allows the user to run reports dealing with internal processing in the system. It also allows users to create new reports. This should not be attempted without the help of qualified support personnel.
The Message Log Report prints out the records in the message log. Messages and errors are listed. The messages indicate when the system used data from the lookup tables instead of data from the NSF input file. Errors are listed with the segment number in the message in which the error was discovered. They also list the loop number and segment name within the message and the reason for the error. The page number of the implementation guide which explains the segment is also listed. The user is allowed to enter parameters which are used to limit the report to specific days, errors or files.
The 837 Claim File Segment Report lists the claim file in the same format as is found in the sample section of the implementation guide. The report lists the loop name in bold print on a single line. This is the controlling loop number until the next time a loop number is listed. The next line lists the segment name and appropriate qualifier; then the segment description and type. For example an NM1 segment with an 84 qualifier is a Billing Provider Name. An NM1 segment with a 117 qualifier is a Subscriber Name. The next line of the report lists the segment number within the message file, akin to a line number, and the contents of the segment. Remember that a proper ANSI message file does not contain any return or line feed characters. It is one long character string. Most recipients of ANSI claim files will not allow them to be submitted containing carriage return or line feed characters at the end of every segment. This report is the way in which the message files may be viewed line by line or segment by segment. The user may select to view or print messages from the message log as well. In order to understand an error message in an ANSI file the user must know the loop in which the error occurred in the ANSI message, the Segment in which the error occurred and the position within the segment or data element that caused the error. There is another section of the manual which deals with understanding error messages.
The 837 Claim File Segment Detail Report lists the claim message file as above but with an additional level of detail. In addition to the listing above this report lists each data element on a separate line. The data is listed with its definition.
The 997 Acknowledgement Segment Report allows the user to print the 997 transaction set, Functional Acknowledgement report. This 997 transaction set is a functional acknowledgement of the receipt of an ANSI message submission. It is analogous to a certified mail return receipt. It does not guarantee adjudication of the submitted claims in any way. It can contain error messages regarding the submitted claim file. See the Implementation guide, page B.15 for an explanation of the 997 transaction set. You are looking for an AK5 or AK9 with a transaction set acknowledgement code of `A' for accepted.
The 997 Acknowledgement Segment Report Detail allows the user to print the 997 transaction, functional acknowledgment with each data element listed individually and described in detail
The File Transmission Report lists the files in the output folder and their intended recipients. The user may find this report helpful when transmitting files to the payers or intermediaries.
The Gap Analysis Report is designed to facilitate the collection of information which may be required for the various lookup tables in the system. It is very useful during program setup. The report starts with a listing of the Submitter / Trading Partner name, address and ID. Next it lists the Receiver ID and a blank space for the receiver organization name. There is no assigned place in the NSF for the receiver organization name. The receiver ID is listed in the NSF AA0 record, field 17. After listing the Submitter and Receiver the Gap Analysis Report lists the Information about the Billing Provider. The NSF contains fields which are designed to contain the Billing Provider specialty codes, they are not widely used. The same thing is true about Provider tax identification numbers. The Provider table in HIPAAMagic is designed to hold this information for use when needed.
After listing data about the billing provider, the report lists information from each claim in the file about the Payer Name, Address and ID. This is information which is found in the NSF DA0, DA1 and DA2 records. If any required Payer information is missing in the NSF file it may be recorded here for later use in updating the lookup tables.
When the Gap Analysis report lists information about referring providers, particular care must be taken when reviewing the data about the provider National Provider ID, or NPI. An explanation about National Provider ID is given elsewhere in the system documentation but bears repeating here. Even though there is documentation published by Medicare in which the Medicare ID numbers in the NSF are referred to as the NPI, National Provider ID, they may not be used in the ANSI X12 837 transaction set files until the National Provider Identification number system is implemented by CMS. This is the single most important reason for the requirement that providers furnish their employer tax identification numbers for use in the lookup tables or use their tax ID numbers in the NSF files in the appropriate fields. Medicare has taken the position that improper use of the NPI is reason for rejection of an entire claim file. When references are made to NPI in NSF files, they refer to the Medicare assigned ID number. When references are made to the NPI in ANSI files they refer to the National Provider ID initiative assigned ID numbers. When the Gap Analysis Report lists NPI numbers care must be taken when they are read. Provider ID numbers are listed in several places in NSF files. In addition to the NPI, Medicare has long used an ID known as the UPIN number, or unique provider identification number. Both the NPI or Medicare ID and the UPIN numbers are assigned by Medicare to Doctors and other medical care providers. UPIN numbers are normally of the format of a single alphabetic character followed by 5 numeric digits. UPIN numbers are often placed in Medicare ID number positions within NSF files. This can happen in the BA0, BA1 records of the billing provider information. It can also happen in the claim level referring provider information in the EA0 records, fields 20 and 21. It may also happen in the FA0 record, field 23 for rendering provider Medicare ID, and in the FA0 record field 24 for referring provider Medicare ID. In the FB1 records the Identification numbers are UPIN numbers. When the translator sees a Medicare ID in the NSF file it uses the Medicare ID to look up the provider in the lookup table and then substitutes the providers Tax ID when constructing ANSI name segments (NM1 segments.) Similarly when the translator sees UPIN numbers in the NSF files it uses the UPIN number in the lookup table to find the provider entry and then substitutes the provider Tax ID when constructing ANSI name segments (NM1 segments.) When the software which creates the NSF files swaps UPIN and Medicare ID numbers, this situation may be rectified through the use of the Pre-Processor and is explained later in this document. The Pre-Processor may be used to swap field contents or to blank them out altogether.
Message Log
Once the files have been converted to ANSI the user should review the Message log for the existence of error messages. If the message log shows no errors, the file should be transmitted to the recipient listed on the transmission log through the means dictated by the recipient. In the event that there are errors in an output file, the corresponding input file, which is now stored in the archive folder with the same name as the output file but with a different extension, NSF, must be fixed and re-converted prior to transmission to the payer or other recipient. In the event that corrections were required to the NSF file, remember to place the fixed file in the input folder for reprocessing. Remember: Convert, Review, Fix input if necessary, Re-Convert, Transmit to payer.
If there are changes that must be made to the input files on a repeated basis, you may use the NSF Pre-Processor to facilitate these changes to the NSF files that are to be converted. The pre-processor documentation is included in the Electroniclaim NSF to ANSI 4010 Help file that can be found by selecting the Contents option from the Help menu.
NSF Pre-Processor
The Pre-processor system allows the user to make changes to an NSF file prior to being translated into the ANSI format. The National Standard Format has been interpreted in different ways by different users. Because of this, it can be necessary to modify either the incoming file or the translator to enable the output of the translator to be exactly what is required in the HIPAA implementation guide. We chose to allow the user to modify the input file, and to keep the translator consistent.
The pre-processor reads through the NSF file, line by line and allows the user to create executable code which can be used to modify the content or position of the data in an NSF record. The program loads the contents of each NSF record into variables. When it has loaded the record into these variables it scans through each of the variables and runs user defined executable code. This code must be written in the Microsoft Visual FoxPro language. The executable code is stored in blocks of text in the pre-processor definitions table. The Pre-Processor form is opened by selecting the Pre-Processor option under the DATA option of the Main Menu. The contents of the variables are referenced in a predetermined fashion which allows users of the software to create executable code easily. The method used to reference each variable in an NSF record is as follows:
Lower Case letter oh + the NSF record identifier + a period character + the word `FIELD' + a two character field number. As an example, the Receiver Identification number in the NSF file is the 17th field of the AA0 record. Therefore the reference to the contents of this field is: "oAA0.FIELD17" The third character of the record identification in the National Standard format is always a numeric character. An example of how to change the value of the data in this field could be as follows:
Any changes made to the contents of the field are rewritten to the file when the next NSF record is read.
The support team for HIPAAMagic will normally provide code which may be cut and pasted into your application. A few notes about the Visual FoxPro language are in order here. If a line of code in the Pre-Processor begins with the `*' character the line of code will not be executed. The asterisk character is the character which denotes a comment line. Two ampersand characters at the end of a line indicate that anything after the ampersand characters is also a comment. Comments are used to document code and tell a person reading the code long after it was written what it was intended to do. Documentation of the Visual FoxPro Language may be found on line at: http://msdn.microsoft.com/vfoxpro/techinfo/documentation/default.asp
Experience with translating NSF files to ANSI 837 transaction sets has indicated that there are some common areas in NSF files which have to be changed in order to become HIPAA compliant. With each successive iteration, of electronic claim formats, there has been a desire on the part of the format designers to include more information in each claim. These design changes have been geared towards the adjudication side of the equation. In the New ANSI 837 formats there is a requirement for individual and organizational tax identification numbers that has not been as rigorous in the past as it is now. This is complicated by the nomenclature in the NSF of provider Medicare identification numbers.
The National Provider Identification Initiative was started by the Health Care Financing Administration, now known as CMS for the Centers for Medicare and Medicaid Services, prior to the year 2000. The Y2K software scare caused the provider identification initiative to be shelved. As of this publication it has not been revived. Medicare has taken the official position that until the National Provider Identification number is mandated for use, it may not be used.
In the NSF, the billing provider information is contained in the BA0 and BA1 records. In version 3.01 of the NSF as defined by HCFA/CMS there is a field which is named the provider NPI. It is field 9 of the BA0 record. This is a different field than the provider UPIN number which stands for unique provider identification number. The billing provider UPIN is contained in the BA0 record, field 10. These are separate and distinct identification numbers. They are both assigned to providers by their local Medicare carriers. There are numerous other instances where Medicare assigned identification numbers are used within NSF claims. The EA0 record contains information relating to the referring provider in fields 20 through 27. Field 20 is the referring provider NPI and field 21 is the referring provider UPIN. Since the NPI may not be used in the ANSI 837 transaction set until the NPI is mandated by congress one is left with only the provider's tax ID or social security number as allowed ID numbers in some of the ANSI segments.
Specifically the NM1 segments in the ANSI claim files may not use an NPI in position 9. If claims are submitted to Medicare carriers with an `XX' qualifier in NM1 position 8 the claim and possibly the entire file will be rejected. There are several places where this prohibition can come into play. In the NSF there are provider listings in the FA0, FB0, FB1 records. These translate into the Rendering, Referring, Ordering and Supervising providers in the ANSI 837 transaction set. There can be instances of these providers at the claim level as well as the line item detail level in ANSI claim files. It is imperative that theses providers and their associated identification numbers be handled properly. This is where most of the executable code in the pre-processor becomes involved.
Case: NSF file contains a UPIN number in EA0_20 and EA0_21 is blank. It is necessary top move the contents of EA0_20 into EA0_21 and blank out the contents of EA0_20. Code is as follows:
Remember that the `*' character as the first character of a line of Visual FoxPro code indicates that the line is a comment line. Similarly the double ampersand, &&, indicates that everything to the right them is also a comment. The above code may be cut and pasted into the executable window of the EA0_20 field in the Pre-Processor form. This may be done by highlighting the code in this document with a mouse and pressing the control key, CTRL' simultaneously with the `C' key. Then go to the executable window for the EA0_20 field in the Pre-Processor. Place the mouse cursor in the upper left of the executable window by a single left click of the mouse with the cursor indicator in the upper left of the window. Then press the control key, `CTRL' simultaneously with the `V' key which causes the clipboard contents, which you filled with the CTRL `C', to be pasted into the executable window. Now, click on the Save icon in the tool bar. The Save icon looks like a floppy disk. The code has now been saved in the Pre-Processor and will be run against each EA0 record in an incoming NSF file. This is how the Pre-Processor allows a user to make changes to the contents of the NSF file prior to being translated into the ANSI 837 transaction set.
Case: The claim file is being submitted to a local Medicare carrier but there is no payer ID or name in the DA0 record. This is a common occurrence. For many years Medicare Carriers each had their own interpretation of the National Standard Format. They did not use the data contained in the payer name or payer ID. They used the data contained in the submitter ID and provider medicare ID to determine that a file was intended for them. After that, they looked at each subscriber's insured ID to make sure that the individual was Medicare eligible, then they imported and processed the claim. In the ANSI format for claims the payer name and ID are required fields. In the DA0 record in the NSF there are two fields which indicate the source of payment and claim type. These are the fifth and sixth fields in the DA0 record. The fourth field indicates whether or not the claim submitter is requesting payment from the payer. The following code may be used to fill in the payer name and ID.
Case: The NSF file contains the name of the facility where services were rendered to the patient, but not the address or correct identification numbers. The Facility name is contained in the EA0 record, Field 39. The rest of the information about a facility is contained in the EA1 record in fields 4 through 10. If the translator sees a name in the EA0_39 field it will try to create an entry for the facility in the ANSI 837 transaction set. This entry requires a tax ID, as well as a name and address, including city state and zip code. The ID and address should come from the EA1 record, fields 4 through 10. Note that the fifth field, EA1_05 is not used. This is where a tax ID could have been placed, but was not. For this reason the translator will create an NM1 segment with an ID with an `XX' qualifier in the eighth position of the segment. As it was mentioned above, this is not allowed until the National Provider Identification initiative is mandated to be used. There are at least two possible solutions.
The first possible solution is to add the Facility to the Facility lookup table with the system ID equal to the contents of the EA1_04 field. The Facility tax ID must be stored in the Id number field of the facility form with a `24' or `34' qualifier depending on whether the Facility Tax ID is an employers tax ID or a social security number. The `Slam It' check box at the bottom of the Facility form must be checked to insure that the translator uses the tax ID in place of the NPI ID from the NSF file.
The second possible solution is to blank out the facility information altogether in the NSF file. This may be done if the facility is the provider's office or the patient's home. The following code may be placed in the EA1_04 field of the Pre-Processor:
This requires that code be placed in the EA0_39 field which blanks out the contents of EA0_39. This code may be as simple as :
This code will erase the contents of every EA0_39 field in any NSF file which is run through the Pre-Processor.
The Pre-Processor remembers the contents of each preceding line in the NSF file which has not been over written by a line with the same line ID, AA0, BA0, etc. This means that when the user wishes to modify the contents of a claim based on data contained in the Provider batch header records, BA0, BA1, it can be accomplished. Remember that this also means that in the event that there is more than one insurance coverage in a claim, which implies that there is more than one set of DA0, DA1, DA2 records, when the Pre-Processor gets to the EA0 record in a claim it remembers the last set of DA0,DA1,DA1 records which is not the primary coverage information. In the event that there is a complicated set of circumstances which require programming, the user may contact the support department at Empire Medical Review Services, Inc.
This should give an overview of the types of problems which one may encounter during translation testing with payers and how easy it is to correct just about anything one may need to fix using the Pre-Processor.
Appendix - HIPAAMagic Billing, Rendering and Referring Provider Lookups
Billing and Pay to Provider: All billing and pay to provider loops are filled with data from the NSF file first and overwritten with data from the provider lookup tables if the Slam It radio button is checked. The key field for lookup is the BA0_02 field in the NSF file. The BA0_02 field is the first field on the Provider table form from the Data menu (Data > Provider). It is in the first tab of the form, upper left, and when the mouse is placed on it you see a tool tip that says BA0_02. The billing provider entry in the Provider table should have the billing provider specialty code filled in as well as the group or practice employer's tax id, with a 24 qualifier. The contact field and the contact phone number are also required. Use no punctuation in the phone number.
Rendering Provider: Claim Level or 2310B loop. The first detail service line in the NSF is searched for the existence of either FA0_23 or FB1_14 or FB1_17. These fields in the NSF are Rendering Provider NPI, Rendering Provider Last Name or Company Name and Rendering Provider UPIN respectively. If you don't have any of these fields then you do not get a rendering provider loop in the ANSI file at either the claim level or the detail level, 2310B or 2420A loops.
If you have one or more of the FA0_23, FB1_14 or FB1_17 fields the software will try to find the provider in the provider table as follows:
First we will use the FA0_23, rendering provider NPI field to look up the provider in the provider table. This is the Provider Medicare ID in the Provider table. It is on the Billing Provider IDs tab of the Provider maintenance form (select Data > Provider from the main menu). Remember FA0_23 = Medicare ID in Provider table. None of the other ID numbers in the table are used in this search.
Second, if the FA0_23 field is blank we will use the FB1_17 rendering provider UPIN number to search the provider table. This is the Provider UPIN in the provider table. It is also on the Billing Provider IDs tab of the Provider maintenance form (select Data > Provider from the main menu). Remember FB1_17 = Provider UPIN ID in Provider table. None of the other ID numbers in the table are used in this search.
Once the correct provider record is found, the NM1 segment and any applicable ref segments are filled in, in the ANSI file.
If there are subsequent entries in the rendering provider fields on detail records other than the first detail record, FA0 sequence 02 or higher, they will be used and included in the ANSI file only if they are different than the first detail record.
Referring provider: Claim level 2310A loop.
For the claim level referring provider we look first in the EA0_21 field for a UPIN number and then in the EA0_20 for the referring provider NPI or Medicare ID. The Provider table is searched using the Provider UPIN as the key field or the Provider Medicare ID in the event that the first search is unsuccessful. If there is no entry in the EA0 record for referring provider we will use the entry in the first detail line or FA0 record to apply to the entire claim. If there are subsequent entries in the detail records for referring provider, they will be included in the ANSI output file only if they are different than the first detail record entry.
Referring Provider: Detail level 2420F loop.
For the detail level referring provider we use the FA0_24 field first and then the FB1_13 field second to search for the provider record in the provider table. If there is an FA0_24 entry and we get a hit on the provider table using the Medicare ID as the key field we will then ignore the FB1_13 information if we have the Referring Provider radio button checked and Slam It checked also.
