evekhm/cms_iom_500 huggingface dataset:
(Medicare Claims Processing Manual)
40.2.4.3 - Training Content and Frequency  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09 -17-13)  See the CMS Provider Education and Training (PET) manual for the definitive provider outreach and training requirements.  Provider training is included in the CMS contractor PET budget and although EDI information must be included in those training efforts as appropriate, the PET requirements contain specific activities that must be completed by A/B MACs, DME MACs and CEDI.  When possible, EDI training should be conducted in conjunction with non- EDI training to share training room and trainers expenses.  This EDI-related training information is included in Chapter 24 for reference purposes only.  When appropriate, A/B MACs, DME MACs and CEDI may develop user groups for general EDI users and free software users. A/B MACs, DME MACs  and CEDI  are not required to support or train providers on the use of software provided by commercial vendors/trading partners, on ASC X12 format structure or coding, the use of PCs, or other subjects non- specific to Medicare EDI.  On an ongoing basis, A/ B MACs, DME MACs and CEDI should assess the need for additional training based on:    Periodic identification and evaluation of common electronic billing errors;  New software release; or   The introduction of new EDI functions or changes to existing functions.   40.2.4.4 - Prohibition Against Requiring Use of Proprietary Software or DDE  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  A/B MACs, DME MACs and CEDI will accept and process HIPAA EDI transactions created from any software as long as the transactions comply with the TR3 requirements standards adopted under HIPAA and CMS business requirements.  A/B MACs, DME MACs and CEDI are prohibited from requiring that submitters of HIPAA EDI transactions use proprietary billing software  or specific hardware.  A/B MACs, DME MACs and CEDI may not charge providers that use their own software, hardware, modems, and telecommunication lines to submit and/or receive EDI electronic transactions in a HIPAA -compliant format.
(Medicare Claims Processing Manual)
DDE screens generally  involve the use of dumb terminals programmed for specific uses, or of PCs that use software issued by a payer to emulate a dumb terminal to permit providers to individually enter claim data and correct claims errors (applies to Medicare institutional claims only), verify beneficiary eligibility (A/B MACs (A) and some A/B MACs (B)), obtain claims status (A/B MACs (A)  and some A/B MACs (B)), or possibly perform another function.  A/B MACs and DME MACs incur additional costs to maintain DDE functionality and support, they are allowed to recoup those costs from users and are permitted to charge a reasonable amount for its use A/B MACs, and DME MACs may not require use of DDE, or refuse to accept or discourage submissions of HIPAA EDI transactions.   40.2.4.5 - Free Claim Submission Software  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  A/B MACs, and CEDI will provide free/at cost software for their providers to use on a Windows -based PC for electronic submission of HIPAA -compliant  claims to Medicare.  At a minimum, this basic software must contain the following:    Edits to prevent incomplete and inaccurate claims from entering the system;  User friendly qualities including:   o A low initial investment, as well as low -cost upgrades, on the part of the submitter;  o Minimal effort for both the software installation and training for the submitter; and  o Clear and understandable software documentation, including information about where to receive additional help.  This software must also be able to identify when Medicare is a secondary payer and to collect data elements concerning a primary payers payment, standard claim adjustment reason codes and adjustment amounts made by a primary payer prior to submission of a claim to Medicare for seco ndary payment.   A/B MACs and CEDI are not funded to issue free/at cost software for other than submissions of ASC X12 837 claim inbound transaction.  NCPDP has indicated software for billing NCPDP formatted claims was already in widespread use by retail ph armacies and there was not a need for Medicare to fund development of free billing software for retail pharmacies.
(Medicare Claims Processing Manual)
The software is free/at cost but A/B MACs and CEDI may charge a fee up to $25.00 per request to recoup their postage, reproduction, and handling expenses when a provider requests the software be sent via diskette, CD, or other medium, rather than downloade d by a provider from the Medicare contractors web page (if not precluded by a software copyright or licensing agreement).  A/B MACs and CEDI are to complete upgrades to their free/at cost billing software to correspond to the requirements of the current X 12 version of the transactions.  Prior to distributing the initial or updated versions, A/B MACs and CEDI will scan the free/at cost billing software with a current anti- virus program.  Whenever A/B MACs and CEDI issue a new version of their free/at cost billing software, they shall notify providers to terminate use of the earlier version of the Medicare free/at cost billing software within 90 -days of release of the updated software.   NOTE:  The free -billing software distributed by A/B MACs (A) is maintained  by the shared system maintainer.  A/B MACs (A) are responsible for testing and distribution of that software only.  There is not a similar common source of free billing software or maintenance for the A/B MACs (A) or A/B MACs (B) . A/B MACS or A/B MACs (B)   are encouraged to obtain and license for distribution Medicare Part B billing software.  This software is available to A/B MACS and A/B MACs (B)  for purchase and licensing from software companies.   40.2.4.6 - Newsletters/Bulletin Board/Internet Publicat ion of EDI Information  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  To educate providers and encourage the use of EDI A/B MACs, DME MACs, and CEDI must periodically include information about use of EDI in their newsletters and on their Web site.  Their newsletter and Web site shall:   1. Announce upcoming EDI changes;  2. Point out common EDI billing errors and provide guidelines to eliminate errors; and 3. Promote use of each of the Medicare -supported HIPAA EDI transactions.
(Medicare Claims Processing Manual)
1. Announce upcoming EDI changes;  2. Point out common EDI billing errors and provide guidelines to eliminate errors; and 3. Promote use of each of the Medicare -supported HIPAA EDI transactions.   A/B MACs, DME MACs, and CEDI will provide access to newsletters via bulletin boards and/or the Internet.  A/B MACs, DME MACs, and CEDI Web pages must include a link to the CMS Web site, which provides record formats and transactions information.  If the i nformation is available on the CMS Home page, A/B MACs, DME MACs, and CEDI should link to it rather than duplicating development and maintenance.  40.2.4.7 - Provider Guidelines for Choosing a Vendor  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Imple mentation: 09 -17-13)  Providers may request assistance in choosing a vendor.  A/B MACs, and CEDI must maintain a list of software vendors and clearinghouses that are currently successfully submitting transactions in HIPAA -compliant formats on their Web page, and are encouraged to also provide factual information such as claims volumes, types of providers serviced by those vendors and clearinghouses, and whether the software may permit automatic posting or printing of ASC X12 835 remittance advice data. Howe ver, A/B MACs, and CEDI must take care to avoid making a specific recommendation and to avoid showing favoritism.  Providers may select any vendor that provides the necessary services.   40.2.4.7.1 - Determining Goals/Requirements  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Before selecting a vendor, the provider must examine its business needs to identify the EDI, practice management, or other services that the provider is interested in obtaining from a vendor. The provider  should consider what services could be easily performed by their in -house staff and which might be more cost effective to obtain through a vendor.  The provider should create a written description of the components of its practice that need vendor support  and a description of support needed so prospective vendors can design their proposals to best meet the providers needs.  Requirements to consider include the following:
(Medicare Claims Processing Manual)
 Future Growth of the Practice;   Workload;   Payer Analysis;   Referral Tracking;   Fee Schedules;   Appointment Scheduling;   Medical Records;   Interconnections with Physicians/Hospitals and other Networks;   Word Processing Needs;   Electronic Billing (formats and versions supported);   Multiple Practices/Locations;   High Volume/Low Volume Billing;   Specific Bill Types;   Management Reporting;   Hardware/Software Requirements/compatibility with existing equipment; and   Data Storage needs.   40.2.4.7.2 - Vendor Selection  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Once a pro vider has determined its own goals and requirements, it must begin the vendor selection process.  Selecting a vendor must be as objective and quantitative as possible.  Areas to be evaluated should include technical functionality, flexibility, and customer  service. The following steps may be used as guidelines for providers to start the vendor selection process:   1. Develop a list of potential vendors:    Ask the Medicare  A/B MACs and CEDI for a list of approved vendors;    Ask other providers of comparable size/specialties what vendors they use for what services and how satisfied they are;    Ask a consultant;    Attend standards conferences, follow trade magazines and investigate Web pages.   2. Call or write the vendors selected/recommended to discuss the organizations needs and request a proposal.   3. Tell the vendors how the proposals should be structured so that the various proposals can be more easily compared.   4. Attend demonstrations of at least two to three vendors and pay close attention to:    How individual requirements will be met;   Ease of understanding;    Ease of features -  data entry, search features, editing/compliance checking features, help features, error correction features;    Security - disaster recovery plans, controls, and audits;    Daily Procedures;    Reporting/Tracking features.   5. Check vendor references and ask specific questions such as:    How long has the business been in operation?    How long has the system been in place?    What is the quality of the training and ongoing support?    Is there a  users group in place?    What formats are supported?   6. Check with providers served by the vendor and ask specific questions such as:    Have you experienced any problems with the system?    Have you experienced any problems with the vendor?
