PROJECT NAME: PDMP

DEPARTMENT:

PROJECT ID:
VERSION: 1 MODIFICATION DATE:

P&I

CREATION DATE: 12 MARCH, 2013

Business Requirements Document (BRD)

Project Name: Project ID: Prepared By:

Karan Ajwani Julie Bingley Justin Novakovich John Marshall Senkarik Molina Healthcare, Inc.

Revision History
Version Number Date of Change Purpose of Change Author

Document1

Page ii

Table of Contents
1. 1.1 1.2 1.3 1.4 2. 2.1 2.2 3. 3.1 3.2 3.3 3.4 3.5 4. 4.1 4.2 4.3 4.4 5. 5.1 5.2 5.3 6. 7. 8. 9. 9.1 9.2 10. 11. 12. 13. 14. BUSINESS REQUIREMENTS OVERVIEW ................................................................................................... 1 BUSINESS PROBLEM STATEMENT AND SUMMARY ............................................................................... 1 KEY BUSINESS OBJECTIVES .............................................................................................................. 1 BENEFITS/RATIONALE ....................................................................................................................... 1 SUCCESS CRITERIA........................................................................................................................... 2 BUSINESS REQUIREMENTS SCOPE ........................................................................................................ 3 SCOPE INCLUSION............................................................................................................................. 3 SCOPE EXCLUSIONS ......................................................................................................................... 3 BUSINESS REQUIREMENTS APPROACH .................................................................................................. 3 ASSUMPTIONS .................................................................................................................................. 3 CONSTRAINTS ................................................................................................................................... 4 DEPENDENCIES................................................................................................................................. 4 BUSINESS ANALYSIS APPROACH ........................................................................................................ 4 BUSINESS ANALYSIS MILESTONE TIMELINE......................................................................................... 5 EXISTING SYSTEM ................................................................................................................................ 5 AS-IS PROCESS MAP ........................................................................................................................ 5 AS-IS BUSINESS PROCESS ................................................................................................................ 5 SYSTEM CONTEXT ............................................................................................................................ 5 LIMITATIONS OF EXISTING SYSTEM OR PROCESS ................................................................................ 5 SOLUTION SCOPE REQUIREMENTS ........................................................................................................ 6 TO-BE PROCESS MAP ...................................................................................................................... 6 SYSTEM OR PROCESS CONTEXT ........................................................................................................ 6 BUSINESS, REGULATORY, AND USER REQUIREMENTS ........................................................................ 6 FUNCTIONAL REQUIREMENTS: SOLUTION CHARACTERISTICS .................................................................. 6 NON-FUNCTIONAL REQUIREMENTS ........................................................................................................ 7 IMPLEMENTATION REQUIREMENTS: TRANSITION ..................................................................................... 7 TEST PLAN ........................................................................................................................................... 8 BUSINESS ......................................................................................................................................... 8 TECHNICAL ....................................................................................................................................... 8 TRACEABILITY MATRIX....................................................................................................................... 8 RISKS ............................................................................................................................................... 9 GLOSSARY ....................................................................................................................................... 9 BUSINESS REQUIREMENTS APPROVALS ............................................................................................. 9 APPENDIX ....................................................................................................................................... 10

Document1

Page iii

1. Business Requirements Overview

1.1

Business Problem Statement and Summary

< This section should include backgound summary information for the specific problem. > < It should also provide a clear definition of the business problem that needs to be solved or improved. It should include enough information for someone unfamilar with the situation to gain an understanding, but should be brief (less than three paragraphs in length). It should include a description of what the problem is, what and who it affects, and why it is essential to solve the problem. It should also include a statement outlining the problem resolution.>

Currently, inconsistencies exist in the management of provider data processes, workflow and technologies. Across the enterprise, variances can be found in how provider data is managed, configured and maintained. Provider information is frequently duplicated between various systems with no linkage between the data bases that store provider data (e.g. QNXT, Cactus, Emptoris, Silo, etc.). The management and handling of provider data is presently very manual and labor intensive. A Workflow application does not currently exist to systematically manage and triage provider data. There is also a lack of a quality assurance program in place to ensure that provider data is accurate and meets current standards (e.g. HEDIS, NCQA, CAHPS). The provider data management project aims to address and resolve these issues.

