hcif imp guide v73 lck

Healthcare Industry Framework

Implementation Guide

© Copyright 2009 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 provided.

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 are 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 Healthcare Industry Framework Document: Implementation Guide Software Version: 7.3 Updated: June 2009

Contents

Chapter 1: Before You Begin ..................................................................................................... 1-1 What Is the Healthcare Industry Framework? ........................................................................ 1-2

PegaHC — Healthcare Foundation Layer ...................................................................... 1-2 PegaHCAUTH — Authorization Management Solution Layer ......................................... 1-4 PegaHCNME — New Member Enrollment Solution Layer .............................................. 1-5 PegaHCAGM — Appeals and Grievance Management Solution Layer .......................... 1-6

Your Framework and Process Commander ........................................................................... 1-7 Who Should Read This Document? ....................................................................................... 1-8 Education and Training ........................................................................................................... 1-9

Chapter 2: What Is Already Set Up ............................................................................................ 2-1 Application Rules .................................................................................................................... 2-3 System Administrator Account ............................................................................................... 2-4 RuleSet Hierarchy .................................................................................................................. 2-5 Data Classes .......................................................................................................................... 2-7 Work Object Naming Conventions ......................................................................................... 2-9 Default Work Groups and Workbaskets ............................................................................... 2-11 Default Operators, Access Groups, and Portals ................................................................... 2-13 Predefined Organizations, Divisions, and Units .................................................................... 2-16 Predefined Access Roles and Privileges .............................................................................. 2-19 Predefined Work Parties ....................................................................................................... 2-23 Correspondence Templates ................................................................................................. 2-24

Correspondence Templates and Fragments for Authorization Management ................ 2-24 Correspondence Templates and Fragments for New Member Enrollment ................... 2-26 Correspondence Templates and Fragments for Appeals and Grievances .................... 2-27

Process Commander Correspondence Templates ............................................................... 2-29 Sample Database Model ...................................................................................................... 2-31 Sample Data to Test All Solutions ........................................................................................ 2-34

Member Data ................................................................................................................. 2-34 Provider Data ................................................................................................................ 2-36 Policy Data .................................................................................................................... 2-39 Plan Benefit Data .......................................................................................................... 2-40 Claim Data ..................................................................................................................... 2-40

Sample Data to Test the Authorization Management Solution ............................................. 2-41

ii Healthcare Industry Framework Implementation Guide

Sample Data to Test the New Member Enrollment Solution ................................................ 2-43 Sample Data to Test the Appeals and Grievance Management Solution ............................. 2-44 Common Object Sample Data Maintenance ........................................................................ 2-46

PegaHC-Data-Party-Member (Sample Members) ......................................................... 2-48 PegaHC-Data-Party-Provider (Sample Providers) ........................................................ 2-50 PegaHC-Data-Policy (Sample Policies) ....................................................................... 2-52 PegaHC-Data-Claim (Sample Claims) .......................................................................... 2-54 PegaHC-Data-Authorization (Sample Authorizations) ................................................... 2-56 PegaHC-NME-Data-EmployerGroup (Sample Employer Groups) ................................ 2-57 PegaHC-Data-Product (Sample Plan / Benefits) ........................................................... 2-59 PegaHC-Data-Company (Sample Companies) ............................................................. 2-61

Industry Code Sets Search and Maintenance ...................................................................... 2-63 HIPAA-Enabled Data Model Overview ................................................................................. 2-68

Object-Oriented Class Model ........................................................................................ 2-68 HIPAA-Complaint Property Values ................................................................................ 2-71

Chapter 3: The Authorization Management Solution .............................................................. 3-1 Understanding the Preconfigured Workflow ........................................................................... 3-3

HIPAA EDI Exchange ...................................................................................................... 3-4 High Level 278 EDI Exchange Architecture .................................................................... 3-4 EDI Validation .................................................................................................................. 3-4 X12 278 Integration ......................................................................................................... 3-5 Key Rules for X12 278 Integration................................................................................... 3-8

Manual Request Generation ................................................................................................. 3-10 Key Rules for the Manual Request Generation Process ............................................... 3-14

Authorization Request Processing ....................................................................................... 3-16 Procedural Validations .......................................................................................................... 3-18

Member Validation ........................................................................................................ 3-18 Key Rules for the Member Validation Process .............................................................. 3-20 Referring Provider Validation ........................................................................................ 3-21 Key Rules for the Referring Provider Validation Process .............................................. 3-23 Duplicate Request Validation ........................................................................................ 3-23 Key Rules for the Duplicate Request Validation Process .............................................. 3-25

Declarative Validations ......................................................................................................... 3-26 Key Rules for the Declarative Process .......................................................................... 3-26 Declarative Validations for Non-Covered Experimental Treatments ............................. 3-30 Declarative Validations for Cosmetic Surgery ............................................................... 3-31 Declarative Validations for Services Not Requiring a Referral ...................................... 3-32 Declarative Validations for Cardiac Rehab Services ..................................................... 3-33

Healthcare Industry Framework Implementation Guide iii

Declarative Validations for Chiropractic Services .......................................................... 3-34 Declarative Validations for Podiatry Services ................................................................ 3-34

Straight Through Processing ................................................................................................ 3-35 Manual Processing ............................................................................................................... 3-36

Workflow Attributes ....................................................................................................... 3-36 Role-Privilege Matrix ..................................................................................................... 3-39 Work Urgency Points Matrix .......................................................................................... 3-42 Service Level Rules ....................................................................................................... 3-43 Correspondence Rules .................................................................................................. 3-46 Reports .......................................................................................................................... 3-48

Chapter 4: X12 Message Processing ........................................................................................ 4-1 Mapping X12 Messages in Process Commander ................................................................... 4-5 X12 Inbound Message Processing ......................................................................................... 4-6 X12 Message Classes ............................................................................................................ 4-8 Segments and Properties ....................................................................................................... 4-9 Example of 278 Message ..................................................................................................... 4-11 X12 Activity Rules ................................................................................................................. 4-13 X12 EDI Management .......................................................................................................... 4-17

Healthcare Eligibility Request Message Processing ..................................................... 4-17 Healthcare Claim Status Request Message Processing ............................................... 4-24

Chapter 5: The New Member Enrollment Solution .................................................................. 5-1 New Member Enrollment High Level Workflow ...................................................................... 5-2 Intake Process ........................................................................................................................ 5-3

Initiating the Enrollment Application Process .................................................................. 5-3 Manual Input Intake Method ............................................................................................ 5-5 PDF Intake Method ......................................................................................................... 5-7 External Message Intake Method .................................................................................... 5-7 Key Rules for the Intake Processing ............................................................................... 5-9

Initial Member Enrollment Application Assignment ............................................................... 5-11 Common Process Workflow .......................................................................................... 5-13

Application Data Entry Workflow .......................................................................................... 5-15 Medical History .............................................................................................................. 5-18 Medical Underwriting Risk Evaluation and Recommendation ....................................... 5-19 New Member Enrollment Application Routing and Review ........................................... 5-24 Output Process .............................................................................................................. 5-34

Service Level Rules .............................................................................................................. 5-36 Correspondence Rules ......................................................................................................... 5-39

iv Healthcare Industry Framework Implementation Guide

Declarative Rule Examples .................................................................................................. 5-41 Key Rules for the Declarative Process .......................................................................... 5-41

Reporting .............................................................................................................................. 5-44 New Business Pipeline .................................................................................................. 5-44 New Business Performance .......................................................................................... 5-45 New Hire Pipeline .......................................................................................................... 5-45 New Hire Performance .................................................................................................. 5-46 Drill-Down Details .......................................................................................................... 5-46

Additional Extension Ideas ................................................................................................... 5-48 Member Access to Enrollment Application .................................................................... 5-48 Member Maintenance .................................................................................................... 5-48 Consumer Driven Healthcare ........................................................................................ 5-49 Medical Underwriting ..................................................................................................... 5-49 Integration with Group Sales Process Management ..................................................... 5-49 Individual Rating ............................................................................................................ 5-50 Member Eligibility Management .................................................................................... 5-50 Extend Member Enrollment for Management ................................................................ 5-50

Chapter 6: The Appeals and Grievances Solution ................................................................... 6-1 The Final Disposition Process for Appeals ............................................................................. 6-4 Extending the Final Disposition Notification Process .............................................................. 6-6 Workbasket Routing for Complaints ....................................................................................... 6-8 Extending the Quality Audit Process ...................................................................................... 6-9 The Appeal Re-Open Process .............................................................................................. 6-10 Appeals and Grievance Manager Reports............................................................................ 6-11

Chapter 7: Extending Your Framework .................................................................................... 7-1 Setup Requirements ............................................................................................................... 7-3 Setting Up Calendars ............................................................................................................. 7-4 Setting Up Correspondence ................................................................................................... 7-6

Sample HTML and Template Letter ................................................................................ 7-8 Adding Additional X-12 Transactions ................................................................................... 7-11

Extending the Classes and Properties .......................................................................... 7-11 Parse Delimited Rules ................................................................................................... 7-12 Activity Rules ................................................................................................................. 7-15 Other Activities .............................................................................................................. 7-18

Member and Eligibility Data Interface ................................................................................... 7-19 Provider Data Interface ......................................................................................................... 7-20 Claim Data Interface ............................................................................................................. 7-21

Healthcare Industry Framework Implementation Guide v

Authorization Data Interface ................................................................................................. 7-22 Interfacing to PegaDISTRIBUTION Manager ....................................................................... 7-23

Chapter 1 Before You Begin

This document describes how to deploy and extend the Healthcare Industry Framework for initial production use. It assumes that:

■ The Healthcare Industry Framework is already installed

■ You have taken the appropriate training courses

■ Some team members are PegaRULES Process Commander certified

1-2 Healthcare Industry Framework Implementation Guide

What Is the Healthcare Industry Framework? Built for healthcare organizations, the Healthcare Industry Framework (HCIF) provides a healthcare-specific foundation and data model for rapid creation and deployment of SmartBPM™ solutions that deliver productivity, spur growth, and ensure compliance. HCIF can be implemented by organizations to:

■ Develop applications that dramatically extend the capabilities of existing systems such as claims, billing, enrollment, membership, and provider networks

■ Revitalize legacy applications

■ Address new market opportunities in a fraction of the time required by more traditional development environments

It includes core features and functions that accelerate the development of personalized solutions for a payer organization’s biggest challenges in areas such as medical management, billing, provider contracting, provider credentialing, and consumer directed healthcare. The framework supports frequent change and extension into new areas as the needs of the business change.

The framework contains four major RuleSet layers - a baseline layer and three supporting layers that are built on top of and leverage the infrastructure of the baseline layer.

■ PegaHC — Healthcare Foundation Layer (baseline)

■ PegaHCAUTH — Authorization Management Solution Layer

■ PegaHCNME — New Member Enrollment Solution Layer

■ PegaHCAGM — Appeals and Grievance Management Solution Layer

PegaHC — Healthcare Foundation Layer This baseline layer contains the common healthcare object model, the X12 message processing infrastructure, a sample organizational model and

Before You Begin 1-3

simulated sample data for end user functions. This layer is required for all healthcare framework layers. Key features include:

HIPAA-Enabled Healthcare Data Model

■ Support of the healthcare data element dictionary (supporting all nine HIPAA EDI Transactions)

■ An object-based class structure for common objects (member, provider, policy, authorization, service, claim, claim line, enrollment, broker, plan sponsor, claim payment, and premium payment)

■ HIPAA-mandated property list validations (such as codes for claim status, remark, rejection reason, and individual relationship)

■ Work party setup for subscriber, member, provider, plan sponsor, broker, and agency

■ Prompt-Select and Dynamic Selection of HTML property attributes

HIPAA-EDI Reference Implementation

■ Structured class model to support HIPAA EDI transaction segments and properties within those segments

■ An automated process for EDI transaction file input

■ Parsing and mapping of the following three EDI transactions to their relevant segments and properties within the data segments

− 837 – Healthcare Professional Claim

− 834 – Healthcare Benefit Enrollment and Maintenance

− 278 – Healthcare Service Review Request (Authorization Request)

− 270 / 271 – Healthcare Eligibility Request and Response

− 276 / 277 – Healthcare Claims Status Request and Response

■ The parsing and mapping of the 278 transaction is extended to create a work object that is processed in the sample Authorization Management Solution layer


■ The parsing and mapping of the 270 and 276 request transactions is extended to create corresponding work objects in the Manage EDI Work pool. The work items are straight-through-processed leveraging the sample data to generate corresponding 271 and 277 response transactions respectively.

Framework Starter Kit

■ A common organization hierarchical setup including divisions and units such as Customer Service, Utilization Management, Provider Network Services, Claims, Compliant Management, and Enrollment.

■ A common-object search and display function for members, providers, policies, claims, and authorizations.

■ Sample data instances for common objects used for rapidly demonstrating workflow processes without having to rely on external databases.

PegaHCAUTH — Authorization Management Solution Layer This layer provides examples of straight-through processing of an X12 278 EDI message against a set of sample business rules for automated approval or denial of the prior authorization request and workflow for managing pended requests. The solution is configured so that it can be easily extended to create a comprehensive authorization management system. Key features include:

■ 278 EDI transaction parsing and authorization request work object creation

■ Provider Web Self-Service application portal and authorization request SOAP message creation

■ Authorization request straight through processing (automated approval and denial rules)

■ Pended request management


− Workbasket routing

− Service level monitoring

− Correspondence generation

− Manual resolution

PegaHCNME — New Member Enrollment Solution Layer This layer provides out-of-the-box examples of new member application submission and enrollment processing. The solution can be rapidly integrated into your existing infrastructure, personalized to reflect your specific policies, and expanded to create a comprehensive enrollment management system. Key features include:

■ Sample enrollment processing workflows driving intake, data entry and output processes

■ Three sample intake methods: Manual, PDF and External Message

■ Automated creation of work items and pre-population of data for non-manual intake methods

■ Intelligent enrollment application routing using skills, work and process assessment rules to determine specific user or workbasket recipients

■ Sample enrollment users across representative departments (sales, enrollment and underwriting) including both internal and external parties (such as Plan Sponsor)

■ Per member risk factor computation based on medical history elements and an underwriting action recommendation based at the application level

■ Service Level Agreement monitoring, notification and escalation

■ Work item resolution including system generated correspondence and automated updates to back-end legacy systems

■ Sample enrollment reports


PegaHCAGM — Appeals and Grievance Management Solution Layer This layer provides a working configuration that you can immediately begin to use to interface with your existing information systems and add personalization to prebuilt workflows. This solution manages complaints received from members and other interested parties (authorized representatives, providers, and third parties such as independent review entities). It provides the capability to create, manage, and resolve new cases for both appeals and grievances. Key features include:

■ Automated creation of the grievance case and capture of the required information including the requestor party and the grievance reason

■ Assignment of urgency status (standard or expedited)

■ Assignment of an owner

■ Automated creation of the appeal case and capture of the required information including the requestor party, appeal level, appeal category, and service and/or claim information

■ Service level monitoring to ensure timely processing


Your Framework and Process Commander PegaRULES Process Commander contains a rules engine, database, processing logic, and functions — providing the base upon which Pegasystems Frameworks are built. Process Commander Frameworks are layered, making use of underlying technology instead of reinventing process flows (Figure 1-1). Additional flows and rules are contained in the Framework layer and support application-specific functions (such as contact management or customer service). The rules you modify when extending the Framework are at the top level, as they supersede the Framework defaults.

Figure 1-1. Process Commander Frameworks Showing Layers

Because Pegasystems Frameworks all share the same underlying technology, configuration processes (such as creating accounts and copying rules) are identical to those in Process Commander.

You can use the Framework RuleSets as a starting point for extending the Framework, making it specific to your organizational needs.


Who Should Read This Document? Before you install, deploy, and extend your Framework, it is assumed you have attended the courses listed below for your specific user role. The specific user roles addressed are the following:

■ Business Managers — responsible for evaluating the Framework solution and possess a general, non-technical understanding of its features and capabilities.

■ Project Managers / Business Analysts — responsible for implementing a Framework solution that can be applied to specific business requirements, and ensures compliance and continuous improvement across organizations.

■ System Architects / Application Developers — responsible for building, maintaining, modifying, and extending the Framework.

■ System and Database Administrators — responsible for the installation, security, and ongoing operational functions of the Framework such as access, tuning, and troubleshooting. These users are presumed to be experienced with system operations.


Education and Training Pegasystems Educational Services delivers in-depth programs that are designed, delivered, and taught by certified experts for those who would like additional training. Through hands-on, role-based training, students receive critical knowledge from professionals skilled in the implementation of PegaRULES Process Commander solutions.

For more information about Pegasystems programs and schedules, visit us at http://pega.com/Services/EducationalServices/Education.asp

The Pega Developer Network (PDN), located at http://pdn.pega.com, is the primary technical resource area for the Process Commander developer community. The PDN contains a broad range of technical articles including troubleshooting and “How-To” information and a comprehensive and searchable knowledgebase to help developers speed their application development. The PDN also links directly to the customer support section of pega.com where customers can submit trouble reports and product enhancement requests.

For information about installing or working with third-party applications, such as Microsoft Visio, consult vendor documentation.

Chapter 2 What Is Already Set Up

This chapter describes defaults and samples that are set up and ready for your use. It is expected that you will use these as a basis for extending the Healthcare Industry Framework. The topics include: ■ Application Rules ■ System Administrator Accounts ■ RuleSet Hierarchy ■ Data Classes ■ Work Object Naming Conventions ■ Default Work Groups and Workbaskets ■ Default Operators and Access Groups ■ Predefined Organizations, Divisions, and Units ■ Predefined Access Roles and Privileges ■ Predefined Work Parties ■ Correspondence Templates ■ Sample Database Model ■ Sample Data for Testing Purposes ■ Common Object Sample Data Maintenance


■ Industry Code Set Search and Maintenance ■ HIPAA-Enabled Data Model Overview

What Is Already Set Up 2-3

Application Rules The Healthcare Industry Framework contains Application Rules for the four layers (PegaHC, PegaHCAGM, PegaHCAUTH, PegaHCNME) of the framework. The Application rules define an ordered set of RuleSets and versions that together identify the parts of the solution ‘layers’ of the framework. In addition, application rules relate the application's objectives, use cases, and actors to objects created as part of the Direct Capture of Objectives capabilities. The Access Groups (listed later) are associated with specific Application Rules. The Healthcare Frameworks use the following numbering convention for the Application rules – xx-yy-zz (e.g. PegaHC 07-03-55) where:

• xx – relates to the major version of the framework

• yy – relates to the minor version of the framework

• zz – relates to the PRPC version that the framework is supported on


System Administrator Account The Healthcare Industry Framework uses the following Operator IDs as the default system administrator accounts for the respective applications. You should change this password after logging in.

Note: Operator IDs are not case sensitive, but passwords are case sensitive.

.

Application Access Group System Administrator ID

PegaHC PegaHC:Administrators Administrator@MyHealthPlan

PegaHCAGM AGM:Administrators AGMAdmin@MyHealthPlan

PegaHCAUTH AUTH:Administrators AUTHAdmin@MyHealthPlan

PegaHCNME NME:Administrators NMEAdmin@MyHealthPlan

The password for each System Administrator login is:

Password: install


RuleSet Hierarchy RuleSets are arranged hierarchically, with the more general rules at the bottom and more specific rules at the top. The four RuleSets at the bottom are standard in all applications and control the underlying Process Commander operations, while the rules towards the top control application functions. The RuleSet order is critical to rule resolution. To find the appropriate rule, Process Commander begins with the top RuleSet in this list, and if the rule is not found moves to the next RuleSet. In this manner, custom, site-specific rules have precedence over application-specific rules. Figure 2-1 shows the RuleSet hierarchy with all the Healthcare Industry Framework layers.

Figure 2-1. RuleSet Hierarchy

The Healthcare Industry Framework RuleSets include:

■ PegaHCNME — the Healthcare Industry rules for New Member Enrollment provide sample workflows of the enrollment process for new hires and new members.


■ PegaHCAUTH — the Healthcare Industry rules for Prior Authorization (Pre-Certification) Management provide examples of straight-through-processing of an X12 278 EDI message against a set of sample business rules for automated approval or denial of the prior authorization request and workflow for managing pended requests.

■ PegaHCAGM — the Healthcare Industry rules for Appeals and Grievances provides a sample configuration that you can use to manage complaints received from members and other interested parties.

■ PegaHC — the healthcare foundation layer containing the common healthcare object model, X12 message processing infrastructure, sample EDI straight-through-processing, a sample organizational model, and simulated sample data for end user functionality (members, policies, benefits, providers, claims, authorizations etc.). This rule set is required for all healthcare framework layers.

