healthcare industry framework implementation guide - pega · you have taken the appropriate...

Healthcare Industry Framework

Version 7.5

Implementation Guide

Copyright 2010 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.5 Updated: August 2010

Contents

Chapter 1: Before You Begin ..................................................................................................... 1-1

What Is the Healthcare Industry Framework? ........................................................................ 1-2 PegaHC — Healthcare Foundation Layer ....................................................................... 1-3 PegaHealthCodes — Healthcare Common Codes Solution Layer ................................. 1-4 PegaHCEDI — Healthcare X12 EDI Solution Layer ........................................................ 1-4 PegaHCAUTH — Authorization Management Solution Layer ......................................... 1-5 PegaHCNME — New Member Enrollment Solution Layer .............................................. 1-5 PegaHCAGM — Appeals and Grievance Management Solution Layer .......................... 1-6 PegaX124010 — HIPAA X12 4010Messaging Layer ...................................................... 1-7 PegaX125010 — HIPAA X12 5010 Messaging Layer ..................................................... 1-7

Your Framework and Process Commander ........................................................................... 1-9

Who Should Read This Document? ..................................................................................... 1-10

Education and Training ......................................................................................................... 1-11

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-6

Work Object Naming Conventions ......................................................................................... 2-8

Default Work Groups and Workbaskets ............................................................................... 2-10

Default Operators, Access Groups, and Portals ................................................................... 2-12

Predefined Organizations, Divisions, and Units .................................................................... 2-15

Predefined Access Roles and Privileges .............................................................................. 2-17

Predefined Work Parties ....................................................................................................... 2-21

Correspondence Templates ................................................................................................. 2-22 Correspondence Templates and Fragments for Authorization Management ................ 2-22 Correspondence Templates and Fragments for Appeals and Grievances .................... 2-25

Sample Database Model ...................................................................................................... 2-27

Sample Data for Testing ....................................................................................................... 2-28 Member Data ................................................................................................................. 2-28 Provider Data ................................................................................................................ 2-31 Policy Data .................................................................................................................... 2-34 Plan Benefit Data .......................................................................................................... 2-35

ii Healthcare Industry Framework Implementation Guide

Claim Data..................................................................................................................... 2-35

Sample Data to Test Authorization Management ................................................................. 2-36

Sample Data to Test New Member Enrollment .................................................................... 2-38

Sample Data to Test Appeals and Grievance Management ................................................. 2-39

Common Object Sample Data Maintenance ........................................................................ 2-41 Portal Overview ............................................................................................................. 2-42 PegaHC-Data-Party-Member (Sample Members) ......................................................... 2-43 PegaHC-Data-Party-Provider (Sample Providers) ........................................................ 2-45 PegaHC-Data-Policy (Sample Policies) ....................................................................... 2-47 PegaHC-Data-Claim (Sample Claims) .......................................................................... 2-49 PegaHC-Data-Authorization (Sample Authorizations) ................................................... 2-51 PegaHC-NME-Data-EmployerGroup (Sample Employer Groups) ................................ 2-52 PegaHC-Data-Product (Sample Plan / Benefits) ........................................................... 2-54 PegaHC-Data-Company (Sample Companies) ............................................................. 2-56

Industry Code Sets Search and Maintenance ...................................................................... 2-58

HIPAA-Enabled Data Model Overview ................................................................................. 2-60 Object-Oriented Class Model ........................................................................................ 2-60 HIPAA-Complaint Property Values ................................................................................ 2-64

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

Authorization Request Processing ....................................................................................... 3-16

Procedural Validations .......................................................................................................... 3-18 Member Validation ........................................................................................................ 3-18 Referring Provider Validation ........................................................................................ 3-21 Duplicate Request Validation ........................................................................................ 3-23

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 Declarative Validations for Chiropractic Services .......................................................... 3-34

Healthcare Industry Framework Implementation Guide iii

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

Straight Through Processing ................................................................................................ 3-35

Manual Processing ............................................................................................................... 3-36 Workflow Attributes ....................................................................................................... 3-36 Role-Privilege Matrix ..................................................................................................... 3-38 Work Urgency Points Matrix .......................................................................................... 3-41

Reports ................................................................................................................................. 3-47

Chapter 4: X12 Message Processing ........................................................................................ 4-1

Mapping X12 Messages in Process Commander ................................................................... 4-4

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-12

X12 EDI Management .......................................................................................................... 4-16 Healthcare Eligibility Request Message Processing ..................................................... 4-16 Healthcare Claim Status Request Message Processing ............................................... 4-23

Adding Additional X-12 Transactions ................................................................................... 4-27 Extending the Classes and Properties .......................................................................... 4-27 Parse Delimited Rules ................................................................................................... 4-28 Activity Rules ................................................................................................................. 4-30 Other Activities .............................................................................................................. 4-32

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

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 Underwriting Risk Evaluation and Recommendation Rule Changes ............................. 5-21 Application Routing and Review .................................................................................... 5-23 Output Process .............................................................................................................. 5-32

