evekhm/cms_iom_500 huggingface dataset:
(Medicare Claims Processing Manual)
A/B MACs, DME MACs, CEDI or other contractors if designated by CMS are responsible to support the exchange of CMS approved electronic transactions.  This support includes testing, certifying, and retention of an audit trail for the electronic data interchange platforms.  A/B MACs, DME MACs, CEDI or ot her contractors if designated by CMS must maintain environments according to CMS security policy and guidelines.  See Section 40.2.1 and 40.2.2 for specific references to this information.  A/B MACs, DME MACs, CEDI or other contractors if designated by CMS  will provide outreach and education to encourage the use of electronic transactions.  A/B MACs, CEDI or other contractors if designated by CMS are responsible for managing the EDI enrollment of entities who will be exchanging electronic transactions and p roviding support to these entities.  A/B MACs, DME MACs, or other contractors if designated by CMS are responsible to support contact with new providers, make available User Guidelines for EDI transactions and EDI provider training, to include information on EDI transactions in newsletters, bulletin boards, and Internet publications.  See Section 40.2.2 and 40.2.3 for specific references to this information.  A/B MACs, DME MACs, CEDI or other contractors if designated by CMS will provide limited support to providers in choosing a vendor, determining goals and requirements for the provider in selecting a vendor and assist in evaluating vendor proposals. See Section 40.2.4 for specific references to choosing a vendor.
(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/.
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
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)
(Medicare Claims Processing Manual)
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)
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
 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.
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
A clearinghouse transfers or moves EDI transactions for a provider or billing service, and generally translates the EDI transactions from or into a proprietary format.  (HIPAA defines a clearinghouse as a business associate of a provider or a health care plan that translates data from a non -standard format into a standard format or vice versa as preferred by their clie nts.)  A clearinghouse generally accepts multiple types of incoming transactions and sends them to various payers, including Medicare.  Clearinghouses often perform general and payer -specific edits on claims, and may handle multiple types of EDI transactio ns for a given provider.  Clearinghouses frequently reformat data for various payers, and manage acknowledgments, remittance advice transactions, and claim status and eligibility queries.   Some entities that refer to themselves as clearinghouses, however, do not edit or translate data, but simply serve as a telecommunication switch, moving transactions from point A to Point B or wherever directed under the terms of the agreement with a provider.  A clearinghouse may also be called a value added network (V AN).  A clearinghouse/VAN may not view privacy -protected Medicare data unless a signed authorization has been filed by the provider for whom the clearinghouse/VAN will submit or received Medicare EDI transactions.  For EDI, a transaction that contains indi vidually identifiable information about a Medicare beneficiary is considered to be privacy protected data.   That provider may not authorize submission or receipt of data by a third party for a Medicare beneficiary unless that beneficiary is a current patient of the provider, has scheduled an appointment, or has inquired about the receipt of supplies or services from the provider.  The provider authorization must be filed with the Medicare contractor to whom EDI transactions will be sent or from whom they wi ll be received.  In the case of a DME claim, this authorization need only be submitted to CEDI.  If multiple A/B MACs are involved, an authorization must be submitted to each.   Each clearinghouse/VAN that will submit or receive Medicare EDI transactions is  prohibited from using the EDI number or password issued to any of the providers they serve.  Each clearinghouse/VAN must obtain its own EDI number and password from each A/B MAC with which it will interact.  For, DME, each Clearinghouse/VAN must obtain it s own EDI number and password from CEDI.
(Medicare Claims Processing Manual)
Some health care providers use or may want to use more than one billing service or clearinghouse/VAN.  An A/B MAC and CEDI ability to handle more than one agent varies.  Some A/B MACs and CEDIs are able to accommod ate one or more clearinghouses/VAN for submission of a providers claims to Medicare, another agent to receive the providers remittance advice transactions, and a third clearinghouse/VAN to verify beneficiary Medicare eligibility for a provider.  Others m ay not be able to accommodate more than one agent for a provider.  A/B MACs and CEDIs are encouraged to support more than one agent for a provider, when permitted by their front end configuration.  A/B MACs and DME MACs, or other contractors if designated by CMS must notify each provider that applies for permission to obtain eligibility data electronically that:   They are permitted to view Medicare eligibility data only for patients currently being treated by or who have requested treatment or supplies from  that provider;    A provider cannot authorize a billing agent or clearinghouse to submit or obtain data from an A/B MACs and DME MACs that the provider is not entitled to personally submit or obtain;    A request for personally identifiable information for an y other Medicare beneficiaries would be a violation of Medicare and HIPAA privacy requirements, and subject to the applicable penalties for such violations.  A/B MACs, and DME MACs must notify each billing service and clearinghouse/VAN at the time of their  application for access to Medicare eligibility data and by also posting information on their web site that:   Their access is limited to submission of transactions and receipt of transactions for those providers that are their clients, but only if those providers authorized the billing agent and/or clearinghouse/VAN to submit or receive each transaction.   A billing agent or clearinghouse/VAN that has provider authorization to submit claim data for a provider cannot obtain eligibility data for that provide r unless that was specifically authorized by the provider.    Likewise, the billing agent or clearinghouse/VAN cannot be sent remittance advice transactions for a provider unless specifically authorized to do so by that provider.
(Medicare Claims Processing Manual)
 Likewise, the billing agent or clearinghouse/VAN cannot be sent remittance advice transactions for a provider unless specifically authorized to do so by that provider.   Providers must submit these  authorizations to their A/B MACs, DME MACs, CEDI or other contractors if designated by CMS in writing; an A/B MAC, DME MAC, CEDI or other contractor if designated by CMS is not permitted to accept a statement signed by a billing agent or clearinghouse/VAN  alleging that they have such provider authorization on file.  An original provider signature is required on these authorizations (but an A/B MAC, DME MAC, CEDI or other contractor if designated by CMS is allowed to accept an authorization signed by a provider by fax or mail).  The A/B MAC, DME MAC, CEDI, or other contractor if designated by CMS is responsible for maintenance of files to establish system access for individual providers, identify those billing agents and clearinghouses/VAN s authorized to access systems as the agent of a specific provider, and to record those transactions for which a billing agent or clearinghouse/VAN is authorized access as the representative of a specific provider.   With authorization, a clearinghouse/VAN may send inquiries for a provider, and receive responses, but it may not view personally identifiable beneficiary data contained in those queries or responses, store it for longer than necessary to assure delivery to the provider (no longer than 30 days maximum), or use pers onally identifiable data in any reports.  The EDI data sent or received belongs ultimately to the beneficiary, not to the clearinghouse/VAN that may translate and transport the data for a provider acting on the beneficiarys behalf.
