evekhm/cms_iom_500 huggingface dataset:
(Medicare Claims Processing Manual)
Providers that wish to utilize the PWK process to submit their additional documentation will be required to use a specially designed cover sheet which will be provided t o them by their servicing A/B MACs, or DME MACs . Contact your servicing A/B MACs or DME MACs  for details on how/where to obtain the cover sheet. These cover sheets will be required to be completely and accurately filled out or they will be manually returne d. It is important to note that the A/B MACs or DME MACs  is not required to return your additional documentation along with the cover sheet. In the instance where the coversheet is returned due to inaccurate or incomplete information, the claim will be adjudicated according to the normal CMS business policies and procedures without regard for the additional documentation received.   When submitting an electronic claim, the submitter must indicate in the body of the electronic claim their intention to submit additional documentation (at the claim level, line level, or both) along with their claim. This is done by indicating the following in the electronic claim: the PWK elements PWK01 (attachment type), PWK02 (transmission method), PWK05 (the value AC), and PW K06 (a 1- 50 byte attachment control number [ACN] of the provider/claim submitters choosing). PWK data submitted at the claim level will apply to the whole claim, unless overridden at the detail line level. Line level PWK data will only apply to that particular detail line of the claim. Electronic claims submitted with an improperly formatted PWK segment will be rejected back to the submitter via either an ASC X12 277CA claim acknowledgment or an ASC X12 999 implementation acknowledgment depending on the na ture and location of the error.  Although the ASC X12 837 claim transaction allows for up to 10 iterations of the PWK at both the claim and line level, only the first iteration of the PWK segment will be utilized for claim adjudication.  Additional iterations of the PWK segment beyond one will be stored by the claims processing contractor to which the claim was submitted.
(Medicare Claims Processing Manual)
Once the electronic claim has been submitted with the PWK, provider/claim submitters are expected to submit their additional documentati on as soon as possible. Providers will be required to either fax or mail their additional documentation to the A/B MACs or DME MACs . The only exception will be for those A/B MACs or DME MACs  which are part of an approved CMS electronic attachment pilot. In that case, your A/B MACs or DME MACs  will notify you of other acceptable methods for submitting your additional documentation. As a rule, the provider/claim submitter is required to provide the additional documentation within 7 calendar days, if utilizing  fax, or within 10 calendar days, if utilizing mail. After the 7/10 day waiting period expires, the claim will be adjudicated according to the normal CMS business procedures and policies in place at the time. Documentation submitted late will not be consid ered for adjudication but will be imaged and sent off for storage as per normal CMS correspondence retention requirements.   50.10.2.2 - Contractor Responsibility  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  A/B MACs and DME  MACs  will be required to establish dedicated fax lines and Post Office boxes for provider/claim submitters to utilize for providing the additional documentation. A/B MACs and DME MACs will provide the education and outreach support to provider/claim submi tters on how to utilize the PWK process.
(Medicare Claims Processing Manual)
The A/B MACs and DME MACs  shall provide the coversheet to the provider/claim submitter in whatever manner they feel provides the most effective and efficient method for providing the cover sheet. If the coversheet is not completely and accurately filled out, the A/B MACs and DME MACs  shall return the coversheet to its originator. A/B MACs and DME MACs shall indicate that the cover sheet is being returned for incomplete/inaccurate completion and the documentation is not being taken into consideration for the purpose of claims adjudication. The A/B MACs and DME MACs  are free to choose the method of returning the cover sheet which they feel best suits their business operation.  It is important to note that the A/B MACs and DME MACs  are not required to return the additional documentation along with the cover sheet. The A/B MACs and DME MACs are to follow their current correspondence retention requirements and processes regarding the controlling and storage of the additional documentation (whether the documentation is utilized for claims processing assessment or not).  If the provider/claim submitter cannot be identified by the A/B MACs and DME MACs  thus making it impossible to return the cover sheet, the documentation will  be imaged and sent off for storage as per normal CMS correspondence retention requirements. Documentation submitted late will not be considered for adjudication but will be imaged and sent off for storage as per normal CMS correspondence retention require ments.   Additional documentation received by A/B MACs and DME MACs  via the PWK process will be imaged and made available for view and/or retrieval by claims examiners/medical review staff. A/B MACs and DME MACs  staff adjudicating claims will only review PWK data when the claim encounters an edit/audit requiring additional documentation. The presence of the PWK indicator within the shared system will alert contractor staff that there is additional documentation which potentially may be used to adjudicate the  claim.  It is important to note that the simple presence of the PWK on a claim will not cause the claim to suspend.
(Medicare Claims Processing Manual)
When A/B MACs and DME MACs staff encounters an edit or an audit within the shared system that could be affected by additional documentation, they will first look to see if a PWK was submitted on the claim. If there is a PWK present, they will retrieve the appropriate additional documentation from their imaging system and review it. If the additional documentation contains the needed informat ion, the A/B MACs and DME MACs  will adjudicate the claim accordingly and flag the claim as dirty. If the additional documentation does not contain the needed information, the claim will then be handled according to the normal CMS business procedures and policies in place at the time. Regardless of whether or not the PWK additional documentation is utilized in adjudicating the claim, the waiting days will not count against the contractors claims processing timeliness (CPT).   60 - EDI Edit Requirements  (Rev.  2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  60.1 - A/B MACs, and CEDI Edit Requirements  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  A/B MACs and CEDI are required to edit submitted transactions at the front end to determine whether they are sufficiently complete to enable processing.  Transactions that are not legible, or do not include adequate data to be considered an acceptable EDI transaction, must be rejected or returned as unprocessable.  Rejected or returned transactions are not classified as received by Medicare.   A/B MACs and CEDI are not required to assign a control number or a receipt date to those transactions rejected  or returned as unprocessable.  Nor are they required to retain any record of those transactions pending correction and resubmission by the original sender.  See  50 and  70 of this chapter for further editing and testing requirements.  CEDI is required to assign a control number and a receipt date to those claims transactions accepted by CEDI.  They are required to retain any record of those originally submitted transaction pending correction and resubmission by the original sender.  See   50 and  70 of this chapter for further editing and testing requirements.
(Medicare Claims Processing Manual)
A. Translation and Date of Receipt Editing  If a shared system detects an improper flat file format/size (incorrect record length, record length exceeding 32,700 bytes, etc.), the flat file will be rejected back to the files submitter (A/B MACs and CEDI) by the shared system with an appropriate error message.   The date of receipt of a claim is the date a claim is received by the A/B MACs and CEDI and not a subsequent date on whic h the claim may have been received by the shared system.  The date of receipt must be an actual calendar date and may not be all zeroes or a future date.  See  80.2.1 of Chapter 1 of this manual for additional information on establishing the date of recei pt of a claim.   B. Implementation Guide (IG) Edits: ASC X12 Version 5010 and NCPDP Version D.0   In conjunction with front -end translation, A/B MACs (A)are to also conduct IG edits to identify submitted data elements that do not comply with data element re quirements added by the IG developers, using either software available from FISS or other software which is able to edit at this level.  A/B MAC (B) shared systems conduct IG edits for transactions sent to the A/B MACs (B).  CEDI conducts IG edits for transactions sent to the DME MACs.   In many cases, IG edits are more restrictive than those established by the ASC X12 standard that served as the platform for development of the TR3.  For instance, the ASC X12 standard might allow a maximum of 30- digits in a data element, but an IG note could limit the maximum size to 20 -digits.  Or the number of valid digits that may be entered in a data element as identified by the qualifiers that apply to the data element, might not permit reporting of more than 15- digits e ven though the standard permits up to 30-digits.
(Medicare Claims Processing Manual)
No national standards have been adopted under HIPAA for acknowledgment or error reporting for any of the HIPAA format transactions.  However, Medicare has adopted the ASC X12 999 implementation acknowledgme nt and ASC X12 277CA claim acknowledgment for this purpose effective with the implementation of version 5010.  For Version 5010 DME MACs will continue the use of proprietary error reporting for CMN rejection reports, which are returned to DME submitters th rough CEDI.  IG and Medicare program error reports related to electronic transactions must be sent to the submitters of those transactions electronically.  IG level edits typically affect a small number of the transactions in a batch.  Whenever not precluded by the standard, A/B MACs and CEDI are expected to reject individual transactions that are identified via IG edits and not reject the entire batch of transactions in which those transactions were submitted.   A/B MACs (A) share IG editing responsibilities with FISS (shared system documentation indicates which IG edits are conducted by the shared system).  A/B MACs (B) shared systems are responsible for IG editing of Part B professional transactions.  CEDI is responsible for IG editing of DME transactions . When editing for IG compliance, the responsible party must verify that:    Amounts, percentages, integers, and other fields designated in the IG as numeric are right -justified and zero- filled if the incoming data are smaller than the Medicare flat file field size;    Fields designated in the IG as alphanumeric are left justified and space filled if the incoming data are smaller than the Medicare flat file field size;    All non- Medicare data field lengths correspond to the maximum IG length.    Incoming alphanumeric non- Medicare data are left justified and space filled if the data are smaller than the Medicare flat file field size;    Incoming numeric non- Medicare data are right justified and zero -filled if the data contain fewer integers than the Medicare flat f ile field size; and    Non-Medicare data (and Medicare data elements where field sizes are in excess of the core system) are mapped to the Medicare flat file (and later written to the store -and-forward repository (SFR) by the shared system).
(Medicare Claims Processing Manual)
 Non-Medicare data (and Medicare data elements where field sizes are in excess of the core system) are mapped to the Medicare flat file (and later written to the store -and-forward repository (SFR) by the shared system).   60.2 - Key Shop  and Optical Character Recognition  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  60.2.1 - Claim Key Shop and Optical Character Recognition (OCR)/Image Character Recognition (ICR) Mapping to ASC X12 Based Flat File  (Rev. 2803, Issued: 10 -28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  A/B MAC  and DME MAC key shop operations, that do not output directly in the ASC X12 837 claim or ASC X12- based flat file as output, must convert the initial  output from paper claims to the ASC X12 -based flat file format or the ASC X12 837 claim prior to transmission to their data center. When the ASC X12- based flat file is the output the REF01 segment/element (found prior to the ST segment) shall contain a value of +PR and REF02 shall contain a value of K (key shop) or O (OCR/ICR).   A/B MACs (B)  and DME MACs who support telephone claim submission shall convert the output to the ASC X12- based flat file.  The value in REF02 shall contain a T (teleclaim).   The DME MAC shared system s hall apply implementation guide edits only to those requirements that are applicable to both the HIPAA and the corresponding fields on the paper claim.  Implementation guide edits that are inappropriate for paper claims shall be by-passed.   60.2.2 - Key Shop and Image Processing  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)
(Medicare Claims Processing Manual)
60.2.2 - Key Shop and Image Processing  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Key shop, imaging, and contractor in- house data entry operations that do not output directly in the ASC X12 837 claim or ASC X12- based flat file format, must convert their initial output format into the ASC X12 -based flat file or the ASC X12 837 claim format prior to transmission to their data center. When the ASC X12- based flat file is the output, the REF01 segment/element (found prior to the ST segment) s hall contain a value of +PR and REF02 shall contain a value of K (external key shop or in- house data entry) or O (OCR/ICR).   Shared systems shall apply IG edits only to those requirements that are applicable to both the HIPAA and the corresponding fi elds on the paper claim. Implementation guide edits that are inappropriate for paper claims shall be by -passed.   An outbound ASC X12 837 claim COB transaction built from a paper claim will be produced as a skinny COB.  Gap filling must occur as needed to enable the file sent to the trading partner to meet minimum data set requirements for a compliant ASC X12 837 claim COB transaction.  Skinny COBs shall contain all required ASC X12 837 claim segments and include post -adjudicated data.   60.3 - COB Tradin g Partner and Contractor Crossover Claim Requirements  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)
(Medicare Claims Processing Manual)
60.3 - COB Tradin g Partner and Contractor Crossover Claim Requirements  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Through the Coordination of Benefits Contractor (COBC), Medicare transmits outbound ASC X12 837 claim Coordination of Benefi t (COB) and Medigap claims to COB trading partners and Medigap plans, collectively termed trading partners, on a post -adjudicative basis.  This type of transaction, originating at individual Medicare contractors following their claims adjudication activities, includes incoming claim data, as modified during adjudication if applicable, as well as payment data.  All Medicare contractors are required to accept all ASC X12 837 claim segments and data elements permitted by the in - force applicable guides on an initial ASC X12 837 claim professional or institutional claim from a provider, but they are not required to use every segment or data element for Medicare adjudication.  Segments and data elements determined to be extraneous for Medicare claims adjudicati on shall, however, be retained by the Medicare contractor within its store -and-forward repository (SFR).  Incoming claims data shall be subjected to standard syntax and applicable TR3 edits prior to being deposited in the SFR to assure non- compliant data w ill not be forwarded on to another payer as part of the Medicare crossover process.  SFR data shall be re -associated with those data elements used in Medicare claim adjudication, as well as with payment data, to create an ASC X12 837 claim IG -compliant out bound COB/Medigap transaction.  The shared systems shall always retain the data in the SFR for a minimum of 6 months.  (See IOM Pub 100- 04, Chapter 28 Sections 70.6 and 70.6.5 for ASC X12 COB requirements and 70.6.6 for NCPDP D.0 COB requirements.)   60.4 - Remittance Advice and Standard Paper Remittances  (Rev. 10236, Issued: 07 -31-2020, Effective: 08- 31-2020, Implementation: 08- 31-2020)
(Medicare Claims Processing Manual)
60.4 - Remittance Advice and Standard Paper Remittances  (Rev. 10236, Issued: 07 -31-2020, Effective: 08- 31-2020, Implementation: 08- 31-2020)   Remittance advice records shall be provided to explain claim adjudication decisions, including for NCPDP format claims.   A/B MACs and CEDI  shall send the Electronic Remittance Advice (ERA) in the ASC X12 835 remittance advice format.  Or the A/B MACs and DME MACs shall send the remittance as a Standard Paper Remittance (SPR) Advice.  HIPAA version implementation guides are  available from the official Washington Publishing Company website.    See Chapter 22 of this manual for further remittance advice information.   60.5 - Payments (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  60.5.1 - Payment Floor Requirement  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  A/B MACs and DME MACs  must transmit the EFT authorization to the originating bank upon the expiration of the payment floor applicable to the claim.  They must designate a payment date (the date on which funds are deposited in the providers account) of two business days later than the date of transmission.  60.5.2 - Alternative to EFT  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  The only acceptable alternative to EFT is paper check mailed by first class mail.   60.5.3 - Electronic Funds Transfer (EFT)  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  EFT is the required method of Medicare payment for all providers entering the Medicare program for the first time and for existing providers that are submitting a change to their existing enrollment data but are not currently receiving payments via EFT.
(Medicare Claims Processing Manual)
Once a provider begins to receive Medicare payments via EFT, the A/B MAC or DME MAC  shall not issue any routine, ongoing payments to the provider via check. (For purposes of this instruction, the term routine, ongoing payments means those payments that are not considered to be special payments, as that latt er term is used in section 4 of the CMS -855 application.)  This means, therefore, that -  with the exception of special payments -  a provider that receives payments via EFT must continue to receive payments via EFT and cannot switch back to receiving paper checks, even in cases of a MAC transition or other CMS -initiated action. A/B MACs and DME MACs shall not approve any requests to change the providers payment method from EFT to check.   Note that the A/B MAC or DME MAC  shall abide by the instructions in Pu b. 100- 08, chapter 10, sections 4.4 and 8 on all provider enrollment issues relating to EFT.  This includes the requirement that A/B MACs and DME MACs  compare the information and signature on the providers Form -CMS -588 (Electronic Funds Transfer Authoriza tion Agreement), to that on the providers CMS -855 form on file.  For changes of information, DME MACs shall verify the authorized official on the CMS 855.  An A/B MAC or DME MAC  shall use a transmission format that is both economical and compatible with the servicing bank.  If the money is traveling separately from an ASC X12 835 remittance advice transaction, then A/B MACs and DME MACs  shall use National Automated Clearinghouse Association (NACHA) format CCP (Cash Concentration/Disbursement plus Addenda - CCD+) to make sure that the addenda record is sent with the EFT.  Providers need the addenda record to re -associate dollars with data. A/B MACs and DME MACs  shall transmit the EFT authorization to the originating bank upon the expiration of the payment floor applicable to the claim.  They shall designate a payment date (the date on which funds are deposited in the providers account) of two business days later  than the date of transmission.  For more information on EFT see IOM Pub 100- 08 Chapter 10.
(Medicare Claims Processing Manual)
For more information on EFT see IOM Pub 100- 08 Chapter 10.   60.5.4 - Tri-Partite Bank Agreement  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  A/B MACs and DME MACs  must ensure that Tri -partite bank agreements (three- party agreements between the contractor, the bank, and the provider) include wording that allows funding of the letter of credit to include EFT as well as paper checks.  The agreement must clearly state that all references to checks in the agreement include checks and/or electronic funds transfer.   For more information, refer to the Medicare Financial Management Manual, Pub. 100- 06, Chapter 5.   60.6 - Health Care Provider Taxonomy Code (HPTC) Requirements  (Rev. 10236, Issu ed: 07 -31-2020, Effective: 08- 31-2020, Implementation: 08- 31-2020)   Health Care Provider Taxonomy Codes (HPTC) are also called Specialty Codes. HPTCs are 9 -digit identifiers assigned by the National Uniform Claim Committee (NUCC) to be used in HIPAA transa ctions.  Contractors are required to validate the incoming HPTC against the most recent taxonomy code list. CMS will notify A/B MACs, their shared system maintainers, and CEDI (via Recurring Update Notification) to load the most recent HPTC code list into a contractor -controlled table.  HPTCs may not be hard coded by the shared system maintainers.  Contractor -controlled tables minimize the impact of future system updates.   HPTCs are updated twice a year (tentatively October and April) by the NUCC and the updates are available for download in a portable document format (PDF) from the official Washington Publishing Company (WPC) website for no charge or an electronic representation of the list, which could facilitate loading of the codes, may be purchased from  WPC on a subscription basis.  Contractors are to use the most cost effective means to obtain the list for validation programming and updating purposes.    70 - CMS Defined File Formats  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)