HCIF Imp Guide V73 LCK

Healthcare Industry Framework
Implementation Guide
Copyright 2009 Pegasystems Inc., Cambridge, MA

All rights reserved. This document describes products and services of Pegasystems Inc. It may contain trade secrets and proprietary information. The document and product are protected by copyright and distributed under licenses restricting their use, copying, distribution, or transmittal in any form without prior written authorization of Pegasystems Inc. This document is current as of the date of publication only. Changes in the document may be made from time to time at the discretion of Pegasystems. This document remains the property of Pegasystems and must be returned to it upon request. This document does not imply any commitment to offer or deliver the products or services provided. This document may include references to Pegasystems product features that have not been licensed by your company. If you have questions about whether a particular capability is included in your installation, please consult your Pegasystems service consultant. For Pegasystems trademarks and registered trademarks, all rights are reserved. Other brand or product names are trademarks of their respective holders. Although Pegasystems Inc. strives for accuracy in its publications, any publication may contain inaccuracies or typographical errors. This document or Help System could contain technical inaccuracies or typographical errors. Changes are periodically added to the information herein. Pegasystems Inc. may make improvements and/or changes in the information described herein at any time.
This document is the property of: Pegasystems Inc. 101 Main Street Cambridge, MA 02142-1590 Phone: (617) 374-9600 Fax: (617) 374-9620 www.pega.com Healthcare Industry Framework Document: Implementation Guide Software Version: 7.3 Updated: June 2009
Contents
Chapter 1: Before You Begin ..................................................................................................... 1-1 What Is the Healthcare Industry Framework? ........................................................................ 1-2 PegaHC Healthcare Foundation Layer ...................................................................... 1-2 PegaHCAUTH Authorization Management Solution Layer ......................................... 1-4 PegaHCNME New Member Enrollment Solution Layer .............................................. 1-5 PegaHCAGM Appeals and Grievance Management Solution Layer .......................... 1-6 Your Framework and Process Commander ........................................................................... 1-7 Who Should Read This Document? ....................................................................................... 1-8 Education and Training........................................................................................................... 1-9 Chapter 2: What Is Already Set Up ............................................................................................ 2-1 Application Rules .................................................................................................................... 2-3 System Administrator Account ............................................................................................... 2-4 RuleSet Hierarchy .................................................................................................................. 2-5 Data Classes .......................................................................................................................... 2-7 Work Object Naming Conventions ......................................................................................... 2-9 Default Work Groups and Workbaskets ............................................................................... 2-11 Default Operators, Access Groups, and Portals ................................................................... 2-13 Predefined Organizations, Divisions, and Units.................................................................... 2-16 Predefined Access Roles and Privileges .............................................................................. 2-19 Predefined Work Parties....................................................................................................... 2-23 Correspondence Templates ................................................................................................. 2-24 Correspondence Templates and Fragments for Authorization Management ................ 2-24 Correspondence Templates and Fragments for New Member Enrollment ................... 2-26 Correspondence Templates and Fragments for Appeals and Grievances .................... 2-27 Process Commander Correspondence Templates............................................................... 2-29 Sample Database Model ...................................................................................................... 2-31 Sample Data to Test All Solutions ........................................................................................ 2-34 Member Data................................................................................................................. 2-34 Provider Data ................................................................................................................ 2-36 Policy Data .................................................................................................................... 2-39 Plan Benefit Data .......................................................................................................... 2-40 Claim Data..................................................................................................................... 2-40 Sample Data to Test the Authorization Management Solution ............................................. 2-41
ii
Healthcare Industry Framework Implementation Guide
Sample Data to Test the New Member Enrollment Solution ................................................ 2-43 Sample Data to Test the Appeals and Grievance Management Solution ............................. 2-44 Common Object Sample Data Maintenance ........................................................................ 2-46 PegaHC-Data-Party-Member (Sample Members) ......................................................... 2-48 PegaHC-Data-Party-Provider (Sample Providers) ........................................................ 2-50 PegaHC-Data-Policy (Sample Policies) ....................................................................... 2-52 PegaHC-Data-Claim (Sample Claims) .......................................................................... 2-54 PegaHC-Data-Authorization (Sample Authorizations) ................................................... 2-56 PegaHC-NME-Data-EmployerGroup (Sample Employer Groups) ................................ 2-57 PegaHC-Data-Product (Sample Plan / Benefits) ........................................................... 2-59 PegaHC-Data-Company (Sample Companies) ............................................................. 2-61 Industry Code Sets Search and Maintenance ...................................................................... 2-63 HIPAA-Enabled Data Model Overview ................................................................................. 2-68 Object-Oriented Class Model ........................................................................................ 2-68 HIPAA-Complaint Property Values ................................................................................ 2-71 Chapter 3: The Authorization Management Solution .............................................................. 3-1 Understanding the Preconfigured Workflow ........................................................................... 3-3 HIPAA EDI Exchange...................................................................................................... 3-4 High Level 278 EDI Exchange Architecture .................................................................... 3-4 EDI Validation.................................................................................................................. 3-4 X12 278 Integration ......................................................................................................... 3-5 Key Rules for X12 278 Integration................................................................................... 3-8 Manual Request Generation................................................................................................. 3-10 Key Rules for the Manual Request Generation Process ............................................... 3-14 Authorization Request Processing ....................................................................................... 3-16 Procedural Validations.......................................................................................................... 3-18 Member Validation ........................................................................................................ 3-18 Key Rules for the Member Validation Process .............................................................. 3-20 Referring Provider Validation ........................................................................................ 3-21 Key Rules for the Referring Provider Validation Process .............................................. 3-23 Duplicate Request Validation ........................................................................................ 3-23 Key Rules for the Duplicate Request Validation Process .............................................. 3-25 Declarative Validations ......................................................................................................... 3-26 Key Rules for the Declarative Process .......................................................................... 3-26 Declarative Validations for Non-Covered Experimental Treatments ............................. 3-30 Declarative Validations for Cosmetic Surgery ............................................................... 3-31 Declarative Validations for Services Not Requiring a Referral ...................................... 3-32 Declarative Validations for Cardiac Rehab Services ..................................................... 3-33
iii
Declarative Validations for Chiropractic Services .......................................................... 3-34 Declarative Validations for Podiatry Services ................................................................ 3-34 Straight Through Processing ................................................................................................ 3-35 Manual Processing ............................................................................................................... 3-36 Workflow Attributes ....................................................................................................... 3-36 Role-Privilege Matrix ..................................................................................................... 3-39 Work Urgency Points Matrix .......................................................................................... 3-42 Service Level Rules....................................................................................................... 3-43 Correspondence Rules.................................................................................................. 3-46 Reports .......................................................................................................................... 3-48 Chapter 4: X12 Message Processing ........................................................................................ 4-1 Mapping X12 Messages in Process Commander................................................................... 4-5 X12 Inbound Message Processing ......................................................................................... 4-6 X12 Message Classes ............................................................................................................ 4-8 Segments and Properties ....................................................................................................... 4-9 Example of 278 Message ..................................................................................................... 4-11 X12 Activity Rules................................................................................................................. 4-13 X12 EDI Management .......................................................................................................... 4-17 Healthcare Eligibility Request Message Processing ..................................................... 4-17 Healthcare Claim Status Request Message Processing ............................................... 4-24 Chapter 5: The New Member Enrollment Solution .................................................................. 5-1 New Member Enrollment High Level Workflow ...................................................................... 5-2 Intake Process ........................................................................................................................ 5-3 Initiating the Enrollment Application Process .................................................................. 5-3 Manual Input Intake Method ............................................................................................ 5-5 PDF Intake Method ......................................................................................................... 5-7 External Message Intake Method .................................................................................... 5-7 Key Rules for the Intake Processing ............................................................................... 5-9 Initial Member Enrollment Application Assignment............................................................... 5-11 Common Process Workflow .......................................................................................... 5-13 Application Data Entry Workflow .......................................................................................... 5-15 Medical History .............................................................................................................. 5-18 Medical Underwriting Risk Evaluation and Recommendation ....................................... 5-19 New Member Enrollment Application Routing and Review ........................................... 5-24 Output Process.............................................................................................................. 5-34 Service Level Rules .............................................................................................................. 5-36 Correspondence Rules ......................................................................................................... 5-39
iv
Declarative Rule Examples .................................................................................................. 5-41 Key Rules for the Declarative Process .......................................................................... 5-41 Reporting .............................................................................................................................. 5-44 New Business Pipeline .................................................................................................. 5-44 New Business Performance .......................................................................................... 5-45 New Hire Pipeline .......................................................................................................... 5-45 New Hire Performance .................................................................................................. 5-46 Drill-Down Details .......................................................................................................... 5-46 Additional Extension Ideas ................................................................................................... 5-48 Member Access to Enrollment Application .................................................................... 5-48 Member Maintenance.................................................................................................... 5-48 Consumer Driven Healthcare ........................................................................................ 5-49 Medical Underwriting ..................................................................................................... 5-49 Integration with Group Sales Process Management ..................................................... 5-49 Individual Rating ............................................................................................................ 5-50 Member Eligibility Management .................................................................................... 5-50 Extend Member Enrollment for Management ................................................................ 5-50 Chapter 6: The Appeals and Grievances Solution................................................................... 6-1 The Final Disposition Process for Appeals ............................................................................. 6-4 Extending the Final Disposition Notification Process.............................................................. 6-6 Workbasket Routing for Complaints ....................................................................................... 6-8 Extending the Quality Audit Process ...................................................................................... 6-9 The Appeal Re-Open Process.............................................................................................. 6-10 Appeals and Grievance Manager Reports............................................................................ 6-11 Chapter 7: Extending Your Framework .................................................................................... 7-1 Setup Requirements ............................................................................................................... 7-3 Setting Up Calendars ............................................................................................................. 7-4 Setting Up Correspondence ................................................................................................... 7-6 Sample HTML and Template Letter ................................................................................ 7-8 Adding Additional X-12 Transactions ................................................................................... 7-11 Extending the Classes and Properties .......................................................................... 7-11 Parse Delimited Rules ................................................................................................... 7-12 Activity Rules ................................................................................................................. 7-15 Other Activities .............................................................................................................. 7-18 Member and Eligibility Data Interface ................................................................................... 7-19 Provider Data Interface......................................................................................................... 7-20 Claim Data Interface ............................................................................................................. 7-21
Authorization Data Interface ................................................................................................. 7-22 Interfacing to PegaDISTRIBUTION Manager ....................................................................... 7-23
Chapter 1 Before You Begin

This document describes how to deploy and extend the Healthcare Industry Framework for initial production use. It assumes that: The Healthcare Industry Framework is already installed You have taken the appropriate training courses Some team members are PegaRULES Process Commander certified
1-2
What Is the Healthcare Industry Framework?

Built for healthcare organizations, the Healthcare Industry Framework (HCIF) provides a healthcare-specific foundation and data model for rapid creation and deployment of SmartBPM solutions that deliver productivity, spur growth, and ensure compliance. HCIF can be implemented by organizations to: Develop applications that dramatically extend the capabilities of existing systems such as claims, billing, enrollment, membership, and provider networks Revitalize legacy applications Address new market opportunities in a fraction of the time required by more traditional development environments
It includes core features and functions that accelerate the development of personalized solutions for a payer organizations biggest challenges in areas such as medical management, billing, provider contracting, provider credentialing, and consumer directed healthcare. The framework supports frequent change and extension into new areas as the needs of the business change. The framework contains four major RuleSet layers - a baseline layer and three supporting layers that are built on top of and leverage the infrastructure of the baseline layer. PegaHC Healthcare Foundation Layer (baseline) PegaHCAUTH Authorization Management Solution Layer PegaHCNME New Member Enrollment Solution Layer PegaHCAGM Appeals and Grievance Management Solution Layer
PegaHC Healthcare Foundation Layer

This baseline layer contains the common healthcare object model, the X12 message processing infrastructure, a sample organizational model and
Before You Begin
1-3
simulated sample data for end user functions. This layer is required for all healthcare framework layers. Key features include:
HIPAA-Enabled Healthcare Data Model

Support of the healthcare data element dictionary (supporting all nine HIPAA EDI Transactions) An object-based class structure for common objects (member, provider, policy, authorization, service, claim, claim line, enrollment, broker, plan sponsor, claim payment, and premium payment) HIPAA-mandated property list validations (such as codes for claim status, remark, rejection reason, and individual relationship) Work party setup for subscriber, member, provider, plan sponsor, broker, and agency Prompt-Select and Dynamic Selection of HTML property attributes
HIPAA-EDI Reference Implementation

Structured class model to support HIPAA EDI transaction segments and properties within those segments An automated process for EDI transaction file input Parsing and mapping of the following three EDI transactions to their relevant segments and properties within the data segments 837 Healthcare Professional Claim 834 Healthcare Benefit Enrollment and Maintenance 278 Healthcare Service Review Request (Authorization Request) 270 / 271 Healthcare Eligibility Request and Response 276 / 277 Healthcare Claims Status Request and Response The parsing and mapping of the 278 transaction is extended to create a work object that is processed in the sample Authorization Management Solution layer
1-4
The parsing and mapping of the 270 and 276 request transactions is extended to create corresponding work objects in the Manage EDI Work pool. The work items are straight-through-processed leveraging the sample data to generate corresponding 271 and 277 response transactions respectively.
Framework Starter Kit

A common organization hierarchical setup including divisions and units such as Customer Service, Utilization Management, Provider Network Services, Claims, Compliant Management, and Enrollment. A common-object search and display function for members, providers, policies, claims, and authorizations. Sample data instances for common objects used for rapidly demonstrating workflow processes without having to rely on external databases.
PegaHCAUTH Authorization Management Solution Layer

This layer provides examples of straight-through processing of an X12 278 EDI message against a set of sample business rules for automated approval or denial of the prior authorization request and workflow for managing pended requests. The solution is configured so that it can be easily extended to create a comprehensive authorization management system. Key features include: 278 EDI transaction parsing and authorization request work object creation Provider Web Self-Service application portal and authorization request SOAP message creation Authorization request straight through processing (automated approval and denial rules) Pended request management
Before You Begin
1-5
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 nonmanual 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
1-6
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
Before You Begin
1-7
Your Framework and Process Commander

PegaRULES Process Commander contains a rules engine, database, processing logic, and functions providing the base upon which Pegasystems Frameworks are built. Process Commander Frameworks are layered, making use of underlying technology instead of reinventing process flows (Figure 1-1). Additional flows and rules are contained in the Framework layer and support application-specific functions (such as contact management or customer service). The rules you modify when extending the Framework are at the top level, as they supersede the Framework defaults.
Figure 1-1. Process Commander Frameworks Showing Layers Because Pegasystems Frameworks all share the same underlying technology, configuration processes (such as creating accounts and copying rules) are identical to those in Process Commander. You can use the Framework RuleSets as a starting point for extending the Framework, making it specific to your organizational needs.
1-8
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.
Before You Begin
1-9
Education and Training

Pegasystems Educational Services delivers in-depth programs that are designed, delivered, and taught by certified experts for those who would like additional training. Through hands-on, role-based training, students receive critical knowledge from professionals skilled in the implementation of PegaRULES Process Commander solutions. For more information about Pegasystems programs and schedules, visit us at http://pega.com/Services/EducationalServices/Education.asp The Pega Developer Network (PDN), located at http://pdn.pega.com, is the primary technical resource area for the Process Commander developer community. The PDN contains a broad range of technical articles including troubleshooting and How-To information and a comprehensive and searchable knowledgebase to help developers speed their application development. The PDN also links directly to the customer support section of pega.com where customers can submit trouble reports and product enhancement requests. For information about installing or working with third-party applications, such as Microsoft Visio, consult vendor documentation.
Chapter 2 What Is Already Set Up

This chapter describes defaults and samples that are set up and ready for your use. It is expected that you will use these as a basis for extending the Healthcare Industry Framework. The topics include: Application Rules System Administrator Accounts RuleSet Hierarchy Data Classes Work Object Naming Conventions Default Work Groups and Workbaskets Default Operators and Access Groups Predefined Organizations, Divisions, and Units Predefined Access Roles and Privileges Predefined Work Parties Correspondence Templates Sample Database Model Sample Data for Testing Purposes Common Object Sample Data Maintenance
2-2
Industry Code Set Search and Maintenance HIPAA-Enabled Data Model Overview
What Is Already Set Up
2-3
Application Rules
The Healthcare Industry Framework contains Application Rules for the four layers (PegaHC, PegaHCAGM, PegaHCAUTH, PegaHCNME) of the framework. The Application rules define an ordered set of RuleSets and versions that together identify the parts of the solution layers of the framework. In addition, application rules relate the application's objectives, use cases, and actors to objects created as part of the Direct Capture of Objectives capabilities. The Access Groups (listed later) are associated with specific Application Rules. The Healthcare Frameworks use the following numbering convention for the Application rules xx-yy-zz (e.g. PegaHC 07-03-55) where: xx relates to the major version of the framework yy relates to the minor version of the framework zz relates to the PRPC version that the framework is supported on
2-4
System Administrator Account