iv Healthcare Industry Framework Implementation Guide

Service Level Rules .............................................................................................................. 5-35

Correspondence Rules ......................................................................................................... 5-37

Declarative Rule Examples .................................................................................................. 5-39

Reporting .............................................................................................................................. 5-42 New Business Pipeline .................................................................................................. 5-42 New Business Performance .......................................................................................... 5-43 New Hire Pipeline .......................................................................................................... 5-43 New Hire Performance .................................................................................................. 5-44 Drill-Down Details .......................................................................................................... 5-44

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

Chapter 6: The Appeals and Grievances Solution ................................................................... 6-1

The Final Disposition Process for Appeals ............................................................................. 6-5

Extending the Final Disposition Notification Process .............................................................. 6-7

Workbasket Routing for Complaints ....................................................................................... 6-9

Extending the Quality Audit Process .................................................................................... 6-10

The Appeal Re-Open Process .............................................................................................. 6-11

Appeals and Grievance Manager Reports ........................................................................... 6-12

Data Interfaces ..................................................................................................................... 6-13

Chapter 1 Before You Begin

This document describes how to deploy and extend the Healthcare Industry Framework (HCIF) Version 7.5 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. Healthcare organizations can leverage HCIF 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 the following application layers:

PegaHC — Healthcare Foundation Layer (baseline)

PegaHealthCodes – Healthcare Common Codes Solution Layer

PegaHCEDI – HIPAA X12 EDI Message Solution Layer

PegaHCAUTH — Authorization Management Solution Layer

PegaHCNME — New Member Enrollment Solution Layer

PegaHCAGM — Appeals and Grievance Management Solution Layer

PegaX124010 — HIPAA X12 4010 Messaging Layer

PegaX125010 — HIPAA X12 5010 Messaging Layer

What Is the Healthcare Industry Framework? 1-3

PegaHC — Healthcare Foundation Layer This baseline layer contains the common healthcare object model, the X12 message processing infrastructure, a sample organizational model and 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

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.


PegaHealthCodes — Healthcare Common Codes Solution Layer The Healthcare Common Codes functionality previously available in the PegaHC foundation layer has been extracted into an independent rule set called PegaHealthCodes. This enables re-use of the Common Codes Solution by other Pega Framework Groups.

The solution provides the data structures, lookup, and maintenance of the following common healthcare code sets:

CPT – Current Procedural Terminology Code Set

HCPCS – Healthcare Common Procedure Coding System

NDC – National Drug Code

GCN – Generic Code Number

ICD 9 – International Classification of Diseases v9

ICD 10 – International Classification of Diseases v10

Additionally the Solution also includes the bi-directional general equivalence mapping for International Classification of Diseases (ICD) diagnosis and procedure codes for versions 9 and 10.

For additional details refer to, the Healthcare Common Codes Business Use Case Guide included on your media.

PegaHCEDI — Healthcare X12 EDI Solution Layer This layer contains the rules for processing two paired request-response X12 messages for Eligibility Request and Response (270/271) and Claim Status Request and Response (276/277). It leverages the X12 processing layer described above for accepting and parsing an inbound X12 270 and 276 messages. Both versions of the X12 messages (4010 and upcoming 5010) are supported.

The parsed messages are mapped to work objects and processed against sample business rules leveraging the sample data in the foundation layer. Corresponding response messages (271 and 277 respectively) are automatically generated.


PegaHCAUTH — Authorization Management Solution Layer This layer provides examples of straight-through processing of an X12 278 (4010) 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


PegaX124010 — HIPAA X12 4010Messaging Layer This application layer contains the HIPAA X12 Reference Implementation for processing X12 transactions for the existing 4010 version of the standard. Key features include:

■ 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

− 837P – Healthcare Professional Claim

− 837I – Healthcare Institutional 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 X12 parsing and mapping functionality of the 270 and 276 request transactions is extended to create corresponding work objects in the Manage EDI Work pool in the PegaHC Foundation layer. The work items are straight-through-processed leveraging the sample data to generate corresponding 271 and 277 response transactions respectively.

PegaX125010 — HIPAA X12 5010 Messaging Layer This application layer contains the HIPAA X12 Reference Implementation for processing X12 transactions for the upcoming 5010 version of the standard. Key features include:

■ 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

837P – Healthcare Professional Claim

837I – Healthcare Institutional Claim

270 / 271 – Healthcare Eligibility Request and Response

276 / 277 – Healthcare Claims Status Request and Response

■ 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.

Your Framework and Process Commander 1-9

