DRAFT_Statement_of_Work.pdf

Statement of Work

Medicare Secondary Payer Integration Contractor

Version December 1, 2016

Table of Contents C.1 Background C.1.1 Medicare Integrity Program (MIP) C.1.2 Medicare Secondary Payer (MSP) Program C.1.3 Coordination of Benefits & Recovery (COB&R) Program C.1.3.1 Benefits Coordination & Recovery Center (BCRC) C.1.3.2 Medicare Secondary Payer Integration Contractor (MSPIC) C.1.3.3 Medicare Secondary Payer Systems Contractor (MSPSC) C.1.3.4 Commercial Repayment Center (CRC) C.1.3.5 Workers’ Compensation Review Contractor (WCRC) C.2 Statement of Work (SOW) Overview C.3 Functional Requirements C.3.1 Program Management Oversight C.3.1.1 Program-wide Management Plan C.3.1.2 Risk Management Plan C.3.1.3 Expedited Life Cycle (XLC) Support C.3.1.4 Problem Reporting/Change Request Tracking C.3.1.5 Change Control Board (CCB) Oversight C.3.1.6 Program Help Desk C.3.2 Business Analysis C.3.2.1 Business Requirements C.3.2.2 User Documentation C.3.2.3 Testing Services C.3.3 Program Document Management C.3.3.1 Document Management Conversion C.3.3.2 Litigation Hold Records and Documents C.3.3.3 Quality Assurance Oversight and Continuous Quality Improvement C.3.3.4 Capability Maturity Model Integration (CMMI) C.3.3.5 Tracking Database C.3.4 Outreach & Education C.3.4.1 Education Activities C.3.4.2 Outreach Activities C.3.4.3 Beneficiary Feedback Mailbox C.3.4.4 Website Content Management

C.3.5 Security Oversight C.3.6 Social Security Number Removal Initiative (SSNRI) C.4 Communication Requirements C.4.1 Joint Operating Agreements (JOA) C.4.3 COB&R Contractors Communication C.4.4 Workers’ Compensation Review Contractor (WCRC) Communication C.4.5 Secure Email C.5 Administrative Requirements C.5.1 Key Personnel and Staffing C.5.2.1 Project Director C.5.2.2 Quality Assurance Officer C.5.2.3 Principal Systems Security Officer (SSO) C.5.2.4 System Development Life Cycle (SDLC) Task Manager C.5.3 Non-Key Personnel C.5.3.1 Training Specialist C.5.3.2 Technical Writer C.6 Project Management Requirements C.6.1 Conflicts of Interest C.6.2 Bi-Weekly Project Status Report C.6.3 COB&R Monthly Executive Report C.6.4 Site Visits C.6.5 Meetings and Workgroup Participation C.7 Infrastructure Requirements C.7.1 Medicare Data Communications Network (MDCN) C.7.2 Government Furnished Software C.7.3 Government Furnished Hardware C.7.4 Security C.7.4.1 Holiday Schedule C.7.5 Business Continuity Planning and Disaster Recovery C.8 Project Management Plan C.8.1 Implementation Project Plan C.8.1.1 Implementation and Transition Requirements C.8.1.2 Contractor Transition Responsibilities C.8.1.3 Transition Project Plan

C.8.1.3.1 Transition Status Report C.8.1.4 Implementation Transition and Cutover Meetings C.8.1.5 Contract Phase-Out Services C.9 Deliverables 508 Compliance Section 508 Compliance for Communications Acronyms Attachments

C.1 Background

C.1.1 Medicare Integrity Program (MIP)

The Health Insurance Portability and Accountability Act of 1996 (HIPAA; Public Law 104- 191), added § 1893 to the Act, establishing the Medicare Integrity Program (MIP; 42 U.S.C. § 1395ddd). This program is funded from Medicare’s Federal Health Insurance Trust Fund for activities related to both Medicare Parts A and B. Specifically, § 1893 enables CMS to contract with an expanded pool of eligible entities to carry out certain Medicare integrity program activities that were being performed under contracts with Fiscal Intermediary (FIs) and carriers. On March 20, 1998, CMS published a notice of proposed rulemaking in the Federal Register (63 FR 13590); however, § 1893 authorizes CMS to enter into MIP contracts without publication of a final rule (see Appendix A, MSP Governing Statute and Implementing Regulations; and Appendix B, MIP Regulation for more information).

The MIP activities identified in § 1893 include: 1) conducting medical reviews of claims to determine whether the services rendered were medically necessary and met an appropriate level of care; 2) detecting and deterring Medicare fraud, waste and abuse; 3) auditing provider cost reports; 4) developing/updating the list of durable medical equipment subject to prior authorization; and most important for purposes of this Statement of Work (SOW), 5) ensuring that Medicare pays appropriately when a beneficiary has other insurance. This last activity is known as “Medicare Secondary Payer” (MSP) and involves those situations in which Medicare does not have primary legal responsibility for paying a beneficiary’s health care expenses.

C.1.2 Medicare Secondary Payer (MSP) Program

