J.9 Section C SOW 7-29.docx

ATTACHMENT J.9

ATTACHMENT J.9 SECTION C— DESCRIPTION/SPECIFICATIONS/WORK STATEMENT

C.1 Background and Scope

Section 1860D-2(b)(4)(D) of the Social Security Act (the Act) authorizes the Secretary to establish procedures for determining whether costs for Part D eligible individuals are being reimbursed through insurance or otherwise, a group health plan, or other third party arrangement and for alerting the Part D plans in which such individual are enrolled about the other prescription drug coverage. Section 1860D-23 of the Act requires Part D plan sponsors to coordinate benefits with State Pharmaceutical Assistance Programs (SPAPs) and other providers of prescription drug coverage. When a Medicare Part D beneficiary has other prescription drug coverage, coordination of benefits (COB) permits the plans that provide coverage for the same beneficiary to determine each of their payment responsibilities. This process is necessary in order to avoid duplication of payment and prevent Medicare from paying primary when it is the secondary payer.

Section 1860D-2 of the Act provides beneficiaries with protection against high out-of-pocket expenditures by requiring Part D sponsors to track beneficiary “true out-of-pocket” (TrOOP) expenditures. Costs for covered Part D drugs are treated as “incurred” only if they were paid by the individual (or by another person, such as a family member, on behalf of the individual), paid on behalf of a low-income subsidy-eligible individual under the Section 1860D–14 provisions, or paid under an SPAP. Costs do not count as “incurred” when no benefits are provided because of the application of either formulary or Medicare Secondary Payer (MSP) rules, or when costs are reimbursed by a third party. Therefore, only certain costs not paid for by the Part D Plan count toward TrOOP. In Part D, COB also serves the function of providing a mechanism supporting the tracking and calculating to beneficiaries’ TrOOP.

To calculate TrOOP, Part D sponsors must determine what other entities made payments on covered drugs. Using the authority provided under Section 1860D-2(b)(4)(D) of the Act, CMS established a “TrOOP facilitation process” that captures TrOOP-relevant data from SPAPs and other providers of prescription drug coverage either online or in a batch process and sends it to the relevant Part D sponsor for TrOOP calculation. This Statement of Work describes the TrOOP facilitation process and the supports it provides for Part D COB and the tracking and calculating of beneficiaries’ TrOOP expenditures.

Part D rules require sponsors to track the beneficiary’s TrOOP costs and gross covered drug spending and correctly apply these costs to the TrOOP and benefit limits in order to correctly administer the benefit and provide the catastrophic level of coverage at the appropriate time. The TrOOP threshold and gross covered drug spending are calculated on an annual basis and must be transferred between Part D plans if a beneficiary changes plan enrollment during the coverage year. An automated process to manage the plan-to-plan transfer of these data is a component of the TrOOP facilitation process.

C.2 Technical Constraints

It is important that the contractor and CMS have a common understanding regarding the conditions on which we shall build our relationship. The following identifies the basic technical constraints concerning this effort:

The contractor shall provide software and/or licenses for software required by CMS.

The contractor shall comply with OIS dataset naming conventions, JCL conventions, security protocols and all associated documentation. Refer to Sections 6, 7, and 9 of the CMS Data Center Users' Guide for specific standards.

The contractor shall provide contractor staff training on software and tools that are not unique to CMS and are required for this contract. (For example: Dynamic Object Oriented Requirements System (DOORS), WebSphere, Endevor, Oracle, DataBase2 (DB2), JAVA).

The contractor shall provide training to CMS staff on contractor unique software and tools that are required for this contract, upon CMS request, and at no additional charge to the contract.

CMS shall provide training to contractor staff on CMS unique software and tools that are required for this contract, upon contractor request. (For example: e-CHIMP).

The contractor shall use All-Fusion ERwin Data Modeler which is the standard data-modeling tool used at CMS.

The contractor shall be responsible for providing all hardware and software not identified as government furnished property/equipment in order to perform the SOW in its entirety.

The contractor shall establish connectivity as needed to the CMS Baltimore Data Center in order to perform required tasks.

All mid-tier (3-zone) architecture development shall be performed at the contractor’s facilities. The contractor shall be responsible for the management of all mid-tier code development. The contractor shall use the current CMS standard desktop suite for all deliverables.

The contractor shall update and maintain all system and user documentation.

The contractor shall attempt to use test data, instead of production data, for the purposes of testing whenever possible. Production data shall only be used for testing if it is approved by CMS. The data shall be kept secure by the contractor. The data shall be used for no other purposes other than for the test being conducted at the time, and when there is no other alternative available to meet the deadline for a release.

C.3 CMS/HHS Standards, Polices and Procedures

A. Architecture Architecture applies to the Contractor’s business processes and rule, systems structure, technical framework and technologies for service delivery. Properly managed, architecture can clarify and help optimize the interdependencies and interrelationships among an organization's business operations and the underlying IT infrastructure and applications that support these operations.

· CMS Enterprise Architecture http://www.cms.hhs.gov/EnterpriseArchitecture/01_Overview.asp

· Federal Technical Reference Model http://www.cms.hhs.gov/EnterpriseArchitecture/04_FederalRefModel.asp B. Information Security