(Medicare Claims Processing Manual)
 What formats are supported?   6. Check with providers served by the vendor and ask specific questions such as:    Have you experienced any problems with the system?    Have you experienced any problems with the vendor?    How long did it take to get up and running?    Are you happy with the system/vendor and would you recommend it/them today?    Is there anything else I should know or ask before making my decision?   Make site visits to the vendor as well as other clients of similar size and bill mix that have been running the system for some time.  40.2.4.7.3 - Evaluating Proposals  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Vendor proposals should be evaluated on several levels including company reputation/history, system functionality, flexibility, overall costs, and support provided.  Providers should create a checklist that compares the vendor proposals against their original requirements by assigning a relative weight to each requirement and t hen rating the vendors ability to meet each requirement based on their written proposals.  Although some aspects of each checklist will be highly individual, the following are some of the elements that should be considered:   1. Overall costs:    Software co sts;  Hardware costs (types as well as quality);   Licensing fees;   Training costs;   Installation costs;   Cabling;   Phone lines (leased line/toll charges);   Remodeling/Furniture;   Forms;   Conversion costs;   Electricity costs;  Supply costs   Annual hardware maintenance;   Annual software maintenance;   Cost of custom program changes; and   Cost of continuous software support.   2. Evaluate hardware differences;   3. Evaluate quality of training and support;   4. Evaluate system documentation;