The Healthcare Industry Framework uses the following Operator IDs as the default system administrator accounts for the respective applications. You should change this password after logging in.
Note: Operator IDs are not case sensitive, but passwords are case
sensitive. . Application PegaHC PegaHCAGM PegaHCAUTH PegaHCNME Access Group PegaHC:Administrators AGM:Administrators AUTH:Administrators NME:Administrators System Administrator ID Administrator@MyHealthPlan AGMAdmin@MyHealthPlan AUTHAdmin@MyHealthPlan NMEAdmin@MyHealthPlan
The password for each System Administrator login is: Password: install
2-5
RuleSet Hierarchy
RuleSets are arranged hierarchically, with the more general rules at the bottom and more specific rules at the top. The four RuleSets at the bottom are standard in all applications and control the underlying Process Commander operations, while the rules towards the top control application functions. The RuleSet order is critical to rule resolution. To find the appropriate rule, Process Commander begins with the top RuleSet in this list, and if the rule is not found moves to the next RuleSet. In this manner, custom, site-specific rules have precedence over application-specific rules. Figure 2-1 shows the RuleSet hierarchy with all the Healthcare Industry Framework layers.
Figure 2-1. RuleSet Hierarchy The Healthcare Industry Framework RuleSets include: PegaHCNME the Healthcare Industry rules for New Member Enrollment provide sample workflows of the enrollment process for new hires and new members.
2-6
PegaHCAUTH the Healthcare Industry rules for Prior Authorization (Pre-Certification) Management provide examples of straight-throughprocessing of an X12 278 EDI message against a set of sample business rules for automated approval or denial of the prior authorization request and workflow for managing pended requests. PegaHCAGM the Healthcare Industry rules for Appeals and Grievances provides a sample configuration that you can use to manage complaints received from members and other interested parties. PegaHC the healthcare foundation layer containing the common healthcare object model, X12 message processing infrastructure, sample EDI straight-through-processing, a sample organizational model, and simulated sample data for end user functionality (members, policies, benefits, providers, claims, authorizations etc.). This rule set is required for all healthcare framework layers.
The Process Commander RuleSets include: Pega-ProCom workflow support and portal facilities Pega-IntSvcs system interface support, including connectors and services Pega-WB internal logic and facilities Pega-RULES activities, Java generation, rule resolution, and other basic rules engine operations
2-7
Data Classes
Data classes define the data structures for supporting information that the Framework uses to process work. The data classes used in the Healthcare Industry Framework are listed below. PegaHC-Data-Attachments PegaHC-Data-Authorization PegaHC-Data-Claim PegaHC-Data-ClaimConditionCodes PegaHC-Data-ClaimLine PegaHC-Data-ClaimOccurrenceCodes PegaHC-Data-ClaimPendCodes PegaHC-Data-ClaimProcedureCodes PegaHC-Data-ClaimSpanOccurrenceCodes PegaHC-Data-ClaimStatusCategoryCodes PegaHC-Data-ClaimStatusCodes PegaHC-Data-ClaimTreatmentCodes PegaHC-Data-ClaimValueCodes PegaHC-Data-CodeGroup PegaHC-Data-CPTCodes PegaHC-Data-Diagnosis PegaHC-Data-DRGCodes PegaHC-Data-DrugCodes PegaHC-Data-EligibilityRequest PegaHC-Data-Enrollment PegaHC-Data-HCPCSCodes PegaHC-Data-Language PegaHC-Data-Measurement PegaHC-Data-NDCCodes PegaHC-Data-Party PegaHC-Data-Party-Agency PegaHC-Data-Party-Broker PegaHC-Data-Party-Company PegaHC-Data-Party-InformationReceiver PegaHC-Data-Party-InformationSource
2-8
PegaHC-Data-Party-Member PegaHC-Data-Party-Payer PegaHC-Data-Party-PlanSponsor PegaHC-Data-Party-Provider PegaHC-Data-Payment PegaHC-Data-Payment-Claim PegaHC-Data-Payment-Premium PegaHC-Data-Policy PegaHC-Data-Population PegaHC-Data-Prescription PegaHC-Data-Product PegaHC-Data-RemarkCodes PegaHC-Data-Service PegaHC-Data-ToothCodes PegaHC-AG-Data-GrievanceReason PegaHC-AG-Data-Service PegaHC-NME-Data-EmployerGroup PegaHC-NME-Data-MedicalExam PegaHC-NME-Data-MedicalHistory PegaHC-X12-Data- classes for segments included in the HIPAA X12 EDI transactions
2-9
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 objects 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 systemassigned number and a prefix defined as in a pyDefault Model in the PegaHCAUTH RuleSet. For example, PR-1003 could be a work object related to a purchase requisition application. The prefixes currently defined in the Healthcare Industry Framework are shown in Figure 2-2.
Prefix
CLMSR-
Work Object
Claim Status Request
Applies To
PegaHC-EDI-WorkClaimStatusRequest
2-10
ELGSR-
Eligibility Request
PegaHC-EDI-WorkEligibilityRequest PegaHC-AUTH-WorkAuthRequest PegaHC-AG-WorkComplaint PeagHC-NME-WorkEnrollment-EnrollmentApp
AuthCMPMEA-
Authorization Request Complaint Member Enrollment Application
Figure 2-2: Work Object IDs You can change this prefix or create additional prefixes by copying the default model into your RuleSet and making your changes.
2-11
Default Work Groups and Workbaskets

Figure 2-3 lists the default work groups and workbaskets used in the Authorization Management Solution workflow in the Healthcare Industry Framework.
Note: The Healthcare layer (PegaHC) does not include any predefined
work groups and workbaskets.
Work Group
Workbasket
Description
Authorization Management Solution ServiceReview@MyHealthPlan ServiceReview@MyHealthPlan Used for routing all pended service review requests MDReview@MyHealthPlan Used for routing all pended service review requests that require the Medical Directors 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 Actuary@MyHealthPlan Enrollment@MyHealthPlan Defaut@MyHealthPlan Actuary@MyHealthPlan Enrollment@MyHealthPlan The default workbasket Used for routing work to the actuary group 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
2-12
Work Group
RenewalSales@MyHealthPlan
Workbasket
RenewalSales@MyHealthPlan
Description
Used for routing work to the renewal sales group
Underwriting@MyHealthPlan
Underwriting@MyHealthPlan
Used for routing work to the underwriting group
UnderwritingSupport@MyHealthPlan
Used for routing work to the underwriting support users
Appeals and Grievance Management Solution Default@MyHealthPlan AppealsGrievance @MyHealthPlan 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@MyHea lthPlan PNSReviewt@MyHealthPlan Used for all issues requiring review, additional research, and / or follow-up by the Network Services Unit. QualityReview@MyHealthPlan QualityReview@MyHealthPlan Used for all issues requiring review, additional research, and / or follow-up by the Quality Review team. UtliziationManagement@MyHealth Plan UMReview@MyHeealthPlan Used for all issues requiring review, additional research, and / or follow-up by the Utilization Management (Case Management) unit. Defaut@MyHealthPlan Complaints@MyHealthPlan The default workbasket Used for all complaints
Figure 2-3. Work Groups and Workbaskets
2-13
Default Operators, Access Groups, and Portals

The Healthcare Industry Framework comes with the following operators, access groups, and portals (Figure 2-4). All passwords are set to install by default.
Operator ID
HCIF Administrator@MyHealthPlan
Access Group
Portal Name
PegaHC:Administrators
HCIFDeveloper (Default) AGMManager (Alternate) AUTHManager (Alternate) NMEManager (Alternate)
Appeals & Grievances Manager (AGM) AGMAdmin@MyHealthPlan AGManager@MyHealthPlan CLMManager@MyHealthPlan MedDirector@MyHealthPlan MRUManager@MyHealthPlan PNSManager@MyHealthPlan QIManager@MyHealthPlan UMManager@MyHealthPlan AGAssistant@MyHealthPlan AGCoordinator@MyHealthPlan CLMCoordinator@MyHealthPlan MRUCoordinator@MyHealthPlan PNSCoordinator@MyHealthPlan QCCoordinator@MyHealthPlan Authorization Management (AUTH) AUTHAdmin@MyHealthPLan MedicalDirector@MyHealthPlan UMCaseManager@MyHealthPlan AUTH:Administrators AUTH:MedicalDirector AUTH:UMCaseManager Developer (Default) AUTHManager (Alternate) AUTHManager AUTHManager AGM:Administrators AGM:AGManager AGM:CLMManager AGM:MedicalDirector AGM:MRUCoordinator AGM:PNSManager AGM:QIManager AGM:CaseManager AGM:AGAssistant AGM:AGCoordinator AGM:CLMCoordinator AGM:MRUCoordinator AGM:PNSCoordinator AGM:QICoordinator Developer (Default) AGMManager (Alternate) AGMManager AGMManager AGMManager AGMManager AGMManager AGMManager AGMManager AGMUser AGMUser AGMUser AGMUser AGMUser AGMUser
2-14
UMCoordinator1@MyHealthPlan UMCoordinator2@MyHealthPlan UMCoordinator3@MyHealthPlan New Member Enrollment NMEAdmin@MyHealthPlan Acturial/Acturial ActuaryManager@MyHealthPlan Actuary1@MyHealthPlan Actuary2@MyHealthPlan Actuary3@MyHealthPlan External/Agency Broker@MyHealthPlan External/PlanSponsor PlanSponsor1@MyHealthPlan PlanSponsor2@MyHealthPlan PlanSponsor3@MyHealthPlan Enrollment/Enrollment EnrollmentManager@MyHealthPlan EnrollmentSupport@MyHealthPlan EnrollmentRep1@MyHealthPlan EnrollmentRep2@MyHealthPlan EnrollmentRep3@MyHealthPlan Sales/NewSales SalesManagerNBU@MyHealthPlan SalesRep1@MyHealthPlan SalesRep2@MyHealthPlan SalesRep3@MyHealthPlan Sales/RenewalSales SalesManagerRenewals@MyHealthPlan RenewalRep1@MyHealthPlan RenewalRep2@MyHealthPlan RenewalRep3@MyHealthPlan Underwriting/Underwriting
AUTH:UMCoordinator AUTH:UMCoordinator AUTH:UMCoordinator
AUTHUser AUTHUser AUTHUser
NME:Administrators
Developer (Default) NMEManager (Alternate)
NME:EnrollmentManager NME:Underwriter NME:Underwriter NME:Underwriter NME:Broker NME:PlanSponsor NME:PlanSponsor NME:PlanSponsor NME:EnrollmentManager NME:EnrollmentRep NME:EnrollmentRep NME:EnrollmentRep NME:EnrollmentRep NME:EnrollmentManager NME:SalesReps NME:SalesReps NME:SalesReps NME:EnrollmentManager NME:SalesReps NME:SalesReps NME:SalesReps
NMEManager NMEUser NMEUser NMEUser NMEUser NMEUser NMEUser NMEUser NMEManager NMEUser NMEUser NMEUser NMEUser NMEManager NMEUser NMEUser NMEUser NMEManager NMEUser NMEUser NMEUser
2-15
UnderwriterManager@MyHealthPlan Underwriter1@MyHealthPlan Underwriter2@MyHealthPlan Underwriter3@MyHealthPlan UnderwritingSupport@MyHealthPlan
NME:EnrollmentManager NME:Underwriter NME:Underwriter NME:Underwriter NME:Underwriter
NMEManager NMEUser NMEUser NMEUser NMEUser
Figure 2-4. Operators, Access Groups, and Portal
2-16
Predefined Organizations, Divisions, and Units

The Healthcare Industry Framework comes with the following predefined organization, division, and units. Organization: MyHealthPlan
Division
Actuarial Administration AppealsGrievances BrokerAdministration CareManagement
Unit
Actuarial Development AppealsGrievances BrokerAdministration DiseaseManagement ProgramManagement
2-17
Division
Claims
Unit
Claims Dental FEP HMO HRA HSA Indemnity ITS Medicaid Medicare NASCO Other POS PPO Secure
CustomerService
MemberServices ProviderServices
Enrollment External
Enrollment Agency PlanSponsor
Marketing ProviderNetwork QualityImprovement
Marketing ProviderNetwork QualityImprovements
2-18
Division
Sales
Unit
NewSales RenewalSales SalesSupport
Underwriting UtilizationManagement
Underwriting UtilizationManagement
Figure 2-5. Predefined Organization, Divisions, and Units
2-19
Predefined Access Roles and Privileges

Your Framework includes a set of predefined access roles. These roles are defined in Rule-Access-Role-Name and are associated with an operators access group. Each of these roles has a corresponding rule in Rule-AccessRole-Obj where you can define specific privileges for each of these roles. Figure 2-6 lists the access roles and privileges defined in the Healthcare Industry Framework.
Note: The Healthcare (PegaHC) and the New Member Enrollment

(PegaHCNME) layers do not include any predefined access roles and privileges. Figure 2-6 shows the privileges for the following access roles: AGAssistant, AGCoordinator , AGManager, AUMCoordinator, and CLMCoordinator. Figure 2-7shows the privileges for the following access roles: MedicalDirector, MRUCoordinator, PSNCoordinstor, QICoordinator, and UMCaseManager.
Access Roles Privileges

AccessAuditTrail ActionGetProviderFeedback ActionCommunicateDecisionTo Provider ActionProcessAuthorization ActionProcesGrievance ActionPickResolutionCorr
X X X X
AGAssistant AGCoordinator AGManager AUMCoordinator CLMCoordinator
X X
X X X
2-20

ActionRequestAdditionalInfo ActionReviewAuth ActionReviewClaim ActionSetFinalDispostion ActionTransferToCR ActionTransferToManager ActionTransferToMedical Director ActionTransferToMRU ActionTransferToOwner ActionTransferToPNS ActionTransferToUM AllFlows AllFlowActions Perform PerformBulk ViewFlowLinks WorkReopen WorkUpdate
X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
AGAssistant AGCoordinator AGManager AUMCoordinator CLMCoordinator
X X X X X X
X X X X X
X X
Figure 2-6. Access Roles and Privileges (For Roles A C)
2-21

AccessAuditTrail ActionGetProviderFeedback ActionCommunicateDecision ToProvider ActionProcessAuthorization ActionProcesGrievance ActionPickResolutionCorr ActionRequestAdditionalInfo ActionReviewAuth ActionReviewClaim ActionSetFinalDispostion ActionTransferToCR ActionTransferToManager ActionTransferToMedical Director ActionTransferToMRU ActionTransferToOwner ActionTransferToPNS ActionTransferToUM AllFlows AllFlowActions Perform PerformBulk
X X X X X X X X X X X X X X X X X X X X MedicalDirector MRUCoordinator X X X PSNCoordinator QICoordinator X UMCaseManager
2-22

ViewFlowLinks WorkReopen WorkUpdate Figure 2-7. Access Roles and Privileges (For Roles M U)
X X X X X X MedicalDirector MRUCoordinator PSNCoordinator QICoordinator UMCaseManager X
2-23
Predefined Work Parties

The Healthcare Industry Framework defines work parties in a record called Default that references the following party roles: Agency AuthorizationRepresentative Broker Dependent EnrollmentRep Interested Member Originator OtherEntity Payer PlanSponsor Provider Requestor ServiceProvider Subscriber Spouse Underwriter
2-24
Correspondence Templates
The Healthcare Industry Framework comes with a standard set of sample correspondence templates and fragments. Fragments provide repeatable and reusable components within the correspondence templates. Templates are instances of Rule-Obj-Corr and Fragments are instances of Rule-CorrFragment.
Note: The Healthcare layer (PegaHC) does not include any predefined
correspondence templates or fragments.
Correspondence Templates and Fragments for Authorization Management

Figure 2-8 lists the correspondence templates that come with the Authorization Management Solution layer. These rules are all defined in the PegaHC-AUTH-Work class. Name Correspondence Rules RequestAdditonalInformation Mail Sent to request additional information from the requesting provider to support the requested service authorization 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 Type Purpose
RejectionNotice
Mail
Correspondence Fragments Logo Mail Sample health plan logo to be inserted in correspondence Used for formatting the HTML correspondence
Stylesheet
Mail
2-25
Name HeaderMember
Type Mail
Purpose Header segment of the correspondence that contains the member name and address Header segment of the correspondence that contains the requesting providers name and address Section that contains the authorization request number, request type, patient name, and received date Closing paragraph that contains the contact information, operator name, and designation
HeaderRequester
Mail
AuthReferenceInformation
Mail
Footer
Mail
Figure 2-8. Authorization Management Solution Correspondence Rules
2-26
Correspondence Templates and Fragments for New Member Enrollment

Figure 2-9 lists the correspondence templates and fragments that come with the New Member Enrollment Solution layer. These fragments are defined in the PegaHCNME-Work-Enrollment-EnrollmentApp class. Name ActionGetProviderFeedback EnrollmentRequest Email Used to notify a Plan Sponsor when an enrollment application ahs been created and assigned to the Plan Sponsor Used to notify an internal user when an enrollment application has been created and assigned to them Sent to a new subscriber when underwriting has approved the new member application Type Purpose
NewEnrollmentApplication
Email
WelcomeLetter
Mail
ActionGetProviderFeedback NMEWorkDetail NMEWorkLink Fragment Fragment Body of the e-mail sent to the plan sponsor Included in the body of the NMEWorkDetail fragment
Figure 2-9. New Member Enrollment Solution Correspondence Rules
2-27
Correspondence Templates and Fragments for Appeals and Grievances

Figure 2-10 lists the correspondence templates and fragments that come with the Appeals and Grievance Management layer. These rules are defined in the PegaHC-AG-Work-Complaints class. Name ActionGetProviderFeedback AppealAcknowledgement AppealApproval AppealDenial ComplaintRejection GetProviderFeedback GrievanceAcknowledgement GrievanceApproval GrievanceDenial RequestAdditionInformation Mail Mail Mail Mail Email Mail Mail Mail Mail Letter template for Appeal Acknowledgement Letter template for Appeal Approval Letter template for Appeal Denial Letter template for Complaint Rejection Letter template to Request Provider Feedback Letter template for Grievance Acknowledgement Letter template for Grievance Approval Letter template for Grievance Denial Letter template to Request Additional Information Type Purpose
ActionGetProviderFeedback AppealReferenceInfo BodyAppealAcknowledgement BodyAppealApproval BodyAppealDenial BodyComplaintRejection BodyGrievanceAcknowledgement BodyGrievanceApproval Mail Mail Mail Mail Mail Mail Mail Appeal-related reference information Body Text for an Appeal Acknowledgement Body Text for an Appeal Approval Body Text for an Appeal Denial Body Text for a Complaint Rejection Body Text for aGrievance Acknowledgement Body Text for aGrievance Approval
2-28
Name BodyGrievanceDenial EnclosureAGProcess
Type Mail Mail
Purpose Body text for a Grievance Denial Body text for the appeals and grievance process enclosure Footer correspondence fragment Footer correspondence fragment Header correspondence rule for the member's representative related to the complaint Header corrrespondence rule for the member related to the complaint Header correspondence rule for other entity related to the complaint Header correspondence rule for requestor of complaint Header correspondence for the service provider related to the complaint Header corr for the service provider related to the complaint Standard logo Standard style sheet Standard style sheet
Footer Footer HeaderAuthorizedRep
Email Mail Mail
HeaderMember
Mail
HeaderOther
Mail
HeaderRequestor
Mail
HeaderServiceProvider
Email
HeaderServiceProvider
Mail
Logo Stylesheet Stylesheet
Mail Email Mail
Figure 2-10. Appeals and Grievance Management Correspondence Fragments
2-29
Process Commander Correspondence Templates

Figure 2-11 lists templates that are not used in the Healthcare Industry Framework workflows but are part of Process Commander and are available for your use. If you decide to use any of these templates, remember that they are samples, and you will need to copy them to your RuleSet and then modify them to meet your requirements. Template AcknowledgeSample DeadlineTimeReminder Details ExternalAcknowledgeSample ExternalRequest ExternalRequestBrief ExternalSample Footer GoalTimeReminder Type Email, Fax, Mail, PhoneText Email Email, Fax, Mail Email Email Email Email Email, Fax, Mail Email Purpose Internal acknowledgement of a work object Notification that a work object has passed its deadline Details of a work object External acknowledgement of a work object Request for information about a work object assigned to an external user Assignment of a work object to an external user Correspondence with external party regarding a work object Signature for correspondence Notification that a work object has passed its goal time Salutation for correspondence Notification that a work object is late Notification of a new assignment on a worklist Notification that a work object has been reopened Prompt for user input
Header LateTimeReminder NewAssignment NotifyReopen PromptSample
Email, fax, mail Email Email Email Email, Fax, Mail, PhoneText
2-30
Template QuestionAboutItem ResolutionDetails ResolutionSample
Type Email, Fax, Mail, PhoneText Email, Fax, Mail Email, Fax, Mail, PhoneText
Purpose Request for more information about a work object Resolution details for a work object Notification that a work object has been resolved
Figure 2-11. Process Commander Correspondence Templates
2-31
Sample Database Model

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

