Compliance Item Codes OSH

by

Overview

Compliance.item_codes_osh provides a structured, business-ready item code view of OSH incident and safety form records. It consolidates form-level and location-related attributes from the source OSH records into a single consistent pattern so that incident, safety, and compliance information can be queried in the same way as other itemised CDM-style views.

This view is designed to support operational reporting, trend analysis, audit activity, and compliance review by exposing source form content as discrete code-based attributes with supporting metadata.

Business Purpose

The purpose of this view is to make OSH form data easier to consume for reporting and analysis.

Rather than requiring users to navigate the source form system or interpret many individual source columns, the view presents the records as structured item attributes. This makes it easier to:

  • analyse incident and safety records consistently
  • identify reporting persons and involved persons
  • review form status and lifecycle signals
  • assess where events occurred, including region, country, company, and business location
  • support compliance, EHS, operational assurance, and management reporting

This view is particularly useful where the business wants to treat incident forms as analysable records rather than as semi-structured source entries.

View Pattern

This is an item codes view.

That means the view stores descriptive or categorical attributes as rows, rather than widening them into columns. Each incident form can therefore emit multiple coded attributes under one or more item types.

The view currently uses two item groupings:

  • FORMS – form and reporting-related attributes
  • LOCATION – location and organisational context attributes

This approach keeps the structure modular and supports flexible downstream pivoting where needed.

Grain

The grain of the view is:

one row per
OBJECT_SEQ + ITEM_KEY + ITEM_TYPE + ATTRIBUTE

In practical terms, this means each OSH document can produce multiple attribute rows for the same item, such as form, module, status, reporting person, region, country, and business area.

Object and Item Identity

OBJECT_SEQ

OBJECT_SEQ identifies the compliance record at document level.

For this view it is defined as:

{"DOC_NO":"000123"}

This means the business object is the OSH document or form record itself, keyed by zero-padded document number.

ITEM_KEY

ITEM_KEY identifies the item instance within the object.

For this view it is defined as:

{"FORM":"<module>","SEQ_NO_KEY":"<form>|<sourceID>"}

This allows the view to distinguish the specific form occurrence associated with the document.

ITEM_TYPE

ITEM_TYPE separates the item into logical business groupings:

  • FORMS
  • LOCATION

This gives a clean way to organise related attributes without overloading a single flat attribute list.

Source

The view is sourced from:

  • osh.myosh_records_forms

This source appears to contain incident and safety reporting records with associated form, status, people, timing, and location fields.

The source is recorded in SOURCE_SYSTEM as:

{"Source":"osh.myosh_records_forms"}

Key Features

1. Business-ready decomposition of OSH forms

The source form record is broken into discrete attributes that are easier to filter, pivot, and analyse.

2. Consistent item-code structure

The output aligns with the broader item-based modelling pattern used elsewhere, allowing incident data to be consumed in a standard way.

3. Separation of form and location context

By dividing output into FORMS and LOCATION, the view makes it easier to understand the role of each attribute family.

4. Metadata-rich code values

Each attribute is supplied with VALUE_METADATA, generally including a CODE and, where useful, a human-readable DESC.

5. Hash-based handling of descriptive identities

Where person or location-style labels may not have a stable enterprise key, hashed short codes are used as the CODE_VALUE, with the readable value preserved in metadata.

Attribute Groups

ITEM_TYPE = FORMS

This item type captures the main record and reporting context of the OSH form.

Attributes

MODULE

The module from which the form record originates.

Metadata includes:

  • CODE = source module
  • DESC = module name

FORM

The form identifier or form type.

Metadata includes:

  • CODE = form code
  • DESC = form name

MODIFIED_DATE

The last modified date of the form, expressed as a date code.

Metadata includes:

  • CODE = modified date
  • DESC = person associated with completion or authoring context where available

This is slightly unusual in that the description carries a person reference rather than a label for the date itself, but it may be useful for traceability.

ARCHIVED

Indicates whether the form has an archived step value.

Only non-zero archive values are emitted.

STATUS

The form or workflow status.

Metadata includes:

  • CODE = status value

REPORTING_PERSON

Represents the person reporting or completing the report.

The code value is an 8-character MD5-derived hash based on the first available value from:

  • person completing report
  • person reporting incident
  • keyword author

Metadata includes:

  • CODE = hashed identifier
  • DESC = source person text

This gives a stable short-form reference without exposing the raw reporting text as the main code.

REPORTED

The date the incident or record was reported.

Derived from:

  • date_reported
  • or creationDate where date_reported is not available

Metadata includes:

  • CODE = reported date

INVOLVED_PERSON

Represents the person involved in the incident or event.

The value is derived from the first available of:

  • person involved category
  • accountable person
  • person reporting incident
  • keyword author

Metadata includes:

  • CODE = hashed identifier
  • DESC = source person text

This field is useful, though it should be noted that the fallback chain may represent a broad notion of “involved” rather than a tightly governed person identity.

DESCRIPTION

Carries the brief description of the incident or record.

Where a brief description exists, the CODE_VALUE is the padded document number and the description text is placed into metadata.

Metadata includes:

  • CODE = padded document number
  • DESC = brief description text

This allows the description to be retained within the code/value pattern without placing long free text into the core code field.