MSP involves those functions performed to identify when another payer has payment responsibility before Medicare in order to pay claims in the proper order and to Medicare primary payments made when another payer held primary responsibility. Under § 1862(a) of the Act (42 U.S.C. § 1395y(a)) items and services furnished by Federal providers, a Federal agency, or under a Federal law or contract, have been excluded from Medicare coverage (e.g., U.S. Military Hospitals, U.S. Department of Veterans Affairs, research grants). Furthermore, § 1862(b)(2)(A)(ii) of the Act (42 U.S.C. § 1395y(b)(2)) and the implementing regulations in 42 CFR Part 411 preclude Medicare from making primary payment where the beneficiary is:

• Age 65 or older and covered under an employer’s Group Health Plan (GHP) based on the current employment status of the individual or of his/her spouse (of any age), and the employer has at least (20) employees, or the GHP is part of a multi-employer plan where at least one employer has at least (20) employees and the GHP has not requested a formal small employer exception under 42 CFR 411.172(b) for any employee age 65 or older employed at a company with less than (20) employees; or

• Under age 65, entitled to Medicare on the basis of disability, and covered under an employer’s Large Group Health Plan (LGHP) based on his/her own current employment status or the current employment status of a family member. A LGHP is a plan where the employer has 100+ employees, or the GHP is part of a multi-employer plan where at least one employer has 100+ employees; or

• Within the first 30 months of eligibility/entitlement to Medicare based on having

End-Stage Renal Disease (ESRD) and is covered under any GHP (regardless of size or employment status) that covers individuals who have ESRD.

Additionally, Medicare may not make payment where payment has been made, or can reasonably be expected to be made, under a workers’ compensation (WC) law or plan, under no-fault insurance, or under liability insurance (including self- insurance). An entity that engages in a business, trade, or profession is deemed to have a self-insured plan if it carries its own risk (whether by a failure to obtain insurance or otherwise) in whole or in part. A primary plan’s responsibility for such payment may be demonstrated by a judgment, a payment conditioned upon the recipient’s compromise, waiver or release (whether or not there is a determination or admission of liability) of payment for items or services included in a claim against the primary plan or the primary plan’s insured, or by other means.

C.1.3 Coordination of Benefits & Recovery (COB&R) Program

The CMS has established a centralized Coordination of Benefits (COB) and Medicare Secondary Payer Recovery (MSPR) operation by consolidating these activities under a single program, COB&R (Coordination of Benefits & Recovery). The COB&R includes all of activities that support the collection, management, and reporting of other insurance coverage of Medicare beneficiaries and the collection of conditional payments or mistaken primary payments. These activities have previously been performed under two separate contracts. CMS has now established a centralized COB and MSPRC operation that provides quality customer service and a single source to Medicare providers, suppliers, beneficiaries, insurers and other stakeholders by streamlining the MSP data and debt collection processes, while ensuring the integrity of the Medicare Trust Funds. As with any consolidation of efforts for similar functions, savings of time and costs can be realized.

Consolidation of these two programs with an award to a single prime contractor has created a substantially large program and continues to impose restrictions on CMS related to its ability to monitor and react to a contractor’s performance. To avoid this situation, CMS has established a matrix organization of independent contracts to manage the major functions. Under the matrix organization, the combined COB&R activities are performed by the:

• Benefits Coordination & Recovery Center (BCRC);

• Medicare Secondary Payer Integration Contractor (MSPIC);

• Medicare Secondary Payer Systems Contractor (MSPSC);

• Commercial Repayment Center (CRC); and

• Workers’ Compensation Review Contractor (WCRC).

These components work in concert to encompass all of the activities necessary to ensure that the primary payer – whether it is Medicare, employer’s group health insurance, or other source of insurance – pays first, then identifies claims that were paid conditionally or mistakenly paid as Medicare primary, and pursues recovery in the most cost effective and efficient manner.

The following sections provide a high level overview of the functions to be performed by the matrix contractors of the COB&R.

C.1.3.1 Benefits Coordination & Recovery Center (BCRC)

The role of the BCRC is to perform those activities related to the operational components of COB&R. The BCRC activities consist of the following high-level functions:

• Call Center

• Mail Room/Imaging

• MSP Assessment and Debt Determination

• Waivers and Appeals

• Finance Administration

• Debt Collections

• Coordination of Benefits Agreement (COBA)

• Electronic Data Interchange (EDI) Support

• Special Projects

C.1.3.2 Medicare Secondary Payer Integration Contractor (MSPIC)

The role of the Integration Contractor is to make certain that all components supporting the COB&R contract function in concert. The MSP Integration Contractor makes certain all new and ongoing activities are properly communicated, handled, and managed by all COB&R supporting matrix contractors. The MSP Integration Contractor will not be held responsible for the various CMS program wide deliverables submitted from the other COB&R matrix contractors. However, the MSPIC will be expected to make sure all COB&R contractors are aware of the program deliverables. The following is a synopsis of the activities that shall be performed by the integration contractor:

• Program Release Management o Change Control Board (CCB) oversight o Problem/Change request database support o Program-wide project management plans o Program help desk

