PDE AP 20111229 Updated AJ

PDE PDE Version 1
Definition for
Health Net, Inc.
Presented on Tuesday, January 17, 2012
The contents of this proposal are Proprietary and Confidential to Pegasystems and Client. We retain the right to change any aspect of this proposal without prior notice.
Copyright 2012 Pegasystems Inc., Cambridge, MA All rights reserved. This document describes products and services of Pegasystems Inc. It may contain trade secrets and proprietary information. The document and product are protected by copyright and distributed under licenses restricting their use, copying distribution, or transmittal in any form without prior written authorization of Pegasystems Inc. This document is current as of the date of publication only. Changes in the document may be made from time to time at the discretion of Pegasystems. This document remains the property of Pegasystems and must be returned to it upon request. This document does not imply any commitment to offer or deliver the products or services described. This document may include references to Pegasystems product features that have not been licensed by your company. If you have questions about whether a particular capability is included in your installation, please consult your Pegasystems service consultant. For Pegasystems trademarks and registered trademarks, all rights reserved. Other brand or product names are trademarks of their respective holders. Although Pegasystems Inc. strives for accuracy in its publications, any publication may contain inaccuracies or typographical errors. This document or Help System could contain technical inaccuracies or typographical errors. Changes are periodically added to the information herein. Pegasystems Inc. may make improvements and/or changes in the information described herein at any time.
This document is the property of: Pegasystems Inc. 101 Main Street Cambridge, MA 02142-1590 Phone: (617) 374-9600 Fax: (617) 374-9620 www.pega.com Document Name: Application Profile Template: PartnerLedAP 06-02-01 Updated: March 8th, 2011
Contents
1 Executive Summary.............................................................5 1.1 The Opportunity.............................................................5 1.2 The Benefits...................................................................5 1.3 Initial Solution Target.....................................................5 1.4 Implementation Approach...............................................5 2 Project Details....................................................................6 2.1 Frameworks Overview.....................................................6 2.1.1 Healthcare Payer Industry Framework......................6 2.2 Duration and Timeline.....................................................7 2.3 Actors............................................................................7 3 Work Types, Processes, and Use Cases.................................8 3.1 Work Type - PDEError.....................................................8 3.1.1 Process - StartPDEError..........................................8 3.1.2 ProcessError.........................................................21 3.1.3 RecycleError.........................................................25 3.1.4 Work Type PDEError includes the following unreferenced Use Cases:.................................................29 3.2 Work Type - Project......................................................30 3.2.1 Process - StartProject...........................................30 3.2.2 DRAFT...................................................................32 3.2.3 Use Case Name: PDE Project Data Load - Preliminary EAS Use Case #: PDE_002 ............................................32 3.2.4 DRAFT...................................................................34 3.2.5 Use Case Name: PDE Project Delta Data Load (Non EAS) Use Case #: PDE_002a............................................34 3.2.6 ...........................................................................34 3.2.7 DRAFT...................................................................36 3.2.8 Use Case Name: PDE Project Data Load (R&R) Use Case #: PDE_002b..........................................................36 3.2.9 ...........................................................................36 3.2.10 DRAFT.................................................................38 3.2.11 Use Case Name: PDE Project Data Load (R&R, CC) Use Case #: PDE_002b....................................................38 3.2.12 .........................................................................38 3.2.13 DRAFT.................................................................40 3.2.14 Use Case Name: PDE Project Load (CC) Use Case #: PDE_002c........................................................................40 3.2.15 .........................................................................40 3.2.16 DRAFT.................................................................42 3.2.17 Use Case Name: PDE Project Delta Load (CC) Use Case #: PDE_002c...........................................................42 3.2.18 .........................................................................42
3.2.19 DRAFT.................................................................44 3.2.20 Use Case Name: PDE Project Delta Data Load Use Case #: PDE_002e..........................................................44 3.2.21 .........................................................................44 3.2.22 DRAFT.................................................................46 3.2.23 Use Case Name: PDE Project Retro Term Data Load Use Case #: PDE_002d....................................................46 3.2.24 .........................................................................46 3.2.25 DRAFT.................................................................48 3.2.26 Use Case Name: PDE Project Delta Data Load (R&R, CC) Use Case #: PDE_002c..............................................48 3.2.27 .........................................................................48 3.2.28 DRAFT.................................................................50 3.2.29 Use Case Name: PDE Project Data Update (Membership) Use Case #: PDE_002e..............................50 3.2.30 .........................................................................50 3.2.31 Process - ProjectAssignment................................59 3.2.32 WorkObjectCreated (project)...............................63 3.2.33 Process - ProjectTableUpdates.............................82 3.2.34 Work Type Project includes the following unreferenced Use Cases:.................................................83 3.3 Work Type - MissingPDEs.............................................84 3.3.1 Process - StartMissingPDEs...................................84 3.4 Supporting Type - Search.............................................87 3.4.1 Supporting Type Search includes the following Use Cases:............................................................................87 3.5 Supporting Type - Security...........................................91 3.5.1 Supporting Type Security includes the following Use Cases:............................................................................91 3.6 Supporting Type - DataManagement.............................94 3.6.1 Supporting Type DataManagement includes the following Use Cases:.......................................................94 3.7 Supporting Type - SysAdmin.........................................95 3.7.1 Supporting Type SysAdmin includes the following Use Cases:......................................................................96 4 Interfaces.........................................................................99 5 Reports and Correspondence...........................................100 6 Prerequisites...................................................................103 7 Project Participants and Roles..........................................104 8 Functional and Performance Testing.................................104 9 Client Enablement/Training..............................................105 10 Governance and Communications...................................105 10.1 Project Status Reporting..........................................106 11 Assumptions.................................................................106 12 Appendix A Unassociated Requirements......................107
1 Executive Summary
Pegasystems certified Partners will work with Health Net, Inc. in such a way as to enable you, our customer, to not only be successful during the first engagement but for all subsequent engagement. If selected, we plan to staff your project with the right mix of qualified individuals who have expertise and success in BPM implementations. They understand your business and our technology and provide the greatest value at the lowest risk to Health Net, Inc..
1.1 The Opportunity

<Insert opportunity here>
1.2 The Benefits

<Insert benefits here>
1.3 Initial Solution Target

The proposed system will target the following business objectives. These objectives will be used as a measure of success:
1. 2. 3. 4. 5. 6. 7. 8.
Faster Time to Market Use of Proven Best Practices Maximize Solution Flexibility Drive Productivity and Compliance Track PDE Errors to ensure all errors are being corrected. Build and maintain an audit trail for the PDE Error correction activities Improved business process efficiency Improved reporting and error tracking
1.4 Implementation Approach

Based upon our experience with hundreds of successful PegaRULES Process Commander Implementation it has been a best practice to look at the current client implementation methodology and integrate into to it many of Pegasystems industry leading best practices including but not limited to our Direct Capture capabilities.
While most organizations have been trained to create voluminous requirements documents in order to build software applications, Pegasystems Direct Capture of Objectives (DCO) product suite is integrated into the system to facilitate build for change development regardless of IT or business orientation.
Pegasystems approach is to directly capture executable requirements within the system and its Build for Change directive addresses the problems with the traditional SDLC approach. Pegas DCO Capabilities work with all Implementation Methodologies and greatly increase their efficiencies by automating many different work products. Pegasystems also has an iterative, agile and adaptable methodology that is supported by its award winning SmartBPM platform which can be deployed as Health Net, Inc. methodology of choice for this initiative. SmartBPM provides wizards, constructs, and easy to use forms to directly capture and execute requirements. Each phase of the methodology depends upon the SmartBPM platform, and the requirements are automatically documented always matching your requirements to development efforts. Using Pegasystems SmartBPM Implementation methodology and/or DCO Capabilities will help Health Net, Inc. achieve their objectives in a much timelier manner with a higher degree of quality. It will also assist Health Net, Inc. in realizing their return on investment (ROI) much earlier than other waterfall or bigbang approaches to development and delivery.
2 Project Details
The following section provides insight into the entire engagement scope including Framework usage, Durations and Timelines, Actors, and Implementation Methodology.
2.1 Frameworks Overview

Leveraging frameworks can expedite the process of application development. The goal of the framework is to provide the client with a platform that has a number of industry standard processes pre-built that can be customized and/or extended to meet the requirements of the client. The following frameworks are being proposed for this implementation:
2.1.1Healthcare Payer Industry Framework

Pegasystems framework for healthcare payers accelerates deployment of agile SmartBPM solutions for healthcare payers. The framework provides authorization process workflows, healthcare service levels, correspondence generation, Web service message intake and responses, HIPAA EDI templates, and a
HIPAA-compliant healthcare data model that accelerates the development of a range of multi-channel solutions such as Medicare Part D marketing, enrollment management applications.
2.2 Duration and Timeline

The timeframes presented below represents an estimate based upon the information know at this time. It is further based upon an allocation of resources and assumptions about the skill levels of these resources from Health Net, Inc.. As more information becomes available and upon further due diligence regarding this project, these estimates and staffing assumptions may need to be adjusted. Estimated Timeline
2
Inception
6 8 Weeks Elaboration Construction
10
Transition
12
The phases of the project are estimated to take: Inception 2 weeks Elaboration 3 weeks Construction 5 weeks Transition 2 weeks
2.3 Actors
Actors are the individuals or systems that will interact with the PDE System. Their names, type, access method and volumes are listed in the following table: Actor HNPS Group Lead HNPS Researcher MBA Group Lead MBA Management MBA Researcher Membership Group Lead Operator Browser Type Operator Operator Operator Count Access Method Browser Browser Browser
Actor Membership MA-PD Researcher Membership PDP Group Lead Membership PDP Researcher Membership Researcher System
Type
Count
Access Method
Operator
Browser
The Standard user portals will be used for the above with the following modifications: } } Add Health Net, Inc. Custom Logo Removal of unnecessary PRPC Gadgets
3 Work Types, Processes, and Use Cases

Work Types describe the high level business functions that will make up this application. Each Work Type lists the specific Use Cases (scenarios) and the specific Interfaces that are invoked. Any functionality not specified below may be addressed in follow-on projects. The names of the Work Types, Use Cases, and Interfaces should be chosen with care, as they will be used extensively in subsequent documentation and governance functions.
3.1 Work Type - PDEError

Describes the process for resolving PDE errors received from CMS through the file upload process.
3.1.1 Process - StartPDEError
Primary Path for StartPDEError (Page 8) 3.1.1.1

