CMMI Value-Based Care Technology Request for Information.pdf

1 | P a g e

Center for Medicare and Medicaid Innovation (CMMI) Value- Based Care Technology Request for Information

Agency:

Contracting Office:

Document Type:

DHHS/CMS/OAGM/CMMI

7500 Security Blvd. Baltimore, MD 21244

Request for Information

Title: CMMI Value-Based Care Technology Request for Information

Posted Date: 10/5/2023

Response Date: 11/16/2023

Classification Code: D - Information technology services, including telecommunication services

NAICS Code:

541511 – Software Analysis and Design Services, Custom Computer

Incumbent: N/A

This is a Request for Information (RFI) to determine if there are contractors and industry solutions focused on value-based care operations that could advance the technology that supports the Innovation Center’s models and demonstrations.

This is a Request for Information (RFI) only. This RFI is solely for information and planning purposes. The RFI does not constitute a Request for Proposal (RFP) or a promise to issue an RFP in the future. This request for information does not commit the Government to contract for any supply or service. CMS is not seeking proposals and will not accept unsolicited proposals.

The U.S. Government will not pay for any information or administrative costs incurred in response to this RFI. Entities may participate in a future RFP, if issued, even if they do not respond to this RFI.

2 | P a g e

Table of Contents

1 Background

1.1 Agency

1.2 Center for Medicare and Medicaid Innovation (Innovation Center)

1.3 Definitions

2 Innovation Center IT

2.1 Vision

2.2 Current State

2.3 Challenges

3 Desired Results

Objective 1: Supply Functional Capabilities More Effectively

Objective 2: Improve Value-Based Care Computations

Objective 3: Provide a Good User Experience

Objective 4: Align with Architecture Vision

Objective 5: Improve CMS’ Internal Operations

4 Questions for RFI Responders

5 Instructions for Responders

Appendix A – Background

Understanding Innovative Models

Model Operations

Model Teams

Appendix B – Sample Model IT Solutions and Participant Data

PCF Model

Kidney Care Choices Model

ET3 Model

Comparison

Appendix C – Scope of Innovation Center Systems

Appendix D - References

3 | P a g e

1 Background

1.1 Agency

CMS is an agency of the US Department of Health and Human Services. CMS oversees three major programs:

1. The federal Medicare insurance program that provides health insurance to people aged 65 or older and certain people under 65 with disabilities or end-stage renal diseases;

2. The joint Federal and State-based Medicaid and Children’s Health Insurance Program (CHIP) that provides health insurance to some people with limited income and resources;

and

3. The Health Insurance Marketplace that allows people under 65 to buy health insurance from private health plans.

1.2 Center for Medicare and Medicaid Innovation (Innovation Center) The Center for Medicare and Medicaid Innovation (Innovation Center or CMMI) is one component in CMS.

Section 3021 of the Affordable Care Act of Public Law 111-148 (codified at Section 1115A of the Social Security Act) established the Innovation Center. The purpose of the Innovation Center is to test “innovative payment and service delivery models to reduce program expenditures…while preserving or enhancing the quality of care” for individuals covered by Medicare, Medicaid, or the Children’s Health Insurance Program.

The Innovation Center manages a portfolio of over 50 models that test new health care payment and service delivery models that aim to achieve better care for patients, better health for our communities, and lower costs through improvement for our health care system.

Refer to Appendix A for more information about the Innovation Center.

1.3 Definitions

Model: A pilot policy program. A model tests an intervention1 for a defined set of beneficiaries, providers, conditions, treatments, and/or populations over a prescribed period of performance. A model is not an IT system, an Artificial Intelligence algorithm, or a

1 Interventions include changes in payment for healthcare services, quality measurement, and incentives.

4 | P a g e mathematical model.

Participants: An organization or entity that has a direct relationship with CMMI and is responsible for meeting a model’s performance goals. Innovation Center model participant types are broad and include, but not limited to, Accountable Care Organizations, Medicare Providers and Suppliers, Medicare Advantage Plans, State Medicaid Agencies, and Community Based Organizations.

Solution: A set of elements that, in aggregate, provide unique operational capabilities for a model. The solution(s) must support the business functions described in Appendix A.

Currently, model solutions include these operational elements:

• IT capabilities from Agency-wide systems.

• IT capabilities from systems designed for Innovative models.

• Computations and analytics Implementation, Evaluation, and Learning contractors (i.e., people).

• People intensive processes such as help desks.

• Interoperable data exchange through health IT standards, such as US Core Data Set Core Data for Interoperability (USCDI) and Fast Health Interoperability Resources (FHIR).

Figure 1. illustrates the conceptual operations of the Innovation Center.

5 | P a g e

Figure 1. The Innovation Center’s Conceptual Operations

6 | P a g e

2 Innovation Center IT

2.1 Vision

CMMI wants the technology portfolio to:

• Help maximize participant retention by creating a positive experience for participants.

• Enable accurate and efficient decision making by making the right data and capabilities available to teams.

• Encourage outcome improvements by sharing data and capabilities within CMS, with participants, and with researchers.

Every year, CMMI launches models that require technology solutions. These models have diverse needs and operationalizing them requires a great deal of novel and agile problem solving. To achieve our aggressive model release schedule, CMMI must look for opportunities to reuse, quickly modify, and scale solutions to serve new needs.

CMMI’s reusability vision is to satisfy model requirements through.

Model solutions

Consuming

Shared services

Guided by

Shared standards

Accomplishing this vision will create a set of solutions and services that satisfy model requirements while avoiding duplication, maximizing reuse across models, and creating the agility needed for CMMI’s environment.