Your Framework and Process Commander PegaRULES Process Commander contains a rules engine, database, processing logic, and functions — providing the base upon which Frameworks are built. Frameworks are layered, making use of underlying technology instead of reinventing process flows. 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.

Because 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 1-11

Education and Training Pegasystems Educational Services delivers in-depth programs that are designed, and delivered 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.

http://pega.com/Services/EducationalServices/Education.asp�

http://pdn.pega.com/�

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 implementing and extending the 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

Application Rules 2-3

Application Rules The framework contains Application Rules for the four main solution 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.

There are two Application Rules configured for PegaHC.

PegaHC 07-05-61 — based on the PegaHCX125010 application RuleSets leveraging the upcoming 5010 version of X12 message processing infrastructure

PegaHC 07-05-62 — based on the PegaHCX124010 application RuleSets leveraging the 4010 version of the X12 message-processing infrastructure

The Application Rules for other solution layers (PegaHCAGM, PegaHCAUTH, PegaHCNME) leverage the PegaHC 07-05-01 Application.


System Administrator Account The framework uses the following Operator IDs as default system administrator accounts. You should change the 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

PegaHC PegaHC:Administrators4010 4010Admin@MyHealthPlan

PegaHC PegaHC:Administrators5010 5010Admin@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 2-5

RuleSet Hierarchy RuleSets are arranged hierarchically with the more general rules at the bottom and more specific rules at the top. The five 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. The following diagram shows the RuleSet hierarchy with all the Healthcare Industry Framework layers. -Your Company Ruleset -PegaHCLP

-PegaHCEDI -PegaHCAUTH

-PegaHCNME -PegaHCAGM

-PegaHC -PegaX125010

-PegaX12 -PegaHealthCodes

-All RuleSets Part of Pega-RULES 06.01.01

Note: Depending on your access group, PegaX125010 may be replaced in your hierarchy with PegaX124010.


Data Classes Data classes define the data structures for supporting information that the framework uses to process work. The data classes used in the framework are listed below.

PegaHC-Data-Attachments PegaHC-Data-Authorization PegaHC-Data-Benefit PegaHC-Data-BenefitGroup 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-DRGCodes PegaHC-Data-EligibilityRequest PegaHC-Data-Enrollment PegaHC-Data-Issues PegaHC-Data-LabResults PegaHC-Data-Language PegaHC-Data-Measurement PegaHC-Data-MedicalHistory PegaHC-Data-Party PegaHC-Data-Party-Agency PegaHC-Data-Party-Broker PegaHC-Data-Party-Company PegaHC-Data-Party-InformationReceiver PegaHC-Data-Party-InformationSource

Data Classes 2-7

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-Risk 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 PegaHealth-Codes-Data- PegaHealth-Codes-Data-CPT PegaHealth-Codes-Data-NDC PegaHealth-Codes-Data-GCN PegaHealth-Codes-Data-HCPCS PegaHealth-Codes-Data-Procedure-ICD9 PegaHealth-Codes-Data-Procedure-ICD10 PegaHealth-Codes-Data-Diagnosis-ICD9 PegaHealth-Codes-Data- Diagnosis-ICD10 PegaHealth-Codes-Data-Procedure-ICD9Map PegaHealth-Codes-Data-Procedure-ICD10Map PegaHealth-Codes-Data-Diagnosis-ICD9Map PegaHealth-Codes-Data-Diagnosis-ICD10Map


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 the following table.

Work Object Naming Conventions 2-9

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

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 This table lists the default work groups and workbaskets used in the Authorization Management Solution workflow in the 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

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

Default Work Groups and Workbaskets 2-11

Work Group Workbasket Description

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.

UtilizationManagement@MyHealthPlan UMReview@MyHeealthPlan Used for all issues requiring review, additional

research, and / or follow-up by the Utilization

Management (Case Management) unit.


Default Operators, Access Groups, and Portals The framework comes with the following operators, access groups, and portals. Passwords are set to install.

Operator ID Access Group Portal Name

HCIF