(Medicare Claims Processing Manual)
Collection agents that contract with providers to collect bad debts and third party entities that may analyze data but do not have a specific initial claim submission role or are not responsible for posting of information in a remittance advice to patient accounts may not be sent beneficiary data by an A/B MAC, DME MAC, CEDI, or other contractor if designated by CMS.  If a collection agent or such a third party has provided adequate privacy and security assurances to protect beneficiary data, the provider may share Medicare payment information with a collection agent, data analysis firm, or similar third party, but the provider would need to furnish that data to that entity agent in this situation, however.  The Medicare program may not incur costs to furnish such data to collection agencies or to other entities that perform services that do not directly support Medicare  activities.  Delinquent collection, analysis of data related to a providers operations, and expenses related to other activities not directly related to Medicare claims or payments are considered provider business expenses.  Such activities do not direct ly benefit Medicare and Medicare may not incur costs to supply data intended only for such uses.  A provider must sign a valid EDI Enrollment Form (see Section 30.1 this chapter) prior to authorizing a billing agent or clearinghouse/VAN to submit/receive a ny EDI transactions on their behalf.  A separate password and User ID is to be used for system access by each authorized provider, billing agent or clearinghouse.  A vendor provides hardware, software and/or ongoing support for total office automation or submission of electronic EDI transactions directly to individual providers, billing agent or clearinghouses/VANs.  Vendors supply the means for Medicare system access but have no right to direct access to the system of an A/B MAC, DME MAC, CEDI, or other contractor if designated by CMS.