Model solutions will start with understanding what people need and designing a comprehensive experience from start to finish. The solutions will often involve more than writing code or may involve no code at all. Additionally, the solutions may include multiple services across multiple CMS components and contracts.

Sprint teams will collaborate with model teams to configure and/or develop solutions. These interdisciplinary teams will be nimble and flexible to organize themselves to meet a model’s needs. This flexibility is essential because of the fluid nature of model policy design and implementation.

7 | P a g e

The teams will use shared services to compose the model solutions. The shared services may include:

Shared Commercial Off the Shelf (COTS) products and services; and Shared Custom Services.

Shared standards guide the model solutions and ensure cohesion and sustainability across the Center.

Accomplishing this vision requires creating a set of solutions and services that satisfy model requirements while following these principles.

1. Avoid duplication and maximize reuse across models;

2. Use CMS-wide systems whenever possible to satisfy a model requirement. Use CMMI-shared services when CMMI must satisfy a model requirement;

3. Use commercial tools, products, and services when possible; and

4. Use health IT standards when possible to interact with participants.

2.2 Current State

Agency-Wide Systems Whenever possible, CMMI’s models use existing IT systems managed by other CMS components (e.g., Fee-for-Service (FFS) claims systems, Chronic Conditions Warehouse (CCW), Integrated Data Repository (IDR), Medicare Advantage and Part D (MAPD) systems).

Innovation Center Systems

CMMI or the Office of Information Technology (OIT) builds Innovation Center Systems for the unique capabilities that other CMS components do not supply for models. These systems fulfill requirements that are unique to the Innovation Center, including:

1. Data collections from participants. Section 3021 allows the Innovation Center to collect data from participants beyond what other components collect (e.g., unique metrics to measure model progress). As a result, CMMI tends to acquire or build these systems instead of using Agency-wide systems.

2. Data sharing and analytics for participants. The Innovation Center shares raw and

8 | P a g e curated data with participants to help them achieve model goals and improve quality and cost.

Model-specific systems CMMI did not have an IT Group or Division when it started in 2010. As a result, many early IT efforts focused on immediate needs without considering long-term architecture approaches.

CMMI still has model-specific systems (one system used by one model). The goal is to retire or consolidate these systems into Center-wide systems.

Center-wide systems created through 2016.

Through approximately 2016, CMMI and OIT developed several Center-wide systems (single systems used by multiple models). These systems slowed the growth of model-specific systems and supported new model implementations and operations across the Center. CMS developed a Center-wide system for ACO’s and another set of systems for non-ACO's.

Table 1. Center-Wide System through 2016

System Owner Scope ACO Operational System

(ACO/OS)

Used by 6 models

OIT Unique data exchange and data processing requirements for ACO and Kidney models.

Reusable Framework (RF)

Used by 13 models at its peak

CMMI Unique data exchange and data processing requirements for non-ACO models.

Innovation Center (IC) Landing Page

15 integrations to CMS Enterprise Identity Management.

CMMI Identity management integration and a common landing page for CMMI applications.

Figure 2. Center-Wide Systems focus on ACO and non-ACO models.

9 | P a g e

System Owner Scope Salesforce

Used by 30 models and initiatives

CMMI Request for application, participant portals, Customer Relationship Management and other requirements suited to Salesforce.

CMMI did not use Salesforce to store Protected Health Information (PHI) or to integrate to other CMS systems until 2022 because of Agency constraints.

Center-wide systems since 2019 Currently, the Innovation Center and OIT offer model teams reusable systems to support new models. OIT developed the 4i system to add a modern user interface on top of the ACO/OS.

CMMI developed three systems that integrate as one platform to use for non-ACO new models instead of Reusable Framework as illustrated in Figure 3. (Centralized Data Exchange (CDX), Health Data Reporting (HDR), and Expanded Data Feedback Reporting (eDFR))

Table 2. Center-Wide System since 2019

System System Owner

Notes

4innovation (4i) OIT Adds a modern user interface on top of the ACO/OS.

One Platform CMMI uses these three integrated systems for non-ACO new models instead of Reusable Framework.

Figure 3. Center-Wide Systems since 2019

10 | P a g e

System System Owner

Notes

• Centralized Data Exchange CMMI An API gateway that supports interoperability.

• Expanded Data Feedback Reporting

CMMI A business intelligence and analytics system.

• Health Data Reporting CMMI Collects clinical and non-clinical data from participants.

Figure 4 illustrates the current systems and services that support models in aggregate. A single model uses a subset of the systems in Figure 4. to launch and operate. Appendix B describes the operational implementation for three models as examples.

11 | P a g e

Figure 4. Current State Solutions

12 | P a g e

1. Common Technical services supply reusable technical services to the systems developed specifically for the Innovation Center including CMS Identity Management integration and an API gateway.

2. Model operations

A. Collect data from participants and manage daily operations.

Several systems exchange data with participants and manage daily operations. The requirements in Participant Agreements govern these data exchanges. These data exchanges are often unique to the Innovation Center and frequently require provider participants to submit data beyond what they submit as a Medicare or Medicaid provider. Depending on the model, CMMI may use:

• A CMS built system called 4i/ACO-OS for ACO models.

• A mix of commercial software (Salesforce) and systems built by the Innovation Center (Centralized Data Exchange (CDX) and Health Data Reporting (HDR)) for non-ACO models (e.g., State-based models, episodic models)

• GrantsSolutions to collect applications for Cooperative Agreement (grants) models.

