Professional Documents
Culture Documents
Implementation Guide
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
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
1-2
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
1-3
simulated sample data for end user functions. This layer is required for all healthcare framework layers. Key features include:
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.
1-5
1-6
1-7
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
1-9
2-2
Industry Code Set Search and Maintenance HIPAA-Enabled Data Model Overview
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
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
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
AuthCMPMEA-
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
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
UnderwritingSupport@MyHealthPlan
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
2-13
Operator ID
HCIF Administrator@MyHealthPlan
Access Group
Portal Name
PegaHC:Administrators
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
NME:Administrators
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
2-16
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
2-18
Division
Sales
Unit
NewSales RenewalSales SalesSupport
Underwriting UtilizationManagement
Underwriting UtilizationManagement
2-19
X X
X X X
2-20
X X X X X X
X X X X X
X X
2-21
2-22
2-23
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.
RejectionNotice
Correspondence Fragments Logo Mail Sample health plan logo to be inserted in correspondence Used for formatting the HTML correspondence
Stylesheet
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
AuthReferenceInformation
Footer
2-26
NewEnrollmentApplication
WelcomeLetter
ActionGetProviderFeedback NMEWorkDetail NMEWorkLink Fragment Fragment Body of the e-mail sent to the plan sponsor Included in the body of the NMEWorkDetail fragment
2-27
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
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
HeaderMember
HeaderOther
HeaderRequestor
HeaderServiceProvider
HeaderServiceProvider
2-29
Email, fax, mail Email Email Email Email, Fax, Mail, PhoneText
2-30
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
2-31
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.
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
2-34
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
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
INT1 INT3
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
First Name
BWH
22-2222222
H-002
282N00000X
Hospital
DFCI
33-3333333
H-003
282N00000X
Hospital
MGH
44-4444444
H-004
282N00000X
Hospital
NEMC
55-5555555
H-005
Hl
282N00000X
Hospital
PC PC PC PC
2-37
Provider ID
GEN2
Provider Tax ID
20-2020202
Electronic Trans ID
G-002
Type
PC
Specialty #
208D00000X
Specialty
General Medicine
First Name
Erin
GEN3
20-2020203
G-003
PC
208D00000X
General Medicine
Byrn
Michael
PC PC PC CO CO CO PE
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
CREHAB2
50-5050502
CR-002
PE
261QR0404X
CREHAB3
50-5050503
CR-003
PE
261QR0404X
CO CO CO CO CO PE
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
First Name
GRP3
98-9898989
GRP-003
PC
193400000X
GRP4
98-9898990
GRP-004
PC
193400000X
GRP5
98-9898995
GRP-005
PC
193400000X
RHM1 EMERG1
88-8888888 99-9999999
RHM-001 EMERG001
CO CO
207RR0500X 207P00000X
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
PLAST1
30-3333333
PLAST001
OP
208200000X
Plastic Surgery
Morgan
Timothy
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
2-40
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
Claim Data
Claim #
CLM-001
Mbr ID
M-103
Svc Pvder ID
EMERG1
Total Charge
340
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
CLM-004
M-501
CARD1
25
5/10/2009
5/10/2009
Paid
93797
CLM-005
S-006
GAST1
1600
5/10/2009
5/10/2009
Paid
91110
2-41
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
Auth-1013
F-003
M-101
HS
ResolvedNoAuthRequired
Auth-1014
I-002
M-201
HS
ResolvedNoAuthRequired
2-42
Requesting Auth #
Auth-1015
Member ID
M-301
Auth Type
HS
Prov ID
G-002
Status
ResolvedNoAuthRequired
Description
No Auth Required (Joint Aspiration)
Auth-1016
G-002
M-901
HS
ResolvedNoAuthRequired
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)
HS HS HS
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)
HS HS HS HS HS HS HS AR
Cardiac Rehab Cardiac Rehab Cardiac Rehab Chiro Service Chiro Service Podiatry Service Podiatry Service Admission Request
2-43
2-44
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
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
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
2-48
2-49
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
2-50
2-51
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
2-52
2-53
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
2-54
2-55
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
2-56
2-57
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
2-58
2-59
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
2-60
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
2-61
2-62
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
2-63
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.
2-64
2-65
2-66
2-67
2-68
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.
2-70
2-71
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).
2-74
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)
3-3
3-4
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
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.
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).
3-8
In production, the outbound response transaction process is similar to the inbound process using one of the service rules.
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
X12GenerateResponse
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
3-10
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
3-12
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
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
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
Function Saves the sample authorization as a work item Displays the Authorization Search screen Displays the Authorization Display screen
3-16
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.
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
3-20
The following validations (Figure 3-16) are performed in the ValidateMember workflow.
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.
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
When
3-21
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
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
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
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
Class: PegaHC-AUTH-Work-AuthRequest DuplicateCheck LookupDuplicate Flow Activity Launches the duplicate request validation process Performs matching for potential duplicates
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.
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).
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.
3-30
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)
3-31
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
Service
Service Codes
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
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
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
If the above conditions are met, the Action Code is set to A1 (Certified In Total).
If the above conditions are met, the Action Code is set to A1 (Certified In Total).
3-35
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)
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.
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
Access Roles
Privileges
Portals
3-38
Description New Pending-UMReview Pending-MDReview Pending-ProviderCommunication Open-AdditionalInfoRequest Resolved-Approved Resolved-PartiallyApproved Resolved-Denied Resolved-NoAction Resolved-Duplicate
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
3-40
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.
3-42
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.
3-43
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
Escalation Activities
Goal Time: Transfer to Manager Deadline Time: Notify Manager by Email
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
SendEmailToManagerOnDeadline
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
AuthReferenceInformation
Footer
3-47
The Correspondence Template for requesting additional information creates this letter (Figure 3-41).
3-48
Reports
The framework includes two inventory reports that are available from the dashboard.
3-49
3-50
Drill-Down Details
Users can drill down from either report to see the following information (Figure 3-44).
3-51
Hover Details
Users can hover over the Auth Number and see detail information about the authorization (Figure 3-45).
4-2
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~
4-3
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
4-6
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
4-9
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
4-11
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
4-13
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.
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.
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.
MoveDataToResponse
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
PegaHC-X12-Data-Transaction
ProcessTransaction MoveDataToResponse
PegaHC-X12-DataLoop2000EServiceProviderLevel PegaHC-X12-Data-Loop2000FServiceLevel
PegaHC-X12-Data-N278 ProcessAuthorization MapToResponse X12GenerateResponse X12WriteMessage Figure 4-10. X12 Activities Working Together
4-17
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.
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
4-23
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
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
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
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
4-26
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
5-2
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
5-5
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
5-7
5-8
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
Rule Type
Function
IsApplicationFromPDF IsApplicationFromImage IsApplicationFromMessage Common Process IsNewBusiness EnrollmentUnit UpdateWorkSLA New Hire Process FindEmployer PDF Intake Process NMEPFDIntake NMEEnrollmentFormTest ParsePDF
True, if is Application From PDF True, if is Application is from Image True, if is Application is from Message
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
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
Function Used to parse XML data to clipboard properties Creates the work item and reads the e-mail message to the clipboard
5-11
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.
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
5-14
5-15
5-16
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.
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.
5-19
5-20
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.
5-22
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.
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
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
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).
5-29
DetermineRequiredSkill
ToSkilledOperator
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
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.
5-33
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
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
5-35
SendCorrespondence
Activity
5-36
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 Escalation Notify Assignee Notify Assignee Notify Assignee Notify Manager Notify Assignee N/A* Notify Assignee
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
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
WelcomeLetter
Fragment Rules NMEWorkDetail NMEWorkLink Fragment Fragment Body of the e-mail sent to the plan sponsor Included in the body of the NMEWorkDetail fragment
5-40
The correspondence template for sending a welcome letter creates the letter shown in Figure 5-38:
5-41
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.
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
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.
5-45
5-46
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).
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
5-48
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
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.
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.
Probationary periods related to dates of hire Dependent eligibility Other insurance and coordination of benefits
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.
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
6-5
6-6
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
6-8
6-9
6-10
6-11
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
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.
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.
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.
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
Figure 7-3. Correspondence Template HTML for Request Additional Information Letter
7-9
7-10
7-11
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).
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.
7-13
7-14
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.
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
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
7-20
7-21
7-22
7-23