(Medicare Claims Processing Manual)
2. Evaluate hardware differences;   3. Evaluate quality of training and support;   4. Evaluate system documentation;   5. Consider the staff si ze of the vendor;   6. Determine how well each vendor responded to requirements and questions in the proposals;  7. Determine flexibility (whether the package is proprietary, whether the software can be easily modified, whether the vendor can accommodate ch anging payer requirements, and if so, at what cost);  8. Determine overall system convenience including hours of customer service, technical support, and connection times;  9. Assess future risks and the vendor mitigation of such risks through system trial periods and source codes placed in escrow.  40.2.4.7.4 - Negotiating With Vendors (Rev. 2803, Issued: 10- 28-13, Effective: 09-17-13, Implementation: 09-17-13)  Once a vendor has been selected, the provider must negotiate the final costs, services, and implementation dates to be provided by the vendor.  All agreements reached between the two parties should be obtained in writing.  Providers should add a clause to their agreements that will permit them to obtain a refund in the event the vendors software does not begin to operate successfully by a specific target date following installation.  Providers should also add a clause to their agreements allowing them to delay final payment pending successful operation of the new software for a specified period a fter successful installation.   40.2.5 - Provision of EDI User Guidelines  (Rev. 2803, Issued: 10- 28-13, Effective: 09-17-13, Implementation: 09-17-13)  A/B MACs, HIPAA Eligibility Transaction System (HETS) ASC X12  270/271 eligibility and CEDI must make EDI  information available to new users that describe the various steps in the testing process (see 30 and 60) and discloses: (This refers to HETS as well.)    The Help Desk contact information, including telephone number, email address , and website to help with:  o Getting started with EDI;   o Needing on -going support for electronic transactions; and  o Needing support for general transaction issues;    Testing requirements and the submitters and A/B MACs, HETS 270/271 and CEDI  level of responsibility throughout each step of the testing phase;   The availability of the appropriate specifications for this provider:  o ASC X12 transactions adopted under HIPAA; and
(Medicare Claims Processing Manual)
 The availability of the appropriate specifications for this provider:  o ASC X12 transactions adopted under HIPAA; and   o NCPDP adopted under HIPAA.   Instructions for accessing and downloading CMS EDI instructions via the CMS Internet EDI Home Page http://www.cms.hhs.gov/ElectronicBillingEDITrans/01_Overview.asp   Login requirements;    Telecommunications options and requirements; and frequently asked questions and answers about EDI.  40.2.6 - Provision and Maintenance of a Directory of Billing Software Vendors and Clearinghouses  (Rev. 2803, Issued: 10- 28-13, Effective: 09-17-13, Implementation: 09-17-13)  A/B MACs and CEDI must maintain a directory of electronic billing software vendors and clearinghouses that have successfully completed software and/or submission testing for the current ASC X12 837 claim, NCPDP claim (applies to CEDI only)  Telecommunication standard and Batch standard claim transactions adopted as national claim standards for HIPAA.  A/B MACs and CEDI must make this directory available to their providers via a Web page or electronic bulletin board.  A/B MACs and CEDI must update the directory whenever product offerings from additional software vendors and/or additional clearinghouses are made available for providers to utilize when submitting transactions for production.  At a minimum, the directory must include the vendor/clearinghouse name, phone number, email address and product offerings.  A/B MACs and CEDI should also note any additional transactions for which the tested software can be used for submission or receipt of HIPAA standard transactions other than the claim.   40.2.7 - Operating Rules for Electronic Transactions  (Rev. 2803, Issued: 10- 28-13, Effective: 09-17-13, Implementation: 09-17-13)
