20260703 DD IG 1.12.0

CodeSystem/usecases-categories-bars.xml

@@ -60,6 +60,18 @@
     <code value="a1t9" />
     <display value="999 to SDEC" />
   </concept>
+  <concept>
+    <code value="a1t10" />
+    <display value="111 to UEC" />
+  </concept>
+  <concept>
+    <code value="a1t11" />
+    <display value="IUC CAS to UEC" />
+  </concept>
+  <concept>
+    <code value="a1t12" />
+    <display value="999 to UEC" />
+  </concept>
   <concept>
     <code value="a2t1" />
     <display value="111 Online to ED" />
@@ -76,6 +88,14 @@
     <code value="a2t4" />
     <display value="S and R to UTC" />
   </concept>
+  <concept>
+    <code value="a2t5" />
+    <display value="111 Online to UEC" />
+  </concept>
+  <concept>
+    <code value="a2t6" />
+    <display value="S and R to UEC" />
+  </concept>
   <concept>
     <code value="a3t1" />
     <display value="999 to CAS Referral" />
@@ -92,6 +112,10 @@
     <code value="a4t3" />
     <display value="999 to Community Services" />
   </concept>
+  <concept>
+    <code value="a4t4" />
+    <display value="999 to UEC Validation" />
+  </concept>
   <concept>
     <code value="a5t1" />
     <display value="Primary Care to Community Pharmacy" />

guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.0.1.page.md

@@ -9,18 +9,18 @@
 | Change                                           | Description                                                                                              |
 |--------------------------------------------------|----------------------------------------------------------------------------------------------------------|
 | Fixed issue with menu in Design/BaRS Core        | The "Failure Scenarios" subsection had an erroneous entry in left-hand navigation. This has been removed | 
-| Updated release notes structure                  | This change was to accomodate historical releases by hiding them in an expander                          |
+| Updated release notes structure                  | This change was to accommodate historical releases by hiding them in an expander                          |
 | Improved release notes navigation                | a "back" button was added to each of the release note detail sections                                    |
 | Updated FHIR assets section                      | Simplified approach with a link out to the full Simplifier project                                       |
-| TKW - Updated context description                | Now includes detail of deployment on INT and rationale adopting this appraoch                            |
+| TKW - Updated context description                | Now includes detail of deployment on INT and rationale adopting this approach                            |
 | TKW - Corrected sentinel values                  | Some sentinel values for referencing UserTest DoS were out of date and did not return                    |
 | TKW - Updated Response scenarios                 | Added the sentinel values, under the Scenarios section, to elicit responses for interim and full Validation responses |
 | TKW - Added table of DoS Service Ids             | Table of DoS Service Ids and how to obtain them to use as sentinel values for TKW Scenarios              |
 | TKW - Updated image                              | Update image detailing how to use MAIT Portal to send requests to a Receiver solution                    |
 | BARS-UEC-1 Application                           | Corrected how elements ServiceRequest.supportInfo and CarePlan.supportingInfo must be populated          |
 | BARS-UEC-2 Application                           | Corrected how elements ServiceRequest.supportInfo and CarePlan.supportingInfo must be populated          |
 | Fixed broken or incorrect links on "Home Page"   | Some links were linking to the wrong page                                                                |
-| Help and Support - fixed broken external links   | Some external linkswere broken or still "boiler plate" links                                             |
+| Help and Support - fixed broken external links   | Some external links were broken or still "boiler plate" links                                             |
 | Updated Change Log naming  | Change Log names have been changed to more in line with the rest of the change log names                                       |
 | Updated wording on releases | Wording of guidance around support for new releases of Core was updated to provide more clarity                               |
 

guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.8.1.page.md

@@ -11,7 +11,7 @@
 | Existing use case categories have been corrected where needed      | existing use case categories have been corrected where required |
 | BaRS Core addition of use context header      | HTTP header for auditing and logging has been added to assist with NHSE reporting. |
 | Bug fixes and corrections  |There have been several bug fixes and corrections in the guide, these includes typos, broken links or corrections.|
-| Improvements to the the Build Section  | Several improvements to the Testing and Environments pages |
+| Improvements to the Build Section  | Several improvements to the Testing and Environments pages |
 | Application 6 TKW changes | Application 6 is now available in the TKW |
 
 <p>

guides/Live-ImplementationGuide-BaRS/Home/Analysis/Versioning.guide.md

