(Medicare Claims Processing Manual)

 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)  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)  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.   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.  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.   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.   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.