Record ๐
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:
| Name | Cardinality | Type | Description & Constraints |
|---|---|---|---|
| on_hold_event_set | 0..1 | CodingEvent | A set of CodingEvents. Represents a set of on hold concepts at a specific event in time. |
| process_event_set | 0..1 | ProcessEvent | A set of ProcessEvents. Represents a set of unique process concepts at a specific event in time. |
Specificationโ
- Schema
- Source
- Example
{
"$id": "https://raw.githubusercontent.com/bcgov/nr-pies/refs/heads/main/docs/spec/element/message/record.schema.json",
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "Record",
"description": "Represents a specific record.",
"type": "object",
"properties": {
"on_hold_event_set": {
"type": "array",
"items": {
"$ref": "https://raw.githubusercontent.com/bcgov/nr-pies/refs/heads/main/docs/spec/element/resource/coding_event.schema.json"
},
"uniqueItems": true
},
"process_event_set": {
"type": "array",
"items": {
"$ref": "https://raw.githubusercontent.com/bcgov/nr-pies/refs/heads/main/docs/spec/element/resource/process_event.schema.json"
},
"uniqueItems": true
}
},
"allOf": [
{
"$ref": "https://raw.githubusercontent.com/bcgov/nr-pies/refs/heads/main/docs/spec/element/data/header.schema.json"
}
]
}
{
"transaction_id": "01950719-b154-72f5-8437-5572df032a69",
"version": "0.1.0",
"kind": "Record",
"system_id": "ITSM-5917",
"record_id": "06bc53dc-3e4f-420b-801c-bd9cc0ea01b2",
"record_kind": "Permit",
"on_hold_event_set": [
{
"event": {
"start_date": "2024-12-10",
"end_date": "2024-12-20"
},
"coding": {
"code": "MISSING_INFORMATION",
"code_set": [
"MISSING_INFORMATION"
],
"code_system": "https://bcgov.github.io/nr-pies/docs/spec/code_system/on_hold_process"
}
}
],
"process_event_set": [
{
"event": {
"start_datetime": "2024-11-30T00:21:20.575Z"
},
"process": {
"code": "PRE_APPLICATION",
"code_display": "Pre-Application",
"code_set": [
"APPLICATION",
"PRE_APPLICATION"
],
"code_system": "https://bcgov.github.io/nr-pies/docs/spec/code_system/application_process"
}
},
{
"event": {
"start_date": "2024-12-01",
"end_date": "2024-12-31"
},
"process": {
"code": "REFERRAL",
"code_set": [
"APPLICATION",
"TECH_REVIEW_COMMENT",
"REFERRAL"
],
"code_system": "https://bcgov.github.io/nr-pies/docs/spec/code_system/application_process",
"status": "Auditing",
"status_code": "AU",
"status_description": "The authorization request is under review by subject matter expert."
}
},
{
"event": {
"start_date": "2025-01-01"
},
"process": {
"code": "DISALLOWED",
"code_set": [
"APPLICATION",
"DECISION",
"DISALLOWED"
],
"code_system": "https://bcgov.github.io/nr-pies/docs/spec/code_system/application_process",
"status": "DeclinedConflict",
"status_description": "The authorization request has not been allowed due to a conflict of interest."
}
}
]
}
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_evententries 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_eventwith multiple associatedon_hold_eventrecords should remain open and in effect for the duration of the stall. - Populate the
on_hold_event_setwith granular events to explain the delay. This enables recipient systems to calculate the "net time" by subtracting on-hold duration from totalprocess_eventduration.