Use Case - UC_PDE_PDEError_0001_CreateError Short Description: Shape: Status: Actors: Pre-Conditions: Once the PDE files have been uploaded and the pre-processing ... Automated Step New Any PDE files have been uploaded and have completed pre processing Triggers: Complexity: Low
Step - CreateError
Post-Conditions: Description
Work objects are created for PDE errors that need to be researched
Once the PDE files have been uploaded and the pre-processing of the files has been completed: 1. The errors that need to be researched/corrected are sent to the PRPC System 2. The System creates a corresponding work object per Claim Control number Linked Requirements: Requirement Name BR_PDE_0018_Process Accepted PDE Records
Category Business Rule
Importance 1 - Critical
Description Cognizant Informatica load processes will generate data output and call a PEGA process. The PEGA process will take the following steps: NOTE: For this process, the following PDE RECORD_ID values are treated as Accepted PDE records ('ACC" (Accepted) and 'INF' (Informational). (1) Find matching work objects by checking all work lists and work baskets. Match is defined as 1st 15 digits of new data record's CLAIM_CONTROL_NO = 1st 15 digits of work object's CLAIM_CONTROL_NO (2) Update work object data fields: => Research Status updated with 'C' (Closed) => Last Updated By populated with 'System" => Last Update Date populated with current system date and time (3) Copy of the work object (including PDE data fields, any research details fields associated with the work object and the system defaulted fields to the PDE History table.
(4) Remove the work object from the work list or work basket. Business Rule: if not match found for the accepted PDE record, PEGA process will move on to the next data record in the load data. Additional Note: Cognizant will be loading these data files into the PDE PEGA scheme in tables that are clones of PDE602 and PDE605 BR_PDE_0019_Process Rejected PDE Records Business Rule 1 - Critical Cognizant will load the PDE files using Informatica into the PDE PEGA scheme in tables that are clones of PDE602 and PDE605and will create output to be used by a PEGA process they will trigger. Frequency of the PDE files is weekly. All PDE records that have not been accepted will continue to "recycle" each time a new PDE file is generated and submitted by Caremark on Health Net's behalf. NOTE: Rejected PDE records are defined as those with 'REJ' value in the RECORD_ID field. PEGA process will take the following steps with this data stream: (1) Find matching records in the PEGA app. Match is defined as the 1st 15 digits of the
CLAIM_CONTROL_NO field from the data stream = 1st 15 digits of the CLAIM_CONTROL_NO of the work object or the PDE record in the PDE History table. (2) Evaluate the status of the work object. If the work object is in a work list or a work basket, add '+1' to the Error Count field and overwrite all the PDE details with the data from the new inbound record. Leave the work object assigned (in the work list) as is. If the work object has been closed or is designated as 'NR" (Not Recycling), retrieve all the details from the PDE History table, Create a new work object with the '+1' in the Error Count field and assign the work object appropriately. If no matches are found anywhere in the PEGA system, create a new work object and set the Error Count field to '0' (zero). Assign work object appropriately. CONSIDERATION: Business has some rules to be applied when the value in Error 1 field is different for the new inbound record than it is in the existing work object record. Those rules will need to be defined during elaboration. BR_PDE_0020_Process Caremark Report 1 Accepted Records Business Rule 1 - Critical Cognizant will use Informatica to load the Caremark Report 1 files (frequency = weekly)
into the PDE PEGA scheme in tables that are clones of PDE602 and PDE605, create a data stream for the PEGA process to use and trigger the PEGA process. NOTE: For this process, accepted records are those with either 'ACC' (Accepted) or 'INF' (Informational) values in the RECORD_ID field. The PEGA process will take the following steps: (1) Find matching work objects by checking all work lists and work baskets. Match is defined as 1st 15 digits of new data record's CLAIM_CONTROL_NO = 1st 15 digits of work object's CLAIM_CONTROL_NO (2) Update work object data fields: => Research Status updated with 'C' (Closed) => Last Updated By populated with 'System" => Last Update Date populated with current system date and time (3) Copy of the work object (including PDE data fields, any research details fields associated with the work object and the system defaulted fields to the PDE History table. (4) Remove the work object from the work list or work basket. Business Rule: if not match found for the accepted PDE record,
PEGA process will move on to the next data record in the load data. BR_PDE_0021_Process Report1 Rejected Records Business Rule 1 - Critical Cognizant will load the Caremark Report 1 files using Informatica into the PDE PEGA scheme in tables that are clones of PDE602 and PDE605 and will create output to be used by a PEGA process they will trigger. Frequency of the Caremark Report 1 files is weekly. All PDE records that have not been accepted will continue to "recycle" each time a new PDE file is generated and submitted by Caremark on Health Net's behalf. NOTE: Rejected PDE records are defined as those with 'REJ' value in the RECORD_ID field. PEGA process will take the following steps with this data stream: (1) Find matching records in the PEGA app. Match is defined as the 1st 15 digits of the CLAIM_CONTROL_NO field from the data stream = 1st 15 digits of the CLAIM_CONTROL_NO of the work object or the PDE record in the PDE History table. (2) Evaluate the status of the work object. If the work object is in a work list or a work basket, add '+1' to the Error Count field and overwrite all the PDE details with the data
from the new inbound record. Leave the work object assigned (in the work list) as is. If the work object has been closed or is designated as 'NR" (Not Recycling), retrieve all the details from the PDE History table, Create a new work object with the '+1' in the Error Count field and assign the work object appropriately. If no matches are found anywhere in the PEGA system, create a new work object and set the Error Count field to '0' (zero). Assign work object appropriately. CONSIDERATION: Business has some rules to be applied when the value in Error 1 field is different for the new inbound record than it is in the existing work object record. Those rules will need to be defined during elaboration.
3.1.1.2 earcher
Use Case - UC_PDE_PDEError_0002_RoutetoResearcher Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description
Step - RoutetoRes
The standard PDE Errors are automatically routed &... Automated Step New Any PDE Error work objects created Work objects are listed in the corresponding Research work basket Triggers: Complexity: Low
The standard PDE Errors are automatically routed - Some work objects may directly routed to a Researcher's individual work list in a round robin fashion - Some work objects may be routed to a Researcher group work basket where the Group Lead will then
access and then assign to an individual work list as necessary - Some work objects may be directly routed to a Group Lead What is routed where will be entirely based upon the criteria defined by the business. An example of routing rules could include: - Error 1 values + Contract IDs for MAPD work objects routed to specific MAPD Research basket - Error 1 values + Contract IDs for PDP work objects routed to specific PDP Membershp Research basket - Error 1 values routed to HNPS Research basket - Error 1 value routed to MBA Research basket NOTE: - Business final criteria/business rules for routing include will be provided by business during Elaboration - The business must have the ability to update the routing requirements in a "self service" kind of fashion as necessary through the PRPC application. (MBA Manager only) - There can be multiple errors associated to one work object, but initial routing is based only on the value present in the Error 1 field. Linked Requirements: Requirement Name
Category
Importance
Description Anytime the work object is set to be routed, the System needs to revalidate the routing path. For example, if data elements that affect routing change due to the Recycle process and the work object is with a researcher, once that researcher submits the work object the System will check to see if should be routed to a different researcher or if it should proceed with the current routing process. The business to define which routing criteria takes precedence in order to decide where the work object should go to next.
BR_PDE_0050_Routing Revalidation Business Rule 1 - Critical
3.1.1.3 or (Page 21) 3.1.1.4 upLead

Use Case - UC_PDE_PDEError_0005_RoutetoGroupLead
Step - ProcessErr Step - RoutetoGro
Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description
The System will route the work object to the corresponding Gr... Automated Step New Any Researcher successfully submits work object to System Work object is listed in work list for corresponding Group Lead Triggers: Complexity: Low
The System will route the work object to the corresponding Group Lead's worklist based on the criteria/business rules defined by the business (to be provided during Elaboration). 1. System updates Record Status field 2. Copy of record with research details, default values and updated Record Status field is moved to PDE History table 3. Work object is routed to corresponding group lead's work list Linked Requirements: Requirement Name
Category
Importance
3.1.1.5 r
Use Case - UC_PDE_PDEError_0006_ReviewError Short Description: Shape: Status: Actors:
Step - ReviewErro
Group Lead accesses Work list Group Lead filte... Human Based Step New Triggers: Complexity: Low
HNPS Group Lead, Membership PDP Group Lead, Membership Group Lead,
MBA Group Lead Pre-Conditions: Post-Conditions: Description Work object is listed in Group Lead's work list Work object is in Closed status (if no other errors remain)
1. Group Lead accesses Work list 2. Group Lead filters Work List to "process" a sub group of work objects The Group Lead can then: Select a specific work object and review the details submitted by Researcher Confirm work for sub group of work objects and assign them to the "Auto Recycle" project The System confirms that the work object does not need to be routed to the next group
After the Group Lead finalizes his/her process and confirms the work object(s) 1. The System changes the status for all the work objects in the sub group to pending 2. System copies the PDE record with all research details and default values to the PDE History table. NOTES: - The Group Lead is not required to check every single work object. Instead the Group Lead will "spot check" one or a few items. - The Auto Recycle project is just a holding place for those work objects whose research is considered complete and are in pending status. - The business needs to be able to filter the list based on specific criteria (e.g., selected comment or Researcher). Final list of criteria to be determined during Elaboration. - The process that sends the information about resolved errors to CMK happens completely outside of the PRPC application. The System just needs to keep the resolved work objects in their pending status and in the Auto Recycle "project" until a future file is received with some kind of update about the error. Linked Requirements: Requirement Name
Category
Importance
Description The Group Lead needs to have a "confirm" option available to him on his screen. This is so he can select 1 or more work objects and choose to close them manually.
BR_PDE_0047_Confirm option for Group Lead Business Rule 1 - Critical
3.1.1.6 routeError (optional)

Use Case - UC_PDE_PDEError_0007_Re-routeError (optional) Short Description: Shape: Status: Actors: Post-Conditions: Description When the Group Lead submits the work object to the System:
Step - Re-
When the Group Lead submits the work object to the System:1. ... Automated Step New Any Work object is routed to the work basket for the next team responsible for error resolution Triggers: Complexity: Low
1. The System checks to see if the work object needs to be routed to another group based on rules/criteria provided by the business - If yes, the work object is routed to the next work basket or list as per the routing rules and the use case resumes from the corresponding step. - If no, the use case proceeds to the next step NOTE: - Final rules and criteria the System will use to determine if a work object needs to be re-routed will be provided by the business during Elaboration. Linked Requirements: Requirement Name
Category
Importance
3.1.1.7
Use Case - UC_PDE_PDEError_0008_CloseError Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description
Step - CloseError
1. PDE Record returned as accepted2. The System sets the stat... Integration New Any Work object is in Pending status The record is closed and no longer part of the work queue Triggers: Complexity: Low
1. PDE Record returned as accepted 2. The System sets the status of the corresponding work object to Closed 3. The System sends a copy of the record to and changes the status of the record in the PDE History table NOTES: - Records are matched based on the following CMS rules --> HICN --> Service Provider ID --> Service Provider ID Qualifier --> Prescription Service Ref number --> DOS --> Fill Number --> Dispensing Status - The work object is "held" in the System until a record is returned from CMS as an accepted PDE --> Work objects in pending status are still searchable, but can be viewed only - Work objects are cleared by subsequent files that may include project files and the NFAR list.
Alternate Steps for StartPDEError (Page 8) 3.1.1.8

Use Case - UC_PDE_PDEError_0009_RejectError_duplicate1 Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description After reviewing the details in the work object, the Group Lea... Human Based Step New Triggers: Complexity: Low
Step - RejectError
HNPS Group Lead, Membership Group Lead, Membership PDP Group Lead, MBA Group Lead Error is with Group Lead for resolution Error is returned to the Researcher's Work List
After reviewing the details in the work object, the Group Lead determines that there is an issue with the research conducted and that the work object must be returned to the Researcher: 1. Group Lead rejects the work object and indicates why research is incomplete. 2. Work object is returned to the top of the work list for the Researcher that submitted the error 3. Use Case resumes from "ProcessError"
3.1.1.9 oject
Use Case - UC_PDE_PDEError_0010_AssigntoProject Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description
Step - AssigntoPr
There are two ways a work object can end up in a project duri... Human Based Step New Triggers: Complexity: Low
HNPS Group Lead, MBA Group Lead, Membership Group Lead, Membership PDP Group Lead Work object forwarded to Group Lead for review by Researcher Work object removed from work queue
There are two ways a work object can end up in a project during the PDE Error process: either the researcher selects a project as part of the research or the group lead selects it as part of the review process. Please note that there is a process that happens during the file load process to try and automatically pull out items that are known to be part of a project. That is the Systematic project assignment. This is the manual re-assignment that may happen. SCENARIO 1: RESEARCHER SELECTS PROJECT DURING RESEARCH 1. Researcher selects a project option on the research form 2. Researcher submits the research details to the Group Lead 3. The Group Lead reviews the research details, approves the research and submits the work object details to the System 4. Copy of PDE record and all additional research data and defaults are moved to the PDE History table 5. Copy of PDE record is also moved to the project table - Note: only those fields that the record table calls for are copied over 6. Work object is removed from the work queue. SCENARIO 2: GROUP LEAD ASSIGNS TO PROJECT DURING REVIEW 1. Group Lead reviews Researcher's information for a submitted work object 2. Group Lead determines that the PDE record must be included in a Project 3. Group Lead assigns the work object to the corresponding project (see attachment) 4. Group Lead submits work object details to the System 5. Copy of PDE record and all addtional research data and defaults is moved to the PDE History table 6. Copy of PDE record is also moved to the Project table - Note: Only those fields that the record table calls for are copied over 7. Work object is removed from the work queue
3.1.1.10 or (Page 25) 3.1.1.11 openError

Use Case - UC_PDE_PDEError_0012_Re-openError Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description
Step - RecycleErr Step - Re-
1. A new PDE file has new error information for an ... Automated Step New Any New PDE file received and includes error record for existing Work Object in pending status Work object with new error regarding existing record is listed in Research's work list Triggers: Complexity: Low
1. A new PDE file has new error information for an existing record that is associated to a work object in Pending status and is in Auto-Recycle project 2. The Use case resumes from "RoutetoResearcher" NOTE: Allowing the work object to be pulled from the auto recycle project needs confirmation from: - The business in terms if that is the desired approach - The tech team that it is feasible. - If the work object is in an R&R project it stays associated to that project but is also kicked over to the corresponding research team. - Once a work object has been accepted it is never re-opened. Instead, if an error is re-opened, a new work object is just created.
3.1.2 ProcessError
Use Case for Process

Use Case - ProcessError Short Description: Type: From either the group work basket or his individual work list... Sub Process Triggers:
Status: Actors: Pre-Conditions: Post-Conditions: Description
New
Complexity:
Low
HNPS Researcher, MBA Researcher, Membership MA-PD Researcher, Membership PDP Researcher Work object is either selected by the Researcher from the work basket, or is listed on the Researcher's individual work list Work object is forwarded to Group Lead
From either the group work basket or his individual work list: 1. Researcher selects specific work object to process 2. System displays selected work object. NOTES: - Work objects can only be worked on by one Researcher at a time. - Urgency points will be applied to work objects in work lists to ensure that the most critical items have the most visibility (e.g., may be listed towards the top of the list, etc.). >> Business to supply business rules to determine urgency, listing order during elaboration. >> Visual representation of these urgent items to be discussed during elaboration Linked Requirements: Requirement Name BR_PDE_0005_Researchers can only edit their fields
Category
External ID Importance Description 1 - Critical Researchers can only edit the fields specific to their area of research, but will be able to view details for all other fields. > MBA updating form and profile for maintenance screen > HNPS Read Only on all data; Update on HNPS related data > Membership - Read Only on all data; Update on
Business Rule FUN.007
Membership related data BR_PDE_0037_Minimize Manual Entry of Details Functional 1 - Critical The System must provide an easy way for Researchers to enter their research details from ABS/CMK or other external Systems that minimizes the need for retyping. For example: allowing Researchers to cut and paste details from ABS into the PRPC application.
Primary Path for ProcessError (Page 21) 3.1.2.1 ror

Use Case - UC_PDE_PDEError_0003_ResearchError Short Description: Shape: Status: Actors: Pre-Conditions: Description The Researcher accesses ABS and/or the CareMark (CMK) system via PRPC in order to conduct research on corresponding error. NOTES: - ABS (eligibility) and CMK (eligibility and source pharmacy claim) are not the only Systems utilized. Other Systems may include: The Researcher accesses ABS and/or the CareMark (CMK) sy... Human Based Step New Triggers: Complexity: Low
Step - ResearchEr
HNPS Researcher, MBA Researcher, Membership MA-PD Researcher, Membership PDP Researcher Error is selected and open for processing when possible Researcher has access to all core systems
--> CSC (an external vendor application) --> eligibility --> MC400 --> eligibility --> MARX --> CMS The business will provde a final list of all Systems that need to be accessed during Elaboration. - Access to external systems should be initiated from within PRPC (e.g., either as links or framed in) in order to make it easier for the User to gain access. - CMK is a vendor application which may require the use of the BlueZone emulator
3.1.2.2 earch
Use Case - UC_PDE_PDEError_0004_SubmitResearch Short Description: Shape: Status: Actors: Pre-Conditions: Description 1. Researcher will enter research details into PRPC - There will be different forms based on Researcher type - Each form will have the values as defined in attachments.
Step - SubmitRes
1. Researcher will enter research details into PRPC &nbs... Human Based Step New Triggers: Complexity: Low
HNPS Researcher, MBA Researcher, Membership MA-PD Researcher, Membership PDP Researcher Researcher has finalized research in ABS and/or Caremark
--> MBA business owners wants to add addtional fields now for future use (Attribute1 through Attribute10) to all researcher detail subforms. 2. Researcher will submit form - Details on subform will be associated with the PDE Error record. - When the PDE error record is forwarded to another Team for further research, the research details will also be available to the next team for review in read only mode. 3. The System will save the details to the corresponding database using the PDE Schema 4. The System will update the corresponding field according to the error type and selections made in the form --> Business to provide final business rules per status available ------------------------------------Researcher may also say that the error should be in a project, but will not be added until GL confirms. Linked Requirements: Requirement Name
Category Importance
Description
BR_PDE_0037_Minimize Manual Entry of Details Functional 1 - Critical
The System must provide an easy way for Researchers to enter their research details from ABS/CMK or other external Systems that minimizes the need for retyping. For example: allowing Researchers to cut and paste details from ABS into the PRPC application.
Alternate Steps for ProcessError (Page 21) 3.1.2.3 Member

Use Case - UC_PDE_PDEError_0013_ProcessbyMember Short Description: Shape: Status: Actors: Description In addition to processing errors by work object ID, Researchers will be able to process all work objects associated to a member. There are scenarios where a single member may have the same type of error across multiple work objects. As a result, allowing the Researcher to define research details across all those work objects at the same time will improve efficiency. Linked Requirements: Requirement Name In addition to processing errors by work object ID, Researche... Human Based Step New HNPS Researcher Triggers: Complexity: Low
Step - Processby
Category Importance
Description The System will provide Researchers with the ability to resolve multiple work objects associated to a single member at one time.
BR_PDE_0043_Resolve Errors by Member ID Functional 1 - Critical
3.1.3 RecycleError

Use Case - RecycleError
Type: Status: Actors: Description
Sub Process New Any
Triggers: Complexity: Low
Primary Path for RecycleError (Page 25) 3.1.3.1 ed

Use Case - UC_PDE_PDEError_0011A_Error Accepted Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description When a new PDE file comes in and an error with a corresponding work object comes back as accepted... SCENARIO 1 If a work object has been created but has not yet been touched for processing (only initial automatic assignment has occurred) and a new file comes in stating the record has been accepted: 1. The System will copy the record details to the History table 2. The System will update the file details and send the updates to the History table Recycle count DOES NOT change in this scenario 3. The System will close the corresponding work object -------------------SCENARIO 2 If a work object has been created, the the work object is with a Researcher, and a new file comes in stating that the record has been accepted: Once the Researcher completes his process: 1. The System will update the details (the recycle count DOES NOT update) 2. The System will insert a record into the History table with both the research details and the new details in the file 3. The System will close the work object When a new PDE file comes in and an error with a corresp... Automated Step New Any PDE error for an existing open record is returned in a subsequent PDE file Existing work object is found and updated Triggers: Complexity: Low
Step - ErrorAccept
NOTE: Basically, if an error is with the Researcher but comes back as accepted in a subsequent file midway through the process, it will not go to the group lead.
-------------------SCENARIO 3 If a work object has been created, the work object is with a Group Lead and the Group Lead has not yet touched that work object for processing, and a new file comes in stating that the record has been accepted: Once the Group Lead completes their process 1. The System will update the details 2. The System will insert a record into the History table with both the research details and the new details in the file 3. The System closes the work object ---------------------SCENARIO 4 If a work object has been created, the work object is with a Group Lead and the Group Lead has started to review the work object for processing, and a new file comes in stating that the record has been accepted: 1. The System will update the details 2. The work object will still be on the work list for the Group Lead but it will visually display that it has been accpeted 3. Once the Group Lead finalizes the process, the System will insert a record into the History table with both the research details and the new details in the file 4. The System closes the work object ---------------------NOTES: 1. For Scenario 4, there may be a time lag between when the file comes in and the research/group lead finish their research. The System needs to be able to account for this lag but still allow all the details to be updated as needed. For example: - The file comes in on Monday, March 1st and has an accepted update for a work object that is with a Group Lead - The Group Lead does not finalize his part of the process for that work object until Thursday, March 4th Although the final detail update won't be completed until the Group Lead finalizes his process, there are key data points that should be updated right away. For example, the System should show that the error has been accepted. 2. If a work object had been created and the error was corrected and the work object is now in ACC
or INF status and a PDE file has new information for that existing record: - If the file is still accepted then nothing is done - If the file has a new error (comes back as rejected), then a new work object is created
Alternate Steps for RecycleError (Page 25) 3.1.3.2 Rejected

Use Case - UC_PDE_PDEError_0011B_Error Rejected Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description When a new PDE file comes in SCENARIO 1 If a work object has been created and is in pending status and a new file has that error listed as rejected again with new PDE information: 1. The details are copied to the history table 2. The System updates the recycle count (+ 1) to account for the PDE Error record being recycled 3. The System updates the corresponding details in the existing work object -------------------------SCENARIO 2 If a work object has been created and is in pending status and a new file has that error listed as rejected again with a new value in any Error field: 1. The details are copied to the history table 2. The System updates the recycle count (+ 1) to account for the PDE Error record being recycled 3. The System updates the corresponding details in the existing work object NOTE: If there is a new error code and the work object is associated to a membership project, the work object will be routed to Membership research so that they can research/resolve the new error. The work object will need to be routed back to the project it originated from once the error is resolved. ---------------------------------------When a new PDE file comes in SCENARIO 1If a work obj... Automated Step New Any PDE error for an existing open record is returned in a subsequent PDE file Existing work object is found and updated Triggers: Complexity: Low
Step - Error
SCENARIO 3 If a work object has been created and is in open status and a new file has that error listed as rejected again with any new PDE information: 1. 2. 3. 4. The details are copied to the history table The System will update the details The System updates the recycle count (+ 1) to account for the PDE Error record being recycled The Work Object remains with whomever is currently working on it (even if the Error1 field has changed)
-------------------------NOTES: - Business to provide business rules for the tracking of turn around time (and application or urgency points when a PDE record recycles) during elaboration - There is an evaluation to determine if the value in Error 1 field has changed in the new record being updated. There is a field in the PDE record (provided to Researcher in read only mode) that informs the Researcher when this condition is true. That step also helps the Researcher account for the results of any research already done for this PDE error.
3.1.4 Work Type PDEError includes the following unreferenced Use Cases: 3.1.4.1 or_0009_RejectError
Use Case - UC_PDE_PDEError_0009_RejectError Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description After reviewing the details in the work object, the Group Lead determines that there is an issue with the research conducted and that the work object must be returned to the Researcher: 1. Group Lead rejects the work object and indicates why research is incomplete. 2. Work object is returned to the top of the work list for the Researcher that submitted the error 3. Use Case resumes from Researcher resolving work object After reviewing the details in the work object, the Group Lea... N/A New Any Error is with Group Lead for resolution Error is returned to the Researcher's Work List Triggers: Complexity: Low
UC_PDE_PDEErr
3.2 Work Type - Project

Details the processes involved with PDE projects.
3.2.1 Process - StartProject
Primary Path for StartProject (Page 30) 3.2.1.1 ption

Use Case - UC_PDE_Exception_0001_CreateException Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description All project list files are created by either the HNPS team or the Membership Team. Because they are manually generated, duplicate records for the same Claim Control Number can be present in the file. The PEGA process will need to review the project list file to determine if duplicate records exist. If there are duplicate records, one record will be loaded to the Project Table and all other iterations will be used to generated Exception work objects. There is a possibility that more than one work object may be created for the exception. The PEGA process will need to retrieve the PDE details for the PDE fileds that are displayed in read only mode. Refer to attached use cases for details on how to determine if a record is a duplicate and what should happen in each scenario. NOTES: --> Data elements defined for Project Exception screen in spreadsheet will be confirmed during elaboration NOTE REGARDING THE ATTACHMENTS Please note that the use case details contained in the displayed attachments below are as per early project discussions with Pat. All the details contained within them may not accurately reflect the intended All project list files are created by either the HNPS team or... Automated Step New Any Pega process determines if duplicate records exist in project files Exception work object created per duplicate instance Triggers: Complexity: Low
Step - CreateExce
process. These attachments should be used as reference purposes only. All final and accurate use cases will be finalized during Elaboration. Attached File(s): PDE Exception Record Fields_MBA Researcher.xls:
The follow ing fields are included in a w ork object geneated from the Exception Process (and business rules). "Previous" is defined as asscoaited with a P record from the previous PDE file (associated w ith the com DE pare/diff process); "Comparison" is defined as associated w ith the current PDE file (associated w ith the compare/diff process).
Field Name Previous PDE Claim Control Number Previous PDE Report File ID Previous PDE Contract ID Previous PDE Date of Service Previous PDE HICN Previous PDE Cardholder ID Previous PDE Error 1
Comment
Previous PDE Record ID Previous PDE PBP Code Previous PDE Transaction Date Comparison PDE Report File ID Insert Date Comment Action Taken Record Status Last Updated By Last Update Date
Includes 'ACC;, 'INF' or 'REJ' records. 'ACC; and 'INF' for PDE Record ID values are both "viewed" aby the PDE process with CMS as Accpeted PDE records.
System date Drop down list C' (Closed) or 'O' (Open) Contains the User ID value for the last person who updated the PDE work object Contains the system date and time for the last time the PDE work object was updated.
PDE Project Data Load EAS_002_draft_Mary_V1.doc:
3.2.2DRAFT 3.2.3Use Case Name: PDE Project Data Load - Preliminary EAS Use Case #: PDE_002
Iteration: 1 Priority: High Description/Objective: To document the steps for loading lists of PDE records associated with one or more EAS Preliminary ProjectFiles. Project files are identified by the field PROJ within the file. This use case applies the following Projectfiles: Preliminary EAS Project Files (Restacker project lists) form Caremark back-end system Actors: Projectfile and PEGA System Triggers: Caremark Preliminary EAS Project files received from Caremark. Pre-conditions: Agreement between MBA Team and Caremark for PDE records associated with active Caremark Projects. PEGA database table for loading project lists. Cognizant DWH Team Informatica process for successfully loading and updating records in PDE PET Projects table. Post-conditions: New record/work objects loaded into PDE PET Project table. Data in table is available to PDE PET users as read only. Logic to drive the process for inserting in the PDE Project table, the PDE Project Exception Table and creating new work objects are appropriate. Frequency of Use: New Project files from Caremark and/or Membership are expected on a weekly basis. Normal Course of Events Step Actor Action System Response 1 The use case starts when 1. Load process updates or inserts records into PDE
the Cognizant Informatica process is triggered by the presence of new Caremark Projectdata files.
2
PET Projecttable. 2. CTS Projectfile is archived and removed from inbound UNIX directory.

Determine if duplicate records exist in Project file record is valid for processing with regard to the other records within the file itself.
If Cardholder ID value within the file and PROJ Year values are same: Evaluate the records found that meet the criteria Then If all other fields are same then keep one record for loading purposes and the other(s)records should be loaded to the Exception tableIf all fields in record are duplicates: Reject one of the duplicate records and load that record into ProjectException table (see Duplicate Project Records Alt 1). Else insert all records in Exception table.
When the Cardholder ID and the PROJ Year match, A new work object is created for each new record loaded into the
PDE Project Delta Data Load Non EAS_002a_draft.doc:
3.2.4DRAFT 3.2.5Use Case Name: PDE Project Delta Data Load (Non EAS) Use Case #: PDE_002a 3.2.6
Iteration: 1 Priority: High Description/Objective: To document the steps for loading lists of PDE records associated with Membership Project List Delta File for Non-EAS PDE records. Actors: Project List Delta file and PEGA System Triggers: Project List Delta files received from Membership. Pre-conditions: PEGA database table and the MBA Exception Table for loading project records.. Cognizant DWH Team Informatica process for successfully loading and updating records in PDE PET Projects table. The Cognizant Project load process sends email notification to MBA Team. Post-conditions: New record loaded into PDE PET Project table. Data in table is available to PDE PET users as read only. Frequency of Use: New Project List Delta files from Membership are available on a weekly basis. Normal Course of Events Step Actor Action System Response 1 The use case starts when 3. Cognizant load process updates or inserts records
the Cognizant Informatica process is triggered by the presence of new Project List Delta data files.
into PDE PET Project List table.

4.
PEGA process is called. System Architect to determine if this is solely a PEGA process.
5. The following fields are included on Non-EAS project files: PROJ (Project) CLAIM_NO PROJ_NO MBR_ID STATUS REASON CODE
Determine if duplicate records exist in project list Delta file.
(1) If all fields in record are duplicates: Reject one of the duplicate records and load that record into Project List Exception table. Update the Record Status field to DD (Delta Dup) (2) Load the other record into the Project List table.
Update the Record Status field with DC (Delta Closed)
Update the Reason Code field with Delta

3
Determine if PDE Delta
(1) If record does not exist in Project List table, insert
PDE Project Data Load_RR_002b_draft.doc:
3.2.7DRAFT 3.2.8Use Case Name: PDE_002b 3.2.9

Iteration: 1 Priority: High Description/Objective: To document the steps for loading lists of PDE records associated with Membership Project List File for Reverse and Reprocess (R&R) project. Actors: Project List files and PEGA System Triggers: New Project(R&R) List files received from Membership Pre-conditions: PEGA database table and MBA Exception table for loading project records. The Cognizant DWH Team Informatica process for successfully loading/updating R&R records in PDE PET Projects table. The Cognizant Project load process sends email notification to MBA Team. Post-conditions: New record loaded into PDE PET Project table or Exception table. Data in table is available to PDE PET users as read only. Frequency of Use: New Project List files are available on a weekly basis. Normal Course of Events Step Actor Action 1 The use case starts when System Response
PDE Project Data Load (R&R) Use Case #:
the Cognizant Informatica process is triggered by the presence of new Membership RR Project List data files.
2
6. Cognizant load process updates or inserts R&R records into PDE PET Project List table or records into the MBA Exception table. 7. PEGA process is called. System Architect to determine if this is solely a PEGA process. 1. If all fields in record are duplicates: Reject one of the duplicate records and load that record into Project List Exception table Set Record Status value to RRE (R&R Exception) Complete steps 2 & 3 from the Duplicate Project Records Alt 1
Determine if duplicate records exist in project list file.
Determine if Project record in Project List table This use case ends when all records in the new Project List file records have been processed.
If the record does not exist Project List table. Insert new record into Project List table Set Record Status to RRO (R & R Open).
Alternate Course of Events The contents of this proposal are Proprietary and Confidential to Pegasystems and Client. We retain the right to change any aspect of this proposal without prior notice.
PDE Project Delta Data Load_002b_draft.doc:
3.2.10 DRAFT 3.2.11 Use Case Name: PDE Project Data Load (R&R, CC) Use Case #: PDE_002b 3.2.12
Iteration: 1 Priority: High Description/Objective: To document the steps for loading lists of PDE records associated with Caremark Project List Delta File for Reverse and Reprocess (R&R) project and/or for Claim Correction project (CC) Actors: Caremark Project List files and PEGA System Triggers: New Caremark Project List files received from Caremark. Pre-conditions: Agreement between MBA Team and Caremark for PDE Project records associated with active Caremark Projects. PEGA database table for loading project records. Cognizant DWH Team Informatica process for successfully loading and updating records in PDE PET Projects table. The Cognizant Project load process sends email notification to MBA Team. Post-conditions: New record loaded into PDE PET Project table. Data in table is available to PDE PET users as read only. Frequency of Use: New Project List files from Caremark are available as needed. Normal Course of Events Step Actor Action System Response 1 The use case starts when 8. Cognizant load process updates or inserts records
the Cognizant Informatica process is triggered by the presence of new Caremark Project List Delta data files.
2
into PDE PET Project List table. 9. Project list file is archived and removed from inbound UNIX directory. System Architect to determine if this is solely a PEGA process. 2. If all fields in record are duplicates: Reject one of the duplicate records and load that record into Project List Exception table. Update the Record Status field to DD (Delta Dup) Load the other record into the Project List table. 3. If only the Claim ID field is a duplicate, reject the record and load into the Project List Exception table. 4. Create a work object for each new record loaded into the Project List Exception table. 5. Assign new work objects to the MBA work list
Update the Reason Code field with Delta Auto assign to HNPS?
PDE Project Data Load_CC_002c_draft.doc:
3.2.13 DRAFT 3.2.14 Use Case Name: PDE Project Load (CC) Use Case #: PDE_002c 3.2.15
Iteration: 1 Priority: High Description/Objective: To document the steps for loading lists of PDE records associated with Project List Delta File for Claim Correction (CC) project. Actors: CC Project List files and PEGA System Triggers: New CC Project List file. Pre-conditions: PEGA database table and MBA Exception table for loading CC project records. Cognizant DWH Team Informatica process for successfully loading and updating records in PDE PET Projects table. The Cognizant Project load process sends email notification to MBA Team. Post-conditions: New CC record loaded into PDE PET Project table or MBA Exception table. Data in table is available to PDE PET users as read only. Frequency of Use: New CC Project List files are available weekly. Normal Course of Events Step Actor Action System Response 1 The use case starts when 10. Cognizant load process updates or inserts CC
the Cognizant Informatica process is triggered by the presence of new Membership CC Project List data files.
2
records into PDE PET Project List table. 11. PEGA process is called. System Architect to determine if this is solely a PEGA process. If all fields in record are duplicates: Reject one of the duplicate records and load that record into Project List Exception table. Set Record Status Value to CCE (CC Exception) Complete steps 2 & 3 from the Duplicate Project Records Alt 1.
Determine if duplicate records exist in project list file.
Determine if Project Already Exists in Project List table
If record does not exist in Project List table.
Insert new record into Project List table Set the Record Status field to CCO (CC Project Open)
This use case ends when all records in the new Project List file records have been processed.
PDE Project Data Load_CC_Delta_002c_draft.doc:
3.2.16 DRAFT 3.2.17 Use Case Name: PDE Project Delta Load (CC) Use Case #: PDE_002c 3.2.18
Iteration: 1 Priority: High Description/Objective: To document the steps for loading lists of PDE records associated with Membership Project List Delta File for Claim Correction (CC) project. Actors: Membership CC Project Delta List files and PEGA System Triggers: New Membership CC Project Delta List file. Pre-conditions: PEGA database table and MBA Exception table for loading Membership CC Project Delta records. Cognizant DWH Team Informatica process for successfully loading and updating records in PDE PET Projects table. The Cognizant Project load process sends email notification to MBA Team. Post-conditions: New CC Delta record loaded into PDE PET Project table or MBA Exception table. Data in table is available to PDE PET users as read only. Frequency of Use: New CC Project Delta List files are available weekly. Normal Course of Events Step Actor Action System Response 1 The use case starts when 12. Cognizant load process updates or inserts CC delta
the Cognizant Informatica process is triggered by the presence of new Membership CC Project Delta List data files.
2
records into PDE PET Project List table. 13. PEGA process is called. System Architect to determine if this is solely a PEGA process. If all fields in record are duplicates: Reject one of the duplicate records and load that record into Project List Exception table. Set Record Status Value to DD (Delta Dup) Complete steps 2 & 3 from the Duplicate Project Records Alt 1.
Determine if duplicate records exist in project delta list file.
Determine if Project Already Exists in Project List table
If record does not exist in Project List table.
Insert new record into Project List table Set the Record Status field to C (Closed)
Set the Reason Code field to DA (Delta Add)

4 5
Determine if PDE records are currently recycling. This use case ends when all records in the new Project List file records have been processed.
If no PDE records are recycling, the process moved to the next record in the CC Delta List file.
PDE Project EAS Delta Data Load_002e_draft.doc:
3.2.19 DRAFT 3.2.20 Use Case Name: PDE Project Delta Data Load Use Case #: PDE_002e 3.2.21
Iteration: 1 Priority: High Description/Objective: To document the steps for loading lists of PDE records associated with Membership Project List Delta File for Non-EAS PDE records. Actors: Project List Delta file and PEGA System Triggers: Project List Delta files received from Membership. Pre-conditions: PEGA database table and the MBA Exception Table for loading project records.. Cognizant DWH Team Informatica process for successfully loading and updating records in PDE PET Projects table. The Cognizant Project load process sends email notification to MBA Team. Post-conditions: New record loaded into PDE PET Project table. Data in table is available to PDE PET users as read only. Frequency of Use: New Project List Delta files from Membership are available on a weekly basis. Normal Course of Events Step Actor Action System Response 1 The use case starts when 14. Cognizant load process updates or inserts records
the Cognizant Informatica process is triggered by the presence of new Project List Delta data files.
into PDE PET Project List table.

15. PEGA process is called. System Architect to
determine if this is solely a PEGA process. 16. The following fields are included on EAS Delta project files: PROJ (Project) CLAIM_NO PROJ_NO MBR_ID STATUS REASON_CD
(3) If all fields in record are duplicates: Reject one of the duplicate records and load that record into Project List Exception table. Update the Record Status field to DD (Delta Dup) (4) Load the other record into the Project List table.
Update the Reason Code field with Delta

3
Determine if PDE Delta
(3) If record does not exist in Project List table, insert
PDE Project Retro Term Load 002d_draft.doc:
3.2.22 DRAFT 3.2.23 Use Case Name: PDE Project Retro Term Data Load Case #: PDE_002d 3.2.24
Iteration: 1 Priority: High Description/Objective: To document the steps for loading Membership Project file records. These members may be identified based on retro terminations in the Health Net eligibility system(s based on the TRR reports from CMS. Member Project Files driven by HNPS or Membership identification of claims that must be included in specific Caremark projects to be fully resolved. Membership list will include the Member ID and the Year (associated with the retro termination).. Actors: CTS load process and PEGA System Triggers: New Membership Retro Term Project file received. Pre-conditions: PEGA Project and Project Exception database tables. PEGA System process for successfully loading Membership Project files in PDE PET Projects table. The PEGA system load process sends email notification to MBA Team. Post-conditions: New record loaded into PDE PET Project table or Project Exception table. Creation of new work objects with assignment to appropriate work list or work basket. Frequency of Use: New Project List files from Membership generated monthly. Normal Course of Events Step Actor Action System Response 1 The use case starts when 17. CTA load process completed successfully.
Use
the new Membership Project file is found.

2
18. PEGA process is called System Architect to determine if this is solely a PEGA process. Compare file name of current file to previously loaded files. Validate all Member IDs included in current file. Each Member ID within a file should be unique. 1. Evaluate all work list objects to determine if Open work objects exist. 2. Match is defined as Member Project List Member ID value equals work object PDE Cardholder ID value. 3. Retrieve Claim ID, Date of Service, Original File Name and Record Status field data
Determine if Member Project list file already exists Determine if file includes Duplicate Member IDs Retrieve additional PDE project data
3 4
Create new work object
A new work object is created for each new Member Project record. Set default values: Set Record Status field to PRR (Project Retro
PDE Project Delta Data Load_RR_002c_draft.doc:
3.2.25 DRAFT 3.2.26 Use Case Name: PDE Project Delta Data Load (R&R, CC) Use Case #: PDE_002c 3.2.27
Iteration: 1 Priority: High Description/Objective: To document the steps for loading lists of PDE records associated with Caremark Project List Delta File for Reverse and Reprocess (R&R) project and/or for Claim Correction project (CC) Actors: Caremark Project Delta List files and PEGA System Triggers: New Caremark Project List Delta files received from Caremark. Pre-conditions: Agreement between MBA Team and Caremark for PDE Project records associated with active Caremark Projects. PEGA database table for loading project records. Cognizant DWH Team Informatica process for successfully loading and updating records in PDE PET Projects table. The Cognizant Project load process sends email notification to MBA Team. Post-conditions: New record loaded into PDE PET Project table. Data in table is available to PDE PET users as read only. Frequency of Use: New Project List Delta files from Caremark are available as needed. Normal Course of Events Step Actor Action System Response 1 The use case starts when 19. Cognizant load process updates or inserts records
the Cognizant Informatica process is triggered by the presence of new Caremark Project List Delta data files.
2
into PDE PET Project List table. 20. Project list file is archived and removed from inbound UNIX directory. System Architect to determine if this is solely a PEGA process. 6. If all fields in record are duplicates: Reject one of the duplicate records and load that record into Project List Exception table. Update the Record Status field to DD (Delta Dup) Load the other record into the Project List table. 7. If only the Claim ID field is a duplicate, reject the record and load into the Project List Exception table. 8. Create a work object for each new record loaded into the Project List Exception table. 9. Assign new work objects to the MBA work list
Update the Reason Code field with Delta Auto assign to HNPS?
PDE MBR Project Data Update Load 002e_draft.doc:
3.2.28 DRAFT 3.2.29 Use Case Name: PDE Project Data Update (Membership) Use Case #: PDE_002e 3.2.30
Iteration: 1 Priority: High Description/Objective: To document the steps for loading updates for Membership Pending work objects. When the business decision has been made that these members are associated with a specific project, an update list will be prepared by the Membership team and presented for loading. The update files will be used to close pending records. Membership list will include the Member ID, Year, Project Name and Status that the specific PDE record is associated with. Actors: Membership Project Update file and PEGA System Triggers: New Membership Project Update file received. Pre-conditions: PEGA Project and Project Exception database tables and pended work objects in the Membership Pended work list. . PEGA process successfully loads Membership Project update files in PDE PET Projects table. Post-conditions: Records loaded into PDE PET Project table will be updated and Pending work objects removed from Membership Pended work list. Frequency of Use: New Project Update List files from Membership generated weekly. Normal Course of Events Step Actor Action System Response 1 The use case starts when 21. CTS load process completes successfully.
the new Membership Project Update file is found.

2
22. PEGA process called.
Find matches for Pending work objects in the Membership Pending work list. Update the work object (2) (3) (4) (5)
Matches are determined to be true when the value in the Member ID field of the Membership project list equals the value of the Cardholder ID field in the PDE work object
(`1) Change the Record Status to P (Project).. Update the Project name with the specific project detail from the data file. Update the Last Updated By field to MPU (Membership Project Update) Update the Last Update Date field with current system date. Copy the record to the PDE History table.
Remove the work object from the Membership Pending work list. This use case ends when all records in the new
Linked Requirements: Requirement Name
Category
Description If the exception is a duplicate that is already in the project table, then the data from the project table must be linked to the record on the file to be viewed and analyzed in the System. The Researcher will use the information to identify which is the correct one. When you are inserting one of exact duplicate into exception table, the record needs to be tagged somehow. This will signify that the record does not need to be researched. NOTE: Look into closing that one record in the exception table so that research isn't conducted.
BR_PDE_0045_Linking Duplicate Data from Project Business Table Rule
BR_PDE_0057_Tagging of Exact Duplicates
Business Rule
1 - Critical
BR_PDE_0018_Process Accepted PDE Records
Business Rule
1 - Critical
Cognizant Informatica load processes will generate data output and call a PEGA process. The PEGA process will take the following steps: NOTE: For this process, the following PDE RECORD_ID values are treated as Accepted PDE records ('ACC" (Accepted) and 'INF' (Informational). (1) Find matching work objects by checking all work lists and work baskets. Match is defined as 1st 15 digits of new data record's CLAIM_CONTROL_NO = 1st 15 digits of work object's
CLAIM_CONTROL_NO (2) Update work object data fields: => Research Status updated with 'C' (Closed) => Last Updated By populated with 'System" => Last Update Date populated with current system date and time (3) Copy of the work object (including PDE data fields, any research details fields associated with the work object and the system defaulted fields to the PDE History table. (4) Remove the work object from the work list or work basket. Business Rule: if not match found for the accepted PDE record, PEGA process will move on to the next data record in the load data. Additional Note: Cognizant will be loading these data files into the PDE PEGA scheme in tables that are clones of PDE602 and PDE605 BR_PDE_0019_Process Rejected PDE Records Business Rule 1 - Critical Cognizant will load the PDE files using Informatica into the PDE PEGA scheme in tables that are clones of PDE602 and PDE605and will create output to be used by a PEGA process they will trigger. Frequency of the PDE files is weekly. All PDE records that have not been accepted will continue to
"recycle" each time a new PDE file is generated and submitted by Caremark on Health Net's behalf. NOTE: Rejected PDE records are defined as those with 'REJ' value in the RECORD_ID field. PEGA process will take the following steps with this data stream: (1) Find matching records in the PEGA app. Match is defined as the 1st 15 digits of the CLAIM_CONTROL_NO field from the data stream = 1st 15 digits of the CLAIM_CONTROL_NO of the work object or the PDE record in the PDE History table. (2) Evaluate the status of the work object. If the work object is in a work list or a work basket, add '+1' to the Error Count field and overwrite all the PDE details with the data from the new inbound record. Leave the work object assigned (in the work list) as is. If the work object has been closed or is designated as 'NR" (Not Recycling), retrieve all the details from the PDE History table, Create a new work object with the '+1' in the Error Count field and assign the work object appropriately. If no matches are found anywhere in the PEGA system, create a new work object and set the Error Count field to '0'
(zero). Assign work object appropriately. CONSIDERATION: Business has some rules to be applied when the value in Error 1 field is different for the new inbound record than it is in the existing work object record. Those rules will need to be defined during elaboration. BR_PDE_0020_Process Caremark Report 1 Accepted Records Business Rule 1 - Critical Cognizant will use Informatica to load the Caremark Report 1 files (frequency = weekly) into the PDE PEGA scheme in tables that are clones of PDE602 and PDE605, create a data stream for the PEGA process to use and trigger the PEGA process. NOTE: For this process, accepted records are those with either 'ACC' (Accepted) or 'INF' (Informational) values in the RECORD_ID field. The PEGA process will take the following steps: (1) Find matching work objects by checking all work lists and work baskets. Match is defined as 1st 15 digits of new data record's CLAIM_CONTROL_NO = 1st 15 digits of work object's CLAIM_CONTROL_NO (2) Update work object data fields: => Research Status updated with 'C' (Closed) => Last Updated By
populated with 'System" => Last Update Date populated with current system date and time (3) Copy of the work object (including PDE data fields, any research details fields associated with the work object and the system defaulted fields to the PDE History table. (4) Remove the work object from the work list or work basket. Business Rule: if not match found for the accepted PDE record, PEGA process will move on to the next data record in the load data. BR_PDE_0021_Process Report1 Rejected Records Business Rule 1 - Critical Cognizant will load the Caremark Report 1 files using Informatica into the PDE PEGA scheme in tables that are clones of PDE602 and PDE605 and will create output to be used by a PEGA process they will trigger. Frequency of the Caremark Report 1 files is weekly. All PDE records that have not been accepted will continue to "recycle" each time a new PDE file is generated and submitted by Caremark on Health Net's behalf. NOTE: Rejected PDE records are defined as those with 'REJ' value in the RECORD_ID field. PEGA process will take the following steps with this data stream: (1) Find matching records in the PEGA
app. Match is defined as the 1st 15 digits of the CLAIM_CONTROL_NO field from the data stream = 1st 15 digits of the CLAIM_CONTROL_NO of the work object or the PDE record in the PDE History table. (2) Evaluate the status of the work object. If the work object is in a work list or a work basket, add '+1' to the Error Count field and overwrite all the PDE details with the data from the new inbound record. Leave the work object assigned (in the work list) as is. If the work object has been closed or is designated as 'NR" (Not Recycling), retrieve all the details from the PDE History table, Create a new work object with the '+1' in the Error Count field and assign the work object appropriately. If no matches are found anywhere in the PEGA system, create a new work object and set the Error Count field to '0' (zero). Assign work object appropriately. CONSIDERATION: Business has some rules to be applied when the value in Error 1 field is different for the new inbound record than it is in the existing work object record. Those rules will need to be defined during elaboration.
3.2.30.1 eptionList
Use Case - UC_PDE_Exception_0002_RoutetoExceptionList Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description
Step - RoutetoExc
If the System deems that this work object is an exception it ... Automated Step New Any Exception work object created Exception work object listed in MBA team exception work basket Triggers: Complexity: Low
If the System deems that this work object is an exception it is automatically routed to the MBA team's exception work basket. Note: - If an MBA has multiple types of work objects listed in his work list, the User needs to be able to visual differentiate this error type from the others. Linked Requirements: Requirement Name
Category
Importance
3.2.30.2 xception
Use Case - UC_PDE_Exception_0003_ResearchException Short Description:
Step - ResearchE
MBA researcher will run queries within PRPC to try and determ...
Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description
Human Based Step New MBA Researcher
An Exception work object is added to the Exception work list The exception is closed
MBA researcher will run queries within PRPC to try and determine why there are duplicate errors. NOTE: - Business needs to identify what criteria they will need to be able to search by in order to research these errors.
3.2.30.3 losed (manually)

Use Case - UC_PDE_Exception_0004_ExceptionClosed (manually) Short Description: Shape: Status: Actors: Description
Step - ExceptionC
MBA Researcher notes the exception details directly into the ... Human Based Step New MBA Researcher Triggers: Complexity: Low
MBA Researcher notes the exception details directly into the work object and then manually closes the work object.
Alternate Steps for StartProject (Page 30) 3.2.30.4 losed (Systematically)

Short Description: Shape: Status: Actors: Description 1. The project work object is updated as follows: A. If it is supposed to be loaded, then it is loaded to the project table B. If it is supposed to be closed then it is closed --> Any objects associated to that same claim control number must also be closed
Step - ExceptionC
Use Case - UC_PDE_Exception_0006_ExceptionClosed (Systematically) 1. The project work object is updated as follows: &... Integration New Any Triggers: Complexity: Low
2. The System automatically closes all corresponding work objects after it is loaded Linked Requirements: Requirement Name BR_PDE_0040_Linking Work Objects
Importance
Description The System must allow work objects to be "linked" together so that the Researcher can ensure that they are resolved together. There are instances during the Project Exception Error process where work objects are processed in groups. For example, if there were two work objects due to a duplication, but only one of the work objects was sent back there needs to be some way to make sure that the two work objects are linked and somehow resolves together. There is a scenario where a claim may already exist in the project table but be associated to a different project. The System needs to somehow recognize that there is a conflict in project information and notify the team.
BR_PDE_0041_Conflict in Project Information Business Rule
3.2.31 Process - ProjectAssignment
Primary Path for ProjectAssignment (Page 59) 3.2.31.1 Created (project) (Page 63) Alternate Steps for ProjectAssignment (Page 59) Step - WorkObject
3.2.31.2 Exists (rejected)

Use Case - UC_PDE_Assignment_0004_WorkObjectExists (rejected) Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description
Step - WorkObject
If a work object already exists in the PRPC application and i... Automated Step New Any A project file is loaded Existing work objects are associated to the corresponding project Triggers: Complexity: Low
If a work object already exists in the PRPC application and in a subsequent rejected file the PDE Error would be associated to a project SCENARIO 1: If the work object has not yet been opened for any kind of processing (in other words, may be assigned, but User has not touched it yet), then 1. The work object is set to pending status 2. The work object is assigned to the corresponding project 3. A record is inserted into a. the Project Table b. The PDE History table SCENARIO 2: If the work object is with a Researcher 1. The Researcher will finalize their process and submit the information 2. The work object is set to pending status 3. The work object is removed from the Users work list 4. The work object is assigned to the corresponding project 5. A record is inserted into a. the Project Table b. The PDE History table 6. The work object is listed as part of the XX frequency diff report that shows where it physically went vs where it was supposed to go based on the Researchers information (this is a report for the Group Leads to keep track of what happened within their group) SCENARIO 3: If the work object is with a Group Lead 1. The work object status is set to pending 2. The work object is removed from the Users work list 3. The work object is assigned to the corresponding project 4. A record is inserted into a. the Project Table b. The PDE History table SCENARIO 4: If the work object is already in a different project and its allowed to be put in a new project based on the type of new project * 1. The work object status stays as pending 2. The work object is also associated to that corresponding project 3. A record is inserted into a. the Project Table (for the new project)
b. The PDE History table * NOTE: A work object can be assigned to more than one project based on rules that the business will define during Elaboration.
3.2.31.3 Exists (accepted)

Use Case - UC_PDE_Assignment_0005_WorkObjectExists (accepted) Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description
Step - WorkObject
If a work object already exists in the PRPC application ... Automated Step New Any A project file is loaded Existing work objects are associated to the corresponding project Triggers: Complexity: Low
If a work object already exists in the PRPC application and in a subsequent accepted file the PDE Error would be associated to a project SCENARIO 1: If the work object is not assigned to anyone then 1. The work object is set to closed status 2. The work object stays assigned to wherever it is within the project table and none of the record statuses change in the project table 3. A record is inserted into the History table SCENARIO 2: If the work object is with a Researcher 1. The Researcher will finalize their process and submit the information 2. The work object is set to closed status 3. The work object is removed from the work list 4. The work object stays assigned to wherever it is within the project table and none of the record statuses change in the project table 5. A record is inserted into the History table 6. The work object is listed as part of the XX frequency diff report that shows where it physically went vs where it was supposed to go based on the Researchers information (this is a report for the Group Leads to keep track of what happened within their group) SCENARIO 3: If the work object is with a Group Lead 1. The work object status is set to closed 2. The work object stays assigned to wherever it is within the project table and none of the record statuses change in the project table 3. The work object is removed from the Users work list 4. A record is inserted into the History table SCENARIO 4: If the work object is already in a project 1. The work object status is changed to closed 2. The work object stays assigned to wherever it is within the project table and none of the record statuses change in the project table 3. A record is inserted into the History table
3.2.31.4
Use Case - UC_PDE_Assignment_0006_NFAR Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description
Step - NFAR
If a work object is assigned to the NFAR project at anytime d... Automated Step New Any A project file is loaded Existing work objects are associated to the corresponding project Triggers: Complexity: Low
If a work object is assigned to the NFAR project at anytime during the work objects life cycle SCENARIO 1: If the work object is not assigned to anyone then 1. The work object is set to pending status 2. The work object is associated to the NFAR project 3. Proceed with Business Rule #2 for UC_PDE_Missing_0001_CreateMissingError under MissingPDEs SCENARIO 2: If the work object is with a Researcher 1. 2. 3. 4. 5. The Researcher will finalize their process and submit the information The work object is set to pending status The work object is removed from the work list The work object is associated to the NFAR project The work object is listed as part of the XX frequency diff report that shows where it physically went vs where it was supposed to go based on the Researchers information (this is a report for the Group Leads to keep track of what happened within their group) 6. Proceed with Business Rule #2 for UC_PDE_Missing_0001_CreateMissingError under MissingPDEs SCENARIO 3: If the work object is with a Group Lead 1. 2. 3. 4. The work object status is set to pending The work object is removed from the Users work list The work object is associated to the NFAR project Proceed with Business Rule #2 for UC_PDE_Missing_0001_CreateMissingError under MissingPDEs
----------------------------------NOTE: The NFAR work object statuses will be changed to closed once it stops recycling
3.2.32 WorkObjectCreated (project)

Use Case - UC_PDE_Assignment_0001_WorkObjectCreated (project) Short Description: Type: Status: Actors: Description If a PDE work object does not exist in PRPC application and a new PDE error comes in as part of a reject file and the PDE Error would be associated to a project based on validation against the project table during load then a work object is created and follows one of the three project paths. Note: Project association is for PDE Work object(s). 1. Member ID/HICN based projects for HNPS 2. Member ID/HICN based projects for Membership 3. PDE Record based projects for HNPS Linked Requirements: Requirement Name BR_PDE_0054_Work Object Association to Projects If a work object does not exist in PRPC application and a new... Sub Process New Any Triggers: Complexity: Low
Description A work object can belong to both an HNPS and a Membership project, but it cannot belong to two different HNPS projects. ACTION ITEM: Lakhwinder to verify if Membership wants the member to be part of more than one Membership project
BR_PDE_0022_Load Prelim EAS Project File
Business Rule
2 - Very Important
Project files are manually created by HNPS or Membership teams and posted for use by the PEGA system (file names and
directories for posting to be determined during elaboration). Frequency for project files is weekly. The PEGA load process (high level requirements only) will need to take the following steps: (1) Evaluate validity of each record for processing When duplicate records are found, an Expection record is generated and loaded into the Exception Table. ==>PDE details are gathered and an Exception work object is created and asisgned to the appropriate MBA researcher and work list. ==> Determine if the PDE Record (from data gathered above) exists in the Project table. Record does exist in the Project table when the following Business Rules are true: Business Rule 1: If the CLAIM_CONTROL_ID value from the PDE data gathered equals the CLAIM_CONTROL_ID value in the Project table record. Business Rule 2: If the Cardholder ID in the Project file equals the Cardholder ID in the Project table. Business Rule 3: If the Project Type in the Project file equals the Project Type Number from the Project table.
Business Rule 4: If the Project Number in the Project file equals the Project Number form the Project table. Business Rule 5: If the Project Year from the Project file equals the Project Year in the Project table. ==>If the record does exist in the project table and the value of the Status field equals 'Open" no new record is added to the Project table. How to track this condition for audit purposes will be determined during elaboration. ==>If the record does exist in the Project table and the value of the Status field equals "Closed", a copy of the record is stored in the History table and a new record is appended into the Project table. --> If a record does not exist in the Project table, append a new record into the Project table and set the Status field to "Open. Fields included in the Project table are: - Project Owner (HNPS, Membership, MBA, CM) - Project Type - Project Number - Claim Control Number (1st 15 digits) - Status ('O' Open; 'C' Closed) - Reason Code (if Closed; why)
- Project Year - Claim Last File ID - RS_STATE - RS_DATE - Orig File Name - Upd File Name - Record Insert Date - Last Update Date ==> Search work lists to find matching work objects. Matches if New Porject record Claim Control ID - work object Claim Control ID. ==> Remove work object from work list. System updates Record Status to 'P' (Project). Last Updateed by is populated with "System" and Last Update Date is populated with the current system date and time. ==> Copy of the PDE record, all research details associated with it and default updates is stored in the PDE History table. BR_PDE_0023 Load Delta EAS Project File Business Rule 2 - Very Important Delta EAS project files may or may not be present each week. When available, they will be loaded and will follow the same steps (to be finalized during elaboration phase). At a high level, the Delta EAS project file includes more current information about PDE records included in a project. When matches are found in the work lists, the work object is closed and a copy of the PDE
details, all research details and all default values will be copied to the PDE History table. Any new EAS project records will be loaded to the Project table. BR_PDE_0024_Load Final EAS Project File Business Rule 2 - Very Important The Final EAS proejct file includes all PDE records (based on Claim Control Number) that are included is this specfic EAS project. The file will be loaded and follow all the logic steps for determining duplicates and matches (to be detailed during the elaboration phase). Project records will be added to the History table and to the Project table (as needed). Work objects will be removed from the work lists and work baskets and a copy of the PDE details, any research details associated with the PDE record and the system defaults will be copied to the PDE History table. BR_PDE_0025_Load Non-EAS Project File Business Rule 2 - Very Important HNPS and Membership will manually prepare the Non-EAS Project files on a weekly basis. The file naming convention and the directory where the files will be posted will be determined during elaboration. The same processes will be applied to these project files for validating the files (to be detailed during
elaboration) Duplicate records will be added to the Exception table, the PDE details will be retrieved and a new work object will be created and assigned to the appropriate MBA researcher. The following fields are included in the NonEAS proejct files: - Project - Claim Control Number - Project Number - Member ID - Status - Reason Code. When matching work objects are found for new Non-EAS project records, the work object is removed form the work list or work basket. A copy of the work object with the PDE details, associated research details and system defaulted data will be stored in the PDE history table. New project records (not found in the Project table) will be appended. When matches are found in the project table, the update process (to be detailed during elaboration) will take place. BR_PDE_0026_Load Delta Non-EAS Project File Business Rule 2 - Very Important The Delta Non-EAS proejct file may or may not be available each week. Project files are manually generated by the HNPS and Membeship teams.
File naming conventions and directories the files are posted to will be determined during elaboration. The Delta Non-EAS project file will include the same fields as the Non-EAS Project file and will be subject to the same file validation processes (to be detailed during elaboration). Duplicate records (duplicate logic will be added during elaboration) will be inserted into the Exception table and will retreive PDE details to be included in the work object that is created. The work object will be assigned to the appropirate MBA Researcher work list. Matches for work objects (based on the Claim Control ID value) will be closed. A copy of the work object PDE details, any research details associateda with it and the system defaulte fields will be copied to the PDE History table. Matches for Non-EAS proejct records existing in the Project table will be managed by business rules that will be added during elaboration. New NonEAS project records will be appended to the Project table as needed.
BR_PDE_0027_Load R&R Project File
Business Rule
2 - Very Important
Reverse and Reprocess (R&R) Project files are manually created by HNPS and Membership. These files will be posted on a weekly basis. File naming conventions and the directory the files will be posted to will be detailed during the elaboration file. File validation processes will take place (business rules will be determined during elaboration). Duplicate records will loaded to the Exception table. PDE details will be retrieved and a work object will be created and assigned to the appropriate MBA Researcher work list. Matching work objects will be found and closed. A copy of the work object PDE details, all associated research details and system defaulted values will be stored in the PDE history table. Matching records in the Project table will be updated based on business rules that will be detailed during the elaboration phase. New project records will be appended into the Project table.
BR_PDE_0028 Load Delta R&R Project File
Business Rule
2 - Very Important
There may or may not be a Delta Reverse and reprocess (R&R) project file each week.
These files are manually created by the HNPS and Membership teams. The validation processes will be applied ot the file (business rules will be determined during the elaboration phase). Duplicate records will be inserted into the Exception table. The PDE details will be retreived and a new work object will be created and assigned to the appropriate MBA researcher. Matching work objects (based on the Claim Control Number value) will be found and the work objects will be closed. A copy of the work object PDE details, associated research details and system defaulted fields will be copied to the PDE History table. Matches for R&R Project records in the Project table will be updated based on business rules that will be provided during elaboration. New R&R Project records will be added to the Project table as needed. BR_PDE_0029_Load CC Project Files Business Rule 2 - Very Important There may or may not be Claim Correction (CC) Project files posted each week. These project files are manually created by the HNPS and Membership teams.
CC Project file validation processes will be applied based on business rules provided during the elaboration phase. Duplicate records will be inserted into the Exception table. PDE details will be retrieved and work objects will be created and assigned to the appropriate MBA Researcher work list. Matching CC Project records found in the Project table will be updated based on business rules (to be determined during elaboration). New CC project records will be inserted into Project table as needed. Matching work objects will be found and closed. All work object PDE details, assocaited research details and system defaulted values will be copied to the PDE History table. BR_PDE_0030_Load Delta CC Project Files Business Rule 2 - Very Important There may or may not be a weeky Claims Correction Delta Project file posted. The CC Delta Project files are manually created by the HNPS and Membership teams. File naming conventions and the directory the file is posted to will be determined during elaboration. File validation processes will be done
based on business rules that will be detailed during elaboration. Duplicate records found in the project file will be loaded to the Exception table. PDE details will be retreived and a work object will be created and assigned to the appropriate MBA Reseacher. Matching records (based on the Claim Control Number value) in the Project table will lbe updated based on business rules provided in the elaboration phase. New project records will be inserted into the Project table as needed. Matching work objects will be found and closed. The work object with the PDE details, the associated research details and system defaulted fields will be copied to the PDE History table. BR_PDE_0031_Load Retro Term Project File Business Rule 2 - Very Important Members are occasionally terminated retroactively which impacts the PDE records that were submitted to CMS on behalf of Health Net. There may or may not be a Retro Term Project file each week. Retro Term Project files are manually created by HNPS and Membership teams. File naming
conventions and the directory the files will be posted to will be determined during the elaboration file. File validation processes will be applied based on business rules that will be detailed during elaboration. Duplicate records will be loaded into the Exception table. PDE details will be retrieved and a work object will be created and assigned to the appropriate MBA Researcher work list. Matching records in the Project table will be updated based on business rules that will be detailed during elaboration. New Retro Term Project records will be inserted into the Proejct table as needed. Matching work objects will be found and closed. A copy of the work object with the PDE details, associated Research details and system defaulted fields will be copied to the PDE History table. BR_PDE_0032_Load Delta Retro Term Project File Business Rule 2 - Very Important There may or may not be Delta Retro Term Project files each week. Project files are manually created by HNPS and Membership teams and the file naming convention and the
directory the file is posted to will be determined during the elaboration phase. File validation processes will be applied to the files based on business rules that will be detailed during elaboratioin. Duplicate records in the Retro Term Project file will be loaded into the Exception table. The PDE details will be retreived and a work object will be created and assigned to the appropriate MBA Researcher work list. Matching Retro Term Project records (based on the Claim Control Number value) will be updated in the project table based on business rules that will be determined during elaboration. New Retro Term Project records will be added to the Project table as needed. Matching work objects will be found and closed. The work object with the PDE details, associated research details and system defaulted fields will be copied to the PDE History table. BR_PDE_0033_Project Update_Membership Business Rule 2 - Very Important When the busienss decision has been made that these members are associated with a specific proejct, an
update list will be prepared by the Membership team and presented for load. The update files will be used to close "pending" project records. The Membership Project Update file may or may not be available on a weekly basis. File naming conventions and the directory the file will be posted to will be determined during the elaboration phase. The Membership Project Update file will contain the following fields: - Member ID, - Year - Project Name - Status (that the specific PDE record is associated with). The PEGA process will take the follwoing steps: (1) Matching for Pending work objects will be found in the Membership Pending work list Matches are determined based on the value in the Member ID field of the Memberhsip Update Project list equals the value of the Cardholder ID field in the work object. ==> If not matching record is found, a record will be inserted in the Exception Table. ==> Create a work object and assign to the appropriate MBA Researcher work list.
(2) System will update the work object and set the default field values based on business rules that will be detailed during the elaboration phase. (3) Work object will be removed from the work list. (4) A copy of the work object and the PDE details, the associated research details and the system defaulted fields will be copeid to the PDE History table. BR_PDE_0034_Load Membership Project Delta Update file Business Rule 2 - Very Important There may or may not be a Membership Delta Update Project file each week. The file naming convention and the directory the file is posted to will be determined during the elaboration phase. The Memberhship Project Delta Update file will contain the following fields: - Project - Claim Control Number - Project Number - Member ID - Status - Reason Code. File validation processes will be applied based on business rules that will be detailed during the elaboration phase. Duplicate records will be inserted into the Exception table. The PDE details will be retreived and a work object will be created and assigned to the appropriate MBA
Researcher work list. Matching Membership Project records in the Project table will be updated based on business rules that will be detailed during elaboration. New Membership Project records will be inserted in the Project table, as needed. Matching work objects will be found and closed. The work object PDE details, associated research details and system defaulted fields will be copied to the PDE History table. BR_PDE_0035_Load HNPS Project Update File Business Rule 2 - Very Important When the busienss decision has been made that these members are associated with a specific proejct, an update list will be prepared by the HNPS team and presented for load. The update files will be used to close "pending" project records. The HNPS Project Update file may or may not be available on a weekly basis. File naming conventions and the directory the file will be posted to will be determined during the elaboration phase. The PEGA process will take the follwoing steps: (1) Matching work objects will be found .
==> If not matching record is found, a record will be inserted in the Exception Table. ==> Create a work object and assign to the appropriate MBA Researcher work list. (2) System will update the work object and set the default field values based on business rules that will be detailed during the elaboration phase. (3) Work object will be removed from the work list. (4) A copy of the work object and the PDE details, the associated research details and the system defaulted fields will be copeid to the PDE History tab BR_PDE_0036_Load HNPS Delta Project Update Business File Rule 2 - Very Important There may or may not be an HNPS Delta Project update file each week. The project file is manually created by the HNPS team. File naming conventions and the directory the files will be posted to will be determined during the elaboration phase. File validation processes will be applied based on business rules that will be detailed during the elaboration phase. Duplicate records will be inserted into the Exception table. The PDE details will be retreived and a work object will be created and assigned to the appropriate MBA Researcher work list.
Matching HNPS Project records in the Project table will be updated based on business rules that will be detailed during elaboration. New HNPS Project records will be inserted in the Project table, as needed. Matching work objects will be found and closed. The work object PDE details, associated research details and system defaulted fields will be copied to the PDE History table. BR_PDE_0042 Load NFAR Project Data Business Rule 2 - Very Important HNPS and Membership Team will create a list for PDE records with a "No Further Action Required" (NFAR) status. There may or may not be a weekly file generated for NFAR project lists. When the file is present, PEGA will load the data, find matching open work objects (based on the 1st 15 digits of the Claim Control Number) and close the work object with a record status of 'NFAR'. The work object will be removed from the work list or work basket. All NFAR records will be loaded into the PEGA project table. BR_PDE_0046_Linking Acc & Inf to Project Table Business Rule 1 - Critical When ACC&INF PDEs flow into the System
they close work objects. However, sometimes the record is in the Project Table and not part of a work basket/list and that PDE record still needs to be closed. This process will be built to validate if the record exists in the Project Table and 1 - Closes the record 2 - Makes a copy of the final record details to the PDE History Table CONSIDERATION It is believed that a PDE Record can only be present in a work basket/list OR in a project table, but not both. --> This is to be confirmed. BR_PDE_0053_Member ID Association to HNPS Member Projects BR_PDE_0055_Project Table Comparisons Business Rule Business Rule 1 - Critical A Member ID cannot exist in more than one HNPS member project. When we compare against the project table we should only look at those records that have an open status. A member can be associated to more than one open membership project.
1 - Critical
BR_PDE_0056_Membership Project Association
Business Rule
1 - Critical
Primary Path for WorkObjectCreated (project) (Page 63) 3.2.32.1 ID/HICN

Use Case - UC_PDE_Assignment_0002_Member ID/HICN Short Description: SCENARIO 1: Member ID/HICN based projects for HNPS or Members...
Step - Member
Shape: Status: Actors: Description
Automated Step New Any
SCENARIO 1: Member ID/HICN based projects for HNPS or Membership 1. The work object is created 2. The work object status is set to pending if it meets the criteria as defined by the business (e.g., it falls within the start and end date of the project) 3. A new record is inserted into the appropriate project in the project table 4. The work object is automatically assigned to the corresponding HNPS or Membership project
Alternate Steps for WorkObjectCreated (project) (Page 63) 3.2.32.2

Use Case - UC_PDE_Assignment_0003_Claim Based Project Short Description: Shape: Status: Actors: Description SCENARIO 2: PDE Record based projects for HNPS (these projects are HNPS based only) 1. The work object is created 2. The work object status is set to pending if it meets the criteria as defined by the business (e.g., Specified PDE Data Elements) 3. The work object is automatically assigned to the corresponding project (the record already exists in the project table which is why only the association happens) SCENARIO 2: PDE Record based projects for HNPS (these project... Automated Step New Any Triggers: Complexity: Low
Step - Claim
3.2.33 Process - ProjectTableUpdates
Primary Path for ProjectTableUpdates (Page 82) 3.2.33.1 ates

Use Case - UC_PDE_Updates_0001_ManualUpdates Short Description: The MBA Management team needs the ability to make manual upda...
Step - ManualUpd
Shape: Status: Actors: Description
Human Based Step New MBA Management
The MBA Management team needs the ability to make manual updates to the Project Table by accessing interfaces in the PRPC application. Updates can be made at the overall project level or the individual record level. At the project level 1. MBA Management User will have the ability to update the project related elements associated to a project (i.e, project #, file ID, project status etc. to be finalized during Elaboration) NOTE: What processes happen after a data element is changed will depend upon what is actually updated. For example, what happens if a project # is changed will be different from happens if the project status is changed. For example If the PDE is being released out of a HNPS closed project (R&R or EAS), because the PDE is still rejecting. It needs to be released to HNPS only regardless of the error code. Same thing with Membership projects, the PDE needs to be released to Membership only once the project is closed, if the PDE is still rejecting. Also when we are releasing the rejecting PDEs from closed project, we need to provide both of the teams with the Project name the PDEs were locked under. 2. MBA Management User will have the ability to create a new project At the individual record level 1. The MBA Management User will have the ability to udpate the project related elements associated to one or more individual record at a time (i.e., would not include things like member ID or claim ID, but otherwise see above examples) 2. The MBA Management User will have the ability to create a new record and associate to a project as needed
3.2.34 Work Type Project includes the following unreferenced Use Cases: 3.2.34.1 UC_PDE_Assign ment_0006_WorkObjectExists (accepted)
Use Case - UC_PDE_Assignment_0006_WorkObjectExists (accepted) Short Description: Shape: If a work object already exists in the PRPC application ... N/A Triggers:
Status: Actors: Description
New Any
Complexity:
Low
If a work object already exists in the PRPC application and in a subsequent accepted file the PDE Error would be associated to a project SCENARIO 1: If the work object is not assigned to anyone then 1. The work object is set to closed status 2. The work object stays assigned to wherever it is within the project table and none of the statuses change in the project table 3. A record is asserted into the History table SCENARIO 2: If the work object is with a Researcher 1. The Researcher will finalize their process and submit the information 2. The work object is set to closed status 3. The work object is removed from the work list 4. The work object stays assigned to wherever it is within the project table and none of the statuses change in the project table 5. A record is asserted into the History table NOTE: The diff report does not apply to accepted scenarios SCENARIO 3: If the work object is with a Group Lead 1. The work object status is set to closed 2. The work object stays assigned to wherever it is within the project table and none of the statuses change in the project table 3. The work object is removed from the Users work list 4. A record is asserted into the History table SCENARIO 4: If the work object is already in a project 1. The work object status is changed to closed 2. The work object stays assigned to wherever it is within the project table and none of the statuses change in the project table 3. A record is asserted into the History table
3.3 Work Type - MissingPDEs

Describes the process involved when having to reconcile missing PDE files between loads.
3.3.1 Process - StartMissingPDEs
Primary Path for StartMissingPDEs (Page 84)
3.3.1.1 ngError
Use Case - UC_PDE_Missing_0001_CreateMissingError Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description
Step - CreateMissi
Work objects are created for those records deemed as missing ... Automated Step New Any Programmatic compare-diff has been completed by CTS A corresponding work object is created for each missing record Triggers: Complexity: Low
Work objects are created for those records deemed as missing from the current file. CTS will complete a comparison between the previous PDE file and the current PDE file. If any records are "missing" from the current PDE file, an exception record will be included in an output file. PDE records WILL NOT be determined as "missing" if the following business rules are met: - Business Rule 1: If a record is a rejected record on a previous fiel and is an accepted record on the current file, this is acceptable and should not be reported as a missing record. - Business Rule 2: If a record is a rejected record on the previous file, but the record is determined to be a "NFAR" (No Futher Action Required), this is acceptable and should not be reported as a missing record. Therefore, the rejected record should be searched (search criteria to be delivered during Elaboration) for in the Project table (and validated to be in an NFAR Project) before excluding the record from the missing records output. The work object is closed, the record status in the Project Table is changed to closed and the closure reason code is set to NFAR. - Business Rule 3: If a record is rejected on the previous field and not found on the current file, the process must validate that specific PDE record is not included in the Project Table. IF the record is associated with a project, this is acceptable and should not be reported as a missing record. - Business Rule 4: If a record is an Accepted record in the current file and was also an Accepted on the previous file, this is acceptable and would not be reported as a missing record. - Business Rule 5: If a record was Accepted on the previus file and is not included (Accepted or Rejected) on the current file, this is acceptable and would not be reported as a missing record. - Business Rule 6: If a record is Accepted on the current file but was not present (Accepted or Rejected) on the previous file, this is acceptable and would not be reported as a missing record. - Business Rule 7: If a record was rejected on the current file but was not present (Accepted or Rejected) in the previous file, this is acceptable and would not be reported as a missing record. ELSE, the rejected records outputted from the compare/diff process would be considered "missing" and a work object would be generated and assigned.
3.3.1.2 ngError
Use Case - UC_PDE_Missing_0002_RouteMissingError
Step - RouteMissi
Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description
All work objects will be automatically routed to the MBA ... Automated Step New Any Work object is created for missing PDE records Work object is listed in corresponding MBA work basket Triggers: Complexity: Low
All work objects will be automatically routed to the MBA Missing PDE worklist NOTES: - There might be a time lag that PRPC App will need to manage for the business. - These missing PDE work objects must appear in their own list view or at least easily separated from the rest of the items in MBA Researcher work basket/list Linked Requirements: Requirement Name
Category
Importance
3.3.1.3 rNFAR
Use Case - UC_PDE_Missing_0003_ProcessMissingError Short Description: Shape: Status: Actors:
Step - MissingErro
1. MBA Researcher selects work object to process2. MBA Resear... Human Based Step New MBA Researcher Triggers: Complexity: Low
Pre-Conditions: Post-Conditions: Description
Work object is listed in corresponding work basket Research documented and work object closed
1. MBA Researcher selects work object to process 2. MBA Researcher documents research as required in the supplied PRPC screen (see attachment) 3. MBA Researcher designates the work object as NFAR 4. The work object status is set to closed 5. The work object is removed from the work queue NOTE: - All research will happen outside of the PRPC application - Need clarification on where research is going to be conducted/what tools are going to be used.
Alternate Steps for StartMissingPDEs (Page 84) 3.3.1.4 rRecovered

Use Case - MissingErrorRecovered Short Description: Shape: Status: Actors: Description If a record was missing and a missing work object was created, but is listed again in a subsequent file then the missing work object needs to be closed. If a record was missing and a missing work object was created... Automated Step New Any Triggers: Complexity: Low
Step - MissingErro
3.4 Supporting Type - Search

Describes the general process for searching for work objects.
3.4.1 Supporting Type Search includes the following Use Cases: 3.4.1.1 _0001_EnterCriteria
Use Case - UC_PDE_Search_0001_EnterCriteria Short Description: Shape: Status: Actors: 1. User defines critiera2. User submits criteriaPlease note t... N/A New Any Triggers: Complexity: Low
UC_PDE_Search
Pre-Conditions: Post-Conditions: Description 1. User defines critiera 2. User submits criteria
PDE database tables are available for query Defined criteria successfully submitted to System for query
Please note the following: 1. User will be able to perform a simple search or an advanced search - Simple search options are always displayed; search can be triggered from any screen - Advanced Search option: when clicked will display an advanced search screen with submit and cancel options 2. Simple search - 2 options - Search by Claim Control Number - Search by Member ID 3. Advanced Search - will allow a search to be conducted on the following criteria - Member ID - HICN - Claim Control Number - Date of Service - Product Service ID (NDC) - Comment (drop down list selection) - Date last updated - Service Provider - Prescription Service Reference Number - Error Code Fields ** Parameters will be used for things like Date of Service, Date last updated, Error Code Fields. This would mean that it can be a date range, or a combination of a specific date + multiple disparate date ranges so the business will need to have the ability to add search fields on the fly*** CONSIDERATIONS: Current error history is maintained within an Access DB. Need to determine what information will be available on the record detail screen and what information, if any, from the Access DB will be initially brought in for in progress errors. Linked Requirements: Requirement Name
Category External ID Importance
Description Allow for end users to query and view current and historical data of one to many PDE records and all associated data (using first 15 digits of the PDE claim #). > This can be driven by various fields like HIC#, Claim #, Date of Service, etc. > The screen will be
BR_PDE_0004_PDE Inquiry History Screen Functional FUN.007
available during research of a PDE record or via Reporting screen. > Selection screen should: - Allow for dynamic selection of available fields to be entered into the screen or txt file uploaded when multiple records need to be displayed. - Denote if the record was previously NFARed - HNPS needs inquiry screen to view Project table
3.4.1.2 _0002_DisplayResults
Use Case - UC_PDE_Search_0002_DisplayResults Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description 1. System runs a query on the defined criteria 2. Matching work objects are listed on the results screen
UC_PDE_Search
1. System runs a query on the defined criteria2. Matching wor... N/A New Any Valid search criteria submitted Query runs and results are displayed Triggers: Complexity: Low
NOTE - Whether a simple search or advanced search, search criteria field(s) will be displayed with defined value populated Linked Requirements: Requirement Name
Category Importance
Description Provide Users with the ability to print and/or save the search results list. > Print will just print all records returned for that search in printer friendly
BR_PDE_0016_Ability to Print/Save Search Results Functional
format > Save will convert the all records returned for that search into a csv or xls format and prompt the User to save
3.4.1.3 _0003_DisplayDetails
Use Case - UC_PDE_Search_0003_DisplayDetails Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description
UC_PDE_Search
1. User clicks on a work object from the results list2. Syste... N/A New Any Search yielded actual results Details for the selected work object are displayed Triggers: Complexity: Low
1. User clicks on a work object from the results list 2. System displays the detail screen for the corresponding work object - Details on this screen are read only - Business to define what field values are to be displayed on this screen and default sort order for results Linked Requirements: Requirement Name
Category
Importance
Description When a User opts to view the "history" associated to a specific claim number or member ID, all of the history associated to a specific claim #/member ID should be displayed - even if it is across multiple work objects.
BR_PDE_0049_Viewing History Business Rule
3.4.1.4 _0004_NoResults
Use Case - UC_PDE_Search_0004_NoResults Short Description: Shape: Status: Actors:
UC_PDE_Search
1. System runs a query on the defined criteria2. System finds... N/A New Any Triggers: Complexity: Low
Pre-Conditions: Description
Valid search criteria submitted
1. System runs a query on the defined criteria 2. System finds no match to the defined criteria 3. System displays No Results page NOTE: - Whether a simple search or advanced search, search criteria field(s) will be displayed with defined value populated - User will have the ability to modify search criteria and resubmit query - User will also have the ability to Cancel search function
3.5 Supporting Type - Security

Use cases dealing with authentication, authorization
3.5.1 Supporting Type Security includes the following Use Cases: 3.5.1.1 _0001_LogIn
Use Case - UC_PDE_Security_0001_LogIn Short Description: Shape: Status: Actors: Users will log onto the system using SSO and LDAP. Credential... N/A New Triggers: Complexity: Low
UC_PDE_Security
HNPS Group Lead, HNPS Researcher, MBA Group Lead, MBA Researcher, MBA Management, Membership Group Lead, Membership MA-PD Researcher, Membership PDP Group Lead, Membership PDP Researcher, Membership Researcher
Description Users will log onto the system using SSO and LDAP. Credentials will be entered on the portal screen and the control will be passed over to PRPC. 1. The User accesses the PRPC Login Screen 2. The User enters and submits login details (AID&corresponding password) 3. The System verifies details 4. The System displays the corresponding default screen based on the access group associated to the account NOTES: - Details that will appear on the default screen for each User type will be determined during Elaboration. This includes, but is not limited to: --> The different views that the User type should have including which is the default view --> The different field values that would be displayed per view --> The default sort order
- There will need to be a unique screen per the following User type (business to confirm): -> HNPS Researcher -> HNPS MA-PD Researcher -> HNPS PDP Researcher -> MBA Researcher -> Membership Researcher -> HNPS Group Lead -> MBA Group Lead -> Membership Group Lead -> MBA Management Linked Requirements: Requirement Name BR_PDE_0001_Front End User Profiles
Category
External ID Importance 1 - Critical
Description The System will provide access to different features and functions based on different login levels. This would include, but not be limited to views/access for: HNPS, Membership, MBA, display only Provide the ability for the Users to sort their views. Please note the following: > Users will have the ability to sort in ascending or descending order > work objects impacted by Urgency Points will also be resorted, but will still have a visual indicator to their urgency (e.g., remain in bold face font or bold face red font) > when the User has more than 1 work list the Sort By function will be applied only to the current work list
BR_PDE_0017_Ability to Re-sort Work Lists Business Rule
1 - Critical
> When the User logs off, the sort for the impacted work list will return to the defaulted work list sort when the Researcher logs back on BR_PDE_0009_Update to front end fields Business Rule FUN.010 1 - Critical Update the fields to be viewed and sorted in the front end for Membership and HNPS. Final list of fields that need to be displayed for each User type will be finalized during elaboration. Create a Web Based Front End that allows each group to view and research their specific errors. Please note the following: > A PDE can only be with one group at a time to research. > Only the group actually working the work object can edit the details, all others can only view the details BR_PDE_0039_Hierarchical Access Business Rule 1 - Critical The roles within the application have some kind of hierarchy. This means that anyone with one role can access all the other role type functions that are contained within the roles
BR_PDE_0003_Web Based Front End
1 - Critical
below them. For example, a Group Lead will be able to "step down" to the role of a Researcher in order to perform Researcher functions. The MBA Management role is the highest level on the hierarchy. Business to provide hierarchical list during elaboration.
3.6 Supporting Type - DataManagement

Use cases specific to managing lists of products, reference data tables, broadcast messages
3.6.1 Supporting Type DataManagement includes the following Use Cases: 3.6.1.1 001_ManagingPulldownValues
Use Case - UC_PDE_Data_0001_ManagingPulldownValues Short Description: Shape: Status: Actors: Description The MBA User will have the ability to manage what values are displayed in the different pulldown menus available in the PDE PRPC application. This would include the ability to not only change what options are listed, but to also determine what options are listed per User type ("visible when" type of logic). This would include being able to manage the Project List values. All pull downs needed and corresponding values will be discused during Elaboration. Please note the following: 1. Although the capabilities are available within PRPC as a System Administrator type of User, this The MBA User will have the ability to manage what values are ... N/A New MBA Management Triggers: Complexity: Low
UC_PDE_Data_0
is a customized feature that will need to be created and made available to the MBA Management user type only 2. Full details will be discussed during Elaboration. This could include things like: 3. 1. If new fields need to be added on the fly or if the ability is just to update options within existing fields 2. If this will apply to pulldown options only or if the team will need the ability to also update field labels 3. etc...
Linked Requirements: Requirement Name
Category External ID Importance
Description Maintenance access to Lookup tables needed for all fields with drop down values, including but not limited to: PDE Error Code Assign New User HNPS User Fields Membership User Fields Project Look-up List PDE Record Status Codes PDE Reaston Status Code Research Detail Comments (HNPS, Membership and MBA) Action Taken NOTE: Maintenance rights should be given to MBA
BR_PDE_0007_Management of Pulldown values Functional FUN.008
3.7 Supporting Type - SysAdmin

Use cases specific to managing operator profiles, calendars, skills, rule migration/promotion
3.7.1 Supporting Type SysAdmin includes the following Use Cases: 3.7.1.1 min_0001_Re-assignWorkObjects
Use Case - UC_PDE_SysAdmin_0001_Re-assignWorkObjects Short Description: Shape: Status: Actors: Description Group leads will be able to reassign one or many work objects from one user to another at one time. Note: During demostrations it was been confirmed that the out of the box functionality as it exists within the Manager Portal meets the needs of the business. Group leads will be able to reassign one or many work ob... N/A New Triggers: Complexity: Low
UC_PDE_SysAd
MBA Management, HNPS Group Lead, Membership Group Lead, MBA Group Lead, Membership PDP Group Lead
Linked Requirements: Requirement Name BR_PDE_0006_Re-assignment of Unconfirmed records
Category External ID Importance Functional FUN.007 1 - Critical
Description MBA Users must have the option to retrieve unconfirmed PDE records and re-assign Group Owners need to be able to query to determine and assign specific error codes to researchers. More specifically, Group Owner needs to be able to grab their error population and assign out by the error code. Then if file is too large then an error code may go to more
BR_PDE_0011_Group Owner Assignment Capabilities
Functional FUN.012
1 - Critical
than 1 member. Break out unique HICN count by year and by pharm vs elig error groups; can then break out the assignment by a single error code. Be able to select the error codes that are needed for the assignment. A one to many error query.
3.7.1.2 min_0002_SuspendUserRouting
Use Case - UC_PDE_SysAdmin_0002_SuspendUserRouting Short Description: Shape: Status: Actors: Description
UC_PDE_SysAd
Group Leads need the ability to prevent the System from assig... N/A New Triggers: Complexity: Low
MBA Management, HNPS Group Lead, MBA Group Lead, Membership Group Lead, Membership PDP Group Lead
Group Leads need the ability to prevent the System from assigning work objects to Users. An example of when this would be needed is if that resource is out on PTO. 1. Group Lead will access the My Group area 2. Group Lead will select a Resource to update 3. Group Lead will be able to define dates the Resource is unavailable NOTE: It was determined during a demonstration that the standard out of the box capabilties will suffice for this Use Case/Requirement.
3.7.1.3 UC_PDE_SysAd min_0003_ManageUserProfiles_duplicate2

Use Case - UC_PDE_SysAdmin_0003_ManageUserProfiles_duplicate2 Short Description: Shape: The MBA Team will have the ability to manage User accounts an... N/A Triggers:
Status: Actors: Description
New MBA Management
Complexity:
Low
The MBA Team will have the ability to manage User accounts and what access each User has. This includes managing who can work on what errors, user skill level, etc. Skill type is something that is managed in a User's Profile under the My Group area. What skills are available, etc are all part of standard PRPC functionality that the business has confirmed meets their needs during a demostration. The ability to manage Users who have access to the application is a function that will happen separately and be administered by the PCOE or Sys Admin. New User requests will need to be submitted by the define process. The ability to allow the business to manage what Access Group the Users belong to is a customization that will need to be completed. The capabilities are available to the System Administrator within PRPC, but they are not available in a "gadget" that is then available to a manager or other similar user type. The capability of only managing access group will need to be opened up to the MBA team. Linked Requirements: Requirement Name
Category
Importance
Description MBA team will have authorization to add new members to the different user groups based on template request form filled out by Group Owner.
BR_PDE_0038_Managing Access Rights Business Rule
3.7.1.4 min_0004_ManageRoutingRules
Use Case - UC_PDE_SysAdmin_0004_ManageRoutingRules Short Description: Shape: Status: Actors: Description
UC_PDE_SysAd
The business needs the ability to update routing rules based ... N/A New MBA Management Triggers: Complexity: Low
The business needs the ability to update routing rules based on current business needs. The criteria that needs to be updated needs to be identified so that only those elements can be exposed to the business users.
3.7.1.5 min_0005_Releasing Projects

Use Case - UC_PDE_SysAdmin_0005_Releasing Projects Short Description: Shape: Status: Actors: Description
UC_PDE_SysAd
The User will have the ability to "release" projects from the... N/A New MBA Management Triggers: Complexity: Low
The User will have the ability to "release" projects from the active project list. Essentially, 1. The User will acess a screen that has all of the active projects listed 2. The User will select which projects need to be released and click some kind of submission option 3. The System will 4. 1. Close the selected projects 2. Close any work objects associated to the selected projects 3. Remove the projects from the corresponding pulldown menus in the PRPC application CONSIDERATIONS --> What happens to a work object that is midstream in the process but whose corresponding project was released --> When claims are associated to the project and stored in the project table and MBA is notified that the project is done, there is a need to fully close the record in the Project ("pending") table. - Close changes the record status - Moves the final copy to the PDE History table *** Is the record also removed from the project table? In other words, are we cleaning out the table as work objects are moved to the PDE History table? ***
4 Interfaces
The Pegasystems solution will interchange with the systems described in this section using the protocol specified. Name Protocol Data # of Description Source Interchanges Exists Pega Database PDE Schema on PAOS Database ABS Membership Unknown Unknown ServiceYes Yes Yes Need to determine if it should be ABS or
Name
Protocol
Data Source Exists
# of Interchanges
Description
SOAP Bluezone emulator Unknown for CMK Informatica MC400 CSC Market Prominence Marx Unknown Unknown Unknown Yes Yes Yes Yes
TR. If we need 24/7 access then we need to use TR. TR is the preference. RxClaims system
Need to clarify what data we will be pulling from MC400 This is the eligibility system for PDP members only. This is the external Pega application managed by CSC. CMS System (web based)
Unknown
Yes
5 Reports and Correspondence

It is Pegasystems philosophy that decisions about reporting are best made after some experience with the system. Therefore, reporting activity typically occurs as a separate initiative and may require that Health Net, Inc. export data from the system to a data warehouse. Customers typically find that they can overlap these data warehouse initiatives with user acceptance testing. Reports - We expect that the standard reports will be supplemented by 20 custom reports. We expect that out of the boxreports will be supplemented by 8 custom reports. Details for the out of the box reports will come from the Pega tables. This means those reports will only have those details which occur through the Pega work flow process. Please note that PRPC supports "static display" reports. In other words, business intelligence/more dynamic reporting cannot be generated/initiated from within PRPC. This could included, but not be limited to, the following types of reports: - Adhoc reporting - Multi-dimensional reporting - Drill down reporting Name Category Complexity Description Work List Age ByWork Queue IC Age By AssignmentMonitoring Low AssignmentMonitoring Low AssignmentMonitoring Low This list View rule displays the worklist for selected operator ID. Timeliness by work queue based on established SLAs Timeliness by operator based on established SLAs
Name Assignee IC Age By Workgroup Assignee
Category
Complexity
Description Timeliness by workgroup and operator based on established SLAs Timeliness by flow task based on established SLAs Average processing time per task
AssignmentMonitoring Low
Age ByWorklist AssignmentMonitoring Low TaskIC Action Performance Time IC Age ByFlow Assignment IC Performance Detail Count Resolved By Resolver Top5IC Weekly Throughput IC Generate Statistics PerformanceAnalysis Low
PerformanceAnalysis PerformanceAnalysis WorkAnalysis
Low Low Low
Timeliness by flow and task based on established SLAs Summary of processing time, idle time, and overall duration per task for a given flow Count of processes resolved by top 5 operators
WorkMonitoring
Low Medium
Throughput in past week by work type, including previous balance and current status Counts of PDE work objects in work lists and work baskets - displyed at top of user screen. This would be a display for Group Leads only.
Year over Year PDE Totals ( Acturial) Errors by Project Success of Individual Project
Low
Sum of paid amounts (included in the PDE fields provided to researchers). Which fields to be determined during elaboration. Count of Error values for work objects assigned to a project. Questions on the reuqirements to be answered during elaboration. Count of work objects associated with project(s) compared against subsequent accepted PDE records across the year. Includes what percentge of PDE Errors were corrected by the project they are assigned to. We may be able to accommodate this with an OOTB report but need to verify. An item may be rejected on several occassions, then be accepted, and then be rejected again later. If an item has been accepetd, but rejected again, the report needs to then run off the oldest date that exists in the series of consecutive rejections. Once an item is accepted everything essentially starts over again. In other words, the aging for that error starts over again.
Low
Low
Age by 1st Rejection Date
Low
Name Skill sets by User
Category
Complexity Low
Description --> Look at using the julian date from the file ID Provide managers with a report that details what skills are currently associated to each of their team members. The report would essentially list a team member's name and then detail all the skills currently associated to that User. It was confirmed that these details do exist in PRPC, but that a custom report needs to be created in order to display the details in this manner. Full details to be flushed out in Elaboration.
Sum of Error Dollars Missing Error (PDEs) Aging Report
Low Low
Details will need to be finalized during Elaboration. Report sample is preferred if possible. Need a report that identifies how long a Missing Errors have not been recycling from PDE file load. This is essentially an aging report; there may be an OOTB report to meet this need. This would be if a rejected PDE is not listed in a file load and a missing error work object is created. After a XX (parameterized) subsequent file loads the work object is still open the business needs to made aware.
Diff Report
Low
Group Leads need a report that details out the difference between what work objects are a Researcher selected to assign to the Group Lead and what work objects did actually get assigned. BACKGROUND There are scenarios where although a Researcher says a work object should go to a Group Lead that the work object will not be assigned since it was closed for a different reason prior to the physical reassigment process. ADDITIONAL NOTES - The report will be delivered to the Group Lead on an interval that is TBD during elaboration (e.g., "x" days) - The report will contain only those details relevant to that particular Group Lead - The report SHOULD NOT include details about accepted files - The work object will need to have something started against it that is searchable so that the Group Lead can search for those work objects that didn't get assigned to them and view the details if needed.
Fall Out Report
Low
If the work object is already in a different project and
Name
Category
Complexity
Description its not allowed to be put in a new project, then the System will 1. Add a record to the history table with a standard reason (Fall Out Report XX/XX/XXXX) 2. Create a fall out report that details why it could not be inserted into that project. Full details for the report to be finalized during Elaboration
Correspondence - The Pegasystems solution is expected to generate approximately 3 pieces of Correspondence (email, letter, PDF). Name Success of Project file load Complexity Low Description PEGA will be loading the indvidual proejct lists (from Membership or HNPS) to indicate which file is loaded (file name) and the record counts. Sent to PDE@healthnet.com PEGA will be loading Project list file(s). Should any of those load processes fail, the business wants an email notificaiton. Notification informaiton should include the name of the file that failed during the load process. Send to PDE@healthnet.com An email will be sent to the Group Lead that summarizes the assignment totals. This will be one email per Group Lead type that summarizes the totals for only those Researcehrs/Work baskets the Group Leads are responsible for. The specifics on the details/format of the email will be determined during Elaboration.
Failure of Project Low list loads
Assignment Notification ( Initial Load)
Low
6 Prerequisites
Prior to project start, the following prerequisites must be met: } } } } Customer to name team members by role Customer to send each team member to appropriate role based training Joint agreement on an iterative implementation methodology, it is recommended to conduct a Method Adoption Workshop Joint agreement on a formal governance structure and process
7 Project Participants and Roles

Health Net, Inc. Role Alloc. Project Manager Business Architect System Architect 1.0 FTE 1.0 FTE 1.5 FTE
Responsibility / Work Project Plan, Overall Project Success
Enablement Plan Business Architect Essentials
Create/Validate Use Cases, Create Customized Reports and Business Architect Correspondence Essentials Create Flows, Modify Flows, Add Decision Tables, Decision Fast Track, Boot Trees, Change Harness Sections, Design Test Cases Camp
Pegasystems Certified Partner Resources Role Alloc. / Location Technical Engagement Leader Lead System Architect System Architect 1.0 FTE / On Site 1.0 FTE / On Site 1.0 FTE / On Site
Responsibility / Work
Lead PRPC Technology insertion and adoption within the customer organization, Guardrail Compliance, Project Governance, Support Project Plan and Methodology Create functional Design, Construct Class Hierarchy and Object Models, Define Test Strategy Implement Activities and Methods, Implement Pega-Responsible Services and Connectors Governance, Executive Support Interfaces with User/User Representatives to capture user needs and goals. Interfaces with developers to ensure the users' needs and goals are expressed in the User Interface design. Manages User Interface Design with regards to Visual Design, Navigation, Information Design and Task Analysis. Establishes Usability goals and resolves Usability issues as necessary.
Practice Leader 0.1 FTE / On Site User Experience Architect .25FTE / On Site
8 Functional and Performance Testing

Functional and performance testing tasks will be conducted as follows: Health Net, Inc. will develop the Functional and Performance test strategy Health Net, Inc. will agree to the test strategy during the Elaboration phase; agreement must be reached in a timely manner so as not to hold up project execution
Health Net, Inc. will jointly develop the test plan for the Process Commander components of the system during the Elaboration phase; development must be completed in a timely manner so as not to hold up project testing Test Plan and Test Scripts will be developed in accordance with the Pegasystems testing Guardrails Health Net, Inc. will be responsible for developing the test scripts and preparing and executing those test scripts. The test plan will be reviewed and approved by the consulting team and Health Net, Inc.
9 Client Enablement/Training
Training is essential in helping to ensure a successful Pega Rules Process Commander Go-Live. There are several benefits to our PRPC training: } Increased self-sufficiency and productivity } Realization of the Build for Change value proposition, as PRPC-trained business analysts respond directly to expected changes and evolving project requirements } Faster response to new business demands due to lower reliance on external resources } Trained delivery project team members design and build solutions faster } Project risks minimized with trained and certified staff } Skill development for business and IT staff as they acquire new business process management knowledge } Lower total cost of ownership by utilizing in-house skilled resources At a minimum Pegasystems requires a single resource be trained as a Pegasystems Process Commander administrator by taking the PegaRULES System Administration course. This role is critical for all projects during both implementation and post production support. Client resources that will be performing the project roles are also required to take Fast Track to PRPC and PRPC Bootcamp training to help facilitate project implementations. The timing of training is critical; we recommend 2- 6 weeks in advance of a project start. Training positively increases the effectiveness of team members ability to lead projects, and ultimately, the quality of the final deliverable. Individuals who take training at the right time retain the knowledge needed to keep projects on track and contribute productively to the project. The aforementioned courses can be taken at a Pegasystems public training site, virtually or can be delivered onsite to the customer. Information about additional training courses and pricing can be found on our web site at:
http://www.pega.com/Services/EducationalServices
10 Governance and Communications

Project Governance is essential to the successful delivery of any project. The governance model described below ensures that the projects goals are achieved, through:
} } } }
The monitoring of progress and achievement against plan The monitoring of budget Management and escalation of issues and risks Effective Change Control
Strong project governance is achieved by carrying out the following: } } } } } } Implementing an Executive Project Steering Committee Weekly Project Status Reports Regular Project Meetings Risk Management having a risk register and adequate mitigation strategy Issue Register with owners and target dates Change Control Process which includes solid impact analysis against the plan
10.1 Project Status Reporting

The Pegasystems Project Status Report (PSR) is the responsibility of the Engagement Leader with input from a number of sources including but not limited to the client Project Manager. This PSR will be circulated on a weekly basis to Customer Project Manager and Account Manager and will be one of the artifacts reviewed as part of the Governance Process. This document provides an update on progress of the project as well as project health indicators which measure the projects health in the following areas: } } } } } } } Overall Status Customer Success Technical Legal Schedule Hours to budget Resources
PSRs are critical piece of the communications process. They provide the raw data that support the current state of the project. They are also used to inform the executives regarding the current status of the project during the Governance Meetings.
11 Assumptions
The following assumptions are critical elements of the functional, schedule, and staff aspects of this proposal. Should these not occur in accordance with the agreed to project schedule then project delays and overruns are deemed the responsibility of the customer. Many of these assumptions embody an iterative implementation philosophy, where the initial implementation is often continuously improved at a frequent pace, based on changes in actual experience. PRPC authentication will be the security mechanism Customer will be responsible for exporting data
Project Sponsor will provide external connectivity to development and test environment for the Pegasystems team members on project commencement Project Sponsor will be responsible for procurement, installation and provisioning of all hardware and non-PRPC-related (third party) software Project Sponsor will provide working facilities, desktops and required software licenses for all resources to work on this project at the requested location. There will be well-defined, documented interfaces for connecting to back-end systems. These will use mechanisms supported by PRPC ( SOAP, MQ, EJB, JDBC). There will be stubs that return accurate representative data where interfaces are not immediately available. Project Sponsor has a test region with access to data that accurately represents test and production information. Project Sponsor will independently build and configure interfaces for external applications as part of the proposed work. Implementation of the application, including the UI, is expected to be handled through out-of-thebox (OOB) rules provided in PRPC with minimum customizations. Standard Harnesses based on standard UI framework and HTML rules (minor modifications to a couple of HTML properties is acceptable) Standard Work Items, Covers (and Folders if needed) Standard Routing and Assignments. Word correspondence based on HTML generation, with standard PDF Generation as indicated in the Use Cases. Standard SLA handling and Notifications. Standard Input Validation. Standard Interfaces to External Systems (including error handling). PRPC authentication will be the security mechanism for this project unless there is an explicit alternative specified in the Interfaces. Production roll-out and training is out of the scope of this proposal. Project Sponsor will be responsible for exporting data into a customer-defined data warehouse or developing ad hoc reports from SQL Output.
12 Appendix A Unassociated Requirements

The following is a list of the Business Requirements that must be met to ensure Business acceptance. These requirements are not referenced in any of the use cases above.
Requirements request list as follows: Requirement Name BR_PDE_0002_Load MBA PDE tables (history) Category Data Load External ID Importance FUN.004
> Load the MBA PDEPRD tables in PDE605 > ITG confirm the data is complete > Create load and balance reports counts. Email reports to PDE@hea Please note:
> Access to the current MBA PET t > The export will be set to export b process. > The DBAs who are exporting the listed in the original project BARR t each of the tables are. > The DBA who is importing the MB tables were created in the new prod process has completed. The expor counts. > As part of this import/export proc new tables BR_PDE_0008_Table Updates for New Fields BR_PDE_0010_Tracking of PDE and related modifications Non_Functional Non-Functional FUN.009 FUN.011 FUN.014
Update the tables for new fields. Fi
History tables should identify the P
BR_PDE_0012_Audit/Balance/Error Reporting Reports
Audit and balance reports, and erro tables.
BR_PDE_0013_Email Notifications Correspondence_Rule FUN.015 of Audit/Balance/Error Reports
Email notification to be sent to each successfully loaded: ==> CTS Informatica process will l ==> PEGA process will create the n ==> Group Lead email address ma ==> Email notification to include the ==> File Name (File ID from PD ==> Total new work objects ass example: HNPS Group Lead and counts and all new MBA work objec Membership PDP Group Lead wou
Sucessful Project file loads would a ==> See note above for Group Lea ==> Email notifiacation to include th ==> Project File Name and file d ==> Total records in file ==> Total work objects assigned ==> Total project records loaded ==> Total number of open work
Whenever a PDE file, Report 1 file sent to all the Group Leads. ==> Email Notification will include for file load resolution and ETA info BR_PDE_0014_Email Group when Correspondence_Rule FUN.016 Records available for research BR_PDE_0015_Reporting BR_PDE_0044 Research Details History Update Reporting Business Rule FUN.017 PID 11488 FUN.004
Send an automated email to the co
Year Over Year Report Errors By P
3 - Important Business has been using an Acces been doing on open PDE Error Rec update must take place to "append
Business will supply a file from the work objects regardless of what wo
PEGA process will also move a cop the PDE History table.
When the business user clicks on t historical research details and be a and update the research details.
Next steps (such as sending the wo Process.
Because of the volume of the data before the PEGA PDE Error Tracki production. BR_PDE_0048_Table Creation Business Rule
The following tables need to be cre Project PDE History Exception
BR_PDE_0051_Reason Codes
Business Rule
In order to better track why work ob For example, if a work object is clo
- status would be "closed" - the reason code would be "accep
A final list of reason codes will be p BR_PDE_0052_Needed History Reporting
The business needs 10 years worth written to tape after it is past the 10

PDE AP 20111229 Updated AJ

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

PDE AP 20111229 Updated AJ

Caricato da

Copyright:

Formati disponibili

PDE PDE Version 1

Health Net, Inc.

Presented on Tuesday, January 17, 2012

1.1 The Opportunity

1.2 The Benefits

1.3 Initial Solution Target

1.4 Implementation Approach

2.1 Frameworks Overview

2.1.1Healthcare Payer Industry Framework

2.2 Duration and Timeline

6 8 Weeks Elaboration Construction

3 Work Types, Processes, and Use Cases

3.1 Work Type - PDEError

3.1.1 Process - StartPDEError

Primary Path for StartPDEError (Page 8) 3.1.1.1

Category Business Rule

BR_PDE_0050_Routing Revalidation Business Rule 1 - Critical

3.1.1.3 or (Page 21) 3.1.1.4 upLead

Step - ProcessErr Step - RoutetoGro

Short Description: Shape: Status: Actors: Pre-Conditions: Post-Conditions: Description

BR_PDE_0050_Routing Revalidation Business Rule 1 - Critical

BR_PDE_0047_Confirm option for Group Lead Business Rule 1 - Critical

3.1.1.6 routeError (optional)

BR_PDE_0050_Routing Revalidation Business Rule 1 - Critical

Alternate Steps for StartPDEError (Page 8) 3.1.1.8

3.1.1.10 or (Page 25) 3.1.1.11 openError

Step - RecycleErr Step - Re-

Use Case for Process

Status: Actors: Pre-Conditions: Post-Conditions: Description

Business Rule FUN.007

Primary Path for ProcessError (Page 21) 3.1.2.1 ror

BR_PDE_0037_Minimize Manual Entry of Details Functional 1 - Critical

Alternate Steps for ProcessError (Page 21) 3.1.2.3 Member

BR_PDE_0043_Resolve Errors by Member ID Functional 1 - Critical

Use Case for Process

Type: Status: Actors: Description

Sub Process New Any

Triggers: Complexity: Low

Primary Path for RecycleError (Page 25) 3.1.3.1 ed

Alternate Steps for RecycleError (Page 25) 3.1.3.2 Rejected

3.2 Work Type - Project

3.2.1 Process - StartProject

Primary Path for StartProject (Page 30) 3.2.1.1 ption

PDE Project Data Load EAS_002_draft_Mary_V1.doc:

PDE Project Delta Data Load Non EAS_002a_draft.doc:

into PDE PET Project List table.

Determine if duplicate records exist in project list Delta file.

Update the Record Status field with DC (Delta Closed)

Update the Reason Code field with Delta

Determine if PDE Delta

(1) If record does not exist in Project List table, insert

PDE Project Data Load_RR_002b_draft.doc:

3.2.7DRAFT 3.2.8Use Case Name: PDE_002b 3.2.9

PDE Project Data Load (R&R) Use Case #:

Determine if duplicate records exist in project list file.

PDE Project Delta Data Load_002b_draft.doc:

Determine if duplicate records exist in project list Delta file.

Update the Record Status field with DC (Delta Closed)

PDE Project Data Load_CC_002c_draft.doc:

Determine if duplicate records exist in project list file.

Determine if Project Already Exists in Project List table

If record does not exist in Project List table.