1. From the Tools menu, select Database > Modify Database Schema. The View/Modify Database Schema Wizard appears with the Select a Database showing (Figure 2-12).
Figure 2-12. Select a Database 2. Select a Database from the Selection box and click Next.
2-32
3. Select a Table from the Selection box and click Next. Figure 2-13 appears showing the classes for the selected table.
Figure 2-13. Classes in Selected Table 4. Do one of the following:
To view a table of database columns along with their data type and size, click the number following the title Columns in the table (#112,) or the View Columns link on the left (Figure 2-14). To view a detailed table of database properties, click the number in the Properties Set to be Visible column (Figure 2-15).
2-33
Figure 2-14. Database Table Partial List of Database Columns Screen
Figure 2-15. Database Table Partial List of Database Properties Screen
2-34
Sample Data to Test All Solutions

The following sample data is provided in the Healthcare Industry Framework for you to test any solution. Refer to the instances of the relevant data class for a complete list of sample data instances. The Search Object Model feature available from the Run > Process menu of the Administrator portal provides functionality to search, review, update, and clone sample data instances. Member Data Provider Data Policy Data Plan Benefit Data Claim Data
Member Data
ID #
S-001 M-101 M-102 M-103
Last
Weiss Weiss Weiss Weiss
First
Matthew Jean David Jennifer
DOB
1/28/1960 3/4/1965 3/12/1996 5/12/1998
Policy #
P-001 P-001 P-001 P-001
Role
18-Self 01-Spouse 19-Child 19-Child
Eff Date
1/1/2008 1/1/2008 1/1/2008 1/1/2008
Term Date
12/31/2010 12/31/2010 12/31/2010 12/31/2010
Status
Active Active Active Active
PCP #
GEN1 FAM3 FAM3 FAM3
S-002 M-201 M-202 M-203
Schlatter Schlatter Schlatter Schlatter
Jane Thomas Laura Nancy
4/4/1956 7/10/1959 5/12/1990 8/20/1991
P-002 P-002 P-002 P-002
1/1/2008 1/1/2008 1/1/2008 1/1/2008
12/31/2010 12/31/2010 12/31/2010 12/31/2010
FAM2 INT2 FAM2 FAM2
S-003 M-301 M-302 M-303
Miller Miller Miller Miller
Eugene Beth Chris Amy
11/27/1960 2/27/1962 6/12/1997 4/28/2000
P-003 P-003 P-003 P-003
1/1/2008 1/1/2008 1/1/2008 1/1/2008
12/31/2010 12/31/2010 12/31/2010 12/31/2010
FAM1 GEN2 GEN3 GEN3
2-35
ID #
Last
First
DOB
Policy #
Role
Eff Date
Term Date
Status
PCP #
S-004 M-401
Martin Martin
Julia John
2/16/1945 10/20/1940
P-004 P-004
18-Self 01-Spouse
1/1/2008 1/1/2008
12/31/2010 12/31/2010
Active Active
FAM1 GEN1
S-005 M-501
Keuhn Keuhn
Enrico Ladena
4/27/1948 9/30/1949
P-005 P-005
18-Self 01-Spouse
1/1/2008 1/1/2008
12/31/2010 12/31/2010
Active Active
GEN2 GEN2
S-006 M-601 S-007 M-701 M-702
Dixon Dixon Gast Gast Gast
Mark Mary Ronald Linda Carl
5/15/1952 5/15/1954 10/14/1950 2/4/1952 5/19/1980
P-006 P-006 P-007 P-007 P-007
18-Self 01-Spouse 18-Self 01-Spouse 19-Child
1/1/2008 1/1/2008 1/1/2008 1/1/2008 1/1/2008
12/31/2010 12/31/2010 12/31/2010 12/31/2010 6/30/2008
Active Active Active Active Inactive
INT1 INT3
S-008 M-801 M-802
Brown Brown Brown
James Julia Oliver
10/14/1950 2/4/1952 5/19/1980
P-008 P-008 P-008
18-Self 01-Spouse 19-Child
1/1/2008 1/1/2008 1/1/2008
12/31/2010 12/31/2010 6/30/2008
Active Active Inactive
S-009 M-901 M-902
Stokes Stokes Stokes
Joseph Martha Albert
10/14/1950 2/4/1952 5/19/1980
P-009 P-009 P-009
18-Self 01-Spouse 19-Child
1/1/2008 1/1/2008 1/1/2008
12/31/2010 12/31/2010 6/30/2008
Active Active Inactive
S-010 M-1001 M-1002 M-1003
Baker Baker Baker Baker
Richard Deborah Timothy Carol
1/28/1960 3/4/1965 3/12/1996 5/12/1998
P-010 P-010 P-010 P-010
1/1/2006 1/1/2006 1/1/2006 1/1/2006
12/31/2007 12/31/2007 12/31/2007 12/31/2007
Inactive Inactive Inactive Inactive
S-011
Bishop
John
4/12/1939
P-011
18-Self
1/1/2008
12/31/2010
Active
INT1
2-36
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
BIDMC
Provider Tax ID
11-1111111
Electronic Trans ID
H-001
Type
H
Specialty #
282N00000X
Specialty
Hospital
Last Name / Org Name

Beth Israel Deaconess Medical Center
First Name
BWH
22-2222222
H-002
282N00000X
Hospital
Brigham and Women's Hospital
DFCI
33-3333333
H-003
282N00000X
Hospital
Dana Farber Cancer Institute
MGH
44-4444444
H-004
282N00000X
Hospital
Massachusetts General Hospital
NEMC
55-5555555
H-005
Hl
282N00000X
Hospital
New England Medical Center
FAM1 FAM2 FAM3 GEN1
10-1010101 10-1010102 10-1010103 20-2020201
F-001 F-002 F-003 G-001
PC PC PC PC
207Q00000X 207Q00000X 207Q00000X 208D00000X
Family Medicine Family Medicine Family Medicine General Medicine
Bhatti Bordes Chiang Ancona
Nasir Mary Mary Carl
2-37
Provider ID
GEN2
Provider Tax ID
20-2020202
Electronic Trans ID
G-002
Type
PC
Specialty #
208D00000X
Specialty
General Medicine

Burns
First Name
Erin
GEN3
20-2020203
G-003
PC
208D00000X
General Medicine
Byrn
Michael
INT1 INT2 INT3 CHIRO1 CHIRO2 CHIRO3 CREHAB1
30-3030301 30-3030302 30-3030303 40-4040401 40-4040402 40-4040403 50-5050501
I-001 I-002 I-003 C-001 C-002 C-003 CR-001
PC PC PC CO CO CO PE
207R00000X 207R00000X 207R00000X 111N00000X 111N00000X 111N00000X 261QR0404X
Internal Medicine Internal Medicine Internal Medicine Chiropractor Chiropractor Chiropractor Cardiac Rehab Facility
Bertelson Bernstein Binder Barone Meyer Lee New England Cardiac Rehab Boston Cardiac Rehab Northeast Cardiac Rehab Calder Ayala Smith Brimer Bongiorno New England Home Health New England Medical Associates
John Matthew Lisa David Robert Frank
CREHAB2
50-5050502
CR-002
PE
261QR0404X
Cardiac Rehab Facility
CREHAB3
50-5050503
CR-003
PE
261QR0404X
Cardiac Rehab Facility
POD1 POD2 POD3 CARD1 GAST1 HHA1
60-6060601 60-6060602 60-6060603 70-7070701 80-8080801 90-9090901
P-001 P-002 P-003 CRD-001 GAST-001 HHA-001
CO CO CO CO CO PE
213E00000X 213E00000X 213E00000X 207RC0000X 207RG0100X 251E00000X
Podiatry Podiatry Podiatry Cardiology Gastroenterology Home Health Agency
Gerard Enrico Marshall Joseph Charles
GRP1
66-6666666
GRP-001
PC
193200000X
Multi-Specialty Group
2-38
Provider ID
GRP2
Provider Tax ID
77-7777777
Electronic Trans ID
GRP-002
Type
CO
Specialty #
207P00000X
Specialty
Emergency Medicine

New England Critical Care Associates Well Health Clinic
First Name
GRP3
98-9898989
GRP-003
PC
193400000X
Medical Group Single Specialty
GRP4
98-9898990
GRP-004
PC
193400000X
Good Foot Clinic
GRP5
98-9898995
GRP-005
PC
193400000X
Fine Spine Clinic
RHM1 EMERG1
88-8888888 99-9999999
RHM-001 EMERG001
CO CO
207RR0500X 207P00000X
Rheumatology Emergency Medicine
Denman Bell
Susan Stuart
EMERG2
99-9999998
EMERG002
CO
207P00000X
Emergency Medicine
Laplante
Michael
EMERG3
99-9999997
EMERG003
CO
207P00000X
Emergency Medicine
Brown
John
OBGYN1
10-1111111
OBGYN001
CO
207V00000X
OB - GYN
Norin
Sandra
RAD1
20-2222222
RAD-001
PE
203BR0201Y
Radiology
New England Radiology Associates
PLAST1
30-3333333
PLAST001
OP
208200000X
Plastic Surgery
Morgan
Timothy
Figure 2-16. Provider Data
2-39
Policy Data
Policy #
P-001 P-002 P-003 P-004 P-005 P-006 P-007 P-008 P-009 P-010 P-011 P-012 P-013 P-014 P-015
Policy Type
Family Family Family Emp + Sp Emp + Sp Emp + Sp Family Family Family Family Emp Only Family Family Family Emp + Sp
Plan #
HMO15 HMO15 HMO15 POS15 POS15 POS15 PPO15 PPO15 PPO15 HMO10 HMO15 HMO15 HMO15 HMO15 POS15
Plan Type
HMO HMO HMO POS POS POS PPO PPO PPO HMO HMO HMO HMO HMO POS
Group #
G-001 G-002 G-003 G-001 G-002 G-003 G-001 G-002 G-003 G-001 G-001 G-002 G-001 G-002 G-003
Group Name
Pegasystems Inc. Razorfish Inc. Eclyspis Inc Pegasystems Inc. Razorfish Inc. Eclyspis Inc Pegasystems Inc. Razorfish Inc. Eclyspis Inc Pegasystems Inc. Pegasystems Inc. Razorfish Inc. Pegasystems Inc. Razorfish Inc. Eclyspis Inc
Effective Date
1/1/2008 1/1/2008 1/1/2008 1/1/2008 1/1/2008 1/1/2008 1/1/2008 1/1/2008 1/1/2008 1/1/2006 1/1/2008 1/1/2006 1/1/2006 1/1/2006 1/1/2006
End Date
12/31/2010 12/31/2010 12/31/2010 12/31/2010 12/31/2010 12/31/2010 12/31/2010 12/31/2010 12/31/2010 12/31/2007 12/31/2010 12/31/2007 12/31/2007 12/31/2007 12/31/2007
Figure 2-17. Policy Data
2-40
Plan Benefit Data

Plan #
HMO15 PPO15 PPO Plan 1 POS15 POS Plan 1 CHIRO10 DEN10 Chiro Rider 1 Dental Plan 1
Plan Name
HMO Plan 1
Description
$15 OV, $50 ER, $75 IP, $15 / $25 / $30 Rx $15 OV, $50 ER, $20 / $40 / $60 Rx, Non-Network $250 / $500 Ded, 80% to $3000 / $6000 $15 OV, $50 ER, $75 IP, $20 / $40 / $60 Rx, NonNetwork $250 / $500 Ded, 80% to $1000 / $2000 $10 OV, 20 VS MAX 70%, $50 / $150 / $1500 DED
Effective Date
5/12/2002
End Date
12/31/3000
5/12/2002
12/31/3000
5/12/2002 5/12/2002 5/12/2002
12/31/3000 12/31/3000 12/31/3000
Figure 2-18. Plan / Benefit Data
Claim Data
Claim #
CLM-001
Mbr ID
M-103
Svc Pvder ID
EMERG1
Total Charge
340
Svc From Date

5/10/2009
Svc To Date
5/10/2009
Claim Type
P
Status
Svc Code
99284
Description
Emergency Medical Care
Paid
CLM-002
M-101
OBGYN1
55
5/10/2009
5/10/2009
Paid
59025
Maternity Service
CLM-003
M-801
HHA1
340
5/10/2009
5/10/2009
Denied
S9330
Home Health Service
CLM-004
M-501
CARD1
25
5/10/2009
5/10/2009
Paid
93797
Cardiac Rehab Service

GI Service
CLM-005
S-006
GAST1
1600
5/10/2009
5/10/2009
Paid
91110
Figure 2-19. Claim Data
2-41
Sample Data to Test the Authorization Management Solution

The Authorization type abbreviations used are: SC Specialty Care Review HS Health Service Review AR Admission Review
Requesting Auth #
Auth-1001 Auth-1002 Auth-1003 Auth-1004 Auth-1005 Auth-1006 Auth-1007 Auth-1008 Auth-1009 Auth-1010 Auth-1011
Member ID
S-002 M-301 S-999 MM-902 M-501 M-401 S-006 S-008 S-007 S-003
Auth Type
SC SC SC SC SC HS HS HS HS HS HS
Prov ID
G-001 CRD-001 G-001 G-002 G-002 G-002 G-001 I-001 I-001 I-002 F-001
Status
Resolved-Denied Resolved-Denied Resolved-Denied Resolved-Denied Resolved-Denied Resolved-Denied Resolved-Denied Resolved-Denied Resolved-Denied Resolved-Denied ResolvedNoAuthRequired
Description
Service Prov Not on File Requesting Prov Not a PCP Subscriber Not Found Patient Not Found Patient Not Eligible Experimental Treatment (Thermograph) Experimental Treatment (Dynamic Infra-red Perfusion Imaging) Experimental Treatment (Surface Scan) Experimental Treatment (EMG) Cosmetic Surgery No Auth Required (Diagnostic X-Ray)
Auth-1012
I-001
S-011
HS
ResolvedNoAuthRequired
No Auth Required (Diagnostic Lab)
Auth-1013
F-003
M-101
HS
No Auth Required (EKG)
Auth-1014
I-002
M-201
HS
No Auth Required (Cardiac Stress Test)
2-42
Requesting Auth #
Auth-1015
Member ID
M-301
Auth Type
HS
Prov ID
G-002
Status
Description
No Auth Required (Joint Aspiration)
Auth-1016
G-002
M-901
HS
No Auth Required (Echocardiogram)
Auth-1017 Auth-1018
G-002 G-002
M-801 S-008
HS HS
Pending-Review Pending-Review
Cardiac Rehab (Service Not Eligible - Diagnosis not matched) Cardiac Rehab (Service Not Eligible - Svc Prov Specialty not matched)
Auth-1019 Auth-1020 Auth-1021
G-002 G-001 G-001
S-009 S-001 S-007
HS HS HS
Pending-Review Pending-Review Pending-Review
Cardiac Rehab (Service Not Eligible - Diagnosis date too old) Chiro Service (Service Not Eligible - Diagnosis not matched) Chiro Service (Service Not Eligible - Service Provider Specialty not matched)
Auth-1022 Auth-1023
F-002 F-002
S-002 S-011
HS HS
Pending-Review Pending-Review
Podiatry Service (Service Not Eligible - Diagnosis not matched) Podiatry Service (Service Not Eligible - Svc Prov Specialty not matched)
Auth-1024 Auth-1025 Auth-1026 Auth-1027 Auth-1028 Auth-1029 Auth-1030 Auth-1031
G-002 G-002 G-002 G-001 G-001 F-002 F-002 F-002
M-801 S-008 S-009 S-001 S-007 S-002 S-011 S-011
HS HS HS HS HS HS HS AR
Resolved-Approved Resolved-Approved Resolved-Approved Resolved-Approved Resolved-Approved Resolved-Approved Resolved-Approved Pending-Review
Cardiac Rehab Cardiac Rehab Cardiac Rehab Chiro Service Chiro Service Podiatry Service Podiatry Service Admission Request
Figure 2-20. Authorization Data
2-43
Sample Data to Test the New Member Enrollment Solution

Sample Employer Group data is provided or you can create new sample data to test the New Member Enrollment layer. Two instances of sample Employer Group records are preconfigured: GRP-0001 Joergs Bookstore GRP-0002 Jeffs Diner
2-44
Sample Data to Test the Appeals and Grievance Management Solution

To help you test the system, the Appeals and Grievance Management layer you can uses the following sample data. This sample data is leveraged from the underlying Healthcare Industry Framework and is shown in previous tables. These members have denied authorizations / and / or claims associated with them. Member Information
ID
S-006 S-007 S-008 M-401 M-501 M-801
Last
Dixon Gast Brown Martin Keuhn Brown
First
Mark Ronald James John Ladena Julia
DOB
5/15/1952 10/14/1950 10/14/1950 10/20/1940 9/30/1949 2/14/1952
Policy
P-006 P-007 P-008 P-004 P-005 P-008
Role
Subscriber Subscriber Subscriber Spouse Spouse Spouse
Provider Information
ID
INT1 INT2 GEN1 GEN2 Claims ID CLM-1
Last
Bertelson Bernstein Ancona Burns
First
John Matthew Carl Erin
Specialty
207R00000X 207R00000X 208D00000X 208D00000X Internal Medicine Internal Medicine General Medicine General Medicine
For Member M-801
2-45
Authorizations ID Auth-1 Auth-2 Auth-3 Auth-4 Auth-5 For Member M-501 M-401 S-006 S-008 S-007
2-46
Common Object Sample Data Maintenance

The Healthcare Industry Framework comes with preconfigured sample data instances for commonly referenced objects. The sample data in the framework is used in the solution layers (Apeals & Grievances Manager, Authorization Management, New Member Enrollment) as well as other healthcare frameworks (Customer Process Manager for Healthcare, Claims Automation Suite, Sales Process Manager, and Care Management Workflow), The sample data model can also be used to quickly develop proof of concept demonstrations without having to configure SQL / Oracle / DB2 queries to external databases. Instances for the following data classes are included: Member Provider Policy Claim Authorization Employer Group Plan Benefits Company
The PegaHC-Maintenance-Work workpool in the Framework also includes workflows for maintaining and creating the sample data instances for the objects mentioned above. . The Search Object Model processing option is available from the Run > Process menu option of the Developer portal. (Figure 2-21).
2-47
Figure 2-21. Search Object Model Menu Option
2-48
PegaHC-Data-Party-Member (Sample Members)

Figure 2-22 and Figure 2-23 show the Member maintenance workflow options.
Figure 2-22. Member Search
Figure 2-23. Member Data Update
2-49
Key Rules for Member Maintenance

Figure 2-24 shows the key workflow rules used in the member maintenance processes.
Rule Name
Rule Type
Function
Class: PegaHC-Maintenance-Work MemberSearch MemberNew MemberMaintenance Flow Flow Flow Launches the member search workflow Launches new member data instance workflow Launches member maintenance workflow
Figure 2-24. Member Maintenance Workflow Rules
2-50
PegaHC-Data-Party-Provider (Sample Providers)

Figure 2-25 and Figure 2-26 show the Provider Maintenance workflow options.
Figure 2-25. Provider Search
Figure 2-26. Provider Data Update
2-51
Key Rules for Provider Maintenance

Figure 2-27 shows the workflow rules used in the provider maintenance process.
Rule Name
Rule Type
Function
Class: PegaHC-Maintenance-Work ProviderSearch ProviderNew ProviderMaintenance Flow Flow Flow Launches the provider search workflow Launches the new provider data instance creation workflow Launches the provider maintenance workflow
Figure 2-27. Provider Maintenance Workflow Rules
2-52
PegaHC-Data-Policy (Sample Policies)

Figure 2-28 and Figure 2-29 show the Policy Maintenance workflow options.
Figure 2-28. Policy Search
Figure 2-29. Policy Data Update
2-53
Key Rules for Policy Maintenance

Figure 2-30 shows the workflow rules used in the policy maintenance .
Rule Name
Rule Type
Function
Class: PegaHC-Maintenance-Work PolicySearch PolicyNew PolicyMaintenance Flow Flow Flow Launches the search screen workflow Launches the new policy data instance creation workflow Launches the policy maintenance workflow
Figure 2-30. Policy Maintenance Workflow Rules
2-54
PegaHC-Data-Claim (Sample Claims)

Figure 2-31 and Figure 2-32 show the ClaimSearch workflow options.
Figure 2-31. Claim Search
Figure 2-32. Claim Header Data
2-55
Key Rules for Claim Maintenance

Figure 2-33 shows the workflow rules used in the claim maintenance process.
Rule Name
Rule Type
Function
Class: PegaHC-Maintenance-Work ClaimSearch NewClaims ClaimMaintenance Flow Flow Flow Launches the claim search workflow Launches the new claim data instance creation workflow Launches the Claim Maintenance worklfow
Figure 2-33. Claim Maintenance Workflow Rules
2-56
PegaHC-Data-Authorization (Sample Authorizations)

Figure 2-34 and Figure 2-35 show the Authorization Maintenance workflow options.
Figure 2-34. Authorization Search
Figure 2-35. Authorization Data
2-57
Key Rules for Authorization Maintenance

Figure 2-36 shows the workflow rules used in the authorization maintenance .
Rule Name
Rule Type
Function
Class: PegaHC-Maintenance-Work AuthSearch AuthNew AuthMaintenance Flow Flow Flow Launches the auth search workflow Launches the new auth data instance creation workflow Launches the auth maintenance workflow
Figure 2-36. Authorization Maintenance Workflow Rules
PegaHC-NME-Data-EmployerGroup (Sample Employer Groups)

Figure 2-37 and Figure 2-38 show the Employer Group Maintenance workflow options.
2-58
Figure 2-37. Employer Group Search
Figure 2-38. Employer Group Data Updates
2-59
Key Rules for Employer Group Maintenance

Figure 2-39 shows the workflow rules used in the Employer Group
maintenance process. Rule Name Rule Type Function
Class: PegaHC-Maintenance-Work EmployerGroupSearch EmployerGroupNew EmployerGroupMaintenance Flow Flow Flow Launches the search workflow Launches the new employer group data instance creation workflow Launches the employer group maintenance workflow
Figure 2-39. Authorization Maintenance Workflow Rules
PegaHC-Data-Product (Sample Plan / Benefits)

Figure 2-28 and Figure 2-29 show the Plan Benefit (Product) Maintenance workflow options.
Figure 2-40. Product Search
Figure 2-41. Product Data Update (Product Information Tab)
2-60
Figure 2-42. Product Data Update (Benefits Tab)
Key Rules for Plan / Benefit Maintenance

Figure 2-30 shows the workflow rules used in the plan benefit maintenance process.
Rule Name
Rule Type
Function
Class: PegaHC-Maintenance-Work PlanBenefitSearch ProductNew Flow Flow Launches the search workflow Launches the workflow for creation of new plan benefit instances Launches the plan / benefits maintenance woirkflow
PlanBenefitsMaintenance
Flow
Figure 2-43. Plan Benefit Maintenance Workflow Rules
2-61
PegaHC-Data-Company (Sample Companies)

Figure 2-28 and Figure 2-29 show the Company Maintenance workflow options.
Figure 2-44. Company Search
Figure 2-45. Company Data Update
2-62
Key Rules for Company Maintenance

Figure 2-46 shows the workflow rules used in the company maintenance process.
Rule Name
Rule Type
Function
Class: PegaHC-Maintenance-Work CompanySearch CompanyNew CompanyMaintenance Flow Flow Flow Launches the search workflow Launches the workflow for creation of new company data instances Launches the company data maintenance workflow
Figure 2-46. Company Maintenance Workflow Rules
2-63
Industry Code Sets Search and Maintenance

The Healthcare Industry Framework comes with preconfigured sample database tables for the following code sets: CPT (Current Procedure Terminology) - Procedure codes used in claims HCPCS (Healthcare Procedure Code System) - Another type of Procedure Codes used in claims ICD9 (International Classification of Diseases) - Diagnosis Codes NDC (National Drug Codes) - Drug Codes used in pharmacy claims GCN (Generic Code Number) Drug Codes used in pharmacy claims
NOTE: The sample code set tables packaged with the framework are for demo purposes only. Use of the CPT code sets in production require subscription license from the American Medical Association. Extend / substitute these tables by the customers own data sets.
Search Code Sets

This functionality allows the user to search code sets and review code descriptions.
Figure 2-47. Access to Code Search Functionality
2-64
Figure 2-48. Select Code Type
Figure 2-49. Review Search Results (CPT)
Figure 2-50. Review Search Results (HCPCS)
2-65
Figure 2-51. Review Search Results (ICD9)
Figure 2-52. Review Search Results (NDC)
2-66
Figure 3-54: Review Search Results (GCN)
Manage Code Groups

This functionality allows the user to search code sets and create custom code groups that can be used in other processing rules. The Care Management Solution Framework uses this functionality to define custom code groups to search for in medical and pharmacy claims.
Figure 2-53. Access tp Manage Code Groups Functionality
2-67
Figure 2-54. Select Code Group
Figure 2-55. Add Codes to Code Group
2-68
HIPAA-Enabled Data Model Overview

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

The Healthcare Data Element Dictionary references the properties as they are related to the different HIPAA EDI transactions. The Healthcare Industry Framework organizes these properties in an Object-Oriented Class Structure as shown below to avoid redundancies (Figure 2-56).
Figure 2-56. Object-Oriented Class Structure
2-69
Each of the classes shown in Figure 2-57 contains specific properties that belong to the relevant data class. Figure 2-58 shows the properties in the Pega-Data-Party-Member class, and Figure 2-59 shows the properties in the Pega-Data-Claim class.
Figure 2-57. Properties of the PegaHC-Data-Party-Member Class
2-70
Figure 2-58. Properties of the PegaHC-Data-Claim Class
2-71
HIPAA-Complaint Property Values

Many of the properties included in the Healthcare Data Dictionary have standard listings of valid values associated with them. Most of these properties end with a Code in their name. The Data Model incorporates these listing as prompt lists on the Table Edit tab of the property rule. Figure 2-59 shows the prompt list for an individual relationship.
Figure 2-59. Individual Relationship Property for PegaHC-Data-Party-Member Class
2-72
Figure 2-60 shows the prompt list for the taxonomy code.
Figure 2-60. Taxonomy Code Property for PegaHC-Data-Party-Provider Class While most of the value listings are limited enough to be configured as Prompt Lists, others contain extensive listings. The properties with extensive listings are configured as their own Data Classes with a Data Table associated with them. This allows you to maintain the listing by exporting it to Excel. Figure 2-61 shows the Data Classes that have their own Data Table associated with them:
2-73
Figure 2-61. Data Classes with Data Tables Examples of instances of these data classes are shown for Claim Status Codes (Figure 2-62) and Claim Status Category Codes (Figure 2-63).
Figure 2-62. Claim Status Codes Instances
2-74
Figure 2-63. Claim Status Category Codes Instances
Chapter 3 The Authorization Management Solution

The Authorization Management Solution is a sample workflow that leverages key rules and features of the Framework and the underlying platform. The framework is configured so that you can easily extend it to create your own Authorization Management system. Authorization (also known as referral / precertification) management is an administrative process handled by the Case Management or Utilization Management departments at healthcare payer organizations (Health Plan). Healthcare service providers (mostly physicians) may be required to get a health plans 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 members plan type and benefit structure.
3-2
There are three types of requests for authorizations. The values for the Request Type Code mentioned below are standard HIPAA-mandated values from the X12 278 (Healthcare Service Review) transaction implementation guide. Admission Review (AR) a request for prior authorization for admission to a hospital or skilled nursing facility Specialty Care Review (SC) a request for authorization of a referral to a specialist Health Service Review (HS) a request for prior certification of a service (such as CT Scan)
The Authorization Management Solution
3-3
Understanding the Preconfigured Workflow

Figure 3-1 shows the key elements of the preconfigured process in the Framework. Each of the key components is briefly described below with a reference to the key rules and a recommendation for extension.
Figure 3-1. Key Elements of Preconfigured Process
3-4
HIPAA EDI Exchange

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

Figure 3-2 shows the architecture of a 278 EDI exchange.
Figure 3-2. EDI Exchange Architecture
EDI Validation
The X12 EDI exchange requires six validation levels to be compliant with the HIPAA Standard. It is assumed that these validations are performed by the Payers EDI Gateway and are beyond the scope of this Framework.
3-5
X12 278 Integration

In production, the EDI message is likely to be integrated with Process Commander using one of the service and listener rules such as MQ, File, and SOAP. Once the X12 278 file is made available to Process Commander, the 278 message segments are parsed and the data in the segments is mapped to the X12 properties on the clipboard. The X12 segments and properties are then mapped to the business-specific properties belonging to the authorization request work object. For purposes of demonstration, testing, and showing the processes of parsing and work object creation the Framework includes a sample 278 transaction with 31 separate authorization request messages in one batch file. The batch file is hard-coded in the Java step of the ParseRequestTestData activity in the PegaHC-X12-Data-N278-Transaction class (Figure 3-3).
Figure 3-3. ParseRequestTestData Activity
3-6
Figure 3-4 shows the quick-launch hyperlink that is included on the UM Case Manager portal. Use this link to launch the activity and thereby the X12 parsing process.
Figure 3-4. Quick Launch Hyperlink The Framework leverages the generic X12 parsing configuration of the underlying Healthcare Industry Framework (PegaHC), described in Chapter 4, X12 Message Processing. Once the file is parsed, the process returns a Statistics screen that displays some metrics of the X12 transaction and indicates whether any errors were encountered during the parsing.
Extension Tip: The error trapping and debugging process can be

extended so system architects or system administrators can get additional information about the segments in error. The next key step in the process is to map the X12 segments and properties to the business-specific properties on the work object. This is done in the
3-7
ProcessTransaction activity. The mapping involves properties associated with the overall request and the service (such as request type, requested urgency, service type, procedure, and diagnoses codes) as well as specific properties associated with the parties (referring service providers, subscriber, and if different than the member).
Extension Tip: Mapping to the work object properties is limited to the

commonly requested service types (such as specialty care referral, admission request, and healthcare service review). Mapping can be extended to include additional parsing and mapping of specific services requests as described in the 278 Implementation Guide (such as home health care service, home oxygen therapy, and spinal manipulation service). The individual authorization request messages of the batch transaction are processed against the business validation rules configured in the workflow (described later) and the resulting status (certified, denied, pending) is assembled in the 278 Response Transaction along with original request message. The Response transaction is written to a Temp folder on the server (Figure 3-5).
Figure 3-5. Output File Location
3-8
In production, the outbound response transaction process is similar to the inbound process using one of the service rules.
Key Rules for X12 278 Integration

Figure 3-6 shows the activities that are used for the X12 278 integration.
Rule Name
Class: PegaHC-X12-DataX12ParseMessageStart X12ParseMessageType X12WriteMessage
Function
Starts the processing of an X12 file Determines the message type Writes an outbound X12 message to a file
Class: PegaHC-X12-Data-N278 X12ParseMessage CreatePegaHCData Parses and maps the 278 message into X12 segments and properties on an X12 page on the clipboard Sets up the 278 Response with initial segments. Starts the processing of each transaction Maps data from AuthorizationRequest work object to 278 Response page after work object has been processed Creates the 278 Response page and sets it up with initial segments Defined in the PegaHCAUTH RuleSet, creates an AuthorizationRequest work object, executes the flow defined for it, and updates the 278 Response with the results Assembles the data on the 278 Response page into an X12 formatted message
MapToResponse MoveDataToResponse ProcessAuthorization
X12GenerateResponse
Class: PegaHC-X12-Data-N278-Transaction ParseRequestTestData Launches the parsing of the test file
3-9
Rule Name
ProcessTransaction MoveDataToResponse
Function
Maps the Transaction X12 segments and properties to the Authorization Data object and to the 278 Response page Moves transaction segments to 278 Response page
Class: PegaHC-X12-Data-N278-Loop2000EServiceProviderLevel MapToAuthorization MoveDataToResponse Maps the Service Provider X12 segments and properties to the Authorization Data object and to 278 Response page 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 Moves Service Line segments to 278 Response page
MoveDataToResponse
Figure 3-6. X12 278 Integration Activity Rules
3-10
Manual Request Generation

Although the Web Service Portal and X12 278 EDI exchange are the two most common ways for submitting an authorization request to the payer organization, a Process Commander harness also can be used to manually create and submit a transaction. The Utilization (Case) Management department may have users creating requests manually from faxed transactions or requests taken by telephone, or they can be generated by customer service (member and/or provider) applications. Figure 3-7 shows the link to launch New Authorization Request from the UM Case Manager Portal. Additionally, the Foundation (PegaHC) layer (PegaHC) of the framework provides pre-configured sample data instances for authorizations that can be used to demonstrate manual auth processing.
Figure 3-7. New Auth Request Link on UM Case Manager Portal To create a New Authorization Request, click the New Auth Request link. The following series of screens are displayed (Figure 3-8 to Figure 3-12).
3-11
Figure 3-8. New Auth Request Enter IDs
Figure 3-9. New Auth Request Select Policy
3-12
Figure 3-10. New Auth Request Enter Auth Info
Figure 3-11. New Auth Request Review Auth Request Info (Before Processing)
3-13
Figure 3-12. New Auth Request Review Auth Request (After Processing)
3-14
Key Rules for the Manual Request Generation Process

Figure 3-13 lists the activity and harness rules that are used in the manual request generation process. Rule Name Rule Type Function
Class: PegaHC-AUTH-Work-AuthRequest NewAuthRequest EnterAuthRequest EnterIDs Flow Flow Flow Action Initiates the new authorization request manual process Manages entry of the new authorization request manual process Allows user to enter Member, Requesting, & Service Provider IDs Allows user to select a policy for the member Allows user to enter authorization information Allows user to review entered authorization information Manages the new authorization request manual process Saves the authorization data instance after processing
SelectPolicy EnterAuthInfo ReviewAuthData
Flow Action Flow Action Flow Action
NewAuthRequest SaveAuthData
Activity Activity
Class: PegaHC-Data-Authorization AuthSearch GetAuthList DisplaySampleAuth AuthNew Activity Activity Activity Activity Launches the authorization search process Gets the list of authorizations based on search parameters Displays the sample authorization Creates a new authorization
3-15
Rule Name SaveAuthAsWorkItem AuthSearch AuthDisplay
Rule Type Activity Harness Harness
Function Saves the sample authorization as a work item Displays the Authorization Search screen Displays the Authorization Display screen
Figure 3-13. Manual Request Generation Rules
3-16
Authorization Request Processing

All authorization request transactions submitted create a work object and are processed as shown in the ProcessAuthorizationRequest workflow in the PegaHC-AUTH-Work-AuthRequest class (Figure 3-14).
Figure 3-14. Process Authorization Request Workflow Figure 3-14 shows that the submitted transaction follows the straight through processing path and is validated against business validation rules to determine if it can be automatically approved or denied. The Framework includes some examples of business rule validations. Some of these validations are performed procedurally while others are done declaratively (based on the relationships among data items).
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.
3-18
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 payers 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 PegaHCData-Party-Member class. See Chapter 2, What is Already Set Up for the complete list of sample Member Data. Figure 3-15 shows the ValidateMember workflow which includes a process to search for the member by ID and then by a combination of last name, first name, and date of birth.
3-19
Figure 3-15. ValidateMember Flow
3-20
The following validations (Figure 3-16) are performed in the ValidateMember workflow.
Validation Patient Not Found Patient Not Eligible
Reject Reason Code 77 95
Figure 3-16: Member Validations The Framework validates the member if the member is active on the requested service date on the authorization by comparing the service date to effective and term dates on the member data.
Key Rules for the Member Validation Process

Figure 3-17 shows the rules that are used in the member validation process. Rule Name Rule Type Function
Class: PegaHC-AUTH-Work-AuthRequest ValidateMember GetMemberDataByID GetMemberDataByOther MemberNotFound Flow Activity Activity When Launches the member validation process Searches for the member by ID Searches for the member by name and DOB Checks to see if a member record was found Checks to see if the member is active on the service date
MemberIneligibleOnServiceDate Figure 3-17. Member Validation Rules
When
3-21
Extension Tip: The current workflow for searching and validating

members is a placeholder. In production, the integration with the payers 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 PegaHCData-Party-Provider class. See Chapter 2, What is Already Set Up for the complete list of sample Provider Data. Figure 3-18 shows the ValidateReferringProvider workflow that includes a process to search for the referring provider by ID.
3-22
Figure 3-18. ValidateReferringProvider Flow The following validations are performed in the ValidateReferringProvider workflow.
Validation
Provider Not On File Provider is not a Primary Care Physician
Reject Reason Code

51 49
The Framework validates the Primary Care Physician (PCP) only when the members plan type is HMO. The requesting provider ID is matched against the PCP ID on the member data retrieved in the earlier process.
3-23
Key Rules for the Referring Provider Validation Process

Figure 3-19 shows the rules that are used in the referring provider validation process. Rule Name Rule Type Function
Class: PegaHC-AUTH-Work-AuthRequest ValidateReferringProvider GetReferringProviderDataByID ReferringProviderNotFound Flow Activity When Launches the provider validation process Searches for the provider by ID Checks to see if a referring provider record was found Checks to see if the referring provider is a PCP for the member
ReferringProviderNotPCP
When
Figure 3-19. Referring Provider Validation Rules
Extension Tip: The current workflow for searching and validating

providers is a placeholder. In production, the integration with the payers legacy data will involve one of the other service and / or connector rules. The Framework assumes a single match against the searched data instance. In production, the workflow should be updated to accommodate situations when multiple matching records are found.
Duplicate Request Validation

The Framework includes a process to validate for potential duplicate requests. The validation is performed against existing Authorization Requests (instances of PegaHC-AUTHWork-AuthRequest). Figure 3-20 shows the DuplicateCheck workflow that includes a process to search for potential duplicate records with previously created work objects.
3-24
Figure 3-20. DuplicateCheck Flow Comparison of the following data elements determines if this is a duplicate request: Request Type Requesting Provider ID Member ID Service Type Service Date Request Status (of Pending) An item match is only considered if all of the data elements listed above are the same as the current request. If a single match is found to all of the data elements listed above, the request transaction is denied, and the following data elements are set: Certification Action Code = A3 (Not Certified) Reject Reason Code = 91 (Duplicate Service)
3-25
Key Rules for the Duplicate Request Validation Process

Figure 3-21 shows the rules that are used in the duplicate request validation process. Rule Name Rule Type Function
Class: PegaHC-AUTH-Work-AuthRequest DuplicateCheck LookupDuplicate Flow Activity Launches the duplicate request validation process Performs matching for potential duplicates
Figure 3-21. Referring Provider Validation Rules
3-26
Declarative Validations
The Framework includes examples of declarative validation rules for the specific requested services. These types of validations are intended to automatically approve or deny specific service requests and achieve straight through processing where possible. These validations reduce the number of requests that need to be processed manually. Extension Tip: Although the framework includes only a few examples of these types of validations, the declarative network described below can easily be extended to include other service types and increase the rate of straight through processing.
Key Rules for the Declarative Process

Declarative rules provide a way for you to set or restrict property values, dynamically retrieve the necessary data, and automate the decision of when to perform a process. In the Authorization Management framework, the main flow called ProcessAuthorizationRequest uses declarative rules to reach an automated decision. The process begins by validating the member, and referring provider, and checking for duplicates. If the authorization request passes the member and provider validity screening and the procedural checks for duplicates, it begins the declarative processing by calling the decision tree AuthorizationDecision in the PegaHC-Data-Service class. Figure 3-22 shows the decision tree for AuthorizationDecision.
3-27
Figure 3-22. AuthorizationDecision Decision Tree This decision tree establishes a value for the AuthorizationDecision property (which contains the text description of the decision) and the ActionCode property (which contains the X12 standard code for the decision). The decision tree checks the values of the AuthorizationStatus property for each of the Procedure Lines and sets the overall decision for the authorization. The AuthorizationStatus values for the Procedure Line are calculated using a declare expression in the PegaHC-AUTH-Work-AuthRequest class. This expression uses the decision tree called AuthorizationDecision in the PegaHC-Data-Service class and possibly one of the following decision trees to establish a value: CardiacRehabDecision ChiroServicesDecision PodiatryServicesDecision
3-28
Figure 3-23 shows the decision tree for the CardiacRehabDecision. This decision tree evaluates the treatment type of the procedure, the diagnosis codes and dates, and the number of requested units for the service. Similar validations for other specific service requests may include evaluating other parameters of the request (such as providers specialty, members age, members plan type).
Figure 3-23. Cardiac Rehab Decision Tree
3-29
The decision tree rules used in this process uses Function Alias rules that allow the system to perform more complicated evaluations while keeping the decision tree rules understandable for a business user. These rules are: DecisionIsInProcedureList (in the PegaHC-Data-Authorization class) DiagnosisInRangeExists (in the PegaHC-Data-Service class) DiagnosisInRangeAndDate (in the PegaHC-Data-Service class)
The Treatment type places ranges of procedures into categories, and it is calculated by a declare expression in the PegaHC-AUTH-Work-AuthRequest class. The declare expression uses a decision table called Treatment in the PegaHC-Data-Service class which looks at the Procedure Code and Treatment Type and then places a procedure into a Treatment category. Figure 3-24 shows the decision table called Treatment.
Figure 3-24. Decision Table for Treatment
3-30
Declarative Validations for Non-Covered Experimental Treatments

Certain services are considered experimental treatments. The requests for these types of services are considered non-covered and are denied appropriately. Figure 3-25 lists the treatments and service codes. If any one of the service codes match, the service is denied.
Treatment Thermography Dynamic Infra-red perfusion Imaging Surface Scanning and EMG Spinal Manipulation under Anesthesia Figure 3-25. Non-Covered Experimental Treatments
Service Codes 93740, 93760, 93762 C9723 95860-872, S3900 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.
3-31
Declarative Validations for Cosmetic Surgery

Figure 3-26 lists the service codes for cosmetic surgery. If any one of the service codes match, the service is denied.
Treatment Cosmetic Surgery
Service Codes 11920-22, 15775-76, 15781, 15788-93, 15828-29, 15831, 19140, 19316, 19318, 19325, 19328, 19330, 19355, 19396, 30400-50
Figure 3-26. Cosmetic Surgery Service Codes 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 = 88 (Non-covered Service)
3-32
Declarative Validations for Services Not Requiring a Referral

Figure 3-27 lists the services not requiring a referral. These are identified by Service Type Codes or Services Codes.
Service
Service Type Code 4 5
Service Codes
Diagnostic X-Ray Diagnostic Lab EKG
93000, 93005, 93010, 93040-42, 93224-27, 93230-37, 93268, 93270-72 93015-18 93303-04, 93307-08, 93312-18, 93320-21, 93325, 93350 D7870
Cardiac Stress Test Echocardiogram
Joint Aspiration
Figure 3-27. Services Not Requiring a Referral When any of the services above are encountered, they are denied and the following properties are set on the Response Transaction: Certification Action Code = No Authorization Required
3-33
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
3-34
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).
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.
3-36
Manual Processing
If the request does not meet any of the auto-denial or auto-approval validations described in the declarative processing section, it is pended for manual processing (Pending-UMReview), and the assignment is transferred to the ServiceReview workbasket.
Extension: Although the Framework includes only a generic workbasket

