Approving an event code configuration
New event codes or changes to existing ones are sent for approval to the System manager work queue. Authorized users can then approve these items.
Most event code approvals will follow the standard approval actions, but due to the versioning, some situations present alternative buttons in the approval screen. The available actions are detailed in the table below:
| Scenarios | Event code actions | Approval screen information |
| Approval date is before version start date | Create new event code, create new version, edit version | Approve, Reject, and Send to originator buttons are displayed. |
| Approval date is after or same date as the configured version start date | Create new event code | Approve system date, Approve requested date, Reject and Send to originator buttons are displayed. |
| Approval date is after the configured version end date | Create new event code, create new version, edit version | Reject button is displayed. The configured version is already in the past. |
| Approval date is after or same date as the configured version start date | Create new version | Approve system date, Reject and Send to originator buttons are displayed. |
| Approval date is after or same date as the configured version start date | Edit Version | Approve system date and Reject buttons are displayed. |
| Deactivate date and the original version end date are in the past | Deactivate event code | Reject button is displayed. The configured end date is in the past and the event code is already inactive. An informational alert is also displayed. |
| Deactivate date is in the past and the original version end date is in the future | Deactivate event code | Approve and Reject buttons are displayed. On approval, the system date is used as the version end date. An informational alert is also displayed. |
The changes to the requested version start or end dates for the event code is required as processing is performed utilizing the system date. This will ensure that any previous versions are end dated appropriately and any new configurations can take effect when required. When the approved system date is utilized, the new event code version start date will reflect the system date, and if a previous version exists, it will have an event code version end date of the system date minus one day.
When event codes have a configuration due to start today, any claims processed against a previous configuration or instance where this event code was not configured may need to be reprocessed.
This is identified as a note in the screen shot below:
Note: best practice for implementing event code configurations is to ensure the start date for the version is in the future.
Previous topic Deleting an event code Next topic Event code history