Administrator@MyHealthPlan PegaHC:Administrators Developer (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

Default Operators, Access Groups, and Portals 2-13


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



New Member Enrollment NMEAdmin@MyHealthPlan NME:Administrators Developer (Default)

NMEManager (Alternate)

Acturial/Acturial

ActuaryManager@MyHealthPlan NME:EnrollmentManager NMEManager

Actuary1@MyHealthPlan NME:Underwriter NMEUser



External/Agency

Broker@MyHealthPlan NME:Broker NMEUser

External/PlanSponsor

PlanSponsor1@MyHealthPlan NME:PlanSponsor NMEUser





Enrollment/Enrollment

EnrollmentManager@MyHealthPlan NME:EnrollmentManager NMEManager

EnrollmentSupport@MyHealthPlan NME:EnrollmentRep NMEUser

EnrollmentRep1@MyHealthPlan NME:EnrollmentRep NMEUser



Sales/NewSales

SalesManagerNBU@MyHealthPlan NME:EnrollmentManager NMEManager

SalesRep1@MyHealthPlan NME:SalesReps NMEUser



Sales/RenewalSales

SalesManagerRenewals@MyHealthPlan NME:EnrollmentManager NMEManager

RenewalRep1@MyHealthPlan NME:SalesReps NMEUser



Underwriting/Underwriting

UnderwriterManager@MyHealthPlan NME:EnrollmentManager NMEManager

Underwriter1@MyHealthPlan NME:Underwriter NMEUser



UnderwritingSupport@MyHealthPlan NME:Underwriter NMEUser

Predefined Organizations, Divisions, and Units 2-15

Predefined Organizations, Divisions, and Units The 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

Claims Claims

Dental

FEP

HMO

HRA

HSA

Indemnity

ITS

Medicaid

Medicare

NASCO

Other

POS

PPO

Secure


Division Unit

CustomerService MemberServices

ProviderServices

Enrollment Enrollment

External Agency

PlanSponsor

Marketing Marketing

ProviderNetwork ProviderNetwork

QualityImprovement QualityImprovements

Sales NewSales

RenewalSales

SalesSupport

Underwriting Underwriting

UtilizationManagement UtilizationManagement

Predefined Access Roles and Privileges 2-17

Predefined Access Roles and Privileges The framework includes a set of predefined access roles. The following tables list 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.

This table shows the privileges for the following access roles: AGAssistant, AGCoordinator, AGManager, AUMCoordinator, and CLMCoordinator.

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

ActionRequestAdditionalInfo X X X X

ActionReviewAuth X X

ActionReviewClaim X X

ActionSetFinalDispostion X X

ActionTransferToCR X X


Access Roles

Privileges AGAssistant AGCoordinator AGManager AUMCoordinator CLMCoordinator

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

Predefined Access Roles and Privileges 2-19

This table shows the privileges for the following access roles: MedicalDirector, MRUCoordinator, PSNCoordinator, QICoordinator, and UMCaseManager.

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


Access Roles

Privileges MedicalDirector MRUCoordinator PSNCoordinator QICoordinator UMCaseManager

ActionTransferToUM

AllFlows X X X

AllFlowActions X X X

Perform X X X

PerformBulk X X X

ViewFlowLinks X

WorkReopen X X X

WorkUpdate X X X

Access Roles and Privileges (For Roles M – U)

Predefined Work Parties 2-21

Predefined Work Parties The 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.

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

Correspondence Templates and Fragments for Authorization Management This table lists the correspondence templates that come with the Authorization Management Solution layer and are 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

Correspondence Templates 2-23

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


Correspondence Templates and Fragments for New Member Enrollment This table lists the correspondence templates and fragments that come with the New Member Enrollment Solution layer and 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

Correspondence Templates 2-25

Correspondence Templates and Fragments for Appeals and Grievances This table lists the correspondence templates and fragments that come with the Appeals and Grievance Management layer and 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


Name Type Purpose

BodyGrievanceAcknowledgement Mail Body Text for a Grievance Acknowledgement

BodyGrievanceApproval Mail Body Text for a Grievance Approval

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 correspondence 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

Sample Database Model 2-27

Sample Database Model The 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.

See online Application Help or the PDN for information about how to view and modify the database schema.


Sample Data for Testing The following sample data is included in the 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 Pega Button > HC Sample Process (Landing Page) menu option 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

Sample Data for Testing 2-29


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

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


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


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

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


Sample Data to Test Authorization Management 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)

Sample Data to Test Authorization Management 2-37

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


Sample Data to Test New Member Enrollment 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 Appeals and Grievance Management 2-39

Sample Data to Test Appeals and Grievance Management To help you test the system, the Appeals and Grievance Management layer, you can use the following sample data. This sample data is leveraged from the underlying 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 2-41