• Business Analysis o Business Requirement development o Testing and testing support o Documentation development

• Program-wide Document Management o Document management system o Document management administration

• Security Oversight

• Quality Assurance Oversight

• Outreach and Education

C.1.3.3 Medicare Secondary Payer Systems Contractor (MSPSC)

The role of the MSPSC is to provide development and support for all information systems for the COB&R contract. The MSPSC will be allocated 90,000 hours annually to perform these functions. Two-thirds of these allocated hours are expected to be used for development activities, while the remaining hours are to be used to for ongoing support of the information systems. This support would include all systems operations and software support.

The MSPSC Contractor would be comprised of the following groups and/or functions:

• Data Center Operations

• Network Support

• Systems Security

• Communication Support

• Data Management

• Software Development and Support

C.1.3.4 Commercial Repayment Center (CRC)

The CRC functions would include the identification and development of Group Health Plan (GHP) MSP Recovery, Non-GHP recovery cases where ongoing responsibility for medical care exists, and all associated recovery activities, which include, but are not limited to:

• Identifying and developing debts;

• Responding to incoming inquiries;

• Reviewing and responding to demand defenses and rebuttals;

• Providing litigation and negotiation support;

• Performing all related Debt Collection Improvement Act of 1996

(DCIA) activities; and

• Complying with all required financial activities.

C.1.3.5 Workers’ Compensation Review Contractor (WCRC)

• Reviews submitted Workers’ Compensation Medicare Set-aside Arrangement

(WCMSA) proposals to determine adequacy of proposed settlement funds in anticipating a beneficiary’s future ongoing course of medical treatment in association with his/her work-acquired illness, injury, or disease.

• Counters WCMSA proposals that have not anticipated future costs appropriately in light of standard medical care guidelines.

• As necessary, reconsiders additional information not previously provided in association with a previously submitted WCMSA proposal.

C.2 Statement of Work (SOW) Overview

C.2.1 Scope

The role of the Contractor is to make certain that all components supporting the COB&R contract function in concert. The Contractor will ensure all new and ongoing activities are properly communicated, handled, and managed by all COB&R supporting matrix contractors. As such, it is essential that this Contractor, the MSPIC, maintain communication and coordination with the other components of the COB&R. The Contractor tasks will include but will not be limited to the following:

• Program Wide Release Management o Responsible for ensuring all COB&R components are aware of upcoming releases and have taken into consideration any impact that would be imposed on any of the components through facilitation and analysis and includes but is not limited to those items enumerated on page 8 at C.1.3.2.

• Business Analysis o Primary responsibilities related to business analysis activities, including the development of business and functional requirements for enhancements to existing and development of application systems and includes but is not limited to those items enumerated on page 8 at C.1.3.2. . These activities will also include the execution of testing services and the development of all user manuals and documentation.

• Program-Wide Document Management o Responsible for providing an enterprise document management system for all COB&R components and to ensure all program documentation (e.g. business requirements, operating procedures, meeting minutes, etc.) is captured and stored in a logical manner.

• Quality Assurance (QA) Oversight o Function as an autonomous QA group for the COB&R components. This role in quality assurance would focus both on procedures and data quality. This group would be responsible for communicating CMMI compliancy requirements to the other components and creating a plan to attain a level 3 assessment. As such, this would also require the Contractor to perform comprehensive reviews of business procedures and develop process improvement recommendations. The Contractor shall also develop a feature/tool to track and monitor the progress of on-going COB&R projects, activities, etc.

o The QA group will also incorporate a data validation component. The data collected for COB&R requires substantial submissions of information from a variety of groups and individuals. Although these groups may submit information that passes system validity checks, there may be issues with the quality or correctness of the values provided. The data validation component would be used to address these types of issues and provide recommendations for improved data quality.

• Outreach and Education

Responsible for providing outreach activities to internal and external customers in support of the activities of COB&R. Development of education programs for external customers will be related to the understanding of the COB&R programs and policies. Development of education programs for internal customers will primarily be related to the use of IT systems, but may include education related to the COB&R program and policies.

• COB&R Website Content Management o The Contractor shall work closely with the COB&R components to assess and provide website support for all outreach and educational needs. Tracking and monitoring of MSP policy and procedural changes will be necessary to ensure the outreach and education requirements are being met. All documents will be maintained and tracked in the document management system and an approval process be developed.

• Security Oversight o Responsibility to ensure all physical and system security requirements are maintained by the COB&R components. The Contractor will ensure these processes are adequate and appropriate.

C.3 Functional Requirements

The following general requirements shall be adhered to for all functional requirements unless explicitly stated otherwise in the functional requirement:

• All timeframes stated within the SOW are in calendar days, calendar weeks and calendar months, unless otherwise explicitly stated.

• All CMS submitted documents shall be submitted in Microsoft Word 2013 or a compatible format (or in the latest version used by CMS).

• All CMS submitted project plans shall be submitted in Microsoft Project 2013 or a compatible format (or in the latest version used by CMS).