@@ -8,7 +8,7 @@ The Booking and Referral Standard (BaRS) will follow [Semantic Versioning](https
 Full details can be found at the [Semantic Versioning](https://semver.org/) site, key points outlined below:
 
 #### Major version
-The major version is incremented when an incompatible changes are made, i.e. a non backwards compatible change.
+The major version is incremented when incompatible changes are made, i.e. a non backwards compatible change.
 
 #### Minor version
 The minor version increments when changes are made in a backwards compatible manner.
@@ -39,14 +39,14 @@ Breaking change will always be considered before being implemented, the overhead
 
 ### <span style="color:red">**For the Core elements of BaRS (BaRS Core) suppliers will be expected to revise their solution to support a MAJOR release within six months from the version release date**</span>
 
-<span style="color:red">Note: Major releases of BaRS Core will be NO LESS than SIX MONTHS from the preceeding major release</span>
+<span style="color:red">Note: Major releases of BaRS Core will be NO LESS than SIX MONTHS from the preceding major release</span>
 
 
 <center>
 {{render:versioning.png}}
 </center>
 
-Compatibilty is verified dynamically during workflows through the 'version' element defined on the Capability Statement and Message Definitions. Senders and Receivers should operate on the highest version they are both compatible with and negoitate down, where possible. 
+Compatibility is verified dynamically during workflows through the 'version' element defined on the Capability Statement and Message Definitions. Senders and Receivers should operate on the highest version they are both compatible with and negotiate down, where possible. 
 
 A Sender **must** check the returned 'version' in these resources before proceeding to make requests of a Receiver. For version 1.0.0 **only** versions within the major version v1.0.0 should be considered compatible (1.0.0 extensions excluded):-
 
@@ -61,19 +61,19 @@ A Receiver **should** check the version a Sender is expecting interoperate on by
 </center>
 
 ### Pre-release Labels
-These labels will be taken from the GDS (Goverment Digital Services) development process stages, and will be one of:
+These labels will be taken from the GDS (Government Digital Services) development process stages, and will be one of:
 
 * **Discovery**: a Feasibility study. A 'No code' development. Designed to find out what users are trying to achieve, any constraints, improvement opportunities
 
 * **Alpha**: Develop prototypes and test with users. Could be minimal functionality and potentially prototypes for any options to determine which is best
 
 * **Private Beta**: Working version and test with invited users. Handle real transactions and work at scale. ‘Invite only’ or regional. Must Pass assessment by business and technical SME’s
 
-* **Public Beta**: All users can participate. Version unlikely to change substantially, but still needs further testing by a wider group of implementors before becoming live
+* **Public Beta**: All users can participate. Version unlikely to change substantially, but still needs further testing by a wider group of implementers before becoming live
 
 * **Live**: The live phase is about supporting the service in a sustainable way, and continuing to iterate and make improvements
 
-* **Retiring**: Implementors notified that the service is discontinued and not to be used for new developments
+* **Retiring**: Implementers notified that the service is discontinued and not to be used for new developments
 
 <hr>
 
@@ -88,7 +88,7 @@ APIs should have the ability to route traffic based on the version header as sho
 
 <a href="https://raw.githubusercontent.com/NHSDigital/NHSDigital-FHIR-BookingAndReferrals/main/BaRS-Images//Versioning/API_Proxies-1.1.0.svg" target="_blank"><img src="https://raw.githubusercontent.com/NHSDigital/NHSDigital-FHIR-BookingAndReferrals/main/BaRS-Images/Versioning/API_Proxies-1.1.0.svg" width="800"></img></a>
 
-API Versioning between entities is fairly loose, only the major versioning differences would case a failure. with the exception of new endpoints which will be gated by minor versioning. The diagram below shows desired behavior in all versioning negotiations at the API.
+API Versioning between entities is fairly loose, only the major versioning differences would case a failure. with the exception of new endpoints which will be gated by minor versioning. The diagram below shows desired behaviour in all versioning negotiations at the API.
 
 <a href="https://raw.githubusercontent.com/NHSDigital/NHSDigital-FHIR-BookingAndReferrals/main/BaRS-Images//Versioning/API_Interactions-1.1.0.svg" target="_blank"><img src="https://raw.githubusercontent.com/NHSDigital/NHSDigital-FHIR-BookingAndReferrals/main/BaRS-Images/Versioning/API_Interactions-1.1.0.svg" width="1800"/></img></a>
 
@@ -102,7 +102,7 @@ The CapabilityStatement, coupled with the Accept header can define what version
 
 ### MessageDefinition (step 3)
 
-The serviceID will help dictate what MessageDefinitions are returned and ensure they are specifiic to the service being queried. The version of the MessageDefinitions returned would be linked to the version of the Use case. The use case is identified using the useContext element.
+The serviceID will help dictate what MessageDefinitions are returned and ensure they are specific to the service being queried. The version of the MessageDefinitions returned would be linked to the version of the Use case. The use case is identified using the useContext element.
 
 For example, a service could service multiple applications covered by a single message definition, of varying versions. They would then choose the version of the message definition most appropriate for the use case. Knowing, from Service Discovery, that the Receiver accepts that type of referral and that it requires that version of the messageDefinition.