January 22, 2008
Electronic Data Interchange
Medicare Part A 837 Version 4010 A1 Companion Document
The Health Insurance Portability and Accountability Act (HIPAA) requires that Medicare, and all other health insurance payers in the United States, comply with the EDI standards for health care as established by the Secretary of Health and Human Services. The ANSI X12N 837 implementation guides have been established as the standards of compliance for submission of claims for all services, supplies, equipment, and health care other than retail pharmacy prescription drug claims. The implementation guides for each X12 transaction adopted as a HIPAA standard are available electronically at http://www.wpc-edi.com 
.
.The following information is intended to serve only as a companion document to the HIPAA X12N 837 Institutional Claim Implementation Guide (IG). The use of this document is solely for the purpose of clarification.
The information describes specific requirements to be used for processing data in the FISS system of First Coast Service Options, Inc. (FCSO), Contractor number 00090. The information in this document is subject to change. Changes will be communicated in the standard Medicare EDI notifications and will be available on the Medicare Web site: www.fcso.com . Separate companion documents have been or will be issued for use with other HIPAA transaction standard IGs. This companion document supplements, but does not contradict any requirements in the X12N 837 Institutional Implementation Guide.
. Separate companion documents have been or will be issued for use with other HIPAA transaction standard IGs. This companion document supplements, but does not contradict any requirements in the X12N 837 Institutional Implementation Guide.Below is a listing of Medicare specific guidelines related to the HIPAA 4010A1 Transaction
• The maximum size for the fields containing the number of day information (covered, lifetime reserve, etc.) in the Medicare system is four characters. Claims submitted with data that exceeds four characters will be returned to the provider (RTP’d) or will be errored back to the submitter by FCSO.
• The maximum size for dollar amount fields in the Medicare system is 10 characters. Claims submitted with dollar amounts in excess of 99,999,999.99 will be RTP’d or will be errored back to the submitter by FCSO.
• Claims submitted with attending, other or operating physician UPIN data exceeding 6 positions will be RTP’d or will be errored back to the submitter by FCSO.
• Claims with external code set data that does not conform to the format requirements of the external code set maintainer will be RTP’d or will be errored back to the submitter by FCSO.
• Data elements referencing external code sets are limited to the size of the data as defined by the code set maintainer. For example, the element in the Implementation Guide designated for HCPCS information may contain up to 30 positions but the HCPCS external code list allows only 5 positions (claims with more than 5 positions of HCPCS data in this element would be RTP’d) or will be errored back to the submitter by FCSO.
• The maximum size for the service unit count field in the Medicare system is 7 characters. Claims submitted with data that exceeds this limit will be RTP’d or errored back to the submitter by FSCO. Claims submitted with decimal data will be rounded to the closest whole number before being processed.
• The Medicare system does not process decimal points in diagnosis codes or ICD9-CM procedure codes. Medicare will strip out decimal points submitted in valid diagnosis or procedure codes before processing.
• You may send as many diagnosis codes as allowed in the implementation guide. However, only the primary/principal and first eight other diagnosis codes will be considered for adjudication and payment determination.
• Hospital other (14X) claims that lack diagnosis information when required for CMS adjudication (2300 HI Principal, Admitting, E-Code and Patient Reason for Visit Diagnosis Information) will be RTP’d or errored back to the submitter by FCSO.
• Claims that lack a patient status code when required for CMS adjudication will be RTP’d or errored back to the submitter by FCSO.
• Claims that lack an admission source code when required for CMS adjudication will be RTP’d or errored back to the submitter by FCSO.
• Inpatient claims that lack HCPCS when required for CMS adjudication will be RTP’d or errored back to the submitter by FCSO.
• Medicare will process only HL structures as described in the implementation guide front matter (Billing Provider HL (parent) followed by the appropriate Subscriber HL (child).
• FCSO will convert all lower case characters submitted on an inbound 837 file to upper case when sending data to the Medicare Processing system. Consequently, data later submitted for coordination of benefits will be submitted in upper case.
• Only loops, segments, and data elements valid for the HIPAA Institutional Implementation Guide will be translated. Submitting data not valid based on the Implementation Guide will cause files to be rejected.
• The following characters from the extended character set will not be accepted and may cause the interchange (transmission) to be rejected at the translator:
• Percent Sign %
• Brackets [ ] { }
• Pound Sign #
• Slash mark \
• Less than <
• Dollar Sign $
• The characters tilde (~), asterisk (*), the pipe (|), the colon ( : ) or greater than sign (>), may be used only as segment, element and sub-element delimiters. Use of these characters other than as specified will cause the interchange (transmission) to be rejected at the translator.
• You must submit incoming 837 claim data using the basic character set as defined in Appendix A of the 837 Institutional Implementation Guide. In addition to the basic character set, you may choose to submit lower case characters and the ‘@’ symbol from the extended character set. Any other characters submitted from the extended character set may cause the interchange (transmission) to be rejected at the intermediary’s translator.
• The National Provider Identifier (NPI) must be submitted in all NM109 data elements (NM108=XX) where NM109 is required and in the Service Facility (2310E) NM109 if known.
• All dates that are submitted on an incoming 837 Claim Transaction must be valid calendar dates in the appropriate format based on the respective qualifier. Failure to submit a valid calendar date or submission of a future date (with billing exceptions) will result in rejection of the claim or the applicable interchange.
• Compression of files using PKZIP is supported for transmissions between the submitter and FCSO.
• Only valid qualifiers for Medicare must be submitted on incoming 837 claim transactions. Any qualifiers submitted for Medicare processing, which are not defined for use in Medicare billing may cause the claim or the transaction to be rejected.
• Do not use Credit/Debit card information to bill Medicare. Credit/Debit card information will be ignored.
• FCSO will edit data submitted within the envelope segments (ISA, GS, ST, SE, GE, and IEA) beyond the requirements defined in the Institutional Implementation Guides. Requirements are listed in this document under “enveloping”.
• FCSO will not process an interchange (transmission) that is not submitted with a valid receiver/submitter code (as assigned by FCSO).
• FCSO will reject an interchange (transmission) that is submitted with an invalid value in GS03 (Application Receivers Code).
• FCSO will accept claims for only one line of business per transaction. Claims submitted for multiple lines of business within one ST-SE (Transaction Set) will cause the transaction to reject.
• FCSO will reject an interchange (transmission) that is not submitted with unique values in the ST02 (Transaction Set Control Number) elements within the same GS to GE envelope.
• Transaction Set Purpose Code (BHT02) must be equal ‘00’ (Original).
• FCSO will accept and process transmissions with a Claim or Encounter Indicator (BHT06) of 'CH' (Chargeable). FCSO will accept but will ignore a Claim or Encounter Indicator (BHT06) if 'RP' (Reporting) during adjudication.
• The 837 Institutional claim transaction will not be piloted. Claim files submitted with a Transmission Type Code value of 004010X098DA1 in REF02 will cause the file to be rejected.
• Providers shall be in compliance with CR 5243: ‘Reporting of Taxonomy Codes to Identify Provider Subparts on Institutional Claims’.
• The subscriber hierarchical level (HL segment) must be in order from one, by one (+1) and must be numeric.
• The Patient Hierarchical Level (2000C loop) is not used.
• Negative values submitted in CLM02 may not be processed and may result in the claim being rejected.
• Total submitted charges (CLM02) must equal sum of the line item charge amounts (SV203).
• Data submitted in CLM20 (Delay Reason Code) will be ignored.
• Effective October 2004, all diagnosis codes submitted on a claim must be valid codes per the qualified code source. Claims that contain invalid diagnosis codes will be rejected.
• The format for National Drug Codes (NDC) is 5-4-2 (11 positions). Claims that contain NDC codes in any other format will be rejected.
• We suggest retrieval of the ANSI 997 functional acknowledgment files on or before the first business day after the claim file is submitted, but no later than five days after the file submission.
• FCSO will generate a 997 Functional Acknowledgment transaction in reply to an 837 transaction. FCSO will issue specific instructions about accessing the 997 transactions.
• For 997 acknowledgements, FCSO will return the version of the standard used to create the 997 Transaction in GS08 (Version/Release/Industry Identifier Code).
• Data submitted in Property and Casualty loops will be ignored.
• If used, currency code (CUR02) must equal ‘USA’.
• A 0001 total revenue line should not be sent.
• Data submitted in the PWK (Paperwork) segment will not be processed.
• Only data submitted in the Claim NTE*ADD segment will be processed. All data submitted in the other NTE segments will not be processed.
• FCSO will edit data submitted within the envelope segments (ISA, GS, ST, SE, GE, and IEA) beyond the requirements defined in the Institutional Implementation Guides. Requirements are listed in this document under “enveloping”.
• Claims submitted with more than 449 service lines per claim will be RTP’d.
• Only valid qualifiers for Medicare must be submitted on incoming 837 claim transactions. Any qualifiers submitted for Medicare processing which are not defined for use in Medicare billing may cause the claim or the transaction to be rejected.
• You may submit up to 5 modifiers.
• Any file resubmitted within 30 days will reject as a duplicate file if the two files are an exact byte for byte match.
• The HIPAA 837 transaction only allows for 1 Investigational Device Exemption (IDE) per electronic claim.
• Claims containing a non-numeric revenue code will have the revenue code replaced with 9’s by the standard system, and the claims will RTP. Revenue codes must be 4 digits in length, with a leading zero.
• Notice of Election (NOE) is not established under HIPAA. These claims should be submitted via paper or DDE.
• FCSO will validate individual identifiers submitted within the ISA and GS envelope segments in addition to the verifying the format requirements defined in the IG. Claims submitted with invalid Medicare identifiers will be RTP’d.
• Both the 'from' and 'to' Statement Dates are required and must be entered in the DTP*434 segment in the 2300 loop for adjudication. The same date can be used in both locations. Claims received without the 'from' and 'to' dates will RTP in the processing system.
• A unit rate (SV206) is required when the associated revenue code is between 100-219. Zero is an allowable entry in the field.
• There are a number of elements where, for Medicare adjudication, the Fiscal Intermediary Shared System (FISS) processing system requires fewer bytes than the 837 Implementation Guide allows. If a numeric field is received longer than the FISS processing system edits allow, that field will be converted to all nines (9). If an alphanumeric field is received longer than FISS edits allow, that field will be converted to all ampersands.
For example: In ANSI the billing provider number (NM1 09) has a COBOL picture of up to 80 characters but FISS only accepts up to 13 positions. If Medicare receives a claim with a provider number of 15 characters, the file will be accepted at mailbox, the provider number will be converted to 9999999999999 to reflect that data provided exceeds that expected by Medicare for processing and the claim will reject (RTP) at the FISS processing system. These abbreviated field lengths are in line with current Medicare claim processing.
Specifications Necessary for Creating and Transmitting Tests
Test Files
EDI submitters are required to pass testing prior to production usage of the 4010A1 version of the X12N 837.
You must submit at least 25 test claims within your 4010A1 file, representative of all types of bills you currently send to Medicare Part A. We ask that you only send positive test files, which contain claims you believe should process and pay. In the file envelope, the ISA 15 must contain a “T”. Note: This file will only be processed as a test; no claims will be paid.
Please review the information under Reports for details of reports that may be returned to you after submitting a test file. Medicare will not contact you in regards to a rejected file. If your file passes both Standard and IG requirements, Medicare will contact you with your test results within 3 business days.
If an EDI submitter is using a vendor, clearinghouse, or billing service to generate a certain transaction and that entity has passed testing requirements for a specific transaction and is using the same program to generate the translation for all of their clients, then all clients of the vendor/clearing house /billing service will not be required to test prior to intermediary acceptance of production. It is the responsibility of the vendor, clearinghouse or billing service to provide Medicare their client information.
Delimiters
The Functional Acknowledgment report (997) will be returned to you using the delimiters specified within the 837. Note: if you use the tilde (~) as a segment delimiter, your 997 will be returned to you as one string, “unwrapped.”
Enveloping
Enveloping information must be as follows:
(Files that do not include this information will reject.)
ELEMENT |
CONTENT |
|---|---|
ISA 05 & 07 |
ZZ |
ISA 06 |
Your mailbox number |
ISA 08 |
592015694 |
ISA 15 |
T or P (test/prod) |
GS 02 |
Your sender number |
GS 03 |
MEDA00090EMC |
GS 08 |
004010X096A1 |
REF 02 |
004010X096A1 |
1000A loop NM1 09 |
Your sender number |
1000B loop NM1 09 |
00090 |
Claims files submitted with a Transmission Type Code of 00401X098DA01 in REF02 will cause the file to be rejected | |
Commands
In addition to LOGON and SUBMIT command, you will need two OBTAIN commands, one for the 997 which has a EDI data type and a second command for the Inbound Reject and Accept reports which have a REJ data type. The appropriate command instructions can be found in our publication Guide to Gateway which is available on our Web site at www.fcso.com .
.TA1
If your test file contains incorrect enveloping information (ISA, GS, ST, SE, GE, IEA segments) a TA1 will be returned to you. If you need assistance reading your TA1 please contact Medicare EDI at the number below.
997 Functional Acknowledgment
If your ANSI X12 4010A1 file does not create a TA1 you will receive a Functional Acknowledgment (997) report. This report, sent to your mailbox for retrieval, will tell you if your file has been accepted under X12 Standard. Standard requirements can be found in the 4010 Implementation Guide* (IG) under the STANDARD heading for each segment. This report is created up to 4 hours after transmission, but is usually ready for pick up in your mailbox in the same session. Any error at this level will cause the entire FILE to reject.
* X12 Implementation Guides can be downloaded from www.wpc-edi.com .
Additional documentation can be found at www.cms.hhs.gov.
.Additional documentation can be found at www.cms.hhs.gov
.Medicare Part A Inbound Reports
Subsequent to files passing the X12 Standard, they are then reviewed for X12 Implementation Guide requirements. X12 Implementation Guide requirements can be found in the 4010A1 Implementation Guide under the IMPLEMENTATION heading for each segment and in the body of the segment information. Medicare Part A Inbound Reports will be generated and ready for pick up in your electronic mailbox on the business day following the day the file was transmitted. For example, if a file is sent on Monday and passes standard level edits with a positive 997 report, the IG claim level reports will be available on Tuesday. If you receive a 997 indicating your file rejected, the file will not be subjected to the Implementation Guide requirements and therefore, no Medicare Part A inbound report will be created.
There are two Medicare Part A reports which may be returned to your electronic mailbox. The Medicare Part A Inbound Reject report is only created when an IG error exists. If your file does not contain any IG errors you will not receive this report.
If any or all claims pass the IG level edits you will receive a Medicare Part A Accept report, which summarizes claims that have been passed on to the FISS processing system.
If your file passes standard ANSI 997 edits, you will always receive at least one Implementation Guide report, either an Accept or Reject report. If only a portion of your claims reject at the IG level, you will receive two reports, one listing the claims that rejected and the other listing the claims that were accepted.
These reports can be retrieved with an “OBTAIN REJ” command. We recommend that you change your command to ‘OBTAIN REJ ALL” which will allow you to retrieve all reject reports in one session. If you choose not to modify your obtain command, you can continue to retrieve the reports separately by submitting multiple obtain commands.
These reports are not generated during the new sender testing phase.
Implementation Guide rejects are claim level, and are performed at three levels:
Provider:
If your file has an error in a Provider loop – all claims for that provider will reject at the mailbox. All other good providers and their claims within the file will pass into the processing system.
Subscriber:
If your file has an error in a Subscriber loop – all claims for that subscriber will reject at the mailbox. All other good claims for that provider and subsequent claims within the file will pass into the processing system.
Claim:
If your file has an error within a claim - only that claim will reject at the mailbox. All other claims for that subscriber within the file will pass into the processing system.
Note: These edits are performed at the Implementation Guide level. If your file has an ANSI Standard error (997 report) the entire file will still be rejected.
The only time rejected claims are not listed in detail is if an entire loop has been rejected. That error is noted on the bottom of the Reject report.
In addition to the Implementation Guide edits, the following Medicare business edits must be met to have a claim successfully pass through the Medatran edits. Please note that Medicare will now edit for field content and claim rejections will occur if data is not valid.
Medicare Business Requirement |
ANSI Reference |
|---|---|
The ‘Facility Name’ should not be used to indicate the lab that will perform the lab work. This loop, with an “FA” qualifier in the NM1 02, should not be used for Medicare Part A claims. |
2310E Service Facility Name loop NM1 segment N3 segment N4 segment REF segment |
Outpatient claims must not contain a discharge hour. A DTP segment with a qualifier of ‘096’ must only be used for Inpatient claims. |
2300 Claims Info loop DTP segment |
The date range for a line item date of service should not be used. A D8 qualifier with a single date of service is required for all Medicare Part A claims. An RD8 date range should only be used for pharmacy claims. All outpatient claims must contain a date of service for each revenue code or the claim will be rejected. |
2400 Institutional Service Line loop DTP segment |
If a service, such as chemotherapy, occurs on 5 different dates, the revenue code and HCPCS must be listed 5 times on the claim, once for each date. See note below for exceptions. |
2400 Institutional Service Line loop DTP segment |
The exception to individual revenue code lines is dialysis, home health and hospice providers. Those providers can continue rolling up the services onto a single, dated line, as long as that line has a date that falls within the statement dates of the claim. Breaking out claims by individual dates of service is still allowable. This rollup work around is only acceptable for TOBs 72x, 81x, 82x, 32x, and 33x. |
2400 Institutional Service Line loop DTP segment |
Diagnosis Related Group (DRG) information cannot be submitted on outpatient type of bill claims. This segment with a ‘DR’ qualifier can only be used to report DRG information to the payer on inpatient claims. |
2300 Claims info loop HI segment DR qualifier |
You must use ‘MEDICARE’ as the group name for the subscriber. The group number must be blank. Do not use ‘999999’ or any other information in the group number field. |
2000B Subscriber loop SBR 03 and 04 |
All Medicare inpatient claims must contain the source and type of admission. |
2300 Claim info loop CL1 01 and CL1 02 |
The “ZZ” qualifier, which represents ‘patient’s reason for visit’ is required only for unscheduled outpatient visits and is traditionally only used for emergency room and clinic visits. The ZZ qualifier is not allowed on 76x type of bill claims. All claims containing revenue code 045X, 0516, or 0526 must also contain a “ZZ” qualifier, along with a compliant “Patient Reason for Visit” diagnosis code. If a ‘ZZ” qualifier is received without those revenue codes, your claim will reject. All Health Insurance Prospective Payment System (HIPPS) Rate codes used with a “ZZ” qualifier will be accepted. A complete list of valid HIPPS codes may be found at http://www.cms.hhs.gov/ProspMedicareFeeSvcPmtGen/02_HIPPSCodes.asp  . |
2300 Claim info loop HI segment – ZZ qualifier |
The individual relationship code (SBR02) must contain ‘18’ which represents ‘self’. The patient and subscriber must be the same person for Medicare claims. This field cannot contain spaces. |
2000B Subscriber level SBR 02 |
An admitting diagnosis is always required on Inpatient type of bill claims. |
2300 Claim Info loop HI segment - BJ qualifier |
FCSO may reject an interchange (transmission) that is not submitted with a valid intermediary code (NM1). FCSO intermediary code for Medicare Part A is 00090. |
|
All inpatient claims must contain the admission date, admitting diagnosis, admission type code, patient status code and admission source code or the claim will reject. This information was not previously required on 12X or 22X types of bills. |
2300 Claim info loop HI segment – BQ qualifier |
Any external cause of injury code (E-Code) sent in a claim must be valid E-code. |
2300 Claim info loop HI segment – BN qualifier |
Any country code used must be a valid two digit code from the ISO (International Organization for Standardization) 3166 country code list. All state abbreviations used must be a valid code from the US Postal Service list. State codes can be found at www.usps.com/ncsc/lookups/usps_abbreviations.html |
All N4 segments |
Any outpatient claims that contain an ICD-9 procedure code will be rejected before entering the processing system. |
2300 Claim info loop HI segment – various qualifiers |
All inbound claims containing codes from an external code source will be checked for validity before entering the processing system. This includes: • E-codes, • Value codes, • Diagnosis codes, • Occurrence codes, or • Occurrence span codes Invalid codes will cause the claim to be rejected before entering the processing system. |
|
Inbound Medicare Secondary Payer claims will be rejected before entering the processing system if the total of the paid amounts and adjusted amounts does not equal the billed amounts at the line level, the claim level and if the claim lacks standard claim adjustment reason codes to identify the adjustments performed. |
All test claims must pass 100% of the standard syntax edits and at least 95% of the IG or business edits, and the contractor must feel confident that the submitter will correct programming that resulted in the IG errors up to 5% prior to use of the format in production
If you have additional questions please contact Medicare Part A at (904) 791-8131 option 2. Office hours are 8:00am to 4:30pm Monday through Thursday and 12:30 to 4:30 on Friday.