• All initial delivered documents to CMS are considered drafts. CMS shall be provided 7 calendar days to review and approve documents submitted. Unless otherwise stated the Contractor will have 3 business days to apply corrections to documentation after CMS review.

C.3.1 Program Management Oversight

The Contractor shall be responsible for ensuring all components of the COB&R process interact seamlessly to meet all of the processes requirements and objectives.

The Contractor shall participate in at least 26 COB&R program status meeting with all COB&R component contractors and CMS. The COB&R Program Status Meeting will be held at least a monthly basis, or bi-weekly if CMS so directs. The Contractor shall prepare agendas and schedule teleconference lines for these meetings and prepare at least 26 official meeting minutes, unless CMS directs that meetings occur bi-weekly.

C.3.1.1 Program-wide Management Plan

The Contractor shall develop and maintain a Project-wide Management Plan (PWMP) for the COB&R program. The MSPIC Contractor shall incorporate at least 3 other COB&R contractors’ PWMPs, including transition and implementation plans, into a master PWMP no later than 90 calendar days after each COB&R contract award. The PWMP will be used to monitor, track, and manage all system and functional initiatives. The initial PWMP shall be delivered 90 calendar days after award of the contract and as necessary. The PWMP should reflect a period of time to cover the remainder of the current fiscal year through the next fiscal year. The PWMP shall include the following items:

• A project plan for all release activities. The plan shall include all tasks and milestones associated with the release activities for all COB&R components.

• Routine scheduled activities. Any activity that occurs on an ongoing basis and may impact a COB&R contracting components. This should include, but not be limited to, deliverables, all contract tasks, and infrastructure outages for hardware and software maintenance. Routine activity schedule changes are not deemed critical and shall be updated on a bi-weekly basis.

• Special initiatives. These items should be added to the PWMP as needed and will include new task orders. These initiatives may also be the result of new policies, major hardware and software upgrades outside of routine system maintenance. Special initiative schedule changes are considered critical and shall be updated in the PWMP on a daily basis as necessary.

C.3.1.2 Risk Management Plan

The Contractor shall develop and maintain a Risk Management Plan (RMP) for the COB&R program. Each component of the COB&R (BCRC, MSPSC, and CRC) will develop its own Risk Management Plan, and delivered to CMS based upon their individual contract award date. The Contractor shall consolidate these separate RMPs and provide a comprehensive program-wide plan. The program-wide RMP shall be delivered not later than 90 days after the award of the contract. The RMP shall be reviewed by the Contractor and updated as necessary on an annual basis.

The risk management plan shall also encompass the development of a Business Continuity Plan (BCP). The BCP should identify the MSPIC Contractor’s vulnerabilities to internal and external threats and provide prevention and recovery to the organizations from those threats. Additionally, each component of the COB&R will develop its own BCP. The MSPIC Contractor shall verify that each component of the COB&R has accomplished its individual plan. The consolidated BCPs shall be completed and delivered no later than 60 days after the award of the contract. The MSPIC Contractor’s BCP shall be reviewed and updated as necessary on an annual basis.

The Contractor shall be responsible for conducting at least 10 Production Readiness Review (PRR) sessions for all major system releases, including quarterly releases.

C.3.1.3 Expedited Life Cycle (XLC) Support

The Contractor shall provide active support for all phases of software maintenance releases in coordination with the MSP Systems Contractor (MSPSC).

The Contractor shall assist CMS with overall project management activities throughout all phases of the XLC lifecycle for project applications. The Contractor shall provide, implement, and maintain an integrated project management approach that combines the technical plans, schedule plans, and the plans to meet cost objectives. This assistance shall include the following:

• General Project support – Support CMS by participating in recurring status meetings and taking meeting minutes, maintaining the project plans, issues log, metric reports and meeting scheduling.

• Status reviews – Attend meetings with CMS, BCRC, MSPSC, CRC, and WCRC as directed. Assist in developing and reporting the status of all the project related activities.

• Strategic Planning – Assist CMS with strategic planning for upcoming projects.

• Analysis/Design support—Assist CMS in tracking and reporting on the progress and quality of project deliverables. Other activities include participating in discussions regarding the proposed solution for design, and assisting with facilitation of resolution of open issues that affect the design of subsequent phases.

• Development support – Participate in discussions and reviews aimed at development activities. Assist CMS in tracking and reporting on the progress of the development efforts, while assisting in the consolidation of the comments related to the deliverables associated with these activities.

• Implementation support – Participate in discussions and reviews aimed at project implementation activities. Assist CMS in tracking, reporting and resolving all outstanding issues that would impede the implementation of scheduled projects. Program Issues Log – The Contractor shall maintain an issue log and report on it regularly. The issue log shall track open business, policy, or process issues. The initial issues log shall be delivered to CMS 60 calendar days after the award of the contract. Note: The Program Issue Log shall be updated bi-weekly and delivered to CMS with the Contractor Project Status Report.

• Project Briefings – The Contractor shall prepare project briefings upon request.

These briefings shall highlight the status of the project and all ongoing activities.