• A combination of long-standing CMS systems Health Plan Management System (HPMS) and Medicare Advantage Prescription Drug (MARx) for MAPD models

B. Claims, Encounter, Payment There are several systems and services that process claims, encounters, and make payments. Depending on the model, CMMI may:

• Adjust FFS claims through the FFS Shared Systems and Medicare Administrative Contractors (MACs)

• Process encounters and adjust plan capitation payments through the MAPD Systems.

• Make non-claims-based payments through the Innovation Payment Contractor (IPC). Examples of non-claims-based payments are population-based payments, incentive payments, and infrastructure payments.

13 | P a g e

C. Implementation and monitoring contractors Implementation2 and monitoring contractors supply many services for models, such as:

• Develop methodologies (e.g., attribution, payment, participant vetting, auditing).

• Implement methodologies such as o Compute attribution o Compute benchmark o Compute claims-based measures o Reconcile performance against benchmark (e.g., compute shared savings/losses) o Vet participants

• Track and monitor participant performance.

• Identify trends.

3. Analytics for Models, Evaluation, and Learning

A. Models CMMI creates data products for model participants.

• The Expanded Data Feedback Reporting (eDFR) produces feedback dashboards and analytics for model participants. These products are based on CMS claims and model data.

• 4i/ACO-OS and eDFR produce raw claims files for participants (CMS Claims and Claims Line Feeds).

• Several models use the Beneficiary Claims Data Sharing API (BCDA) to share claims data with participants via API.

B. Evaluation All Section 3021 models must receive an evaluation. Evaluation teams typically use the Chronic Conditions Warehouse (CCW) to access the historical administrative data

2 Implementation contractors are not IT Implementation contractors. They provide health research services.

14 | P a g e required to conduct evaluations.

C. Learning CMMI’s Learning & Diffusion Group (LDG) convenes learning collaboratives for models.

• The eDFR system, described above, supplies feedback reports that inform participants and help them succeed in models.

• CONNECT is a Salesforce chatter application that creates a social media environment to facilitate participant-to-participant collaboration.

• LDG also uses a Salesforce application to collect meta data about learning events and dashboards from AMS to analyze the learning systems.

4. Internal Analytics CMMI produces analytics that support internal teams. CMMI teams use these systems and capabilities to assess the model portfolio, identify process improvement opportunities, and support new model design.

• The CMMI Analytics and Management System (AMS) aggregates model characteristics and model participation data to enable Center-wide dashboards and analytics.

• CMMI uses the Salesforce Customer Relationship Management (CRM) product to track and organize contacts with external entities.

5. CMS-Wide Data Sources CMMI uses CMS-wide data sources as described in Table 3.

Table 3. CMS-Wide Data Source Use

CMS Wide Data Source System Owner Purpose for CMMI Master Data Management

(MDM)

OIT Stores attribution lists for the models that have overlaps business rules.

Models that have overlaps rules check MDM to avoid disallowed overlaps.

Provider Enrollment, Chain, and Ownership System (PECOS)

Center for Program Integrity (CPI)

CMMI vets provider participants against CPI’s data sources (e.g., enrolled?, program integrity issues?)

1-800 MEDICARE Office of Communications

(OC)

CMMI checks 1-800 MEDICARE to filter out beneficiary records if the beneficiary opted out of data sharing.

15 | P a g e

CMS Wide Data Source System Owner Purpose for CMMI Healthcare Integrated General Ledger Accounting System

(HIGLAS)

Office of Financial Management

(OFM)

CMMI operates the Innovation Payment Contractor to make payments and interfaces with HIGLAS for banking and General Ledger functions.

Integrated Data Repository (IDR)

OIT Model teams use IDR’s claims, provider, and beneficiary data to support operations.

Chronic Conditions Warehouse (CCW)

Office of Enterprise Data Analytics (OEDA)

Evaluation teams use CCW’s claims, provider, and beneficiary data to support the analytics required for evaluation. Some model teams also use CCW to support operations instead of

IDR.

6. Third Party Data CMMI uses third-party data to enrich systems and analysis.

2.3 Challenges

CMMI has achieved a great deal of reusability in the last 10 years and has successfully launched 58 models since the Center’s inception. However, there are still gaps in the architecture and opportunities to improve the experience of all entities involved with models.

There are model-specific IT systems remaining.

In 2020, 43% of CMMI’s IT systems were model-specific systems. These systems were developed specifically for a model and not usable by other models. Since 2020, CMMI has retired 7 systems. 11% of the Center’s IT systems are now model-specific systems.

Individual model implementations are complex.

One model needs multiple systems, services, and operations from multiple contracts and CMS components. Model teams navigate a complex set of systems and processes to implement operations for a model. This creates complex implementation projects that CMMI must complete on the accelerated timeframes between model clearance and model go-live (often one year or less). Appendix B illustrates sample model implementations.

The user experience is fragmented.

16 | P a g e

Participants typically interact with several CMS systems to engage in a model. Additionally, many data exchanges with participants do not use health IT standards or take advantage of existing EHR capabilities. As a result, submitting data to CMS is often burdensome because organizations must take extra steps outside of their normal workflow and create custom capabilities to participate in models. This situation creates barriers to participation, increases provider burden, and misses opportunities to improve the beneficiary experience through care coordination.

There is duplicated participant data.

Multiple systems and contractors store and use participant lists. This situation increases the risk of incorrect business processing and increases costs. Appendix B includes an example of duplicated participant data.

Contractors manually perform critical business operations.