The following section applies to all organizations which possess or use Federal information, or which operate, use or have access to Federal information systems (whether automated or manual), on behalf of CMS. The Contractor shall arrange, finance and/or perform all activities as required under FISMA and described in this section, and throughout the SOW.

The central tenet of the CMS Information Security (IS) Program is that all CMS information and information systems shall be protected from unauthorized access, disclosure, duplication, modification, diversion, destruction, loss, misuse, or theft—whether accidental or intentional. The security safeguards to provide this protection shall be risk-based and business-driven with implementation achieved through a multi-layered security structure. All information access shall be limited based on a least-privilege approach and a need-to-know basis, i.e., authorized user access is only to information necessary in the performance of required tasks. Most of CMS' information relates to the health care provided to the nation’s Medicare and Medicaid beneficiaries, and as such, has access restrictions as required under legislative and regulatory mandates.

The CMS IS Program has a two-fold purpose:

(1) To enable CMS’ business processes to function in an environment with commensurate security protections, and

(2) To meet the security requirements of federal laws, regulations, and directives.

The principal legislation for the CMS IS Program is Public Law (P.L.) 107-347, Title III, Federal Information Security Management Act of 2002 (FISMA), http://csrc.nist.gov/drivers/documents/FISMA-final.pdf. FISMA places responsibility and accountability for IS at all levels within federal agencies as well as those entities acting on their behalf. FISMA directs Office of Management and Budget (OMB) through the Department of Commerce, National Institute of Standards and Technology (NIST), to establish the standards and guidelines for federal agencies in implementing FISMA and managing cost-effective programs to protect their information and information systems. As a CMS contractor the Contractor shall:

1. Establish senior management level responsibility for IS,

1. Define key IS roles and responsibilities within their organization,

1. Comply with a minimum set of controls established for protecting all Federal information, Act in accordance with CMS reporting rules and procedures for IS.

The Contractor shall arrange, finance and/or perform all activities as required under FISMA as described in this statement of work.

C. CMS Information Security Deliverables Quick Reference Chart

The CMS Information Security Virtual Handbook at this link, http://cms.hhs.gov/informationsecurity, contains all the information required by the contractor to implement CMS Security protocols.

The templates for the following documents/methods are available via the Information Security Library link listed in the left-hand side menu at the CMS website shown above:

· System Security Plan

· Risk Assessment

· Contingency Plan

· Contingency Plan Testing

· Privacy Impact Assessment

· Security Test & Evaluation

· Security Controls Testing

· Plan of Actions & Milestones

· Corrective Action Plans

· Security Costs Budgeting

If the contractor believes that an updated IS-related requirement posted to the CMS website may result in a significant cost impact, the contractor may submit a request for equitable cost adjustment before implementing the change.

The Contractor shall comply with the CMS IS Program requirements by performing, but not limited to, the following:

· Implementing their own IS program that adheres to CMS IS policies, standards, procedures, and guidelines, as well as industry best practices;

· Participating and fully cooperating with CMS IS audits, reviews, evaluations, tests, and assessments of contractor systems, processes, and facilities;

· Providing upon request results from any other audits, reviews, evaluations, tests and/or assessments that involve CMS information or information systems;

· Reporting and processing corrective actions for all findings, regardless of the source, in accordance with CMS procedures;

· Documenting its compliance with CMS security requirements and maintain such documentation in the systems security profile;

· Preparing and submitting in accordance with CMS procedures, an incident report to CMS of any suspected or confirmed incidents that may impact CMS information or information systems; and

· Participating in CMS IT information conferences as directed by CMS.

D. Other Standards, Policies and Procedures

The following laws, regulations and standards provide the structure for CMS to implement and manage a cost-effective IS program to protect its information and information systems.