Common Object Sample Data Maintenance The framework comes with preconfigured sample data instances for commonly referenced objects. The sample data in the framework is used in the solution layers (Appeals & 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 work pool 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 on Developer portal. To access the Developer portal use Run >Open Portal> PegaHealth User Portal.

Note: The same functionality can be invoked using the HC Sample Processes Landing Page accessed from the Pega button


Portal Overview


PegaHC-Data-Party-Member (Sample Members) These examples show the Member maintenance workflow options.

Member Search

Member Data Update


Key Rules for Member Maintenance This table lists 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


PegaHC-Data-Party-Provider (Sample Providers) These examples show the Provider Maintenance workflow options.

Provider Search

Provider Data Update


Key Rules for Provider Maintenance This table lists 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


PegaHC-Data-Policy (Sample Policies) These examples show the Policy Maintenance workflow options.

Policy Search

Policy Data Update


Key Rules for Policy Maintenance This table lists 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


PegaHC-Data-Claim (Sample Claims) These examples show the ClaimSearch workflow options.

Claim Search

Claim Header Data


Key Rules for Claim Maintenance This table lists 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


PegaHC-Data-Authorization (Sample Authorizations) These examples show the Authorization Maintenance workflow options.

Authorization Search

Authorization Data

Key Rules for Authorization Maintenance This table lists 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


PegaHC-NME-Data-EmployerGroup (Sample Employer Groups) These examples show the Employer Group Maintenance workflow options.

Employer Group Search

Employer Group Data Updates


Key Rules for Employer Group Maintenance

This table lists 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


PegaHC-Data-Product (Sample Plan / Benefits) These examples show the Plan Benefit (Product) Maintenance workflow options.

Product Search

Product Data Update (Product Information Tab)

Product Data Update (Benefits Tab)


Key Rules for Plan / Benefit Maintenance This table lists 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


PegaHC-Data-Company (Sample Companies) These examples show the Company Maintenance workflow options.

Company Search

Company Data Update


Key Rules for Company Maintenance This table lists 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


Industry Code Sets Search and Maintenance The Healthcare Common Codes Solution provides data structures, lookup and maintenance of common healthcare codes including the bi-directional general equivalence mapping for International Classification of Diseases (ICD) diagnosis and procedure codes for versions 9 and 10.

The features of the solution include:

• Common Code Lookup

o CPT – Current Procedural Terminology Code Set

o HCPCS – Healthcare Common Procedure Coding System

o NDC – National Drug Code

o GCN – Generic Code Number

o ICD 9 – International Classification of Diseases v9

o ICD 10 – International Classification of Diseases v10

• General Equivalence Mapping

o Mapping of ICD-9-to-10 and ICD10-to-9 Diagnosis and Procedures Codes

End User Process

System Processes

• HTTP Service

• SOAP Service

• Code Group Management

• Sample Code Set Maintenance

For additional details refer to, the Healthcare Common Codes Business Use Case Guide document included on your media.

Industry Code Sets Search and Maintenance 2-59

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 and/or substitute these tables with your own data sets.


HIPAA-Enabled Data Model Overview The Heathcare Foundation 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 relate to the different HIPAA EDI transactions. The framework organizes these properties in a Class Structure as shown below to avoid redundancies. Each class contains properties belonging to the relevant data class.

HIPAA-Enabled Data Model Overview 2-61

The following examples show properties in the Pega-Data-Party-Member and Pega-Data-Claim classes.


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.

This example shows the prompt list for an individual relationship.


This example shows the prompt list for the taxonomy code.

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.


This example shows the Data Classes that have their own Data Table associated with them:

Examples of instances of these data classes are shown below for Claim Status Codes and Claim Status Category Codes.

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)

Understanding the Preconfigured Workflow 3-3

Understanding the Preconfigured Workflow This diagram shows the key elements of the preconfigured process in the Framework. Each of the key components is briefly described with a reference to the key rules and a recommendation for extension.

EDI Request(X12 278)

Provider Web Service Request

(SOAP)

Create Work Object

Declarative Validations

(Specific Service Auto Approval or

Denial Rules )

Process Manually

Create AssignmentRoute to Workbasket

Assign SLAEscalate / Prioritize

Generate CorrespondenceRoute to Med Director

Assign Final DispositionTrack Inventory

END

Procedural Validations(Member,

Referring Provider, Duplicate)

Is Request Pending?

GenerateAppropriate Response

Message(278/ SOAP /

Confirmation Screen)

Manual Request (from PROC

screen)

Y

N


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 This diagram shows the architecture of a 278 EDI exchange.

EDI Validation The X12 EDI exchange requires six validation levels to be compliant with the HIPAA Standard. It assumes that the 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 most likely 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.


The following example 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.

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 performed by 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 from 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.

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 This table lists the activities 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

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


Rule Name Function

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


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.

This example 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.

To create a New Authorization Request, click the New Auth Request link. The following series of screens are displayed.

Manual Request Generation 3-11

New Auth Request – Enter IDs

New Auth Request – Select Policy


New Auth Request – Enter Auth Info

New Auth Request – Review Auth Request Info (Before Processing)


New Auth Request – Review Auth Request (After Processing)


Key Rules for the Manual Request Generation Process This table lists the activity and harness rules that 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


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.

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).

Authorization Request Processing 3-17

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.

The following diagram 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.

Procedural Validations 3-19


This table lists the validations and codes performed in the ValidateMember workflow.

Validation Reject Reason Code

Patient Not Found 77

Patient Not Eligible 95

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 This table lists the rules 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


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.

This diagram shows the ValidateReferringProvider workflow that includes a process to search for the referring provider by ID.


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 This table lists the rules 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

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).