for all pending requests, additional routing can easily be created based on key parameters of the request.
Workflow Attributes
Figure 3-28 shows the key attributes of the workflows. Attribute Application Name Unit of Work Relevant Org Hierarchy Description Healthcare Payer Authorization Management System Process Authorization Request Org: MyHealthPlan Div: Utilization Management Unit: Utilization Management Work Group Workbaskets ServiceReview ServiceReview@MyHealthPlan ProviderFeedbackRequest@MyHealthPlan MDReview@MyHealthPlan Class Group Parties PegaHC-AUTH-Work Referring Provider (PegaHC-Data-Party-Provider) Service Provider PegaHC-Data-Party-Provider) Member (PegaHC-Data-Party-Member)
3-37
Attribute Access Groups
Description 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
3-38
Attribute Work Object Statuses
Description New Pending-UMReview Pending-MDReview Pending-ProviderCommunication Open-AdditionalInfoRequest Resolved-Approved Resolved-PartiallyApproved Resolved-Denied Resolved-NoAction Resolved-Duplicate
Figure 3-28. Key Workflow Attributes
3-39
Role-Privilege Matrix
Figure 3-29 shows the privileges and roles predefined in the framework. Roles UMCoordinator CaseManager X X X X X MedicalDirector
Privileges ActionComunicateDecisionToProvider ActionProcessAuthorization ActionRequestAdditonalInformation ActionTransferToManager ActionTransferToMedicalDirector Figure 3-29. Privileges and Roles X X X X
Processing Flow Actions