These briefings may be focused on such things as the status of the current release or the overall project status. These briefings shall be appropriate to the audience and shall provide CMS the necessary information to understand and manage the project.

The Contractor shall be responsible for conducting a Production Readiness Review (PRR) for all major system releases, including quarterly releases.

The Contractor shall deliver a Post Implementation Review Report for each major release and special initiatives as needed. This report will consist of the following: release overview, lessons learned, comparative analysis of measurable improvements, success analysis, and defect analysis. The purpose of this report is to document issues and problems encountered with each release. The lessons learned portion will include a summary of problems encountered during the entire development lifecycle for the release and include recommended process improvements to prevent reoccurrence. The report also needs to include a detailed defects analysis portion. This portion will document problem reports opened during the first month following the release deployment. The process shall also track and report all variances from the baseline release schedule.

The report shall be delivered to CMS no later than 60 calendar days after the release. CMS at its discretion may request the findings be presented as a part of a Post Implementation Review (PIR) meeting.

C.3.1.4 Problem Reporting/Change Request Tracking

The Contractor shall provide a Problem Report/Change Request application to track all problem reports, change requests, and service requests. The application must be accessible by all components associated with the COB&R programs and CMS. Application access shall be managed and controlled by the Contractor.

The application shall include varying levels of access authority, restricting or allowing users the ability to add, update, and close problem reports and change requests. Problem reports and change requests can include Protected Health Information (PHI); accordingly, the application must be have appropriate security controls.

The Problem Report/Change Request application and database shall support at a minimum the following fields or functions:

• Title or abbreviated synopsis.

• Requesting person or group information (name, phone, email).

• Assigned person or group (name, phone, email).

• Detailed description of problem or change request.

• Detailed text of resolution.

• Defect type or cause.

• Status indicator.

• Priority indicator.

• Dates including open, assigned, closed.

• Related system or functional area.

• Related change request or problem number.

• Audit trail of activity.

The application shall provide the ability to generate reports or perform ad-hoc queries. The database shall be used proactively to routinely analyze all problems in order to implement process improvements or to identify changes to reduce the number of future problems.

The Problem Report/Change Request Tracking application and supporting database shall be available 60 calendar days after the award of the contract. Existing system change requests and problem logs under the COB&R programs shall be converted to this Problem Report/Change Request database no later than 90 calendar days after the award of the contract

C.3.1.5 Change Control Board (CCB) Oversight A CCB process shall be instituted to review, monitor, and manage all system change requests and problem corrections for all systems operating under COB&R. Each contracting component of the COB&R and CMS should comprise the CCB. MSPIC staff shall also attend the CCB meetings when held. The Contractor shall develop the procedures that govern the CCB. The CCB procedure shall be submitted to CMS no later than 30 calendar days after the award of the contract. Upon approval by CMS, the Contractor shall enact these procedures and assume the lead role in overseeing the CCB meetings. As part of the CCB process, the MSPIC shall:

• Track the status of emergency fixes/PLOGs and Service Requests as well as Change Request priorities. Note: CR priorities will determine the scope of the changes for a quarterly or monthly release.

• Coordinate changes with other CMS applications that interface with the COB&R program, such as HIGLAS, MyMedicare, CWF, MBD, IDR, and the like. Such coordination includes monitoring HIGLAS CRs as well as CMS E-chimp changes (FFS and MAPD, as applicable).

The MSPIC should anticipate at least 26 CCB meetings per contract year, which will be held on a bi-weekly basis. The MSPIC shall submit an agenda for each CCB meeting to all CCB members three (3) business days in advance of the meeting. Additionally, the MSPIC shall distribute CCB meeting minutes to the CCB members within two (2) business days after a CCB meeting is held.

C.3.1.6 Program Help Desk

The Contractor shall establish a help desk to support and resolve issues arising within the COB&R program. The Contractor shall work as a conduit to report all system outages and application problems to and from the MSPSC, BCRC, CRC and WCRC. All systems refer to any internal or external facing application.

The Contractor shall provide a phone number and email address, (facsimile is optional) where COB&R components can report issues. The Contractor Help Desk phone shall be manned from 8:00 am to 8:00 pm Eastern Time. Voicemail and emails should be accepted during non-operational hours. During established Contractor holidays, where the Contractor is not working, they shall establish procedure, so critical or emergency issues can be addressed. Emails sent to the Contractor Help Desk shall be reviewed throughout the business day and an acknowledgement shall be provided to the submitter no later than the following business day. An escalation procedure shall be established for timeframes where the Contractor Help Desk is not manned. The escalation procedure must ensure that critical or emergency issues are addressed and resolved. The Contractor shall develop Standard Operating Procedures (SOP) for the Help Desk no later than 60 calendar days after the award of the contract.

All Help Desk contacts shall be recorded in a database. The information must include at a minimum:

• Title or abbreviated synopsis.

• Requesting person or group information (name, phone, email).

• Assigned person or group (name, phone, email).

• Detailed description of problem or change request.

• Detailed text of resolution.