1.2

Key Business Objectives

< What does the business wish to achieve with this project this is not the same as what features,functions, processes the business wishes to have in place but it should define the ultimate business objective. An example of a key business objective is a new or growing business may need to attract new customers to improve its market share. >

The goal of the PIM Redesign Program is to implement a standardized and most optimal end-to-end Provider Data Management process that will enable the company to be better aligned with its quality and growth strategies. Intended Results: Gained efficiencies in the flow and processing of Provider Data Standardization of provider data management and ability to meet the needs of the Medicaid Exchange project Implementation of new technology to assist enterprise-wide initiatives supporting provider data

1.3

Benefits/Rationale

< This section describes the reason why the business wants to implement the Business Requirements and the major benefits to be achieved. >

In order to implement a standard set of practices for managing provider data, a suite of projects will be implemented to achieve the desired benefits. The Provider Data Management is an overarching program encompassing the following sub-projects: Organizational Alignment:

Document1

Page 1 of 10

Desired Outcome: Re-align appropriate Health Plan PIM staff under MHI (Corporate) PIM Leadership Emptoris/Cactus/QNXT Integration: Desired Outcome: Use of technology to link various systems (contracting, credentialing), reduce redundancies (data entry), and reduce inconsistencies (i.e. provider types, provider specialties, etc.) between provider data bases Integrated PIM Workflow: Desired Outcome: Standardization of manual processes Provider Directories (Phase I and Phase II): Desired Outcome: Streamline and standardize the creation, organization, and distribution of provider directories in a single repository Provider Data Maintenance (Smart Form) Desired Outcome: Creation of online web form to facilitate provider data adds, changes and terminations Provider Data Maintenance (Web Updates): Desired Outcome: Ability for online provider data adds, changes, and terminations to be directly updated in QNXT and other systems Workflow Application: Desired Outcome: Implement a Workflow application to systematically manage and triage provider data Quality Audit: Desired Outcome: Implement a quality assurance program to ensure provider data is accurate and meets current standards (e.g. HEDIS, NCQA, CAHPS).

In addition to the above mentioned project outcomes, other benefits are as follows: Standardized processes for data maintenance activities Streamlining and standardization of PIM guidelines and material Enterprise wide PIM training program

1.4

Success Criteria

< Success Criteria are measures that quantify management objectives along with a target or threshold, and enable the measurement of strategic performance through use of Key Performance Indicators (KPIs) based on the defined business requirements. > < Success Criteria should not be confused with Critical Success Factors , which are outcomes of a project or achievements of an organization that are needed to consider the project a success or to deem the organization successful. > < Please list all applicable success criteria in this section. >

Any Key Performance Indicators in place?

Document1

Page 2 of 10

2. Business Requirements Scope

2.1 Scope Inclusion

< A narrative that describes the overall boundaries of the project. This should be limited to a few paragraphs or be in list format and should include a high level description of Product or Service scope: The sum of the features that make up the product or the service that is created by the project. Typically a scope inclusion is necessary for the completion of the project. > < Examples: > - Organizational/Geographic - Process Scope - Functional Scope < Examples might include: Implementation of Medicare and Medicaid lines of business, specific health plans or corporate departments, the beginning and end of the identified process. > Areas within Molina (MCO) that gather, manage and input provider data, including the following, are within the scope. Provider Contracting Inbound Provider Data Provider Web Portal Provider Credentialing Provider Contract Configuration Provider Configuration Provider Directories (online and literature) Outbound Provider Network Files Organizational reporting teams All Health Plans within Molina MCO are included MIT areas that support the listed groups are included

2.2

Scope Exclusions

<The details or list that describes what is OUT OF SCOPE for the project. The more specific the description, the less opportunity for scope creep. Typically it is out of scope if it is NOT necessary for the completion of the project.>

