The file's text, extracted by GovTribe without its formatting.
Centers for Medicare & Medicaid Services Center for Program Integrity (CPI)
Unified Case Management (UCM) System UCM 1.0 Functional Requirements Document (FRD) Version 1.1 07/13/2015 Document Number: 0001 Contract Number:
Exhibit E.5 HHSM-500-2015-RFP-0122 UPIC
Table of Contents
| List of Figures | iii | |
| List of Tables | iv | |
| 1. | Introduction | 5 |
| 1.1 | Purpose | 5 |
| 1.2 | Document Management | 5 |
| 1.3 | Intended Audience | 5 |
| 2. | Overview | 6 |
| 2.1 | Business Purpose | 6 |
| 2.1 | Functional Purpose | 6 |
| 2.2 | Measures of Success | 6 |
| 2.3 | Stakeholders | 7 |
| 2.4 | Project Priorities | 10 |
| 2.5 | Business Terminology | 10 |
| 2.6 | Project Diagrams | 12 |
| 2.6.1 | System Context Diagram | 12 |
| 2.6.2 | UCM Record Types Business Context | 14 |
| 3. | Assumptions/Constraints/Risks | 16 |
| 3.1 | Assumptions | 16 |
| 3.2 | Constraints | 17 |
| 3.3 | Risks | 17 |
| 4. | UCM Functional Requirements | 17 |
| 4.1 | Lead Management | 17 |
| 4.1.1 | Lead Creation | 19 |
| 4.1.2 | Immediate Advisement | 46 |
| 4.1.3 | Linkable Cases (Record Types) | 49 |
| 4.1.4 | Automatic System Check | 57 |
| 4.1.5 | Manual System Check | 63 |
| 4.1.6 | Non-Actionable Leads | 67 |
| 4.1.7 | Work Assignment | 70 |
| 4.2 | Investigations | 86 |
| 4.2.1 | Lead Validation | 90 |
| 4.2.2 | Additional Case Search | 94 |
| 4.2.3 | Plan of Action | 97 |
| 4.2.4 | Interview | 102 |
| 4.2.5 | On-Site Visit | 107 |
| 4.2.6 | Site Verification | 113 |
| 4.2.7 | Background Check | 117 |
| 4.2.8 | Check Medicaid Data | 120 |
| 4.2.9 | Request Information from External Partners | 123 |
| 4.2.10 | Provide Education | 126 |
| 4.2.11 | Desk Level Data Analysis | 129 |
| 4.2.12 | Desk Level Medical Review | 132 |
| 4.2.13 | Close Investigation | 135 |
| 4.3 | Additional Record Types | 137 |
| 4.3.1 | Request for Information (RFI) | 137 |
| 4.3.2 | Request for Assistance (RFA) | 146 |
| 4.3.3 | Proactive Data Project | 155 |
| 4.3.4 | FPS ASR | 162 |
| 4.3.5 | Referrals | 167 |
| 4.4 | Additional UCM Functionality | 179 |
| 4.4.1 | Search for Cases and Information | 179 |
| 4.4.2 | Document Management | 183 |
| 4.4.3 | Notifications and Alerts | 189 |
| 4.4.4 | Auditing | 191 |
| 4.4.5 | Systems Administration | 191 |
| 4.4.6 | Social Collaboration (optional) | 192 |
| 4.4.7 | Form Letters (optional) | 192 |
| 4.4.8 | Data Migration | 194 |
| 4.4.9 | Records Management | 194 |
| 4.4.10 | Archiving Requirements | 195 |
| 4.4.11 | System Capabilities | 195 |
| 4.4.12 | User Roles | 200 |
| 5. | Administrative Actions Functional Requirements | 207 |
| 5.1 | Administrative Actions | 207 |
| 5.1.1 | General Administrative Actions Requirements | 207 |
| 5.1.2 | Administrative Action: Auto-Denial Edits | 210 |
| 5.1.3 | Administrative Action: Pre-Payment Edits | 218 |
| 5.1.4 | Administrative Action: Overpayments | 224 |
| 5.1.5 | Administrative Action: Post-Payment Review | 233 |
| 5.1.6 | Administrative Action: Medical Review (UCM 1.0) | 238 |
| 5.1.7 | Administrative Action: Corrective Action Plan (CAP) | 244 |
| 5.1.8 | Administrative Action: Reconsideration Request | 252 |
| 5.1.9 | Administrative Action: Payment Suspension - Initiation | 259 |
| 5.1.10 | Administrative Action: Payment Suspension - Extension | 266 |
| 5.1.11 | Administrative Action: Payment Suspension - Rebuttal | 270 |
| 5.1.12 | Administrative Action: Payment Suspension - Termination | 275 |
| 5.1.13 | Administrative Action: Revocation | 285 |
| 5.1.14 | Administrative Action: Deactivation | 294 |
| 5.1.15 | Administrative Action: Incentive Rewards Program (IRP) | 303 |
| 5.1.16 | Administrative Action: TBD | 309 |
| 6. | UCM Non- Functional Requirements | 314 |
| 6.1 | Security and Privacy Controls | 314 |
| 6.2 | Freedom of Information Act (FOIA) | 317 |
| 6.3 | Accessibility | 319 |
| 6.4 | Reliability (Backups, Redundancy, Downtime, Failovers) | 324 |
| 6.5 | System Monitoring | 325 |
| 6.6 | UCM System Performance Service Level Agreements (SLAs) | 325 |
| 6.7 | Performance Metrics | 330 |
| 7. | UCM Supporting Functions | 331 |
| 7.1 | Dashboard Requirements | 331 |
| 7.2 | Ad-Hoc Reporting Requirements | 333 |
| 7.3 | Standard Reporting Requirements | 335 |
| Appendix A: | Acronyms | 357 |
| Appendix B: | UCM Screen Mock-ups | 360 |
| | List of Figures |
| Figure 21 UCM ‘To-Be’ System Context Diagram | 13 | |
| Figure 41 Lead Management Business Context | 17 | |
| Figure 42 Investigations Business Context | 87 | |
| Figure 4.245 Site Verification ‘To-Be’ Process Flow | 113 | |
| Figure 46 Request for Information (RFI) ‘To-Be’ Process Flow | 138 | |
| Figure 47 Request for Assistance (RFA) ‘To-Be’ Process Flow | 147 | |
| Figure 48 Search ‘To-Be’ Process Flow | 179 | |
| Figure 49 Document Management ‘To-Be’ Process Flow | 184 | |
| Figure 51 Auto-Denial Edits ‘To-Be’ Process Flow | 210 | |
| Figure 52 Pre-Payment Edits ‘To-Be’ Process Flow | 218 | |
| Figure 53 Overpayments ‘To-Be’ Process Flow | 226 | |
| Figure 54 Post-Payment Review ‘To-Be’ Process Flow | 234 | |
| Figure 55 Medical Review (UCM 1.0) ‘To-Be’ Process Flow | 240 | |
| Figure 56 Corrective Action Plan (CAP) ‘To-Be’ Process Flow | 244 | |
| Figure 57 Reconsideration Request ‘To-Be’ Process Flow | 252 | |
| Figure 58 Payment Suspension (Initiation) ‘To-Be’ Process Flow | 260 | |
| Figure 59 Payment Suspension (Extension) ‘To-Be’ Process Flow | 266 | |
| Figure 510 Payment Suspension (Rebuttal) ‘To-Be’ Process Flow | 271 | |
| Figure 511 Revocation ‘To-Be’ Process Flow | 286 | |
| Figure 512 Incentive Rewards Program (IRP) ‘To-Be’ Process Flow | 304 | |
List of Tables
| Table 2.41 System Stakeholders | 7 |
| Table 2.51 Project Priorities | 10 |
| Table 2.61 Business Terminology | 10 |
| Table 3.31 Probability Ratings | 17 |
| Table 2 Linkable Record Type Search Data Table | 53 |
| Table 3 Linkable Record Types Search Results Data Table | 54 |
| Table 4 On-Site Visit Data Table | 110 |
| Table 5 Site Verification Data | 115 |
| Table 6 Request for Information Data | 142 |
| Table 7 Request for Assistance Data | 151 |
| Table 8 Proactive Data Project Data Table | 160 |
| Table 9 Referral Sent Data Table | 171 |
| Table 10 Referrals Accepted Data Table | 174 |
| Table Appendix B 7.32 | 357 |
Introduction
UCM 1.0 Functional Requirements Document (FRD) - Version 1.1 260 Unified Case Management (UCM) System
Introduction This document has been developed to define the requirements of the Unified Case Management (UCM) system and associated operational services to support the workload of the Centers for Medicare & Medicaid Services (CMS) Center for Program Integrity (CPI) contractors across the Medicare and Medicaid programs.
The implementation of a UCM system aligns with the organizational goal to support cooperation and communication between regional Program Integrity (PI) contractors to ensure a standardized national approach to lead management, investigations, administrative actions and workload reporting. The UCM project aligns with CPI’s business goals.
By investing in a UCM system that supports this strategy, CMS expects a range of benefits, including accurate reporting, increased contractor oversight and management, and increased efficiency by integrating with other CMS systems.
Purpose This document provides the Medicare and Medi-Medi functional and non-functional requirements for implementation within the UCM system. This document lists the business requirements, business rules, user requirements, and functional/nonfunctional requirements for the project, herein collectively referred to as “requirements”. It also contains the supporting process flows, process narratives, data elements, and reporting mockups.
This document is for Phase One of the UCM implementation and the subject matter specified in this document will be supplemented with other requirement documents for future phases. In this document, there are functional and non-functional requirements. From a business owner’s perspective, a functional requirement describes what the software system should do, while non-functional requirements place constraints on how the system will do so.
Document Management The requirements included in this document shall be traced back to the appropriate sections within the statement of work and forwarded into design, development and testing phases to ensure that all requirements are properly implemented, tested, and approved by CPI stakeholders.
Intended Audience The target audience includes all business, technical, governance and project management stakeholders.
Overview The implementation of the UCM system aligns with the organizational goal to support cooperation and communication between regional PI contractors to ensure a standardized national approach to how lead management, investigations, administrative actions, and workload reporting will be managed within UCM. The UCM system goals align with CPI’s business goals to:
· Maintain a central repository to track leads containing all contractor workload reporting, dashboards to monitor progress, and outcome measure calculations
· Establish transparency in Medicaid and Medicare analysis, audits, and investigations workload, prioritization, and outcomes by facilitating the sharing of information across States, programs, and CMS contractors as appropriate Reduce the number of systems that require input from contractors and CMS
· Strengthen national level oversight of contractor work through rapid, and accurate flow of information Business Purpose The purpose of the UCM system is to improve prevention and detection of fraud, waste and abuse in Medicare and Medicaid program spending. By investing in a UCM system that supports CMS’s strategy, CMS expects a range of benefits, including cost savings in operational IT infrastructure, and improved cost recovery from administrative actions. The UCM system will improve and enhance the management and oversight of the program integrity contractors, resulting in benefits across all areas of PI. This enhancement will provide direct and transparent access to the program integrity workflow, as well as promote coordination and efficiency across the lifecycle of a case, again resulting in an increase in return on investment and potential cost savings from achieving economies of scale.
0. Functional Purpose The functionality of the UCM system will be implemented by analyzing and reviewing current systems used by CMS contractors. Several information management systems currently support CMS PI activities by tracking investigations and the workload of PI contractors who investigate allegations of suspected fraud, waste, or abuse (FWA). In the current environment, a number of PI contractors maintain their own standalone proprietary case tracking systems to track their workload and produce reports. Current tracking systems include contractor-owned and operated systems, and three CMS-owned/contractor-operated systems—the CMS Analysis, Reporting, and Tracking System (CMSARTS); Fraud Investigation Database (FID); and Work Flow Management System (WFMS).
Measures of Success All requirements listed are included and fully functional in the UCM system based on the phased prioritization agreed upon by CPI Executive Stakeholders. The measure of success will be a fully functional system with the capability to execute all requirements listed in this document. All requirements should have full functionality as stated and discussed with stakeholders for the business needs of the system.
Stakeholders A stakeholder in the architecture of the UCM system is an individual, team, organization, or classes thereof, having an interest in the realization of the system. Stakeholders in the below table provide an adequate representation across the board, including nontechnology stakeholders (such as acquirers and users) and technology focused one.
Table 2.31 System Stakeholders
| 1-800-Medicare Beneficiary Contact Center (BCC) |
| BCC provides a central point of contact for Medicare Beneficiaries and their caregivers with scripted responses on coverage information, healthcare choices, claims, and preventive services. |
| Assistant United States Attorney (AUSA) |
| U.S. attorneys and their assistant attorneys serve as the principal federal litigators under the U.S. attorney general. AUSA is part of the Medicare Fraud Strike Force to help prevent and combat health care fraud, waste, and abuse. |
| Audit Medicaid Integrity Contractors (MICs) |
| MICs’ team of auditors, medical claims reviewers, and data analysts review and analyze claims submitted by all types of Medicaid providers to identify aberrant claims and potential billing vulnerabilities. The Audit MIC’s also identify Medicaid overpayments and refer them to state for recovery. The Audit MICs also identify Medicaid overpayments and refer them to the state for recovery. |
| Beneficiaries |
| Beneficiaries are people who receive healthcare services that are financially supported by a Medicare, Medicaid, and CHIP. |
| CMS Center for Program Integrity (CPI) |
| Business owner of the UCM system. |
| CMS Regional Offices |
| CMS has ten Regional Offices (ROs) reorganized in a Consortia structure based on the Agency's key lines of business: Medicare Health Plans Operations, Financial Management and Fee For Service Operations, Medicaid and Children's Health Operations, and Quality Improvement and Survey & Certification Operations. |
| Department of Justice (DOJ) |
| The DOJ’s mission is to enforce the law and defend the interests of the United States according to the law; to ensure public safety against threats foreign and domestic; to provide federal leadership in preventing and controlling crime; to seek just punishment for those guilty of unlawful behavior; and to ensure fair and impartial administration of justice for all Americans. DOJ is part of the Medicare Fraud Strike Force to help prevent and combat health care fraud, waste, and abuse. |
| Federal Bureau of Investigations (FBI) |
| The FBI is an agency that supports exposing and investigating Federal healthcare fraud, with jurisdiction over both federal and private insurance programs. It seeks to identify and pursue investigations against the most egregious offenders involved in health care fraud through investigative partnerships with federal, State, and local agencies, as well as its relationships with private insurance national groups, associations, and investigative units. Its field offices proactively target fraud through coordinated initiatives, task forces and strike teams, and undercover operations. FBI is part of the Medicare Fraud Strike Force to help prevent and combat health care fraud, waste, and abuse. It should be noted that The Office of Inspector General (OIG) is the primary agency exposing and investigating Federal healthcare fraud for CMS. |
| Government Accountability Office (GAO) |
| The GAO supports congressional oversight by auditing agency operations to determine whether federal funds are being spent efficiently and effectively; investigating allegations of illegal and improper activities; reporting on how well government programs and policies are meeting their objectives; performing policy analyses and outlining options for congressional consideration; and issuing legal decisions and opinions. |
| HHS Office of the Inspector General (OIG) |
| HHS OIG is the largest inspector general's office in the Federal Government dedicated to combating fraud, waste and abuse and to improving the efficiency of HHS programs. A majority of OIG's resources goes toward the oversight of Medicare and Medicaid. OIG is part of the Medicare Fraud Strike Force to help prevent and combat health care fraud, waste, and abuse. |
| Medicaid Fraud Control Units (MFCU) |
| The MFCUs are Federal and State-funded law enforcement entities that investigate and prosecute provider fraud and violations of State law pertaining to fraud in the administration of the Medicaid program. MFCUs operate in every State except North Dakota. The MFCU also investigates allegations of abuse of Medicaid beneficiaries. |
| Medicare Administrative Contractors (MAC) |
| MACs serve as the primary operational contact between the Medicare Fee-For-Service program, and approximately 1.5 million health care providers enrolled in the program. MACs enroll health care providers in the Medicare program and educate providers on Medicare billing requirements, in addition to answering provider and beneficiary inquiries. On a day to day basis, the MACs process Medicare FFS claims, implement administrative actions requested by ZPICs/PSCs, and manage a workload of actions for CMS. |
| National Benefit Integrity Medicare Drug Integrity Contractor (NBIMEDIC) |
| The National Benefit Integrity Medicare Drug Integrity contractor provides oversight and investigates allegations of fraud, waste or abuse in the Medicare Parts C and D programs. |
| Medicare-Medicaid Data Match program partners |
| The Medicare-Medicaid Data Match program (Medi-Medi program) enables Program Safeguard Contractors (PSC), Zone Program Integrity Contractors (ZPIC), and participating State and Federal Government agencies to collaboratively analyze billing trends across the Medicare and Medicaid programs to identify potential fraud, waste, and abuse. Participation is optional. |
| Office of Financial Management (OFM) |
| OFM serves as the Chief Financial Officer and Comptroller for CMS. OFM performs CMS' debt management activities (e.g., accounts receivable, user fees, penalties, disallowances), performs provider profiling, works with Medicare Administrative Contractors through JOAs, manages the Medicare financial management system, and reconciles all CMS financial data including all administrative actions that will be captured within UCM. In addition, OFM does several other activities for CMS including performing CMS’ debt management activities, cash management activities, and reconciles all CMS financial data and prepares external reports. |
| Office of Technology Solutions (OTS) |
| OTS assists CPI in managing the UCM System solution through the CMS system lifecycle and provides oversight of the system conformance with CMS enterprise standards |
| Program Safeguard Contractors (PSCs) |
| The PSC is a contractor dedicated to Medicare program integrity that handles such functions as, Medical review and potential fraud and abuse investigations consolidated into a single contract. They are being replaced with Zone Program Integrity Contractors (ZPICs). |
| Providers |
| Providers are healthcare professionals or associated entities who provide healthcare services to beneficiaries. In this document, all references to providers includes suppliers. |
| Qualified Independent Contractors (QIC) |
| QIC performs reconsiderations of appeals. |
| Quality Improvement Organizations (QIO) |
| A QIO is a group of health quality experts, clinicians, and consumers organized to improve the care delivered to people with Medicare. QIOs work under the direction of CMS to assist Medicare providers with quality improvement and to review quality concerns for the protection of beneficiaries and the Medicare Trust Fund. |
| Recovery Auditors (RAs) |
| The Recovery Auditors identify and correct Medicare improper payments through the efficient detection and collection of overpayments made on claims of health care services provided to Medicare beneficiaries, and the identification of underpayments to providers so that the CMS can implement actions that will prevent future improper payments in all 50 states. There are also Medicaid RAs. |
| State Licensing Board |
| Each state has their own licensing board for clinicians and clinician specialties that practice (prescribe and or diagnose) within the state. Clinicians become licensed to practice medicine. These boards regulate and enforce the licenses of various clinicians and specialty clinicians. Clinicians require a license in order to practice medicine and must adhere to the state regulations and standards of care. |
| State Medicaid Agencies |
| State Medicaid Agencies administer the Medicaid State program. There are also State PI units that may be operating outside of the Medicaid Agency such as the NYS Office of the Medicaid Inspector General (OMIG) or the NJ Office of the State Comptroller Medicaid Fraud Division (MFD). If a State PI unit operating outside of the SMA must be recognized as a stakeholder. |
| Unified Program Integrity Contractors (UPIC) |
| CMS currently relies on a network of various Contractors to carryout program integrity work in Medicare and Medicaid. The Zone Program Integrity Contractors (ZPICs) and Program Safeguard Contractors (PSCs) are under contract to perform Medicare program integrity functions. The Medicare-Medicaid Data Match (Medi-Medi) program is incorporated under the ZPIC scope of work to conduct Medi-Medi activities including matching Medicare and Medicaid data and investigating potential instances of fraud, waste, and abuse. This is also incorporated in the PSC scope of work. The Medicaid Integrity Contractors (MICs) are under contract to perform Medicaid program integrity functions. The UPIC seeks to consolidate various program integrity functions and contractors that are separate and distinct by contract into one unified contractor that encompasses all of Medicare, Medi-Medi and Medicaid program integrity work. There will be a predefined number of UPICs that perform these functions within a defined geographic areas on behalf of CMS. The entities awarded these contract(s) will be referred to as UPICs. |
| Zone Program Integrity Contractors (ZPIC) |
| CMS currently relies on a network of Contractors to carryout program integrity work in Medicare and Medicaid. The Zone Program Integrity Contractors (ZPICs)) are under contract to perform Medicare program integrity functions. The Medicare-Medicaid Data Match (Medi-Medi) program is incorporated under the ZPIC scope of work to conduct Medi-Medi activities including matching Medicare and Medicaid data and investigating potential instances of fraud, waste, and abuse. |
Project Priorities There is always an inherent conflict between scope, budget, and schedule. The following project priorities have been established by CMS to help the project prioritize requirements.
Table 2.41 Project Priorities
| Product Quality Dimension |
| Priority Level (High, Medium, Low) |
| Resources (manpower, budget) |
| Medium |
| Nice-To-Have/Cosmetic |
| Low |
Business Terminology The table below describes the business terms used in this document. These terms were identified during the requirements gathering phase, reviewed with stakeholders, and approved for consistency.
Table 2.51 Business Terminology
| Term |
| Definition/UCM Interpretation |
| Additional Document Request (ADR) |
| A letter used by PICs and other stakeholders to request medical record documents from providers/suppliers. The data elements of this template are built into UCM Administration Actions where appropriate. |
| Business Requirement (BR) |
| A BR is a statement of the functions needed in order to accomplish the business objectives. It is the highest level of requirement, developed through the dictation of policy and process by the business owner. |
| Business Rule (RU) |
| An RU is a statement that defines or constrains some aspect of the business. It is intended to assert business structure, or to control or influence the behavior of the business. The RUs that concern the project are atomic in that they cannot be further decomposed and they are not process-dependent, so that they apply at all times. Business rules typically fall into one of five categories: terms, facts, derivations, assertions or action enablers. |
| Case |
| UCM case is the overall investigative record within UCM and is inclusive of the entire UCM case lifecycle from lead management to investigation. From the investigative activities that occur within a UCM case, additional actions may be implemented and tracked (e.g., Administrative Actions/Referrals to Law Enforcement). |
| Data Analytics (Complex vs. Desk Level) |
| In support of investigative activities or administrative actions, a statistician may perform Complex Data Analysis outside of the UCM system. UCM will support the development, tasking, and tracking of this analysis. An investigator may also perform Desk Level data analytics. |
| Education |
| Education is any information, policies, assistance, or training provided to any provider. The education is any type of notification, letter, or training with a goal of changing or improving the providers claim practices. The goal of provider education is to reduce payment error by identifying and addressing billing errors concerning coverage and coding made by providers. |
| Functional Requirement (FR) |
| An FR is a statement of an action or expectation of what the system will take or do. It is measured by concrete means like data values, decision making logic and algorithms. |
| Linking |
| Linking is the creation of a relationship between one case and another case. This allows the user to see the details of a case with easy visibility to a related case. |
| Medical (Records) Review |
| Medical review is the collection of information and clinical review of medical records by Medicare contractors to ensure that payment is made only for services that meet all Medicare coverage, coding, and medical necessity requirements. UCM supports two types of medical review: desk level (performed by investigators or analysts) and complex (performed by clinicians which include nurses and doctors). |
| Nonfunctional Requirement (NR) |
| An NR is a low-level requirement that focuses on the specific characteristics that must be addressed in order to be acceptable as an end product. NRs have a focus on messaging, security, and system interaction. |
| Priority |
| Priority is what determines what activity, task, or condition takes precedence or proceeds before others. UCM indicates priority via numerical ranking throughout the system. It will allow the user to identify which cases rank higher or lower in priority for workload management. |
| Provider |
| A provider is any hospital, clinic, health care professional, supplier, vender, or group who provides service to patients or customers for Medicare or Medicaid services. Also included are individuals who provide personal care to Medicaid recipients. These individuals are not required to have NPIs. |
| Record Type |
| UCM will allow users the ability to track and document activities that are in support of a main case (lead + investigation). These activities may include: Medical Review, Administrative Actions, Proactive Data Analysis, or Referrals to Law Enforcement. These activities, including the case, are considered unique Record Types within UCM. Each record type within UCM will have its own supporting associated data elements, work queues, business rules, and system life cycle. |
| Request for Assistance (RFA) |
| Request for Assistance (RFI) is a request for assistance received from any External Partner (e.g., OIG/ FBI/ State/MAC/CMS). |
| Request for Information (RFI) |
| Request for Information (RFI) is a request for information received from any External Partner (e.g., OIG/ FBI/ State/MAC/CMS). |
| Scenario |
| A scenario is a sequence of steps taken to complete a user requirement, similar to a use case. |
| UCM 1.0 |
| UCM 1.0 refers to the initial implementation/Go-Live of the Unified Case Management system to support CMS and PI contractor activities to prevent improper payments and fraud waste and abuse within the Medicare and Medicaid programs. |
| Use Case |
| A use case is a description of a system’s behavior as it responds to a request that originates from outside of that system. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. The use case should contain all system activities that have significance to the users. Use cases typically avoid technical jargon, preferring instead the language of the subject matter expert. |
| User Requirement (UR) |
| A UR is a statement of what users need to accomplish. It is a mid-level requirement describing specific operations for a user (e.g., a business user, system administrator, or the system itself). They are usually written in the user’s language and define what the user expects from the end product. |
Project Diagrams
System Context Diagram UCM will interact with multiple systems owned by multiple stakeholders. The ‘To-Be’ integration approach and implementation phases are depicted below in Figure 2.7.1.
Figure 21 UCM ‘To-Be’ System Context Diagram
UCM Record Types Business Context UCM will allow users the ability to track and document activities that are in support of a UCM case (lead + investigation). There are additional activities that can occur alongside, prior to, or after the UCM case. For example, FPS ASRs (Fraud Prevention System Alert Summary Report), and Proactive Data Projects (Data analytical projects conducted by contractors to discover leads), are data analysis based on lead generating activities. These activities generate leads upon which a UCM case is built. As another example, A UCM case can create referrals, complex medical reviews, complex data analysis, as well as administrative actions during the course of its lifecycle.
These activities, or modules of functionality, are called Record Types within UCM. A UCM case is one of many record types within UCM. Each record type within UCM will have its own supporting associated user roles, data elements, work queues, business rules, and the system life cycle.
Table 2.7.2 Record Types in UCM
| 1 |
| UCM Case |
| 11 |
| Post Payment Review |
| 2 |
| Complex Medical Review |
| 12 |
| Overpayment |
| 3 |
| Referrals |
| 13 |
| Revocation |
| 4 |
| FPS ASRs |
| 14 |
| Corrective Action Plan |
| 5 |
| Request for Information |
| 15 |
| Payment Suspension |
| 6 |
| Request for Assistance |
| 16 |
| Deactivation |
| 7 |
| Complex Data Analysis |
| 17 |
| Reconsideration Request |
| 8 |
| Proactive Data Projects |
| 18 |
| 9 |
| Auto-denial Parameters |
| 19 |
Figure 2.7.2 UCM Record Types
Assumptions/Constraints/Risks Assumptions The list below details the assumptions identified and made during requirements gathering and development.
1. UCM will use CMS Enterprise Identity Management (EIDM) for identity and access management to all IT environments.
2. UCM will be hosted in the CMS VDC environment.
3. The hardware and software configurations will be documented, including build specifications that are required to support its application in compliance with CMS TRA standards and security policies in a CMS-furnished data center environment.
4. UCM will be developed in a government-furnished development environment and configured to integrate with the government-furnished facilities, data centers, and tools.
5. UCM will support receiving information and data through integration with the CMS FPS system at the time of its initial release to production. A future enhancement will include the receipt of data from FPS and UCM providing data to FPS through bi-directional integration, which is dependent on FPS 2.0 implementation. UCM will replace FID, WFMS and the CMS ARTS for workload functions. The UCM system integration will be defined in the Systems Integration Plan and Systems Design Documents, which will be submitted and approved independent of this FRD by CMS.
6. Future system enhancements and releases will be prioritized by the business need for UCM integration with other CMS systems (e.g. PECOS, CNC, OIG Exclusion, RAC DW, IDR/OnePI, MAS, esMD, HIGLAS, PCRS). See Figure 2.7.-1 above for a complete list of systems.
7. The following capabilities are considered out of scope for initial ‘Go-Live’. UCM will not:
a. Perform claims data analysis or social network analysis to identify fraud, waste, and abuse; PI contactors will use other systems to perform data analysis
b. Integrate with a telephony system to manage calls that generate leads
c. Replace or contain any of the Contract Management data (e.g. contractor costs, hours, and various deliverables) currently being performed by CMS ARTs.
d. Replace the Health Integrity Tracking System (HITS) or incorporate the functionality to support the MEDIC contractor workload and operations.
8. UCM initially will not be used by external stakeholders, e.g. MACs, Law Enforcement, and States during initial ‘Go-Live’; however, they will use and access the system at a later date to be determined by CMS.
9. UCM will not integrate with legacy ZPIC contractor systems.
10. UCM will not include all internal ZPIC contractor standard reports. UCM will provide an ad-hoc reporting capability which will allow users to build reports using the data elements captured within UCM.
Constraints The list below describes constraints identified and taken into consideration in the development of requirements.
· UCM will only be accessible through CMSNet via approved, dedicated connections or VPN.
· UCM must meet the CMS ARS for a Federal Information Security Management Act (FISMA) Medium level system. This constraint precludes the use of any cloud-based software or infrastructure as a service solution.
· The CMS Technical Review Board (TRB) must approve all software and hardware technologies and products selected by the Contractor before implementation.
Risks These are the identified risks that the requirements team has captured, documented and continue to track during our business requirements elicitation. These risks could potentially create down-stream issues for UCM and could affect the project achieving the desired results (e.g., satisfying requirements, meeting project goals and priorities, achieving measures of success) stated in this document.
Table 3.31 Probability Ratings
| High |
| High impact risks may result in a nonfunctional system that does not meet business requirements. |
| Medium |
| Medium impact risks may result in a system that does not have 100% of business requirements, and contains few noticeable missing functionalities. |
| Low |
| Low impact risks may noticeably affect operations, but the system will still be fully operational. |
UCM Functional Requirements Lead Management The following section describes the activities and requirements needed to perform Lead Management within UCM. This section includes the supporting process flows, narratives, and requirements to support the ‘To-Be’ vision depicted below in Figure 4.1-1.Figure 41 Lead Management Business Context
Lead Management Business Context The term Case, as defined by the business owners (CMS/CPI), is inclusive of lead management, investigations, referrals, and administrative actions. UCM, however, defines UCM Case as a record type that includes lead management and investigations only. Referrals and administrative actions are their own unique record types within UCM.
Lead Management is the process where information is received through tips or complaints, all of which is called a lead in UCM. The source, subject and allegations are documented during the lead creation process. The UCM user role of lead analyst documents the lead management information.
After the initial information is documented, it is then determined if there is enough information provided to build a successful investigation (non actionable check), or if there is information present that warrants an immediate advisement to law enforcement (IA). For additional information, automated system checks are performed in UCM, or a user may perform manual system checks.
The user may also look within UCM to see if this new lead (which is a part of UCM Case) has providers or beneficiaries that may have had any previously created record types (RFI, UCM case, FPS ASRs, etc.). If existing record types are found within UCM on either the provider or beneficiary of this new lead (case), to the user may reference them with each other in order to build a more robust history for that beneficiary or provider. This functionality is referred to as linking within UCM.
Once it is determined that the lead (case) should be escalated to an investigation (also UCM case), the lead is sent to the supervisor for review. The supervisor reviews the information, prioritizes the lead and sends it forward to the lead vetting process with CMS/CPI.
After the lead vetting process is completed, the lead may be released by CMS/CPI to the supervisor for assignment as an investigation to the UCM user role of investigative analyst.
Lead Creation The following sub-section details the process flows and business requirements for UCM implementation.
Lead Creation ‘To-Be’ Process Flow Figure 4.1 Lead Creation ‘To-Be’ Process Flow
Lead Creation Narrative
| LEAD MANAGEMENT |
| Lead Creation: Documenting Source, Subject, Allegations, and Additional Information |
| DESCRIPTION |
| The lead management process begins once the lead analyst receives the lead information. The lead analyst document the Source, Subject, and Allegations that are provided as part of the lead information. The lead analyst may document additional information such as Task order, CLIN, and claim type as part of the lead management intake process. |
| Step # |
| Process Description |
| 1) Receive Lead from Source |
| The lead analyst may receive the lead information from a variety of sources including beneficiary/employee/provider complainants, the OIG hotline, 1-800-Medicare, and data analytic systems. |
| 2) Input Source of Lead |
| The lead analyst documents the Source information into UCM including traceability back to the origin of the lead information. |
The source of this lead can be anonymous.
The source can be beneficiaries or providers.
The source of this lead can be a system such as Fraud Prevention System (FPS).
The source can be former employees.
The source can be beneficiary family/ guardian.
As well as other valid values.
| 3) Input Subject of Lead |
| The lead analyst documents the Subject of the information. The subject can be a beneficiary or a provider. Providers can be physicians, businesses, hospitals, DMEPOS suppliers, hospices, Skilled Nursing Facilities (SNFs), Home Health Agencies (HHAs) etc. |
| 4) Input Allegation of Lead |
| The lead analyst documents the Allegations, including the allegation (s) time frame as part of lead creation. The lead analyst will also capture the claim type and dollars at risk based on the allegations. The dollars at risk can be manually calculated using the OnePI (One Program Integrity) system. |
| 5) Input Additional Information of Lead |
| The lead analyst documents additional general information about this lead such as the task order or CLIN (Contract Line Item Number) number for this work. The lead analyst will also determine if there are additional return on investment attributions that need to be made to FPS or IRP. |
| 6) Automatic System Check of Source and Subject |
| Once the lead analyst has input the Source and Subject information, UCM will perform an automatic system check for possible hits on PECOS, FPS, and OnePI. If any information matches, the lead analyst will be shown the information. |
| 7) Manual System Check of Subject |
| The lead analyst may check other Systems for additional information on the Source or Subject. Additional data fields will capture information from CNC, Medicare Exclusion Database, Shared Systems, RAC Data warehouse and other systems. |
| 8) Immediate Advisement |
| Once the lead analyst reviews the information for the Source, Subject, and Allegations, they determine if this lead requires an Immediate Advisement to law enforcement. If needed, the Immediate Advisement can be made at any time. |
| 9) Search for Linkable Cases |
| Once the lead analyst has input the Source and Subject information, UCM will perform an automatic search for linkable cases. If multiple entries are found, the lead analyst will be able to select the case (or other record type) with which they want to link to. |
| 10) Actionable? |
| Once the lead analyst has input the Source, Subject, Allegations, and Additional information they can at this point in time determine if this lead can substantiate an investigation or whether this lead should be closed due to lack of information upon which to build the investigation. |
| 11) Close Lead |
| Once the lead analyst determines that this lead is non actionable they can proceed to close this lead. |
| 12) Assign Work |
| Once the lead analyst determines that this lead warrants an investigation they can send it forward to the lead vetting and work assignment process. |
Lead Creation: Source Subject Allegations Requirements
| Requirement Number |
| Requirement Description |
| Requirement Source |
| SOW Mapping |
| SSA-1.0 |
| UCM shall allow for the creation of a new case from the users landing page. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-2.0 |
| UCM shall allow for the status of a new case to be “New Lead”. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-3.0 |
| UCM shall require a set of minimum data elements for source, subject, allegations and lead information when creating a new case. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-4.0 |
| UCM shall require users to input the source of a lead when opening PI workload. |
| SOW (UCM and/or Draft UPIC) |
| UCM SOW 4.9.2.6 |
| SSA-5.0 |
| UCM shall require users to enter information for the following data elements as part of creating a new case: Task Order, CLIN, Claim Type, Source, Source Type, Lead Origin, Beneficiary Name or HICN or SSN, (When applicable), Provider Name or PTAN or NPI (When applicable), Allegations, and the Allegations date range. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA5.1 |
| UCM shall allow the user to enter information for the follow data elements as listed in the following data tables: Source, Allegations, Lead Information, Beneficiary, Provider, Attorneys, and Anonymous. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-6.0 |
| UCM shall allow the user to input multiple source and source types for a new case. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-7.0 |
| UCM shall allow the user to input only 1 valid lead origin for a new case. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-8.0 |
| UCM shall allow the user to select multiple allegations when creating a new case. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-9.0 |
| UCM shall allow the user to select multiple Medicare and/or Medicaid claim types when creating a new case. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-10.0 |
| UCM shall allow the user to enter information for only one Lead origin when creating a new case. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-11.0 |
| UCM shall allow for Lead origin valid values to include, but not limited to beneficiaries, providers, anonymous, FPS, or Proactive data projects. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-12.0 |
| UCM shall allow for the entry of Task Order or CLIN information. The Task Order or CLIN information may change, and requires a historical table to display the past values, who changed them and when. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-13.0 |
| UCM shall allow for the beneficiary to remain anonymous for all outbound data transfers (Reporting Purposes) when they are the Lead origin for a case and they provided the contractor with personally identifiable information. The contractor can designate this anonymous functionality on individual Beneficiaries. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-14.0 |
| UCM shall require that the information for the primary subject be entered into the system when creating a new case. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-15.0 |
| UCM shall require users to select at least one subject Type reference value within the Subject information when creating a lead. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-16.0 |
| UCM shall allow users to enter provider details when opening a case. |
| SOW (UCM and/or Draft UPIC) |
| UCM SOW 4.9.2.5 |
| SSA-17.0 |
| UCM shall allow a user to log all work performed as part of a case using both structured (predefined field elements and drop downs) and free-form entry of details. |
| SOW (UCM and/or Draft UPIC) |
| UCM SOW 4.9.2.8 |
| SSA-18.0 |
| UCM shall allow users to be able to update structured data elements. |
| SOW (UCM and/or Draft UPIC) |
| UCM SOW 4.9.2.8 |
| SSA-19.0 |
| UCM shall allow users to be able to enter free-form comments or notes concerning the investigation. |
| SOW (UCM and/or Draft UPIC) |
| UCM SOW 4.9.2.8 |
| SSA-20.0 |
| UCM shall provide the capability to enter multiple items for a single data field via manual entry or multiple selections from a drop-down menu or list. |
| SOW (UCM and/or Draft UPIC) |
| UCM SOW 4.9.2.8 |
| SSA-21.0 |
| UCM shall allow users to enter a reason for making changes to an existing case file whenever existing content is removed or replaced. (Editing of data does not require a reason.) |
| SOW (UCM and/or Draft UPIC) |
| UCM SOW 4.9.2.8 |
| SSA-22.0 |
| UCM shall automatically check the spelling of all text manually entered into the system. |
| SOW (UCM and/or Draft UPIC) |
| UCM SOW 4.9.2.8 |
| SSA-23.0 |
| UCM shall allow the user to click to create a case once all the required information has been inputted. The user must then decide if they want to assign the case to themselves, or send it to a supervisors queue. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-23.1 |
| UCM shall assign a new case a new UCM unique case identifier once the user has made an assignment decision and a case has been created. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-23.2 |
| UCM shall allow the user to send a case to the supervisor’s queue for assignment, once the minimum required data elements have been inputted. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-23.3 |
| UCM shall allow the user to assign a case to themselves in order to continue entering information once the minimum required data elements have been inputted. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-23.4 |
| UCM shall change the status of a new case to Lead in process once the case has been created and assigned to a user. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-23.5 |
| UCM shall change the status of a new case to Lead pending assignment once the case has been created and is waiting in the supervisors queue for assignment. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-24.0 |
| UCM shall allow the user to document the suspected Medicare policy violation. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-25.0 |
| UCM shall permit the user to document only the following completed activities prior to the lead vetting process: Verification of provider’s enrollment status; Data analysis; Contact with the complainant; Beneficiary interviews; Referring/ordering physician interviews if there is no indication that the physician(s) are involved in the scheme related to the lead; and Site verification. |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-26.0 |
| UCM shall require that all leads (cases) that warrant further investigations (cases) require CMS approval via lead vetting process prior to transitioning the lead (case) to an investigation (case). |
| CMS Stakeholder Meeting Sessions |
| N/A |
| SSA-27.0 |
| UCM shall allow for spell check and basic font editing, i.e. bullets, bold, underline, etc. for the narrative section where the user will provide information about the progress of the case. |
| CMS Stakeholder Meeting Sessions |
| N/A |
Table 4.1-1 Source Data Table
| Data Element Name |
| Element Definition |
| Required/ Optional |
| Entry Method/ Default Values |
| Single/ Multi-value Selection Option |
| Additional Rules/ Edits |
| Source |
| Captures the source that identified the lead |
| Required |
| Entry |
| Multi-Select |
| Reference data |
Allow for a table where multiple sources can be added.
Allow for numbering to show traceability. For example, 1 sent to 2, sent to 3.
| Lead Type |
| Designates whether the lead originated from the contractor (proactive) or any other source (reactive) |
| Required |
| Entry |
| Single Dropdown |
| Reference data |
| Lead Origin |
| Identifies the origin of the allegations. |
| Required |
| Entry |
| Single Dropdown |
| Reference data |
Only one per lead
FPS and Data project are valid values
| Lead Source Classification |
| Captures the case’s work category. Options include: FPS priority 100, |
Stakeholder Identified, CMS generated request, Law Enforcement
| Required |
| Entry |
| Single Dropdown |
Reference data
| FPS ASR |
| Indicator for an alert summary report from FPS |
| Optional |
| Entry |
| Radio Button for Association(Yes/No) |
| Displays the ASR workload date. |
| FPS ASR Number |
| Captures the alert summary report number (if applicable) |
| Optional |
| Feed from FPS |
| Single Text Box |
| Display links to FPS ASRs for the user. The user should be able to de-link if they are not applicable. |
| FPS Extra Information |
| Captures additional information from the FPS |
| Optional |
| Feed from FPS |
| Single Text Box |
| Depends on integration with FPS |
| IRP |
| Indicator to show that this case involves the incentive reward program |
| Optional |
| Entry |
| Checkbox |
Table 4.1-1 Beneficiary Data Table
| Data Element Name |
| Element Definition |
| Required/ Optional |
| Entry Method/ Default Values |
| Single/ Multi-value Selection Option |
| Additional Rules/ Edits |
| Name |
| Captures beneficiary information when the beneficiary is the originator |
| Required |
| Entry |
Single Text Box
| Alias |
| Captures alias information for beneficiary |
| Optional |
| Entry |
| Single Text Box |
| Anonymous |
| Indicates if the beneficiary reporting the lead wishes to remain anonymous |
| Optional |
| Entry |
| Single Text Box |
| CNC |
| Indicates to notate that this beneficiary has been found on the CNC |
| Optional |
| Entry |
| Single Check box |
| CNC Risk Code |
| Code from the CNC that indicates why this person is listed on the CNC |
| Optional |
| Entry |
| Single Text Box |
| Available for input if CNC check box is checked |
| CNC Risk Date |
| Date as of when this individual was given the risk code |
| Optional |
| Entry |
| Date |
| Available for input if CNC check box is checked |
| Victim |
| Indicates if this person has been the victim of ID Theft |
| Optional |
| Entry |
| Single Check box |
| Phone Number |
| Captures the phone number of the beneficiary |
| Optional |
| Entry |
| Multiple Text boxes |
| Can add multiples |
| Address |
| Captures the address of a beneficiary |
| Optional |
| Entry |
| Text Box |
| Can add multiples |
| Email Address |
| Captures the email address of a beneficiary |
| Optional |
| Entry |
| Text Box |
| Can add multiples |
| HICN |
| Captures the HICN of a beneficiary |
| Optional |
| Entry |
| Alpha-Number |
| Recipient ID |
| Captures the Medicaid Recipient ID of a beneficiary |
| Optional |
| Entry |
| Alpha-Number |
| Dual Eligible |
| Designates if the beneficiary is dual eligible |
| Optional |
| Entry |
| Single Checkbox |
| Only available if Recipient ID is entered |
| Gender |
| Captures the gender of the beneficiary |
| Optional |
| Entry |
| Single Radio Button |
| Male or Female |
| Date of Birth |
| Captures the date of birth of a beneficiary |
| Optional |
| Entry |
| Date |
| Calendar |
| Language |
| Captures the native language of a beneficiary |
| Optional |
| Entry |
| Single Drop Down Value |
| Reference Table |
Table 4.1-1 Anonymous Source Data Table
| Data Element Name |
| Element Definition |
| Required/ Optional |
| Entry Method/ Default Values |
| Single/ Multi-value Selection Option |
| Additional Rules/ Edits |
| Anonymous |
| Indicates if the beneficiary reporting the lead wishes to remain anonymous |
| Optional |
| Check box |
| Single Text Box |
| Checked by Default |
Cannot uncheck
| Phone Number |
| Captures the phone number of the beneficiary |
| Optional |
| Entry |
| Multiple Text boxes |
| Can add multiples |
| Address |
| Captures the address of a beneficiary |
| Optional |
| Entry |
| Text Box |
| Can add multiples |
| Email Address |
| Captures the email address of a beneficiary |
| Optional |
| Entry |
| Text Box |
| Can add multiples |
| Gender |
| Captures the gender of the beneficiary |
| Optional |
| Entry |
| Single Radio Button |
| Male or Female |
| Date of Birth |
| Captures the date of birth of a beneficiary |
| Optional |
| Entry |
| Date |
| Calendar |
| Language |
| Captures the native language of a beneficiary |
| Optional |
| Entry |
| Single Drop Down Value |
| Reference Table |
Table 4.1-1 Allegations Data Table
| Data Element Name |
| Element Definition |
| Required/ Optional |
| Entry Method/ Default Values |
| Single/ Multi-value Selection Option |
| Additional Rules/ Edits |
| Allegations |
| High level allegation category |
| Required |
| Entry |
Multiple Value, Multi-Select
| Allegations summary |
| Captures the details of allegations |
| Required |
| Entry |
| Single Text Box |
| 1 textbox for all allegations |
| Date of Service (from) |
| Provides the starting date of the allegations |
| Optional |
| Entry |
| Date |
| Calendar |
| Date of Service (to) |
| Provides the ending date of the allegations |
| Optional |
| Entry |
| Date |
| Calendar |
| Medicare Dollars at risk |
| Provides the total dollar amount at risk for Medicare |
| Optional |
| Read Only |
| Number |
| Summation of Part A Total + Part B Total + Part C + Part D |
This is the start of the file's text. The full file is on GovTribe.