Based on the privileges listed in Role and Privilege matrix, Figure 3-30 shows the options (flow actions) available to users.
3-40
Figure 3-30. Processing Option Choices for Users
3-41
Process Authorization
Figure 3-31 shows the options that allow users to process the request and manually set the disposition at the authorization header level as well as at the service line level. Users can also document the utilization management guideline or medical policy information that was referenced in determining the decision.
Figure 3-31. Authorization Disposition Options
Transfer to Manager or to Medical Director

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

Once the request is Approved or Denied, users are presented with a screen to communicate the information to the referring provider. The referring provider information is presented for quick reference (Figure 3-33).
Figure 3-33. Communicate Decision to Provider
Extension Tip: This flow action is a place holder for additional detailed
processing as per the business requirements. The process can involve integrating with the phone switch for outbound calling and / or linking to correspondence functions to generate correspondence of the final disposition.
Work Urgency Points Matrix

The value of property .pyUrgencyWorkAdjust is set to the value in a decision table in a DeclareExpressions Rule by the same name (Figure 3-34).
Figure 3-34. Urgency Decision Table
3-43
Service Level Rules

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

The default service level rule is called AuthRequest and is set in the model (pyDefault) on the work object (Figure 3-35).
Figure 3-35. Default Service Level Rule The default service level rule is Circumstanced based on the value of the RequestedUrgency (U = urgent request, 03 = emergency request). Figure 3-36 shows the Circumstance set to .RequestedUrgency=U in the top right of the form.
3-44
Figure 3-36. Service Level Rule Circumstance set to .ReguestedUrgency=U Figure 3-37 shows the Circumstance set to .RequestedUrgency=03
Figure 3-37. Service Level Rule Circumstance set to .ReguestedUrgency=03 The goal and deadline times are different and reflect the urgency (Figure 3-38). The escalation events upon expiration of the goal and deadline time are the same for all three service levels.
3-45
Requested Urgency Routine Urgent Emergency
Goal Time 3 Days 12 Hours 6 Hours
Deadline Time 5 Days 1 Day 12 Hours
Figure 3-38. Goal and Deadline Times
Escalation Activities
Goal Time: Transfer to Manager Deadline Time: Notify Manager by Email
Service Level: MedicalInfoRequest

The service level rule called MedicalInfoRequest is applied to the assignment when it is open because the provider requested additional information.
Figure 3-39. Service Level Rule
3-46
Correspondence Rules
The following correspondence rules in the PegaHC-AUTH-Work class are used to produce the request letter (Figure 3-40). Name Correspondence Rules RequestAdditionalInformation Mail Sent to request additional information from the requesting provider to support the requested service authorization Sent to inform requestor that the request was rejected because additional information was not received in the specified time frame Sent to notify the manager that the Request has past the Deadline time set on the SLA Type Purpose
RejectionNotice
Mail
SendEmailToManagerOnDeadline
Email
Fragment Rules Logo Stylesheet HeaderMember Mail Mail Mail Sample health plan logo to be inserted in correspondence Used for formatting the HTML correspondence Header segment of the correspondence that contains the member name and address Header segment of the correspondence that contains the requesting providers name and address Section that contains the authorization request number, request type, patient name, and received date Closing paragraph that contains the contact information, operator name, and designation
HeaderRequester
Mail
AuthReferenceInformation
Mail
Footer
Mail
Figure 3-40. Authorization Management Correspondence and Fragment Rules
3-47
The Correspondence Template for requesting additional information creates this letter (Figure 3-41).
Figure 3-41. Correspondence Request
3-48
Reports
The framework includes two inventory reports that are available from the dashboard.
Open Authorizations by Request Type and Status

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

The report shows all Requests (by type and status) that have been Resolved in the past 90 days (Figure 3-43).
Figure 3-43. Resolved Authorizations by Type
3-50
Drill-Down Details
Users can drill down from either report to see the following information (Figure 3-44).
Figure 3-44. Drill-Down Information
3-51
Hover Details
Users can hover over the Auth Number and see detail information about the authorization (Figure 3-45).
Figure 3-45. Hover Detail Information
Chapter 4 X12 Message Processing

The Accredited Standards Committee (ASC) X12 message is used to transfer data across and between industries. The Healthcare Industry Framework can recognize, accept, and parse messages that comply with the X12 standard. This section provides an overview of an X12 message and how inbound and outbound processing works in the Healthcare Industry Framework. The X12 standards provide the syntax and control structures that allow data elements, segments, and transaction sets to be defined. Figure 4-1 shows the overall structure of X12 data.
4-2
Figure 4-1. Format of an X12 Interchange
ISA*00* *00* *ZZ*SUBMITTERS ID *ZZ*RECEIVERS ID *050811*0800*U*00401*000000100*0*P*:~ GS*HI*SENDER CODE*RECEIVER CODE*20050811*0802*2781001*X*004010X094A1~ ST*278*1001~ BHT*0078*13*A20050810001*20050810*0801~ HL*1**20*1~ NM1*X3*2*MY HEALTHPLAN*****PI*MYHP~ HL*2*1*21*1~ NM1*1P*1*DOE*JOHN****46*NEW1~ REF*ZH*NEW1~ N3*125 MILL ST~ N4*BELMONT*MA*02478~ PER*IC*CONTACT PERSON*TE*8005551212*FX*8005551213~
Figure 4-2 shows a portion of an X12 message.

ISA*00* *00* *ZZ*SUBMITTERS ID *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~ *ZZ*RECEIVERS ID
X12 Message Processing
4-3
HL*2*1*21*1~ NM1*1P*1*DOE*JOHN****46*NEW1~ REF*ZH*NEW1~ N3*125 MILL ST~ N4*BELMONT*MA*02478~ PER*IC*CONTACT PERSON*TE*8005551212*FX*8005551213~
Figure 4-2. Portion of x12 Message Each line is a segment that starts off with a segment identifier and ends with a ~ . Each segment is made up of one or more delimited data elements. The most common delimiter used is the asterisk * and it is used in the example below. The example above is a part of a 278 transaction. In the example, the following line is an NM1 segment. NM1*X3*2*MY HEALTHPLAN*****PI*MYHP~ 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.
4-4
This segment contains the following data elements: *X3* Entity identifier code (X3=UMO) *2* Entity type qualifier (2=non-person entity, 1=person) *MY HEALTHPLAN* Last name or Organization name ***** 4 unused data elements *PI* Identification code qualifier (PI=Payer Identification) *MYHP* Identification code (UMO Identifier)
4-5
Mapping X12 Messages in Process Commander

The Healthcare Industry Framework contains all the classes and properties needed to support the data elements in the following transaction types: 837 Healthcare claim (professional, institutional, and dental) 834 Healthcare enrollment 278 Healthcare services review request and response 270 / 271 Healthcare eligibility request & response 276 / 277 Healthcare claim status request & response There is a class for each segment in the X12 standard and a property for each data element in the segment. These classes are common to all transaction types and can be used by each of them. In addition, a class exists for each transaction type (such as PegaHC-X12-Data-N278), which is built using the predefined classes as the inbound X12 message file is processed. The data in an X12 message is received by a Process Commander listener that maps the data to properties on the clipboard. An activity is called to determine the transaction type that is included in the functional group. A clipboard page is created that includes all the transactions that are found in the functional group. It is assumed that a functional group contains transactions of the same type. However, an X12 message file can contain more than one functional group, and each group can contain different transaction types. While unlikely, Process Commander can process an X12 message file containing multiple transaction types and can map them all to the clipboard. Process Commander maps the data in the message to the X12 clipboard page as follows for a 278 transaction: While maintaining the looping structure, a property of an associated class is created for each segment as embedded pages in the PegaHCX12-Data-N278 class. Properties are then created in each of these segment classes for each data element. These segment classes are defined in the PegaHC-X12-Data- class and are general for all message types. A class is created for each loop.
4-6
X12 Inbound Message Processing

The Rule-Service-File instance called X12file.X12.X12Inbound reads the X12 message input file and calls the activity X12ParseMessageStart to start the processing (Figure 4-3). Process Commander reads the X12 Message input file using this Rule-Service-File instance.
Figure 4-3. Rule-Service-File Rule X12File The X12ParseMessageStart activity includes Java that calls another activity, X12ParseMessageType. The X12ParseMessageType activity sets the type of the transactions that are in each functional group. It then calls the appropriate activity that handles the given message type by calling the X12ParseMessage activity defined in the appropriate class (such as PegaHC-X12-Data-N278).
4-7
The X12ParseMessage activity is composed of Java code that parses the message according to its message type (such as 278) to determine the segments and the context of where these segments lie within the message. With this information, the activity determines the classes that should be populated with the data and calls the appropriate Rule-Parse-Delimited rule for each segment. The Rule-Parse-Delimited rule parses the data and puts the data onto the clipboard. After the entire functional group has been processed, an instance of the X12 data object is created. The Java code used in the X12ParseMessage activity uses the syntax of a given message type, based on the segments used and the format of the transaction as defined in the associated EDI Implementation Guide. The code uses the following logic to parse the X12 message one segment at a time: Gather control information from the ISA, GS, and ST segments and determine the message type found in the GS functional group. 1. Keep track of the current loop identifier and monitor when it changes. The loop identifier is hard coded into the Java code based on the message type. With the 278 message type, the starting loop ID is HEADER, which switches to the second loop 2000A. The loop ID can change when any of the following is found.
HL segment identifying a new Hierarchical Level NM1 segment identifying a new sub-loop
2. For each segment, identify the ParseDelimited rule name and the class that should be populated with this segments data. Invoke the appropriate ParseDelimited rule that populates the clipboard with the appropriate class and properties. Refer to Adding Additional X12 Transactions in Chapter 6 for more information.
4-8
X12 Message Classes

Two types of classes exist to support processing X12 Messages. Generic classes that are common to all types of X12 messages. There is one class for each segment in the X12 standard. Specific classes for a given message type (such as 278). These are subclasses of the message type class (such as PegaHC-X12-Data-N278). These classes contain properties that are of the appropriate PegaHCX12-Data-segment class. Figure 4-4 shows the message class hierarchy.
Figure 4-4. Message Class Hierarchy
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. Figure 4-5 is a data element diagram taken from the X12 EDI standards documentation showing the data segments in the NM1 segment. The NM1 segment holds the individual or organization name. The first data element, NM101 Entity ID Code, identifies how this name will be used. For example, a value of X3 identifies this as the name of the UMO. The second data element, NM102 Entity Type Qualifier, determines if this name is for an individual or an organization. A value of 1 is a person and a value of 2 is a non-person.
Figure 4-5. Data Element Diagram for Messages The data element diagram shown in Figure 4-5 for the NM1 segment results in the creation of the following properties in the NM1_IndividualOrOrganizationalName class (Figure 4-6).
4-10
Figure 4-6. Properties Created
4-11
Example of 278 Message

Figure 4-7 shows an example of a 278 message that was read by the Rule-Service-File instance X12file.X12.X23inbound.
Figure 4-7. Example of 278 Message Figure 4-8 shows the clipboard page for the HealthServicesRequest (278 transaction type) with the embedded pages expanded to show the RequesterName. On the right, it also shows the properties for the ReceiverName.
4-12
Figure 4-8. Example of a Clipboard Message
4-13
X12 Activity Rules

The mapping of the X12 message into the X12 page on the clipboard is handled by activity rules. Figure 4-9 describes each of the activities used in mapping X12 messages.
Rule Name
Class: PegaHC-X12-DataX12ParseMessageStart
Function
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. This activity sets the message type and calls the X12ParseMessage activity in the appropriate class to process the message. Writes an outbound X12 message to a file in a temp folder on the server. This activity should be modified to customize output location.
X12ParseMessageType
X12WriteMessage
Class: PegaHC-X12-Data-N837 X12ParseMessage Parses and maps the 837 message into X12 segments and properties on an X12 page on the clipboard by invoking ParseDelimited-Rules. Each Parse-Delimited-Rule handles the parsing of the data elements in a segment. It creates an instance of the PegaHC-X12-Data-N837 data object and calls the following activity: CreateHCClaimWork to map data to claim work object CreateHCClaimWork X12GenerateProfessional Placeholder activity, implemented in Claims Layer (PegaHCCLM) Generates X12 message with single professional claim from X12 clipboard structure
4-14
Rule Name
X12GenerateInstitutional
Function
Generates X12 message with single institutional claim from X12 clipboard structure Parses and maps the 278 message into X12 segments and properties on an X12 page on the clipboard by invoking ParseDelimited-Rules. Each Parse-Delimited-Rule handles the parsing of the data elements in a segment. It creates an instance of the PegaHC-X12-Data-N278 data object and calls the following activities: CreatePegaHCData to map data to PegaHC Authorization Request and create Authorization Response. X12GenerateResponse to assemble 278 Response into X12 format. X12WriteMessage to write X12 message to file.
Class: PegaHC-X12-Data-N278 X12ParseMessage
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. Maps data from AuthorizationRequest work object to the 278 Response page after the work object has been processed. Creates the 278 Response page and sets it up with the ISA and GS segments. 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.
MapToResponse MoveDataToResponse ProcessAuthorization
4-15
Rule Name
X12GenerateResponse
Function
Assembles the data on the 278 Response page into an X12 formatted message. Launches the parsing of the test file Maps the Transaction X12 segments and properties to the Authorization Data object. Calls PegaHC-X12-Data-N278Transaction-MoveDataToResponse to move transaction segments to 278 Response page. Calls PegaHC-X12-DataN278-Loop2000EServiceProviderLevel-MapToAuthorization to handle mapping of ServiceProvider data. Moves appropriate transaction segments to 278 Response page. Maps the Service Provider X12 segments and properties to the Authorization Data object. Calls MoveDataToResponse to move Service Provider data to 278 Response page. Calls PegaHC-X12-Data-N278-Loop2000FServiceLevelMapToAuthorization to handle mapping of Service line data. Moves appropriate Service Provider segments to 278 Response page.
Class: PegaHC-X12-Data-N278-Transaction ParseRequestTestData ProcessTransaction
MoveDataToResponse
Class: PegaHC-X12-Data-N278-Loop2000EServiceProviderLevel MapToAuthorization
MoveDataToResponse
Class: PegaHC-X12-Data-N278-Loop2000FServiceProviderLevel MapToAuthorization Maps the Service Line X12 segments and properties to the Authorization Data object. Calls MoveDataToResponse to move Service Line data to 278 Response page. Calls ProcessAuthorization in the N278 class to continue with processing the newly created PegaHC-Data-Authorization data object. MoveDataToResponse Figure 4-9. X12 Activity Rules Moves appropriate Service Line segments to 278 Response page.
4-16
The following chart shows the activities and the flow between them (Figure 4-10).
Class
PegaHC-X12-Data
Activity
X12ParseMessageStart X12ParseMessageType
PegaHC-X12-Date-N278
X12ParseMessage CreatePegaHCData MoveDataToResponse
PegaHC-X12-Data-Transaction
ProcessTransaction MoveDataToResponse
PegaHC-X12-DataLoop2000EServiceProviderLevel PegaHC-X12-Data-Loop2000FServiceLevel
MapToAuthorization MoveDataToResponse MapToAuthorization MoveDataToResponse
PegaHC-X12-Data-N278 ProcessAuthorization MapToResponse X12GenerateResponse X12WriteMessage Figure 4-10. X12 Activities Working Together
4-17
X12 EDI Management