People at implementation contractors perform many of the most essential business functions for value-based care models. The contractors (a) acquire workspace in the IDR or CCW; (b) write SAS queries to extract data; (c) complete computations; and (d) create files in a desktop tool like Microsoft Excel. The model teams and contractors do not share code or data with each other.

These processes will be difficult to scale if the CMS actuary certifies models for expansion. Table

4. describes how CMMI implements common value-based care operations.

Table 4. Current implementation of value-based care operations

Function Definition Current Method

Attribution The process of assigning providers and/or patients to an entity (e.g., an ACO) that will be responsible for cost and quality of care.

Implementation contractors compute attribution manually.

Benchmark Establish cost or quality baseline with participants at the beginning of a model.

Implementation contractors compute benchmarks manually.

Quality Measures/ Clinical Data

Compute claims-based quality measures to monitor participant performance, trends, and, potentially, make payment

Implementation contractors compute quality measures manually.

17 | P a g e

Function Definition Current Method

Non-Claims Based Payments

Make incentive payments, population-based payments and other payments not based on claims submission.

Implementation contractors compute these payments manually. CMMI’s Innovation Payment Contractor (IPC) makes the payments.

Reconcile Benchmark, Settlement

Reconcile actual performance against benchmark.

Implementation contractors complete manually.

Potential solutions have addressed a portion of needs.

CMMI regularly receives concepts from vendors and contractors. Each of these potential solutions has addressed only a portion of the Innovation Center’s need described in the next section. For example, new concepts suggested to the Innovation Center have:

• Focused on ACOs and not considered other model types such as State-based models;

• Suggested capabilities to share Innovation Center data with external entities, but did not address the need to collect data from participants; and

• Interacted with clinical data but did not address the payment functions of models.

CMMI started a pilot of a commercial software product for value-based care models. The pilot set out to prove that a commercial tool could support all innovative models and become a single platform for value-based care programs. Indeed, the product included promising features. However, CMMI stopped the pilot because:

1. The current state of participant data made it difficult to use the product efficiently.

2. The product could not replace enough current systems and processes to produce a Return on Investment.

18 | P a g e

3 Desired Results

Section 3 describes CMMI’s desired results.

Objective 1: Supply Functional Capabilities More Effectively Accomplish a solution that supplies the capabilities described in Table 5. effectively and overcomes the challenges described in Section 2.3.

Table 5. Functional Capabilities

Capabilities Current State Typical Solution

Participant Application & Selection

Collect Letter of Intent Salesforce

Collect Request for Application Salesforce

Allow a participant to simulate the impact of model participation None

Publish Notice of Funding Opportunity & Cooperative Agreement Application

Grants Solutions3

Vet participants (Check provider enrollment and integrity status)

• 4i-to-PECOS Integration (ACO models)

• Send manual file to PECOS (non- ACO models)

• Salesforce-to-PECOS integration in process

Allow secure sign off on documents (e.g., Participant Agreements)

• 4i (ACO models)

• Salesforce e-signature in process

Collect and evaluate bids from MAPD Plans for MAPD models HPMS4 Track secondary agreements (e.g., gainsharing, collaborative care agreements)

Manual

Participant & Beneficiary Tracking

Allow entity to submit provider/participant roster to CMS

• 4i (ACO models)

• ISP - HDR (Non-ACO models)

Manage provider and beneficiary overlap across models. MDM

Track Part C & Part D enrollments for MAPD models MARx5

Compute and share attribution Implementation Contractors6

Identify participants in a mandatory model Implementation Ctrs (IDR or CCW)

3 Grants Solutions appears for context. CMS does not expect the RFI responders to recommend an alternative.

4 HPMS appears for context. CMS does not expect the RFI responders to recommend an alternative.

5 MARx appears for context. CMS does not expect the RFI responders to recommend an alternative.

6 Use of ISP – eDFR to compute attribution for a model is in process.

19 | P a g e

Capabilities Current State Typical Solution

Benchmarks & FFS or MAPD Setup

Compute Benchmark Implementation Ctrs (IDR or CCW)

Share participant list and waiver list with FFS systems

• 4i (ACO models)

• Manual (Non-ACO models)

Process FFS claims FFS Shared Systems & CWF7

Process MAPD encounters MAPD Systems8

Participant Interaction

Collect data

Collect participant reported quality measures (endorsed & non-endorsed)

• ISP – HDR

Collect model-specific metrics from participants

• 4i (ACO models)

• ISP - HDR (Non-ACO models)

Collect clinical data from participants • ISP - HDR

Collect other non-clinical data from participants

• 4i (ACO models)

• ISP - HDR (Non-ACO models)

Collect enhanced demographics data from participants (USCDI compliant)

• ISP: HDR, CDX

Collect social determinants of health data from participants • ISP: HDR, CDX

Collect survey data

• Industry survey instruments

• ISP - HDR

Share data externally

Send raw data to participants such as Claims & Claim Line Feeds (CCLFs)

• 4i (ACO models)

• ISP - eDFR (non-ACO models)

Produce reports & dashboards for participants - based on claims data • ISP: eDFR Produce reports & dashboards for participants - based on clinical/quality data

• ISP: eDFR

Produce reports & dashboards for participants - incorporate third-party data

None

Profile providers to help participants make referrals None

Integrate with EHRs (integrate w/in workflow (e.g., alerts in EMR); send messages in EMR)

None

Integrate with HIEs (to enable multi-payer aggregation) A PCF solution. No Center-wide solution.

Integrate with non-provider organizations (e.g., Community Care Orgs) None

7 FFS claims appear for context. CMS does not expect the RFI responders to recommend an alternative.

