The following is the column names, null / not null status of the columns, and size / type of the columns of the STATUS_CODE table.
STATUS_CODE NOT NULL NUMBER(2)
USER_FLAG NOT NULL VARCHAR2(1)
STATUS_TEXT NOT NULL VARCHAR2(80)
PAGER_REQUIRED_FLAG NOT NULL VARCHAR2(1)
COVERAGE_ALLOWED_FLAG NOT NULL VARCHAR2(1)
ON_PAGER_ACTION NOT NULL VARCHAR2(1)
ONCALL_ALLOWED_FLAG NOT NULL VARCHAR2(1)
The first thing we notice here is that almost all of the columns are NOT NULL, which means a value has to be assigned to the column.
The default statuses on newer systems are:
-1 User Defined
2 IN HOSPITAL ON PAGE
3 IN HOSPITAL PAGE EMERGENCY ONLY
4 IN HOSPITAL NOT AVAILABLE
5 OUT OF HOSPITAL ON PAGE
6 OUT OF HOSPITAL PAGE EMERGENCY ONLY
7 OUT OF HOSPITAL NOT AVAILABLE
8 IN OPERATING ROOM NOT AVAILABLE
9 AVAILABLE BY PHONE PLEASE CALL MY OFFICE
10 UNAVAILABLE PLEASE CALL PAGE OPERATOR
11 OVERHEAD PAGE ONLY PLEASE CALL PAGE OPERATOR
12 OVERHEAD PAGE ZONE 1
13 OVERHEAD PAGE ZONE 2
14 OUT ON WIDE AREA PAGE
20 ON DUTY
21 OFF DUTY
Each of the above statuses has its own PAGER_REQUIRED_FLAG, COVERAGE_ALLOWED_FLAG, and so on. Most of the columns are VARCHAR2 which means it can be numbers or letters. For the single character columns, the value should be entered as a T or F. The back-end portions of the programs usually check to see if this value is F and assume it to be T if it isn't, therefore there's really no point in making it other than T or F.
The STATUS_CODE column is the "status number" for a status. This must be a number and can be as high as 99 since the column is a NUMBER(2).
The USER_FLAG column lets the system know whether or not this is a status that can be used by default in the applications (Smart Console, SmartWeb, etc). Of course, if the SQL statement (in a Smart Console config, for example) is written without checking that column, the data can still be seen.
The STATUS_TEXT column is where the visible text of the status is stored. This can be up to 80 characters of numbers and / or letters.
The PAGER_REQUIRED_FLAG column tells the system whether or not an operable pager must be assigned to the listing record in order for the status to be assigned to the user.
The COVERAGE_ALLOWED_FLAG column tells the system whether or not a record can cover for another record's paging while that status is set. For example, "OUT OF HOSPITAL ON PAGE" implies that although the person / function may not be in the building, they are still available for paging. Generally you wouldn't want to set a COVERAGE_ALLOWED_FLAG as true for a status that clearly states that the person is not available.
The ON_PAGER_ACTION column tells the system whether or not to place that record as pageable once the status is set (this can be seen in the listing form in Smart Center as the check box next to the "On Pager" label at the bottom). For example, you would set this to F if adding a status of "ON VACATION" and the record should no longer be pageable once this status is set.
The ONCALL_ALLOWED_FLAG tells the system whether or not a record can be in an active on call assignment. Someone may want a status where the PAGER_REQUIRED_FLAG is F but the ONCALL_ALLOWED_FLAG is T. Perhaps the record has no pager but has the instructions that contain the number that should be called in the event someone is needed; or a record with this status has a permanent referral and that's where someone should call.
The PAGE_ROUTE column is not required, but can be assigned to a status so that certain programs, such as eNotify, may select which pager to use when a person is paged.
The "-1" STATUS_CODE is used to enter custom text (such as by Smart Console users) that is not in the default list.
There is not a Smart Center form to allow direct interface to the STATUS_CODE table. Additions and removals must be made via the database. Removal of a STATUS_CODE that is in use (assigned to a record) is not allowed, so you would have to find all records with that STATUS_CODE and change them to something else before removing it.
When adding a new status, attention must be paid to the customer setup to ensure that a special prompt doesn't need to be created to add this STATUS_TEXT to the VOCAB table (which is a billable request, as it consists not only of creating a prompt and importing to the VOCAB table, but also editing vru initialization files so that the status is played back in the list of statuses).