evekhm/cms_iom_500 huggingface dataset:
(Medicare Claims Processing Manual)
 ASC X12 277CA claim acknowledgment for ASC X12 837 professional  claim transactions    ASC X12 277 claim status response for ASC X12  transactions    NCPDP transmission response NCPDP transactions    DME MAC Front End Report with accepted claims received and CMN rejections based on ASC X12  claim submiss ions  Claims accepted by CEDI are assigned the Claim Control Number (CCN) to be used by the DME MACs in processing the claim.  CEDI translates the claims into the Medicare flat file format and delivers the claims to the appropriate DME MAC based on the beneficiary state code submitted on the claim.   CEDI receives inbound claim status requests (ASC X12 276 claim status request), performs all front end editing on the transactions, and returns the ASC X12 277 claim status response showing accepted and rejected  transactions.  ASC X12 276 claim status request transactions accepted by CEDI are translated to the Medicare flat file format and delivered to the DME MAC based on the contractor code submitted on the ASC X12 276 claim status request file.   CEDI receives the DME MAC front end report showing claims received by the DME MACs as well as any CMN rejections and returns this report to the Trading Partner's CEDI mailbox.   CEDI receives the ASC X12 835 remittance advice and ASC X12 277 claim acknowledgment flat fil e formatted transactions from the DME MACs, translates these to the ASC X12 format and delivers them to the Trading Partner's CEDI mailbox.   50.4.1 - CEDI Claim Numbering (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  CEDI wi ll assign the CCN to accepted ASC X12 and NCPDP claims utilizing the DME MACs defined range of CCNs.  The CCNs are reported back to the Trading Partner on the front end reports and response files.  On the 837 flat file, the CCN will be populated in the 2300 loop REF segment for that claim where REF01 = +CN.  For NCPDP, the CCN will be populated in the Transaction Header Segment in positions 117- 130.
(Medicare Claims Processing Manual)
If the number of accepted claims for a given DME MAC exceeds their defined threshold, CEDI will hold the claims in excess of the threshold to be delivered the next business day using the next business days range of CCNs.  Claims held will have the date of receipt when the CEDI received the claim.   50.4.2 - CEDI Receipt Control and Balancing (Rev. 2803, Issue d: 10 -28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  CEDI, upon receiving a submitted ASC X12 837 professional claim and/or NCPDP D.0 file from a Trading Partner, will run the file through their Commercial Off The Shelf (COTS) translator.  The COTS  translator creates an ASC X12 837 professional claim or NCPDP flat file, includes a CTRD record for each ISA/IEA and each Batch Header/Trailer present, forwards the flat file to the EDC, and stores the CTRD record to a database.   The EDC updates the Recei pt, Control and Balancing Detail Record (CTRD) creating a CTRD Response.  This file is sent back to CEDI who in turn triggers an alert when an out of balance condition has been reported, matches the response to the original CTRD record and stores the updat ed record to a database.  This process will check to be sure what was sent to the EDC is what the EDC received and to update the CTRD record.  If it balances, the file continues along through the DME MACs VMS cycle.  If it does not balance, the file will n ot continue.  The CTRD record contained in the database is updated with the counts (which identifies which pat of the file is out of balance).  CEDI will review the CTRD response file for the out of balance reason and resolve the issue. If necessary, a CTR R resubmission will be sent.   50.4.3 - CEDI Acknowledgments for ASC X12 Version 5010 and NCPDP D.0. Transactions (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)
(Medicare Claims Processing Manual)
Trading Partners transmit their ASC X12 5010 transactions and CED I performs the following functions.  1. CEDI front end performs Standard and Implementation Guide edits on the ASC X12 837 claims.  These edits include, but are not limited to, edits on the ASC X12 837 professional claim edit spreadsheet tagged for ASC X12 TA 1 interchange acknowledgment and  ASC X12 999R and 999E implementation acknowledgment responses.  Please refer to the CMS website for a copy of the ASC X12 837 professional claim edit spreadsheet.   2. CEDI uses the ASC X12 837 professional claim edit spreadshe et to determine whether an edit failure necessitates the rejection of the entire ASC X12 837 transaction set (ASC X12  999R implementation acknowledgment edit) or whether those files should be passed on for further business validation editing, resulting in  a claim level rejection via the ASC X12 277CA claim acknowledgment.  Errors that the translator identifies at the 999 level and passes on for further business validation and ASC X12 277CA claim acknowledgment issuance are referred to as ASC X12 999E imple mentation acknowledgment edits on the ASC X12 837 professional claim edit spreadsheet.  3. If the ASC X12 837 professional claim edit necessitates rejection of the entire ST -SE transaction set (ASC X12  999R implementation acknowledgment edit), CEDI returns t he ASC X12  999 implementation acknowledgment to the Trading Partner indicating the affected ST -SE was rejected. The transaction set is not passed for further processing.   4. If the ASC X12 837 professional claim edit sets an edit that does not necessitate rejection of the entire ST -SE transaction set (ASC X12 999E implementation acknowledgment edit), CEDI will:  a. Return the ASC X12 999 implementation acknowledgment to the Trading Partner indicating the affected ST -SE transaction was accepted with errors.   b. Continue with performing the ASC X12 837 professional claim edit at the Business Validation level.
(Medicare Claims Processing Manual)
b. Continue with performing the ASC X12 837 professional claim edit at the Business Validation level.  c. Read the beneficiary state code submitted on the accepted claims for use in performing appropriate Business Validation editing (ASC X12 277CA claim acknowle dgment) at the DME MAC level.   d. If an ASC X12 999E implementation acknowledgment error is listed with a coordinating ASC X12 277CA claim acknowledgment, any claims falling subordinate to the level at which the ASC X12 999E implementation acknowledgment erro r occurred will be rejected.   5. If CEDI does not set any  ASC X12 999E implementation acknowledgment edits, CEDI will:  a. Return ASC X12 999 implementation acknowledgment to the Trading Partner indicating the affected ST -SE transaction was accepted.   b. Continue performing the ASC X12 837 professional claim edit at the Business Validation level.   6. After all ASC X12 837 professional claim edits have been performed, and claims have successfully passed any  ASC X12 999R implementation acknowledgment, ASC X12 999E impl ementation acknowledgment, or ASC X12 277CA claim acknowledgment level editing, CEDI will:  a. Assign the CCN to the accepted ASC X12 837 claims.  b. Insert a receipt date segment (+RC DTP segment) into the ASC X12 837 flat file.  c. Create a control record (CTR segment) containing the appropriate counts.  The CTR is placed in front of each ISA segment on the ASC X12 837 flat file.  7. CEDI will create the ASC X12 277CA claim acknowledgment transactions to be returned to the Trading Partner, containing all ASC X12 277CA claim acknowledgment errors that may have occurred at the ASC X12 999E implementation acknowledgment  or Business Validation level.  8. CEDI will deliver the ASC X12 837 flat files to the EDC for the appropriate DME MAC.   Trading Partners transmit their NC PDP D.0 transactions to and CEDI performs the following functions.
(Medicare Claims Processing Manual)
8. CEDI will deliver the ASC X12 837 flat files to the EDC for the appropriate DME MAC.   Trading Partners transmit their NC PDP D.0 transactions to and CEDI performs the following functions.  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)
(Medicare Claims Processing Manual)
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)
(Medicare Claims Processing Manual)
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)
(Medicare Claims Processing Manual)
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
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
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);
(Medicare Claims Processing Manual)
 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.   50.10 - Additional Documentation Submitted Via Paperwork (PWK) Segment  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  50.10.1 - PWK Background  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)