The Healthcare Industry Framework also contains preconfigured rules for managing the following two real-time X12 EDI messages: X12 270 / 271 Healthcare Eligibility Request & Response X12 276 / 277 Healthcare Claim Status Request & Response.
The sample implementations contain message intake and parsing rules, work object creation and mapping, sample business edits, and outbound response message generation. The framework also includes sample X12 files for 270 and 276 messages.
Healthcare Eligibility Request Message Processing

The framework provides preconfigured rules to process real-time 270 Eligibility Request messages. The X12 parsing rules are configured as per the X12 270 / 271 Healthcare Eligibility Request & Response Implementation Guide.and as such supports batch as well as real-time message processing. The sample scenarios included in the framework reflect a real-time processing situation with immediate response generated after processing the message. To reflect a real-time situation, the messages are limited to one benefit request per member (subscriber or patient). The key functionality includes: X12 270 Message Parsing as per the 270/271 Implementation Guide Eligibility Request Work Object Creation for every benefit request submitted in the transaction Validation of Information Source Level
4-18
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 predefined threshold for real-time processing (framework parameter is set at 25). If the validation fails, further processing of the message is skipped and an appropriate AAA Request Validation segment is included in this loop in the outbound 271 message. AAA01 = Y AAA03 = 04 AAA04 = C
Validation of Information Receiver Level o Check for Provider on File sample business validation rule that searches for the provider record based on the Information Receiver ID submitted on the 270. The validation fails if a matching provider record is not found in the sample database, If the validation fails, further processing of the message is skipped and an appropriate AAA Request Validation segment is included in this loop in the outbound 271 message. AAA01 = Y AAA03 = 51 AAA04 = C
4-19
Validation of Subscriber Level o Check for Subscriber on File sample business validation rule that searches for the subscriber record based on the Subscriber ID submitted on the 270. The validation fails if a matching subscriber record is not found in the sample database, If the validation fails, further processing of the message is skipped and an appropriate AAA Request Validation segment is included in this loop in the outbound 271 message. AAA01 = Y AAA03 = 75 AAA04 = C
Eligibility Benefit Request Processing o Check for Active Policy If the validation fails, an appropriate EB segment is returned in the 271 message EB*6**30~ EB01 = 6 (Inactive) EB03 = 30 (Health Benefit Plan Coverage) o Check Eligibility On Service Date The validation fails if the requested service date is outside the effective period on the active policy. If the validation fails, an appropriate EB segment is returned in the 271 message EB*I**30~ EB01 = I (Non Covered) EB03 = 30 (Health Benefit Plan Coverage)
4-20
Process Generic Eligibility Request - If a specific EQ segment is NOT submitted on the 270, a minimum eligibility information response is returned in the corresponding EB segment on the 271 response message. EB01 = 1 (Active) EB02 = Policy.BenefitCoverageLevelCode EB03 = 30 (Health Benefit Plan Coverage) EB05 = Policy.PlanCoverageDescription Example: EB*1*FAM*30* HMO1: $10 OV, $25 ER, $250 IP Copay, $5/$10/$15 Rx~ (when the policy is P-001)
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
4-21
EB08 = map value from BenefitPercent from the matching benefit string EB09 = map value from QuantityQualifier from the matching benefit string EB10 = map value from BenefitQuantity from the matching benefit string EB11 = map value from CertificationConditionIndicator from the matching benefit string EB12 = map value from InPlanNetworkIndicator from the matching benefit string X12 271 Message Generation - as per the 270/271 Implementation Guide
Figure 4-11 Menu Options for Processing Sample Eligibility Request Messages
4-22
Figure 4-12 Eligibility Request Message Processing Summary
Figure 4-13 Eligibility Request Work Object
4-23
Figure 4-14 270 271 Message Side-By-Side Comparison
Key Rules in X12 270-271 Message Processing

Rule Name Rule Type Function
Class: PegaHC-EDI-Work-EligibilityRequest ProcessX12N270 Process270Transaction ParseTransaction ValidateTransaction ValidateInformation Source ValidateInformation Receiver ValidateSubscriber ProcessEligibility Request SendResponse ParseMessage PrepareResponse Activity Collection Collection Collection Collection Main activity to launch 270 message processing Main collection rule for processing 270 message Parses 270 message and prepares 271 response Controls validation rules for various loops Controls validation of Information Source level
Collection Collection Collection
Controls validation of Information Receiver level Controls validation of Subscriber level Controls mapping to work object and processing of benefit request Controls 277 message generation and distribution Parses 270 message Prepares 271 message shell
Collection Activity Activity
4-24
Rule Name
CheckLimit CheckProviderOnFile CheckSubscriberOnFile MapMessageToWork item ProcessEligibility Generate271 SendMessage ReviewX12
Rule Type
Activity Activity Activity Activity Activity Activity Activity Activity
Function
Validates the number of requests in a transaction Looks up Provider based on ID submitted on 270 Looks up Subscriber based on ID submitted on 270 Maps 270 message to work object Initiates specific benefit request processing Generates 271 message Place holder for 271 message distribution Provides side by side comparison of 270 - 271
Healthcare Claim Status Request Message Processing

The framework provides preconfigured rules to process real-time 276 Claim Status Request messages. The X12 parsing rules are configured as per the X12 276 / 277 Healthcare Claim Status Request & Response Implementation Guide.and as such supports batch as well as real-time message processing. The sample scenarios included in the framework reflect a real-time processing situation with immediate response generated after processing the message. To reflect a real-time situation, the messages are limited to one claim status request per member (subscriber or patient). As per the X12 276/277 Implementation Guide specification, there is no validation performed at the various levels of the message loops. The key functionality includes: X12 276 Message Parsing as per the 276/277 Implementation Guide
4-25
Claim Status Request Work Object Creation for every claim submitted in the transaction Claim Retrieval sample business rules to retrieve claim from the sample database based on the Claim Identifiers submitted on the 276 message. If a matching claim is not found, an appropriate STC segment is returned on the outbound 277 message. If a matching claim is found, system returns the claim status information in the STC segment of the 277 message. X12 277 Message Generation - as per the 2760/277 Implementation Guide
Figure 4-15 Menu Options for Processing Sample Claim Status Request Messages
Figure 4-16 Claim Status Request Message Processing Summary
4-26
Figure 4-17 Claim Status Request Work Object
Figure 4-18 276 277 Message Side-By-Side Comparison
Key Rules in X12 276-277 Message Processing

Rule Name Rule Type Function
Class: PegaHC-EDI-Work-ClaimStatusRequest ProcessX12N276 Activity Main activity to launch processing of 276 message
4-27
Rule Name
Process276Transaction ParseTransaction ProcessClaimStatus Request SendResponse ParseMessage PrepareResponse MapMessageToWork Item SendMessage ReviewX12
Rule Type
Collection Collection Collection Collection Activity Activity Activity Activity Activity
Function
Main rule for processing 276 message Parse message & prepare 277 response Maps message to work object and processes claim lookup Generates 277 and sends message Parses 276 message Prepares 277 message shell Maps 276 message to work object Place holder to configure 277 message Provides side by side comparison of 276 and 277
Figure 4-19 Key Rules for Claim Status Request Message Processing
Chapter 5 The New Member Enrollment Solution

The New Member Enrollment Solution is a sample design model included in the Healthcare Industry Framework. This solution comes with examples of new member application submission and enrollment processing that leverage key rules and features of the Framework and its underlying platform (PegaRULES Process Commander). The New Member Enrollment Solution is also designed for extension. It can be rapidly integrated into a clients existing infrastructure, personalized to reflect a clients specific policies, and expanded to create a comprehensive enrollment management system. This solution can be deployed by itself or integrated with existing sales and group enrollment systems, such as Pegasystems Sales Process Manager, to facilitate desired automation in the sales and enrollment processes.
5-2
New Member Enrollment High Level Workflow

Figure 5-1 shows the Application Process Flow used by the solution to manage the three major steps in the enrollment process: 1. Intake Process that creates the enrollment application work item 2. Common Process that manages the steps to complete the enrollment application 3. Output Process that manages the processes that occur when the enrollment application work item is resolved. These processes are described in detail below.
Figure 5-1. Overall Member Enrollment Application Process
Extension Tip: The Framework provides examples of new membership

additions for new and existing group business. It can easily be extended to support membership changes for all types of business and new membership additions for individual business.
The New Member Enrollment Solution
5-3
Intake Process
Initiating the Enrollment Application Process
Enrollment applications can be originated by multiple users such as brokers, members, Plan Sponsors, and internal health plan representatives and submitted through multiple intake channels (such as web, fax, email, and phone). The Intake Process Flow (Figure 5-2) determines the source through which an application is originated and applies specific routing or processing rules based on that source and the level of application completion. The Framework routes completed applications received electronically to a general workbasket for underwriting approval and routes applications received via the Manual Input method directly to specific enrollment representatives using skills-based routing rules. Three sample intake methods (Manual Input, PDF Intake, and External Message Intake) are described below.
5-4
Figure 5-2. Application Intake Processes
Extension Tip: Routing logic can be personalized for unique business

criteria. Approval rules can be used to assess application completion, including adherence to eligibility requirements, thereby moving acceptable applications through to the output process. Use of approval rules can eliminate the review step and fully automate the procedure. Additional intake methods can easily be added to the solution. When received by the Framework, member enrollment applications can be scanned as images to initiate enrollment work items. The image ID number can be saved on the enrollment work item, or the image can be saved as an attachment and viewed with the PegaIMAGE Viewer, making the information available for use in the completing applications.
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 Frameworks web site. The Framework provides the example in which an enrollment support representative initiates the process by entering required group level information such as a group number, and the system creates an application work item based on the successful access to back-end legacy systems (Figure 5-3).
Figure 5-3. Find Employer Information The system drives the application completion process. Its first step is to confirm and bring back relevant employer group information. The system performs a look up of relevant internal and external data sources to verify the employer group number entered on the application. Typically the data source is a legacy membership system that maintains the most current group level data. Upon confirming the group, the system retrieves relevant group information such as plan availability and eligibility requirements that drive the ensuing enrollment process and screen selections. The look up and status update are handled with the Find Group Flow (Figure 5-4).
5-6
Figure 5-4. Find Employer Group 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 through the use of parse rules. Figure 5-5 shows an example of an XML Parse Rule.
Note: The New Member Enrollment Solution integrates seamlessly with

the Pegasystems Sales Process Manager Framework (SPM). SPM manages the sales and group enrollment processes for Healthcare s.
5-8
Figure 5-5. Parse Rule
Extension Tip: The XML parse rule can also be used to personalize
other integration methods such as MQ Series or SOAP that are easily deployed through Pegasystems pre-built services. The Frameworks folder capabilities can be used to track completed member applications against the total census if such capability is not present in the external systems.
5-9
Key Rules for the Intake Processing

Figure 5-6 shows the key rules that are used in the three intake processes. Rule Name Intake Process:
IsNewHire When True, if Is New Hire
Rule Type
Function
IsApplicationFromPDF IsApplicationFromImage IsApplicationFromMessage Common Process IsNewBusiness EnrollmentUnit UpdateWorkSLA New Hire Process FindEmployer PDF Intake Process NMEPFDIntake NMEEnrollmentFormTest ParsePDF
When When When
True, if is Application From PDF True, if is Application is from Image True, if is Application is from Message
When Ticket Activity
True, if is New Business Used to route back to enrollment unit Processes the work item SLA
Connector
Used to connect to an external data source to verify employer level data based on a group ID
File Listener eForm Map Parse Structured
Used to read in a file from a designated directory Used to map PDF form contents to clipboard properties 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
5-10
Rule Name EnrollmentApplication ParseEmail
Rule Type XML Parse Service EMail
Function Used to parse XML data to clipboard properties Creates the work item and reads the e-mail message to the clipboard
Figure 5-6. Key Rules for Intake Processing
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 (Figure 5-7). The work item is accessible to any operator who has access to the workbasket.
Figure 5-7. Route PDF to General Workbasket
5-12
The routing rule used in the External Message Intake method, routes the application work item to the specific individual the Plan Sponsor who is identified in the XML message that initiates the process (Figure 5-8). The work item then appears in the Plan Sponsors work list.
Figure 5-8. Route to Plan Sponsor indicated in the XML message
Extension Tip: Directed Web Access can be used to send a work item
assignment to external users. An email is sent with a secure link directly into the case to allow external input and processing.
5-13
Figure 5-9 describes the key assignment rules applied to work items created from the PDF and External Message Intake methods. Rule Name PDF Intake Routing: ToWorkBasket Router Routes the application work item to specified work basket Rule Type Function
External Message Intake Routing PrepareExternal ToAssignedOperator Activity Router Notifies Plan Sponsor about the creation of a new application work item Routes the application work item to specified operator indicated in the XML message
Figure 5-9. Key Assignment Rules
Common Process Workflow

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

For applications requiring manual data entry, the process is managed by he Application Flow (Figure 5-11) the first step of the Common Process. This flow intelligently manages the screens users see for data entry based on the information as it is submitted. In the solution example, data entry may be accomplished through as little as two screens for a single healthy individual without other insurance and enrolling in a plan that does not require a PCP. Or, the process can require as many as nine screens depending on the subscriber demographics and medical history. The system pre-populates data whenever possible based on the intake method and information originally supplied. The system employs security rules to determine which portions of the member enrollment application and what data to display to users. User roles define which users have rights to previously entered information. Security and user role rules are personalized for each client installation.
5-16
Figure 5-11. Application Data Entry Screen Flow
5-17
Figure 5-12 shows the browser-based user interface that users see when entering data through the browser. Fields with asterisks are required to drive the work through to completion. The system uses intent-led processing to guide users efficiently through the application process. For example, only if users select coverage for a spouse or children will the additional screens pertaining to spouse or children appear.
Figure 5-12. Application Data Entry Screen
Extension Tip: The New Member Enrollment Solution provides product

selection at the member level and can easily be extended to support consumer driven healthcare by supporting benefit selection at the rider level. Data properties are easily added, changed, or classified and can be standardized for specific sales types (individual, small group, large group, Medicare), geographic regions, employer groups, and so on.
5-18
Medical History
The New Member Enrollment Solution comes with a series of medical questions that are asked for each member identified on the member application. The response to these questions drives the need for further detailed questions that the system uses to evaluate member risk factors and determine an underwriting recommendation at the applicant level. Figure 5-13 shows the initial medical history screen. Figure 5-14 displays only if users have a positive response to a question asked on the first screen.
Figure 5-13. Medical History Questionnaire Step 1
Figure 5-14. Medical History Questionnaire Step 2
5-19
Medical Underwriting Risk Evaluation and Recommendation

The New Member Enrollment Solution calculates a risk factor for each individual on the enrollment application based on the responses to the medical questions above. An applicant underwriting recommendation is then determined based on the risk factor for each member on the application using a decision tree that evaluates the applicant risk factor and returns the underwriting recommendation. The Underwriter Recommendation Flow manages the process of risk evaluation and the underwriting recommendation (Figure 5-15).
5-20
Figure 5-15. Determining Risk and Underwriting Recommendation
5-21
The Decision Table Rule (UWRecommendation, Figure 5-16) is used to determine a members risk factor based the following questions: During the past 10 years has any proposed insured had any indication of, diagnosis of, or treatment for: The heart or circulatory system, including high blood pressure, high cholesterol, heart attack or murmur, heart valve disease, chest pain, or irregular heart beat? Was the onset of high blood pressure prior to age 25? Is the condition controlled?
Figure 5-16. Underwriting Risk Factor Decision Table Figure 5-17 shows the underwriting recommendation decision tree.
Figure 5-17. Underwriting Recommendation Decision Tree
5-22
Underwriting Risk Evaluation and Recommendation Rule Changes

The medical underwriting risk calculation and recommendation example in the New Member Enrollment Solution can be extended to include any number of questions and any combinations of responses. The calculation for the overall risk factor for the applicant can also be adjusted, and the decision tree that determines the final recommendation can be expanded to include other variables and additional recommendations. An example of a method to make such a change is outlined below. Business rules in the underwriting department change frequently based on regulatory environment changes and in reaction to the evaluation of historical data. In this example, an underwriting department has determined that it would like to include the use of tobacco when calculating the risk factor for a member that has a heart condition. Figure 5-18 shows the UWRecommendation Decision Table that can easily be modified by authorized users to include yes values in the tobacco use column and add the necessary rows to include all potential combinations of the medical questions used to determine a members risk factor. This type of change can be performed by business users including underwriters themselves and can be applied selectively for different business units or employer groups.
Figure 5-18. UW Risk Factor Decision Table After the Change
5-23
The Run Rule facility located at the top of the rule can be used to test the results of a rule change. Figure 5-19 shows this testing capability.
Figure 5-19. Testing Rule Changes
5-24
Figure 5-20 describes key rules related to the underwriting recommendation included in the Framework. Rule Name UWRecommendation Rule Type Flow Function Manages the overall process of risk evaluation and the underwriting recommendation Manages the process of getting the risk factor for each member Produces the application risk factor based on all the individual member risk factors Determines the UW Recommended action based on the risk factors such as Approve or Deny
UWRecommendation (member)
Flow
GetUnderwriterRecommendation Factors DetermineUWRecommendation
Activity Decision Tree
Figure 5-20. Key Rules for Risk Evaluation
New Member Enrollment Application Routing and Review