• Defect type or cause.

• Status indicator.

• Priority indicator.

• Dates including open, assigned, closed.

• Related system or functional area.

• Related change request or problem number.

• Audit trail of activity.

The Problem Tracking/Change Request database described in section C.3.1.4 can be used for this function, provided help desk reports, system problem reports and change requests can be delineated.

The Help Desk shall monitor incoming calls and be able to assess priority situations. The Help Desk reports database shall be reviewed routinely for common reoccurrences of problems and issues. This information should be used to recommend process improvements. In addition, the Help Desk is responsible for the resetting users’ passwords for applications maintained by the MSPSC. Based on past experience and current trending, the contractor can anticipate an average of 5,000 issues, 5,500 password reset requests, and 2,000 user requests per year.

The MSPSC shall provide a daily report of production processing to the Contractor. The daily production processing report shall include, at minimum, the following information:

• Indication of completion of major applications batch cycles.

• Metrics indicating the number batch transactions processed (e.g. HUSPs transmitted to CWF).

• Notice of any system issues or abends.

The Contractor shall monitor the daily report for items that may impact the BCRC and the CRC. Potential issues or impacts related to COB&R systems must be provided to the business operations immediately.

The Help Desk must be able to send out targeted notifications to users on short notice. Examples include, but are not limited to, system outages that only affect one application. Only the affected users should be notified. The Contractor shall notify all users of unplanned application outages within 30 minutes of learning about the outage. The Contractor shall notify all users of all planned outages when notified by CMS of the outage.

The Contractor shall provide a monthly System Availability Report to CMS. The System Availability Report should report on the availability of all major system applications that support COB&R. A percentage of availability should be provided for overall application availability, as well as for each individual application. System issues reported during the month related to outages or latency shall be included in the System Availability Report with a description of the incident, root cause information, resolution and a list of previously reported related incidents.

C.3.2 Business Analysis

The Contractor shall have primary responsibilities related to business analysis activities, including the development of business and user requirements for the enhancements to existing COB&R systems, as well as the development of new programs and functions to support COB&R. The Contractor can anticipate four

(4) Major quarterly releases, which would entail approximately 5,500 hours each (22,000 hours annually) for system development functions (i.e. system design, coding, unit testing, system testing). The Contractor can also anticipate six (6) Minor releases, which would entail approximately 600 hours each (3,600 hours annually) for system development functions. At CMS’s discretion, business requirements may be required for off-release system modifications. The Contractor can anticipate four (4) off-releases, which would entail approximately 250 hours each (1,000 hours) for system development functions.

C.3.2.1 Business Requirements

The Contractor shall be responsible for the development of business requirement documents for all COB&R application development and modifications. Documents for business requirements include, but are not limited to, Business Process Models (BPM), Requirements Documents (RD), High Level Business Requirements, and Conceptual Data Models (CDM).

Requirements captured at this phase shall provide a suitable level of detail for establishing a common understanding among CMS, the BCRC, MSPSC, CRC, and the WCRC. Various methods, including user interviews, business owner interviews, and joint application development (JAD) sessions, shall be used to capture and validate core business requirements. A CDM may be constructed to define the high-level data objects and data relationships necessary to support the business requirements. The CDM developed as part of this activity, should align with existing COB&R data models. As part of the Business Requirements development, the MSPIC shall review the functional and system requirements produced by the MSPSC in order to make any necessary changes to business requirements based on system constraints.

Requirement Documents must be approved in writing by all COB&R contractor components and CMS before they are considered final. Approvals from impacted COB&R contractor components shall be obtained prior to submission to CMS. CMS shall be provided with seven (7) calendar days to review the Requirements Documents. These timeframes should be considered in the development of any project plans.

Business requirement formats must adhere to the CMS Expedited Life Cycle (XLC) or an agreed upon format with CMS. If a non-ILC standard business requirement format is to be utilized, the revised format must be submitted to CMS for approval no later than 60 days after the award of the contract. Business requirements shall be required for all major application, special initiatives, as well as quarterly and monthly releases. At CMS’s discretion, business requirements may be required for off-release system modifications.

The Contractor must provide CMS with a 7 calendar day window to review and approve requirement documents.

C.3.2.2 User Documentation

The Contractor should expect to update the reference materials and/ or user guides approximately six (6) times a year based on quarterly releases; application training information/materials and/or links to training/user group materials are expected to require updates approximately 10 times a year. The Contractor should anticipate updating application bulletin boards for urgent announcements and/ or links to official information (CMS.gov web sites) approximately 35 times a year.

This task involves developing and publishing user documentation. User documentation may be in the form of electronic or hardcopy documents, online help, online documentation, or context-sensitive help. The Contractor shall coordinate with the MSPSC, the BCRC, the CRC, the WCRC, and CMS to ensure that the user documentation meets all users’ needs. The Contractor will assume maintenance of existing and development of new user guides for all COB&R applications. All published materials for external entities require CMS approval before they are made public. The Contractor activities related to user documentation shall include, but are not limited to, the following:

• Responsible for publishing all application user documentation.