(Medicare Claims Processing Manual)
50.10.1 - PWK Background  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  In the current CMS claims processing environment, providers have to wait to receive requests for additional information, c alled automated development request letters, in order to provide additional documentation necessary for the adjudication of their claims. This solicited method of requesting documentation adds unnecessary extra days to claims processing. Beginning with the 5010 version of the ASC X12 837 institutional and professional (electronic healthcare claim transaction), electronic billers can utilize a new methodology for providing CMS with their additional documentation which is required for claims adjudication. T his new methodology involves submission of the PWK segment (paperwork) in the ASC X12 837 claim to indicate unsolicited claim -related documentation is forthcoming.   50.10.2 - PWK Workflow  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation:  09-17-13)  The PWK segment is the electronic staple which connects paper documentation to an electronic claim. Claims are submitted electronically with the PWK segment populated. The additional documentation is then submitted to the A/B MACs, DME MACs or CEDI  at the same time or within close proximity of the electronic claim. If needed, the A/B MACs, DME MACs or CEDI  will use the additional documentation in their adjudication of the claim. If the claim does not require additional documentation, the clai m will be adjudicated without reviewing the additional documentation. If the additional documentation is not received or provides no value, the claim will be handled as it normally would have if the PWK data not been submitted.  50.10.2.1 - Provider Respon sibility (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)