Pw08 Ibc Final Pie Ppt 090508

BPM Fueled Care Management “PIE Automation” Chuck Schneider, Darlene Lankford & Wendy Dooley

Case Study Table of Contents Precertification Intake Encyclopedia (PIE) Intro Chuck Schneider IBC Middle Office Project Vision Buy vs. Build Background Why Pega? “Easy as PIE” Implementation Best Practices Leveraging Methodology 2.0 Built for Change – Recipe for Success Business & IT Teaming to Win & Reusability Results Before and After Pega “Just Desserts Demo” What’s next… © 2008 Pegasystems Inc.

Independence Blue Cross Founded in 1938 as “Associated Hospital Service of Philadelphia” Five-county region of SE Pennsylvania 3.4 Million members 51,655 Employers 9,000+ Employees 32+ Million claims annually $11 Billion revenue © 2008 Pegasystems Inc.

IBC Middle Office IBC Middle Office supports medical cost and quality management through network management, data analysis, and oversight of care delivery. ,[object Object]

Medical Management Supports & facilitates delivery of quality healthcare services Clinical & non-clinical staff Pre-certification of elective services Medical review of inpatient hospitalizations and other medical services and equipment Discharge Planning Case Management © 2008 Pegasystems Inc.

Precertification – Beginning State Multiple insurance products Multiple pre-cert lists Over 5,700 covered procedures Over 130 discrete process “flows” PAR considerations Interpretation required by specialist Completely manual process © 2008 Pegasystems Inc.

Client Needs Flexible: Adapt to evolving business needs Business Ownership: Minimal IS intervention for routine maintenance tasks Reactive: Quick turnaround for routine changes Documentation: Supplied by tool Sharable: Other applications can benefit Traceable: Track all transactions Data re-use: Leverage data entry to build medical management case © 2008 Pegasystems Inc.

Logistical Considerations Real-time data needs Decision criteria resides in five systems Medical Management system is vendor-supplied Response times Minimize talk-time Minimize new-user training © 2008 Pegasystems Inc.

So, why Pega? ,[object Object]

Precert Intake Encyclopedia Background © 2008 Pegasystems Inc. Like most “Encyclopedias” you must manually look up the information you need and read and interpret the content in order to make use of it…then update it on an ongoing basis or the content quickly becomes obsolete or inaccurate. The “PIE” was aptly named – It contained precert intake information that had evolved over a five-year period. The “PIE” was manually maintained and contained 130+ business process and procedural rules in “XLS Comments” for 5700+ service codes that vary by line of business, product type, provider, member location and/or service setting!

Leveraging SmartBPM® ApproachPre-Inception Phase © 2008 Pegasystems Inc. Prior to Inception onset, in addition to defining the Project Vision and Scope, the IBC Team members worked directly with the HRC Business Sponsor, Managers, Supervisors and Precert Specialist to define and document the “current state” business requirements and work flows. ,[object Object],All IBC dedicated team members also completed Fast Track, Boot Camp and BAE training. IBC worked with the Pega EL throughout the Pre-Inception Phase to define/refine the Pegasystems Application Profile and SOW. Which enabled both docs to be completed and fully executed prior to the onset of the Inception Phase.

“Built for Change” The PIE Recipe for Success © 2008 Pegasystems Inc. Identifying and allocating both IT and Business team members 100% for the duration of the project Enabled team members prior to project onset Right-sizing the project scope – The initial release for this project was limited to phone intake for Elective Procedures. Emergent and Urgent services, as well as IVR and Web intake methods are slated for future releases. Involved Business Stakeholders and COE representatives throughout the Project Life Cycle Built the solution for change and reuse from Day 1 in keeping with both short-term goals and objectives and long-term enterprise-wide vision and strategy Interfaces to back-end systems were created specifically with reuse in mind and were built at the “Shared” level in the application Leveraging PRPC & HPIF “Out of Box” Capabilities & Properties…modeling flows and UI in the system and demonstrating those capabilities to the stakeholders prior to creating and adding custom or specialized components. And last but not least, upgrading to 5.4 to enable the project team to fully utilize the DCO suite of tools and wizards that facilitate implementation using Methodology 2.0

Business and IT – Teaming to Win! It’s a fact, teams can make or break a project. We had an exceptional combination of Core Client and Pega IT and Business dedicated team members, most of which had not used 5.4 or DCO – but were eager and willing to embrace it 100% Highly supportive and engaged extended team members which included: An Executive Sponsor, COE Participants, PMO Support, Project Manager, Governance Team, Trainers, Testers and End Users. All of these supporting team members collaborated on an ongoing basis with the core team. They responded to requests in a timely manner, provided ongoing verbal and written feedback, made timely informed decisions with regard to Change Control Requests, and steadfastly adhered to and complied with Pega recommended best practices, and Methodology 2.0. When an organization as a whole provides that kind of support you have one heck of highly motivated team and drive to succeed! © 2008 Pegasystems Inc.

Key Ingredients…Application Organization The key to constructing the PIE for change and reuse began with assuring that the application was organized in a manner that could be maintained and changed by a Business Analyst on an ongoing basis. As the precertification business rules for IBC’s current book of business and targeted future markets can and will continue to change rapidly. In other words both IT and Business team members had to think more like end users and less like developers. As a result, three applications were built and organized in adherence with Pega’s own COE Best Practices! © 2008 Pegasystems Inc.