The Process Commander RuleSets include:

■ Pega-ProCom — workflow support and portal facilities

■ Pega-IntSvcs — system interface support, including connectors and services

■ Pega-WB — internal logic and facilities

■ Pega-RULES — activities, Java generation, rule resolution, and other basic rules engine operations


Data Classes Data classes define the data structures for supporting information that the Framework uses to process work. The data classes used in the Healthcare Industry Framework are listed below. PegaHC-Data-Attachments PegaHC-Data-Authorization PegaHC-Data-Claim PegaHC-Data-ClaimConditionCodes PegaHC-Data-ClaimLine PegaHC-Data-ClaimOccurrenceCodes PegaHC-Data-ClaimPendCodes PegaHC-Data-ClaimProcedureCodes PegaHC-Data-ClaimSpanOccurrenceCodes PegaHC-Data-ClaimStatusCategoryCodes PegaHC-Data-ClaimStatusCodes PegaHC-Data-ClaimTreatmentCodes PegaHC-Data-ClaimValueCodes PegaHC-Data-CodeGroup PegaHC-Data-CPTCodes PegaHC-Data-Diagnosis PegaHC-Data-DRGCodes PegaHC-Data-DrugCodes PegaHC-Data-EligibilityRequest PegaHC-Data-Enrollment PegaHC-Data-HCPCSCodes PegaHC-Data-Language PegaHC-Data-Measurement PegaHC-Data-NDCCodes PegaHC-Data-Party PegaHC-Data-Party-Agency PegaHC-Data-Party-Broker PegaHC-Data-Party-Company PegaHC-Data-Party-InformationReceiver PegaHC-Data-Party-InformationSource


PegaHC-Data-Party-Member PegaHC-Data-Party-Payer PegaHC-Data-Party-PlanSponsor PegaHC-Data-Party-Provider PegaHC-Data-Payment PegaHC-Data-Payment-Claim PegaHC-Data-Payment-Premium PegaHC-Data-Policy PegaHC-Data-Population PegaHC-Data-Prescription PegaHC-Data-Product PegaHC-Data-RemarkCodes PegaHC-Data-Service PegaHC-Data-ToothCodes PegaHC-AG-Data-GrievanceReason PegaHC-AG-Data-Service PegaHC-NME-Data-EmployerGroup PegaHC-NME-Data-MedicalExam PegaHC-NME-Data-MedicalHistory PegaHC-X12-Data- classes for segments included in the HIPAA X12 EDI transactions


Work Object Naming Conventions There are three primary types of work objects: basic work objects, covers, and folders. Applications use basic work objects; some, but not all, may use covers or folders.

■ Work objects capture and process information about an individual unit of work.

■ Covers tightly coordinate processing of one or more distinct, but closely related, work objects. The system normally resolves a cover work object after all its component work objects are resolved.

■ Folders hold one or more work objects (which can be basic work objects, covers, or other folders). In contrast to covers, the relationship between folders and work objects and their contents may be many to many. One work object may be associated with multiple folders, but only one cover.

When your application initiates a work object, a predefined model populates key property values (such as urgency) that directly affects the work object’s relative priority and placement in operator worklists. As work objects progress towards resolution, core property values such as priority and status are continually updated to reflect the current stage of processing.

Each work object has a unique ID that is computed by combining a system-assigned number and a prefix defined as in a pyDefault Model in the PegaHCAUTH RuleSet. For example, PR-1003 could be a work object related to a purchase requisition application. The prefixes currently defined in the Healthcare Industry Framework are shown in Figure 2-2.

Prefix Work Object Applies To

CLMSR- Claim Status Request PegaHC-EDI-Work-ClaimStatusRequest


ELGSR- Eligibility Request PegaHC-EDI-Work-EligibilityRequest

Auth- Authorization Request PegaHC-AUTH-Work-AuthRequest

CMP- Complaint PegaHC-AG-Work- Complaint

MEA- Member Enrollment Application PeagHC-NME-Work-Enrollment-EnrollmentApp

Figure 2-2: Work Object IDs

You can change this prefix or create additional prefixes by copying the default model into your RuleSet and making your changes.


Default Work Groups and Workbaskets Figure 2-3 lists the default work groups and workbaskets used in the Authorization Management Solution workflow in the Healthcare Industry Framework.

Note: The Healthcare layer (PegaHC) does not include any predefined work groups and workbaskets.

Work Group Workbasket Description

Authorization Management Solution

ServiceReview@MyHealthPlan ServiceReview@MyHealthPlan Used for routing all pended service review requests

MDReview@MyHealthPlan Used for routing all pended service review requests that require the Medical Director’s review

ProviderFeedbackRequest@MyHealthPlan Used for routing service review requests when additional supporting information has been requested from the referring provider

New Member Enrollment Solution

Default@MyHealthPlan Defaut@MyHealthPlan The default workbasket

Actuary@MyHealthPlan Actuary@MyHealthPlan Used for routing work to the actuary group

Enrollment@MyHealthPlan Enrollment@MyHealthPlan Used for routing work to the enrollment group

General@MyHealthPlan Used for routing application received by the PDF listener

NewSales@MyHealthPlan NewSales@MyHealthPlan Used for routing work to the new sales group


Work Group Workbasket Description

RenewalSales@MyHealthPlan RenewalSales@MyHealthPlan Used for routing work to the renewal sales group

Underwriting@MyHealthPlan Underwriting@MyHealthPlan Used for routing work to the underwriting group

UnderwritingSupport@MyHealthPlan Used for routing work to the underwriting support users

Appeals and Grievance Management Solution

Default@MyHealthPlan Defaut@MyHealthPlan The default workbasket

AppealsGrievance @MyHealthPlan

Complaints@MyHealthPlan Used for all complaints

ClaimsResearch@MyHealthPlan ClaimsReview@MyHealthPlan Used for all issues requiring review, additional research, and / or follow-up by the Claims Research Unit.

MemberResearch@MyHealthPlan MRUReviewt@MyHealthPlan Used for all issues requiring review, additional research, and / or follow-up by the Member Research Unit.

ProviderNetworkServices@MyHealthPlan

PNSReviewt@MyHealthPlan Used for all issues requiring review, additional research, and / or follow-up by the Network Services Unit.

QualityReview@MyHealthPlan QualityReview@MyHealthPlan Used for all issues requiring review, additional research, and / or follow-up by the Quality Review team.

UtliziationManagement@MyHealthPlan

UMReview@MyHeealthPlan Used for all issues requiring review, additional research, and / or follow-up by the Utilization Management (Case Management) unit.

Figure 2-3. Work Groups and Workbaskets


Default Operators, Access Groups, and Portals The Healthcare Industry Framework comes with the following operators, access groups, and portals (Figure 2-4). All passwords are set to install by default.

Operator ID Access Group Portal Name

HCIF Administrator@MyHealthPlan PegaHC:Administrators HCIFDeveloper (Default) AGMManager (Alternate) AUTHManager (Alternate) NMEManager (Alternate) Appeals & Grievances Manager (AGM) AGMAdmin@MyHealthPlan AGM:Administrators Developer (Default) AGMManager (Alternate) AGManager@MyHealthPlan AGM:AGManager AGMManager CLMManager@MyHealthPlan AGM:CLMManager AGMManager MedDirector@MyHealthPlan AGM:MedicalDirector AGMManager MRUManager@MyHealthPlan AGM:MRUCoordinator AGMManager PNSManager@MyHealthPlan AGM:PNSManager AGMManager QIManager@MyHealthPlan AGM:QIManager AGMManager UMManager@MyHealthPlan AGM:CaseManager AGMManager AGAssistant@MyHealthPlan AGM:AGAssistant AGMUser AGCoordinator@MyHealthPlan AGM:AGCoordinator AGMUser CLMCoordinator@MyHealthPlan AGM:CLMCoordinator AGMUser MRUCoordinator@MyHealthPlan AGM:MRUCoordinator AGMUser PNSCoordinator@MyHealthPlan AGM:PNSCoordinator AGMUser QCCoordinator@MyHealthPlan AGM:QICoordinator AGMUser Authorization Management (AUTH) AUTHAdmin@MyHealthPLan AUTH:Administrators Developer (Default) AUTHManager (Alternate) MedicalDirector@MyHealthPlan AUTH:MedicalDirector AUTHManager UMCaseManager@MyHealthPlan AUTH:UMCaseManager AUTHManager


UMCoordinator1@MyHealthPlan AUTH:UMCoordinator AUTHUser UMCoordinator2@MyHealthPlan AUTH:UMCoordinator AUTHUser UMCoordinator3@MyHealthPlan AUTH:UMCoordinator AUTHUser New Member Enrollment NMEAdmin@MyHealthPlan NME:Administrators Developer (Default) NMEManager (Alternate) Acturial/Acturial ActuaryManager@MyHealthPlan NME:EnrollmentManager NMEManager Actuary1@MyHealthPlan NME:Underwriter NMEUser Actuary2@MyHealthPlan NME:Underwriter NMEUser Actuary3@MyHealthPlan NME:Underwriter NMEUser External/Agency

Broker@MyHealthPlan NME:Broker NMEUser External/PlanSponsor PlanSponsor1@MyHealthPlan NME:PlanSponsor NMEUser PlanSponsor2@MyHealthPlan NME:PlanSponsor NMEUser PlanSponsor3@MyHealthPlan NME:PlanSponsor NMEUser Enrollment/Enrollment EnrollmentManager@MyHealthPlan NME:EnrollmentManager NMEManager EnrollmentSupport@MyHealthPlan NME:EnrollmentRep NMEUser EnrollmentRep1@MyHealthPlan NME:EnrollmentRep NMEUser EnrollmentRep2@MyHealthPlan NME:EnrollmentRep NMEUser EnrollmentRep3@MyHealthPlan NME:EnrollmentRep NMEUser Sales/NewSales SalesManagerNBU@MyHealthPlan NME:EnrollmentManager NMEManager SalesRep1@MyHealthPlan NME:SalesReps NMEUser SalesRep2@MyHealthPlan NME:SalesReps NMEUser SalesRep3@MyHealthPlan NME:SalesReps NMEUser Sales/RenewalSales SalesManagerRenewals@MyHealthPlan NME:EnrollmentManager NMEManager RenewalRep1@MyHealthPlan NME:SalesReps NMEUser RenewalRep2@MyHealthPlan NME:SalesReps NMEUser RenewalRep3@MyHealthPlan NME:SalesReps NMEUser Underwriting/Underwriting


UnderwriterManager@MyHealthPlan NME:EnrollmentManager NMEManager Underwriter1@MyHealthPlan NME:Underwriter NMEUser Underwriter2@MyHealthPlan NME:Underwriter NMEUser Underwriter3@MyHealthPlan NME:Underwriter NMEUser UnderwritingSupport@MyHealthPlan NME:Underwriter NMEUser

Figure 2-4. Operators, Access Groups, and Portal


Predefined Organizations, Divisions, and Units The Healthcare Industry Framework comes with the following predefined organization, division, and units.

Organization: MyHealthPlan

Division Unit

Actuarial Actuarial

Administration Development

AppealsGrievances AppealsGrievances

BrokerAdministration BrokerAdministration

CareManagement DiseaseManagement

ProgramManagement


Division Unit

Claims Claims

Dental

FEP

HMO

HRA

HSA

Indemnity

ITS

Medicaid

Medicare

NASCO

Other

POS

PPO

Secure

CustomerService MemberServices

ProviderServices

Enrollment Enrollment

External Agency

PlanSponsor

Marketing Marketing

ProviderNetwork ProviderNetwork

QualityImprovement QualityImprovements


Division Unit

Sales NewSales

RenewalSales

SalesSupport

Underwriting Underwriting

UtilizationManagement UtilizationManagement

Figure 2-5. Predefined Organization, Divisions, and Units


Predefined Access Roles and Privileges Your Framework includes a set of predefined access roles. These roles are defined in Rule-Access-Role-Name and are associated with an operator’s access group. Each of these roles has a corresponding rule in Rule-Access-Role-Obj where you can define specific privileges for each of these roles. Figure 2-6 lists the access roles and privileges defined in the Healthcare Industry Framework.

Note: The Healthcare (PegaHC) and the New Member Enrollment (PegaHCNME) layers do not include any predefined access roles and privileges.

Figure 2-6 shows the privileges for the following access roles: AGAssistant, AGCoordinator , AGManager, AUMCoordinator, and CLMCoordinator. Figure 2-7shows the privileges for the following access roles: MedicalDirector, MRUCoordinator, PSNCoordinstor, QICoordinator, and UMCaseManager.

Access Roles

Privileges AGAssistant AGCoordinator AGManager AUMCoordinator CLMCoordinator

AccessAuditTrail X X X

ActionGetProviderFeedback X X

ActionCommunicateDecisionTo Provider

X

ActionProcessAuthorization X

ActionProcesGrievance X X

ActionPickResolutionCorr X X


Access Roles

Privileges AGAssistant AGCoordinator AGManager AUMCoordinator CLMCoordinator

ActionRequestAdditionalInfo X X X X

ActionReviewAuth X X

ActionReviewClaim X X

ActionSetFinalDispostion X X

ActionTransferToCR X X

ActionTransferToManager X X

ActionTransferToMedical Director

X

ActionTransferToMRU X X

ActionTransferToOwner X X

ActionTransferToPNS X X

ActionTransferToUM X X

AllFlows X X X X

AllFlowActions X X X X

Perform X X X X

PerformBulk X X

ViewFlowLinks X

WorkReopen X X X

WorkUpdate X X X

Figure 2-6. Access Roles and Privileges (For Roles A – C)


Access Roles

Privileges MedicalDirector MRUCoordinator PSNCoordinator QICoordinator UMCaseManager

AccessAuditTrail X X

ActionGetProviderFeedback X

ActionCommunicateDecision ToProvider

X

ActionProcessAuthorization X

ActionProcesGrievance

ActionPickResolutionCorr

ActionRequestAdditionalInfo X X X

ActionReviewAuth

ActionReviewClaim

ActionSetFinalDispostion

ActionTransferToCR


ActionTransferToMedical Director

X

ActionTransferToMRU

ActionTransferToOwner X X

ActionTransferToPNS

ActionTransferToUM

AllFlows X X X

AllFlowActions X X X

Perform X X X

PerformBulk X X X


Access Roles

Privileges MedicalDirector MRUCoordinator PSNCoordinator QICoordinator UMCaseManager

ViewFlowLinks X

WorkReopen X X X

WorkUpdate X X X

Figure 2-7. Access Roles and Privileges (For Roles M – U)


Predefined Work Parties The Healthcare Industry Framework defines work parties in a record called Default that references the following party roles:

Agency

AuthorizationRepresentative

Broker

Dependent

EnrollmentRep

Interested

Member

Originator

OtherEntity

Payer

PlanSponsor

Provider

Requestor

ServiceProvider

Subscriber

Spouse

Underwriter


Correspondence Templates The Healthcare Industry Framework comes with a standard set of sample correspondence templates and fragments. Fragments provide repeatable and reusable components within the correspondence templates. Templates are instances of Rule-Obj-Corr and Fragments are instances of Rule-Corr-Fragment.

Note: The Healthcare layer (PegaHC) does not include any predefined correspondence templates or fragments.

Correspondence Templates and Fragments for Authorization Management Figure 2-8 lists the correspondence templates that come with the Authorization Management Solution layer. These rules are all defined in the PegaHC-AUTH-Work class.

Name Type Purpose

Correspondence Rules

RequestAdditonalInformation Mail Sent to request additional information from the requesting provider to support the requested service authorization

RejectionNotice Mail Sent to the requesting provider to notify them that the request has been rejected because the additional information requested was not received within the predefined timeframe

Correspondence Fragments

Logo Mail Sample health plan logo to be inserted in correspondence

Stylesheet Mail Used for formatting the HTML correspondence


Name Type Purpose

HeaderMember Mail Header segment of the correspondence that contains the member name and address

HeaderRequester Mail Header segment of the correspondence that contains the requesting provider’s name and address

AuthReferenceInformation Mail Section that contains the authorization request number, request type, patient name, and received date

Footer Mail Closing paragraph that contains the contact information, operator name, and designation

Figure 2-8. Authorization Management Solution Correspondence Rules


Correspondence Templates and Fragments for New Member Enrollment Figure 2-9 lists the correspondence templates and fragments that come with the New Member Enrollment Solution layer. These fragments are defined in the PegaHCNME-Work-Enrollment-EnrollmentApp class.

Name Type Purpose

ActionGetProviderFeedback

EnrollmentRequest Email Used to notify a Plan Sponsor when an enrollment application ahs been created and assigned to the Plan Sponsor

NewEnrollmentApplication Email Used to notify an internal user when an enrollment application has been created and assigned to them

WelcomeLetter Mail Sent to a new subscriber when underwriting has approved the new member application


NMEWorkDetail Fragment Body of the e-mail sent to the plan sponsor

NMEWorkLink Fragment Included in the body of the NMEWorkDetail fragment

Figure 2-9. New Member Enrollment Solution Correspondence Rules


Correspondence Templates and Fragments for Appeals and Grievances Figure 2-10 lists the correspondence templates and fragments that come with the Appeals and Grievance Management layer. These rules are defined in the PegaHC-AG-Work-Complaints class.

Name Type Purpose


AppealAcknowledgement Mail Letter template for Appeal Acknowledgement

AppealApproval Mail Letter template for Appeal Approval

AppealDenial Mail Letter template for Appeal Denial

ComplaintRejection Mail Letter template for Complaint Rejection

GetProviderFeedback Email Letter template to Request Provider Feedback

GrievanceAcknowledgement Mail Letter template for Grievance Acknowledgement

GrievanceApproval Mail Letter template for Grievance Approval

GrievanceDenial Mail Letter template for Grievance Denial

RequestAdditionInformation Mail Letter template to Request Additional Information


AppealReferenceInfo Mail Appeal-related reference information

BodyAppealAcknowledgement Mail Body Text for an Appeal Acknowledgement

BodyAppealApproval Mail Body Text for an Appeal Approval

BodyAppealDenial Mail Body Text for an Appeal Denial

BodyComplaintRejection Mail Body Text for a Complaint Rejection

BodyGrievanceAcknowledgement Mail Body Text for aGrievance Acknowledgement

BodyGrievanceApproval Mail Body Text for aGrievance Approval


Name Type Purpose

BodyGrievanceDenial Mail Body text for a Grievance Denial

EnclosureAGProcess Mail Body text for the appeals and grievance process enclosure

Footer Email Footer correspondence fragment

Footer Mail Footer correspondence fragment

HeaderAuthorizedRep Mail Header correspondence rule for the member's representative related to the complaint

HeaderMember Mail Header corrrespondence rule for the member related to the complaint

HeaderOther Mail Header correspondence rule for other entity related to the complaint

HeaderRequestor Mail Header correspondence rule for requestor of complaint

HeaderServiceProvider Email Header correspondence for the service provider related to the complaint

HeaderServiceProvider Mail Header corr for the service provider related to the complaint

Logo Mail Standard logo

Stylesheet Email Standard style sheet

Stylesheet Mail Standard style sheet Figure 2-10. Appeals and Grievance Management Correspondence Fragments


Process Commander Correspondence Templates Figure 2-11 lists templates that are not used in the Healthcare Industry Framework workflows but are part of Process Commander and are available for your use. If you decide to use any of these templates, remember that they are samples, and you will need to copy them to your RuleSet and then modify them to meet your requirements.

Template Type Purpose

AcknowledgeSample Email, Fax, Mail, PhoneText Internal acknowledgement of a work object

DeadlineTimeReminder Email Notification that a work object has passed its deadline

Details Email, Fax, Mail Details of a work object

ExternalAcknowledgeSample Email External acknowledgement of a work object

ExternalRequest Email Request for information about a work object assigned to an external user

ExternalRequestBrief Email Assignment of a work object to an external user

ExternalSample Email Correspondence with external party regarding a work object

Footer Email, Fax, Mail Signature for correspondence

GoalTimeReminder Email Notification that a work object has passed its goal time

Header Email, fax, mail Salutation for correspondence

LateTimeReminder Email Notification that a work object is late

NewAssignment Email Notification of a new assignment on a worklist

NotifyReopen Email Notification that a work object has been reopened

PromptSample Email, Fax, Mail, PhoneText Prompt for user input


Template Type Purpose

QuestionAboutItem Email, Fax, Mail, PhoneText Request for more information about a work object

ResolutionDetails Email, Fax, Mail Resolution details for a work object

ResolutionSample Email, Fax, Mail, PhoneText Notification that a work object has been resolved

Figure 2-11. Process Commander Correspondence Templates