When data entry is complete, the enrollment application is assigned to specific users who can then review, modify, and submit the application for further processing. The solution provides different examples of how and where work items can be routed as outlined in Figure 5-21. Completed By Plan Sponsor Enrollment Support Rep Enrollment Rep Routed To Sales (Department) Enrollment Rep (Individual) Underwriter (Individual) Flow Rule Used Sales Review Route to Enrollment Route to Underwriting
Figure 5-21. Routing and Review
5-25
The example for the External Message Intake example process provided in the Framework involves submission and completion of an application by an external party such as a Plan Sponsor or Member. In this example, the application work item is routed to the sales work group for review using the SalesUnit flow rule. When sales users review the member application, the actions these users can take are managed by the flow actions shown in Figure 5-22.
Figure 5-22. Routing to Work Group The browser interface for the sales users is shown in Figure 5-23. Tabs are used to navigate and store all information collected in the work item, separated in to logical groups such as subscriber, spouse, children, other insurance, and medical history. When users select a tab, the system displays the collected information.
5-26
Figure 5-23. Browser Interface for Sales Users The history of what has happened to the work item, known as the audit trail, is also accessible to users reviewing and processing the enrollment work item. The audit trail shows which operators have worked on the work item, what actions were performed, and when the action was performed. The audit trail also logs when and what automatic processes were performed by the application (Figure 5-24). Work item history instances are stored as objects in classes derived from the History-Work- class.
5-27
Figure 5-24. Work Item History
Route to an Individual
The Manual and PDF Intake examples provided in the solution involve completion of an application by an internal party. In these examples, the Framework routes the application to the appropriate enrollment representative for review using the skill-based routing rule shown below in Figure 5-25.
5-28
Figure 5-25. Route To Enrollment Representative Based on Skill Level The Operator ID records contains the skills and the skill rating used by the To Skilled Operator Routing Rule (Figure 5-26).
Figure 5-26. Operator Record with Specific Skills
5-29
Key Rules for Routing to Individuals

Figure 5-27 describes key rules related to routing to individuals provided in the New Member Enrollment solution: Rule Name RouteToEnrollment Rule Type Flow Function Determine Enrollment Representative Skill level to be used in the ToSkilledOperator routing rule below Determines the skill required to complete the application Finds the operator with the best skill as defined by the decision tree above and routes the application
DetermineRequiredSkill
Decision Tree Router
ToSkilledOperator
Figure 5-27. Key Rules for Routing to Individuals
Routing Rule Change

If Enrollment Department Management wants to identify late enrollment applications and process them differently, they can easily change the Enrollment Routing Rule that all applications requesting effective dates in the past are routed to the Enrollment Managers workbasket for exception processing. The sample routing decision tree provided in the Framework uses the skill level of the Enrollment Representative, the primary language experience, and the requested effective date on the member application to route the application work item (Figure 5-28).
5-30
Figure 5-28. Solution Sample Decision Tree Determines Required for Routing To handle exception processing as outlined above, the Enrollment Manager can easily change the rules shown in Figure 5-29.
Figure 5-29. Solution Sample Decision Tree Updated To Route to Enrollment Manager
Note: The routing process can also be managed by modifying the skill
settings at the operator level.
Route to Underwriting
When enrollment representatives complete their portion of the enrollment application they submit the application to underwriting for review. The underwriter reviews medical history and eligibility qualifications as provided in the application. The application is routed to an underwriting representative for approval or denial based on the completion of medical history by using the rules below (Figure 5-30).
5-31
Figure 5-30. Route to Underwriting
5-32
Figure 5-31 shows a flow rule that defines the actions an underwriter user can take, such as approve, reject, or update the application.
Figure 5-31. Underwriting Unit Review and Actions
5-33
Key Rules for Application Routing and Review

Figure 5-32 lists the key rules provided to route and review member application work items. Rule Name Plan Sponsor to Sales ToWorkGroup Router Routes the application to the specified work group Rule Type Function
Enrollment Support Rep to Enrollment Rep DetermineRequiredSkill ToSkilledOperator Decision Tree Router Determines the skill required to complete the application Finds the operator with the best skill as defined by the decision tree above and routes the application
Enrollment Rep to Underwriting Rep DetermineUnderwriter ToAssignedOperator Decision Table Router Determines the individual underwriter to whom the application is routed Routes the application to the underwriter as determined by the decision table above
Figure 5-32. Key Rules for Application Routing and Review
5-34
Output Process
When the application work item is finalized, either through straight through processing or manually by a user, its status is moved to Resolved-Approved. When this occurs, the system automatically sends correspondence to relevant parties and updates external data sources with requisite application information. These steps are managed in the Output Process Flow (Figure 5-33).
Figure 5-33. Output Process Sends Correspondence and Update External Data Sources
Extension Tip: Any number of work parties can be notified automatically

using multiple methods including e-mail or letter at any time in any flow as shown in the Output Process Flow example above. Updates to external data sources can also be extended to include any number of required interfaces with external data sources.
5-35
Key Rules for Output Process

Figure 5-34 describes key rules related to the output process. Rule Name UpdateSPM ProcessOutput Rule Type Connector Connector Function Communicates member enrollment data to a group enrollment system such as SPM Communicates member enrollment data to external data sources such as legacy systems Sends a welcome letter to the new subscriber with the application is approved by underwriting
SendCorrespondence
Activity
Figure 5-34. Key Rules for Output Process
5-36
Service Level Rules

Service level rules let you measure and manage quality and also keep processes moving forward. The system measures quality by measuring and reporting performance related to goals and deadlines set for a work item or an assignment of a work item. The system manages quality and moves processes towards resolution through the notification and escalation of work based on reaching or exceeding goals and deadlines. The member enrollment process may have multiple steps and assignments to complete before the work is resolved. Through the use of SLAs, the system promotes straight through processing, speeds work to completion, draws attention to the process through escalation of aging work and notification to assignees or managers when work is nearing defined goals and deadlines. Each service level rule defines one or two time intervals, known as goals and deadlines, which indicate the expected or targeted turnaround time for each assignment, or time-to-resolve for the overall work object. For assignments, the service level rule is referenced in the Assignment Properties of the assignment task. For the overall work object, the service level rule is identified in the standard property.
The SLAs that come with the prepackaged in the New Member Enrollment Solution are described in the table below (Figure 5-35).
5-37
Service Level for Plan Sponsor Enrollment Support Enrollment Rep Enrollment Workbasket Underwriting Work Object Work Object
Service Level Name Application Application Enrollment PDFApplication Underwriting Overall Application**
Goal Time 1 day 1 day 2 days 1 day 1 day 4 days 1 day
Goal Escalation Notify Assignee Notify Assignee Notify Assignee Notify Manager Notify Assignee N/A* Notify Assignee
Deadline Time 3 days 3 days 4 days 3 days 2 days 9 days 3 days
Deadline Escalation Transfer to Manager Transfer to Manager Transfer to Manager Transfer to Manager Transfer to Manager N/A* Transfer to Manager
Figure 5-35. New Member Enrollment Solution SLAs * Work Object SLAs are used to track overall application performance for reporting purposes. ** Used as work object SLA during initial data entry The Underwriting Service Level Agreement rule (Figure 5-36) lets managers in charge of timelines for the work item assignments maintain the SLAs. In this example, the underwriter receives an e-mail notification when the goal time is reached.
5-38
Figure 5-36. Underwriting Assignment Service Level Agreement
5-39
Correspondence Rules
Figure 5-37 shows the sample correspondence rules in the PegaHCNMEWork-Enrollment-EnrollmentApp class used to produce e-mails and letters during the enrollment process. Name Correspondence Rules EnrollmentRequest Email Used to notify a Plan Sponsor when an enrollment application has been created and assigned to the Plan Sponsor Used to notify an internal user when an enrollment application has been created and assigned to them Sent to a new subscriber when underwriting has approved the new member application Type Purpose
NewEnrollmentApplication
Email
WelcomeLetter
Mail
Fragment Rules NMEWorkDetail NMEWorkLink Fragment Fragment Body of the e-mail sent to the plan sponsor Included in the body of the NMEWorkDetail fragment
Figure 5-37. New Member Enrollment Correspondence Rules
5-40
The correspondence template for sending a welcome letter creates the letter shown in Figure 5-38:
Figure 5-38. Welcome Letter
Extension Tip: In production, sample correspondence templates should

be replaced with client-specific materials. Correspondence templates and fragments and their reusability are described in Chapter 3.
5-41
Declarative Rule Examples

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

The Rule-Declare-Expression rule shown in (Figure 5-39) facilitates reporting on the Requested Effective Date property. It uses an exposed property in the standard Process Commander work database table and maps the requested effective date on the application to it.
Figure 5-39. Rule-Declare-Expression to Map Requested Effective Date
5-42
Figure 5-40 shows the Change Tracking tab of the rule above. Whenever the input changes in this case the requested effective date the property pyWorkListDate1 is updated.
Figure 5-40. Selecting the Event to Track The Rule-Declare-Expression rule shown in Figure 5-41 calculates the age of the subscriber based on two parameters: the requested effective date and the subscribers date of birth. This rule uses a Rule-Utility-Function rule to compute and store the age in a separate property called Age. Whenever a property used by this function is changed, the age is recalculated.
Figure 5-41. Calculating Age of Subscriber
5-43
Figure 5-42 shows some of the key declarative rules used in the New Member Enrollment Solution layer. Rule Name DetermineRequiredSkill .pyWorkListDate1 .pyWorkListText1 .pyWorkListText2 .pyWorkListText3 Rule Type Decision Tree Expression Expression Expression Expression Function Produces skill required to complete the task Maps requested effective date Maps subscriber name Maps subscriber SSN Determines if group is enrolled or new business Maps group name Produces underwriting recommendation based on overall risk factor Produces underwriter to route to based on medical history
.pyCustomerName DetermineUWRecommendation
Expression Decision Tree
DetermineUnderwriter Figure 5-42. Key Declarative Rules
Decision Table
5-44
Reporting
The New Member Enrollment Solution includes four sample enrollment reports, all of which are available from the sample Managers dashboard. All reports in this solution can be exported to Excel as well as customized and saved to a users favorites list using the customize criteria link located at the top left of the report.
New Business Pipeline

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

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

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

The report shows completion time for all resolved new hire member enrollment applications for existing group business (Figure 5-46).
Figure 5-46. New Hire Performance
Drill-Down Details
Users can drilldown on any of the reports to view a list of the enrollment applications included. Further drill-down is possible by clicking on and opening each individual work item (Figure 5-47).
Figure 5-47. Drill-Down Information
Extension Tip: The New Member Enrollment Solution layer comes with a
reporting wizard that can be used to create custom reports. Once created, these reports can be saved as favorites for access by an individual manager or for an entire access group. Figure 5-48 shows the report wizard.
5-47
Figure 5-48. Report Wizard
5-48
Additional Extension Ideas

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

The solution provides examples of how a Plan Sponsor logs into the system with an ID and password and enters member enrollment data. Through the use of Directed Web Access, the solution can be extended to include access to subscribers, members, and prospects to complete their own enrollment applications and member maintenance requests. Directed Web Access is especially useful for prospects who do not yet have passwords to use on an existing web site. When individuals complete their own application, the work item can be automatically routed to the Plan Sponsor for approval and submission to Sales.
Member Maintenance
Member maintenance activities, such as additions and deletions to family members on a contract, account for a large percentage of the work completed by an enrollment department of a Healthcare . The sample solution workflows can be copied and then modified to create member maintenance request workflows and work items that process requests to add/delete family members, change plan choices, update demographic information, and request new PCPs. Declarative rules determining the member maintenance request type can drive the relevant information assembly for both internal and external users.
5-49
Consumer Driven Healthcare

In the solutions enrolment examples, users make selections at the product level: one for both Medical and Dental insurance. The solution can easily be expanded to include additional products such as life or vision insurance. By expanding the product tables to include rider- and benefit -based selections, the solution can be used effectively to support consumer driven healthcare initiatives.
Medical Underwriting
The solution includes examples of how responses to medical questions can be used to support the calculation of risk factors and the creation of a recommended action for an underwriter to take when reviewing a new application. The solution can accommodate a variety of medical underwriting by expanding the medical questions, expanding the requested additional information for positive responses, and extending the business rules related to the risk and recommendation. The New Member Enrollment Solution can also be extended to handle and manage additional requests for information from the medical information bureau, requests for lab work or tests and requests for physician statements. These types of requests require the creation of child work items that are associated with the parent member enrollment work item.
Integration with Group Sales Process Management

If a Healthcare has a group sales and enrollment system in place to manage prospecting, quoting, group sales and group enrolment, the solution can be extended to receive and send enrollment data to the group enrollment system to support the group finalization and acceptance process.
5-50
Individual Rating
The New Member Enrollment Solution collects subscriber and dependent data used by the Healthcare Industry Framework in the creation of premium rates. The rating tables and the rating expressions can be built within the solution as they have been for Pegasystems Sales Process Manager which in turn can be used to create rates for individual applicants in real time as they complete their application forms.
Member Eligibility Management

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

Probationary periods related to dates of hire Dependent eligibility Other insurance and coordination of benefits
Extend Member Enrollment for Management

During the enrollment process, additional forms or information such as student certification or incapacitated dependent forms may need to accompany the member enrollment application. The solution can easily be extended to either maintain or leverage these forms.
Chapter 6 The Appeals and Grievances Solution

The Appeals and Grievance Management Solution is a sample workflow that leverages key rules and features of the Framework and the underlying platform. This solution manages complaints received from members and other interested parties (authorized representatives, providers, and third parties such as independent review entities). It provides the capability to create new cases (work objects) for two different types of complaints (appeals and grievances), and processes them through to resolution. In addition, resolved appeals can be reopened and reprocessed as necessary. The following sections describe this solutions 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.
6-2
Appeals Management Workflows Start-to-end process for managing appeals filed for denial of service or claim payment. Capabilities include the creation of an appeal case, capturing required information including information about the requestor party, appeal level, appeal category, service and or claim information, assigning an owner and standard or expedited urgency status, and applying appropriate service levels to ensure timely processing. Directed Web Access for External Users A secure one-time link to the system sent to the provider who is the subject of a grievance to seek feedback on the issue when the grievance is related to providers or providers office staff (such as appointments, staff behavior, and prolonged wait times.). Once the provider submits the required information, the process automatically resumes and is routed to the owner of the case for review. Service Levels, Routing, Prioritization, and Escalation Tracking of each complaint case with priority assigned based on urgency status, type and level of complaint, and type of denial. Service level rules monitor goal and deadline times based on predefined standard parameters (14 days or 30 days). When the case reaches goal times, additional priority points escalate the case relative to other cases in the queue. Routing capabilities include requesting input from supporting departments such as provider network services or utilization and claims management. Correspondence Generation Preconfigured letter templates for communicating with the involved parties at various stages of the complaint process. Standard templates for acknowledging a complaint, requesting additional information, and communicating final disposition can be quickly and easily customized to meet your specific needs. The letter templates are complied dynamically and include re-usable correspondence fragment rules for common sections such as headers, footers, style sheets, and logos. You have the flexibility to generate correspondence automatically in the background or to allow / require editing as well as verification before it is finalized.
The Appeals and Grievances Solution
6-3
Quality Improvement Audit Preconfigured auditing of complaints based on frequency for a specific provider. The process creates a quality review case that is forwarded to the Quality Improvement Department for further review. Legacy System Information Retrieval and display of commonly referenced legacy system information such as members eligibility as well as processing feedback comments from all involved parties (member research and provider network departments). Reporting Preconfigured productivity reporting to track process assignments, activity, quality, and performance. The reporting wizard allows managers to build custom reports necessary to manage the complaint resolution processes. Custom preconfigured reports include: Aging Inventory By Complaint Type Appeal Inventory By Denial Type Resolved Grievances By Resolution Type Resolved Appeals By Resolution Type
Connectors to External Systems Leverage of the comprehensive integration capabilities of Process Commander. The complaint management process enables retrieval and display of pertinent information from the Health Plans existing legacy systems, making it readily available for users during the process of resolving the complaint. The members eligibility information and the original authorization or claim information are automatically retrieved and made available as part of the case history. This availability avoids the need to toggle back to legacy systems for lookup and research of the information required to efficiently resolve the complaint. The Appeals and Grievance Management Solution provides the foundation for Health Plans to build for change. It comes with a working configuration that you can extend to create your own solution. The remaining part of this chapter provides some suggestions as to where you might extend the Appeals and Grievances Solution.
6-4
The Final Disposition Process for Appeals

The Appeals and Grievance Manager layer comes with a standard disposition process for an appeal where the original denial on the claim or the authorization can be flagged as Upheld or Overturned. The workflow then proceeds to allow users to select the appropriate correspondence to communicate the final disposition (approval or denial of the appeal). When the decision on the original claim or authorization transaction is overturned (meaning approving the claim payment or the requested service), you may want to extend the process to either generate a new claim or authorization transaction that reflects the change and route it to the appropriate department (claims or utilization management) for follow-up. Alternatively, the original transaction can be updated in the host legacy system. Figure 6-1 shows where you might extend the flow rule to add the new processes either in the same flow or spawning a new flow.
6-5
Figure 6-1. Resolve Complaint Flow
6-6
Extending the Final Disposition Notification Process

When users select the final disposition to the complaint, the system displays a selection box of available correspondence templates for approval or denial of the grievance or appeal as warranted by the case disposition The Appeals and Grievance layer is setup with default correspondence templates for approving or denying a grievance or appeal: GrievanceApproval GrievanceDenial AppealApproval AppealDenial
These correspondence templates are set up to require user editing and supervisor verification before they can be sent to the requestor. These editing and verification requirement options can be modified to suit your business needs. You may want to extend the list of available correspondence templates to choose for approving or denying a complaint. Specific templates can be created for specific types of grievances or appeals. Alternatively, you can present users with a specific version of the template automatically by using the Circumstance feature. This feature lets you display different versions of the default correspondence based on a specific property value (Figure 6-2).
6-7
Figure 6-2. Circumstance Feature in Correspondence
6-8
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.
6-9
Extending the Quality Audit Process

The Appeals and Grievance Manager layer comes with a sample Quality Improvement audit check, enabling a quality review for providers who have more than ten grievances lodged against them within a 30-day period. This check is performed in the ResolveComplaint flow within an activity called ProviderQualityCheck, which creates a list of matching cases by Provider Identifier, for grievances which dealt with provider service. If there are more than ten matching cases, the flow calls a spinoff flow named ProviderQualityReview, which in turn generates an assignment to the Quality Review department to investigate and enter notes on the issue. This serves as a placeholder for more complex Quality Improvement review processes. This could be used to do statistical sampling to check on a given percentage of new complaint processors cases, or to check on frequently complaining members. The current process generates an assignment on the current complaint and records notes about the investigation; this could also be expanded to provide a folder or list of existing cases, or to interface with your provider data repository to set warning flags.
6-10
The Appeal Re-Open Process

