evekhm/cms_iom_500 huggingface dataset:
(Medicare Claims Processing Manual)
When counting electronic claims for workload reporting, the A/B MAC, DME MAC and CEDI  include data on all bills received for initial processing from providers directly or indirectly through another A/B MAC (A), etc.  They also include data on demand bills and no- pay bills submitted by providers with no charges and/or covered days/visits.  See  90 of this chapter for information about application of the claims payment floor when a claim is submitted electronically in a non -HIPAA -compliant format.   A/B MACs and DME MACs are not permitted to classify the following as electronic claims for Electronic Data Interchange (EDI) reporting, for payment floor or Administrative Simplification Compliance Act (ASCA, see section 90) mandatory electronic claim submission purposes:    Bills received from providers if they are incomplete, incorrect, or inconsistent, and consequently returned for clarification. Individual controls are not required for these bills;   Adjustment bills (A/B MAC (A) only);    Home Health Agency (HHA) bills where no utilization is chargeable and no payment has been made, but which have been requested only to facilitate record keeping processes (There is no CMS requirement for HHAs to submit no payment non-utilization chargeable bills.);   Bills paid by an HMO and processed by the contractor; and   A/B MACs, DME MACs and CEDI are not permitted to accept claims via fax -imaging, tape/diskette or similar storage media.  A/B MACs, DME MACs and CEDI are to assist billers using such media to transition to more efficient electronic media.   50.1.3 - Telecommunications and Transmission Protocols  (Rev. 3346, Issued: 09- 04-15, Effective: 10- 06-15, Implementation: 10- 06-15)  Providers must access A/ B MACs and DME MACs online applications, Medicare Part A Direct Data Entry (DDE), Medicare Part B Professional Provider Telecommunications Network (PPTN) and DME MAC Claim Status Inquiry (CSI) as directed  by the A/B MAC or DME MAC.  A/B MACs and DME MACs a re to permit access to DDE, PPTN and DMCS by using the most cost -effective transmission solution, among the CMS -sanctioned options, that meets the needs of their trading partners.
(Medicare Claims Processing Manual)
A/B MACs and CEDI may, but are not required to, support electronic transfer s for Medicare using 56 K connections for their asynchronous communications lines.  For asynchronous communications, A/B MACs and CEDI may, but are not required to, support provider access through Transmission Control Protocol/Internet Protocol (TCP/IP).  If A/B MACs and CEDI do support TCP/IP, it must be compliant with Internet Request for Comment (RFC) number 1122 and 1123, using Serial Line Internet Protocol (SLIP) or Point -to-Point Protocol (PPP). For any EDI transfers over TCP/IP connections, A/B MACs and CEDI must support using File Transfer Protocol (FTP) in a secure manner which is supported within the FTP protocol in a consistent manner and which takes advantage of existing security infrastructure and technology, compliant with RFC 2228.  FTP server s provide for user authentication through user ID/password mechanisms.  A/B MACs and CEDI must submit any other security mechanism in addition to this to CMS for approval prior to implementation.  A/B MACs and CEDI may but are not required to support file compression for ASC X12 or NCPDP (CEDI only) transactions.  Compression is permitted between the contractor and its data center.
(Medicare Claims Processing Manual)
A/B MACs and CEDI may not limit the number of ASC X12 837 claim transactions or the number of providers with transactions incl uded in a single transmission, but they may limit a single transmission to 5,000 claims if that is necessary for efficient operations.  For NCPDP, CEDI may not limit the number of transactions per batch except as noted within the batch standard.  However, they may limit a single physical file to having only one batch. Server capacity must be adequate to support simultaneous sustained file transfers from all configured communications lines.  A/B MACs and CEDI must accept and send all ASC X12 837 claim transa ctions as a continuous byte stream or as a variable length record.  A/B MACs and CEDI are not permitted to require that provider EDI transaction data be broken down into 80 byte segments and may not require any other deviation from the variable length form at or the continuous byte stream format.  For example, submitters may not be forced to create each segment as its own record by inserting carriage returns or line feeds.  Only standard ASC X12 envelopes may be used with ASC X12 transactions.  Only standard NCPDP envelopes may be used with NCPDP transactions (applies to CEDI only).   The ASC X12 and NCPDP transactions are variable -length records designed for wire transmission.  Medicare contractors must be able to accept them over a wire connection.  Each sen der and receiver must agree on the blocking factor and/or other pertinent telecommunication protocols.   Unless otherwise approved, A/B MACs, DME MACs and CEDI are only permitted to accept EDI transactions via the Internet when explicitly directed by CMS. T his ability includes compliance with the operating rules for Section 1104 of the Affordable Care Act.  50.1.4 - Toll-Free Service  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Toll free lines are not available for submission  or receipt of EDI transactions.  Providers and their agents are responsible for all costs they incur for communication and connectivity as described in Section 50.1.  50.2 - Translators (Rev. 10236, Issued: 07 -31-2020, Effective: 08- 31-2020, Implementation: 08 -31-2020)
(Medicare Claims Processing Manual)
A/B MACs and CEDI  must accept HIPAA compliant transactions into their front -end system and translate that data into the appropriate flat file format for the transaction type to enable processing by their shared system.  HIPAA c ompliant transactions may include Medicare data (data sent to the core shared system) and non -Medicare data (data not sent to the core shared system).  Translators are required to validate the syntax compliance of each inbound transaction against the trans action standards adopted under HIPAA and upon which the implementation guides (also adopted under HIPAA) are based.  Syntax edits must be limited to those syntax requirements specified in those implementation guides (IGs) adopted under HIPAA.
(Medicare Claims Processing Manual)
A/B MACs and  CEDI  must use the ASC X12  999 implementation acknowledgment to report  transaction level errors detected by translators and to acknowledge receipt of claims that did not contain syntax errors, unless the submitter has indicated a preference not to receiv e acknowledgments for claims without errors.  A/B MACs or CEDI  may purge ASC X12 999 implementation acknowledgment transactions from submitter mailboxes after five (5) business days in the event not downloaded by the submitting entity, but are encouraged to retain these as long as 30 days if system capacity permits.  Once purged, an A/B MACs or CEDI  is not required to be able to recreate that ASC X12 999 implementation acknowledgment transactions. A provider or clearinghouse that failed to download the ASC X 12 999 implementation acknowledgment in a timely manner may submit a claim status query to obtain comparable information for accepted claims.  If that response indicates no record of the claim(s), suggesting front end rejection due to a syntax error, the provider/clearinghouse can resubmit the claim and have a new ASC X12 999 implementation acknowledgment issued.  The ASC X12 999 implementation acknowledgment TR3 can be downloaded from the official Washington Publishing Company website. A/B MACs and CEDI ar e required to meet the ASC X12 999 implementation acknowledgment TR3 requirements when issuing the 999.   When receiving claims in the HIPAA adopted NCPDP formats, CEDI must produce a response file in the NCPDP format containing one Transaction Header and one Transaction Trailer with the appropriate syntax error noted in the message field.   A/B MACs and CEDI  must accept the entire extended character set.  Refer to the ASC X12 TR3 for specifics on the character set.  If A/B MACs and CEDI  cannot accept more than 9,999 loops or segments per loop in an ASC X12 transaction due to the limitations of their translator, they may reject the transaction at the translator level and use the ASC X12 999 implementation acknowledgment with the IK304 with a value of 4.  Translators are to edit the envelope segments (ISA, GS, ST, SE, GE, and IEA) that surround individual transactions so the
(Medicare Claims Processing Manual)
999 implementation acknowledgment with the IK304 with a value of 4.  Translators are to edit the envelope segments (ISA, GS, ST, SE, GE, and IEA) that surround individual transactions so the translation process can immediately reject an interchange, functional group, or transaction set not having met the requirements contain ed in the specific structure, which could cause software failure when mapping to the flat file.  A/B MACs and CEDI  are not required to accept multiple functional groups (GS/GE) with multiple transaction types within one transmission for ASC X12 transaction s.
(Medicare Claims Processing Manual)
For ASC X12 transactions A/B MACs and CEDI  translators must also:   Convert lower case to upper case;    Pass all spaces to the flat file for fields that are not present in an inbound transaction but which are included in the flat file;    Map Not Used data elements for A/B MACs and CEDI based upon that segments definition only, i.e., if a data element is never used, do not map it.  However, if a data element is required or situational in some segments but not used in others, then it must be mapped;   Not Used data elements are not to be mapped to the flat file; and    Accept multiple interchange envelopes within a single transmission. This is only applicable to ASC X12 transactions as NCPDP only processes a single batch per transmission.    Translate data for outgoing transactions supplied by the shared system in the flat file format into the appropriate, compliant IG standard as adopted under HIPAA. Translation of outgoing transactions is to follow the same character set and case requirement s noted for incoming translation. A/B MACs and CEDI  are not required to accept or process ASC X12 999 implementation acknowledgment transactions from trading partners for any outgoing ASC X12 transactions.  See Section 60 for additional A/B MACs and CEDI  translator edit requirements that may be specific to individual standards.   50.3 - Common Edits and Enhancements Module (CEM) - General Description Across All Versions  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)
(Medicare Claims Processing Manual)
The CEM e stablishes consistent editing, acknowledgments, and error handling of the electronic data interchange (EDI) transactions across Medicare Administrative Contractor (MAC) jurisdictions.  The CEM is implemented by each A/B MAC in their local data center (LDC) . The Part A and Part B CEMs were developed by their corresponding Medicare Shared System Maintainers (SSMs).  The Durable Medical Equipment (DME) MACs editing, acknowledgment, and error handling of EDI transactions is processed by the Common Electronic Da ta Interchange (CEDI) contractor.  Each A/B MAC has integrated the CEM into its Front- End Systems for both inbound and outbound EDI transaction processing.  The CEM, in conjunction with the A/B MAC Commercial Off -the-Shelf (COTS) translator and any additional Front End Solution, is responsible for editing current ASC X12 standard transactions established under HIPAA via Technical Report Type 3 (TR3s).   The CEM provides submitters with quicker acknowledgments for the claim transaction(s) ASC X12 version(s) 005010 and beyond inclusive of any adopted errata under HIPAA.  This allows submitters to correct any errors and resubmit their transactions without having to wait for a batch cycle.   The CEM includes the following capabilities:   Code set editing   Medicare- specific editing    Duplicate submission checking   Claim Control Number assignment of Internal Control Number (ICN) or Document Control Number (DCN)    Creation of the ASC X12 277CA claim acknowledgment (flat file)    Creation of a CEM -edited transaction flat file    Receipt/Control/Balancing between the local data centers (LDCs) and EDCs for claims, claim status request and responses, and remittance advice    Reporting Capabilities based on the Control Record database   50.3.1 - Claim Numbering (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)
(Medicare Claims Processing Manual)
 Reporting Capabilities based on the Control Record database   50.3.1 - Claim Numbering (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  The CEM will assign a claim control number to each accepted claim.  An accepted claim is a unit of work, 2300 loop followed by a 2400 loop, as described in the ASC X12 837 claim TR3 that has passed all translator syntax/semantic and CEM Medicare business edits and has been assigned a claim control number.  The assigned claim control number will be reported back to the submitter via the ASC X12 277CA claim acknowledgment.  This will provide the submit ter with the claim control number earlier in the adjudication process, thus enabling the submitter to perform more specific claim status inquiries on individual claims instead of entire submissions via standard HIPAA adopted transactions or via traditional  IVR/ARU (Interactive Voice Response/Automated Response Unit methods.  50.3.2 - Receipt Control and Balancing  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Upon receiving an ASC X12 276 claim status request or ASC X12 837 cl aim (institutional or professional)current standard transaction adopted under HIPAA, the A/B MAC will process the file through their Front End EDI solution, composed of at minimum a COTS translator.  The COTS translator creates the appropriate CMS defined flat file, based on transaction type.  The CMS defined flat file will include a skeleton Control Record, either a Detail Record (CTRD) or a Resubmission Record (CTRR), for each Interchange Control Header/Interchange Control Trailer (ISA/IEA) present, and t he A/B MAC then loads/places this file into the designated folder for the CEM to pick up and process.
(Medicare Claims Processing Manual)
The CTRD/CTRR record is placed in the designated transaction outbound folder for the A/B MAC LDC to move via Network Data Mover (NDM) to the EDC.  The ED C will run a receipt/control/balancing process upon receipt of a file to ensure that what was sent by the LDC is what the EDC received.  Once the EDCs have checked the files, the Received portion of the Control Records will be populated, and a copy of the Control Record shall be sent back to the LDC and logged in the Control Record database.  If the file balances, the Control Records will be stripped off and the file will be queued up to be pulled in to the next processing cycle.  If file does not balance , Received portion of the Control Records will be populated, and a copy of the Control Record shall be sent back to the LDC and logged in the Control Record database.  An alert will be sent to the LDC to indicate there is a problem with a file, and the b ad ISA/IEA will be stripped out of the file.  Once the LDC has identified and fixed the issues, they resubmit the bad ISA/IEA.   The Receipt/Control/Balancing process will also be in place for the outbound ASC X12 835 remittance advice and the ASC X12 277 c laim status response.  The shared system maintainers (SSMs) will create the appropriate CMS defined flat file, based on transaction type.  The CMS defined flat file will include the Control Records.  The transactions will be sent to the MAC/CEDI local data  center, where they will be passed through the receipt/control/balancing process to ensure if the CMS defined flat file is balanced.  During the outbound translation process the A/B MACs shall remove the control records prior to translating the CMS defined flat files to ASC X12 EDI format.   50.3.3 - Acknowledgements  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)
(Medicare Claims Processing Manual)
50.3.3 - Acknowledgements  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  The A/B MACs front end process uses the transaction appropriate CMS edits spreadsheet to determine whether an edit failure necessitates the rejection of the entire transaction set via the ASC X12 TA1 interchange acknowledgment or ASC X12 999 implementation acknowledgment edit, back to the submitter or whether those errors are accepted and passed onto the CEM for claim level rejection via the ASC X12 277CA claim acknowledgment.  Errors that the translator passes to the CEM are referred to as ASC X12 999 implementation acknowledgment Accepted, but Errors Noted (ASC X12 999E implementation acknowledgment) edits.   The CEM  will receive CMS defined 837 and 276 flat files from the A/B MACs translator.  The CEM will flag any 837 flat file data in error and will report that data back to the submitter via the ASC X12 277CA claim acknowledgment. Any 276 flat file data in error w ill be reported back to the submitter via an ASC X12 277 claim status request response transaction.  All accepted data will be sent to the SSM for processing.   1. If the translator sets an  edit that does not necessitate rejection of the entire ST -SE transacti on set (ASC X12 999E implementation acknowledgment edit), the contractor front end:   a. Creates an STC segment to document the error and inserts it into the ASC X12 837 claim CMS defined flat file following the segment containing the error.   b. Returns the ASC  X12 999 implementation acknowledgment to the submitter indicating the affected ST -SE transaction was accepted with errors noted.   c. Inserts a receipt date segment (+RC DTP segment) into the ASC X12 837 claim CMS defined flat file.   d. Creates a skeleton (350 c haracter space filled) Control Record (CTR segment) and, if desired, populates CTR17.  The CTR is placed in front of each ISA segment.
(Medicare Claims Processing Manual)
d. Creates a skeleton (350 c haracter space filled) Control Record (CTR segment) and, if desired, populates CTR17.  The CTR is placed in front of each ISA segment.   e. Submits the ASC X12 837 claim CMS defined flat file containing STC error segments to the CEM.   2. If the translator does not set any edits, the contractor front end:   a. Returns the ASC X12 999 implementation acknowledgment to the submitter indicating the affected ST -SE transaction was accepted.   b. Inserts a receipt date segment (+RC DTP segment) into the ASC X12 837 claim CMS defined flat file.   c. Creates a skeleton CTR segment and if desired, populates CTR17.  The CTR is placed in front of each ISA segment.  d. Submits the ASC X12 837 claim CMS defined flat file to the CEM.   50.3.3.1 - Outbound File Compliance Check  (Rev. 2803, Issued: 10 -28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  The ASC X12 999 implementation acknowledgment, the ASC X12 835 remittance advice, ASC X12 276/277 claim status response and the ASC X12 277CA claim acknowledgment outbound files shall be com pliance checked for the following:    Basic syntactical integrity and specific syntax requirements on all outbound files;   Balanced field totals, financial balancing of claims or remittance advices, and balancing of summary fields, if appropriate for all out bound file;    Specific inter -segment situations described in the HIPAA Implementation Guides for all outbound files; and   Valid TR3 specific code set values and other code sets adopted as HIPAA standards for all outbound files.  50.3.4 - Common Edits and Enhancement Module (CEM) Code Sets Requirements  (Rev.: 4388; Issued: 09- 06-19; Effective: 10- 07-19; Implementation: 10 -07-19)
(Medicare Claims Processing Manual)
The functionality of the CEM is dependent on the standard system maintainers (SSM) providing current code sets for inbound claims and claim status inquiries to be edited against.  This requires the CEM maintainer to update the following code sets on a quarterly release basis in order to align with industry:    Country Codes (ISO 3166- 1)  Country Subdivision Codes  (ISO 3166- 2)  State Codes (United States, Canada, Mexico)   Not Otherwise Classified (NOC) Procedure Codes (as defined by CMS)   National Uniform Billing Committee (NUBC) Condition Codes (that are valid for use on the 837 Professional claim per the National Uniform Claim Committee (NUCC))   Ambulance Modifiers   Health Insurance Prospective Payment System (HIPPS) (as updated and maintained by CMS)   A/B MACs are required to validate the incoming codes listed above against the most recent codes sets provided by the S SM. CMS will notify the shared system maintainers (via Recurring Update Notification) to load the most recent code sets into the CEM environment for download to the A/B MAC local data center (LDC) in conjunction with the quarterly release.   The CEM maintainer also updates the following code sets on a frequency basis other than quarterly in order to align with industry:    ZIP codes   Claim Adjustment Reason Codes (CARC)   Anesthesia Modifiers   Diagnosis Related Groups (DRG) codes   Healthcare Common Procedure  Coding System (HCPCS) codes   Health Insurance Premium Payment System (HIPPS) codes   International Classification of Diseases, (ICD) codes   National Drug Codes (NDC) (as published by the Federal Drug Administration(FDA))   National Provider Identifier (NPI)   Remittance Advice Remark Codes (RARC)   Taxonomy Codes   Procedure Code Modifier Codes   Admission Source Codes   Admission Type Codes   Patient Status Codes   Condition Codes   Occurrence Codes   Occurrence Span Codes   Value Codes   Revenue Codes   Uniform Bill Type codes   Provi der Control File (PCF) -  Part B only   A/B MACs are required to validate the incoming codes listed above against the most recent codes sets provided by the SSM. When the above listed reference code sets are updated, they are sent to the A/B MAC (LDC) as part of nightly code updates.
(Medicare Claims Processing Manual)
50.3.5 - Handling of Poorly Formed/Invalid Flat Files for a 277CA  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  When a poorly formed/corrupted invalid flat file for an ASC X12 277CA claim ackno wledgment outbound transaction is received, the contractor may manually correct the flat file acknowledgment data necessary to produce a valid ASC X12 277CA claim acknowledgment. The manually corrected information is then to be submitted to the translator.  This process shall be executed on an exception basis to ensure that an ASC X12 277CA claim acknowledgment can be produced for an accepted transaction.  50.4 - CEDI - Unique Specifications for DME  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implemen tation: 09 -17-13)  The Common Electronic Data Interchange (CEDI) contractor is the single front end solution for Durable Medical Equipment (DME) electronic transactions including ASC X12 837 claims, NCPDP claims, ASC X12 835 remittance advice (ERA), ASC X12 276 claims status requests, ASC X12 277 claim status responses, and electronic front end reports.   CEDI receives inbound claims (ASC X12 837 professional claim  and NCPDP claim), performs all front end editing on the claims, and returns the reports showi ng accepted and rejected claims to the Trading Partner's CEDI mailbox.   The following front end reports will be returned by CEDI:    ASC X12 837 professional claim and 276 claim status request transactions; NCPDP transactions    ASC X12 999 implementation acknowledgment for ASC X12 837 claim and ASC X12 276 claim status request transactions    ASC X12 TA1 interchange acknowledgment for ASC X12 837 claim and ASC X12 276 claim status request transactions (when requested)    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