Sample Database Model The Healthcare Industry Framework comes with an industry-standard sample database. You can use this sample database model as delivered without additional configuration, or you can add or modify the data to meet your needs. The Framework uses the standard Process Commander tables called pr_data and pc_work. If you are using external interfaces, your interface activities will map your data back to this table.

Follow the procedure below to view the database information.

To view database table information:

1. From the Tools menu, select Database > Modify Database Schema. The View/Modify Database Schema Wizard appears with the Select a Database showing (Figure 2-12).

Figure 2-12. Select a Database

2. Select a Database from the Selection box and click Next.


3. Select a Table from the Selection box and click Next. Figure 2-13 appears showing the classes for the selected table.

Figure 2-13. Classes in Selected Table

4. Do one of the following:

− To view a table of database columns along with their data type and size, click the number following the title Columns in the table (#112,) or the View Columns link on the left (Figure 2-14).

− To view a detailed table of database properties, click the number in the Properties Set to be Visible column (Figure 2-15).


Figure 2-14. Database Table— Partial List of Database Columns Screen

Figure 2-15. Database Table — Partial List of Database Properties Screen


Sample Data to Test All Solutions The following sample data is provided in the Healthcare Industry Framework for you to test any solution. Refer to the instances of the relevant data class for a complete list of sample data instances. The Search Object Model feature available from the Run > Process menu of the Administrator portal provides functionality to search, review, update, and clone sample data instances.

■ Member Data

■ Provider Data

■ Policy Data ■ Plan Benefit Data ■ Claim Data

Member Data

ID # Last First DOB Policy # Role Eff Date Term Date Status PCP #

S-001 Weiss Matthew 1/28/1960 P-001 18-Self 1/1/2008 12/31/2010 Active GEN1

M-101 Weiss Jean 3/4/1965 P-001 01-Spouse 1/1/2008 12/31/2010 Active FAM3

M-102 Weiss David 3/12/1996 P-001 19-Child 1/1/2008 12/31/2010 Active FAM3

M-103 Weiss Jennifer 5/12/1998 P-001 19-Child 1/1/2008 12/31/2010 Active FAM3

S-002 Schlatter Jane 4/4/1956 P-002 18-Self 1/1/2008 12/31/2010 Active FAM2

M-201 Schlatter Thomas 7/10/1959 P-002 01-Spouse 1/1/2008 12/31/2010 Active INT2

M-202 Schlatter Laura 5/12/1990 P-002 19-Child 1/1/2008 12/31/2010 Active FAM2

M-203 Schlatter Nancy 8/20/1991 P-002 19-Child 1/1/2008 12/31/2010 Active FAM2

S-003 Miller Eugene 11/27/1960 P-003 18-Self 1/1/2008 12/31/2010 Active FAM1

M-301 Miller Beth 2/27/1962 P-003 01-Spouse 1/1/2008 12/31/2010 Active GEN2

M-302 Miller Chris 6/12/1997 P-003 19-Child 1/1/2008 12/31/2010 Active GEN3

M-303 Miller Amy 4/28/2000 P-003 19-Child 1/1/2008 12/31/2010 Active GEN3


ID # Last First DOB Policy # Role Eff Date Term Date Status PCP #

S-004 Martin Julia 2/16/1945 P-004 18-Self 1/1/2008 12/31/2010 Active FAM1

M-401 Martin John 10/20/1940 P-004 01-Spouse 1/1/2008 12/31/2010 Active GEN1

S-005 Keuhn Enrico 4/27/1948 P-005 18-Self 1/1/2008 12/31/2010 Active GEN2

M-501 Keuhn Ladena 9/30/1949 P-005 01-Spouse 1/1/2008 12/31/2010 Active GEN2

S-006 Dixon Mark 5/15/1952 P-006 18-Self 1/1/2008 12/31/2010 Active INT1

M-601 Dixon Mary 5/15/1954 P-006 01-Spouse 1/1/2008 12/31/2010 Active INT3

S-007 Gast Ronald 10/14/1950 P-007 18-Self 1/1/2008 12/31/2010 Active

M-701 Gast Linda 2/4/1952 P-007 01-Spouse 1/1/2008 12/31/2010 Active

M-702 Gast Carl 5/19/1980 P-007 19-Child 1/1/2008 6/30/2008 Inactive

S-008 Brown James 10/14/1950 P-008 18-Self 1/1/2008 12/31/2010 Active

M-801 Brown Julia 2/4/1952 P-008 01-Spouse 1/1/2008 12/31/2010 Active

M-802 Brown Oliver 5/19/1980 P-008 19-Child 1/1/2008 6/30/2008 Inactive

S-009 Stokes Joseph 10/14/1950 P-009 18-Self 1/1/2008 12/31/2010 Active

M-901 Stokes Martha 2/4/1952 P-009 01-Spouse 1/1/2008 12/31/2010 Active

M-902 Stokes Albert 5/19/1980 P-009 19-Child 1/1/2008 6/30/2008 Inactive

S-010 Baker Richard 1/28/1960 P-010 18-Self 1/1/2006 12/31/2007 Inactive

M-1001 Baker Deborah 3/4/1965 P-010 01-Spouse 1/1/2006 12/31/2007 Inactive

M-1002 Baker Timothy 3/12/1996 P-010 19-Child 1/1/2006 12/31/2007 Inactive

M-1003 Baker Carol 5/12/1998 P-010 19-Child 1/1/2006 12/31/2007 Inactive

S-011 Bishop John 4/12/1939 P-011 18-Self 1/1/2008 12/31/2010 Active INT1


Provider Data The provider type abbreviations used in this table are:

■ H — Hospital

■ PC — Primary Care Physician

■ CO — Consulting

■ PE — Performing

■ OP — Operating

Provider ID

Provider Tax ID

Electronic Trans ID Type Specialty # Specialty

Last Name / Org Name First Name

BIDMC 11-1111111 H-001 H 282N00000X Hospital Beth Israel Deaconess Medical Center

BWH 22-2222222 H-002 H 282N00000X Hospital Brigham and Women's Hospital

DFCI 33-3333333 H-003 H 282N00000X Hospital Dana Farber Cancer Institute

MGH 44-4444444 H-004 H 282N00000X Hospital Massachusetts General Hospital

NEMC 55-5555555 H-005 Hl 282N00000X Hospital New England Medical Center

FAM1 10-1010101 F-001 PC 207Q00000X Family Medicine Bhatti Nasir

FAM2 10-1010102 F-002 PC 207Q00000X Family Medicine Bordes Mary

FAM3 10-1010103 F-003 PC 207Q00000X Family Medicine Chiang Mary

GEN1 20-2020201 G-001 PC 208D00000X General Medicine

Ancona Carl


Provider ID

Provider Tax ID




Burns Erin


Byrn Michael

INT1 30-3030301 I-001 PC 207R00000X Internal Medicine Bertelson John

INT2 30-3030302 I-002 PC 207R00000X Internal Medicine Bernstein Matthew

INT3 30-3030303 I-003 PC 207R00000X Internal Medicine Binder Lisa

CHIRO1 40-4040401 C-001 CO 111N00000X Chiropractor Barone David

CHIRO2 40-4040402 C-002 CO 111N00000X Chiropractor Meyer Robert

CHIRO3 40-4040403 C-003 CO 111N00000X Chiropractor Lee Frank

CREHAB1 50-5050501 CR-001 PE 261QR0404X Cardiac Rehab Facility

New England Cardiac Rehab


Boston Cardiac Rehab


Northeast Cardiac Rehab

POD1 60-6060601 P-001 CO 213E00000X Podiatry Calder Gerard

POD2 60-6060602 P-002 CO 213E00000X Podiatry Ayala Enrico

POD3 60-6060603 P-003 CO 213E00000X Podiatry Smith Marshall

CARD1 70-7070701 CRD-001 CO 207RC0000X Cardiology Brimer Joseph

GAST1 80-8080801 GAST-001 CO 207RG0100X Gastroenterology Bongiorno Charles

HHA1 90-9090901 HHA-001 PE 251E00000X Home Health Agency

New England Home Health

GRP1 66-6666666 GRP-001 PC 193200000X Multi-Specialty Group

New England Medical Associates


Provider ID

Provider Tax ID



GRP2 77-7777777 GRP-002 CO 207P00000X Emergency Medicine

New England Critical Care Associates

GRP3 98-9898989 GRP-003 PC 193400000X Medical Group – Single Specialty

Well Health Clinic


Good Foot Clinic


Fine Spine Clinic

RHM1 88-8888888 RHM-001 CO 207RR0500X Rheumatology Denman Susan

EMERG1 99-9999999 EMERG-001

CO 207P00000X Emergency Medicine

Bell Stuart

EMERG2 99-9999998 EMERG-002


Laplante Michael

EMERG3 99-9999997 EMERG-003


Brown John

OBGYN1 10-1111111 OBGYN-001

CO 207V00000X OB - GYN Norin Sandra

RAD1 20-2222222 RAD-001 PE 203BR0201Y Radiology New England Radiology Associates

PLAST1 30-3333333 PLAST-001

OP 208200000X Plastic Surgery Morgan Timothy

Figure 2-16. Provider Data


Policy Data Policy #

Policy Type

Plan #

Plan Type

Group #

Group Name

Effective Date

End Date

P-001 Family HMO15 HMO G-001 Pegasystems Inc. 1/1/2008 12/31/2010

P-002 Family HMO15 HMO G-002 Razorfish Inc. 1/1/2008 12/31/2010

P-003 Family HMO15 HMO G-003 Eclyspis Inc 1/1/2008 12/31/2010

P-004 Emp + Sp POS15 POS G-001 Pegasystems Inc. 1/1/2008 12/31/2010

P-005 Emp + Sp POS15 POS G-002 Razorfish Inc. 1/1/2008 12/31/2010

P-006 Emp + Sp POS15 POS G-003 Eclyspis Inc 1/1/2008 12/31/2010

P-007 Family PPO15 PPO G-001 Pegasystems Inc. 1/1/2008 12/31/2010

P-008 Family PPO15 PPO G-002 Razorfish Inc. 1/1/2008 12/31/2010

P-009 Family PPO15 PPO G-003 Eclyspis Inc 1/1/2008 12/31/2010


P-011 Emp Only HMO15 HMO G-001 Pegasystems Inc. 1/1/2008 12/31/2010




P-015 Emp + Sp POS15 POS G-003 Eclyspis Inc 1/1/2006 12/31/2007

Figure 2-17. Policy Data


Plan Benefit Data Plan # Plan Name Description Effective

Date End Date

HMO15 HMO Plan 1 $15 OV, $50 ER, $75 IP, $15 / $25 / $30 Rx 5/12/2002 12/31/3000

PPO15 PPO Plan 1

$15 OV, $50 ER, $20 / $40 / $60 Rx, Non-Network $250 / $500 Ded, 80% to $3000 / $6000 5/12/2002 12/31/3000

POS15 POS Plan 1

$15 OV, $50 ER, $75 IP, $20 / $40 / $60 Rx, Non-Network $250 / $500 Ded, 80% to $1000 / $2000 5/12/2002 12/31/3000

CHIRO10 Chiro Rider 1 $10 OV, 20 VS MAX 5/12/2002 12/31/3000

DEN10 Dental Plan 1 70%, $50 / $150 / $1500 DED 5/12/2002 12/31/3000

Figure 2-18. Plan / Benefit Data

Claim Data Claim #

Mbr ID

Svc Pvder ID

Total Charge

Svc From Date

Svc To Date

Claim Type

Status Svc Code

Description

CLM-001 M-103 EMERG1 340 5/10/2009 5/10/2009 P Paid 99284 Emergency Medical Care

CLM-002 M-101 OBGYN1 55 5/10/2009 5/10/2009 P Paid 59025 Maternity Service

CLM-003 M-801 HHA1 340 5/10/2009 5/10/2009 I Denied S9330 Home Health Service

CLM-004 M-501 CARD1 25 5/10/2009 5/10/2009 I Paid 93797 Cardiac Rehab Service

CLM-005 S-006 GAST1 1600 5/10/2009 5/10/2009 P Paid 91110 GI Service

Figure 2-19. Claim Data


Sample Data to Test the Authorization Management Solution

The Authorization type abbreviations used are: ■ SC — Specialty Care Review ■ HS — Health Service Review ■ AR — Admission Review

Auth #

Requesting Prov ID

Member ID

Auth Type

Status

Description

Auth-1001 G-001 S-002 SC Resolved-Denied Service Prov Not on File

Auth-1002 CRD-001 M-301 SC Resolved-Denied Requesting Prov Not a PCP

Auth-1003 G-001 S-999 SC Resolved-Denied Subscriber Not Found

Auth-1004 G-002 M- SC Resolved-Denied Patient Not Found

Auth-1005 G-002 M-902 SC Resolved-Denied Patient Not Eligible

Auth-1006 G-002 M-501 HS Resolved-Denied Experimental Treatment (Thermograph)

Auth-1007 G-001 M-401 HS Resolved-Denied Experimental Treatment (Dynamic Infra-red Perfusion Imaging)

Auth-1008 I-001 S-006 HS Resolved-Denied Experimental Treatment (Surface Scan)

Auth-1009 I-001 S-008 HS Resolved-Denied Experimental Treatment (EMG)

Auth-1010 I-002 S-007 HS Resolved-Denied Cosmetic Surgery

Auth-1011 F-001 S-003 HS Resolved-

NoAuthRequired

No Auth Required (Diagnostic X-Ray)

Auth-1012 I-001 S-011 HS Resolved-

NoAuthRequired

No Auth Required (Diagnostic Lab)

Auth-1013 F-003 M-101 HS Resolved-

NoAuthRequired

No Auth Required (EKG)

Auth-1014 I-002 M-201 HS Resolved-

NoAuthRequired

No Auth Required (Cardiac Stress Test)


Auth #

Requesting Prov ID

Member ID

Auth Type

Status

Description

Auth-1015 G-002 M-301 HS Resolved-

NoAuthRequired

No Auth Required (Joint Aspiration)

Auth-1016 G-002 M-901 HS Resolved-

NoAuthRequired

No Auth Required (Echocardiogram)

Auth-1017 G-002 M-801 HS Pending-Review Cardiac Rehab (Service Not Eligible - Diagnosis not matched)

Auth-1018 G-002 S-008 HS Pending-Review Cardiac Rehab (Service Not Eligible - Svc Prov Specialty not

matched)

Auth-1019 G-002 S-009 HS Pending-Review Cardiac Rehab (Service Not Eligible - Diagnosis date too old)

Auth-1020 G-001 S-001 HS Pending-Review Chiro Service (Service Not Eligible - Diagnosis not matched)

Auth-1021 G-001 S-007 HS Pending-Review Chiro Service (Service Not Eligible - Service Provider Specialty

not matched)

Auth-1022 F-002 S-002 HS Pending-Review Podiatry Service (Service Not Eligible - Diagnosis not matched)

Auth-1023 F-002 S-011 HS Pending-Review Podiatry Service (Service Not Eligible - Svc Prov Specialty not

matched)

Auth-1024 G-002 M-801 HS Resolved-Approved Cardiac Rehab

Auth-1025 G-002 S-008 HS Resolved-Approved Cardiac Rehab

Auth-1026 G-002 S-009 HS Resolved-Approved Cardiac Rehab

Auth-1027 G-001 S-001 HS Resolved-Approved Chiro Service

Auth-1028 G-001 S-007 HS Resolved-Approved Chiro Service

Auth-1029 F-002 S-002 HS Resolved-Approved Podiatry Service

Auth-1030 F-002 S-011 HS Resolved-Approved Podiatry Service

Auth-1031 F-002 S-011 AR Pending-Review Admission Request

Figure 2-20. Authorization Data


Sample Data to Test the New Member Enrollment Solution Sample Employer Group data is provided or you can create new sample data to test the New Member Enrollment layer. Two instances of sample Employer Group records are preconfigured:

■ GRP-0001 — Joerg’s Bookstore

■ GRP-0002 — Jeff’s Diner


Sample Data to Test the Appeals and Grievance Management Solution

To help you test the system, the Appeals and Grievance Management layer you can uses the following sample data. This sample data is leveraged from the underlying Healthcare Industry Framework and is shown in previous tables. These members have denied authorizations / and / or claims associated with them.

Member Information

ID Last First DOB Policy Role

S-006 Dixon Mark 5/15/1952 P-006 Subscriber

S-007 Gast Ronald 10/14/1950 P-007 Subscriber

S-008 Brown James 10/14/1950 P-008 Subscriber

M-401 Martin John 10/20/1940 P-004 Spouse

M-501 Keuhn Ladena 9/30/1949 P-005 Spouse

M-801 Brown Julia 2/14/1952 P-008 Spouse

Provider Information

ID Last First Specialty

INT1 Bertelson John 207R00000X Internal Medicine

INT2 Bernstein Matthew 207R00000X Internal Medicine

GEN1 Ancona Carl 208D00000X General Medicine

GEN2 Burns Erin 208D00000X General Medicine

Claims ID For Member

CLM-1 M-801


Authorizations

ID For Member

Auth-1 M-501

Auth-2 M-401

Auth-3 S-006

Auth-4 S-008

Auth-5 S-007


Common Object Sample Data Maintenance The Healthcare Industry Framework comes with preconfigured sample data instances for commonly referenced objects. The sample data in the framework is used in the solution layers (Apeals & Grievances Manager, Authorization Management, New Member Enrollment) as well as other healthcare frameworks (Customer Process Manager for Healthcare, Claims Automation Suite, Sales Process Manager, and Care Management Workflow), The sample data model can also be used to quickly develop proof of concept demonstrations without having to configure SQL / Oracle / DB2 queries to external databases.

Instances for the following data classes are included:

■ Member

■ Provider

■ Policy

■ Claim

■ Authorization

■ Employer Group

■ Plan Benefits

■ Company

The PegaHC-Maintenance-Work workpool in the Framework also includes workflows for maintaining and creating the sample data instances for the objects mentioned above. . The Search Object Model processing option is available from the Run > Process menu option of the Developer portal. (Figure 2-21).


Figure 2-21. Search Object Model Menu Option


PegaHC-Data-Party-Member (Sample Members) Figure 2-22 and Figure 2-23 show the Member maintenance workflow options.

Figure 2-22. Member Search

Figure 2-23. Member Data Update


Key Rules for Member Maintenance Figure 2-24 shows the key workflow rules used in the member maintenance processes.

Rule Name Rule Type Function

Class: PegaHC-Maintenance-Work

MemberSearch Flow Launches the member search workflow

MemberNew Flow Launches new member data instance workflow

MemberMaintenance Flow Launches member maintenance workflow Figure 2-24. Member Maintenance Workflow Rules


PegaHC-Data-Party-Provider (Sample Providers) Figure 2-25 and Figure 2-26 show the Provider Maintenance workflow options.

Figure 2-25. Provider Search

Figure 2-26. Provider Data Update


Key Rules for Provider Maintenance Figure 2-27 shows the workflow rules used in the provider maintenance process.



ProviderSearch Flow Launches the provider search workflow

ProviderNew Flow Launches the new provider data instance creation workflow

ProviderMaintenance Flow Launches the provider maintenance workflow Figure 2-27. Provider Maintenance Workflow Rules


PegaHC-Data-Policy (Sample Policies) Figure 2-28 and Figure 2-29 show the Policy Maintenance workflow options.

Figure 2-28. Policy Search

Figure 2-29. Policy Data Update


Key Rules for Policy Maintenance Figure 2-30 shows the workflow rules used in the policy maintenance .



PolicySearch Flow Launches the search screen workflow

PolicyNew Flow Launches the new policy data instance creation workflow

PolicyMaintenance Flow Launches the policy maintenance workflow Figure 2-30. Policy Maintenance Workflow Rules


PegaHC-Data-Claim (Sample Claims) Figure 2-31 and Figure 2-32 show the ClaimSearch workflow options.

Figure 2-31. Claim Search

Figure 2-32. Claim Header Data


Key Rules for Claim Maintenance Figure 2-33 shows the workflow rules used in the claim maintenance process.



ClaimSearch Flow Launches the claim search workflow

NewClaims Flow Launches the new claim data instance creation workflow

ClaimMaintenance Flow Launches the Claim Maintenance worklfow Figure 2-33. Claim Maintenance Workflow Rules


PegaHC-Data-Authorization (Sample Authorizations) Figure 2-34 and Figure 2-35 show the Authorization Maintenance workflow options.

Figure 2-34. Authorization Search

Figure 2-35. Authorization Data


Key Rules for Authorization Maintenance Figure 2-36 shows the workflow rules used in the authorization maintenance .



AuthSearch Flow Launches the auth search workflow

AuthNew Flow Launches the new auth data instance creation workflow

AuthMaintenance Flow Launches the auth maintenance workflow Figure 2-36. Authorization Maintenance Workflow Rules

PegaHC-NME-Data-EmployerGroup (Sample Employer Groups) Figure 2-37 and Figure 2-38 show the Employer Group Maintenance workflow options.


Figure 2-37. Employer Group Search

Figure 2-38. Employer Group Data Updates


Key Rules for Employer Group Maintenance Figure 2-39 shows the workflow rules used in the Employer Group maintenance process.



EmployerGroupSearch Flow Launches the search workflow

EmployerGroupNew Flow Launches the new employer group data instance creation workflow

EmployerGroupMaintenance Flow Launches the employer group maintenance workflow

Figure 2-39. Authorization Maintenance Workflow Rules

PegaHC-Data-Product (Sample Plan / Benefits) Figure 2-28 and Figure 2-29 show the Plan Benefit (Product) Maintenance workflow options.

Figure 2-40. Product Search

Figure 2-41. Product Data Update (Product Information Tab)


Figure 2-42. Product Data Update (Benefits Tab)

Key Rules for Plan / Benefit Maintenance Figure 2-30 shows the workflow rules used in the plan benefit maintenance process.



PlanBenefitSearch Flow Launches the search workflow

ProductNew Flow Launches the workflow for creation of new plan benefit instances

PlanBenefitsMaintenance Flow Launches the plan / benefits maintenance woirkflow

Figure 2-43. Plan Benefit Maintenance Workflow Rules


PegaHC-Data-Company (Sample Companies) Figure 2-28 and Figure 2-29 show the Company Maintenance workflow options.

Figure 2-44. Company Search

Figure 2-45. Company Data Update


Key Rules for Company Maintenance Figure 2-46 shows the workflow rules used in the company maintenance process.



CompanySearch Flow Launches the search workflow

CompanyNew Flow Launches the workflow for creation of new company data instances

CompanyMaintenance Flow Launches the company data maintenance workflow Figure 2-46. Company Maintenance Workflow Rules


Industry Code Sets Search and Maintenance The Healthcare Industry Framework comes with preconfigured sample database tables for the following code sets:

■ CPT (Current Procedure Terminology) - Procedure codes used in claims

■ HCPCS (Healthcare Procedure Code System) - Another type of Procedure Codes used in claims

■ ICD9 (International Classification of Diseases) - Diagnosis Codes

■ NDC (National Drug Codes) - Drug Codes used in pharmacy claims

■ GCN (Generic Code Number) – Drug Codes used in pharmacy claims

NOTE: The sample code set tables packaged with the framework are for demo purposes only. Use of the CPT code sets in production require subscription license from the American Medical Association. Extend / substitute these tables by the customer’s own data sets.

Search Code Sets

This functionality allows the user to search code sets and review code descriptions.

Figure 2-47. Access to Code Search Functionality


Figure 2-48. Select Code Type

Figure 2-49. Review Search Results (CPT)

Figure 2-50. Review Search Results (HCPCS)


Figure 2-51. Review Search Results (ICD9)

Figure 2-52. Review Search Results (NDC)


Figure 3-54: Review Search Results (GCN)

Manage Code Groups This functionality allows the user to search code sets and create custom code groups that can be used in other processing rules. The Care Management Solution Framework uses this functionality to define custom code groups to search for in medical and pharmacy claims.

Figure 2-53. Access tp Manage Code Groups Functionality


Figure 2-54. Select Code Group

Figure 2-55. Add Codes to Code Group


HIPAA-Enabled Data Model Overview The Healthcare layer consists of a robust data model of properties for common objects such as member, provider, claim, and authorization. These properties (approximately 2000) represent the standard healthcare business properties that support the nine HIPAA EDI transactions. The naming convention and the specifics for each property follow the Healthcare Data Element Dictionary published by Washington Publishing Company.

Object-Oriented Class Model The Healthcare Data Element Dictionary references the properties as they are related to the different HIPAA EDI transactions. The Healthcare Industry Framework organizes these properties in an Object-Oriented Class Structure as shown below to avoid redundancies (Figure 2-56).

Figure 2-56. Object-Oriented Class Structure


Each of the classes shown in Figure 2-57 contains specific properties that belong to the relevant data class. Figure 2-58 shows the properties in the Pega-Data-Party-Member class, and Figure 2-59 shows the properties in the Pega-Data-Claim class.

Figure 2-57. Properties of the PegaHC-Data-Party-Member Class


Figure 2-58. Properties of the PegaHC-Data-Claim Class


HIPAA-Complaint Property Values Many of the properties included in the Healthcare Data Dictionary have standard listings of valid values associated with them. Most of these properties end with a Code in their name. The Data Model incorporates these listing as prompt lists on the Table Edit tab of the property rule.

Figure 2-59 shows the prompt list for an individual relationship.

Figure 2-59. Individual Relationship Property for PegaHC-Data-Party-Member Class


Figure 2-60 shows the prompt list for the taxonomy code.

Figure 2-60. Taxonomy Code Property for PegaHC-Data-Party-Provider Class

While most of the value listings are limited enough to be configured as Prompt Lists, others contain extensive listings. The properties with extensive listings are configured as their own Data Classes with a Data Table associated with them. This allows you to maintain the listing by exporting it to Excel.

Figure 2-61 shows the Data Classes that have their own Data Table associated with them:


Figure 2-61. Data Classes with Data Tables

Examples of instances of these data classes are shown for Claim Status Codes (Figure 2-62) and Claim Status Category Codes (Figure 2-63).

Figure 2-62. Claim Status Codes Instances


Figure 2-63. Claim Status Category Codes Instances

Chapter 3 The Authorization Management Solution

The Authorization Management Solution is a sample workflow that leverages key rules and features of the Framework and the underlying platform. The framework is configured so that you can easily extend it to create your own Authorization Management system.

Authorization (also known as referral / precertification) management is an administrative process handled by the Case Management or Utilization Management departments at healthcare payer organizations (Health Plan). Healthcare service providers (mostly physicians) may be required to get a health plan’s prior approval before certain services are delivered to certain members (patients) covered by the Health Plan. The types of services that may require prior approval are determined by the member’s plan type and benefit structure.


There are three types of requests for authorizations. The values for the Request Type Code mentioned below are standard HIPAA-mandated values from the X12 278 (Healthcare Service Review) transaction implementation guide.

■ Admission Review (AR) — a request for prior authorization for admission to a hospital or skilled nursing facility

■ Specialty Care Review (SC) — a request for authorization of a referral to a specialist

■ Health Service Review (HS) — a request for prior certification of a service (such as CT Scan)

The Authorization Management Solution 3-3

Understanding the Preconfigured Workflow Figure 3-1 shows the key elements of the preconfigured process in the Framework. Each of the key components is briefly described below with a reference to the key rules and a recommendation for extension.

Figure 3-1. Key Elements of Preconfigured Process


HIPAA EDI Exchange Healthcare providers and payer organizations who engage in electronic exchange of the Healthcare Service Review and Response messages are required to comply with the HIPAA-mandated X12 278 Transaction Standard. The official Implementation Guide for the 278 Transaction (and other HIPAA Standard Transactions) is published by Washington Publishing Company and describes the format, syntax, and data requirements of the 278 EDI Transaction.

High Level 278 EDI Exchange Architecture Figure 3-2 shows the architecture of a 278 EDI exchange.

Figure 3-2. EDI Exchange Architecture

EDI Validation The X12 EDI exchange requires six validation levels to be compliant with the HIPAA Standard. It is assumed that these validations are performed by the Payer’s EDI Gateway and are beyond the scope of this Framework.


X12 278 Integration In production, the EDI message is likely to be integrated with Process Commander using one of the service and listener rules such as MQ, File, and SOAP.

Once the X12 278 file is made available to Process Commander, the 278 message segments are parsed and the data in the segments is mapped to the X12 properties on the clipboard. The X12 segments and properties are then mapped to the business-specific properties belonging to the authorization request work object.

For purposes of demonstration, testing, and showing the processes of parsing and work object creation the Framework includes a sample 278 transaction with 31 separate authorization request messages in one batch file. The batch file is hard-coded in the Java step of the ParseRequestTestData activity in the PegaHC-X12-Data-N278-Transaction class (Figure 3-3).

Figure 3-3. ParseRequestTestData Activity


Figure 3-4 shows the quick-launch hyperlink that is included on the UM Case Manager portal. Use this link to launch the activity and thereby the X12 parsing process.

Figure 3-4. Quick Launch Hyperlink

The Framework leverages the generic X12 parsing configuration of the underlying Healthcare Industry Framework (PegaHC), described in Chapter 4, “X12 Message Processing.” Once the file is parsed, the process returns a Statistics screen that displays some metrics of the X12 transaction and indicates whether any errors were encountered during the parsing.

Extension Tip: The error trapping and debugging process can be extended so system architects or system administrators can get additional information about the segments in error.

The next key step in the process is to map the X12 segments and properties to the business-specific properties on the work object. This is done in the


ProcessTransaction activity. The mapping involves properties associated with the overall request and the service (such as request type, requested urgency, service type, procedure, and diagnoses codes) as well as specific properties associated with the parties (referring service providers, subscriber, and if different than the member).

Extension Tip: Mapping to the work object properties is limited to the commonly requested service types (such as specialty care referral, admission request, and healthcare service review). Mapping can be extended to include additional parsing and mapping of specific services requests as described in the 278 Implementation Guide (such as home health care service, home oxygen therapy, and spinal manipulation service).

The individual authorization request messages of the batch transaction are processed against the business validation rules configured in the workflow (described later) and the resulting status (certified, denied, pending) is assembled in the 278 Response Transaction along with original request message. The Response transaction is written to a Temp folder on the server (Figure 3-5).

Figure 3-5. Output File Location


In production, the outbound response transaction process is similar to the inbound process using one of the service rules.

Key Rules for X12 278 Integration Figure 3-6 shows the activities that are used for the X12 278 integration.

Rule Name Function

Class: PegaHC-X12-Data-

X12ParseMessageStart Starts the processing of an X12 file

X12ParseMessageType Determines the message type

X12WriteMessage Writes an outbound X12 message to a file

Class: PegaHC-X12-Data-N278

X12ParseMessage Parses and maps the 278 message into X12 segments and properties on an X12 page on the clipboard

CreatePegaHCData Sets up the 278 Response with initial segments. Starts the processing of each transaction

MapToResponse Maps data from AuthorizationRequest work object to 278 Response page after work object has been processed

MoveDataToResponse Creates the 278 Response page and sets it up with initial segments

ProcessAuthorization Defined in the PegaHCAUTH RuleSet, creates an AuthorizationRequest work object, executes the flow defined for it, and updates the 278 Response with the results

X12GenerateResponse Assembles the data on the 278 Response page into an X12 formatted message

Class: PegaHC-X12-Data-N278-Transaction

ParseRequestTestData Launches the parsing of the test file


Rule Name Function

ProcessTransaction Maps the Transaction X12 segments and properties to the Authorization Data object and to the 278 Response page

MoveDataToResponse Moves transaction segments to 278 Response page

Class: PegaHC-X12-Data-N278-Loop2000EServiceProviderLevel

MapToAuthorization Maps the Service Provider X12 segments and properties to the Authorization Data object and to 278 Response page

MoveDataToResponse Moves Service Provider segments to 278 Response page

Class: PegaHC-X12-Data-N278-Loop2000FServiceProviderLevel

MapToAuthorization Maps the Service Line X12 segments and properties to the Authorization Data object and to 278 Response page

MoveDataToResponse Moves Service Line segments to 278 Response page Figure 3-6. X12 278 Integration Activity Rules


Manual Request Generation Although the Web Service Portal and X12 278 EDI exchange are the two most common ways for submitting an authorization request to the payer organization, a Process Commander harness also can be used to manually create and submit a transaction. The Utilization (Case) Management department may have users creating requests manually from faxed transactions or requests taken by telephone, or they can be generated by customer service (member and/or provider) applications.

Figure 3-7 shows the link to launch New Authorization Request from the UM Case Manager Portal. Additionally, the Foundation (PegaHC) layer (PegaHC) of the framework provides pre-configured sample data instances for authorizations that can be used to demonstrate manual auth processing.

Figure 3-7. New Auth Request Link on UM Case Manager Portal

To create a New Authorization Request, click the New Auth Request link. The following series of screens are displayed (Figure 3-8 to Figure 3-12).


Figure 3-8. New Auth Request – Enter IDs

Figure 3-9. New Auth Request – Select Policy


Figure 3-10. New Auth Request – Enter Auth Info

Figure 3-11. New Auth Request – Review Auth Request Info (Before Processing)


Figure 3-12. New Auth Request – Review Auth Request (After Processing)


Key Rules for the Manual Request Generation Process Figure 3-13 lists the activity and harness rules that are used in the manual request generation process.


Class: PegaHC-AUTH-Work-AuthRequest

NewAuthRequest Flow Initiates the new authorization request manual process

EnterAuthRequest Flow Manages entry of the new authorization request manual process

EnterIDs Flow Action Allows user to enter Member, Requesting, & Service Provider IDs

SelectPolicy Flow Action Allows user to select a policy for the member

EnterAuthInfo Flow Action Allows user to enter authorization information

ReviewAuthData Flow Action Allows user to review entered authorization information

NewAuthRequest Activity Manages the new authorization request manual process

SaveAuthData Activity Saves the authorization data instance after processing

Class: PegaHC-Data-Authorization

AuthSearch Activity Launches the authorization search process

GetAuthList Activity Gets the list of authorizations based on search parameters

DisplaySampleAuth Activity Displays the sample authorization

AuthNew Activity Creates a new authorization



SaveAuthAsWorkItem Activity Saves the sample authorization as a work item

AuthSearch Harness Displays the Authorization Search screen

AuthDisplay Harness Displays the Authorization Display screen

Figure 3-13. Manual Request Generation Rules


Authorization Request Processing All authorization request transactions submitted create a work object and are processed as shown in the ProcessAuthorizationRequest workflow in the PegaHC-AUTH-Work-AuthRequest class (Figure 3-14).

Figure 3-14. Process Authorization Request Workflow

Figure 3-14 shows that the submitted transaction follows the straight through processing path and is validated against business validation rules to determine if it can be automatically approved or denied. The Framework includes some examples of business rule validations. Some of these validations are performed procedurally while others are done declaratively (based on the relationships among data items).


The validation rule categories are applied as independent objects so you can rearrange the order of the high-level categories as well as the groups of changes within a category.


Procedural Validations The Framework includes examples of procedural validations for the referring provider and member information submitted on the Authorization Request. These validations are performed against sample data instances in the PegaHC-Data-Party-Provider and PegaHC-Data-Party-Member classes, respectively. The Framework also includes a process to check for potential duplicate requests.

The intent of these types of validations is to determine if the request is legitimate and worth processing.

Extension Tip: The current workflows for searching providers and members are placeholders for the validation process. In production, the integration with the payer’s legacy data will involve one of the other service and / or connector rules.

The Framework assumes a single match against the searched data instance. In production, the workflow should be updated to accommodate situations when multiple matching records are found.

Member Validation The Framework includes a process to validate the member (patient) information submitted on the Authorization Request. The validation is performed against the sample member data records stored in the PegaHC-Data-Party-Member class. See Chapter 2, What is Already Set Up for the complete list of sample Member Data. Figure 3-15 shows the ValidateMember workflow which includes a process to search for the member by ID and then by a combination of last name, first name, and date of birth.


Figure 3-15. ValidateMember Flow


The following validations (Figure 3-16) are performed in the ValidateMember workflow.

Validation Reject Reason Code

Patient Not Found 77

Patient Not Eligible 95 Figure 3-16: Member Validations

The Framework validates the member if the member is active on the requested service date on the authorization by comparing the service date to effective and term dates on the member data.

Key Rules for the Member Validation Process Figure 3-17 shows the rules that are used in the member validation process.



ValidateMember Flow Launches the member validation process

GetMemberDataByID Activity Searches for the member by ID

GetMemberDataByOther Activity Searches for the member by name and DOB

MemberNotFound When Checks to see if a member record was found

MemberIneligibleOnServiceDate When Checks to see if the member is active on the service date

Figure 3-17. Member Validation Rules


Extension Tip: The current workflow for searching and validating members is a placeholder. In production, the integration with the payer’s legacy data will involve one of the other service and / or connector rules.

The Framework assumes a single match against the searched data instance. In production, the workflow should be updated to accommodate situations when multiple matching records are found.

Referring Provider Validation The Framework includes a process to validate the referring (requesting) provider information submitted on the Authorization Request. The validation is performed against the sample provider data records stored in the PegaHC-Data-Party-Provider class. See Chapter 2, What is Already Set Up for the complete list of sample Provider Data.

Figure 3-18 shows the ValidateReferringProvider workflow that includes a process to search for the referring provider by ID.


Figure 3-18. ValidateReferringProvider Flow

The following validations are performed in the ValidateReferringProvider workflow.

Validation Reject Reason Code

Provider Not On File 51

Provider is not a Primary Care Physician 49

The Framework validates the Primary Care Physician (PCP) only when the member’s plan type is HMO. The requesting provider ID is matched against the PCP ID on the member data retrieved in the earlier process.


Key Rules for the Referring Provider Validation Process Figure 3-19 shows the rules that are used in the referring provider validation process.



ValidateReferringProvider Flow Launches the provider validation process

GetReferringProviderDataByID Activity Searches for the provider by ID

ReferringProviderNotFound When Checks to see if a referring provider record was found

ReferringProviderNotPCP When Checks to see if the referring provider is a PCP for the member

Figure 3-19. Referring Provider Validation Rules

Extension Tip: The current workflow for searching and validating providers is a placeholder. In production, the integration with the payer’s legacy data will involve one of the other service and / or connector rules. The Framework assumes a single match against the searched data instance. In production, the workflow should be updated to accommodate situations when multiple matching records are found.

Duplicate Request Validation The Framework includes a process to validate for potential duplicate requests. The validation is performed against existing Authorization Requests (instances of PegaHC-AUTHWork-AuthRequest).

Figure 3-20 shows the DuplicateCheck workflow that includes a process to search for potential duplicate records with previously created work objects.


Figure 3-20. DuplicateCheck Flow

Comparison of the following data elements determines if this is a duplicate request: ■ Request Type ■ Requesting Provider ID ■ Member ID ■ Service Type ■ Service Date ■ Request Status (of Pending)

An item match is only considered if all of the data elements listed above are the same as the current request. If a single match is found to all of the data elements listed above, the request transaction is denied, and the following data elements are set:

■ Certification Action Code = A3 (Not Certified) ■ Reject Reason Code = 91 (Duplicate Service)


Key Rules for the Duplicate Request Validation Process Figure 3-21 shows the rules that are used in the duplicate request validation process.



DuplicateCheck Flow Launches the duplicate request validation process

LookupDuplicate Activity Performs matching for potential duplicates Figure 3-21. Referring Provider Validation Rules


Declarative Validations The Framework includes examples of declarative validation rules for the specific requested services. These types of validations are intended to automatically approve or deny specific service requests and achieve straight through processing where possible. These validations reduce the number of requests that need to be processed manually.

Extension Tip: Although the framework includes only a few examples of these types of validations, the declarative network described below can easily be extended to include other service types and increase the rate of straight through processing.

Key Rules for the Declarative Process Declarative rules provide a way for you to set or restrict property values, dynamically retrieve the necessary data, and automate the decision of when to perform a process. In the Authorization Management framework, the main flow called ProcessAuthorizationRequest uses declarative rules to reach an automated decision.

The process begins by validating the member, and referring provider, and checking for duplicates. If the authorization request passes the member and provider validity screening and the procedural checks for duplicates, it begins the declarative processing by calling the decision tree AuthorizationDecision in the PegaHC-Data-Service class. Figure 3-22 shows the decision tree for AuthorizationDecision.


Figure 3-22. AuthorizationDecision Decision Tree

This decision tree establishes a value for the AuthorizationDecision property (which contains the text description of the decision) and the ActionCode property (which contains the X12 standard code for the decision). The decision tree checks the values of the AuthorizationStatus property for each of the Procedure Lines and sets the overall decision for the authorization.

The AuthorizationStatus values for the Procedure Line are calculated using a declare expression in the PegaHC-AUTH-Work-AuthRequest class. This expression uses the decision tree called AuthorizationDecision in the PegaHC-Data-Service class and possibly one of the following decision trees to establish a value: ■ CardiacRehabDecision ■ ChiroServicesDecision ■ PodiatryServicesDecision


Figure 3-23 shows the decision tree for the CardiacRehabDecision. This decision tree evaluates the treatment type of the procedure, the diagnosis codes and dates, and the number of requested units for the service. Similar validations for other specific service requests may include evaluating other parameters of the request (such as provider’s specialty, member’s age, member’s plan type).

Figure 3-23. Cardiac Rehab Decision Tree


The decision tree rules used in this process uses Function Alias rules that allow the system to perform more complicated evaluations while keeping the decision tree rules understandable for a business user. These rules are:

■ DecisionIsInProcedureList (in the PegaHC-Data-Authorization class)

■ DiagnosisInRangeExists (in the PegaHC-Data-Service class)

■ DiagnosisInRangeAndDate (in the PegaHC-Data-Service class)

The Treatment type places ranges of procedures into categories, and it is calculated by a declare expression in the PegaHC-AUTH-Work-AuthRequest class. The declare expression uses a decision table called Treatment in the PegaHC-Data-Service class which looks at the Procedure Code and Treatment Type and then places a procedure into a Treatment category. Figure 3-24 shows the decision table called Treatment.

Figure 3-24. Decision Table for Treatment


Declarative Validations for Non-Covered Experimental Treatments Certain services are considered experimental treatments. The requests for these types of services are considered non-covered and are denied appropriately. Figure 3-25 lists the treatments and service codes. If any one of the service codes match, the service is denied.

Treatment Service Codes

Thermography 93740, 93760, 93762

Dynamic Infra-red perfusion Imaging C9723

Surface Scanning and EMG 95860-872, S3900

Spinal Manipulation under Anesthesia 00640, 22505

Figure 3-25. Non-Covered Experimental Treatments

When any of the services above are encountered, they are denied and the following properties are set on the Response Transaction:

■ Certification Action Code = A3 (Not Certified)

■ Reject Reason Code = 98 (Experimental Service or Procedure)

The work object status is then set to Resolved-Denied.


Declarative Validations for Cosmetic Surgery Figure 3-26 lists the service codes for cosmetic surgery. If any one of the service codes match, the service is denied.

Treatment Service Codes

Cosmetic Surgery 11920-22, 15775-76, 15781, 15788-93, 15828-29, 15831, 19140, 19316, 19318, 19325, 19328, 19330, 19355, 19396, 30400-50

Figure 3-26. Cosmetic Surgery Service Codes


■ Certification Action Code = A3 (Not Certified)

■ Reject Reason Code = 88 (Non-covered Service)



Declarative Validations for Services Not Requiring a Referral Figure 3-27 lists the services not requiring a referral. These are identified by Service Type Codes or Services Codes.

Service Service Type Code

Service Codes

Diagnostic X-Ray 4

Diagnostic Lab 5

EKG 93000, 93005, 93010, 93040-42, 93224-27, 93230-37, 93268, 93270-72

Cardiac Stress Test 93015-18

Echocardiogram 93303-04, 93307-08, 93312-18, 93320-21, 93325, 93350

Joint Aspiration D7870

Figure 3-27. Services Not Requiring a Referral


■ Certification Action Code = No Authorization Required



Declarative Validations for Cardiac Rehab Services Requests for Cardiac Rehab are approved if the request meets the following validations:

■ Service Type Code = BG

■ Service Provider Specialty = 261QR0404X

■ Service Code In = 93797 or 93798

■ Diagnosis Code In = 394-397.9, 398.91, 410.00-414.90, 424.0-424.3, 425.0-425.9, 427.0-427.2, 427.41-427.42, 427.5, V42.1-V42.2, V45.81-V45.82

■ Diagnosis data is not more than 26 weeks old (for example, DATEDIFF IN WEEKS (Diagnosis Date – Current Date) < 26

If all the conditions above are met, the following properties are set on the work object:

■ Certification Number = Work Object ID

■ If the Request Service Units are = or < 30, the action code is set to A1 (certified in total) and the Authorized Units are ser to the Requested Units

■ If the Requested Service Units are > 30, the action code is set to A6 (modified) and the Authorized Units are set to 30


Declarative Validations for Chiropractic Services

Requests for Chiropractic Services are approved if:

■ Service Type Code = 33 OR 34

■ Service Provider Specialty = 111N00000X

■ Service Code In = 99201-04, 98940-43

■ Diagnosis Code In = 353.0-353.9, 722.0-722.11, 723.2-723.4, 724.3, 729.2, 739.0-739.9, 846.0, 846.9, 847.0-847.2

If the above conditions are met, the Action Code is set to A1 (Certified In Total).

Declarative Validations for Podiatry Services Requests for Podiatry Services are approved if:

■ Service Type Code = 93, 94, or 95

■ Service Provider Specialty = 213E00000X

■ Service Code In = 99201-04, 28001-28899

■ Diagnosis Code In = 117.1-117.9, 700.0, 703.8, 250.0-250.90, 443.0, 443.80-443.89, 444.21-444.22, 445.01-445.02

If the above conditions are met, the Action Code is set to A1 (Certified In Total).


Straight Through Processing When the authorization request transaction meets one of the auto-validation rules mentioned above (denial or approval), the corresponding response transaction (278 RP or SOAP Message) is created with the appropriate status codes as mentioned in the specific validations.

In addition, on the 278 Response transaction, Loop 2000F – Service Level is updated with:

An HCR segment containing the following:

■ Certification Action Code is set to one of the following:

− A1 – Certified in Total

− A3 – Not Certified

− A4 – Pended

− A6 – Modified (Partially Approved)

■ Certification Number (work object ID)

■ Reject Reason Code (for denied cases)

The DTP Segment is updated with the following if the request transaction is approved or partially approved:

■ Certification Issue Date (Status Date)

■ Certification Expiration Date (Issue Date + 30 days)

The work object status is set to the appropriate Resolved status.


Manual Processing If the request does not meet any of the auto-denial or auto-approval validations described in the declarative processing section, it is pended for manual processing (Pending-UMReview), and the assignment is transferred to the ServiceReview workbasket.

Extension: Although the Framework includes only a generic workbasket for all pending requests, additional routing can easily be created based on key parameters of the request.

Workflow Attributes Figure 3-28 shows the key attributes of the workflows.

Attribute Description

Application Name Healthcare Payer Authorization Management System

Unit of Work Process Authorization Request

Relevant Org Hierarchy Org: MyHealthPlan

Div: Utilization Management

Unit: Utilization Management

Work Group ServiceReview

Workbaskets ServiceReview@MyHealthPlan

ProviderFeedbackRequest@MyHealthPlan

MDReview@MyHealthPlan

Class Group PegaHC-AUTH-Work

Parties Referring Provider (PegaHC-Data-Party-Provider)

Service Provider PegaHC-Data-Party-Provider)

Member (PegaHC-Data-Party-Member)



Access Groups AUTH:Administrators

AUTH:SystemArchitects

AUTH:ProcessArchitects

AUTH:WorkManagers

AUTH:WorkUsers

AUTH:UMCaseManagers

AUTH:UMCoordinators

AUTH:MedicalDirector

Access Roles AUTH:UMCaseManager

AUTH:UMCoordinator

AUTH:MedicalDirector

Privileges ActionProcessAdmissionRequest

ActionRequestAdditionalInformation

ActionTransferToManager

ActionTransferToMedicalDirector

ActionCommunicateDecisionToProvider

Portals AUTHSysAdmin

AUTHManager

AUTHUser



Work Object Statuses New

Pending-UMReview

Pending-MDReview

Pending-ProviderCommunication

Open-AdditionalInfoRequest

Resolved-Approved

Resolved-PartiallyApproved

Resolved-Denied

Resolved-NoAction

Resolved-Duplicate

Figure 3-28. Key Workflow Attributes


Role-Privilege Matrix Figure 3-29 shows the privileges and roles predefined in the framework.

Roles

Privileges UMCo

ordi

nato

r

Case

Mana

ger

Medi

calD

irect

or

ActionComunicateDecisionToProvider X X

ActionProcessAuthorization X X

ActionRequestAdditonalInformation X X


ActionTransferToMedicalDirector X Figure 3-29. Privileges and Roles

Processing Flow Actions Based on the privileges listed in Role and Privilege matrix, Figure 3-30 shows the options (flow actions) available to users.


Figure 3-30. Processing Option Choices for Users


Process Authorization Figure 3-31 shows the options that allow users to process the request and manually set the disposition at the authorization header level as well as at the service line level. Users can also document the utilization management guideline or medical policy information that was referenced in determining the decision.

Figure 3-31. Authorization Disposition Options

Transfer to Manager or to Medical Director Figure 3-32 shows the options that allow users to transfer the assignment to the Manager or Medical Director with some forwarding notes.

Figure 3-32. Transfer to Manager or Medical Director


Communicate Decision to Provider Once the request is Approved or Denied, users are presented with a screen to communicate the information to the referring provider. The referring provider information is presented for quick reference (Figure 3-33).

Figure 3-33. Communicate Decision to Provider

Extension Tip: This flow action is a place holder for additional detailed processing as per the business requirements. The process can involve integrating with the phone switch for outbound calling and / or linking to correspondence functions to generate correspondence of the final disposition.

Work Urgency Points Matrix The value of property .pyUrgencyWorkAdjust is set to the value in a decision table in a DeclareExpressions Rule by the same name (Figure 3-34).

Figure 3-34. Urgency Decision Table


Service Level Rules Service level rules let you measure and manage quality. The Framework comes with several predefined service level rules described below.

Service Level: AuthRequest The default service level rule is called AuthRequest and is set in the model (pyDefault) on the work object (Figure 3-35).

Figure 3-35. Default Service Level Rule

The default service level rule is Circumstanced based on the value of the RequestedUrgency (U = urgent request, 03 = emergency request). Figure 3-36 shows the Circumstance set to .RequestedUrgency=U in the top right of the form.


Figure 3-36. Service Level Rule Circumstance set to .ReguestedUrgency=U

Figure 3-37 shows the Circumstance set to .RequestedUrgency=03

Figure 3-37. Service Level Rule Circumstance set to .ReguestedUrgency=03

The goal and deadline times are different and reflect the urgency (Figure 3-38). The escalation events upon expiration of the goal and deadline time are the same for all three service levels.


Requested Urgency Goal Time Deadline Time

Routine 3 Days 5 Days

Urgent 12 Hours 1 Day

Emergency 6 Hours 12 Hours Figure 3-38. Goal and Deadline Times

Escalation Activities ■ Goal Time: Transfer to Manager

■ Deadline Time: Notify Manager by Email

Service Level: MedicalInfoRequest The service level rule called MedicalInfoRequest is applied to the assignment when it is open because the provider requested additional information.

Figure 3-39. Service Level Rule


Correspondence Rules The following correspondence rules in the PegaHC-AUTH-Work class are used to produce the request letter (Figure 3-40).

Name Type Purpose


RequestAdditionalInformation Mail Sent to request additional information from the requesting provider to support the requested service authorization

RejectionNotice Mail Sent to inform requestor that the request was rejected because additional information was not received in the specified time frame

SendEmailToManagerOnDeadline Email Sent to notify the manager that the Request has past the Deadline time set on the SLA

Fragment Rules

Logo Mail Sample health plan logo to be inserted in correspondence

Stylesheet Mail Used for formatting the HTML correspondence

HeaderMember Mail Header segment of the correspondence that contains the member name and address

HeaderRequester Mail Header segment of the correspondence that contains the requesting provider’s name and address

AuthReferenceInformation Mail Section that contains the authorization request number, request type, patient name, and received date

Footer Mail Closing paragraph that contains the contact information, operator name, and designation

Figure 3-40. Authorization Management Correspondence and Fragment Rules


The Correspondence Template for requesting additional information creates this letter (Figure 3-41).

Figure 3-41. Correspondence Request


Reports The framework includes two inventory reports that are available from the dashboard.

Open Authorizations by Request Type and Status The report shows all open authorization requests by type (AR – Admission Review, HS – Health Service Review, SC – Specialty Care Review) and status (Figure 3-42).

Figure 3-42. Open Authorizations by Type and Status


Resolved Authorizations by Type The report shows all Requests (by type and status) that have been Resolved in the past 90 days (Figure 3-43).

Figure 3-43. Resolved Authorizations by Type


Drill-Down Details Users can drill down from either report to see the following information (Figure 3-44).

Figure 3-44. Drill-Down Information


Hover Details Users can hover over the Auth Number and see detail information about the authorization (Figure 3-45).

Figure 3-45. Hover Detail Information

Chapter 4 X12 Message Processing

The Accredited Standards Committee (ASC) X12 message is used to transfer data across and between industries. The Healthcare Industry Framework can recognize, accept, and parse messages that comply with the X12 standard. This section provides an overview of an X12 message and how inbound and outbound processing works in the Healthcare Industry Framework.

The X12 standards provide the syntax and control structures that allow data elements, segments, and transaction sets to be defined. Figure 4-1 shows the overall structure of X12 data.


Figure 4-1. Format of an X12 Interchange

ISA*00* *00* *ZZ*SUBMITTERS ID *ZZ*RECEIVERS ID

*050811*0800*U*00401*000000100*0*P*:~

GS*HI*SENDER CODE*RECEIVER

CODE*20050811*0802*2781001*X*004010X094A1~

ST*278*1001~

BHT*0078*13*A20050810001*20050810*0801~

HL*1**20*1~

NM1*X3*2*MY HEALTHPLAN*****PI*MYHP~

HL*2*1*21*1~

NM1*1P*1*DOE*JOHN****46*NEW1~

REF*ZH*NEW1~

N3*125 MILL ST~

N4*BELMONT*MA*02478~

PER*IC*CONTACT PERSON*TE*8005551212*FX*8005551213~

Figure 4-2 shows a portion of an X12 message.

ISA*00* *00* *ZZ*SUBMITTERS ID *ZZ*RECEIVERS ID

*050811*0800*U*00401*000000100*0*P*:~

GS*HI*SENDER CODE*RECEIVER

CODE*20050811*0802*2781001*X*004010X094A1~

ST*278*1001~

BHT*0078*13*A20050810001*20050810*0801~

HL*1**20*1~


X12 Message Processing 4-3

HL*2*1*21*1~

NM1*1P*1*DOE*JOHN****46*NEW1~

REF*ZH*NEW1~

N3*125 MILL ST~

N4*BELMONT*MA*02478~

PER*IC*CONTACT PERSON*TE*8005551212*FX*8005551213~

Figure 4-2. Portion of x12 Message

Each line is a segment that starts off with a segment identifier and ends with a ‘ ~ ’. Each segment is made up of one or more delimited data elements. The most common delimiter used is the asterisk ‘ * ’ and it is used in the example below.

The example above is a part of a 278 transaction. In the example, the following line is an NM1 segment.


This NM1 segment represents the UMO Name. The structure is of the 278 transaction type, Loop 2010A, which means this NM1 segment is the UMO Name. In addition, the first data element in the segment indicates this is the UMO Name.


This segment contains the following data elements:

■ *X3* — Entity identifier code (X3=UMO)

■ *2* — Entity type qualifier (2=non-person entity, 1=person)

■ *MY HEALTHPLAN* — Last name or Organization name

■ ***** — 4 unused data elements

■ *PI* — Identification code qualifier (PI=Payer Identification)

■ *MYHP*— Identification code (UMO Identifier)


Mapping X12 Messages in Process Commander The Healthcare Industry Framework contains all the classes and properties needed to support the data elements in the following transaction types: ■ 837 — Healthcare claim (professional, institutional, and dental) ■ 834 — Healthcare enrollment ■ 278 — Healthcare services review – request and response ■ 270 / 271 – Healthcare eligibility request & response ■ 276 / 277 – Healthcare claim status request & response There is a class for each segment in the X12 standard and a property for each data element in the segment. These classes are common to all transaction types and can be used by each of them. In addition, a class exists for each transaction type (such as PegaHC-X12-Data-N278), which is built using the predefined classes as the inbound X12 message file is processed.

The data in an X12 message is received by a Process Commander listener that maps the data to properties on the clipboard. An activity is called to determine the transaction type that is included in the functional group. A clipboard page is created that includes all the transactions that are found in the functional group. It is assumed that a functional group contains transactions of the same type. However, an X12 message file can contain more than one functional group, and each group can contain different transaction types. While unlikely, Process Commander can process an X12 message file containing multiple transaction types and can map them all to the clipboard. Process Commander maps the data in the message to the X12 clipboard page as follows for a 278 transaction:

■ While maintaining the looping structure, a property of an associated class is created for each segment as embedded pages in the PegaHC-X12-Data-N278 class.

■ Properties are then created in each of these segment classes for each data element.

■ These segment classes are defined in the PegaHC-X12-Data- class and are general for all message types.

■ A class is created for each loop.


X12 Inbound Message Processing The Rule-Service-File instance called X12file.X12.X12Inbound reads the X12 message input file and calls the activity X12ParseMessageStart to start the processing (Figure 4-3). Process Commander reads the X12 Message input file using this Rule-Service-File instance.

Figure 4-3. Rule-Service-File Rule X12File

The X12ParseMessageStart activity includes Java that calls another activity, X12ParseMessageType. The X12ParseMessageType activity sets the type of the transactions that are in each functional group. It then calls the appropriate activity that handles the given message type by calling the X12ParseMessage activity defined in the appropriate class (such as PegaHC-X12-Data-N278).


The X12ParseMessage activity is composed of Java code that parses the message according to its message type (such as 278) to determine the segments and the context of where these segments lie within the message. With this information, the activity determines the classes that should be populated with the data and calls the appropriate Rule-Parse-Delimited rule for each segment. The Rule-Parse-Delimited rule parses the data and puts the data onto the clipboard. After the entire functional group has been processed, an instance of the X12 data object is created.

The Java code used in the X12ParseMessage activity uses the syntax of a given message type, based on the segments used and the format of the transaction as defined in the associated EDI Implementation Guide. The code uses the following logic to parse the X12 message one segment at a time:

Gather control information from the ISA, GS, and ST segments and determine the message type found in the GS functional group.

1. Keep track of the current loop identifier and monitor when it changes. The loop identifier is hard coded into the Java code based on the message type. With the 278 message type, the starting loop ID is HEADER, which switches to the second loop 2000A. The loop ID can change when any of the following is found.

− HL segment identifying a new Hierarchical Level

− NM1 segment identifying a new sub-loop

2. For each segment, identify the ParseDelimited rule name and the class that should be populated with this segments data. Invoke the appropriate ParseDelimited rule that populates the clipboard with the appropriate class and properties. Refer to “Adding Additional X12 Transactions” in Chapter 6 for more information.


X12 Message Classes Two types of classes exist to support processing X12 Messages.

■ Generic classes that are common to all types of X12 messages. There is one class for each segment in the X12 standard.

■ Specific classes for a given message type (such as 278). These are sub-classes of the message type class (such as PegaHC-X12-Data-N278). These classes contain properties that are of the appropriate PegaHC-X12-Data-segment class. Figure 4-4 shows the message class hierarchy.

Figure 4-4. Message Class Hierarchy


Segments and Properties Each data element in a segment results in a property defined in the class for that segment. Refer to the X12 EDI standards documentation for a complete list of all the segments and their data elements (classes and properties). Some of the properties for a 278 message are discussed here for illustration purposes.

Figure 4-5 is a data element diagram taken from the X12 EDI standards documentation showing the data segments in the NM1 segment. The NM1 segment holds the individual or organization name. The first data element, NM101 Entity ID Code, identifies how this name will be used. For example, a value of ‘X3’ identifies this as the name of the UMO. The second data element, NM102 Entity Type Qualifier, determines if this name is for an individual or an organization. A value of 1 is a person and a value of 2 is a non-person.

Figure 4-5. Data Element Diagram for Messages

The data element diagram shown in Figure 4-5 for the NM1 segment results in the creation of the following properties in the NM1_IndividualOrOrganizationalName class (Figure 4-6).


Figure 4-6. Properties Created


Example of 278 Message Figure 4-7 shows an example of a 278 message that was read by the Rule-Service-File instance X12file.X12.X23inbound.

Figure 4-7. Example of 278 Message

Figure 4-8 shows the clipboard page for the HealthServicesRequest (278 transaction type) with the embedded pages expanded to show the RequesterName. On the right, it also shows the properties for the ReceiverName.


Figure 4-8. Example of a Clipboard Message


X12 Activity Rules The mapping of the X12 message into the X12 page on the clipboard is handled by activity rules. Figure 4-9 describes each of the activities used in mapping X12 messages.

Rule Name Function

Class: PegaHC-X12-Data- X12ParseMessageStart Initial activity that starts the processing of an X12 file. This

activity is called from the service rule that handles the X12 inbound interface. It reads the message in and breaks it into sub-messages, each containing a functional group (bounded by GS and GE segments). It then calls X12ParseMessageType for each sub-message for continued processing.

X12ParseMessageType This activity sets the message type and calls the X12ParseMessage activity in the appropriate class to process the message.

X12WriteMessage Writes an outbound X12 message to a file in a temp folder on the server. This activity should be modified to customize output location.

Class: PegaHC-X12-Data-N837 X12ParseMessage Parses and maps the 837 message into X12 segments and

properties on an X12 page on the clipboard by invoking Parse-Delimited-Rules. Each Parse-Delimited-Rule handles the parsing of the data elements in a segment. It creates an instance of the PegaHC-X12-Data-N837 data object and calls the following activity: CreateHCClaimWork to map data to claim work object

CreateHCClaimWork Placeholder activity, implemented in Claims Layer (PegaHCCLM)

X12GenerateProfessional Generates X12 message with single professional claim from X12 clipboard structure


Rule Name Function

X12GenerateInstitutional Generates X12 message with single institutional claim from X12 clipboard structure

Class: PegaHC-X12-Data-N278 X12ParseMessage Parses and maps the 278 message into X12 segments and

properties on an X12 page on the clipboard by invoking Parse-Delimited-Rules. Each Parse-Delimited-Rule handles the parsing of the data elements in a segment. It creates an instance of the PegaHC-X12-Data-N278 data object and calls the following activities: ■ CreatePegaHCData to map data to PegaHC

Authorization Request and create Authorization Response.

■ X12GenerateResponse to assemble 278 Response into X12 format.

■ X12WriteMessage to write X12 message to file. CreatePegaHCData Calls MoveDataToResponse to set up the 278 Response with

initial segments. It then loops through the transactions in the X12 page and calls ProcessTransaction for each transaction that handles the main processing.

MapToResponse Maps data from AuthorizationRequest work object to the 278 Response page after the work object has been processed.

MoveDataToResponse Creates the 278 Response page and sets it up with the ISA and GS segments.

ProcessAuthorization A stub activity that can be overridden by an activity in an application to process the Authorization Data object as needed. A ProcessAuthorization activity defined in the PegaHCAUTH RuleSet processes the Authorization Data object for the application. It creates an AuthorizationRequest work object that executes the flow defined for it. When the flow completes, it calls MapToResponse to update the 278 Response with the results of processing the AuthorizationRequest.


Rule Name Function

X12GenerateResponse Assembles the data on the 278 Response page into an X12 formatted message.

Class: PegaHC-X12-Data-N278-Transaction ParseRequestTestData Launches the parsing of the test file

ProcessTransaction Maps the Transaction X12 segments and properties to the Authorization Data object. Calls PegaHC-X12-Data-N278-Transaction-MoveDataToResponse to move transaction segments to 278 Response page. Calls PegaHC-X12-Data-N278-Loop2000EServiceProviderLevel-MapToAuthorization to handle mapping of ServiceProvider data.

MoveDataToResponse Moves appropriate transaction segments to 278 Response page.

Class: PegaHC-X12-Data-N278-Loop2000EServiceProviderLevel MapToAuthorization Maps the Service Provider X12 segments and properties to the

Authorization Data object. Calls MoveDataToResponse to move Service Provider data to 278 Response page. Calls PegaHC-X12-Data-N278-Loop2000FServiceLevel-MapToAuthorization to handle mapping of Service line data.

MoveDataToResponse Moves appropriate Service Provider segments to 278 Response page.

Class: PegaHC-X12-Data-N278-Loop2000FServiceProviderLevel MapToAuthorization Maps the Service Line X12 segments and properties to the

Authorization Data object. Calls MoveDataToResponse to move Service Line data to 278 Response page. Calls ProcessAuthorization in the N278 class to continue with processing the newly created PegaHC-Data-Authorization data object.

MoveDataToResponse Moves appropriate Service Line segments to 278 Response page.

Figure 4-9. X12 Activity Rules


The following chart shows the activities and the flow between them (Figure 4-10).

Class Activity

PegaHC-X12-Data X12ParseMessageStart

X12ParseMessageType

PegaHC-X12-Date-N278 X12ParseMessage

CreatePegaHCData

MoveDataToResponse

PegaHC-X12-Data-Transaction ProcessTransaction

MoveDataToResponse

PegaHC-X12-Data-Loop2000EServiceProviderLevel

MapToAuthorization

MoveDataToResponse

PegaHC-X12-Data-Loop2000FServiceLevel MapToAuthorization

MoveDataToResponse

PegaHC-X12-Data-N278 ProcessAuthorization

MapToResponse

X12GenerateResponse

X12WriteMessage

Figure 4-10. X12 Activities Working Together


X12 EDI Management

The Healthcare Industry Framework also contains preconfigured rules for managing the following two real-time X12 EDI messages:

• X12 270 / 271 – Healthcare Eligibility Request & Response

• X12 276 / 277 – Healthcare Claim Status Request & Response.

The sample implementations contain message intake and parsing rules, work object creation and mapping, sample business edits, and outbound response message generation. The framework also includes sample X12 files for 270 and 276 messages.

Healthcare Eligibility Request Message Processing The framework provides preconfigured rules to process real-time 270 Eligibility Request messages. The X12 parsing rules are configured as per the X12 270 / 271 Healthcare Eligibility Request & Response Implementation Guide.and as such supports batch as well as real-time message processing. The sample scenarios included in the framework reflect a real-time processing situation with immediate response generated after processing the message. To reflect a real-time situation, the messages are limited to one benefit request per member (subscriber or patient).

The key functionality includes:

• X12 270 Message Parsing – as per the 270/271 Implementation Guide

• Eligibility Request Work Object Creation – for every benefit request submitted in the transaction

• Validation of Information Source Level


o Check Limit Validation – sample business validation rule evaluates for the number of benefit requests in a single transaction. The validation fails if the number exceeds a pre-defined threshold for real-time processing (framework parameter is set at 25). If the validation fails, further processing of the message is skipped and an appropriate AAA Request Validation segment is included in this loop in the outbound 271 message.

AAA01 = Y AAA03 = 04 AAA04 = C

• Validation of Information Receiver Level

o Check for Provider on File – sample business validation rule that searches for the provider record based on the Information Receiver ID submitted on the 270. The validation fails if a matching provider record is not found in the sample database, If the validation fails, further processing of the message is skipped and an appropriate AAA Request Validation segment is included in this loop in the outbound 271 message.

AAA01 = Y AAA03 = 51 AAA04 = C


• Validation of Subscriber Level

o Check for Subscriber on File – sample business validation rule that searches for the subscriber record based on the Subscriber ID submitted on the 270. The validation fails if a matching subscriber record is not found in the sample database, If the validation fails, further processing of the message is skipped and an appropriate AAA Request Validation segment is included in this loop in the outbound 271 message.

AAA01 = Y AAA03 = 75 AAA04 = C

• Eligibility Benefit Request Processing

o Check for Active Policy – If the validation fails, an appropriate EB segment is returned in the 271 message

• EB*6**30~

EB01 = 6 (Inactive) EB03 = 30 (Health Benefit Plan Coverage)

o Check Eligibility On Service Date – The validation fails if the requested service date is outside the effective period on the active policy. If the validation fails, an appropriate EB segment is returned in the 271 message

• EB*I**30~

EB01 = I (Non Covered) EB03 = 30 (Health Benefit Plan Coverage)


o Process Generic Eligibility Request - If a specific EQ segment is NOT submitted on the 270, a minimum eligibility information response is returned in the corresponding EB segment on the 271 response message.

EB01 = 1 (Active)

EB02 = Policy.BenefitCoverageLevelCode

EB03 = 30 (Health Benefit Plan Coverage)

EB05 = Policy.PlanCoverageDescription

Example: EB*1*FAM*30* HMO1: $10 OV, $25 ER, $250 IP Copay, $5/$10/$15 Rx~ (when the policy is P-001)

o Process Specific Benefit Request - If a specific EQ segment IS submitted on the 270 and a matching service type code is available in the retrieved plan benefit, the system returns as much detail as is available in the corresponding EB segment on the 271 response message.

EB01 = 1 (Active)

EB02 = Policy.BenefitCoverageLevelCode

EB03 = value of ServiceTypeCode in incoming EQ01

EB05 = Policy.PlanCoverageDescription

EB06 = map value from TimePeriodQualifier from the matching benefit string

EB07 = map value from BenefitAmount from the matching benefit string


EB08 = map value from BenefitPercent from the matching benefit string

EB09 = map value from QuantityQualifier from the matching benefit string

EB10 = map value from BenefitQuantity from the matching benefit string

EB11 = map value from CertificationConditionIndicator from the matching benefit string

EB12 = map value from InPlanNetworkIndicator from the matching benefit string

• X12 271 Message Generation - as per the 270/271 Implementation Guide

Figure 4-11 Menu Options for Processing Sample Eligibility Request Messages


Figure 4-12 Eligibility Request Message Processing Summary

Figure 4-13 Eligibility Request Work Object


Figure 4-14 270 – 271 Message Side-By-Side Comparison

Key Rules in X12 270-271 Message Processing


Class: PegaHC-EDI-Work-EligibilityRequest

ProcessX12N270 Activity Main activity to launch 270 message processing

Process270Transaction Collection Main collection rule for processing 270 message

ParseTransaction Collection Parses 270 message and prepares 271 response

ValidateTransaction Collection Controls validation rules for various loops

ValidateInformation Source

Collection Controls validation of Information Source level

ValidateInformation Receiver

Collection Controls validation of Information Receiver level

ValidateSubscriber Collection Controls validation of Subscriber level

ProcessEligibility Request

Collection Controls mapping to work object and processing of benefit request

SendResponse Collection Controls 277 message generation and distribution

ParseMessage Activity Parses 270 message

PrepareResponse Activity Prepares 271 message shell



CheckLimit Activity Validates the number of requests in a transaction

CheckProviderOnFile Activity Looks up Provider based on ID submitted on 270

CheckSubscriberOnFile Activity Looks up Subscriber based on ID submitted on 270

MapMessageToWork item

Activity Maps 270 message to work object

ProcessEligibility Activity Initiates specific benefit request processing

Generate271 Activity Generates 271 message

SendMessage Activity Place holder for 271 message distribution

ReviewX12 Activity Provides side by side comparison of 270 - 271

Healthcare Claim Status Request Message Processing The framework provides preconfigured rules to process real-time 276 Claim Status Request messages. The X12 parsing rules are configured as per the X12 276 / 277 Healthcare Claim Status Request & Response Implementation Guide.and as such supports batch as well as real-time message processing. The sample scenarios included in the framework reflect a real-time processing situation with immediate response generated after processing the message. To reflect a real-time situation, the messages are limited to one claim status request per member (subscriber or patient).

As per the X12 276/277 Implementation Guide specification, there is no validation performed at the various levels of the message loops.

The key functionality includes:

• X12 276 Message Parsing – as per the 276/277 Implementation Guide


• Claim Status Request Work Object Creation – for every claim submitted in the transaction

• Claim Retrieval – sample business rules to retrieve claim from the sample database based on the Claim Identifiers submitted on the 276 message. If a matching claim is not found, an appropriate STC segment is returned on the outbound 277 message. If a matching claim is found, system returns the claim status information in the STC segment of the 277 message.

• X12 277 Message Generation - as per the 2760/277 Implementation Guide

Figure 4-15 Menu Options for Processing Sample Claim Status Request Messages

Figure 4-16 Claim Status Request Message Processing Summary


Figure 4-17 Claim Status Request Work Object

Figure 4-18 276 – 277 Message Side-By-Side Comparison

Key Rules in X12 276-277 Message Processing


Class: PegaHC-EDI-Work-ClaimStatusRequest

ProcessX12N276 Activity Main activity to launch processing of 276 message



Process276Transaction Collection Main rule for processing 276 message

ParseTransaction Collection Parse message & prepare 277 response

ProcessClaimStatus Request

Collection Maps message to work object and processes claim lookup

SendResponse Collection Generates 277 and sends message

ParseMessage Activity Parses 276 message

PrepareResponse Activity Prepares 277 message shell

MapMessageToWork Item

Activity Maps 276 message to work object

SendMessage Activity Place holder to configure 277 message

ReviewX12 Activity Provides side by side comparison of 276 and 277

Figure 4-19 Key Rules for Claim Status Request Message Processing

Chapter 5 The New Member Enrollment Solution

The New Member Enrollment Solution is a sample design model included in the Healthcare Industry Framework. This solution comes with examples of new member application submission and enrollment processing that leverage key rules and features of the Framework and its underlying platform (PegaRULES Process Commander). The New Member Enrollment Solution is also designed for extension. It can be rapidly integrated into a client’s existing infrastructure, personalized to reflect a client’s specific policies, and expanded to create a comprehensive enrollment management system.

This solution can be deployed by itself or integrated with existing sales and group enrollment systems, such as Pegasystems Sales Process Manager, to facilitate desired automation in the sales and enrollment processes.


New Member Enrollment High Level Workflow Figure 5-1 shows the Application Process Flow used by the solution to manage the three major steps in the enrollment process:

1. Intake Process that creates the enrollment application work item

2. Common Process that manages the steps to complete the enrollment application

3. Output Process that manages the processes that occur when the enrollment application work item is resolved.

These processes are described in detail below.

Figure 5-1. Overall Member Enrollment Application Process

Extension Tip: The Framework provides examples of new membership additions for new and existing group business. It can easily be extended to support membership changes for all types of business and new membership additions for individual business.

The New Member Enrollment Solution 5-3

Intake Process

Initiating the Enrollment Application Process Enrollment applications can be originated by multiple users such as brokers, members, Plan Sponsors, and internal health plan representatives and submitted through multiple intake channels (such as web, fax, email, and phone). The Intake Process Flow (Figure 5-2) determines the source through which an application is originated and applies specific routing or processing rules based on that source and the level of application completion. The Framework routes completed applications received electronically to a general workbasket for underwriting approval and routes applications received via the Manual Input method directly to specific enrollment representatives using skills-based routing rules. Three sample intake methods (Manual Input, PDF Intake, and External Message Intake) are described below.


Figure 5-2. Application Intake Processes

Extension Tip: Routing logic can be personalized for unique business criteria. Approval rules can be used to assess application completion, including adherence to eligibility requirements, thereby moving acceptable applications through to the output process. Use of approval rules can eliminate the review step and fully automate the procedure. Additional intake methods can easily be added to the solution. When received by the Framework, member enrollment applications can be scanned as images to initiate enrollment work items. The image ID number can be saved on the enrollment work item, or the image can be saved as an attachment and viewed with the PegaIMAGE Viewer, making the information available for use in the completing applications.


Manual Input Intake Method In the Manual Input Intake method, users initiate the application process, manually entering the application data. This often occurs when an enrollment application is received on paper. Prospective members, Plan Sponsors, or partners such as brokers and consultants can also enter an application using the Framework’s web site. The Framework provides the example in which an enrollment support representative initiates the process by entering required group level information such as a group number, and the system creates an application work item based on the successful access to back-end legacy systems (Figure 5-3).

Figure 5-3. Find Employer Information

The system drives the application completion process. Its first step is to confirm and bring back relevant employer group information. The system performs a look up of relevant internal and external data sources to verify the employer group number entered on the application. Typically the data source is a legacy membership system that maintains the most current group level data. Upon confirming the group, the system retrieves relevant group information such as plan availability and eligibility requirements that drive the ensuing enrollment process and screen selections. The look up and status update are handled with the Find Group Flow (Figure 5-4).


Figure 5-4. Find Employer Group Process


PDF Intake Method In the PDF Intake method, the New Member Enrollment Solution reads and maps data elements from an electronically submitted PDF and automatically populates these data elements into the member enrollment application work item it created. The system uses a PDF parse rule and creates a work item containing these data elements.

Extension Tip: For electronically submitted applications, business policy may require that the application be printed and returned to the prospect for a signature. In this case, the PDF input functions can easily be extended to create PDF output inclusive of any data added by the processor.

External Message Intake Method The New Member Enrollment Solution is designed to facilitate the straight through process by working with external systems commonly used in the sales and group enrollment process. In such instances, the solution locates external messages containing employee census information and from them creates member enrollment work items. It then populates the work items with properties it maps from the external message through the use of parse rules. Figure 5-5 shows an example of an XML Parse Rule.

Note: The New Member Enrollment Solution integrates seamlessly with the Pegasystems Sales Process Manager Framework (SPM). SPM manages the sales and group enrollment processes for Healthcare s.


Figure 5-5. Parse Rule

Extension Tip: The XML parse rule can also be used to personalize other integration methods such as MQ Series or SOAP that are easily deployed through Pegasystems pre-built services. The Framework’s folder capabilities can be used to track completed member applications against the total census if such capability is not present in the external systems.


Key Rules for the Intake Processing Figure 5-6 shows the key rules that are used in the three intake processes.


Intake Process:

IsNewHire When True, if Is New Hire

IsApplicationFromPDF When True, if is Application From PDF

IsApplicationFromImage When True, if is Application is from Image

IsApplicationFromMessage When True, if is Application is from Message

Common Process

IsNewBusiness When True, if is New Business

EnrollmentUnit Ticket Used to route back to enrollment unit

UpdateWorkSLA Activity Processes the work item SLA

New Hire Process

FindEmployer Connector Used to connect to an external data source to verify employer level data based on a group ID

PDF Intake Process

NMEPFDIntake File Listener

Used to read in a file from a designated directory

NMEEnrollmentFormTest eForm Map Used to map PDF form contents to clipboard properties

ParsePDF Parse Structured

Process to call the PDF utilities and create the application work item

External Message Intake Process

NMEEmailIntake E-Mail Listener

Used to read in a file from a designated directory



EnrollmentApplication XML Parse Used to parse XML data to clipboard properties

ParseEmail Service EMail

Creates the work item and reads the e-mail message to the clipboard

Figure 5-6. Key Rules for Intake Processing


Initial Member Enrollment Application Assignment The solution provides examples of different assignment options including assignments to workbaskets and to individuals. The routing rule used in the PDF Intake method, routes the application work item to a general workbasket (Figure 5-7). The work item is accessible to any operator who has access to the workbasket.

Figure 5-7. Route PDF to General Workbasket


The routing rule used in the External Message Intake method, routes the application work item to the specific individual — the Plan Sponsor who is identified in the XML message that initiates the process (Figure 5-8). The work item then appears in the Plan Sponsor’s work list.

Figure 5-8. Route to Plan Sponsor indicated in the XML message

Extension Tip: Directed Web Access can be used to send a work item assignment to external users. An email is sent with a secure link directly into the case to allow external input and processing.


Figure 5-9 describes the key assignment rules applied to work items created from the PDF and External Message Intake methods.


PDF Intake Routing:

ToWorkBasket Router Routes the application work item to specified work basket

External Message Intake Routing

PrepareExternal Activity Notifies Plan Sponsor about the creation of a new application work item

ToAssignedOperator Router Routes the application work item to specified operator indicated in the XML message

Figure 5-9. Key Assignment Rules

Common Process Workflow When straight through processing cannot be achieved, the solution manages the completion of applications and any subsequent review or approvals through the Common Process Flow (Figure 5-10).


Figure 5-10. Application Common Processes


Application Data Entry Workflow For applications requiring manual data entry, the process is managed by he Application Flow (Figure 5-11) — the first step of the Common Process. This flow intelligently manages the screens users see for data entry based on the information as it is submitted. In the solution example, data entry may be accomplished through as little as two screens for a single healthy individual without other insurance and enrolling in a plan that does not require a PCP. Or, the process can require as many as nine screens depending on the subscriber demographics and medical history.

The system pre-populates data whenever possible based on the intake method and information originally supplied. The system employs security rules to determine which portions of the member enrollment application and what data to display to users. User roles define which users have rights to previously entered information. Security and user role rules are personalized for each client installation.


Figure 5-11. Application Data Entry Screen Flow


Figure 5-12 shows the browser-based user interface that users see when entering data through the browser. Fields with asterisks are required to drive the work through to completion. The system uses intent-led processing to guide users efficiently through the application process. For example, only if users select coverage for a spouse or children will the additional screens pertaining to spouse or children appear.

Figure 5-12. Application Data Entry Screen

Extension Tip: The New Member Enrollment Solution provides product selection at the member level and can easily be extended to support consumer driven healthcare by supporting benefit selection at the rider level. Data properties are easily added, changed, or classified and can be standardized for specific sales types (individual, small group, large group, Medicare), geographic regions, employer groups, and so on.


Medical History The New Member Enrollment Solution comes with a series of medical questions that are asked for each member identified on the member application. The response to these questions drives the need for further detailed questions that the system uses to evaluate member risk factors and determine an underwriting recommendation at the applicant level.

Figure 5-13 shows the initial medical history screen. Figure 5-14 displays only if users have a positive response to a question asked on the first screen.

Figure 5-13. Medical History Questionnaire Step 1

Figure 5-14. Medical History Questionnaire Step 2


Medical Underwriting Risk Evaluation and Recommendation The New Member Enrollment Solution calculates a risk factor for each individual on the enrollment application based on the responses to the medical questions above. An applicant underwriting recommendation is then determined based on the risk factor for each member on the application using a decision tree that evaluates the applicant risk factor and returns the underwriting recommendation.

The Underwriter Recommendation Flow manages the process of risk evaluation and the underwriting recommendation (Figure 5-15).


Figure 5-15. Determining Risk and Underwriting Recommendation


The Decision Table Rule (UWRecommendation, Figure 5-16) is used to determine a member’s risk factor based the following questions:

During the past 10 years has any proposed insured had any indication of, diagnosis of, or treatment for:

The heart or circulatory system, including high blood pressure, high cholesterol, heart attack or murmur, heart valve disease, chest pain, or irregular heart beat?

− Was the onset of high blood pressure prior to age 25? − Is the condition controlled?

Figure 5-16. Underwriting Risk Factor Decision Table

Figure 5-17 shows the underwriting recommendation decision tree.

Figure 5-17. Underwriting Recommendation Decision Tree


Underwriting Risk Evaluation and Recommendation Rule Changes The medical underwriting risk calculation and recommendation example in the New Member Enrollment Solution can be extended to include any number of questions and any combinations of responses. The calculation for the overall risk factor for the applicant can also be adjusted, and the decision tree that determines the final recommendation can be expanded to include other variables and additional recommendations. An example of a method to make such a change is outlined below.

Business rules in the underwriting department change frequently based on regulatory environment changes and in reaction to the evaluation of historical data. In this example, an underwriting department has determined that it would like to include the use of tobacco when calculating the risk factor for a member that has a heart condition.

Figure 5-18 shows the UWRecommendation Decision Table that can easily be modified by authorized users to include yes values in the tobacco use column and add the necessary rows to include all potential combinations of the medical questions used to determine a member’s risk factor. This type of change can be performed by business users including underwriters themselves and can be applied selectively for different business units or employer groups.

Figure 5-18. UW Risk Factor Decision Table — After the Change


The Run Rule facility located at the top of the rule can be used to test the results of a rule change. Figure 5-19 shows this testing capability.

Figure 5-19. Testing Rule Changes


Figure 5-20 describes key rules related to the underwriting recommendation included in the Framework.


UWRecommendation Flow Manages the overall process of risk evaluation and the underwriting recommendation

UWRecommendation (member) Flow Manages the process of getting the risk factor for each member

GetUnderwriterRecommendationFactors

Activity Produces the application risk factor based on all the individual member risk factors

DetermineUWRecommendation Decision Tree

Determines the UW Recommended action based on the risk factors such as Approve or Deny

Figure 5-20. Key Rules for Risk Evaluation

New Member Enrollment Application Routing and Review When data entry is complete, the enrollment application is assigned to specific users who can then review, modify, and submit the application for further processing. The solution provides different examples of how and where work items can be routed as outlined in Figure 5-21.

Completed By Routed To Flow Rule Used

Plan Sponsor Sales (Department) Sales Review

Enrollment Support Rep Enrollment Rep (Individual) Route to Enrollment

Enrollment Rep Underwriter (Individual) Route to Underwriting

Figure 5-21. Routing and Review


The example for the External Message Intake example process provided in the Framework involves submission and completion of an application by an external party such as a Plan Sponsor or Member. In this example, the application work item is routed to the sales work group for review using the SalesUnit flow rule.

When sales users review the member application, the actions these users can take are managed by the flow actions shown in Figure 5-22.

Figure 5-22. Routing to Work Group

The browser interface for the sales users is shown in Figure 5-23. Tabs are used to navigate and store all information collected in the work item, separated in to logical groups such as subscriber, spouse, children, other insurance, and medical history. When users select a tab, the system displays the collected information.


Figure 5-23. Browser Interface for Sales Users

The history of what has happened to the work item, known as the audit trail, is also accessible to users reviewing and processing the enrollment work item. The audit trail shows which operators have worked on the work item, what actions were performed, and when the action was performed. The audit trail also logs when and what automatic processes were performed by the application (Figure 5-24). Work item history instances are stored as objects in classes derived from the History-Work- class.


Figure 5-24. Work Item History

Route to an Individual The Manual and PDF Intake examples provided in the solution involve completion of an application by an internal party. In these examples, the Framework routes the application to the appropriate enrollment representative for review using the skill-based routing rule shown below in Figure 5-25.


Figure 5-25. Route To Enrollment Representative Based on Skill Level

The Operator ID records contains the skills and the skill rating used by the To Skilled Operator Routing Rule (Figure 5-26).

Figure 5-26. Operator Record with Specific Skills


Key Rules for Routing to Individuals Figure 5-27 describes key rules related to routing to individuals provided in the New Member Enrollment solution:


RouteToEnrollment Flow Determine Enrollment Representative Skill level to be used in the ToSkilledOperator routing rule below

DetermineRequiredSkill Decision Tree

Determines the skill required to complete the application

ToSkilledOperator Router Finds the operator with the best skill as defined by the decision tree above and routes the application

Figure 5-27. Key Rules for Routing to Individuals

Routing Rule Change If Enrollment Department Management wants to identify late enrollment applications and process them differently, they can easily change the Enrollment Routing Rule that all applications requesting effective dates in the past are routed to the Enrollment Managers workbasket for exception processing.

The sample routing decision tree provided in the Framework uses the skill level of the Enrollment Representative, the primary language experience, and the requested effective date on the member application to route the application work item (Figure 5-28).


Figure 5-28. Solution Sample Decision Tree Determines Required for Routing

To handle exception processing as outlined above, the Enrollment Manager can easily change the rules shown in Figure 5-29.

Figure 5-29. Solution Sample Decision Tree — Updated — To Route to Enrollment Manager

Note: The routing process can also be managed by modifying the skill settings at the operator level.

Route to Underwriting When enrollment representatives complete their portion of the enrollment application they submit the application to underwriting for review. The underwriter reviews medical history and eligibility qualifications as provided in the application. The application is routed to an underwriting representative for approval or denial based on the completion of medical history by using the rules below (Figure 5-30).


Figure 5-30. Route to Underwriting


Figure 5-31 shows a flow rule that defines the actions an underwriter user can take, such as approve, reject, or update the application.

Figure 5-31. Underwriting Unit Review and Actions


Key Rules for Application Routing and Review Figure 5-32 lists the key rules provided to route and review member application work items.


Plan Sponsor to Sales

ToWorkGroup Router Routes the application to the specified work group

Enrollment Support Rep to Enrollment Rep

DetermineRequiredSkill Decision Tree

Determines the skill required to complete the application

ToSkilledOperator Router Finds the operator with the best skill as defined by the decision tree above and routes the application

Enrollment Rep to Underwriting Rep

DetermineUnderwriter Decision Table

Determines the individual underwriter to whom the application is routed

ToAssignedOperator Router Routes the application to the underwriter as determined by the decision table above

Figure 5-32. Key Rules for Application Routing and Review


Output Process When the application work item is finalized, either through straight through processing or manually by a user, its status is moved to Resolved-Approved. When this occurs, the system automatically sends correspondence to relevant parties and updates external data sources with requisite application information. These steps are managed in the Output Process Flow (Figure 5-33).

Figure 5-33. Output Process — Sends Correspondence and Update External Data Sources

Extension Tip: Any number of work parties can be notified automatically using multiple methods including e-mail or letter at any time in any flow as shown in the Output Process Flow example above. Updates to external data sources can also be extended to include any number of required interfaces with external data sources.


Key Rules for Output Process Figure 5-34 describes key rules related to the output process.


UpdateSPM Connector Communicates member enrollment data to a group enrollment system such as SPM

ProcessOutput Connector Communicates member enrollment data to external data sources such as legacy systems

SendCorrespondence Activity Sends a welcome letter to the new subscriber with the application is approved by underwriting

Figure 5-34. Key Rules for Output Process


Service Level Rules Service level rules let you measure and manage quality and also keep processes moving forward. The system measures quality by measuring and reporting performance related to goals and deadlines set for a work item or an assignment of a work item. The system manages quality and moves processes towards resolution through the notification and escalation of work based on reaching or exceeding goals and deadlines.

The member enrollment process may have multiple steps and assignments to complete before the work is resolved. Through the use of SLAs, the system promotes straight through processing, speeds work to completion, draws attention to the process through escalation of aging work and notification to assignees or managers when work is nearing defined goals and deadlines.

Each service level rule defines one or two time intervals, known as goals and deadlines, which indicate the expected or targeted turnaround time for each assignment, or time-to-resolve for the overall work object.

■ For assignments, the service level rule is referenced in the Assignment Properties of the assignment task.

■ For the overall work object, the service level rule is identified in the standard property.

The SLAs that come with the prepackaged in the New Member Enrollment Solution are described in the table below (Figure 5-35).


Service Level for

Service Level Name

Goal Time

Goal Escalation

Deadline Time

Deadline Escalation

Plan Sponsor Application 1 day Notify Assignee 3 days Transfer to Manager

Enrollment Support Application 1 day Notify Assignee 3 days Transfer to Manager

Enrollment Rep Enrollment 2 days Notify Assignee 4 days Transfer to Manager

Enrollment Workbasket PDFApplication 1 day Notify Manager 3 days Transfer to Manager

Underwriting Underwriting 1 day Notify Assignee 2 days Transfer to Manager

Work Object Overall 4 days N/A* 9 days N/A*

Work Object Application** 1 day Notify Assignee 3 days Transfer to Manager Figure 5-35. New Member Enrollment Solution SLAs

* Work Object SLAs are used to track overall application performance for reporting purposes. ** Used as work object SLA during initial data entry

The Underwriting Service Level Agreement rule (Figure 5-36) lets managers in charge of timelines for the work item assignments maintain the SLAs. In this example, the underwriter receives an e-mail notification when the goal time is reached.


Figure 5-36. Underwriting Assignment Service Level Agreement


Correspondence Rules Figure 5-37 shows the sample correspondence rules in the PegaHCNME-Work-Enrollment-EnrollmentApp class used to produce e-mails and letters during the enrollment process.

Name Type Purpose


EnrollmentRequest Email Used to notify a Plan Sponsor when an enrollment application has been created and assigned to the Plan Sponsor

NewEnrollmentApplication Email Used to notify an internal user when an enrollment application has been created and assigned to them

WelcomeLetter Mail Sent to a new subscriber when underwriting has approved the new member application

Fragment Rules

NMEWorkDetail Fragment Body of the e-mail sent to the plan sponsor

NMEWorkLink Fragment Included in the body of the NMEWorkDetail fragment

Figure 5-37. New Member Enrollment Correspondence Rules


The correspondence template for sending a welcome letter creates the letter shown in Figure 5-38:

Figure 5-38. Welcome Letter

Extension Tip: In production, sample correspondence templates should be replaced with client-specific materials. Correspondence templates and fragments and their reusability are described in Chapter 3.


Declarative Rule Examples The New Member Enrollment Solution layer includes examples of various declarative validation rules for intent-driven workflows, routing, and reporting. The Solution’s sample declarative rules provide a way to set or restrict property values, dynamically retrieve necessary data, and automate the decision of when to perform a process. The skills-based routing rules shown previously in Figure 5-25 and Figure 5-26 are examples of the declarative network packaged in the New Member Enrollment layer.

Key Rules for the Declarative Process The Rule-Declare-Expression rule shown in (Figure 5-39) facilitates reporting on the Requested Effective Date property. It uses an exposed property in the standard Process Commander work database table and maps the requested effective date on the application to it.

Figure 5-39. Rule-Declare-Expression to Map Requested Effective Date


Figure 5-40 shows the Change Tracking tab of the rule above. Whenever the input changes — in this case the requested effective date — the property pyWorkListDate1 is updated.

Figure 5-40. Selecting the Event to Track

The Rule-Declare-Expression rule shown in Figure 5-41 calculates the age of the subscriber based on two parameters: the requested effective date and the subscriber’s date of birth. This rule uses a Rule-Utility-Function rule to compute and store the age in a separate property called Age. Whenever a property used by this function is changed, the age is recalculated.

Figure 5-41. Calculating Age of Subscriber


Figure 5-42 shows some of the key declarative rules used in the New Member Enrollment Solution layer.


DetermineRequiredSkill Decision Tree Produces skill required to complete the task

.pyWorkListDate1 Expression Maps requested effective date

.pyWorkListText1 Expression Maps subscriber name

.pyWorkListText2 Expression Maps subscriber SSN

.pyWorkListText3 Expression Determines if group is enrolled or new business

.pyCustomerName Expression Maps group name

DetermineUWRecommendation Decision Tree Produces underwriting recommendation based on overall risk factor

DetermineUnderwriter Decision Table Produces underwriter to route to based on medical history

Figure 5-42. Key Declarative Rules


Reporting The New Member Enrollment Solution includes four sample enrollment reports, all of which are available from the sample Manager’s dashboard. All reports in this solution can be exported to Excel as well as customized and saved to a user’s favorites list using the customize criteria link located at the top left of the report.

New Business Pipeline This report shows all unresolved new business member enrollment applications by status (Figure 5-43).

Figure 5-43. New Business Pipeline by Status


New Business Performance This report shows total time for completion of all resolved new business member enrollment applications (Figure 5-44).

Figure 5-44. New Business Performance

New Hire Pipeline This report shows all unresolved new hire member enrollment applications by status (Figure 5-45).

Figure 5-45. New Hire Pipeline by Status


New Hire Performance The report shows completion time for all resolved new hire member enrollment applications for existing group business (Figure 5-46).

Figure 5-46. New Hire Performance

Drill-Down Details Users can drilldown on any of the reports to view a list of the enrollment applications included. Further drill-down is possible by clicking on and opening each individual work item (Figure 5-47).

Figure 5-47. Drill-Down Information

Extension Tip: The New Member Enrollment Solution layer comes with a reporting wizard that can be used to create custom reports. Once created, these reports can be saved as favorites for access by an individual manager or for an entire access group. Figure 5-48 shows the report wizard.


Figure 5-48. Report Wizard


Additional Extension Ideas The New Member Enrollment Solution layer has been designed and built to be flexible, easy to change, and to provide core enrollment capabilities that can serve as the back-bone for extension into multiple functions related to member enrollment. A few examples of extension areas are described below.

Member Access to Enrollment Application The solution provides examples of how a Plan Sponsor logs into the system with an ID and password and enters member enrollment data. Through the use of Directed Web Access, the solution can be extended to include access to subscribers, members, and prospects to complete their own enrollment applications and member maintenance requests. Directed Web Access is especially useful for prospects who do not yet have passwords to use on an existing web site. When individuals complete their own application, the work item can be automatically routed to the Plan Sponsor for approval and submission to Sales.

Member Maintenance Member maintenance activities, such as additions and deletions to family members on a contract, account for a large percentage of the work completed by an enrollment department of a Healthcare . The sample solution workflows can be copied and then modified to create member maintenance request workflows and work items that process requests to add/delete family members, change plan choices, update demographic information, and request new PCPs. Declarative rules determining the member maintenance request type can drive the relevant information assembly for both internal and external users.


Consumer Driven Healthcare In the solution’s enrolment examples, users make selections at the product level: one for both Medical and Dental insurance. The solution can easily be expanded to include additional products such as life or vision insurance. By expanding the product tables to include rider- and benefit -based selections, the solution can be used effectively to support consumer driven healthcare initiatives.

Medical Underwriting

The solution includes examples of how responses to medical questions can be used to support the calculation of risk factors and the creation of a recommended action for an underwriter to take when reviewing a new application. The solution can accommodate a variety of medical underwriting by expanding the medical questions, expanding the requested additional information for positive responses, and extending the business rules related to the risk and recommendation.

The New Member Enrollment Solution can also be extended to handle and manage additional requests for information from the medical information bureau, requests for lab work or tests and requests for physician statements. These types of requests require the creation of child work items that are associated with the parent member enrollment work item.

Integration with Group Sales Process Management If a Healthcare has a group sales and enrollment system in place to manage prospecting, quoting, group sales and group enrolment, the solution can be extended to receive and send enrollment data to the group enrollment system to support the group finalization and acceptance process.


Individual Rating The New Member Enrollment Solution collects subscriber and dependent data used by the Healthcare Industry Framework in the creation of premium rates. The rating tables and the rating expressions can be built within the solution – as they have been for Pegasystems Sales Process Manager – which in turn can be used to create rates for individual applicants in real time as they complete their application forms.

Member Eligibility Management Many rules related to member enrollment can be supported in the solution itself or can be retrieved by the system as rules from other data sources during the enrollment process to achieve greater automation. Examples of these types of rules are:

■ Probationary periods related to dates of hire

■ Dependent eligibility

■ Other insurance and coordination of benefits

Extend Member Enrollment for Management During the enrollment process, additional forms or information such as student certification or incapacitated dependent forms may need to accompany the member enrollment application. The solution can easily be extended to either maintain or leverage these forms.

Chapter 6 The Appeals and Grievances Solution

The Appeals and Grievance Management Solution is a sample workflow that leverages key rules and features of the Framework and the underlying platform. This solution manages complaints received from members and other interested parties (authorized representatives, providers, and third parties such as independent review entities). It provides the capability to create new cases (work objects) for two different types of complaints (appeals and grievances), and processes them through to resolution. In addition, resolved appeals can be reopened and reprocessed as necessary.

The following sections describe this solution’s key features:

Grievance Management Workflows — Start-to-end process for managing member grievances. This process includes the creation of a grievance case, capturing required information including information about the requestor party and the grievance reason, assigning standard or expedited urgency status, and applying appropriate service levels to ensure timely processing.


Appeals Management Workflows — Start-to-end process for managing appeals filed for denial of service or claim payment. Capabilities include the creation of an appeal case, capturing required information including information about the requestor party, appeal level, appeal category, service and or claim information, assigning an owner and standard or expedited urgency status, and applying appropriate service levels to ensure timely processing.

Directed Web Access for External Users — A secure one-time link to the system sent to the provider who is the subject of a grievance to seek feedback on the issue when the grievance is related to providers or providers office staff (such as appointments, staff behavior, and prolonged wait times.). Once the provider submits the required information, the process automatically resumes and is routed to the owner of the case for review.

Service Levels, Routing, Prioritization, and Escalation — Tracking of each complaint case with priority assigned based on urgency status, type and level of complaint, and type of denial. Service level rules monitor goal and deadline times based on predefined standard parameters (14 days or 30 days). When the case reaches goal times, additional priority points escalate the case relative to other cases in the queue. Routing capabilities include requesting input from supporting departments such as provider network services or utilization and claims management.

Correspondence Generation — Preconfigured letter templates for communicating with the involved parties at various stages of the complaint process. Standard templates for acknowledging a complaint, requesting additional information, and communicating final disposition can be quickly and easily customized to meet your specific needs. The letter templates are complied dynamically and include re-usable correspondence fragment rules for common sections such as headers, footers, style sheets, and logos. You have the flexibility to generate correspondence automatically in the background or to allow / require editing as well as verification before it is finalized.

The Appeals and Grievances Solution 6-3

Quality Improvement Audit — Preconfigured auditing of complaints based on frequency for a specific provider. The process creates a quality review case that is forwarded to the Quality Improvement Department for further review.

Legacy System Information — Retrieval and display of commonly referenced legacy system information such as member’s eligibility as well as processing feedback comments from all involved parties (member research and provider network departments).

Reporting — Preconfigured productivity reporting to track process assignments, activity, quality, and performance. The reporting wizard allows managers to build custom reports necessary to manage the complaint resolution processes. Custom preconfigured reports include:

■ Aging Inventory By Complaint Type

■ Appeal Inventory By Denial Type

■ Resolved Grievances By Resolution Type

■ Resolved Appeals By Resolution Type

Connectors to External Systems — Leverage of the comprehensive integration capabilities of Process Commander. The complaint management process enables retrieval and display of pertinent information from the Health Plan’s existing legacy systems, making it readily available for users during the process of resolving the complaint. The member’s eligibility information and the original authorization or claim information are automatically retrieved and made available as part of the case history. This availability avoids the need to toggle back to legacy systems for lookup and research of the information required to efficiently resolve the complaint.

The Appeals and Grievance Management Solution provides the foundation for Health Plans to build for change. It comes with a working configuration that you can extend to create your own solution. The remaining part of this chapter provides some suggestions as to where you might extend the Appeals and Grievances Solution.


The Final Disposition Process for Appeals The Appeals and Grievance Manager layer comes with a standard disposition process for an appeal where the original denial on the claim or the authorization can be flagged as “Upheld” or “Overturned.” The workflow then proceeds to allow users to select the appropriate correspondence to communicate the final disposition (approval or denial of the appeal).

When the decision on the original claim or authorization transaction is overturned (meaning approving the claim payment or the requested service), you may want to extend the process to either generate a new claim or authorization transaction that reflects the change and route it to the appropriate department (claims or utilization management) for follow-up. Alternatively, the original transaction can be updated in the host legacy system.

Figure 6-1 shows where you might extend the flow rule to add the new processes either in the same flow or spawning a new flow.


Figure 6-1. Resolve Complaint Flow


Extending the Final Disposition Notification Process When users select the final disposition to the complaint, the system displays a selection box of available correspondence templates for approval or denial of the grievance or appeal as warranted by the case disposition The Appeals and Grievance layer is setup with default correspondence templates for approving or denying a grievance or appeal:

■ GrievanceApproval

■ GrievanceDenial

■ AppealApproval

■ AppealDenial

These correspondence templates are set up to require user editing and supervisor verification before they can be sent to the requestor. These editing and verification requirement options can be modified to suit your business needs.

You may want to extend the list of available correspondence templates to choose for approving or denying a complaint. Specific templates can be created for specific types of grievances or appeals. Alternatively, you can present users with a specific version of the template automatically by using the Circumstance feature. This feature lets you display different versions of the default correspondence based on a specific property value (Figure 6-2).


Figure 6-2. Circumstance Feature in Correspondence


Workbasket Routing for Complaints The Appeals and Grievance Manager layer comes with a default Complaints workbasket to which all new grievances and appeals are originally routed.

When the complaint is routed for input from specific departments (Member Research, Provider Network Services, Utilization Management, or Claims), the work object is routed to default workbaskets created for each of these departments.

Users belonging to these departments have the default workbaskets assigned to their operator profile.

You can extend the routing process to include specific workbaskets for grievances and appeals or to include specific workbaskets for specific types of complaints. For example, you could have a workbasket for pre-service and claim denials by line of business. Based on your needs the extended workbasket structure can be mapped to specific users based on their skill sets.


Extending the Quality Audit Process The Appeals and Grievance Manager layer comes with a sample Quality Improvement audit check, enabling a quality review for providers who have more than ten grievances lodged against them within a 30-day period. This check is performed in the ResolveComplaint flow within an activity called ProviderQualityCheck, which creates a list of matching cases by Provider Identifier, for grievances which dealt with provider service. If there are more than ten matching cases, the flow calls a spinoff flow named ProviderQualityReview, which in turn generates an assignment to the Quality Review department to investigate and enter notes on the issue.

This serves as a placeholder for more complex Quality Improvement review processes. This could be used to do statistical sampling to check on a given percentage of new complaint processors’ cases, or to check on frequently complaining members. The current process generates an assignment on the current complaint and records notes about the investigation; this could also be expanded to provide a folder or list of existing cases, or to interface with your provider data repository to set warning flags.


The Appeal Re-Open Process The Appeals and Grievance Manager layer provides the ability to reopen appeals that were closed at Level 1 or 2. This is done through an activity called ReopenAppeal, which is tied to the Reopen button on the review screen. This is only permitted on appeals, and does not work for grievances. The activity checks that the appeal was closed recently enough to allow a reopen — this check is performed in a When rule named ResolvedRecently, and is set to 60 days. This record can be copied and modified to set your own timeframes for appeal reopening.

The activity additionally increments the appeal level, and calls the ReopenAppeal flow, which allows the operator to enter notes for Appeal level 2 or 3 as appropriate.

You might want to expand this activity into a more complex Appeal Reopen and Review process or use it to route reopened appeals to specific workbaskets for higher-level appeals. Currently, the reopening operator enters the new notes, and then the appeal goes through the same workflow as at level 1 for investigating claim/authorization data and setting a disposition. This could be replaced with a separate flow with additional routing logic for reopened cases. This could also be used to assure that operators who previously worked on an appeal do not rework the appeal at a higher level. Currently, the first complaint operator to pick up a case is set as the complaint owner until it is resolved. That process could be used to create a list of previous owners, and the GetWork process then modified to prohibit a prior owner from working a reopened appeal.


Appeals and Grievance Manager Reports Appeals and Grievance Manager reports are available from the Components Snapshot section of the Dashboard workspace. The reports gadget gives you links to each of the reports.

■ Aging Inventory by Complaint Type — shows all the open Appeals and Grievance cases, grouping them into “time aging” ranges of 5-day intervals

■ Appeal Inventory by Denial Type — shows all open Appeals, grouped by appeal level (1, 2, or 3) and then broken out by denial type (pre-service, concurrent service, or post-service)

■ Resolved Grievances by Type — shows all resolved Grievances, grouped by their status and requested urgency (for example, Resolved-GrievanceApproved:Standard)

■ Resolved Appeals by Type — shows all resolved Appeals, grouped by their appeal levels and request urgency (for example, Resolved-AppealApproved:Standard)

Chapter 7 Extending Your Framework

This chapter describing areas of the Framework you might want to extend and includes:

Standard setup requirements that describe what must be done with any new installation.

■ Setup requirements

■ Setting up calendars

■ Setting up correspondence

Extension ideas including areas of the Framework that you may want to extend:

■ Authorization Management Solution Layer (described in chapter 3

■ New Member Enrollment Solution Layer (described in chapter 5

■ Appeals and Grievance Manager Layer (described in chapter 6)

■ Self-Service Options for Authorization

■ Adding X12 Messages


Integration activities including places in the Framework that you may want to integrate with external systems to either push or pull data:

■ Common object data interface

■ Data interfaces for Member and Eligibility, Provider, Claim, and Authorization

■ Interfacing to PegaDISTRIBUTION Manager

Extending Your Framework 7-3

Setup Requirements Ensure you have set up the following before extending your framework:

■ Operators — Operator IDs define the type of users who work with the Framework and the application you build. The Healthcare Industry Framework comes with a set of predefined operator IDs that you can use to create your own.

■ Access Groups — Operators IDs specify an access group that determines options that portal users see, RuleSets they can access, classes of work that appear in their portal, default class group of rules that users work with, and access roles. The Healthcare Industry Framework comes with a set of predefined access groups that you can use to create your own.

■ Access Roles — An access role is defined as having certain class access rights. Users can have one or more access roles, which are listed in access groups. The Healthcare Industry Framework comes with a set of predefined access roles that you can use to create your own.

■ Privileges — A privilege allows users with a particular role to execute certain functions. Privileges are associated with access roles, not directly with users. If a user has the access role with which the privilege is associated, the user has the privilege. Privileges also play a role in routing work as users can only receive work items for which they have privileges.

Tip: Access-Role-Obj rules (of type Rule-Access-Role-Obj) associate access roles with the classes to which they provide access and with any relevant privileges or access settings. When you create a new access role, you must associate it with the appropriate classes. When you associate an access role or privilege with a class, you not only associate the names of the rules, but you also specify the level of access a role or privilege has to a class or the conditions under which the role or privilege can access the class. This process allows for an extremely flexible and powerful way of defining class-based security.


Setting Up Calendars The calendar identifies business days and the hours of operation on these days. Holidays and other non-work days, typically Saturday and Sunday, are considered non-business days.

Calendars affect the following activities:

■ Case types that require a work date to be a business day

■ Service Level Rules that measure goal and deadline times in business days

The Healthcare Industry Framework comes with a sample calendar for 2006. As part of the deployment process, you can add, delete, and update the calendar to reflect your operation’s open business days and local holidays. The RuleSet record is Data-Admin-Calendar. The default time zone is EST.


Figure 7-1 shows the 2006 calendar supplied with the product.

Figure 7-1. Default Calendar for 2006


Setting Up Correspondence The Healthcare Industry Framework comes with predefined correspondence templates.

Some correspondence rules are called top-level rules (indicated on the Prompts tab of the rule form). Master templates are based on a top-level correspondence rule and can include other rules or references to other rules. The correspondence type — whether e-mail, mail, phone, or fax — is defined in the top-level correspondence rule when it is created.

The rules define various correspondence segments such as the header, footer, and body. Each segment (or stream) provides a piece of the HTML code needed to generate a complete piece of correspondence. The advantage of defining correspondence templates in separate rules is that one header or footer, for example, can be used in many correspondence rules.

Figure 7-2 shows a representative correspondence template structure.

Figure 7-2. Standard Correspondence Template Elements


Because the correspondence is HTML based, it provides the opportunity to create a professional look and feel to letters, e-mails, and faxes that are sent to customers and banks. See page Chapter 3, “What is Already Set Up” for a list of preconfigured correspondence templates and correspondence fragments.

E-mails are generated through capabilities built into PegaRULES Process Commander. The routing, printing, and faxing of correspondence is handled by an interface to the PegaDISTRIBUTION Manager. However, it is not necessary to have PegaDISTRIBUTION Manager installed when updating and testing changes to the templates. Correspondence will be generated, attached to the case, and can be reviewed online in its printed form. It won’t print until the interface is active.

Tip: To copy and customize the templates in your RuleSet, maintain the same Correspondence Rule name to avoid unnecessary updates to workflow elements that call specific templates. Add templates only when no alternative is available.


Sample HTML and Template Letter Shown below are the underlying HTML for the Request Additional Information letter correspondence template, the several Fragments associated with the template, and the letter produced by the Healthcare Industry Framework. (Figure 7-3 through Figure 7-6 show several parts of a piece of correspondence.)

Figure 7-3. Correspondence Template — HTML for Request Additional Information Letter


Figure 7-4. Correspondence Fragment – Stylesheet for Correspondence Template

Figure 7-5. Correspondence Fragment — Header Requestor for Correspondence Template


Figure 7-6. Correspondence Output – Sample Letter


Adding Additional X-12 Transactions The Healthcare Framework can be extended to support additional X12 transactions. This section describes how to extend the classes and properties, and the supporting Parse Delimited and Activity Rules.

Extending the Classes and Properties The classes and properties that come with the Framework support the segments for the 278, 837 and 834 X12 transaction types as defined in the corresponding National Electronic Data Interchange (EDI) Transaction Set Implementation Guide (IG). Most of these segments are common to all transaction types. Refer to Chapter 5, “X12 Message Processing” for a full description of the class structure. When adding an additional transaction type, follow these steps using the class structures provided for the existing transaction types as a guide:

1. Create classes for additional segments needed for new transaction type.

− Examine the appropriate Transaction Set Implementation Guide to determine which additional segments you need to create.

− For each new segment, create an abstract sub-class in the PegaHC-X12-Data class following the naming convention of SegmentId_SegmentName (such as NM1_IndividualorOrganizationalName). This name should be a generic name for the segment, not specific to the usage in the transaction set.

− Create a property for each of the data elements in the new segment class as defined in the Transaction Set Implementation Guide.

− Note the special handling of a component data element (see CAS_ClaimsAdjustment as an example).

2. Create a class for the new transaction type itself.

− Create a concrete class in the PegaHC-X12-Data class for the new transaction type.


− Under this newly created class for the transaction type, create an abstract class for each of the loops defined in the Transaction Set Implementation Guide.

− Create properties in each of the loop classes for each of the segments in that loop. This is an iterative process as there are sub-loops contained in loops.

− Create an abstract class for the X12 object itself. For example, under the PegaHC-X12-Data-N278 class, two classes are defined, HealthcareServicesRequest and HealthcareServicesResponse. Create the properties for this class which make up the object, using the newly defined classes for the loops. Note that the X12 object corresponds to the entire functional group in the X12 message, so this X12 object class will most likely contain 3 properties: FunctionalGroupHeader and FunctionalGroupTrailer, each of which is a page of the appropriate class and Transaction, which is a page list of the newly created transaction class.

Parse Delimited Rules

Parse Delimited rules need to be created for each of the new classes you created for segments not previously defined.

Figure 7-7 shows an example of a Parse Delimited rule using the UM_HealthCareServicesReviewInformation class.


Figure 7-7. Parse Delimited Rule Example


Create the Parse Delimited rules as follows. 1. Create a Rule-Parse-Delimited instance for each newly created

segment. − Use the appropriate PegaHC-X12-Data- class for the Applies to part of

the key. − Use “ParseX12” for the Namespace part of the key. − Use the segment id for the Record Type part of the key. − Use an “*” for the delimiter and a “\” for the escape character. − Select Use Parse Details as the method and check Drain Remaining

Data. − In the parsing details section:

Select Clipboard in the Map To field. Use the smart prompt in the Map To Key field to select each property

in the segment class.

− g. For properties that are defined for component data elements, call another parse delimited rule for the appropriate class by specifying Delimited ParseRule in the Map To field and the Record Type of the parse rule you are calling in the Map To Key field.

2. Create a Rule-Parse-Delimited instance for each of the classes that were created to support a component data element.

− For the Applies To part of the key, be sure to use the same class as the calling Parse Delimited rule.

− Use “ParseX12” for the Namespace part of the key. − Use the property name for the composite data structure for the Record

Type part of the key. − Use a “:” for the delimiter and a “\” for the escape character. − Select Use Parse Details as the method and check Drain Remaining

Data. − In the parsing details section:

Select “Clipboard” in the Map To field. Use the smart prompt in the Map To Key field to select each property

in the segment class.


Activity Rules To support processing the X12 message (getting the X12 data onto the clipboard and ready for processing by the application), create one new X12ParseMessage and update the existing activity, X12ParseMessageType, to support the new transaction type.

Creating X12ParseMessage Activity Create a new X12ParseMessage (it must have this name) in the concrete class that was previously created for the transaction type. (Any of the three X12ParseMessage activities provided in the Framework support the three transaction types, N278, N837 and N834, and can be used as an example.) The first four steps in the activity are standard for all X12ParseMessage activities and are required to parse the X12 message and put the data onto the X12Data page in the clipboard.

Note: The X12ParseMessage activity for the N278 class has additional steps – these steps are to support the functions in the PegaHCAUTH application.


The logic in the X12ParseMessage activity that is specific to the transaction type it is processing can be found in the Java step. The Java code is written explicitly based on the X12 layout for the transaction as defined in the Transaction Set Implementation Guide. The basic logic of the Java is as follows:

■ Scan the message — processing a segment at a time.

■ By keeping track of the location in the message (the loop) and by looking at the segment ID, determine the loop for this segment.

■ Once the current loop is determined, look at the segment ID and determine the property name in the transaction type class to which this segment should be mapped.

■ Call the appropriate Parse Delimited rule to parse the segment data and put it onto the clipboard.

Once the Java is written, step 1 in the activity is complete. Steps 2, 3 and 4 can remain the same as any of the X12ParseMessage activities provided. Step 2 updates data on the Statistics Page of the clipboard to capture data about the processing of the X12 message file. Steps 3 and 4 create an instance of the data object. Step 5 of X12ParseMessage would probably be updated to call an activity to handle the transaction type as required by your application.


Updating X12ParseMessageType Activity The X12ParseMessageType activity must be modified for the new transaction type. Update the “if” statement in the Java code segment below to recognize the code for the new transaction type and its corresponding object class.

if (strSegmentLine[1].equalsIgnoreCase("HC")) newObjClass = myStepPage.getProperty(".pxObjClass").toString() + "N837"; else if (strSegmentLine[1].equalsIgnoreCase("BE")) newObjClass = myStepPage.getProperty(".pxObjClass").toString() + "N834"; else if (strSegmentLine[1].equalsIgnoreCase("HI")) newObjClass = myStepPage.getProperty(".pxObjClass").toString() + "N278"; else newObjClass = "UNKNOWN";


Other Activities If your application requires that an X12 message be generated and sent out, an activity is needed to build that X12 message. The N278 class contains an activity that builds an X12 message for an outgoing Authorization Response (X12GenerateResponse). You can use this activity as an example.

The process is as follows:

■ Based on processing within the application, the data is put on a page in the clipboard in the X12 structure, similar to the X12Data page that was created from the inbound X12 message process.

■ An activity similar to the X12GenerateResponse is called that has a Java step that pulls data off the clipboard and moves it into a string buffer in the X12 format. Similar to the Java in the X12ParseMessage activity, this Java uses the transaction type that is being processed as defined in the Implementation Guide.


Member and Eligibility Data Interface The Appeals and Grievances layer provides data classes, PegaHC-Interface-Member and PegaHC-Interface-Policy, to store member information and policy/eligibility data. The sample data is stored as a Process Commander Data instance of these classes and accessed through the Rule-Obj-Open method. This access method can be used in production, in which case it would be necessary to create a feed process that updates the Process Commander data table periodically with new, updated, and deleted records.

To use an existing data source for these records, the Appeals and Grievances layer provides placeholder activities that can be copied and modified to enable the lookup and retrieval of information from your own centralized database files. Based on the entry of a member identifier, the lookup validates and returns member data and eligibility information. When retrieved, this information is placed on a clipboard and subsequently mapped into a Complaint case. These activities are called within a flow, which itself can be copied and modified if you require more complex processing for your lookup procedures.

To create your customer file interface, select your connectivity method (see PegaRULES Process Commander — Integrating with External Systems for your connectivity options and determine your field mapping between the data source and Smart Investigate.) Then, create and modify versions of the following activities to map and validate the data.

PegaHC-AG-Complaints GetMemberData — The activity looks up the member information in the database and sets the properties on the clipboard.

PegaHC-AG-Complaints GetMemberPolicyData — The activity looks up the member’s policy and eligibility information in the database and sets the properties on the clipboard.


Provider Data Interface The Appeals and Grievances layer provides a data class, PegaHC-Interface-Provider, to store provider information. The sample data is stored as a Process Commander data instance of this class and accessed through the Rule-Obj-Open method. This access method can be used in production, in which case it would be necessary to create a feed process that updates the PRPC data table periodically with new, updated, and deleted records.

To use an existing data source for these records, the Appeals and Grievances layer provides provides placeholder activities that can be copied and modified to enable the lookup and retrieval of information from your centralized database files. Based on the entry of a provider identifier, the lookup validates and returns provider data. When retrieved, this information is placed on a clipboard and subsequently mapped into a Complaint case. These activities are called within a flow, which itself can be copied and modified if you require more complex processing for your lookup procedures.

To create your provider file interface, select your connectivity method (see PegaRULES Process Commander — Integrating with External Systems for your connectivity options and determine your field mapping between the data source and Smart Investigate.) Then, create and modify versions of the following activities to map and validate the data.

PegaHC-AG-Complaints GetProviderData — The activity looks up the provider information in the database and sets the properties on the clipboard.


Claim Data Interface The Appeals and Grievances layer provides a data class, PegaHC-Interface-ClaimHeaderDetail, to store historical claim information. The sample data is stored as Process Commander data instance of this class and accessed through the Rule-Obj-Open method. This access method can be used in production, in which case it would be necessary to create a feed process that updates the Process Commander data table periodically with new, updated, and deleted records.

To use an existing data source for these records, the Appeals and Grievances layer provides provides placeholder activities that can be copied and modified to enable the lookup and retrieval of information from your centralized database files. Based on the entry of a claim reference number, the lookup validates and returns claim data. When retrieved, this information is placed on a clipboard and subsequently mapped into a Complaint case. These activities are called within a flow, which itself can be copied and modified if you require more complex processing for your lookup procedures.


PegaHC-AG-Complaints GetClaimData — The activity looks up the claim information in the database and sets the properties on the clipboard.


Authorization Data Interface The Appeals and Grievance Manager layer provides a data class, PegaHC-Interface-Authorization, to store historical authorization information. The sample data is stored as Process Commander data instances of this class and accessed through the Rule-Obj-Open method. This access method can be used in production, in which case it would be necessary to create a feed process that updates the Process Commander data table periodically with new, updated, and deleted records.

To use an existing data source for these records, the Appeals and Grievance layer provides placeholder activities that can be copied and modified to enable the lookup and retrieval of information from your centralized database files. Based on the entry of a authorization reference number, the lookup validates and returns authorization data. When retrieved, this information is placed on a clipboard and subsequently mapped into a Complaint case. These activities are called within a flow, which itself can be copied and modified if you require more complex processing for your lookup procedures.


PegaHC-AG-Complaints GetAuthData — The activity looks up the authorization information in the database and sets the properties on the clipboard.


Interfacing to PegaDISTRIBUTION Manager PegaDISTRIBUTION Manager is a required companion product that works with the Healthcare Industry Framework to activate printers and print servers to send correspondence in print, fax, or Rich Text Format (RTF) file modes. It can also print HTML files and their associated image files. Installed independently of the framework, it is designed to run on Microsoft Windows 2000 Professional or Server or Windows XP.

To install and configure the PegaDISTRIBUTION Manager, refer to the PegaDISTRIBUTION Manager™ (IOS) for PegaRULES Process Commander — Installation and Deployment Guide.

hcif imp guide v73 lck

Documents