This diagram shows the DuplicateCheck workflow that includes a process to search for potential duplicate records with previously created work objects.


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 This table lists the rules used in the duplicate request validation process.



DuplicateCheck Flow Launches the duplicate request validation process

LookupDuplicate Activity Performs matching for potential duplicates


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.

Declarative Validations 3-27

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


The following example 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).


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. This example shows the decision table called 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. The following table 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

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 This table 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


■ Certification Action Code = A3 (Not Certified)

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



Declarative Validations for Services Not Requiring a Referral This table lists the services not requiring a referral. These are identified by Service Type codes or Service 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


■ 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 3-35

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 This table lists 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)

Manual Processing 3-37


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

Role-Privilege Matrix This table lists 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


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


Process Authorization This example 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.

Transfer to Manager or to Medical Director This example shows the options that allow users to transfer the assignment to the Manager or Medical Director with some forwarding notes.


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.

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.


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.

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


This shows the Circumstance set to .RequestedUrgency=03

The goal and deadline times are different and reflect the urgency. 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

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.


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

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


The Correspondence Template for requesting additional information creates this letter.

Reports 3-47

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.


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

Reports 3-49

Drill-Down Details Users can drill down from either report to see the following information.


Hover Details Users can hover over the Auth Number and see detail information about the authorization.

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 for versions 4010 and 5010. This section provides an overview of an X12 message and how inbound and outbound processing works in the framework.

The X12 standards provide the syntax and control structures that allow data elements, segments, and transaction sets to be defined. The following page contains a diagram that shows the overall structure of X12 data and examples of message content.

NOTE: The X12 message processing capability included in the framework does not support X12 message compliance checks.


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~

Mapping X12 Messages in Process Commander 4-3

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~


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~

Each line is a segment that starts off with a segment identifier and ends with a ‘ ~ ’. Each segment is composed 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. It 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 framework contains all the classes and properties needed to support the data elements in the following transaction types:

837 (4010, 5010) — Healthcare claim; professional and institutional

834 (4010) — Healthcare enrollment

278 (4010) — Healthcare services review; request and response

270 / 271 (4010, 5010) – Healthcare eligibility: request & response

276 / 277 (4010, 5010) – Healthcare claim status; request & response Rules for processing X12 transaction files are stored in the following RuleSets:

PegaX12 — base classes for all supported X12 messages

PegaX124010 —rules for processing version 4010 of the X12 EDI Standard

PegaX125010 — rules for processing version 5010 of the X12 EDI Standard

PegaHCEDI —rules and sample business processes for processing 270/ 271 and 276/ 77 transactions

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 PegaX12-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

Mapping X12 Messages in Process Commander 4-5

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 PegaX12-Data-N278 class

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

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

■ A class is created for each loop


X12 Inbound Message Processing The service rule instance called X12file.X12.X12Inbound reads the X12 message input file and calls the activity X12ParseMessageStart to start the processing.

X12 Inbound Message Processing 4-7

The X12ParseMessageStart activity includes Java that calls another activity, X12ParseMessageType. This activity sets the type of the transactions that are in each functional group. It then calls an activity that handles the given message type by calling the X12ParseMessage activity defined in the appropriate class (such as PegaX12-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 a Parse Delimited rule for each segment. The 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 in the 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:

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

2. 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

3. For each segment, identify the Parse Delimited rule name and the class that should be populated with this segments data. Invoke that Parse Delimited rule to populate the clipboard with the appropriate class and properties. Refer to Adding Additional X12 Transactions later in this Chapter for more information.


X12 Message Classes Two types of classes 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 PegaX12-Data-N278). These classes contain properties that are of the appropriate PegaX12-Data-segment class.

Segments and Properties 4-9

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.

This diagram 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.

The data element for the NM1 segment in the diagram results in the creation of the following properties in the NM1_IndividualOrOrganizationalName class.

Example of 278 Message 4-11

Example of 278 Message This is an example of a 278 message that was read by the X12file.X12.X12Inbound service file.

The following example shows the clipboard page for the HealthServicesRequest (278 transaction type) with the embedded pages expanded to show the RequesterName. On the right, it shows the properties for the ReceiverName.


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

Rule Name Function

Class: PegaX12-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: PegaX12-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 PegaX12-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

X12 Activity Rules 4-13

Rule Name Function

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

Class: PegaX12-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 PegaX12-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: PegaX12-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 PegaX12-Data-N278-Transaction-MoveDataToResponse to move transaction segments to 278 Response page. Calls PegaX12-Data-N278-Loop2000EServiceProviderLevel-MapToAuthorization to handle mapping of ServiceProvider data.

MoveDataToResponse Moves appropriate transaction segments to 278 Response page.

Class: PegaX12-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 PegaX12-Data-N278-Loop2000FServiceLevel-MapToAuthorization to handle mapping of Service line data.