The Appeals and Grievance Manager layer provides the ability to reopen appeals that were closed at Level 1 or 2. This is done through an activity called ReopenAppeal, which is tied to the Reopen button on the review screen. This is only permitted on appeals, and does not work for grievances. The activity checks that the appeal was closed recently enough to allow a reopen this check is performed in a When rule named ResolvedRecently, and is set to 60 days. This record can be copied and modified to set your own timeframes for appeal reopening. The activity additionally increments the appeal level, and calls the ReopenAppeal flow, which allows the operator to enter notes for Appeal level 2 or 3 as appropriate. You might want to expand this activity into a more complex Appeal Reopen and Review process or use it to route reopened appeals to specific workbaskets for higher-level appeals. Currently, the reopening operator enters the new notes, and then the appeal goes through the same workflow as at level 1 for investigating claim/authorization data and setting a disposition. This could be replaced with a separate flow with additional routing logic for reopened cases. This could also be used to assure that operators who previously worked on an appeal do not rework the appeal at a higher level. Currently, the first complaint operator to pick up a case is set as the complaint owner until it is resolved. That process could be used to create a list of previous owners, and the GetWork process then modified to prohibit a prior owner from working a reopened appeal.
6-11
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, ResolvedGrievanceApproved:Standard) Resolved Appeals by Type shows all resolved Appeals, grouped by their appeal levels and request urgency (for example, ResolvedAppealApproved:Standard)
Chapter 7 Extending Your Framework

This chapter describing areas of the Framework you might want to extend and includes: Standard setup requirements that describe what must be done with any new installation. Setup requirements Setting up calendars Setting up correspondence
Extension ideas including areas of the Framework that you may want to extend: Authorization Management Solution Layer (described in chapter 3 New Member Enrollment Solution Layer (described in chapter 5 Appeals and Grievance Manager Layer (described in chapter 6) Self-Service Options for Authorization Adding X12 Messages
7-2
Integration activities including places in the Framework that you may want to integrate with external systems to either push or pull data: Common object data interface Data interfaces for Member and Eligibility, Provider, Claim, and Authorization Interfacing to PegaDISTRIBUTION Manager
Extending Your Framework
7-3
Setup Requirements
Ensure you have set up the following before extending your framework: Operators Operator IDs define the type of users who work with the Framework and the application you build. The Healthcare Industry Framework comes with a set of predefined operator IDs that you can use to create your own. Access Groups Operators IDs specify an access group that determines options that portal users see, RuleSets they can access, classes of work that appear in their portal, default class group of rules that users work with, and access roles. The Healthcare Industry Framework comes with a set of predefined access groups that you can use to create your own. Access Roles An access role is defined as having certain class access rights. Users can have one or more access roles, which are listed in access groups. The Healthcare Industry Framework comes with a set of predefined access roles that you can use to create your own. Privileges A privilege allows users with a particular role to execute certain functions. Privileges are associated with access roles, not directly with users. If a user has the access role with which the privilege is associated, the user has the privilege. Privileges also play a role in routing work as users can only receive work items for which they have privileges.
Tip: Access-Role-Obj rules (of type Rule-Access-Role-Obj) associate

access roles with the classes to which they provide access and with any relevant privileges or access settings. When you create a new access role, you must associate it with the appropriate classes. When you associate an access role or privilege with a class, you not only associate the names of the rules, but you also specify the level of access a role or privilege has to a class or the conditions under which the role or privilege can access the class. This process allows for an extremely flexible and powerful way of defining class-based security.
7-4
Setting Up Calendars
The calendar identifies business days and the hours of operation on these days. Holidays and other non-work days, typically Saturday and Sunday, are considered non-business days. Calendars affect the following activities: Case types that require a work date to be a business day Service Level Rules that measure goal and deadline times in business days
The Healthcare Industry Framework comes with a sample calendar for 2006. As part of the deployment process, you can add, delete, and update the calendar to reflect your operations open business days and local holidays. The RuleSet record is Data-Admin-Calendar. The default time zone is EST.
7-5
Figure 7-1 shows the 2006 calendar supplied with the product.
Figure 7-1. Default Calendar for 2006
7-6
Setting Up Correspondence
The Healthcare Industry Framework comes with predefined correspondence templates. Some correspondence rules are called top-level rules (indicated on the Prompts tab of the rule form). Master templates are based on a top-level correspondence rule and can include other rules or references to other rules. The correspondence type whether e-mail, mail, phone, or fax is defined in the top-level correspondence rule when it is created. The rules define various correspondence segments such as the header, footer, and body. Each segment (or stream) provides a piece of the HTML code needed to generate a complete piece of correspondence. The advantage of defining correspondence templates in separate rules is that one header or footer, for example, can be used in many correspondence rules. Figure 7-2 shows a representative correspondence template structure.
Figure 7-2. Standard Correspondence Template Elements
7-7
Because the correspondence is HTML based, it provides the opportunity to create a professional look and feel to letters, e-mails, and faxes that are sent to customers and banks. See page Chapter 3, What is Already Set Up for a list of preconfigured correspondence templates and correspondence fragments. E-mails are generated through capabilities built into PegaRULES Process Commander. The routing, printing, and faxing of correspondence is handled by an interface to the PegaDISTRIBUTION Manager. However, it is not necessary to have PegaDISTRIBUTION Manager installed when updating and testing changes to the templates. Correspondence will be generated, attached to the case, and can be reviewed online in its printed form. It wont print until the interface is active.
Tip: To copy and customize the templates in your RuleSet, maintain the
same Correspondence Rule name to avoid unnecessary updates to workflow elements that call specific templates. Add templates only when no alternative is available.
7-8
Sample HTML and Template Letter

Shown below are the underlying HTML for the Request Additional Information letter correspondence template, the several Fragments associated with the template, and the letter produced by the Healthcare Industry Framework. (Figure 7-3 through Figure 7-6 show several parts of a piece of correspondence.)
Figure 7-3. Correspondence Template HTML for Request Additional Information Letter
7-9
Figure 7-4. Correspondence Fragment Stylesheet for Correspondence Template
Figure 7-5. Correspondence Fragment Header Requestor for Correspondence Template
7-10
Figure 7-6. Correspondence Output Sample Letter
7-11
Adding Additional X-12 Transactions

The Healthcare Framework can be extended to support additional X12 transactions. This section describes how to extend the classes and properties, and the supporting Parse Delimited and Activity Rules.
Extending the Classes and Properties

The classes and properties that come with the Framework support the segments for the 278, 837 and 834 X12 transaction types as defined in the corresponding National Electronic Data Interchange (EDI) Transaction Set Implementation Guide (IG). Most of these segments are common to all transaction types. Refer to Chapter 5, X12 Message Processing for a full description of the class structure. When adding an additional transaction type, follow these steps using the class structures provided for the existing transaction types as a guide: 1. Create classes for additional segments needed for new transaction type.
Examine the appropriate Transaction Set Implementation Guide to determine which additional segments you need to create. For each new segment, create an abstract sub-class in the PegaHC-X12-Data class following the naming convention of SegmentId_SegmentName (such as NM1_IndividualorOrganizationalName). This name should be a generic name for the segment, not specific to the usage in the transaction set. Create a property for each of the data elements in the new segment class as defined in the Transaction Set Implementation Guide. Note the special handling of a component data element (see CAS_ClaimsAdjustment as an example).
2. Create a class for the new transaction type itself.
Create a concrete class in the PegaHC-X12-Data class for the new transaction type.
7-12
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 subloops contained in loops. Create an abstract class for the X12 object itself. For example, under the PegaHC-X12-Data-N278 class, two classes are defined, HealthcareServicesRequest and HealthcareServicesResponse. Create the properties for this class which make up the object, using the newly defined classes for the loops. Note that the X12 object corresponds to the entire functional group in the X12 message, so this X12 object class will most likely contain 3 properties: FunctionalGroupHeader and FunctionalGroupTrailer, each of which is a page of the appropriate class and Transaction, which is a page list of the newly created transaction class.
Parse Delimited Rules

Parse Delimited rules need to be created for each of the new classes you created for segments not previously defined. Figure 7-7 shows an example of a Parse Delimited rule using the UM_HealthCareServicesReviewInformation class.
7-13
Figure 7-7. Parse Delimited Rule Example
7-14
Create the Parse Delimited rules as follows.

1. Create a Rule-Parse-Delimited instance for each newly created segment. Use the appropriate PegaHC-X12-Data- class for the Applies to part of the key. Use ParseX12 for the Namespace part of the key. Use the segment id for the Record Type part of the key. Use an * for the delimiter and a \ for the escape character. Select Use Parse Details as the method and check Drain Remaining Data. In the parsing details section: Select Clipboard in the Map To field. Use the smart prompt in the Map To Key field to select each property in the segment class.
g. For properties that are defined for component data elements, call another parse delimited rule for the appropriate class by specifying Delimited ParseRule in the Map To field and the Record Type of the parse rule you are calling in the Map To Key field.
2. Create a Rule-Parse-Delimited instance for each of the classes that were created to support a component data element. For the Applies To part of the key, be sure to use the same class as the calling Parse Delimited rule. Use ParseX12 for the Namespace part of the key. Use the property name for the composite data structure for the Record Type part of the key. Use a : for the delimiter and a \ for the escape character. Select Use Parse Details as the method and check Drain Remaining Data. In the parsing details section: Select Clipboard in the Map To field. Use the smart prompt in the Map To Key field to select each property in the segment class.
7-15
Activity Rules
To support processing the X12 message (getting the X12 data onto the clipboard and ready for processing by the application), create one new X12ParseMessage and update the existing activity, X12ParseMessageType, to support the new transaction type.
Creating X12ParseMessage Activity

Create a new X12ParseMessage (it must have this name) in the concrete class that was previously created for the transaction type. (Any of the three X12ParseMessage activities provided in the Framework support the three transaction types, N278, N837 and N834, and can be used as an example.) The first four steps in the activity are standard for all X12ParseMessage activities and are required to parse the X12 message and put the data onto the X12Data page in the clipboard.
Note: The X12ParseMessage activity for the N278 class has additional
steps these steps are to support the functions in the PegaHCAUTH application.
7-16
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.
7-17
Updating X12ParseMessageType Activity

The X12ParseMessageType activity must be modified for the new transaction type. Update the if statement in the Java code segment below to recognize the code for the new transaction type and its corresponding object class.
if (strSegmentLine[1].equalsIgnoreCase("HC")) newObjClass = myStepPage.getProperty(".pxObjClass").toString() + "N837"; else if (strSegmentLine[1].equalsIgnoreCase("BE")) newObjClass = myStepPage.getProperty(".pxObjClass").toString() + "N834"; else if (strSegmentLine[1].equalsIgnoreCase("HI")) newObjClass = myStepPage.getProperty(".pxObjClass").toString() + "N278"; else newObjClass = "UNKNOWN";
7-18
Other Activities
If your application requires that an X12 message be generated and sent out, an activity is needed to build that X12 message. The N278 class contains an activity that builds an X12 message for an outgoing Authorization Response (X12GenerateResponse). You can use this activity as an example. The process is as follows: Based on processing within the application, the data is put on a page in the clipboard in the X12 structure, similar to the X12Data page that was created from the inbound X12 message process. An activity similar to the X12GenerateResponse is called that has a Java step that pulls data off the clipboard and moves it into a string buffer in the X12 format. Similar to the Java in the X12ParseMessage activity, this Java uses the transaction type that is being processed as defined in the Implementation Guide.
7-19
Member and Eligibility Data Interface

The Appeals and Grievances layer provides data classes, PegaHC-Interface-Member and PegaHC-Interface-Policy, to store member information and policy/eligibility data. The sample data is stored as a Process Commander Data instance of these classes and accessed through the RuleObj-Open method. This access method can be used in production, in which case it would be necessary to create a feed process that updates the Process Commander data table periodically with new, updated, and deleted records. To use an existing data source for these records, the Appeals and Grievances layer provides placeholder activities that can be copied and modified to enable the lookup and retrieval of information from your own centralized database files. Based on the entry of a member identifier, the lookup validates and returns member data and eligibility information. When retrieved, this information is placed on a clipboard and subsequently mapped into a Complaint case. These activities are called within a flow, which itself can be copied and modified if you require more complex processing for your lookup procedures. To create your customer file interface, select your connectivity method (see PegaRULES Process Commander Integrating with External Systems for your connectivity options and determine your field mapping between the data source and Smart Investigate.) Then, create and modify versions of the following activities to map and validate the data. PegaHC-AG-Complaints GetMemberData The activity looks up the member information in the database and sets the properties on the clipboard. PegaHC-AG-Complaints GetMemberPolicyData The activity looks up the members policy and eligibility information in the database and sets the properties on the clipboard.
7-20
Provider Data Interface

The Appeals and Grievances layer provides a data class, PegaHC-InterfaceProvider, to store provider information. The sample data is stored as a Process Commander data instance of this class and accessed through the Rule-Obj-Open method. This access method can be used in production, in which case it would be necessary to create a feed process that updates the PRPC data table periodically with new, updated, and deleted records. To use an existing data source for these records, the Appeals and Grievances layer provides provides placeholder activities that can be copied and modified to enable the lookup and retrieval of information from your centralized database files. Based on the entry of a provider identifier, the lookup validates and returns provider data. When retrieved, this information is placed on a clipboard and subsequently mapped into a Complaint case. These activities are called within a flow, which itself can be copied and modified if you require more complex processing for your lookup procedures. To create your provider file interface, select your connectivity method (see PegaRULES Process Commander Integrating with External Systems for your connectivity options and determine your field mapping between the data source and Smart Investigate.) Then, create and modify versions of the following activities to map and validate the data. PegaHC-AG-Complaints GetProviderData The activity looks up the provider information in the database and sets the properties on the clipboard.
7-21
Claim Data Interface

The Appeals and Grievances layer provides a data class, PegaHC-InterfaceClaimHeaderDetail, to store historical claim information. The sample data is stored as Process Commander data instance of this class and accessed through the Rule-Obj-Open method. This access method can be used in production, in which case it would be necessary to create a feed process that updates the Process Commander data table periodically with new, updated, and deleted records. To use an existing data source for these records, the Appeals and Grievances layer provides provides placeholder activities that can be copied and modified to enable the lookup and retrieval of information from your centralized database files. Based on the entry of a claim reference number, the lookup validates and returns claim data. When retrieved, this information is placed on a clipboard and subsequently mapped into a Complaint case. These activities are called within a flow, which itself can be copied and modified if you require more complex processing for your lookup procedures. To create your provider file interface, select your connectivity method (see PegaRULES Process Commander Integrating with External Systems for your connectivity options and determine your field mapping between the data source and Smart Investigate.) Then, create and modify versions of the following activities to map and validate the data. PegaHC-AG-Complaints GetClaimData The activity looks up the claim information in the database and sets the properties on the clipboard.
7-22
Authorization Data Interface

The Appeals and Grievance Manager layer provides a data class, PegaHCInterface-Authorization, to store historical authorization information. The sample data is stored as Process Commander data instances of this class and accessed through the Rule-Obj-Open method. This access method can be used in production, in which case it would be necessary to create a feed process that updates the Process Commander data table periodically with new, updated, and deleted records. To use an existing data source for these records, the Appeals and Grievance layer provides placeholder activities that can be copied and modified to enable the lookup and retrieval of information from your centralized database files. Based on the entry of a authorization reference number, the lookup validates and returns authorization data. When retrieved, this information is placed on a clipboard and subsequently mapped into a Complaint case. These activities are called within a flow, which itself can be copied and modified if you require more complex processing for your lookup procedures. To create your provider file interface, select your connectivity method (see PegaRULES Process Commander Integrating with External Systems for your connectivity options and determine your field mapping between the data source and Smart Investigate.) Then, create and modify versions of the following activities to map and validate the data. PegaHC-AG-Complaints GetAuthData The activity looks up the authorization information in the database and sets the properties on the clipboard.
7-23
Interfacing to PegaDISTRIBUTION Manager

PegaDISTRIBUTION Manager is a required companion product that works with the Healthcare Industry Framework to activate printers and print servers to send correspondence in print, fax, or Rich Text Format (RTF) file modes. It can also print HTML files and their associated image files. Installed independently of the framework, it is designed to run on Microsoft Windows 2000 Professional or Server or Windows XP. To install and configure the PegaDISTRIBUTION Manager, refer to the PegaDISTRIBUTION Manager (IOS) for PegaRULES Process Commander Installation and Deployment Guide.

HCIF Imp Guide V73 LCK

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HCIF Imp Guide V73 LCK

Uploaded by

Copyright:

Available Formats

Healthcare Industry Framework

Copyright 2009 Pegasystems Inc., Cambridge, MA

Healthcare Industry Framework Implementation Guide

Healthcare Industry Framework Implementation Guide

Healthcare Industry Framework Implementation Guide

Healthcare Industry Framework Implementation Guide

Chapter 1 Before You Begin

Healthcare Industry Framework Implementation Guide

What Is the Healthcare Industry Framework?

PegaHC Healthcare Foundation Layer

Before You Begin

HIPAA-Enabled Healthcare Data Model

HIPAA-EDI Reference Implementation

Healthcare Industry Framework Implementation Guide

Framework Starter Kit

PegaHCAUTH Authorization Management Solution Layer

Before You Begin

Workbasket routing Service level monitoring Correspondence generation Manual resolution

PegaHCNME New Member Enrollment Solution Layer

Healthcare Industry Framework Implementation Guide

PegaHCAGM Appeals and Grievance Management Solution Layer

Before You Begin

Your Framework and Process Commander

Healthcare Industry Framework Implementation Guide

Who Should Read This Document?

Before You Begin

Education and Training

Chapter 2 What Is Already Set Up

Healthcare Industry Framework Implementation Guide

What Is Already Set Up

Healthcare Industry Framework Implementation Guide

System Administrator Account

What Is Already Set Up

Healthcare Industry Framework Implementation Guide

What Is Already Set Up

Healthcare Industry Framework Implementation Guide

What Is Already Set Up

Work Object Naming Conventions

Healthcare Industry Framework Implementation Guide

PegaHC-EDI-WorkEligibilityRequest PegaHC-AUTH-WorkAuthRequest PegaHC-AG-WorkComplaint PeagHC-NME-WorkEnrollment-EnrollmentApp

Authorization Request Complaint Member Enrollment Application

What Is Already Set Up

Default Work Groups and Workbaskets

Healthcare Industry Framework Implementation Guide

Used for routing work to the underwriting group

Used for routing work to the underwriting support users

Figure 2-3. Work Groups and Workbaskets

What Is Already Set Up

Default Operators, Access Groups, and Portals

HCIFDeveloper (Default) AGMManager (Alternate) AUTHManager (Alternate) NMEManager (Alternate)

Healthcare Industry Framework Implementation Guide

AUTH:UMCoordinator AUTH:UMCoordinator AUTH:UMCoordinator

AUTHUser AUTHUser AUTHUser

Developer (Default) NMEManager (Alternate)

What Is Already Set Up

UnderwriterManager@MyHealthPlan Underwriter1@MyHealthPlan Underwriter2@MyHealthPlan Underwriter3@MyHealthPlan UnderwritingSupport@MyHealthPlan

NME:EnrollmentManager NME:Underwriter NME:Underwriter NME:Underwriter NME:Underwriter

NMEManager NMEUser NMEUser NMEUser NMEUser

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

Healthcare Industry Framework Implementation Guide

Predefined Organizations, Divisions, and Units

What Is Already Set Up