Changes to processes that indirectly utilize provider data, including but not limited to claims processing, credentialing criteria, provider compensation negotiations, etc.

3. Business Requirements Approach

3.1 Assumptions

< An assumption is something a project expects to be in place or occur, in order to achieve a certain result or successful project outcome. An example would be The project assumes the continued availability of funding following the upcoming merger. Assumption planning should be done to identify alternate solutions in the event original assumption results are disproved.>

Document1

Page 3 of 10

Each sub project will have its own set of business requirements. Viewpoints and/or opinions of different stakeholders will be taken into consideration while gathering business requirements. The Business Requirements for each sub project should be segregated into functional and technical requirements. A standard approach will be used while gathering business requirements e.g.Interviews, JAD sessions, brainstorming etc. Technology is available that will support business trequirements. Industry standards and best practices will be utilized while gathering business requirements.

3.2

Constraints

< What may pose a risk to the successful completion of the project / what are the boundaries within which the project will need to operate? Ex. Availability of Subject Matter Experts is limited.> The requirements gathered do not match system specifications. The requirements gathered are not as per MHI policies and practices. Lack of knowledge or expertise in gathering business requirements. Improper documentation of the gathered requirements. Conflicts of interest while gathering business requirements.

3.3

Dependencies

< Identify and describe all dependencies. Dependencies are key attributes a project should have in place in order to start, proceed, or be successful. Ex. Project cannot start until new HIPAA regulations are adopted. Project dependencies should be well thought out and defined and may include: > An effective gathering of requirements will depend on the inputs from different stakeholders .

3.4

Business Analysis Approach

