(Medicare Claims Processing Manual)

1. CEDI front end performs Standard and Implementation Guide edits on the NCPDP claims.  These edits include, but are not limited to, edits on the NCPDP edit spreadsheet tagged for NCPDP t ransmission response.   2. CEDI uses the NCPDP edit spreadsheet to determine whether an edit failure necessitates the rejection of the entire NCPDP batch or an individual claim.   3. CEDI will read the beneficiary state code submitted on the accepted claims for use in performing appropriate Business Validation editing at the DME MAC level.   4. After all NCPDP edits have been performed, CEDI will assign the CCN to the accepted NCPDP claims.   5. CEDI will return the NCPDP transmission response showing accepted and rejected batches and individual claims as well as the CCN for all accepted claims.   6. Create the NCPDP flat file for each DME MAC with claims for their Jurisdiction.   7. CEDI will deliver the NCPDP flat files to the EDC for the appropriate DME MAC.   50.5 - EDI Testing Accuracy  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  All claim submitters must produce accurate electronic test claims before allowed to submit HIPAA format claim transactions in production.  All submitters must send the A/B MAC or CEDI  a test file containing at least 25 claims, which are representative of their practice or services.  A/B MACs and CEDI may, based on individual consideration, increase or decrease the number of claims required to adequately test any given submitter.  A/B MACs and CEDI will subject test claims to standard syntax and IG semantic data edits and will provide documentation when edits detect errors.   Standard syntax testing validates the programming of the incoming file and includes file layout, record sequencing, balancing, alpha -numeric/numeric/date file conventions, field values, a nd relational edits.  Test files must pass 100 percent of the standard syntax edits before production is approved. An ASC X12 999 implementation acknowledgment will be used to validate compliance with syntax data.    IG Semantic Data testing validates data r equired for claims processing, e.g., procedure/diagnosis codes, modifiers.  A submitter must demonstrate, at a minimum, a 95 percent accuracy rate in data testing before production is approved where, in the judgment of the A/B MAC or CEDI, the vendor/submi tter will make the necessary correction(s) prior to submitting a production file. An ASC X12 277CA claim acknowledgment will be used to validate compliance with semantic data.   50.5.1 - Limitation on Testing of Multiple Providers that Use the Same Clearinghouse, Billing Service, or Vendor Software  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Many claim submitters use the same vendors software product, or the same clearinghouse to submit their electronic claims to Medicare.  In those cases, A/B MACs and CEDI are not required to test each submitter that uses the same software, or each provider or billing agent that uses the same clearinghouse.  A/B MACs a nd CEDI may require potential third party submitters to have an approved Medicare provider as a client prior to testing with such third parties.  It is sufficient to test with a small number of users of the same software to establish that the software is c ompliant, or to simply test with a single provider using a clearinghouse to establish the compliancy of the clearinghouses software and connectivity for transmission of claims data.  Likewise, once A/B MACs and CEDI have tested the validity of the free/at  cost billing software they distribute on request, the A/B MACs and CEDI are not expected to test providers that have elected to use that billing software.   Providers who submit transactions directly to more than one A/B MAC and/or CEDI, and billing servic es and clearinghouses that submit transactions to more than one A/B MAC and/or CEDI, must contact each A/B MAC and/or CEDI with whom they exchange EDI transactions to inquire about the need for supplemental testing whenever they plan to begin to use an additional EDI transaction, different or significantly modified software for submission of a previously used EDI transaction, or before a billing agent or clearinghouse begins to submit transactions on behalf of an additional provider.  A/B MAC and/or CEDI ma y need to retest at that time to re -establish compatibility and accuracy, particularly if there will also be a change in the telecommunication connection to be used.   Billing services and clearinghouses are not permitted to begin to submit or receive EDI transactions on behalf of a provider prior to submission of written authorization by the provider that the billing agent or clearinghouse has been authorized to handle those transactions on the providers behalf.  See Section 30 of this Chapter for further information on EDI Enrollment.  50.5.2 - EDI Receiver Testing by A/B MACs, and CEDI  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  A/B MACs and CEDI are not required to test individuals who request use of outbound electronic remittance advice (ERA) or claim status transactions unless parties that request receipt of those transactions request pre -testing prior to production use of one or more of those outbound transactions.  A/B MACs and CEDI may, at their discretion, require pre -production testing of outbound transactions if there is concern that specific receivers could otherwise experience significant problems.   Even if testing is not normally required, parties that want to begin receipt of an outgoing transaction supported b y Medicare must notify their A/B MACs DME MACs or CEDI when to begin transmission of the HIPAA version of a specific outgoing transaction.   50.6 - Changes in Providers System or Vendors Software and Use of Additional EDI Formats (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Providers who receive or send transactions directly from/to more than one A/B MAC and/or CEDI, and billing services and clearinghouses that receive or send transactions from/to more than one A/B MAC and/ or CEDI, must contact each A/B MAC and/or CEDI with which they receive/send EDI transactions to inquire about the need for supplemental testing whenever they plan to begin to use an additional type of EDI transaction.  A provider must also notify their A/B  MAC and/or CEDI in writing (see EDI enrollment in Section 30 of this chapter) if they will begin to use a billing agent or clearinghouse for the first time, change a billing agent or clearinghouse, discontinue use of any billing agent or clearinghouse, or  authorize a billing agent or clearinghouse currently used for some transactions to begin receiving additional transactions.  A billing agent or clearinghouse representative is prohibited from signing an authorization on behalf of a provider to allow them to act as the sender or receiver of specific EDI transactions on behalf of a provider, even if a provider has signed a contract with the billing agent or clearinghouse for such services.   50.7 - Delimiters  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09 -17-13)  Delimiters - Inbound Transactions   As detailed in the HIPAA adopted ASC X12 implementation guides, delimiters are determined by the characters sent in specified, set positions of the ISA header.  For transmissions to Medicare (inbound transmissions), these charters are determined by the submitter and can be any characters which are not contained within any data elements within the ISA/IEA Interchange Envelope.  Please note, that the delimiters for NCPDP files are dictated by th e transaction standard.   Delimiters - Outbound Transactions   Medicare will use the following delimiters in all outbound ASC X12 transactions.  Note that these characters will not be used in data elements within an ISA/IEA Interchange Envelope.    Delimiter  Character Used  Dec Value  Hex Value  Data Element Separator  * 62 3E Repetition Separator  ^ 94 5E Component Element Separator  : 43 2B Segment Terminator  ~ 126 7E  50.8 - Nulls (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  The null scrubbing of outbound data exiting the Enterprise Data Center (EDC), prior to its delivery to the Local Data Center (LDC) was initiated with Transmittal 702 Change Request 6946, Common Edits and Enhancements Module (CEM) October Release Update for  Test/Production Indicator Activity and Outbound Data Scrubbing . The scrubbing process will apply to ASC X12 outbound file structures to the EDC (e.g., ASC X12 835 and 277 flat files). It will not apply to outbound ASC X12 837 COBC files.   The Shared System maintainer shall implement a scrubbing process that occurs after the creating of the outbound file structures at the EDC (e.g., ASC X12 835 and 277 flat files). Once the flat files have been processed through the EDCs receipt, control and balancing jobs they are viewed as ready for transmission to the LDC. At this point in the process null values are to be replaced with spaces.   50.9 - Direct Data Entry (DDE) Screens  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  HIPAA does  not require, but does permit payers to maintain DDE screens for claim submission, correction, claim status determination, and eligibility verification.  A/B MACs (A) are required to maintain claim submission, claim correction and claim status screens, but  not A/B MACs (B) or DME MACs. This section is applicable to claim entry and claims correction (see chapter 31 for DDE requirements for formats other than claims).   Medicare considers transactions conducted via DDE screens to meet HIPAA -compliancy requirem ents.  DDE claims are considered HIPAA -compliant EDI transactions for application of the 14- day payment floor.    Data entered via DDE screens are not subject to the syntax (format) requirements of the standards, but must meet applicable data content req uirements for comparable HIPAA transactions.  A/B MACs (A) may continue to use existing DDE screens for claim corrections since this function is not subject to HIPAA.  DDE systems are proprietary by definition.  They are a direct link between a particular health plan (Medicare) and its providers, and the software (and sometimes hardware) is unique to and maintained by the plan.  The widespread use of the standard HIPAA transactions should make it economically feasible for more providers to procure or develop their own EDI products that can be used with all plans.  The use of DDE should decrease over time as a result.  The requirement for applicable data content is meant to facilitate that eventual conversion.  Adopting the data content requirements of HIPA A in DDE screens will facilitate eventual migration of providers from DDE to use of EDI transaction software (or to use of a clearinghouse).  This will also permit maintenance of DDE -generated data and HIPAA standard transaction- generated data in the same databases.   In this context, applicable data content means shared system -maintained DDE screens must:    Collect all data elements that are required in the IG as well as those situational elements that are needed for Medicare processing (unless the data i s already available to the payers system);    Use only the internal and external code sets designated in the HIPAA standard TR3 with no additions or substitutions;    Provide for at least the field size minimums noted in the IG, but no more than the maximum s izes (Do not expand the size of a shared systems internal claim records);    Permit at least the minimum number of field repeats noted in the IG, but no more than the maximum number;   Allow for only  one investigational device exemption number (IDE) per claim (at the claim level);    Remove employment status code, employer name, and employer address information;    Allow Other Subscriber Demographic Information (date of birth and gender) if the other subscriber is a person;    Allow for discharge hour and minute information in the numeric form of HHMM; and   Allow for correct processing of the unique physicians identifier number in the 2310A (Attending Physician) loop.  Data elements not used by -Medicare are not currently collected in Medicare DDE screens.  Claims correction via DDE should be limited to Medicare data (non -Medicare data in error should be purged with an appropriate error message to the DDE user).  With Medicare data plus some information fr om shared system files, an IG compliant COB transaction can be written.  NOTE:  See section 60.2.3 for additional DDE edit requirements.