Selecting the Add event code button on the Event codes screen will open the New event code screen.
There are six steps that are shown in the right panel of the New event code screen to walk through the creation of the new event code. These steps are:
- Event information – This section contains key metadata for the event code. For example: event code number, name, version start and end.
- Event configuration – This section provides the core configurations for the event code. For example: dates of service, claim type, clean claim indicator, along with the configurations needed for a dynamic event code.
- Disposition configuration – This section contains the information needed by the system on how to handle the event code when it is set. For example: action, processing dates, SLA, event resolution flow.
- Response configuration – This section contains the information needed by the system to map the outcome of the event to a response code and supplementary information. For example: claims adjustment reason codes, claim status codes, explanation of benefits text.
- Claims transfer configuration – This section contains the settings that can limit where the claim with this event code assigned can be transferred to by an operator. For example: work queues and work lists.
- Review and submit – This step will enable the user to review the entered information, perform any necessary modifications and then submit it for approval. Once the event code is approved, it is available for use.
The fields used in the creation of an event code are listed in the table below. Fields with an asterisk (*) are required.
|1||Information||Version||Version number based on previous existing versions of the same event code. Auto populated by the system.|
|1||Information||Version start*||The date the event code becomes active in the system; must be today or a date in the future. If version start date is set as the current day, an information alert is displayed stating that this might be changed on approval.|
|1||Information||Version end*||The date the event code becomes inactive in the system; must be today or a date in the future and must be greater than or equal to the version start date.|
|1||Information||Is Dynamic event?||Yes / No. This option allows the user to configure the criteria based on which the dynamic event code would be triggered.|
|1||Information||Module Source*||Module that sets the event code. This is defaulted when the is Dynamic event box is checked.|
|1||Information||Event code number*||Numeric field that contains the internal code used to identify the business event rule that was applied during claims execution. Event code number must be in the correct range for the implementation ID chosen.|
|1||Information||Event name*||Name of the event code.|
|1||Information||Description*||Description of the event code.|
|1||Information||Category*||Identifies whether the event code applies to business or system rules. This drives the priority routing of claim work objects.|
|1||Information||Applies to*||Differentiate between claim header and claim line level event codes. This drives the disposition configuration.|
|1||Information||Client ID||Capability for client to add their own mapping for their own event or pend code numbering.|
|1||Information||Event code documents or links||Allows the user to attach documentation that is associated to the event code. For example, knowledge articles, business policies and resolution workbooks.|
|2||Configuration||Event group||The event group to which the event code is associated.|
|2||Configuration||Implementation ID*||The application to which the event code is associated. This field is auto populated.|
|2||Configuration||Clean Claim Indicator||Yes / No. Identifies if the event code would cause the claim to be “clean” or “unclean”.|
|2||Configuration||DOS start*||The first date of service (DOS) on the claim which the configuration applies to; can be any date in the past or future.|
|2||Configuration||DOS end*||The last date of service (DOS) on the claim which the configuration applies to; can be any date in the past or future and must be greater than or equal to the DOS start date.|
|2||Configuration||Event source rule type||Allows you to select the actual flow, collection, decision tree, activity, decision table, or data transform that creates the event code.|
|2||Configuration||Event source rule name||Allows you to add event source rule from drop down selection of rules. This provides transparency between the Pega rule assigning the event code and the event code configuration. This field is displayed once the event source rule type is populated.|
|2||Configuration||Claim type*||Different claim types use different outcomes and descriptions for the event code, Drop Down Box - multiple can be selected. For example: All, Dental, Inpatient, Outpatient, Professional.|
|2||Configuration||Claim identifier*||Different claim identifiers use different outcomes and descriptions for the event code. Drop Down Box - multiple can be selected. For example: All, Chargeable, Reporting, Medicaid Reclamation.|
|2||Dynamic event criteria||Label, Condition & Logic string||This defines the criteria for the dynamic user created events. More information on this is detailed in the section below.|
|2||Dependencies||Dependency event code||This is the list of event codes that will cause this event code to be disregarded in event review. Use the + Add event codes option to add more entries to this list. This is used to remove event codes from the claim that are related to another event code. For example, if a claim set a procedure code not found event, then the benefit not found would also set. Adding the procedure code not found event code as a dependency of the benefit not found event code will remove the benefit not found event code from being reported.|
|3||Disposition Configuration||Claim type, Claim identifier, Submission type, Media type, Processing start, Processing end & Action||The configuration of dispositions is detailed in the section below. This will detail the use of the fields based on the disposition action selected.|
|4||Suspend response configuration & Deny response configuration||Claim status category Code*||Code indicating the general category of the status (accepted, rejected, additional information requested, etc.). Maps to an X12 claim status category code. Required when a suspend or deny disposition exists.|
|4||Suspend response configuration & Deny response configuration||Claim status code*||Code conveying the status of an entire claim or a specific service line.Maps to an X12 claim status code. Required when a suspend or deny disposition exists.|
|4||Suspend response configuration & Deny response configuration||Entity identifier code||Code identifying an organizational entity, a physical location, property or an individual and is associated with a status code. Maps to an X12 entity identifier code.|
|4||Deny response configuration||Claim adjustment group code*||Code identifying the grouping for the financial adjustment associated with the adjustment reason code. Maps to an X12 claim adjustment group code.|
|4||Deny response configuration|
Claim adjustment reason codes*
|Code identifying why the claim or service line was paid differently than billed. Maps to an X12 claim adjustment reason code (CARC). Required when a suspend or deny disposition exists.|
|4||Deny response configuration||Remittance advice code*||Code used to provide additional explanation for an adjustment already described by a claim adjustment reason code or to convey information about remittance processing. Maps to an X12 remittance advice remark code (RARC).|
|4||Deny response configuration||Liability assignment: Provider or Member||Identifies the party, liable for the remainder of the claim. If the selection is Member, then the liability calculation can be either the Billed or Allowed amounts.|
|4||Correspondence configuration||EOB description||Explanation of Benefits - Description of the event code assigned for external communications to the member.|
|4||Correspondence configuration||EOP description||Explanation of Payment - Description of the event code for external communications to the provider.|
|4||Correspondence configuration||Correspondence||Enables the selection of a correspondence rule that can be attached to the event code|
|4||Disposition document and links||Enables the ability to attach documents or links that is associated with the event code. These could be link to external document management systems.|
|5||Claim transfer configuration||Work group||Restricts the transfer of claims with the event code assigned to only the selected work groups. If none are selected, then all work groups will be available for transfer. To add a work group, select Add work groups, and then select the appropriate work groups from the list by selecting Add and then Submit.|
|5||Claim transfer configuration||Work queues||Restricts the transfer of claims with the event code assigned to only the selected work queues. If none are selected, then all work queues will be available for transfer. To add a work queue, select Add work queues, and then select the appropriate work queues from the list by selecting Add and then Submit.|
|5||Claim transfer configuration||Work lists||Restricts the transfer of claims with the event code assigned to only the selected users work lists. If none are selected, then all work lists will be available for transfer. To add a work list, select Add work lists, and then select the appropriate users from the list by selecting Add and then Submit.|
Note: If an event code is configured incorrectly. For example, the triggering logic identifies a line level event, but the event code is configured at the claim level, event code SGB-0011 will be raised.Dynamic events
Dynamic events enable a business user to create the logic that would cause the event code to set. For example: all claims with a specific billing provider tax ID, billing a specific procedure code. Once the event code is defined as a dynamic event code, the configuration elements become available. The applies to setting (claim or line) will define the fields that are available for the dynamic event configuration. An example of a dynamic event configuration is shown below:
The fields used in the dynamic event creation are detailed below. Fields with an asterisk (*) are required:
|Label*||A simple character or word that is used to identify the condition and used in the logic string|
|Condition*||The field on the claim, the expression and the value that is to be compared. The fields available for selection are driven by the applies to setting. Claim and line level fields are available for a line level event and only claim level fields available for a claim level event. A more complex function could also be used instead of a simple expression. To replace the expression with a function, select the caret at the end of the row to bring up the function selection screen.|
|+ Add criteria||Enables another row to be added to the dynamic event configuration for another condition to be applied. If multiple criteria are used, then each row will have an and/or selection to help build the logic string.|
|Logic string*||The final logical string that would be utilized to assign the dynamic event. This can be autogenerated or manually configured. For complex nested conditions, parentheses can be used to group conditions. When automatically generated, the and/or value on each row is used to generate this string.|
Condition rows can be moved by dragging the row via the symbol to another location.
Condition rows can be deleted by utilizing the trashcan icon. If a row has been deleted, you would need to regenerate the logic string to remove that label from consideration.
Once the claim is executed/adjudicated, the dynamic event code would be set on the claim or claim line, if the configured criteria on the event code matches with the relevant data on the claim/line.
The functions available to be used in the dynamic events list are sourced through the data page: D_GetDynamicEventFunctionAliasList. More functions can be easily added to this data page for reference.
The table controlling the claim fields used for consideration in the dynamic event code is the decision table DynamicEventConfigurableProperties. Updating this table will enable other fields on the claim to be utilized for the dynamic event configuration.
The disposition configuration identifies how the claim will process based on the event code assigned. This step defines the action of the disposition (deny, suspend, informational, ignore) based on specific claim criteria. There can be multiple different disposition combinations based on key claim attributes. At least one disposition needs to be configured for the event code.
The following table details the primary fields used for the disposition. Fields with an asterisk (*) are required:
|Claim type*||The claim type used for this disposition. It could be All, or any of the types selected in the event code configuration.|
|Claim identifier*||The claim identifier used for this disposition. It could be All, or any of the identifiers selected in the event code configuration.|
|Submission type*||The submission type used for this disposition. Select All, New, Adjustment/replacement or Void/cancel|
|Media type*||The media type used for this. Select EDI POS, Paper, Electronic batch, VAN POS, Web POS or All|
|Processing start*||Processing start date for the disposition. The date the defined disposition becomes active in the system.|
|Processing end*||Processing end date for the disposition. The date the defined disposition becomes inactive in the system.|
|Action code override info||Action codes assigned on the claim that can be used to override this event code when it is set. This option is only valid for Deny and Suspend dispositions. To add action codes, select + Add action code.|
Note: if an event code is triggered and has an active configuration, but no active disposition, then event code SGB-0047 is assigned to the claim.
The suspend disposition has a wide variety of fields that are used to control how the system manages claims that have events set to suspend. The primary types of configurations are below, each having their own set of options.
- To be submitted to an examiner for manual resolution.
- To auto-recycle for a specified period of time before the claim is denied or requires a manual resolution.
- To set service level agreement (SLA) information for the resolution task, so the claim doesn’t age past a deadline.
- To set a claim hold to stop claim processing for a specified number of days.
The fields to configure the suspend disposition are listed in the table below and are available once a suspend disposition has been selected:
Information on the resolution action buttons that are assigned in the disposition configuration can be found in the Claims Resolution section of the Claims Operations section.
|This is the recycle configuration. It provides the ability to recycle the claim prior to making a disposition decision. The configuration supports hourly, daily, or weekly options to a maximum, after which, a configuration to deny or route the claim or line is applied.|
|Priority||The priority of the event code for a suspend configuration. If multiple event codes are reported on the claim, the highest priority pend will be presented for resolution first.|
|Default work queue||The default work queue for this event code. This is used to assign a specific work queue for this event code. If this is blank, then the default work queue on the system configuration is applied.|
|Claim level / line resolution process||The dedicated process that is presented in the resolution window to resolve an event code at the claim level or line level. If this is blank, then the default line or claim event resolution process on the system configuration is applied.|
|Resolution role||The user role required to resolve a claim with the event code.|
|Override event / Override role||Displays the Override event action on the guided event resolution UX. The user role able to override the event is also identified.|
|Replace event code||Displays the Replace event code action on the guided event resolution UX. The replacement event codes can be constrained to a list of codes by selecting the appropriate codes with + Add event code.|
|No action required||Displays the No action required action on the guided event resolution UX.|
|Update claim / Update claim line||Displays the Update claim or Update claim line action on the guided event resolution UX.|
|Deny claim / Deny claim line||Displays the Deny claim or Deny claim line action on the guided event resolution UX.|
|Cancel claim||Only applies to claim level dispositions. Displays the Cancel claim action on the guided event resolution UX.|
|Manually price claim line||Only applies to claim line dispositions. Displays the Manual price claim line action on the guided event resolution UX.|
|SLA available||Ability to set a specific service level agreement (SLA) for the resolution of the event code.|
|SLA*||Select the SLA rule associated with the event code. Selecting the SLA will display the Goal urgency increase and Deadline urgency increase fields with the values from the selected SLA. *Required when SLA available is selected.|
|SLA days type*||Definition for the type of days being referenced for the SLA: Business days or Calendar days. *Required when SLA available is selected.|
|SLA deadline days*||Contracted claim processing time made with an organization or department. *Required when SLA available is selected.|
|Organization name*||Department or organization identified as responsible for the event resolution SLA. The selection list is defined in the SLA section of the system configuration UX. The organization type is populated based on the selection. *Required when SLA available is selected.|
|Claim hold info available||Identifies if the claim should be held for a specified period of time before reprocessing.|
|Claim hold type*||A reference to identify the type of hold. Related to: External payer, Provider, or Internal. *Required when claim hold info available is selected.|
|Claim hold days type*||The definition for the type of days being referenced for the hold: Business days or Calendar days. *Required when claim hold info available is selected.|
|Claim hold days*||The number of days that the claim will be held based on the hold days type. *Required when claim hold info available is selected.|
|Claim hold begins on*||The date that the claim hold period starts: Claim receipt date or User specified date. If user specified date, the Select date field is available. *Required when claim hold info available is selected.|
Note: if both hold and recycle are configured for the event code, then the hold is applied first and once completed, the recycle configuration takes effect.
Once the disposition has been configured, select Add disposition.
Multiple dispositions can be configured for the event code by selecting + Add disposition in the disposition configuration list.Claim holds and SLA disposition configurations
The SCE provides the ability to perform claim holds or apply specific SLA’s for an event code.
The claim hold scenario enables the claims that meet specific business scenarios be held from adjudicating for period instead of being submitted to a work queue for resolution. An example of a situation where a hold may be applied is where a claim pended for a missing authorization. Authorization approvals may be externally managed and uploaded to the system every 10 days. In which case, the claim would be held for 10 days and then reprocessed. Claims that are held are stored in the claims hold work queue.
Service level agreements (SLAs) define a period for which a claim can be suspended before certain kinds of penalties begin to apply to the claim. For example, interest is required to be paid after 14 days from claim receipt date. The SLAs in the event code configuration enable task level SLAs to be assigned to the resolution instead of the global claim SLA. The SLAs will increase in urgency based on the SLA rule associated with the event code.
The claim audit trail is updated when the SLA or hold time is met, along with the time configured for the hold or SLA.
The Claim exceeded SLA days report showing all claims that have exceeded the SLA is also available for review.Triggering new event codes
New event codes can be easily implemented in the SCE utilizing a standard function during development. To add an event code to the claim, the function CE_SetEventCode is utilized. The parameters for this are the event code ID, a check to indicate a line number is being passed and then the claim line number. Once added, the event code can be seen in the clipboard in the pyWorkPage.EventListOpen structure if the claim is pended or the pyWorkPage.EventList if the claim is approved or resolved.
An example of assigning an event code through a collection is below:
Selecting the event code function from the list will present the fields for the appropriate variables to be added in the collection step:
The assignment of an event code to the claim performs validations in the system. The following table details the errors and where appropriate, the event codes, that are applied if the assignment fails.
|Event code configuration is not found in the system - sets event code: SGB-0046||Event not found|
|Event code configuration is inactive||Event inactive|
|Event code header data is not matched (for example: dates of service, claim type, claim identifier)||Event header data inapplicable|
|Event code disposition is not found (for example: adjudication date, claim type, claim identifier, submission type, media type) – sets event code: SGB-0047||Disposition not found|
|Event code disposition action is set to ignore||Ignore disposition|
|Event code is already raised||Duplicate event|
|Event code is overridden||Override event|
|Event code is reported on denied claim line||Event raised on denied line|
|On any logical error||Error|