< Describe the approach to elicitating the business requirements (e.g. JAD sessions, interviews, questionnaires, brainstorming, and prototyping. The approach should tie back to the busines goals and objectives. Please reference the goals and objectives in the project charter. > Currently, the MHI team is visiting different Molina offices in various states to understand their current process of handling provider data. The team is conducting individual interviews with the staff that handles provider data. Also, the team is circulating a questionnaire to the staff that provides detailed explanation of the ways in which provider data is entered into the QNXT system. It is noted that inconsistencies exist in the management of provider data processes, workflow and technologies. Across the enterprise, variances can be found in how provider data is managed, configured and maintained. Provider information is frequently duplicated between various systems with no linkage between the databases that store provider data (e.g. QNXT, Cactus, Emptoris, Silo, etc.). Various brainstorming sessions will be conducted between the team members to come up with proposed solutions for managing the provider data in a standardized way.

Document1

Page 4 of 10

3.5 Business Analysis Milestone Timeline

< Complete table or insert a chart/timeline (e.g. Gantt, Excel, PowerPoint Graph, etc.) indicating key milestones such as completing requirements work plan (RWP), eliciting requirements from subject matter experts (SME), BRD completion, review, and signoff. >

EXAMPLE
Milestone Task Name Start Date End Date Duration

4. Existing System
4.1 As-Is Process Map

< Insert a high level process map for the As-Is process that is in scope for the project. >

4.2

As-Is Business Process

< This section should include how the current business process works and how it should work for the future state. This may include reporting features among other features. >

4.3

System Context

< Please provide a narrative description of the current process or system. > < Also, insert a context diagram of existing system interfaces with other systems. A context diagram illustrates the relationship between sytems. >

4.4

Limitations of Existing System or Process

< Explain why the current system or process cannot meet the solution requirements. >

Document1

Page 5 of 10

5. Solution Scope Requirements

< Describe the existing system or business process in terms of its high-level functionality, interfaces with other systems or processes (use context diagram), and process flows. Explain why the current system or process cannot meet the Business Requirements. Include limitations, drawbacks, and shortfalls, etc. >

5.1

TO-BE Process Map

< Insert a high level process map for the TO-BE process which will be in place upon successful completion of this project. >

5.2

System or Process Context

< Insert a context diagram if the solution results in a new system or business process which will interface with other systems or processes. A context diagram illustrates the relationship of this new system or process to existing ones. >

5.3

Business, Regulatory, and User Requirements

<Business requirements must be justified by tying them to strategic, tactical, and operational goals. There are also regulatory governance considerations that must be taken into account, and client or user requirements that place the client/user at the center of focus. The following is a list of all regulatory, business and user requirements. The regulatory requirements should be placed first and include the contract/regulatory citation as well as the link to the document where the citation resides. The others should follow in prioritized order. > No. Requirement Regulatory, Business, or User Regulatory Citation (if Applicable)

BR1 BR2 BR3 BR4 BR5

6. Functional Requirements: Solution Characteristics

< The following requirements place the proposed system at the center of focus and provide a prioritized list of capabilities the system must demonstrate in order to satisfy business, user, and regulatory requirements. These requirements determine project success, add value or add convenience. Each functional requirement should have a corresponding solution scope requirement. > No. FR1 FR2 FR3 FR4 FR5 Functional Requirement

Document1

Page 6 of 10

7. Non-Functional Requirements
< The following requirements refer to business or technical characteristics that must be fulfilled related to things like the process, user interface, access security, availability, robustness, system failure, integration, migration, and documentation. As such, they do not deal with the actual functionality of the system, but nevertheless represent key project success factors. > No. NFR1 NFR2 NFR3 NFR4 NFR5 NFR6 Non-Functional Requirement

8. Implementation Requirements: Transition

< The following requirements are needed to facilitate the implementation of the solution. These requirements are temporary, transition-specific requirements and will not be needed once the solution is in place. They include requirements for the generation, conversion and migration of product, service or production data as well as other implementation requirements. > No. IR1 IR2 IR3 IR4 IR5 IR6 Implementation Requirement

Document1

Page 7 of 10

9. Test Plan
< In this section, a quality plan checklist can be defined (includes business, technical, regulatory, and otherwise), which will provide a means for measuring the quality of the final product or process. This will assist in determining whether the key business objective was met. >

9.1

Business

< Define a test plan that outlines the overall testing approach of the new solution requirements, and regression testing as is system, applications, and business process that are directly impacted by changes. > < Components include: Test Scope Out of scope Targeted Testing Areas Resources o Applications o Staff/testers o Training Test deliverables Dependencies Milestone >

9.2

Technical

< Identify the main components of the technical plan that are meant to achieve the overall business objective. >

10. Traceability Matrix

< The requirements traceability matrix is a tool to ensure that deliverables meet the requirements of the project. The matrix provides a thread from the established and agreed upon project requirements, through the projects various phases, and through to completion/implementation. This ensures that the product specifications and features satisfy the requirements on which they were based. > < The following matrix traces all functional requirements to solution scope requirements (business, user and regulatory) and testing scenarios to functional requirements. It ensures that all functions support the solution scope and all functionality is tested. > Solution Scope Requirement No. Functional Requirement No. Testing Scenario No.

Document1

Page 8 of 10

11. Risks
<The following should be risks that have been uncovered throughout the requirements gathering process.> <List each risk event, qualitative probability rating, qualitative impact rating, a response strategy, the person responsible for managing the risk, and status and date of action taken on identified risks. < A Risk and Issues log template is attached in the Appendix of this document for more comprehensive documentation of risks and issues identified during the requirements gathering process, as well as throughout the project lifecycle. > ID Risk Description Risk Triggers Mitigation Plan Owner

12. Glossary
< The following list identifies all industry or line of business jargon, acronyms, common words used in special context, and special terms that are used within this project and business requirements document.> Acronym or Key Term Definition

13. Business Requirements Approvals

< By approving these business requirements, you are also agreeing to follow the processes set forth in the Business Analysis Approach and the Business Analysis Milestone Timeline above. > Approver Title Date Approval Signature

Document1

Page 9 of 10

14. Appendix
Document Name Risk and Issues Log
Molina Risk and Issues Log Template.xls

Location

Document1

Page 10 of 10