8 MAPD encounters appear for context. CMS does not expect the RFI responders to recommend an alternative.

20 | P a g e

Capabilities Current State Typical Solution Offer APIs to participants or a Qualified Health Information Network (QHIN), depending on broader implementation of data sharing under Trusted Exchange Framework and Common Agreement (TEFCA).

BCDA

Monitoring & Internal Functions

Compute claims-based quality measure Implementation Ctrs (IDR or CCW)

Reconcile performance against benchmarks. Complete settlement Implementation Ctrs (IDR or CCW)

Payment

Compute non-claims-based payments and recoupments Implementation Contractors

Make non-claims-based payment IPC Make MAPD capitation payment MAPD9

Make Cooperative Agreement grants payment OAGM’s services10

Evaluation

Collect data from control groups ISP: HDR

Evaluate the model Evaluation Contractors (CCW)

Learning

Enable participant-to-participant learning Salesforce CONNECT

Collect learning event metadata Salesforce

Objective 2: Improve Value-Based Care Computations Accomplish a solution that adds efficiencies to the manual processes that Implementation Contractors now complete manually, including attribution, benchmark, quality measures computation, non-claims-based payment computation.

Objective 3: Provide a Good User Experience Accomplish a solution that reduces barriers to participation and decreases the burden for participants to engage with CMMI in models.

• Maximize the use of interoperable technology and standards to enable provider participants to use their existing EMRs and other technology to interact with CMMI within their normal workflow.

9 MAPD encounters appear for context. CMS does not expect the RFI responders to recommend an alternative.

10 Grants payments appear for context. CMS does not expect the RFI responders to recommend an alternative.

21 | P a g e

• Create a good user experience that maximizes principles from the United States Digital Service’s CIO Playbook.

• Understand what people need.

• Address the whole experience from start to finish.

• Make it simple and intuitive.

Objective 4: Align with Architecture Vision Accomplish a solution that aligns with the CMS Technical Reference Architecture (TRA), the concepts in Section 2.1, and these principles.

• Avoid duplication and maximize reuse across models;

• Use CMS-wide systems whenever possible to satisfy a model requirement;

• Use CMMI-shared services when CMMI must satisfy a model requirement. Where appropriate, take advantage of existing investments;

• Use commercial tools, products, and services when possible; and

• Use health IT standards when possible, to interact with participants.

Objective 5: Improve CMS’ Internal Operations Accomplish a solution that improves CMS’ internal operations by reducing complexity and the fragmentation of data and processes.

CMMI wants any new solution or integration of existing solutions to have the characteristics in in Table 6.

Table 6. Technology, Data, and Model Operations

Solution Characteristics A. Technology Architecture and Operations Uses Health IT standards, including FHIR.

Aligns with CMS’ infrastructure and hosting direction (see Appendix D) Identity management architecture aligns with CMS’ direction (see Appendix D) Data integration architecture align with CMS’ direction.

Offers API to CMS to supply visibility into solution Integrates with CMS’ security direction (see Appendix D) Integrates with CMS’ privacy direction (see Appendix D)

22 | P a g e

Solution Characteristics Integrates with O&M processes and tools B. Data Operations Ability to ingest and work with CMS’ data Robust quality and validation process Accurate, explainable, and reliable computations C. Model Operations Simplify model operations Interacts well with other elements of operations?

Offer transparency to CMS

Any solution that introduces Commercial Off the Shelf (COTS) software or Software as a Service (SaaS) must have a vendor with the characteristics in Table 7.

Table 7. Vendor Characteristics

Vendor Characteristics Financial stability (e.g., strong financial ratios (working capital, quick ratio for liquidity, debt-to-earnings ratio), stable source of funding (internal equity, debt, venture capital) Robust product roadmap Available on Federal acquisition vehicles Efficient licensing arrangement (e.g., modular, scales well) Vendor has a mature implementation approach in environments like CMS Third-party companies are available to implement and integrate the product CMS can self-configure services

23 | P a g e

4 Questions for RFI Responders

1. What should CMS consider for satisfying all the objectives described in Section 3?

• To what degree should CMS reuse existing systems?

• What commercial tools, open-source frameworks, and/or SaaS products should CMS consider?

• To what degree should CMS pursue one IT system to supply all the functional capabilities in Objective 2?

2. What is the most effective way to satisfy Objective 2 (Improve Value Based Care Computations)?

• To what degree should CMS centralize the value-based care computations?

• How can we best satisfy this objective (e.g., tools, platforms)?

3. What new capabilities could technology create that are not described in this RFI document?

CMS recognizes that new capabilities may be possible through technology that are not described in Objective 1, Section 3

5 Instructions for Responders A. Respond to the questions in Section 4. CMS will not return responses or accept responses after the due date. CMS will not share the results of its review with respondents. Information received will be considered solely for CMS’ planning purposes.

B. Please follow this format

• Microsoft Word (or PDF) document with page size 8.5 by 11 inches, with a minimum of 1” margins.

• Calibri Font Size 11 with no less than single spacing between lines.

• Submissions shall not exceed 15 pages.

C. Please provide the following business information in your response:

24 | P a g e o DUNS # o Company Name /Company Address o Current GSA Schedules o Current GWACs o Type of Company

Professional Services Firm, Software Vendor, etc.

NAICS Code o Company Point of Contact, Phone and Email address.

All joint responses should include the above-cited information for each entity on the responding team.

D. Do not include proprietary, classified, confidential, or sensitive information in your response. The Government reserves the right to use any non-proprietary technical information in any resultant solicitation(s).

This RFI does not obligate the Government to award a contract or otherwise pay for the information provided in response. Please submit responses via email to Aaron Blackshire, aaron.blackshire@cms.hhs.gov

POINTS OF CONTACT

Aaron Blackshire, Contracting Officer, aaron.blackshire@cms.hhs.gov

Appendix A – Background Understanding Innovative Models A model is a pilot policy program. A model tests an intervention for a defined set of beneficiaries, providers, conditions, treatments, and/or populations over a prescribed period of performance. CMS monitors models closely and evaluates them to determine if it meets its intended goals. Models that demonstrate the ability to reduce cost and/or improve outcomes are candidates for expansion into Medicare or Medicaid.

CMMI manages a large model portfolio.11 The model portfolio tests new policy concepts throughout the Medicare and Medicaid programs. Major portions of the model portfolio

11 See https://innovation.cms.gov/about/our-team

25 | P a g e include:

1. Seamless Care models that incentivize health care providers to become accountable for a patient population (e.g., Next Generation Accountable Care Organization (ACO), ACO REACH));