(Medicare Claims Processing Manual)
40.2.7 - Operating Rules for Electronic Transactions  (Rev. 2803, Issued: 10- 28-13, Effective: 09-17-13, Implementation: 09-17-13)  The Secretary of Health and Human Services (HHS) adopted HIPAA transaction Operating Rules under section 1104(b) (2) of the Administrative Simplification provision of the ACA, requiring covered entities to comply with new administrative transaction standards.  The purpose of the Administrative Simplification provision is to establish national standards for the electronic transfer of healthcare information.  The Operating Rules are targeted at simplifying administrative processes, and reducing administrative burden and costs for both providers and payers.  The Operating Rules were designed to be added to exist ing electronic transmission standards for the processing of health information and administrative transactions.  The Council for Affordable Quality Healthcares (CAQH) Committee on Operating Rules for Information Exchange (CORE) was chosen as the operating  rules authoring entity for eligibility and healthcare claim status standard transactions.  CORE released three phases of operating rules.  A/B MACs, DME MACs, CEDI or other contractors if designated by CMS are responsible for supporting the implementation and adherence to the CAQH CORE Operating Rules for electronic transactions, including but not limited to all future operating rules.  This support includes implementing necessary changes via Technical Direction Letters as well as Change requests (CRs) and  participating in development meetings with CMS to ensure compliance for the Operating Rules.   40.3 - Trading Partners  (Rev. 2803, Issued: 10- 28-13, Effective: 09-17-13, Implementation: 09-17-13)
(Medicare Claims Processing Manual)
40.3 - Trading Partners  (Rev. 2803, Issued: 10- 28-13, Effective: 09-17-13, Implementation: 09-17-13)  Trading Partners must have signed Trading Partner Agreement s in place with their Medicare FFS Contractor prior to engaging in EDI.  50 - Technical Requirements  (Rev. 11427; Issued: 05-20- 22; Effective: 01 -01-23; Implementation: 01-03-23) NOTE:  CMS seeks to reduce burden and modernize processes to ensure a reduction in improper payments and an increase in customer satisfaction. The Certificate of Medical Necessity (CMN) form and DME Information Form (DIF) were originally required to help document the medical necessity and other coverage criteria for selected  Durable Medical Equipment, Prosthetics, Orthotics, and Supplies (DMEPOS) items. In the past, a supplier received a signed CMN from the treating physician or created and signed a DIF to submit with the claim. Due to improvements in claims processing and medical records management, the information found on CMNs or DIFs is available either on the claim or in the medical record and is redundant. Therefore, to reduce burden and increase customer satisfaction, providers and suppliers no longer need to submit the se forms for services rendered after January 1, 2023.  For claims with dates of service on or after January 1, 2023  providers and suppliers no longer need to submit CMNs or DIFs with claims. Due to electronic filing requirements, claims received with thes e forms attached will be rejected and returned to the provider or supplier.  F or claims with dates of service prior to January 1, 2023  processes will not change and if the CMN or DIF is required, it will still need to be submitted with the claim, or be on file with a previous claim.  This statement applies throughout the Program Integrity Manual wherever CMNs and DIFs are mentioned.     50.1 - Telecommunications, Internet and Dial-up  (Rev. 3346, Issued: 09- 04-15, Effective: 10- 06-15, Implementation: 10- 06-15)
(Medicare Claims Processing Manual)
50.1 - Telecommunications, Internet and Dial-up  (Rev. 3346, Issued: 09- 04-15, Effective: 10- 06-15, Implementation: 10- 06-15)  A/B MACs, DME MACs and CEDI will support connectivity for EDI functions.  These functions include the exchange of EDI transactions at t he A/B MACs and CEDI Front End.  Online systems include the Medicare Part A Direct Data Entry (DDE) used for claim entry, claim correction, claim status checks, and beneficiary eligibility.  Medicare Part B offers the Provider Professional Telecommunications Network (PPTN) and DME MAC offers Claim Status Inquiry to check the status of claims.   50.1.1 - System Avai lability  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  Access to A/B MACs, DME MACs and CEDI to exchange electronic transactions and/or lookup files (e.g., HCPCS codes, fee schedules) may be dependent upon hours the core processing system is available.  Where EDI functions are dependent upon the operation of the host processing system, the host systems hours of operation determine system availability.  A/B MACs, DME MACs and CEDI  shall inform users of system availability schedules including any planned downtime for system maintenance.     50.1.2 - Media (Rev. 10319, Issued: 08- 28-2020, Effective: 09- 29-2020 Implementation: 09- 29-2020)   An EDI transaction is defined by its initial manner of receipt.  Depending upon the capability of the A/B MAC, DME MAC and CEDI and the details negotiated with electronic claim submitters, an electronic claim could be submitted via central processing unit (CPU) to CPU transmission, dial up frame relay, direct wire (T -1 line or similar), o r personal computer modem upload or download (also see Section 50.1.3).