• Routine review of application user documentation and guides and submission of recommendations to CMS for updates and improvements.

• For COB&R Secured Website applications, the Contractor shall be responsible for the completeness and accuracy of technical/operational information and guidance to CMS systems external customers. This includes:

o Systems reference materials (application user guides).

o Frequently asked questions (FAQs), based on inquiries received.

o Help Page and Help Text updates.

o Common problems and recommended resolutions.

o Operational calendar/systems ‘outage’ information.

o Links to official information (CMS.gov websites).

o Relevant customer training information/materials or links to training/user group materials.

o Bulletin board for urgent announcements.

C.3.2.3 Testing Services

This function refers to formal testing services performed by the Contractor to make certain independent validation of software and system components developed, modified, or implemented by the MSPSC. (Note:

This may include testing of Commercial Off-The-Shelf (COTS) products.) To be clear, the MSPSC is responsible for unit, system, and string testing before the software is delivered to the quality assurance environment. The MSPSC is also responsible for debugging and correcting defects once the software has undergone independent testing. Test services shall validate that the software meets the user and systems requirements.

The Contractor is responsible for working with the MSPSC to identify test data. The Contractor shall be responsible for all parts of the testing process including:

• Review of requirement documentation.

• Creation of test case matrix.

• Creation of test cases.

• Execution of test cases.

• Documentation of test results and artifacts.

• Facilitation of daily testing status calls.

• Reporting and updating the problem reporting database for problems identified during testing.

The Contractor shall use automated testing tools to perform testing activities whenever possible.

CMS may request copies of all testing artifacts at its discretion. The Test Results and Test Log shall be delivered to CMS seven (7) calendar days prior to production implementation. Note: The Test Summary Report shall be delivered to CMS with the materials for the PRR prior to production implementation

The Contractor may be required to perform some testing tasks that require its physical presence at secure testing facilities on a scheduled or impromptu basis.

The testing artifacts that the Contractor shall maintain include, but are not limited to, the following:

• Test Plan.

• Test Cases.

• Test Summary Report

• Test Results and Test Log

Test Services for this contract include the following testing tasks:

• User Acceptance Testing (UAT)

UAT services provide end users with an opportunity to assess and accept the overall functionality and interoperability of the entire system. The Contractor is responsible for planning and executing User Acceptance Testing for all releases.

• Regression Testing

Testing performed to assess whether or not software changes to implement new business or technical requirements have negatively impacted unrelated application program or system functions. The Contractor is responsible for planning and executing Regression Testing for all releases.

• Release Implementation Testing

Immediately after all software deployments to the Production environment, the Contractor may be requested by CMS to conduct a series of tests, akin to what is termed “smoke tests,” to verify that the application is functioning correctly.

• Return to Service Testing

Testing performed after system down time to verify the applications are fully functional. After all system outages, planned or unplanned, the Contractor must verify system availability. Planned maintenance outages are normally scheduled for the weekend and testing may be performed on Saturday or Sunday morning. The MSPSC will notify the MPSIC when return to service testing can be started. Results of the testing shall be communicated to CMS. (The MSPSC is responsible for resolving any issues arising during this testing.)

With respect to the releases described in the Business Analysis section above, the contractor should anticipate performing testing for approximately 14 separate releases, which would include writing the necessary test cases. The Contractor may be required to perform some testing tasks that require its physical presence at secure testing facilities on a scheduled or impromptu basis; the Contractor should anticipate three (3) such visits. Since the locations may change, the Contractor is instructed to allocate travel, per diem etc., using Baltimore, Maryland, as the destination.

C.3.3 Program Document Management

The Contractor shall implement a document management system to track and store electronic documents to be shared between all components of the COB&R, 30 days after contract award. This system must allow all entities working on the COB&R program (including CMS) to be able to store, track, update, version and review electronic documents. The Contractor shall be responsible for transitioning all documentation to that system.

Shared documents to be stored within the document management system should include, but are not restricted to:

• Standard operating procedures.

• System documentation.

• Status reports.

• Workload Reports.

• Business requirements.

• Meeting agendas and minutes.

• Business/system diagrams.

• User guides and manuals.

• Training materials.

• Application prototypes.

• All COB&R website documents.

All documents referenced in this section shall also be included in the document management system.

The document management system shall employ a process to restrict access and update capabilities to the documentation based on users and/or groups. Collaboration should be an inherent feature allowing, but controlling, updates of documents by multiple users. The document management system shall not be used to store documents containing PHI, PII or FTI information.

The Contractor shall also have the responsibility for managing all stored documentation. This responsibility includes ensuring all appropriate documentation is stored and up to date. The documentation shall also be stored in a logical manner. All documents will be tracked and version controlled. All documents should be reviewed for accuracy and conformance with CMS policies including 508-compliance where appropriate.

The Contractor can anticipate interaction with approximately 500 COB&R program deliverables a year requiring gathering, reviewing, and storing electronically in a document management system.

C.3.3.1 Document Management Conversion