MoveDataToResponse Moves appropriate Service Provider segments to 278 Response page.

Class: PegaX12-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.

X12 Activity Rules 4-15

The following chart shows the activities and the flow between them.

Class Activity

PegaX12-Data X12ParseMessageStart

X12ParseMessageType

PegaX12-Date-N278 X12ParseMessage

CreatePegaHCData

MoveDataToResponse

PegaX12-Data-Transaction ProcessTransaction

MoveDataToResponse

PegaX12-Data-Loop2000EServiceProviderLevel MapToAuthorization

MoveDataToResponse

PegaX12-Data-Loop2000FServiceLevel MapToAuthorization

MoveDataToResponse

PegaX12-Data-N278 ProcessAuthorization

MapToResponse

X12GenerateResponse

X12WriteMessage


X12 EDI Management The framework contains preconfigured rules for managing the following four real-time X12 EDI messages:

X12 270 / 271 — Healthcare Eligibility Request and Response

X12 276 / 277 — Healthcare Claim Status Request and 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 per the X12 270 / 271 Healthcare Eligibility Request & Response Implementation Guide.and support batch as well as real-time message processing. The activities check for the message version (5010 or 4010) to determine how to handle the 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 that real-time situation, the messages are limited to one benefit request per member (subscriber or patient).

The key functionality includes:

■ X12 270 Message Parsing —per the 270/271 Implementation Guide

■ Eligibility Request Work Object Creation — for every benefit request submitted in the transaction

X12 EDI Management 4-17

■ Validation of Information Source Level

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 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

Check for Provider on File — sample business validation rule that searches for the provider record based on the Information Receiver record is not found in the sample database, If 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

Note: To facilitate processing using sample providers in the foundation layer of the framework, the provider ID on the on the sample 270 message is not using the NPI as mandated by the X12 Implementation Guide for the Transaction.


■ Validation of Subscriber Level

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 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

Check for Active Policy — If validation fails, an appropriate EB segment is returned in the 271 message. EB*6**30~ EB01 = 6 (Inactive) EB03 = 30 (Health Benefit Plan Coverage)

Check Eligibility On Service Date — The validation fails if the requested service date is outside the effective period on the active policy. If 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)


■ Process Generic Eligibility Request — If a Service Type Code "30" is submitted in the 270 EQ01, the following 2110C/D EB03 values are returned if they are a covered benefit category at a plan level.

1 - Medical Care 33 – Chiropractic 35 - Dental Care 47 – Hospital 86 - Emergency Services 88 – Pharmacy 98 - Professional (Physician) Visit – Office AL - Vision (Optometry) MH - Mental Health UC - Urgent Care

■ 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.

■ 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 —per the 270/271 Implementation Guide

The following images are samples of screens users are likely to see and use when processing these messages.

Menu Options for Processing Sample Eligibility Request Messages

Request Message Processing Summary


Eligibility Request Work Object

270 – 271 Message Side-By-Side Comparison


Key Rules This table lists the key rules used in the processing of the X12 270/271 messages.


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 per the X12 276 / 277 Healthcare Claim Status Request & Response Implementation Guide and support batch as well as real-time message processing. The activities check for the message version (5010 or 4010) to determine how to handle the 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 this 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 — 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 — per the 2760/277 Implementation Guide

The following images are samples of screens users are likely to see and use when processing these messages.

Menu Options for Processing Sample Claim Status Request Messages

Claim Status Request Message Processing Summary


Claim Status Request Work Object

Message Side-By-Side Comparison

Key Rules This table lists the key rules used in the processing of the X12 276 / 277 messages.



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

Adding Additional X-12 Transactions 4-27

Adding Additional X-12 Transactions The 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. 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 PegaX12-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 PegaX12-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 PegaX12-Data-N278 class, two classes are defined, HealthcareServicesRequest and HealthcareServicesResponse. Create the properties for this class that 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 that are not previously defined.

This example of a Parse Delimited rule uses the UM_HealthCareServicesReviewInformation class.


Creating Parse Delimited rules

1. Create a Rule-Parse-Delimited instance for each newly created segment.

− Use the appropriate PegaX12-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:

o Select Clipboard in the Map To field

o Use the smart prompt in the Map To Key field to select each property in the segment class


− 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:

o Select “Clipboard” in the Map To field

o 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 the 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 the 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 is 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 called X12GenerateResponse. You can use this activity as an example.

The process is as follows:

■ Based on processing within the application, the data is placed 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.

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 designed for extension. It can be rapidly integrated into an 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 the Sales Process Manager Framework, to facilitate desired automation in the sales and enrollment processes.


New Member Enrollment High Level Workflow This diagram 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 on the following pages.

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

Intake Process 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 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.


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.

Intake Process 5-5

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.

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.