Reusability MetricsWhy we love PIE! The PIE Application was built using ONE primary flow with 10 Secondary Sub-flows The PIE Application contains three IBC Enterprise Reusable RuleSets: PIE, GenPrecertEngine and PMR. The PIE Application contains 35 Classes which contain 855 rules. 98% of these Classes and Rules are utilized by both RuleSets in the PIE Application. 96% (283 of the 296) PIE Rules for Elective Procedures are Reusable 97% (545 of the 559) GenPrecertEngine Rules are Reusable 60% of the PIE Application is maintained by the Business Analyst 31% of the PIE Application will be maintained by IT (I.e. The 13 Connectors to 6 Backend Systems) 5% of the PIE Application can be maintained via the COE for Enterprise-wide Reuse & Quality consistency purposes. 4% of the PIE Application is Security/Access related, which will be maintained by the System Administrator. It takes about 10 minutes to train a user on the application It takes less than 2 minutes to change/maintain a rule! © 2008 Pegasystems Inc.

“Precert Intake Before” Pega

Flowing the Comments Potential Variables ,[object Object]

Precert Intake After Pega“Just desserts demo!” Cataract Case Determination Example Responding to Precert Business Rule Changes/Additions Managing Procedure Business/industry/Medical Rule Changes E.g. Procedure previously defined as Experimental and Investigational (EI) which is deemed approvable based on certain circumstances. © 2008 Pegasystems Inc.

Cataract Example: Before Pega Scenario: PCP Calls in to pre-certify for Cataract surgery Before Pega, Intake Staff had to go into the PIE spreadsheet and find the Cataract procedure in order to make the correct determination. Also, staff would need to toggle between numerous systems to validate all member, provider, and facility information.

Cataract Example: After Pega Scenario: PCP Calls in to pre-certify for Cataract surgery Intake operator: Collects member, provider, and facility data Enters and confirms diagnosis and procedure codes Asks 7 specific questions relating to the Cataract procedure in order for Pega’s rule engine to make a determination Submits determination to maxMC which generates an authorization and returns reference number to Pega Pega: Uses an intent-led UI to walk staff quickly through the process Connects to all systems of record to create a composite view Fires rules to notify operator automatically of status based on information collected

Case Validation Operator captures information from provider in pre-populated drop down menus ensuring accuracy

Member Search Operator has multiple ways to look for Member information

Select a Member Pega connects to Member system of record and returns results. Operator selects correct member and submits to move on in the process “ Bread crumbs” keep track of where operator is in the process and allows easy navigation to previous steps

Validate Member Pega creates a composite screen of all needed member information by connecting to three back-end member enrollment and benefit systems Pega parses PTI data and presents in separate fields

Questions Pega has the ability to ask questions specific to a product or line of business.

Search for Provider All collected case information is organized in the appropriate tabs. If a question arises, with one click the operator has access to all needed data

Validate Provider Composite view of all Provider information needed for validation. Again Pega connected to the back-end system of record and pulled only the needed data fields into memory for use

Facility Search The user enters and submits Facility search criteria. Pega submits the appropriate Request type to back-end Provider system.

Select a Facility Given search criteria, SOAP message returns more than one match.

Diagnosis Entry Operator can enter multiple diagnosis codes which may be used by the rules to make a determination.

Diagnosis Validation Pega pulls diagnosis code information from the Corporate Code Set.

Service Type Selection Service Type drives the type of record that is used to transfer information to the medical management system and determines if additional questions are required for Ancillary services.

Procedure Entry All diagnosis (ICD-9) and procedure (CPT-4) codes are automatically validated against the corporate code set .

Procedure Validation Pega pulls Procedure Code information from the Corporate Code Set.

Procedure Specific Questions Given all the information collected so far, Pega’s rule engine fires off and makes the determination that the following questions must be asked of the provider. We will see later that the logic behind each question is very easy to change for a business user.

Fills out Questionnaire Populated drop-downs allows the intake staff to correctly capture the right information. Since everything is contained in one system, all data collected can be used for reporting purposes.

Review Case Operator receives immediate notification of precert status (could have been Pended or No Precert Required) If more experienced staff members want to look into the decision logic, business rules used are only one-click away. Operator can go back to a step in the process by clicking the appropriate “bread crumb.”

Rule Review Rules are written in English syntax to make it easy for business users to understand and change. This is fully executable business logic. If more experienced staff members want to look into the decision logic, business rules are only one-click away.

Questionnaire Rule Review A business manager can make a change to a rule and it will automatically be updated in the application with the appropriate change management controls.

Confirmation Screen Reference number is created by maxMC. All data collected is sent to document and create a case in maxMC. A new case can be started with one-click

Authorization Created Collected data creates an authorization in the medical management system.

Documenting Notes Notes are created to document data collected including any questions asked with their answers.

Changing Rules by a Business User Changing rules can be done in minutes by a business user and does not have to be submitted to IT for a change request which could take weeks or months. Rules are written in English and not code making it intuitive for a business person to change. All changes made are immediately executable into the system with the appropriate change management controls.

Business Developer Portal Pega can expose all rules and applications that a business user will need to make changes.

Business Requires Rule Change Business environment changes to approve all FLEX Members for Cataract procedures without going through a questionnaire. Business user selects Decision Tree for Cataracts

Changing Rule Cataract rule is checked out and updated to result in ‘Approved’ status.

Pw08 Ibc Final Pie Ppt 090508

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Pw08 Ibc Final Pie Ppt 090508

Semelhante a Pw08 Ibc Final Pie Ppt 090508 (20)

Último

Último (20)

Pw08 Ibc Final Pie Ppt 090508

Notas do Editor