ITEM_TYPE = LOCATION

This item type captures organisational and physical context for the form.

Attributes

REGION

Region associated with the record.

Stored as:

  • CODE_VALUE = 8-character MD5-derived hash of region
  • metadata DESC = original region text

COUNTRY

Country associated with the record.

Stored directly as the country code or value.

TYPE

Location type.

Stored as:

  • CODE_VALUE = hash of location type
  • metadata DESC = location type text

COMPANY

Legal entity or company associated with the record.

Stored as:

  • CODE_VALUE = hash of legal entity
  • metadata DESC = legal entity text

BUSINESS_AREA

Business area associated with the record.

Stored as:

  • CODE_VALUE = hash of business area
  • metadata DESC = business area text

BUSINESS_AREA_SUB

Sub-business area associated with the record.

Stored as:

  • CODE_VALUE = hash of sub-business area
  • metadata DESC = sub-business area text

BUSINESS_LOCATION

Business location associated with the record.

Stored as:

  • CODE_VALUE = hash of location
  • metadata DESC = location text

Output Fields

The final output contains:

  • OBJECT_SEQ
  • ITEM_KEY
  • ITEM_TYPE
  • ATTRIBUTE
  • CODE_VALUE
  • VALUE_METADATA
  • CREATE_DATE
  • EXPIRY_DATE
  • SOURCE_SYSTEM
  • ACTIVE_FLAG
  • CHECKSUM

Audit and History Behaviour

This view currently behaves as a current-state style output.

Audit fields

  • CREATE_DATE = current date at runtime
  • EXPIRY_DATE = 2099-12-31
  • ACTIVE_FLAG = 1

Checksum

A checksum is generated from:

  • OBJECT_SEQ
  • ITEM_KEY
  • ATTRIBUTE
  • CODE_VALUE

This supports change detection and potential future historical handling.

Design Notes

1. Descriptive values are often retained in metadata

Several attributes use a hashed or abbreviated CODE_VALUE while keeping the readable description in VALUE_METADATA. This is a sensible pattern where the source text is long, inconsistent, or not governed as a master key.

2. Person-related attributes are pragmatic, not canonical

REPORTING_PERSON and INVOLVED_PERSON are based on available source text and fallback logic. They are useful for grouping and traceability, but they should not yet be assumed to represent a fully governed enterprise person model.

3. Description is carried as metadata

The incident description is stored in VALUE_METADATA rather than as a separate value-text field. That fits the item-code pattern, but downstream consumers should be aware that meaningful narrative content lives inside metadata.

4. Country is treated differently from other location fields

Unlike most location attributes, COUNTRY is emitted directly rather than hashed. That is reasonable if the country values are already compact and well governed.

Reporting Guidance

This view is well suited to:

  • compliance dashboards
  • EHS and incident reporting
  • audit and assurance review
  • operational safety analysis
  • filtering incidents by region, country, company, or business area
  • tracking forms by status or archive state
  • identifying who reported or was associated with a record

Typical reporting patterns may include:

  • count of incidents by status
  • incidents by region or business area
  • incidents reported over time
  • incidents by reporting person or involved person grouping
  • archived versus active workflow review

Usage Considerations

Use ITEM_TYPE to separate context

Consumers should normally filter or pivot with awareness of ITEM_TYPE, especially where similar-looking attributes may belong to different business contexts.

Do not expand the structural keys

OBJECT_SEQ and ITEM_KEY should be treated as linking fields. They were designed to preserve stable object-item relationships and should not be manually decomposed in reporting unless there is a very specific technical reason.

Use metadata for business labels

For hashed values such as region, company, business area, and person-related fields, the readable business label should be taken from VALUE_METADATA.

Treat person values carefully

These person references are useful for analysis, but they are source-derived and may need later alignment to a broader identity model if this domain develops further.

Example Use Cases

Example 1: Incident status reporting

Filter ITEM_TYPE = 'FORMS' and ATTRIBUTE = 'STATUS' to analyse the distribution of OSH records by current status.

Example 2: Geographic review

Filter ITEM_TYPE = 'LOCATION' and use attributes such as REGION, COUNTRY, and BUSINESS_LOCATION to review where incidents are occurring.

Example 3: Reporter analysis

Filter ATTRIBUTE = 'REPORTING_PERSON' and use VALUE_METADATA.DESC to identify patterns in who is submitting reports.

Example 4: Incident narrative lookup

Filter ATTRIBUTE = 'DESCRIPTION' to recover brief description text from metadata for audit or case review.

Known Limitations

  • Person attribution is source-derived and not yet linked to a canonical person domain.
  • Free-text description is embedded in metadata rather than surfaced as a dedicated text field.
  • MODIFIED_DATE metadata uses a person description pattern, which may not be immediately intuitive to all consumers.
  • The business object is keyed by OSH document number, so any wider compliance case model would need additional design if introduced later.

Summary

Compliance.item_codes_osh is a strong first view for the new compliance-oriented domain. It turns OSH incident and safety forms into a standardised, analysable item-code structure, preserving both operational usability and modelling discipline. It gives the business a practical foundation for compliance and safety reporting while still leaving room for later maturity around identity, case modelling, and wider domain integration.

Leave a Comment