· CMS ILC Framework (http://www.cms.hhs.gov/SystemLifeCycleFramework)CMS Requirements Writer’s Guide

· Federal Enterprise Architecture Consolidated Reference Model Version 2.0, June 2006, http://www.whitehouse.gov/omb/egov/documents/FEA_CRM_v20_Final_June_2006.pdf

· IEEE 1058-1998, IEEE Standard for Software Project Management Plans

· IEEE/EIA 12207.0-1996, IEEE Standard for Information Technology - Software Life Cycle Processes

· IEEE/EIA 12207.1-1997, Guide for ISO/IEC 12207, Standard for Information Technology - Software Life Cycle Processes - Life Cycle Data

· IEEE/EIA 12207.2-1997, Guide for ISO/IEC 12207, Standard for Information Technology - Software Life Cycle Processes - Implementation Considerations

· IEEE Std 1062-1998, IEEE Standard for Recommended Practice for Software Acquisition

· EEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans

· IEEE Std 1012-2004, IEEE Standard for Software Verification and Validation

· IEEE Std 1028-1988, IEEE Standard for Software Reviews

· IEEE Std 1042-1987, IEEE Standard for Software Configuration Management

· IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

· IEEE Std 1540-1998, IEEE Standard for Risk Management

· IEEE Std 828-1998, IEEE Standard for Configuration Management Plans

· IEEE 1362-1998, IEEE Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document

· OMB Circular A-94, Guidelines and Discount Rates for Benefit-Cost Analysis of Federal Programs

· OMB Circular No. A-123, Management’s Responsibility for Internal Control, December 21, 2004, http://www.whitehouse.gov/omb/circulars/a123/a123_rev.html;

· OMB Circular A-130, Management of Federal Information Resources, Transmittal 4, November 30, 2000, http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html;

· Clinger Cohen Act of 1996

· P.L. 93-579, The Privacy Act of 1974, (as amended)

· P.L. 99-474, Computer Fraud & Abuse Act of 1986, www.usdoj.gov/criminal/cybercrime/ccmanual/01ccma.pdf

· P.L. 104-13, Paperwork Reduction Act of 1978, as amended in 1995, U.S. Code 44 Chapter 35, www.archives.gov/federal-register/laws/paperwork-reduction;

· P.L. 104-208, Clinger-Cohen Act of 1996 (formerly known as the Information Technology Management Reform Act),

· P.L. 104-191, Health Insurance Portability and Accountability Act of 1996 (formerly known as the Kennedy-Kassenbaum Act) http://aspe.hhs.gov/admnsimp/pl104191.htm;

· NIST standards and guidance, http://csrc.nist.gov/; and,

· Department of Health and Human Services (DHHS) regulations, policies, standards and guidance http://www.hhs.gov/policies/index.html

· Federal Acquisition Streamlining Act of 1994, Title V

(FASA V) , P.L. 103-355

· Capital Asset Plan and Business Case Summary Exhibit 300

C.4 Concept of Operations

The TrOOP contractor shall:

· Maintain the Part D Eligibility Index provided by CMS.

· Use the Part D Eligibility Index to provide responses to pharmacy queries for beneficiary eligibility information (including supporting the CMS low-income NET program Contractor), and

· Support the TrOOP facilitation process by:

· Building a database of primary Part D and supplemental payer BIN/PCNs;

· Identifying claims supplemental to Part D;

· Using the supplemental claim to build an NCPDP v5.1 (or if applicable D.0) Nx transaction including CMS-required data elements;

· Sending the Nx to the relevant Part D Plan;

· Identifying beneficiary mid-year enrollment changes for automated TrOOP balance transfer; and,

· Creating and sending NCPDP Financial Information Reporting (FIR) transactions to all relevant Part D plans.

· Send electronic copies of Nx transactions to CMS for audit purposes.

· Generate reports and monitor processes and outcomes as directed by CMS.

In order to facilitate TrOOP calculations by Part D plans, the Contractor shall accommodate the delivery of data from other switches (entities that provide network routing services to pharmacies. In order to provide the data to the Contractor for TrOOP facilitation, the switches will conform their systems to any changes necessary to meet CMS and the Contractor’s requirements and will provide training and customer support to their pharmacy customers. CMS desires to reimburse the switches for these transaction routing services. This modification establishes the mechanism for CMS to pay the switches by utilizing the services of the Contractor.

To accomplish the tasks described in this Statement of Work, the Contractor must be an existing pharmacy “switch” (i.e., provider of network routing services) with the systems’ capacity to process a minimum of 37 million TrOOP Facilitation-related, real-time, electronic transactions per month. As detailed in the following sections, the Contractor shall:

1. Accept and respond to pharmacy-initiated eligibility queries;

2. Accept from pharmacies and other switches Part D claims transactions and route these transactions to the Part D plans;

3. Accept supplemental claims transactions from pharmacies and other switches, and create and route transactions reporting supplemental claims data to the Part D plans; and

4. Create and route automated TrOOP balance transfer transactions and accept responses to these transactions.

These tasks require a 24/7 real-time, on-line switching network and connectivity with pharmacies, other pharmacy switches and all Part D plan sponsors, with the exception of Programs of All-Inclusive Care for the Elderly (PACE) organizations that do not participate in the automated TrOOP balance transfer process.

C. 5 True Out-of-Pocket (TrOOP) Facilitation Process

All Part D sponsors must correctly calculate TrOOP in order to properly adjudicate beneficiary claims and to communicate this information to plan enrollees. In lieu of Part D sponsors separately setting up procedures to coordinate benefits with every other payer with responsibility for drug coverage for one of their Part D enrollees, the industry, in response to a request from CMS and in collaboration with the National Council of Prescription Drug Programs (NCPDP), developed the TrOOP facilitation process that allows the majority of pharmacy claims processing to take place real-time at the pharmacy point of sale.

With the implementation of Medicare part D, new electronic transaction capabilities became available as part of the TrOOP facilitation process. As described below, these transactions offer pharmacies the ability to submit eligibility inquiries without the need to fill a prescription and to bill payers supplemental to Medicare.

· A Part D beneficiary enters a pharmacy to fill a prescription. If the beneficiary does not have a Part D ID card and does not know which Part D plan they are in, the pharmacy may execute an E1 transaction to determine Part D plan enrollment and/or Medicare Part A/B eligibility.

· The TrOOP facilitator returns an E1 response to the pharmacy.

· The pharmacy submits the claim to the Part D plan.

· The Part D plan sends a response to the pharmacy with payment information along with any supplemental payer information, including that payer’s unique RxBIN/PCN.

· The pharmacy then generates a secondary claim to the supplemental payer, placing its unique RxBIN/PCN in the claim headers, and routing the claim through the pharmacy’s switch.

· The supplemental payer sends a response back to the pharmacy routed through its switch, which sends a copy of the billing response to the TrOOP facilitator.

· The TrOOP facilitator builds an NCPDP Nx transaction from the response and sends it to the appropriate Part D plan.

· The TrOOP facilitator forwards a copy of that Nx transaction to CMS.

· When a beneficiary changes Part D plan enrollment during the coverage year, the TrOOP facilitator identifies the enrollment changes and sends a FIR transaction in sequence to prior Part D plan during the coverage year.

· Each Part D plan responds back to the TrOOP facilitator with the plan’s accumulated TrOOP and gross drug costs for the beneficiary.

· The TrOOP facilitator sends the total accumulated data from all prior plans to the beneficiary’s new Part D plan.

C. 6 Tasks

A. Task 1: Receive and Maintain the Part A/B and D Eligibility Index

Task 1 includes the functional requirements necessary to receive, store and maintain data necessary to support an eligibility request (usually originating from a pharmacy point-of-sale system). A pharmacy would perform the eligibility request to determine if the beneficiary is enrolled in a Part D plan and, if so, which plan and/or whether the beneficiary is Part A/B eligible when the beneficiary cannot provide some or all of this information (i.e., does not have his/her ID cards) and the pharmacy system does not contain the information (e.g., the first time the beneficiary comes to the pharmacy).

The Contractor shall receive, store and maintain the eligibility index to support Part A/B and/or D eligibility requests and FIR transactions. The Medicare eligibility index record layout specifications are contained in (Attachment J.2).

· Task 1a: Creation and Use of a Medicare Eligibility History File

Using the Medicare eligibility index, the Contractor shall create a Medicare eligibility history database by:

· Receiving and storing CMS-provided Part D eligibility data.

· Comparing the eligibility data on each update file received to the existing history file to identify Part D enrollment changes.

· Adding new enrollments to the history file.

· When an enrollment on the existing history file has been audited off, retaining the record for purposes of FIR, but considering it an invalid record for the purpose of eligibility inquiry requests.

· Task 1b: Receive and Maintain the Plan Pharmacy Help Desk Telephone Numbers

Task 1b includes the functional requirements necessary to receive, store and maintain the Part D Contract Numbers and toll free telephone number of the Part D plan in which a beneficiary is enrolled. These data are received from the Health Plan Management System (HPMS) and stored on the database housing the information coming from the Medicare Beneficiary Database (MBD). A pharmacy would submit an eligibility inquiry to determine the pharmacy help desk phone number of the Part D plan, in order for the pharmacy to identify the number to call for questions regarding claims.

B. Task 2: Switch Processing

The Contractor shall receive data from other entities that provide network services to pharmacies (“switches”) when those switches elect to deliver such data to the Contractor, report to CMS on data routed through each of the other switch’s network, and pay the other switches in accordance with H.9 of this Contract.

C. Task 3: Reporting to CMS

· Task 3a: Daily Reporting for E1 Services

This functional requirement provides ongoing reports for the E1 services showing:

1. The daily match statistics for the E1 and A/B queries (TrOOP Facilitator Match Rate Statistics - Summary Report.)

2. The daily TrOOP Import Daily Report.

3. The daily TrOOP 4Rx Report (as mutually agreed).

· Task 3b: Monthly Reports for E1 and Nx Transactions

Task 1b reports shall be created on a monthly basis or as required (by the GTL). Transaction match rates may vary from month to month. The Contractor shall perform on-going monitoring and analysis of the matching rates to identify problems and their causes, and make recommendations to address them. Any improvements to E1 or Nx transaction processing shall require CMS approval. The monthly reports shall contain a written analysis of the E1 and Nx transaction matching, with a description of the identified causes for problems occurring in the matching and recommendations for improvement, if applicable.

· Task 3c: Provide CMS with Copies of the Nx Transactions

The contractor shall provide CMS with copies, in electronic format, of the Nx transactions delivered to the Part D Plans. At a minimum, the contractor shall transmit to CMS in a weekly batch process a copy of all non-rejected, non-pending Nx transactions transmitted and accepted by the Part D plans.

CMS compares a sample of the Nx transactions that are accepted by the Part D sponsors to the sponsor-submitted prescription drug event (PDE) data to evaluate the accuracy of the PDEs in reporting the TrOOP eligibility of the amounts paid by the supplemental payers.

· Task 3d: Invoice CMS for Costs related to TrOOP Activities

Invoice CMS for costs associated with the contract, including, but not limited to, contract administration and management, processing E1 queries, creating and sending Nx and FIR transactions, and operating the help desk, electronic mailbox and/or other functionality for receiving financial reporting transaction requests.

D. Task 4: Maintain a Help Desk

The contractor shall maintain a help desk to answer technical questions regarding, but not limited to, eligibility queries and the TrOOP facilitation process (including automated TrOOP balance transfer).

The help desk should be functional for 8 hours per day local prevailing time for normal conduct of business for pharmacies and plans in all time zones that the contractor performs its contract-related functions.

E. Task 5: Maintain TrOOP Facilitator Environment

This functional requirement provides for ongoing maintenance of the existing system, to ensure proper functionality (e.g., problem fixes).

The TrOOP Facilitator shall maintain a Disaster Recovery (DR) site for the purpose of ensuring service continuity in the event the primary TrOOP system experiences circumstances of failure which deems it unable to provide services as required under the TrOOP Facilitator contract. The DR site shall be in a secondary location with up-to-date and tested hardware/software; and current application functionality and databases as the primary facility. If required, the DR site shall begin providing services within 24 hours of the primary facility failure.

F. Task 6: Execute a Business Associate Agreement with Each Part D Sponsor for COB Information Exchange

Task 6 is the functional requirement to execute a Business Associate Agreement (BAA) with each Medicare Part D sponsor, so that the reporting of TrOOP information to the TrOOP Facilitation contractor by other (Part D or non-Part D) plans is made to a valid business associate of the Part D Plan as a covered entity. Medicare Part D plans must effectively coordinate benefits with other (non-Part D) plans providing prescription drug coverage as well as transfer TrOOP-related accumulators between Part D plans whenever a beneficiary transfers Part D plan enrollment during the coverage year. To facilitate the information exchange necessary to support coordination of benefits and the tracking of TrOOP costs, the TrOOP facilitator creates and sends transactions reporting non-Part D plan claims information and other Part D TrOOP accumulators to the Part D Plan. Because these reporting transactions involve the exchange of protected health information (PHI), compliance with the HIPAA Privacy Rule concerning PHI use and disclosure by covered entities is required.

To ensure compliance with the HIPAA Privacy Rule (45 CFR Parts 160 and 164), the TrOOP Facilitation contractor shall execute a Business Associate Agreement (BAA) with each Medicare prescription drug plan sponsor, so that the reporting of TrOOP information to the TrOOP Facilitation contractor by other plans is made to a valid business associate of the Part D Plan as a covered entity.

CMS will facilitate this process by making a standard language BAA (see Attachment J-8 available to Part D plan sponsors and encouraging the plans to execute the BAA with the TrOOP Facilitator without amendment. The contractor shall negotiate the execution of a signed BAA with those plan sponsors electing to amend the standard language agreement. The contractor shall not negotiate the amendment of more than 10% of the BAAs with plan sponsors. If more than 10% of plans elect to amend the standard language agreement, the contractor shall notify the Project Officer (PO).

Until signed agreements are executed with all Part D Plan sponsors, the TrOOP Facilitation contractor shall send a monthly electronic status report to the PO detailing: the number of BAAs executed with and without amendment, the number pending; and the current number involving on-going negotiation with plan sponsors.

Prior to the beginning of each new Part D contract year, CMS will identify any new Part D sponsors and the Contractor will execute signed agreements with these sponsors.

G. Task 7: Provide Responses to Pharmacy Eligibility Queries

Task 7 imposes certain requirements related to the Contractor’s provision of a response to an eligibility query (usually originating from a pharmacy point-of-sale system) to determine which Part D Plan a beneficiary is enrolled in and/or whether the beneficiary is Part A/B eligible when the beneficiary cannot provide some or all of this information (i.e., does not have his/her cards) and the pharmacy system does not contain the information (e.g., the first time the beneficiary comes to the pharmacy).

This functional requirement utilizes the E1 specifications outlined in Attachment J-4.

The Contractor shall use all official (i.e., non-audited off) records in the “Part D Contract Data” field in the Medicare eligibility index to determine historical, current and future coverage, including contract information, coverage dates and 4Rx data.

i.The TrOOP Facilitator shall provide on-going support (maintenance) and analysis of the E1 environment, including supporting requirements, design, development, QA, project management.

ii.The TrOOP Facilitator shall maintain the ability for pharmacies to test the E1 transaction;

iii.Incoming E1 Query shall:

· Allow the user to enter a Date of Service that is up to 90 days old and 90 days in the future.

· The database must store historical coverage information for up to 90 days old and future coverage information for up to 90 days in the future.

· The system will retrieve all of the coverage information with:

· An Effective Date greater than or equal to the Date of Service AND

· An Effective Date less than or equal to the Date of Service AND

· A Termination Date greater than the Date of Service.

iv.E1 Queries Matching Logic shall support the following:

· When the Social Security Number, HICN, or Railroad Board Number match exactly, the system will validate that the first four characters of the Last Name in the E1 Request match the first four characters of the Last Name in the Part D Eligibility database.

· If the first four characters of the Last Names do not match, the reject code and message will be as defined in Attachment J-3.

· If the first four characters of the Last Names do match, then the match is returned as defined in Attachment J-3.

· If two or more patients are found, the reject code and message will be as defined in Attachment J-3.

· If the patient is found but the patient’s Part D coverage is not active, based on the Date of Service, then the reject code and message will be as defined in Attachment J-3.

v.The E1 Queries Outgoing E1 Response shall:

· Contain the information specified in Attachment J-3.

· Use the fields from the Part D database to populate the response as defined in Attachment J-3 When the contractor utilizes the Medicare Eligibility Index in an eligibility query response, the Contractor shall:

· Receive the eligibility query and provide a response utilizing the NCPDP v5.1 (or, if applicable, vD.0) E1 standard transaction.

· Receive and respond to batch eligibility transactions following NCPDP standards.

· Use the minimum matching criteria contained in Attachment J-3 to match the E1 query to the Medicare Eligibility Index.

· Ensure that the E1 query response meets the CMS security and privacy standards contained in Section H of the Contract.

Requirements for supporting the NCPDP v5.1 (or, if applicable, vD.0) E1:

· Eligibility Transaction (E1) Query—

The RxBIN/PCN on the query will be specific to TrOOP facilitator and the type of eligibility query requested; i.e., Part A/B or Part D. This information will be contained in the TrOOP facilitator’s Payer sheets containing the E1 specifications and will be available on the TrOOP facilitator’s website.

Required fields that will be used for patient matching are contained in Attachment J-3.

· Eligibility Query (E1) Response

Accepted queries will contain the information as required by NCPDP v5.1 E1 response and latest NCPDP v5 FAQ (or, if applicable, vD.0).

· Task 7a: Maintain isolated, non-production E1 Environment to provide the E1 Replay capability

Subtask a is the functional requirement to maintain a replay environment so that actual historical E1 transactions and new E1 transactions (using the E1 Submission System) can be delivered to an off-line, non-production system that responds to the E1 transactions. This system will enable modification to the E1 algorithm to clearly establish the impact of changes to the algorithm on the match rate.

The TrOOP Facilitator System Shall:

1. Enable changes in an isolated, non-production environment to the algorithm, reject messages, error codes, and application logic to allow for testing of different changes to the existing E1 system in place in the production environment;

2. Enable the delivery of actual past transactions to this non-production Eligibility system;

3. Allow for measurement of changes to the match rate as the system is changed, as described in 1, above.

· Task 7b: Provide On-Request Data Analysis of E1 Transactions Subtask b is the functional requirement to provide an on request report of all E1 transactions (reviewed, matched and not matched) that have been sent to the Facilitator for a period of 60 days or specified period, as well as an “executive summary” of the results. Counts of matched and non-matched transactions are specified as follows:

Data Analysis Reports

Reporting Period: From mm/dd/yyyy to mm/dd/yyyy Number of E1 Transactions Reviewed Number of E1 Transactions Matched Number of E1 Transactions Not Matched

Date of Birth Count of Matched E1 Transactions with Matched Entire Date of Birth Count of Matched E1 Transactions with At Least Matched Day and Month Count of Matched E1 Transactions with At Least Matched Day and Year Count of Matched E1 Transactions with Matched Month and Year Count of Matched E1 Transactions with At Least Matched Day Count of Matched E1 Transactions with At Least Matched Month Count of Matched E1 Transactions with At Least Matched Year

Frequency Distributions Where Month and Year Match

Days Difference is the difference between the E1 date of birth and the date of birth in the found database record.

Months Difference is the difference between the month in the E1 date of birth and the month in the date of birth in the found database record.

Years Difference is the difference between the year in the E1 date of birth and the year in the date of birth in the found database record.

ZIP Code

1. Count of Matched E1 Transactions with Matched Entire ZIP Code

2. Count of Non-Matched E1 Transactions with Non-Matched Entire ZIP Code

3. Count of Matched E1 Transactions with First 3 or More Digits Matching

4. Count of Non-Matched E1 Transactions with First 3 or More Digits Not Matching

Last Name and First Name

1. Count of Matched E1 Transactions where the Last Name in the E1 Matches the First Name in the Database

2. Count of Matched E1 Transactions where the First Name in the E1 Matches the Last Name in the Database

3. Count of Matched E1 Transactions where the Last Name in the E1 Matches the First Name in the Database and the First Name in the E1 Matches the Last Name in the Database

4. Count of Matched E1 Transactions where the Last Name did not match.

5. Count of Matched E1 Transactions where the First Name did not match.

SSN

1. Count of E1 Transactions with a 9 digit value in the Cardholder ID field

2. Percentage of E1 Transactions with a 9 digit value in the Cardholder ID field

H. Task 8: Create and Maintain a BIN/PCN Table to Facilitate Routing of Supplemental Paid Claims Transactions

Task 8 is the functional requirement to create and maintain a BIN/PCN Table to be used by the switch community. The TrOOP Facilitator shall create the table and update it no less than monthly using the BIN/PCN data contained in the COB fields of the Medicare Part D Eligibility Index (see Attachment J-2), and provide the table to the switch community on a regular basis.

The switch community will use this table to determine which of the billing (B) claims that are submitted by their pharmacy customers should be routed to the Facilitator.

The file delivered to the other switches will be structured as follows:

Each field will be delimited with a comma. Each record will be delimited with a CR/LF.

I. Task 9: Transaction Processing, Capture Paid Claims Data, Create an NCPDP v5.1 (or, if applicable, vD.0) Nx Transaction, and Route the Nx Transaction to the Part D Plan

Task 9 is the functional requirement to, in real time, receive and route supplemental paid claims data to the relevant Part D Plan. The contractor shall identify a claim that is supplemental to Part D and match it to the Part D Eligibility Index to identify the beneficiary’s Part D Plan. After the paid claims data is matched, the contractor shall create an NCPDP v5.1 N1 transaction modified to include CMS-required data elements and route the N1 to that Part D Plan.

At a minimum, the contractor shall:

· Maintain file transmission capabilities with CMS using Connect: Direct via the MDCN;

· Receive and process daily updates from CMS;

· Receive supplemental claims transactions where Part D was the primary payer;

· Match the claims to the Part D Eligibility Index;

· Create an Nx transaction in the format described in Attachment J.5 when there is a match;

· Route the Nx to the appropriate Part D Plan;

· Handle adjustments and reversals using the NCPDP N2 and N3 transactions in the format described in Attachment J.5.

· Propose alternate process and matching criteria when there is no match to the Part D Eligibility Index to enable routing of N1 to the appropriate Part D Plan.

· Process the transaction consistent with industry standards for timely online processing.

· Receive data from entities that provide network services to pharmacies (“switches”) when switches elect to deliver such data to the contractor

· Report on and invoice CMS for Nx transactions created based on B transactions that are routed through each switch’s network and that are supplemental to Part D

· Pay switches on the basis of the Nx transactions that are created from the supplemental billing (B) transactions that have been routed to the Contractor.

· Task 9a: Maintain a Replay Environment for NCPDP v5.1 (and, if applicable, vD.0) B and N Transactions Subtask a is the functional requirement to replay Nx transactions which were previously generated and processed by the TrOOP facilitator, but which may not have processed correctly at the Part D plan. The TrOOP facilitator shall:

1. Provide ongoing support (maintenance) and analysis of the N transaction environment.

2. Allow for the re-play of Nx transactions to the Part D Plan that was originally rejected by the Part D Plan.

3. Allow for retention of Nx transactions for up to one year, whether in history or in back-ups, to facilitate the replay process.

4. Replay of Nx transactions will be performed as specific plans make the request.

5. The process must allow for the receipt and processing of Bx transactions, via a data feed, through the TrOOP facilitator system in order to generate Nx transactions.

6. Allow for the re-play of Bx transactions through the TrOOP system, to generate Nx transactions to the Part D Plan because the Part D Plan was not loaded in the Medicare eligibility database when the original Bx transaction was submitted.

· Bx transactions will be supplied via a data feed, from the switch(s).

· Bx transactions from the switch(s) will include appropriate request and response data.

· The TrOOP facilitator will process the Bx transactions, and generate appropriate Nx transactions to the Part D Plans.

· The retry process will run automatically every five days for 90 days from the date of service in the Bx transactions.

7. This process shall run on the 1st and the 15th of each month.

8. Data feeds from the switch(s) will include appropriate request and response data elements.

· Task 9b: Create a Unique Transaction Reference ID for each N1 Transaction Created and Include This ID on N Transactions Routed to the Part D Plan In handling adjustments and reversals, the Contractor shall match the B transactions to prior N1 transactions using six fields: Service Provider ID, Date of Service, Rx/Service Reference Number, Product/Service ID, Cardholder ID, and Fill Number.

When a B2 transaction is received by the Contractor without a Cardholder ID, the Contractor shall use the previously specified fields to match the B2 transaction to the prior N1 transaction in order to retrieve the Cardholder ID for inclusion in the N2 transaction to the Part D plan.

If an adjustment/reversal matches a prior B1 transaction on all six fields, the Contractor shall include the Transaction Reference ID from the N1 transaction for the matched claim on the N2 and N3 transactions routed to the Part D plan. So, when the Contractor sends an N2, N3 or final N1 transaction to a Part D plan, the transaction reference number will be consistent among all transactions for the same prescription/service claim.

The Contractor shall use batch processing for all Nx transactions, sending the transactions daily to Part D plans via the transmission mode (streaming or batch) as arranged with the plans, or the other process defined by NCPDP.

· Task 9c: Capture and Route Supplemental Payer Data via a Batch Subtask c is the functional requirement to receive batch claims data from the supplemental payers and route them to the relevant Part D Plan. The Contractor shall have a batch process available for claims that it receives in a manner other than real time. These claims include those from programs such as the Indian Health Service (IHS) or those presented by the beneficiary to its supplemental payer in hard copy (e.g., out-of-network claims). The supplemental payer will send its paid claims data directly to the Contractor in batch form. Once the Contractor receives the batched paid claims data, it shall follow the same online process, creating the NCPDP Nx transaction and sending it to the relevant Part D Plan.

At a minimum, the contractor shall:

· Receive supplemental claims data directly from the supplemental payer;

· Match the claim to the Part D Eligibility Index utilizing the matching criteria contained in Attachment J.3;

· Create the Nx transaction in the format described in Attachment J.5 when there is a match;

· Route the Nx to the appropriate Part D Plan; and

· Handle adjustments and reversals using the NCPDP N2 and N3 transactions in the format described in Attachment J.5 and following the process outlined in Task 9, Subtask b above; and

· Propose alternate processing and matching criteria when there is no match to Part D Eligibility Index to enable routing of Nx to the appropriate Part D Plan.

J. Task 10: Create NCPDP Financial Information Reporting (FIR) Transactions to Support the Transfer of TrOOP-related Data between Part D Sponsors, when a Beneficiary Changes Enrollment during the Coverage Year

Task 10 is the functional requirement to identify beneficiaries changing Part D enrollment at the contract level during the coverage year, in real-time, create financial information reporting (FIR) transactions that request monthly benefit adjudication balances from each prior Part D plan of record, receive the FIR responses from each sponsor, and route these transactions to each subsequent Part D plan of record.

At a minimum, the contractor shall:

· Identify Medicare beneficiaries who, during the coverage year, are changing plan enrollment at the contract level.

· Create a FIR inquiry transaction requesting monthly benefit adjudication data in the form of total TrOOP amounts and gross covered drug costs from the earliest Part D sponsor in the coverage year. In identifying the earliest plan, include plans with official as well as audited off enrollment records in the eligibility history file.

· The initial set of FIR transactions for each beneficiary identified prospectively as changing enrollment at the contract level is initiated 2 days prior to the beneficiary’s new enrollment date. For enrollment changes with retroactive effective dates, the initial set of transactions is begun on the day following the day the enrollment change is passed in the Medicare eligibility index to the Contractor.

· Receive the FIR transaction response from the earliest Part D plan on record and continue the process of sending and receiving FIR transactions until each subsequent sponsor in consecutive order has received and responded to the FIR transaction. Thus, aggregated benefit adjudication balances are sent at the end of this process.

· Follow the FIR transaction process flow as detailed in the NCPDP FIR Standard Implementation Guide section 4.

· Follow-up FIR transactions requesting updated data from the prior plan(s) of record are sent weekly for a 4-week period, then monthly for an additional 6 months or until March 31st of the following year, whichever is earlier.

· Process the financial reporting transactions consistent with industry standards for timely online processing.

· Apply front-end edits to ensure that sponsor FIR Inquiry and Exchange transaction responses contain valid (i.e., properly formatted) data in all mandatory fields so the contractor can create the subsequent Update or Exchange transaction as appropriate.

· Invoice CMS for processing the financial reporting transactions containing TrOOP-related data.

· Participate in the NCPDP FIR task group to discuss and respond to user questions, concerns and issues.

· Take the lead on identifying FAQs or DERFs for any identified changes needed to FIR in consultation with CMS and NCPDP staff.

· Report to CMS:

· Weekly statistics on successful and failed transactions overall, by processor, and by Part D contract number;

· Bi-monthly reports of undeliverable transactions by beneficiary, processor and type of transaction, including the number of days elapsing since the initial transaction failure, and the transaction reject code.

· Those processors whose FIR transaction results suggest substandard performance, as reflected by non-response, reject and/or host processing error levels that appear atypical.

· Generate daily and bi-monthly exceptions reports to sponsors and processors identifying processing errors requiring sponsor/processor follow-up.

· Invoice CMS for costs associated with the operation of the help desk, electronic mailbox and/or other functionality for receiving financial reporting transaction requests.

· Task 10a: Receive and Respond to Part D Plan Requests for Inclusion in the Financial Information Reporting

Subtask a is the functional requirement to receive and respond to requests from Part D plans, other than the plan on record, which paid for covered Part D drug costs as a primary payer and subsequently became aware that the beneficiary was never enrolled in their plan.

At a minimum, the contractor shall:

· Operate a help desk, electronic mailbox and/or comparable functionality to receive requests for inclusion in the FIR reporting from Part D plans other than the plan on record which paid for covered Part D drugs as primary when the beneficiary is enrolled in another Part D plan.

· Create a “proxy” enrollment record; add the plan to the beneficiary’s eligibility record on the FIR eligibility history file (as for all proxy records, this enrollment would not be reported in response to an E1 query); and add the plan without the official enrollment to the FIR transaction stream preceding the official plan of record for the month(s) the other plan paid Part D claims for the beneficiary.

· Initiate a FIR transaction series incorporating the plan with the proxy enrollment.

· Track plan-requested financial reporting transactions and report on same to CMS.

· Respond to information from plans reporting the existence of a prior plan by:

· Searching the Medicare Eligibility History File to verify if the plan had a terminated or audited enrollment and, if so, adding them to the FIR transaction stream; or,

· If no prior enrollment record exists, contacting the prior plan to secure the information to create a proxy enrollment and adding them to the FIR transaction stream.

· Task 10b: Conduct FIR Certification Testing with New Part D Sponsors/Processors

Subtask b is the functional requirement to conduct certification testing of any new Part D sponsor’s, or new processor’s, ability to receive and respond to FIR transactions.

At a minimum, the contractor shall:

· Work in collaboration with CMS, NCPDP and industry representatives to develop a set of test scenarios and process for the certification testing of any new Part D sponsor’s, or new processor’s, ability to receive and respond to FIR transactions.

· Create a testing capacity to generate, receive and evaluate test FIR transactions.

· Crosswalk each new Part D sponsor to its processor, develop a tracking process to ensure communication with each processor, and working with any new processor schedule, test and certify their ability to receive and appropriately respond to the FIR transactions within the set of test scenarios.

· Report weekly to CMS the results of certification testing conducted, or as directed by PO. Create a help desk function to work with processors to troubleshoot and resolve errors.

C. 7 Upgrades and Ad Hoc Reports

A. Upgrades The Contractor SHALL provide support for the performance of the operations, maintenance and enhancements of the component parts of the TrOOP system. The TrOOP system includes all software and data components of the True Out of Pocket (TrOOP) system.

The Contractor SHALL incorporate enhancements to the system in accordance with CMS guidance.

Upgrades and Ad Hoc Reports may include but are not limited to:

· Technical Consultation and Support

· System Analysis, Develop, and Process Improvement

· 3rd Party Audits

· Use of Supplemental Payer Table

B. Technical Consultation and Support The purpose of this task is to facilitate the provision of technical support to CMS and the managed care, pharmacy and prescription drug benefit industries on data requirements and systems relating to TrOOP facilitation, prescription drug claims and coordination of benefits (COB) for the Part D prescription drug program.