The Contractor shall provide CMS with a migration plan to the enterprise document management system not later than 90 calendar days after contract award. The migration plan shall specify what software will be used for the document management system, the logical structure of the documents, and the transition steps.

At its discretion, CMS may specify an alternative software product for the document management system.

Implementation and conversion to the enterprise document management system shall be completed no later than 90 days after award of the contract.

The Contractor can anticipate that the 10,000 documents will need be transferred from the incumbent’s document management system.

C.3.3.2 Litigation Hold Records and Documents

When the Department of Justice (DOJ) reasonably anticipates litigation implicating the Medicare and/or Medicaid programs, it sends a “litigation hold” request to the Centers for Medicare & Medicaid Services (CMS) via the Office of the General Counsel (OGC) CMS Division. These requests instruct CMS and CMS’s contractors to preserve and retain certain records and documents that relate to a specific case.

The OGC then directs the CMS Office of Strategic Operations and Regulatory Affairs to disseminate a litigation hold and document preservation memorandum to various CMS components who may have previously or currently handled matters related to the specific case, or who may otherwise have documents and information related to the case in their possession, custody, or control. CMS’s obligation to preserve and retain potentially relevant information also extends to CMS’s contractors who have relevant information within their possession, custody, or control. The Contractor may receive periodic litigation holds/document preservation memoranda for cases where the Contractor may have relevant information.

The Contractor shall designate a contact person who will be responsible for ensuring that the preservation and production directives are followed. The contact person designated by your organization shall complete a Contractor Litigation Hold Certification and Information Form (“Certification Form”), a sample of which is attached, and will be required to respond to with the signed Certification Form via email to the COR indicating that all contractor staff have been appropriately notified of the request. By completing and returning the Certification Form, the Contractor’s organization certifies its compliance and identifies individual document custodians.

C.3.3.3 Quality Assurance Oversight and Continuous Quality Improvement

The Contractor shall function as an autonomous Quality Assurance group for all contracting components of the COB&R. This quality assurance role would focus both on procedures and data quality. The Contractor shall perform reviews and audits on new workloads, as of the contract award date accomplished by COB&R Contractors and as directed by their CMS COR.

Not more than 90 calendar days after the effective date of the contract, or as determined by CMS, the Contractor shall provide a QA Plan.

The QA Plan shall be a stand-alone document and shall be a complete guide to the performance of all discrete activities associated with each distinct function. The CMS recommends the use of diagrams and flow charts to communicate to the targeted audience. The QA Plan shall be updated at least yearly, if necessary.

Quality related issues and problems shall be tracked and monitored in an automated fashion. The Contractor shall submit to CMS a QA Report on a quarterly basis. The

QA Report should specify the areas that were reviewed, the results of the reviews, opened action items, and a status of prior action items.

In order to complete the quarterly QA reviews and reports, the Contractor may require access to a number of BCRC systems. As such, the Contractor shall work with the MSPSC to obtain access, as needed for the purposes of the QA review and reports, to the systems listed in Attachment 4- “BCRC Systems List.”

The Contractor should anticipate performing 900 letter review audits per year of the BCRC and CRC Contractors and approximately 200 Call Center telephone audits per year.

C.3.3.4 Capability Maturity Model Integration (CMMI)

All COB&R components including the Contractor are expected to achieve a CMMI Level 3 (Defined) within 18 calendar months after the award of the contract. CMMI level 3 shall be attained for the Service process by the Contractor.

CMS has the discretion to request a CMMI Level 4 appraisal during the contract period.

C.3.3.5 Tracking Database

The Contractor shall create a Deliverable Tracking System to submit, track, monitor, and report on contractor’s deliverables. The BCRC, CRC, MSPSC, MSPIC, and WCRC will use this system to submit deliverables to CMS for review. This system must allow all entities working on the COB&R program, including CMS, to be able to store, monitor, and update deliverables. The Contractor may determine the format in which the database is developed and implemented, but the database shall include the following criteria:

• A method to house all COB&R projects, activities, task orders and/or special initiatives;

• A “dashboard” feature upon entering the database;

• A brief description (1-3 sentences) of each of the aforementioned;

• Identification of the CMS and Contractor owners and back-ups;

• Identification of the start and end dates (if applicable);

• The ability to include or attach separate narratives by the CMS owners and back-ups and the Contractor owners and back-ups; and

• The ability to produce reports upon request by CMS.

The Contractor shall provide a proposed system (database) and method by which the database will be implemented not more than 90 calendar days after the effective date of the contract, or as otherwise determined by CMS.

C.3.4 Outreach & Education

The Contractor shall perform outreach and education functions for internal and external customers for all COB&R processes and functions. All Contractor activities related to education and outreach shall be provided in Contractor bi-weekly status report to CMS. An Education Plan shall be developed indicating expected and planned activities related to education and outreach. The Education Plan shall be developed no later than 90 calendar days after award of the contract and updated on a semi-annual basis.

Internal customers of the COB&R processes and functions include CMS and CMS contractor entities. The CMS contractor entities are not limited to the BCRC, MSPSC, CRC, and WCRC.