2. Primary Care models that strengthen primary care (Comprehensive Primary Care (CPC+), Primary Care First (PCF);

3. Episode-based payment models that hold health care providers accountable for the cost and quality of care beneficiaries receive during an episode of care, which usually begins with a triggering health care event (such as a hospitalization) and extends for a limited period thereafter (include the Bundled Payment for Care Improvement Advanced Initiative (BPCI Advanced) and Coordinated Care for Joint Replacement (CJR) models);

4. Prevention and Population Health models that aim to prevent health problems, delaying the onset of disease, and making families and communities healthier using population health principles (e.g., Accountable Health Communities (AHC) and the Million Hearts Cardiovascular Disease Risk Reduction Model); and

5. State and local models that collaborate with states to develop innovative service delivery and multi-payer payment models that drive health care delivery system transformation (e.g., Maryland Total Cost of Care Model, Pennsylvania Rural Health Model).

The Innovation Center creates Participant Agreement or Cooperative Agreement models.

Participant Agreements modify existing agreements with organizations to describe the requirements for model participation. CMMI uses this Participant Agreement with entities that have existing contractual or provider agreements with CMS (e.g., Primary Care First (PCF))

Cooperative Agreements are alternatives to grants that permit CMMI to fund an entity and retain substantial involvement with the recipient during performance as described by the Federal Grant and Cooperative Agreement Act of 1977, 31 U.S.C. 6301 (e.g., Accountable Health Communities (AHC))

26 | P a g e

CMMI completes a program lifecycle to implement a new model.12 Section 3021 models typically launch within 18-24 months from the planning and design phases.

• The first phase in the lifecycle, known as the Concept phase, identifies potential model ideas. Model teams draft several Concept Papers that are used as the basis for discussion, analysis, refinement, and decision-making. Once a final Concept Paper is approved, the model enters the second phase in the lifecycle, known as the Planning and Design phase.

• During the Planning and Design phase, CMMI designs the model in detail. The model team describes the clinical and financial interventions proposed for the model and how the interventions address problems or opportunities in Medicare or Medicaid. The model team produces an Innovation Center Investment Proposal (ICIP). If the model is mandatory, the model team will also need to go through the notice and comment rulemaking process which can take 5-12 moths.

• The Solicit and Build phase includes clearance, apportionment, solicitations, award, and building of programmatic components of the model based on the design. CMS selects model participants, awards contracts, and prepares IT and learning systems.

• In the Run and Execute phase the model goes “live” and implements the testing of the intervention in the field.

• The Evaluation phase determines the effectiveness of the model’s intervention in meeting the defined cost and quality goals. Evaluation starts in the first year of the model and typically ends approximately 2 years after the model ends. Depending on the results of a separate actuarial and Chief Medical Officer review, CMS may expand the model into Medicare as a permanent benefit or program element.

• The Closing phase is when the model is closed out and/or transitioned to the CMS-owning component.

Model Operations After clearance, models complete the business functions illustrated in Figure 5.

12 This is a program creation lifecycle and not CMS’ systems development lifecycle.

27 | P a g e

Figure 5. CMMI's Business Operations

Manage participants. For many models, the first business process is to publicize the model to the health care industry, invite organizations to participate, and to conduct an application process for interested organizations. The result of this process is a set of organizations with agreements to participate in a voluntary CMMI model. Once the model test starts, CMS communicates with model participants on an ongoing basis.

Operate the model. After making cooperative agreements or participant agreements awards,13 model teams manage the providers, beneficiaries, health plans, or other entities participating in the model. This may include: establishing financial benchmarks; aligning providers to participating entities such as Accountable Care Organizations; collecting clinical, quality measures, or non-clinical data to monitor participants; and supplying feedback reporting to participants.

Payment. CMMI models typically require adjusting payments and making incentive payments to providers, plans, beneficiaries, or other non-provider entities, including:

Adjusting Medicare Fee-for-Service (FFS) claims payments (e.g., introducing a discount on each claims payment to a participating provider; adding a model-specific code to claims, such as a G-code).

Testing full or partial capitation payments or cooperative grants in FFS models

Modifying capitation or risk adjustment payments to Medicare Part C or Part D plans; and

13 These awards are cooperative agreements or participant agreements for model participants and does not refer to award of IT contracts.

28 | P a g e

Calculating and distributing non-claims-based payments to FFS providers and other entities (e.g., incentive payments based on criteria other than FFS claims submission; Per Beneficiary/Per Month payments).

Learning and Diffusion/Knowledge Management. CMMI models create a learning system to spread the best practices and knowledge created by model participants.

Evaluation. To determine if a model accomplishes its intended goals in quality improvement and cost reduction, CMMI conducts a formal evaluation of the model’s results.

Each set of business functions described above uses a different set of systems, services, and data.

Model Teams Model teams are comprised of federal employees with backgrounds in public health administration, clinical specialties, and other specialties such as healthcare and behavioral economics, social sciences, and regulation-writing. A model team typically has three to seven Full Time Equivalents (FTEs). Model teams acquire Implementation Contractors to manage model functions such as payment calculations, benchmarks, and attribution. Model teams typically do not have IT, project management or operational expertise.

The Business Services Group (BSG) delivers the Innovation Center’s mission through operations.

BSG’s services include budget and administrative, acquisition, technology, and payment services.

BSG supplies the IT and other knowledge required to operationalize models.

29 | P a g e

Appendix B – Sample Model IT Solutions and Participant Data Appendix B describes examples of how CMS has implemented operations for innovative models. Each model uses a unique combination of systems and contract. The purpose of this appendix is to illustrate the diversity of model IT solutions.

PCF Model Primary Care First aims to improve quality, improve patient experience of care, and reduce expenditures.

PCF practices interact with several systems and services.

30 | P a g e

Several entities store participant information

31 | P a g e

PCF follows this business process.

Process Facilitated By IT System Used Participant Application & Selection Publish a Letter of Intent and a Request for Application. Collect. Review and score applications, Implementation Contractor Salesforce

Vet participants for program integrity. Implementation Contractor Manual task with CPI

Sign participant agreements. Implementation Contractor/4i team 4i/ACO-OS

Operations: Participant and Beneficiary Tracking Attribute beneficiaries to participants. Implementation Contractor MDM, CCW

Manage beneficiary and provider/participant overlaps with other models. Load participant list data to a database

Implementation Contractor

Internal Implementation Contractor File/System?

MDM

Operations: Benchmarks and FFS Establish benchmarks for model participants. Implementation Contractor CCW

Inform Medicare FFS of participants waived from rules Implementation Contractor Internal Implementation Contractor File/System?

Process claims and apply PCF rules MACs FFS Shared Systems

Operations: Participant Interaction

Collect practice reported data (e.g., provider roster) Implementation Contractor/RF team

Reusable Framework “PCF Practice Portal”

Collect electronic quality measures. CCSQ QPP/MIPS

Supply operational reports to participants (e.g., attribution list)

Implementation Contractor/RF team

RF - “PCF Practice Portal” (RTI posts reports for participants to Practice

32 | P a g e

Process Facilitated By IT System Used Portal)

Produce and send feedback reports for model participants. ISP eDFR

Produces claims data feeds (CCLF) for model participants

Implementation Contractor/4i team 4i/ACO-OS

Supply customer service/support to model participants. CBOSC CBOSC

Operations: Internal Functions

Send participant data to AMS Implementation Contractor/MDM AMS

Send participant information to QPP for eligibility and scoring. AMS Team AMS

Monitor the model. Implementation Contractor Reusable Framework/4i/ACO-OS, CCW

Reconcile (settlement) performance against a benchmark. Implementation Contractor Internal Implementation

Contractor File/System?

Compute claims-based quality measures. Implementation Contractor CCW Payment Compute non-claims-based payments (e.g., performance). Implementation Contractor Internal Implementation

Contractor File/System?

Makes non-claims-based payments (e.g., performance). IPC Team IPC

Recoup payments IPC Team IPC Learning and Diffusion

Enable participant-to-participant collaboration. Learning Contractor SALESFORCE - CONNECT

33 | P a g e

PCF has this set of system and contractor interactions.

34 | P a g e

Kidney Care Choices Model The Kidney Care Choices (KCC) Models are voluntary payment models aimed at reducing the cost and improving the quality and of care for Medicare beneficiaries with late-stage chronic kidney disease (CKD), end stage renal disease (ESRD), and kidney transplants over a 2020-2025 testing period.

Table 8. Basic KCC Functions

Process Facilitated By IT System Used System or Contract Owner

Participant Application & Selection Publish a Letter of Intent and a Request for Application. Collect.

Review and score applications.

CMMI Staff Qualtrics Office of Communications (OC)

Vet participants for program integrity. Implementation Contractor/RELI

Manual task with OnePI/Westlaw

Center for Program Integrity (CPI)

Sign participant agreements.

Implementation Contractor/4i team

4i/ACO-OS OIT

Operations: Participant and Beneficiary Tracking

Attribute beneficiaries to participants.

Implementation Contractor/PAC

(AIR)

MDM/IDR/FFS OIT

Manage beneficiary and provider/participant overlaps with other models. Load participant list data to a database

Implementation Contractor (list) /PAC (AIR)/4i team (data transmission to

MDM)

ACO-OS (Source)

MDM (CMMI Central Repository)

OIT

Operations: Benchmarks and FFS Establish benchmarks for model participants.

CMMI

Staff/Implementa IDR OIT

35 | P a g e tion Contractor/PAC

(AIR)

Inform Medicare FFS of participants waived from rules

Implementation Contractor/4i team

ACO-OS OIT

Process claims and apply model rules MACs FFS Shared Systems OIT

Operations: Participant Interaction

Collect participant reported data Implementation Contractor/IDDO C

4i OIT

Collect electronic quality measures.

Implementation Contractor/PAC

(AIR)

HDR BSG

Supply operational reports to participants (e.g., attribution list)

Implementation Contractor/PAC

(AIR)

4i OIT

Produce and send feedback reports for model participants.

Learning Diffusion Group Qualtrics OC

Produces claims data feeds (CCLF) for model participants

Implementation Contractor/4i team

4i/ACO-OS OIT

Supply customer service/support to model participants. CBOSC/Telligen CBOSC BSG

Engage in a secure participant file/data exchange

Implementation Contractor/IDDO C

4i OIT

Operations: Internal Functions

Send participant data to AMS 4i Team ACO-OS OIT

36 | P a g e

Send participant information to QPP for eligibility and scoring. AMS Team AMS AMS

Use CMS Data to monitor the model.

Implementation Contractor/4i Team

4i/ACO-OS, IDR OIT

Reconcile (settlement) performance against a benchmark.

Implementation Contractor/PAC

(AIR)

Internal Implementation Contractor File/System?

Compute claims-based quality measures.

Implementation Contractor/PAC

(AIR)

4i/ACO-OS, IDR, MDM, FFS OIT

Payment

Compute non-claims-based payments (e.g., performance).

Implementation Contractor/ Insignia

Insignia Model Team

Makes non-claims-based payments (e.g., performance). IPC Team IPC BSG

Recoup payments IPC Team IPC BSG Learning and Diffusion

Enable participant-to-participant collaboration.

Learning Contractor Mathematica

LDG

37 | P a g e

ET3 Model Emergency Triage, Treat, and Transport (ET3) is a voluntary, five-year payment model. The model provides greater flexibility to ambulance care teams to address emergency health care needs of Medicare Fee-for-Service (FFS) beneficiaries after a 911 call. CMS will continue to pay to transport a Medicare FFS beneficiary to a hospital emergency department or other covered destination. In addition, CMS will pay participants to 1) transport to an alternative destination partner, such as a primary care office, urgent care clinic, or a community mental health center (CMHC); or 2) initiate and facilitate treatment in place with a qualified health care partner, either at the scene of the 911 emergency response or via telehealth.