Intake Process 5-7

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 using parse rules. The following is 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.


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 folder capabilities can be used to track completed member applications against the total census if such capability is not present in the external systems.

Intake Process 5-9

Key Rules for the Intake Processing This table lists the key rules 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

Initial Member Enrollment Application Assignment 5-11

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. The work item is accessible to any operator who has access to the 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. The work item then appears in the Plan Sponsor’s work list.

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.

Initial Member Enrollment Application Assignment 5-13

This table lists and 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

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.

Application Data Entry Workflow 5-15

Application Data Entry Workflow For applications requiring manual data entry, the process is managed by he Application Flow — 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.


This example 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.

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.

This example shows the initial medical history screen.

This screen displays only if users have a positive response to a question asked on the first screen.


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.


The Decision Table, UWRecommendation, 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?

This example shows the 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.

This example 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.


The Run Rule facility located at the top of the rule can be used to test the results of a rule change. This example shows this capability.


This table lists and 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

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 this table.

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


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 below.

The browser interface for the sales users is shown below. 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.


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.

Work item history instances are stored as objects in classes derived from the History-Work- class.


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.


The Operator ID records contain the skills and the skill rating used by the To Skilled Operator Routing Rule.


Key Rules for Routing to Individuals This table 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

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.


To handle exception processing as outlined above, the Enrollment Manager can easily change the rules shown in this example.

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.


This diagram shows a flow rule that defines the actions an underwriter user can take, such as approve, reject, or update the application.


Key Rules for Application Routing and Review This table 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

Output Process When the application work item is resolved through automated 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.


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 This table 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

Service Level Rules 5-35

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.


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

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

The Underwriting rule 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.

Correspondence Rules 5-37

Correspondence Rules This table lists 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

The correspondence template for sending a welcome letter creates the letter shown below.


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 5-39

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 this chapter are examples of the declarative network packaged in the New Member Enrollment layer.

The Declare Expressions rule in this example 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.


This example 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.

The Rule-Declare-Expression rule shown below 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.

Key Rules for the Declarative Process

This table lists 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

Declarative Rule Examples 5-41


.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


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.

Reporting 5-43

New Business Performance This report shows total time for completion of all resolved new business member enrollment applications.

New Hire Pipeline This report shows all unresolved new hire member enrollment applications by status.


New Hire Performance The report shows completion time for all resolved new hire member enrollment applications for existing group business.

Drill-Down Details Users can drill-down 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.

Extension Tip: The New Member Enrollment Solution layer comes with a reporting wizard that can be used to create custom reports from the desktop. Once created, these reports can be saved as favorites for access by an individual manager or for an entire access group. See Application Help or the PDN for more information about the wizard.

Additional Extension Ideas 5-45

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 serve as the backbone for extending it into multiple functions related to member enrollment. 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 enrollment examples, users make selections at the product level — one for Medical insurance and one for 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 there is 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

Additional Extension Ideas 5-47

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 Grievances 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.

The following pages describe its 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.

The Final Disposition Process for Appeals 6-3

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.

Quality Improvement Audit — Pre-configured 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 — Pre-configured 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 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 6-5

The Final Disposition Process for Appeals The Appeals and Grievances 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.

The following diagram shows where you might extend the flow rule to add the new processes either in the same flow or spawning a new flow.

Extending the Final Disposition Notification Process 6-7

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.

Workbasket Routing for Complaints 6-9

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 by the ResolveComplaint flow within an activity called ProviderQualityCheck, which creates a list of matching cases by Provider Identifier, for grievances that dealt with a 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 6-11

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 performed 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 reopens.

The activity additionally increments the appeal level, and calls the ReopenAppeal flow that 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 and 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)

Data Interfaces 6-13

Data Interfaces The Appeals and Grievances layer contains five data classes that store information and data.

PegaHC-Interface-Member — member information

PegaHC-Interface-Policy — policy and eligibility data

PegaHC-Interface-Provider — provider information

PegaHC-Interface-ClaimHeaderDetail — historical claim details

PegaHC-Interface-Authorization — historical authorization details

To use an existing data source for these records, the framework provides placeholder activities that you can copy and modify to enable lookup and retrieval of information from your centralized database files. Based on the entry information, a lookup retrieves the data, validates it and maps it to the clipboard and into a Complaint case.

These activities are called within a flow, which also can be copied and modified if you require more complex processing for your lookup procedures.

To create your customer file interfaces

1. Select your connectivity method. See the Integration topics on the PDN for connectivity and field mapping options.

2. Then, create and modify versions of the following activities in the PegaHC-AG-Complaints class that respond to the data classes listed above to look up, validate, and map data to the clipboard.

GetMemberData

GetMemberPolicyData

GetProviderData

GetClaimData

GetAuthData

healthcare industry framework implementation guide - pega · you have taken the appropriate...

Documents