(Medicare Claims Processing Manual)

A/B MACs, DME MACs, CEDI or other contrac tors if designated by CMS will provide support to EDI trading partners through technical assistance and training.  A/B MACs, DME MACs, CEDI or other contractors if designated by CMS will make free claim submission software available to providers and suppor t the software.  A/B MACs, DME MACs, CEDI or other contractors if designated by CMS will also support the software to convert the ASC X12 835 remittance advice into a print document. See Section 40.2.5 and 40.2.6 for specific references to this information.  40.2.1 - Certification Test Program and Annual Recertification Activities  (Rev. 2771, Issued: 08- 16-13, Effective: 09-17-13, Implementation: 09-17-13)  CMS has initiated a Certification Test Program (CTP) comprised of the following : use cases, test cases, and associated test data files to verify that each A/B MACs, DME MACs, or other contractors if designated by CMS is ready to receive and process current transactions as well as other CMS required EDI enhancements.   A/B MACs, CEDI or other contractors if designated by CMS will perform certification testing using the CTP and produce reports based on the test results.  For each use/test case the actual result must be the same as the expected results and must match the associated transactions.  Certification  results, reports, and files will be retained by the A/B MACs, CEDI or other contractors if designated by CMS for audit ability in the future.  As changes are made in to the ASC X12 Version 5010 and D.0 transactions, the CTP will be updated and utilized during recertification.   The CMS will provide detailed instructions to the A/B MACs, CEDI or other contractors if designated by CMS to be used to perform the certification testing.  These instructions will be revised as needed and communicated to the A/B MAC s, CEDI, or other contractors if designated by CMS.  Further information on these instructions can be found at http://www.cms.gov/ElectronicBillingEDITrans/.  In developing the CTP the use case represents the type of response expected by each of the test cases within the use case.  Following the ASC X12 Version 5010 and D.0 Edit Spreadsheets as a guide, a use case for each loop transaction was developed.  There are multiple test cases for each us e case.   In most cases, each loop has at least one accept (in process/flat file mapping) use case and at least one reject use case.  The reject loop use case contains only one test case for the rejection or first negative test of the entire loop.  Depending on the edit type, additional use cases were necessary. For example, each loop will have one ASC X12 999 implementation acknowledgement use case with multiple test cases, one accepted (A) use case for good clean claims in process, flat file mapp ing, and may have one ASC X12 277CA claim acknowledgement use case with multiple test cases. It may be necessary to have more than one data file per use case if there are elements which will result in a structural error by the translator. In those cases, there are multiple data files per use case.   For NCPDP, each segment has one accept (in process/flat file mapping) use case, one reject use case, and one flat file mapping use case.   A test case describes each task that will insure ASC X12 data elements, qualifiers, and data values conform to the TR3 and the transactions edit spreadsheet.  Each valid value, invalid value, and edit as listed in the ASC X12edits spreadsheet has an associated test case.   Each test case includes the purpose of the test case, steps (and prerequisites) required to execute the test case, what the expected results are, and any necessary comments to clarify the test case.   The modifications and enhancements resulting from changes to the Edit Spreadsheets and deviations res ulting from the CTP will be used as part of the annual recertification. The contractors will utilize the Recertification Test Package (RTP) that is updated annually to perform self certification annually. The CMS will provide detailed instructions to the A /B MACs, CEDI or other contractors if designated by CMS to be used to perform the re -certification testing.  These instructions will be revised as needed and communicated to the A/B MACs, CEDI, or other contractors if designated by CMS. The CMS/MAC Re -Certification Instruction Guide will be used as guidance to set up the execution of the Front End system to certify compliance with the standards. As part of recertification, contractors will use template supplied by the STC for reporting of Re -Certification s tatus, re-certification Checklists Reports, and Deviation Reports. In addition, weekly meetings with the contractors will be established by CMS during the recertification process for gathering status and other reporting activities.   The CMS, utilizing exis ting processes and guidelines, will continue to provide ongoing administrative support for the ASC X12 5010 certification/recertification including building the master RTP, review of certification/recertification deviations to ensure the chosen recertification use cases and test cases are in sync with the current edit spreadsheets and complete the final sync (occurring immediately prior to the distribution of the Recertification test package) of the recertification Test Package with the most recent edit spr eadsheet.   40.2.2 - Security Requirements  (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  A/B MACs, DME MACs, CEDI, and other entities contracting directly with CMS are considered service providers to CMS.  As such, these enti ties are part of CMS system security boundary and must be in compliance with the Federal Information Security Management Act (FISMA) and are subject to CMS security policies.  Covered entities, trading partners and business associates not contracting as s ervice providers to CMS are outside of the CMS system security boundary and are not considered as  FISMA entities.  These entities must comply with the mandates of the HIPAA Privacy and Security Rules as well as the mandates defined in ARRA/ Health Informat ion Technology for Economic and Clinical Health (HITECH).   A trading partner submitting an EDI Enrollment Agreement attests that it has executed Business Associate Agreements (contracts), as mandated by HIPAA and ARRA/HITECH, with each of its business associates.  Moreover, the trading partner attests that it has full responsibility, as mandated by HIPAA and ARRA/HITECH, for notification of breaches of protected health information caused by the trading partner or its business associates.   40.2.2.1 - A/B MACs, DME MACs, and CEDI Data Security and Confidentiality Requirements  (Rev. 2803, Issued: 10- 28-13, Effective: 09-17-13, Implementation: 09-17-13)  All Medicare beneficiary -specific information is confidential and subject to the requirements of 1106(a) of the Act and implementing regulations at http://www.gpo.gov/fdsys/browse/collectionCfr.action?collectionCode=CFR .  Those regulations specify that, as a general rule, every proposed disclosure of Medicare information shall be subject to the Freedom of Information Act rules at 45 CFR Part 5.  Also all such information, to the extent that it is maintained in a system of records, is protected under the provisions of the Privacy Act of 1974 (5 USC. 552a) and implementing regulations at http://www.gpo.gov/fdsys/browse/collectionCfr.action?collectionCode=CFR .  Such information is included in claims, remittance advice, eligibility information, online claims corrections, and any other transactions where personal information applicable to a beneficiary is processed or transported.  Such information may not be disclosed to anyone other than the provider or supplier that submitted a claim or to the beneficiary for whom a claim was filed.  A/B, MACs, DME MACs and CEDI must ensure the security of all EDI transactions and data.  See the CMS Busi ness Partners System Security Manual and its Core Security Requirements attachment for more detailed information on system security requirements.   A/B, MACs, DME MACs and CEDI systems must include the following system security capabilities:   All data must be password protected and passwords modified at periodic but irregular intervals, as well as when an individual having knowledge of the password changes positions, and when a security breach is suspected or identified;   Provide mechanisms to detect unauthorized users and prohibit access to anyone who does not have an appropriate user ID and password;   Maintain a record of operator- attempted system access violations;   Maintain a multi- level system/user authorization to limit access to system functions, files, databases, tables, and parameters from external and internal sources;    Maintain updates of user controlled files, databases, tables, parameters, and retain a history of update activity; and   Protect data ownership and integrity from the detailed transact ion level to the summary file level.   40.2.2.2 - A/B MAC, DME MACs and CEDI Audit Trails (Rev. 2803, Issued: 10- 28-13, Effective: 09- 17-13, Implementation: 09- 17-13)  A/B MACs and DME MACs must maintain an automated transaction tracking and retrieval capab ility and retain an audit trail that notes each change made to each claim from date of receipt to date of payment or denial and any subsequent adjustments.  A/B MACs, and DME MACs must be able to retrieve or recreate:    The claim as received (pre- translatio n) from the provider, billing service, or clearinghouse (A/B MACs only);    The claim as received (post -translation) from CEDI (DME MACs only);    The claim as paid to the provider;    All adjustments made on the claim;   The check or the electronic funds transfer (EFT) record sent to the provider; and   The remittance advice as sent to the provider (A/B MACs only);    The remittance advice as sent to CEDI (DME MACs only).   A/B MACs and DME MACs must maintain the ability to cross -refer all associated transacti ons, e.g., EFT or check, claim adjustment, remittance advice, to each related claim being processed.  The records may be kept on electronic, computer -output -microfilm, optical disk media, or other reliable and industry accepted types of storage and retriev al media.  They may never allow anyone to overlay or erase a record.  Each record must be kept intact.  All records must be archived in accordance with the instructions in the Medicare General Information, Eligibility, and Entitlement Manual, Pub. 100- 01, Chapter 7.  It is important to have a well -defined system for maintaining audit trail data so that data integrity is maintained at all times.   CEDI must maintain an automated transaction tracking and retrieval capability and retain an audit trail that note s each change made to each claim from date of receipt to date of transfer to the appropriate DME MAC; and the receipt of remittance advice from the DME MAC and delivery to the provider.  CEDI must be able to retrieve or recreate:    The claim as received (pr e-translation) from the provider, billing service, or clearinghouse;    The remittance advice as sent to the provider.   The records may be kept on electronic, computer -output -microfilm, optical disk media, or other reliable and industry accepted types of storage and retrieval media.  They may never allow anyone to overlay or erase a record.  Each record must be kept intact.  All records must be archived in accordance with the instructions in the Medicare General Information, Eligibility, and Entitlement Manua l, Pub.100- 01, Chapter 7.  It is important to have a well -defined system for maintaining audit trail data so that data integrity is maintained at all times.   40.2.2.3 - Security -Related Requirements for A/B MACs, and CEDI Arrangements With  Clearinghouses and Billing Services  (Rev. 3346, Issued: 09- 04-15, Effective: 10- 06-15, Implementation: 10- 06-15)   A billing service is an entity that markets claim preparation services to providers and should also be able to perform related transactions for providers, such as eligibility and claim status inquiries.  The billing service collects a providers claim info rmation and then bills the appropriate insurance companies, including Medicare.  A billing service may submit claims only, or provide full financial accounting and/or other services.  Billing services are considered to be provider business associates.  As such, HIPAA requires that they comply with each of the privacy and security requirements that apply directly to providers.  They are also required to ensure that they require that any clearinghouses, subcontractors or other business associates of their own that may be involved with handling of Medicare beneficiary data also meet those same security and privacy requirements.  A billing service may view beneficiary or provider data to carry out their billing obligations for a provider, when a provider authori zes them to have that access.  To qualify as a billing service, an entity must at a minimum submit initial claims on the providers behalf.