Table 9. describes the basic functions of the ET3 model.

Table 9. Basic ET3 Functions

Function Operational Element Owner Participants

Offer a participant help desk Centralized Business Operations Center (CBOSC)

BSG (task order on an

OIT IDIQ)

Collect letters of intent. Collect applications through Request for Application

Salesforce BSG

Vet participants for program integrity

PECOS (Implementation Contractor sends manual file)

CPI

Sign participant agreements Manual Model Team Setup vendors for data submissions. Setup API Keys

Centralized Data Exchange (CDX) BSG

FFS Payment

Give participant list and waivers to FFS ops

Implementation Contractor to Medicare Administrative Contractors (MAC) and Shared System Maintainers SSM)

Model Implementation Contractor

Apply ET3 model rules when processing claims

MAC and SSM CM

38 | P a g e

Function Operational Element Owner Participant Interaction

Collect Patient Care Reports from Emergency Medical Services (EMS) Vendors

CDX BSG

Produce operational reports ET3 Business Intelligence Reporting BSG Interact with participants to manage operations

Reusable Framework BSG

Assessment

Monitor model progress and outcomes

Implementation Contractors use Integrated Data Repository (IDR)

OIT

Evaluate the model Evaluation Contractors use Chronic Conditions Warehouse (CCW)

