Important: Versioning information - Preview
-This version of core is strictly a preview of what is currently in development for 1.2.0 and should not be built against.
+This version of core is strictly a preview of what is currently in development for 1.4.x and should not be built against.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Error-Handling/Failure-Scenarios-1-1-x/General-Failure-Scenarios.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Error-Handling/Failure-Scenarios-1-1-x/General-Failure-Scenarios.page.md
index bd03e6c7..7a9da6a0 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Error-Handling/Failure-Scenarios-1-1-x/General-Failure-Scenarios.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Error-Handling/Failure-Scenarios-1-1-x/General-Failure-Scenarios.page.md
@@ -14,7 +14,7 @@ This section will define errors that could be seen in any given step and shared
| 406 | SEND_NOT_ACCEPTABLE | processing | The requested resource is capable of generating only content not acceptable according to the Accept headers sent in the request. Versions in Accept or content.
Version is not present in FOT and should be ignored in FOT if presented. Post FOT it MUST be evaluated. | API |
| 406 | REC_NOT_ACCEPTABLE | processing | The requested resource is capable of generating only content not acceptable according to the Accept headers sent in the request. Versions in Accept or content.
Version is not present in FOT and should be ignored in FOT if presented. Post FOT it MUST be evaluated. | Receiver |
| 429 | SEND_TOO_MANY_REQUESTS | throttled | when rate limiting is applied. | API |
-| 409 | REC_TIMEOUT | timeout | Injected when a 504 is generated in the proxy due to a receiver timing out on a response. | API Injected |
+| 408 | REC_TIMEOUT | timeout | Injected when a 504 is generated in the proxy due to a receiver timing out on a response. | API Injected |
| 500 | REC_SERVER_ERROR | transient | An unexpected exception has occurred during processing at the receiver. | Receiver/ API Injected |
| 500 | PROXY_SERVER_ERROR / SERVER ERROR | transient | An unexpected exception has occurred during processing internally. | API |
| 501 | REC_NOT_IMPLEMENTED | not-supported | The receiver has not yet implemented that endpoint or functionality. | Receiver |
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Error-Handling/Failure-Scenarios-1-1-x/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Error-Handling/Failure-Scenarios-1-1-x/Introduction.page.md
index 3bffee33..4536a9e5 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Error-Handling/Failure-Scenarios-1-1-x/Introduction.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Error-Handling/Failure-Scenarios-1-1-x/Introduction.page.md
@@ -6,6 +6,6 @@ This page defines the foreseen failure scenarios within the BaRS standard and it
The rationale, described in the {{pagelink:core-failure_scenarios-1.4.1, text:error handling}} section is that as much information on the nature of the failure as possible is provided in a standard way.
-Each scenario has a Source to state whether it is the BaRS Proxy or the Receiver which is generating the error. In scenarios where a SEND prefix is used, the sender is not adhering to the API specification in one way or another. These codes are held within OperationOoutcome.issue.details.code and use the http-error-codes value set.
+Each scenario has a Source to state whether it is the BaRS Proxy or the Receiver which is generating the error. In scenarios where a SEND prefix is used, the sender is not adhering to the API specification in one way or another. These codes are held within OperationOutcome.issue.details.code and use the http-error-codes value set.
Note: in future, the PROXY prefix will no longer be used, and all errors from the Proxy will use a code with no prefix.
\ No newline at end of file
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Security-and-Authorisation/Receiver.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Security-and-Authorisation/Receiver.page.md
index 1f872628..944c18f1 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Security-and-Authorisation/Receiver.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Security-and-Authorisation/Receiver.page.md
@@ -8,9 +8,9 @@ BaRS will utilise TLS-MA (Mutual Authentication) to communicate with receiving e
- The receiver will need to request a certificate under the NHS Root CA
- There are two different certificate chains for INT and Prod
- - INT Certificate chains, which are superceded from 4/06/2024, can be found [here](https://digital.nhs.uk/services/path-to-live-environments/integration-environment#rootca-and-subca-certificates)
- - Prod Certificate chains,which expire from 4/06/2024, can be found [here](https://digital.nhs.uk/services/path-to-live-environments/live-environment)
- - **Current** INT Certificate chains can be found [here](https://pki.nhs.uk/G2Transition/)
+ - INT Certificate chains, which are superseded from 4/06/2024, can be found [here](https://digital.nhs.uk/services/path-to-live-environments/integration-environment#rootca-and-subca-certificates)
+ - Prod Certificate chains, which expire from 4/06/2024, can be found [here](https://digital.nhs.uk/services/path-to-live-environments/live-environment)
+ - **Current** INT Certificate chains can be found [here](https://pki.nhs.uk/G2Transition/)
- **Current** Prod Certificate chains can be found [here](https://pki.nhs.uk/G2Transition/)
- The receiving endpoint will present the certificate obtained for TLS-MA
@@ -25,7 +25,7 @@ In production there is a naming convention that must be adhered to. In INT the n
- ==BaRS-< ODSCode >.< OrganisationName >.nhs.uk== , BaRS is always the application name.
-Once you have you have your domain registered you can then begin the process to obtain your certificate by generating a certificate request.
+Once you have your domain registered you can then begin the process to obtain your certificate by generating a certificate request.
Certificate requests will need to be signed for your endpoint. Note that the FQDN is equal to the certificate name (CN) by convention.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Standard-Pattern-Composite-Messages/Message-Headers.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Standard-Pattern-Composite-Messages/Message-Headers.page.md
index 86ba1d80..fcc3aaa2 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Standard-Pattern-Composite-Messages/Message-Headers.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Standard-Pattern-Composite-Messages/Message-Headers.page.md
@@ -10,7 +10,7 @@ BaRS payloads (FHIR message bundles) require a **MessageHeader** FHIR resource w
The **MessageHeader** resource contains the following element which **must** be used as outlined:
* **MessageHeader.source** - stipulates where the payload originated. The Sender **must**, under **MessageHeader.source.endpoint**, include a valid URI which could be used as a NHSD-Target-Identifier (their reference on the Endpoint Catalogue) for the Receiver to send an asynchronous response.
* **MessageHeader.destination** - designates who the payload is intended for, including reference to an Organisation resource and a valid URI (*MessageHeader.destination.endpoint*) which is the NHSD-Target-Identifier (their reference on the Endpoint Catalogue) the payload is being sent to.
-* **MessageHeader.eventCoding** - determines the 'type' of payload, whether booking, referral, request or asynchronousus response. The value **must** be populated from this [CodeSystem](https://simplifier.net/NHSBookingandReferrals/message-events-bars). In referrals, this value, combined with the *ServiceRequest.category* element, allows supports for different styles of referral to support various use-cases. The value **must** be populated from CodeSystems for [specific type](https://simplifier.net/NHSDigital/message-category-servicerequest) and [use-case](https://simplifier.net/nhsbookingandreferrals/usecases-categories-bars).
+* **MessageHeader.eventCoding** - determines the 'type' of payload, whether booking, referral, request or asynchronous response. The value **must** be populated from this [CodeSystem](https://simplifier.net/NHSBookingandReferrals/message-events-bars). In referrals, this value, combined with the *ServiceRequest.category* element, allows for different styles of referral to support various use-cases. The value **must** be populated from CodeSystems for [specific type](https://simplifier.net/NHSDigital/message-category-servicerequest) and [use-case](https://simplifier.net/nhsbookingandreferrals/usecases-categories-bars).
* **MessageHeader.reason.code** - indicates whether the message is '**new**' or an '**update**' to something the Receiver is already aware of. The value **must** be populated from this [CodeSystem](https://simplifier.net/NHSBookingandReferrals/message-reason-bars).
* **MessageHeader.focus** - specifies the root resource through which to start interpreting the payload.
* **MessageHeader.definition** - cites the [MessageDefinition](https://simplifier.net/nhsbookingandreferrals/~resources?category=Example&exampletype=MessageDefinition&sortBy=DisplayName) the payload **must** adhere to and **must** be rejected by the Receiver if it fails to do so. Note: payload conformance to MessageDefinitions is not checked as part of FHIR validation.
@@ -20,7 +20,7 @@ When a Receiver begins to process the payload, they **must** initially ensure it
* check the **MessageHeader.destination.endpoint** is the Service ID they are expected to be processing the request on behalf of.
* Store **MessageHeader.source.endpoint** as NHSD-Target-Identifier to enable an asynchronous response back to the Sender. Not all workflows will require this type of response but this data must be stored for audit purposes.
-Certain elements in MessageHeader explicitly drive workflow, check **MessageHeader.eventCoding** to determine whether a booking or referral payload is being sent, and whether this is an initial or update request or an asynchronous response to a pre-existing request. There are various styles of referral too, a request could be made for a simple 'transfer of care' or, currently, something termed a 'validation', where one service requests another to validate the assessment outcome they have reached. The intention of supporting gradation of referral is to provide BaRS the malleability to support further subtlety of referrals for future use cases. Combining the **MessageHeader.eventCoding** with the **ServiceRequest.cateory** provides this functionality and, with the addition of {{pagelink:core-SPUseCaseCategories-1.4.1, text:use-case categories}} (again populated under **ServiceRequest.category**) specific services are pinpointed through every BaRS workflow.
+Certain elements in MessageHeader explicitly drive workflow, check **MessageHeader.eventCoding** to determine whether a booking or referral payload is being sent, and whether this is an initial or update request or an asynchronous response to a pre-existing request. There are various styles of referral too, a request could be made for a simple 'transfer of care' or, currently, something termed a 'validation', where one service requests another to validate the assessment outcome they have reached. The intention of supporting gradation of referral is to provide BaRS the malleability to support further subtlety of referrals for future use cases. Combining the **MessageHeader.eventCoding** with the **ServiceRequest.category** provides this functionality and, with the addition of {{pagelink:core-SPUseCaseCategories-1.4.1, text:use-case categories}} (again populated under **ServiceRequest.category**) specific services are pinpointed through every BaRS workflow.
Once the above checks have been made, the detail of the payload can start to be unpacked and processed. The structure of the payload **must** be checked first to ensure it adheres to the **MessageHeader.definition** it claims to. The [MessageDefinitions](https://simplifier.net/nhsbookingandreferrals/~resources?category=Example&exampletype=MessageDefinition&sortBy=DisplayName) will principally be defined by BaRS, at a national level (although bespoke definitions can be used through BaRS), and the Receiver is checking to ensure all mandatory FHIR resources are present and meet their assigned cardinality. This is a manual, business logic, check and not something which is supported through standard FHIR validation of the payload (bundle).
Next, **MessageHeader.focus** is the root resource through which the payload is intended to be understood. In an initial referral request, this will typically be the **ServiceRequest** FHIR resource. This root will link to other resources to build a narrative for the payload, for example, the **ServiceRequest** will link to the **Encounter** which led to the referral being made and the **Careplan** detailing next actions. The Entity Relationship Diagrams (included in each {{pagelink:Home/Applications/BaRS-Applications/Applications, text:Application}}) are used as a visual representation of the FHIR resource links in the payloads.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Transactional-integrity/Sender-responsibilities.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Transactional-integrity/Sender-responsibilities.page.md
index 558deee0..1c31061b 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Transactional-integrity/Sender-responsibilities.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Transactional-integrity/Sender-responsibilities.page.md
@@ -12,9 +12,9 @@ The frequency of retries and the duration of a retry period depends on the scena
- REC_TIMEOUT (408)
- REC_TOO_MANY_REQUESTS (429)
- REC_UNAVAILABLE (503)
--retry when an OperationOutcome from BaRS itself contains one of the following:
+- retry when an OperationOutcome from BaRS itself contains one of the following:
- PROXY_TIMEOUT / TIMEOUT (504 indicating 408 internally)
- - PROXY_TOO_MANY_REQUESTS / TOO_MANY_REQUESTS (500 indicating a 408 internally)
+ - PROXY_TOO_MANY_REQUESTS / TOO_MANY_REQUESTS (500 indicating a 429 internally)
- PROXY_UNAVAILABLE / UNAVAILABLE (503)
- retry when an OperationOutcome from the BaRS API contains one of the following:
- SEND_TOO_MANY_REQUESTS (429)
@@ -24,7 +24,7 @@ The frequency of retries and the duration of a retry period depends on the scena
- REC_CONFLICT (409)
- an operationOutcome.issue.code of "duplicate"
-Any intermediary network device responding 'on behalf or in lieu' of the API or the receiver is not likely to respond with an OperationalOutcome or the required X-Request-ID and X-Correlation-ID. Any response not having either one of these properties can be safely deemed a communications failure, a temporary interruption to connectivity or could potentially indicate a service outage. Any of these scenarios could, but not always, warrant an retry. This would be at the discretion of the suppliers however these failed interactions should be logged with as much detail as possible. Errors outside of the HTTP standard should also be logged locally with as much detail as possible, for example; Transport-Layer error messages.
+Any intermediary network device responding 'on behalf or in lieu' of the API or the receiver is not likely to respond with an OperationOutcome or the required X-Request-ID and X-Correlation-ID. Any response not having either one of these properties can be safely deemed a communications failure, a temporary interruption to connectivity or could potentially indicate a service outage. Any of these scenarios could, but not always, warrant a retry. This would be at the discretion of the suppliers however these failed interactions should be logged with as much detail as possible. Errors outside of the HTTP standard should also be logged locally with as much detail as possible, for example; Transport-Layer error messages.
\ No newline at end of file