Skip to content

Code map loading

mdlCodeMaps centralizes lookup tables used to translate NCCI and internal codes into enumerated types across Unit Stat reporting. Most maps are pure in-memory constants; three ("extended" maps) load their code/description pairs from database code tables the first time they are requested, then cache the result for the life of the process.

Field Value
Operation ID OP-US-06
Trigger Caller invokes any Get*Map function in mdlCodeMaps
Inputs For the three database-backed maps: an IDataPortalInfo and an optional refresh flag; the other maps take no parameters
Outputs A cached map object translating code values to strongly typed enumerations with descriptions
Primary components mdlCodeMaps.GetOffsetTypeMap, mdlCodeMaps.GetCostTypeMap, mdlCodeMaps.GetCalculationTypeMap, and the constant in-memory Get*Map functions (RunType, ReportType, UpdateType, ReportRecordType, ReportCorrectionType, NCCIClaimStatusCode, NCCIInjuryCode, NCCIClaimTypes, NCCILossActTypes, NCCILossTypes, NCCIRecoveryTypes, NCCISettlementTypes, NCCIFraudulentClaimTypes, ExposureCoverageCode, ValuationMap)
Entry point Business\SAIF.Business.UnitStat\mdlCodeMaps.vb

Steps

  1. In-memory maps. Most Get*Map functions (RunType, ReportType, UpdateType, ReportRecordType, ReportCorrectionType, NCCIClaimStatusCode, NCCIInjuryCode, NCCIClaimTypes, NCCILossActTypes, NCCILossTypes, NCCIRecoveryTypes, NCCISettlementTypes, NCCIFraudulentClaimTypes, ExposureCoverageCode, ValuationMap) hold their code/enum/description entries as hard-coded constants inside a Friend Sub New() constructor; the first call to each function builds the map once into a Static local variable and every subsequent call in the same process returns the same cached instance. These maps have no database dependency.
  2. Database-backed map dispatch. GetOffsetTypeMap(dpi, refresh), GetCostTypeMap(dpi, refresh), and GetCalculationTypeMap(dpi, refresh) each check a Static cache variable: if refresh is True or the cache is Nothing, a new map instance is constructed by querying its backing code table; otherwise the cached instance is returned immediately without any database access.
  3. Offset type map. clsOffsetTypeMap's constructor runs SELECT code, code_descr FROM us_offset_type_code (SQL-019, US_OFFSET_TYPE_CODE) and maps each row's trimmed, upper-cased code value against a fixed Select Case (FRDI, FRDP, FFRD, NDI, NDP, TPP, TPN, RFN, VOID) to the corresponding OffsetTypes enum member.
  4. Cost type map. clsCostTypeMap's constructor runs SELECT code, code_descr FROM us_cost_type_code (SQL-018, US_COST_TYPE_CODE) and maps BOTH, INC, PAID, NONE to the corresponding CostTypes enum member.
  5. Calculation type map. clsCalculationTypeMap's constructor runs SELECT code, code_descr FROM calculation_type_code (SQL-017, CALCULATION_TYPE_CODE) and maps ADD, SUB, MULT, DIV, MIN, MAX, NONE to the corresponding CalculationTypes enum member.
  6. Unmatched codes are dropped. In all three database-backed maps, a database row whose code value does not match any case in the Select Case block is simply skipped (the Case block has no Case Else), so an unrecognized or newly added database code value is silently excluded from the map rather than raising an error or a default/unknown enum entry.*
  7. Refresh is opt-in and per-process. Because each map is cached in a Static variable local to its function, the cache is scoped to the application process/domain, not to any particular data-portal call; callers must explicitly pass refresh:=True to force a reload after the underlying code table changes, and even then only that single process's cache is refreshed.

Process flow

flowchart TD
    Start([Caller invokes a Get_Map function]) --> Which{In-memory map or<br>database-backed map?}
    Which -->|In-memory| CachedA{Static cache<br>already built?}
    CachedA -->|Yes| ReturnA([Return cached constant map])
    CachedA -->|No| BuildA[Build map from<br>hard-coded constants]
    BuildA --> ReturnA
    Which -->|Database-backed| CachedB{refresh=True or<br>cache empty?}
    CachedB -->|No| ReturnB([Return cached map,<br>no DB access])
    CachedB -->|Yes| Query[Query backing code table:<br>US_OFFSET_TYPE_CODE,<br>US_COST_TYPE_CODE, or<br>CALCULATION_TYPE_CODE]
    Query --> MatchLoop{For each row,<br>code matches a<br>known Case?}
    MatchLoop -->|Yes| AddEntry[Add code to enum<br>mapping with description]
    MatchLoop -->|No| Drop([Row silently dropped])
    AddEntry --> CacheB[Cache built map]
    Drop --> CacheB
    CacheB --> ReturnB

Failure and edge-case behavior

  • Any code value present in US_OFFSET_TYPE_CODE, US_COST_TYPE_CODE, or CALCULATION_TYPE_CODE that does not match one of the hard-coded Case values is silently excluded from its map, with no logging, error, or fallback "unknown" entry — a new or renamed database code requires a corresponding code change in mdlCodeMaps.vb to be usable.*
  • The three database-backed maps are cached per process via Static variables; a refresh:=True call only affects the calling process's cache, so multi-process deployments may see stale maps until each process independently refreshes or restarts.*
  • The in-memory maps have no database dependency at all and cannot become stale relative to a database code table, but conversely cannot pick up new codes without a code change and redeploy.

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.UnitStat\mdlCodeMaps.vb