Skip to main content

Record ๐Ÿ“

Maturity

Official URL: https://bcgov.github.io/nr-pies/docs/spec/element/message/record

JSON Schema URL: https://raw.githubusercontent.com/bcgov/nr-pies/refs/heads/main/docs/spec/element/message/record.schema.json

Represents a specific record.

Scopeโ€‹

This message type is intended to represent an atomic Record originating from a source system. This will commonly be used for sharing a record's process and on hold history. Use cases may include auditing, reporting or compliance.

Note that this message type does not guarantee nor expect all known attributes to be present. It is possible for this message to only represent a subset of a canonically complete Record.

Structureโ€‹

A Record shall contain every standard message Header property, in addition to the following properties:

NameCardinalityTypeDescription & Constraints
on_hold_event_set0..1CodingEventA set of CodingEvents. Represents a set of on hold concepts at a specific event in time.
process_event_set0..1ProcessEventA set of ProcessEvents. Represents a set of unique process concepts at a specific event in time.

Specificationโ€‹

Loading ....

Implementation Guidanceโ€‹

The Record message type is designed to aggregate CodingEvent and ProcessEvent resources.

Systems generating this message should provide all known element definitions associated with a record whenever possible. However, recipient systems must not assume that a single message provides the full data horizon of all attributes. If a comprehensive data set is required, recipient systems must request any additional associated Records.

Temporal Integrity and Workflowโ€‹

The process_event_set represents the lifecycle of a record. To ensure this history is actionable for auditing and reporting, implementations should follow these constraints:

Implicit Linear Flowโ€‹

The application process follows an implicit chronological progression (such as from SUBMITTED to TECHNICAL_REVIEW to ALLOWED).

  • While the message may represent a subset of data, the events within the set should be sequence-aware.
  • "Backward" jumps in state are strongly discouraged in the Application Process workflow.

Reference the Canonical Flow in the Application Process code system for specific details.

Uniqueness of Event Setsโ€‹

To maintain a clean parseable process event sequence, all process_event_set elements must have unique codes.

  • Systems shall not emit or repeat multiple active process_event entries with the same code for the same record.
  • Map business domain transitions directly to the Application Process code system. Avoid intermediary code transformations that alias or misrepresent the source event.

Handling Stalls and Overlapsโ€‹

When a process is stalled (such as waiting for applicant information during a technical review), use the on_hold_event_set to provide additional context.

  • A stalled process_event with multiple associated on_hold_event records should remain open and in effect for the duration of the stall.
  • Populate the on_hold_event_set with granular events to explain the delay. This enables recipient systems to calculate the "net time" by subtracting on-hold duration from total process_event duration.

Referencesโ€‹