(Medicare Claims Processing Manual)

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.   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:    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?    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;   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   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)  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)