Skip to content

Vocational coordinators

Vocational coordinators is the reference-data and validation side of a vocational detail. Reading a coordinator, provider, counselor, status, or status-detail list resolves process-wide lookup data that is cached in shared variables for the lifetime of the application domain, and the object's rule set then requires the selected codes on a dirty record to resolve against those cached lists. None of these lookups is claim-specific, and none of the rules involved is registered in the library's catalogued business rules.*

Field Value
Operation ID OP-CM-06
Trigger A getter reads CoordinatorsList, CoordinatorName, or a sibling reference list, or the framework evaluates the vocational detail's rules during validation
Inputs Data-portal info taken from the object's criteria; no caller-supplied parameters — the coordinator, provider, status, and status-detail lookups are process-wide reference data
Outputs A cached dictionary of coordinator code to coordinator user; a derived coordinator display name; a cached provider-location collection for rehab providers and counselors; a cached dictionary of status codes and names; a cached list of status-detail code, status code, and description rows; broken rules when a selected code does not resolve
Primary components clsVocationalDetail (CoordinatorsList, CoordinatorName, GetCoordinatorList, GetRehabProviderList, CounselorList, StatusList, StatusName, StatusDetailList, GetStatusList, GetStatusDetailList, AddBusinessRules and its rule methods), clsVocationalStatusDetail
Entry point Business\SAIF.Business.Claim.Maintenance\clsVocationalDetail.vb

Steps

  1. Request the coordinator list. A getter or rule evaluation reads CoordinatorsList, which calls the shared helper GetCoordinatorList with the criteria's data-portal info; the cache is checked before any database access.
  2. Populate the cache on first use. When the shared coordinator dictionary is still empty, call the code-list helper against the vocational package's coordinator entry point, keyed by the code column and valued by the coordinator user column, flagged as a stored-procedure call.*
  3. Execute the lookup. The code-list helper runs the stored procedure through the standard request and cursor pattern and materializes the returned rows into a dictionary of code to coordinator user.
  4. Reuse the cache. Because the dictionary is declared shared, it lives for the lifetime of the process, so later calls from any vocational-detail instance skip the round trip entirely.
  5. Resolve the coordinator name. CoordinatorName looks the object's responsibility code up in the cached dictionary and returns the coordinator's display name, or an empty string when the code does not resolve.
  6. Validate the responsibility code. When the object is dirty, the coordinator rule requires a non-blank responsibility code that resolves to a known coordinator name; otherwise it reports that a coordinator is required.*
  7. Resolve and validate the rehab provider. The rehab-provider list caches a provider-location retrieval for the vocational provider type, filtered to locations with a non-empty physical address; the provider rule then requires a selected rehab-provider location, when one is chosen, to appear in that cached list.*
  8. Sub-step: the provider-location retrieval loads the vocational provider locations and their addresses, which this operation only filters and caches.

Origin: clsProviderLocationCollection.GetProviderLocations is implemented in SAIF.BOF.Business.View.Provider and executed on behalf of this operation. That library is documented in the previous format, so no per-operation page exists; see Operations and processes in the SAIF.BOF.Business.View.Provider documentation set. 8. Derive and validate the counselor. The counselor list is derived from the selected rehab provider's related provider locations filtered to the vocational provider type, and is computed only when a rehab provider is set. - The counselor rule requires a selected counselor location to appear in that filtered list, short-circuiting when the list is not available. - A companion rule requires a rehab provider to be selected whenever a counselor is selected.* 9. Resolve and validate the status code. The status list caches an inline select of code and description from the VOCATIONAL_STATUS_CODE lookup table, ordered by description; the status rule requires a non-blank status code that resolves to a name when the object is dirty. That lookup table is not catalogued in the library's SQL or table inventories.* 10. Resolve and validate the status detail. The parameterless status-detail helper caches an inline select of all rows from the VOCATIONAL_STATUS_DETAIL_CODE table, and the status-scoped overload filters that cached list in memory to rows whose status code matches the current status or is blank.* - Each row is materialized as a status-detail object carrying code, status code, and description. - The status-detail rule requires a non-blank, resolvable status detail only when more than one option exists for the current status code. 11. Validate the status date. A further rule requires the status date, when the object is dirty, to fall between 1 January 1850 and thirty days from today; it performs no data access. 12. Register and evaluate the rules. All of these rules are registered once per instance from both constructors and are evaluated whenever the framework runs validation — typically before a caller attempts to save the vocational detail.

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([Getter or rule reads<br>a vocational reference list]) --> Which{Which list?}
    Which -->|Coordinators| CCache{Shared cache populated?}
    Which -->|Rehab providers| PCache{Shared cache populated?}
    Which -->|Statuses| SCache{Shared cache populated?}
    Which -->|Status details| DCache{Shared cache populated?}
    Which -->|Counselors| Prov{Rehab provider selected?}
    CCache -->|No| CLoad[Call coordinator<br>stored procedure via code-list helper]
    CCache -->|Yes| Use[Return cached list]
    PCache -->|No| PLoad[Retrieve vocational provider locations<br>with a physical address]
    PCache -->|Yes| Use
    SCache -->|No| SLoad[Inline select of<br>vocational status codes]
    SCache -->|Yes| Use
    DCache -->|No| DLoad[Inline select of<br>vocational status details]
    DCache -->|Yes| Use
    Prov -->|No| NoList[Counselor list unavailable]
    Prov -->|Yes| Derive[Filter provider's related<br>locations to vocational type]
    CLoad --> Use
    PLoad --> Use
    SLoad --> Use
    DLoad --> Use
    Derive --> Use
    NoList --> Rules
    Use --> Rules{Object dirty?}
    Rules -->|No| Skip([Rules not evaluated])
    Rules -->|Yes| Check[Require coordinator, status,<br>status detail, status date,<br>provider, and counselor to resolve]
    Check --> Result{All resolve?}
    Result -->|No| Broken([Broken rules reported;<br>object invalid])
    Result -->|Yes| Valid([Object valid])

Failure and edge-case behavior

  • The vocational package was not found in the Oracle catalog during retrieval; if the package is genuinely absent in a given environment, the coordinator lookup would fail at execution time with a database error rather than returning a graceful empty result.**
  • Shared caching means the first data-portal info — and therefore the first connection and tenant context — used to populate each list determines the data for the rest of the process lifetime; reference-data changes are not reflected until the process restarts.*
  • The coordinator, status, and status-detail name resolvers return an empty string rather than throwing when the current code does not resolve, silently masking bad or stale codes in read-only display scenarios.
  • The status-detail rule is enforced only when more than one status-detail option exists for the current status, so a blank status detail passes validation for a status with zero or one option even though its resolved name may be empty.
  • The counselor list is computed only when a rehab provider is set; the counselor rule guards against the missing list before testing membership.
  • All of these rules evaluate only when the object is dirty, so a record loaded from the database and never modified is not re-validated even if the underlying reference data has since become stale or invalid.

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts. Statements marked with ** could not be confirmed; treat as unknown until verified.

Sources

  • Business\SAIF.Business.Claim.Maintenance\clsVocationalDetail.vb
  • Business\SAIF.Business.Claim.Maintenance\clsVocationalStatusDetail.vb