Add specific structure and notes to code, process and process_event t…

…ypes

Signed-off-by: Jeremy Ho <jujaga@gmail.com>

docs/spec/data/code.mdx

@@ -1,7 +1,7 @@
 ---
 id: code
 title: Code
-description: A code type
+description: A code type.
 tags:
   - developer
 ---
@@ -23,7 +23,10 @@ concept, element or idea.
 
 ## Structure
 
-Type: `string`
+| Attribute | Value | Description & Constraints |
+| --- | --- | --- |
+| Type | `string` | |
+| Regex Pattern | `^[^\s]+( [^\s]+)*$` | String which has at least one character and no leading or trailing whitespace, and where there is no whitespace other than single spaces in the contents. |
 
 ## Specification
 
@@ -44,8 +47,10 @@ Type: `string`
 
 ## Implementation Notes
 
-TBD
+This data structure is mainly meant to illustrate and restrict what is allowed to be encoded for an arbitrary code
+value. This is meant to only be used as a semantic reference point. This data structure is loosely inspired by the
+[FHIR Code Type](https://www.hl7.org/fhir/datatypes.html#code).
 
 ## References
 
-TBD
+- [FHIR Code Type](https://www.hl7.org/fhir/datatypes.html#code)

docs/spec/data/process.mdx

@@ -25,13 +25,26 @@ Loosely taking inspiration from [HL7 Timing](https://www.hl7.org/fhir/datatypes.
 
 ## Structure
 
+- A Process shall always contain a `class` and `concept` attribute.
+  - The `class` ordered set shall have at least one concept, and no more than three concepts defined. Classes do not
+  require the full path hierarchy defined depending on what the intention of the concept being shared.
+- A Process may contain a `status` attribute.
+  - The `status` attribute acts as a free text field which represents the specific status value that may be stored or
+  encoded in the transmitting system.
+  - If `status` is defined, the `description` and `status_code` attributes may optionally be defined as well.
+- The recipient system shall primarily rely on the `class` and `concept` attributes.
+  - Recipient systems may choose to parse the `status`, `description` and `status_code` attributes as auxiliary or
+  supplementary data.
+  - Recipient systems shall not depend on these attributes as they are not guaranteed to exist, nor do they convey the
+  standard concept hierarchy as defined by this specification.
+
 | Name | Cardinality | Type | Description & Constraints |
 | --- | --- | --- | --- |
-| class | 1..* | `string` | TBD |
-| concept | 1..1 | `string` | TBD |
-| description | 0..1 | `string` | TBD |
-| status | 0..1 | `string` | TBD |
-| status_code | 0..1 | `string` | TBD |
+| class | 1..* | `string[]` | An ordered set of process tracking terms. |
+| concept | 1..1 | `string` | A URI reference to the concept map encodings used. |
+| description | 0..1 | `string` | An optional description of the status if present. |
+| status | 0..1 | `string` | An optional description of the current condition or update of an application or authorization. Additional details about the current state are frequently conveyed (e.g., 'Pending Review', 'Under Inspection'). Statuses may be defined by the line of business. |
+| status_code | 0..1 | [Code](./code) | An optional codified representation of the status attribute. Status codes may be defined by the line of business. |
 
 ## Specification
 
@@ -57,8 +70,33 @@ Loosely taking inspiration from [HL7 Timing](https://www.hl7.org/fhir/datatypes.
 
 ## Implementation Notes
 
-TBD
+The core of the process type is the representation of one of the paths in the
+[Process Tracking Concept Map](../concept/process_tracking). This is represented in the `class` attribute as an ordered
+tuple. Each entry in the ordered set represents a specific detail level in the hierarchy. For example, the array value
+of `["Application", "Review", "Assessment"]` would indicate that the process concept being conveyed is representing the
+`Assessment` Stage within the `Review` Phase of an `Application` Lifecycle.
+
+The class array may be populated with fewer elements in situations where the concept being mapped represents a higher
+level concept. For example, if the `class` attribute only contains the array value of `["Application", "Review"]`, that
+means that only the `Review` Phase of an `Application` Lifecycle is represented; the more detailed Stage concept is not
+encoded. Systems reading the `class` attribute may extract a subset of the transmitted ordered array for processing
+since the lower level concepts map to higher level concepts in the concept map.
+
+The `concept` attribute is a static URI reference to the documentation for the current concept map being used. This URI
+is not intended to be machine readable as it is designed to act as a signal for human readers to see and understand the
+context of which terminologies and concepts are being conveyed.
+
+The `status` attribute is optional, but is designed to be an explicit "escape hatch" for specific lines of business to
+share their most detailed system concepts, should they choose to do so. Statuses declared here will be implicitly
+mapped under the declared `class` ordered tuple. If a `status` is defined, the `description` and `status_code`
+attributes may also be defined in order to assist with clarifying the status value.
+
+Recipient systems may look at `status`, `status_code` and `description` as a reference point. However, the core intent
+of this data type is to ensure that the core `class` attribute to be the main source of truth when handling and
+interpreting the data for processing. Recipient systems SHOULD NOT depend on either `status`, `status_code` or
+`description` attributes when parsing and interpreting the process concept.
 
 ## References
 
-TBD
+- [Code](./code)
+- [Process Tracking Concept Map](../concept/process_tracking)

docs/spec/data/process.schema.json

@@ -7,7 +7,7 @@
   "properties": {
     "class": {
       "type": "array",
-      "description": "A process tracking term.",
+      "description": "An ordered set of process tracking terms.",
       "items": {
         "type": "string",
         "description": "A process tracking term."
@@ -18,7 +18,7 @@
     },
     "concept": {
       "type": "string",
-      "description": "A reference to the concept map encodings used.",
+      "description": "A URI reference to the concept map encodings used.",
       "format": "uri",
       "pattern": "^https://bcgov.github.io/nr-pies/docs/concept/*$"
     },
@@ -32,7 +32,8 @@
     },
     "status_code": {
       "description": "An optional codified representation of the status attribute. Status codes may be defined by the line of business.",
-      "type": "string"
+      "type": "string",
+      "pattern": "^[^\\s]+( [^\\s]+)*$"
     }
   },
   "required": ["class", "concept"]

docs/spec/resource/process_event.mdx

@@ -54,8 +54,12 @@ Loosely taking inspiration from [HL7 Timing](https://www.hl7.org/fhir/datatypes.
 
 ## Implementation Notes
 
-TBD
+The Process Event type is designed to act as a container data type representing a cartesian product between the
+[Event](../data/event) and [Process](../data/process) data types. Both data types are required in order to have a
+semantically coherent Process Event. Recipient systems will be able to associate a specific process happening at a
+defined time using this data type.
 
 ## References
 
-TBD
+- [Event](../data/event)
+- [Process](../data/process)