OEDA

Figure 6. illustrates the unique data collection for the ET3 model.

39 | P a g e

40 | P a g e

Figure 6. ET3 Unique Data Collection

41 | P a g e

Comparison Table 10. compares the operational implementation of several models.

Table 10. Operational Comparison of Models

Operations Functions

Process Process requires Participant List?

PCF ACO REACH KCC BPCI A

Participant Application and Selection

Publish a Letter of Intent and a Request for Application. Collect.

Review and score applications

Salesforce Qualtrics Qualtrics Salesforce

Participant Application and Selection

Vet participants (with CPI) for program integrity

Yes Manual Task – Impl.

Contractor

Manual Task – Impl. Contractor

Manual Task – Impl. Contractor

Vet participants using Salesforce data and send to

CPI

Participant Application and Selection

Send participant list to implementation contractor

Yes Salesforce Qualtrics Qualtrics Salesforce

Participant Application and Selection

Sign Co-Op or Participant Agreement

Yes 4i 4i/ACO-OS 4i/ACO-OS Salesforce

Participant Application and Selection

Manage project officer interaction with participants & participant mngt. functions

N/A N/A

Operations:

Participant and Beneficiary Tracking

Check for overlap, attribute beneficiaries to participants, load result to database

Yes MDM, CCW MDM MDM MDM

42 | P a g e

Operations Functions

Process Process requires Participant List?

PCF ACO REACH KCC BPCI A

Operations:

Participant and Beneficiary Tracking

Attribute providers to model/manage overlaps

Yes Implementation contractor

Implementation contractor

Implementation contractor

Implementation contractor

Operations:

Participant and Beneficiary Tracking

Identify participants that are in a mandatory model

N/A N/A

Operations:

Participant and Beneficiary Tracking

Load data to MDM Yes Implementation contractor

4i/ACO-OS 4i/ACO-OS Implementation contractor

Operations:

Benchmarks and FFS

Establish benchmark with participants

Yes Implementation contractor uses

CCW

Implementation contractor uses

IDR

Implementation contractor uses

IDR

CWF

Operations:

Benchmarks and FFS

Implementation Contractor sends list of participants waived from FFS rules (inform FFS about participants waivers)

Yes Implementation…