-
-Once the appointment is cancelled, the Receiver is responsible for managing the pointer in the central Registry, as described in {{pagelink:core-StandardPattern-document-reference-1.3.1, text: Document Reference Standard Pattern}}.
\ No newline at end of file
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Initial-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Initial-Booking.page.md
index 0d04fce8..f8d34835 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Initial-Booking.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Initial-Booking.page.md
@@ -17,7 +17,8 @@ If undertaking a booking within the context of an Application, the guidance stat
* Confirm BaRS [Capabilities](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/metadata)
* [Request Available slots](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Slot)
* Select a slot
-* Perform a [PUT](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#post-/Appointment) operation to complete the booking NB: the returned Appointment.id for future operations
+* Perform a [POST](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#post-/Appointment) operation to complete the booking NB: the returned Appointment.id for future operations
+* Once processed, the Receiver of the booking must makes a [POST](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#post-/DocumentReference) request to create a pointer in the central Registry, as described in {{pagelink:core-StandardPattern-document-reference-Receiver-1.3.1, text: Document Reference Standard Pattern - Receiver}}
Request Body
@@ -52,8 +53,4 @@ Request Body
}
```
-
-
-Once the appointment is created, the Receiver is responsible for managing the pointer in the central Registry, as described in {{pagelink:core-StandardPattern-document-reference-1.3.1, text: Document Reference Standard Pattern}}.
-
-
+
\ No newline at end of file
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Introduction.page.md
index c5adbc7e..0b503799 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Introduction.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Introduction.page.md
@@ -5,14 +5,14 @@ topic: core-StandardPattern-appointment-Introduction-1.3.1
# Standard Pattern - Appointments
This Section of the Implementation Guide is currently a preview, in an Alpha state and subject to change.
+This Section of the Implementation Guide is currently a preview, in an Alpha state and subject to change. Only Internal NHSE programmes are currently permitted to build against this release. If you are interested in building against this documentation, please, contact the BaRS Team
-
-Once the appointment is rebooked, the Receiver is responsible for managing the pointer in the central Registry, as described in {{pagelink:core-StandardPattern-document-reference-1.3.1, text: Document Reference Standard Pattern }}.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Reschedule-Existing-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Reschedule-Existing-Booking.page.md
index 0ed83ae9..a9bc4d08 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Reschedule-Existing-Booking.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Reschedule-Existing-Booking.page.md
@@ -8,14 +8,12 @@ The Reschedule operation supports amending the slot a booking is made against. T
Steps to Reschedule:
-* Perform a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\}. Alternatively, if the .id is not known, a search of the Registry can be undertaken with [GET DocumentReference](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/DocumentReference) (searchset bundle) and selecting the Service and Appointment.id to create the read request of the Appointment resource by .id. NB: If a match cannot be performed using this method, the processing of updating must be done manually.
-* Ensure the booking is still active by chekcing the .status
-* {{pagelink:core-EndToEndWorkflow-ServiceDiscovery-1.3.1, text:Select the **same** service}} to reschedule the booking with
-* Confirm BaRS [Capabilities](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/metadata)
-* [Request Available slots](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Slot)
+* Perform a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) operation using the .id of the appointment to /Appointment/\{id\}. Alternatively, if the .id is not known, a search of the Registry can be undertaken following the {{pagelink:core-StandardPattern-document-reference-Sender-1.3.1, text: Document Reference Standard Pattern - Sender}}. NB: If a match cannot be obtained using this method the process of updating must be performed manually
+* [Request Available slots](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Slot) from the service
* Select a new slot
* Update the resource with the new slot. NB: Only the .slot element of the resource must be updated
* Perform a [PATCH](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#patch-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\}
+* Once processed, the Receiver of the booking must [update (PUT)](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/DocumentReference/-id-) the pointer in the central Registry, as described in {{pagelink:core-StandardPattern-document-reference-Receiver-1.3.1, text: Document Reference Standard Pattern - Receiver}}
In this example the Appointment resource is with the existing slot, and updated with the newly selected slot.
@@ -85,5 +83,3 @@ Request Body
}
```
-
-Once the appointment is rescheduled, the Receiver is responsible for managing the pointer in the central Registry, as described in {{pagelink:core-StandardPattern-document-reference-1.3.1, text: Document Reference Standard Pattern }}.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Update-Existing-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Update-Existing-Booking.page.md
index fe9cd2c9..d22e14c6 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Update-Existing-Booking.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Update-Existing-Booking.page.md
@@ -6,8 +6,8 @@ topic: core-StandardPattern-appointment-update-1.3.1
Steps to update:
-* Perform a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\}. Alternatively, if the .id is not known, a search of the Registry can be undertaken with [GET DocumentReference](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/DocumentReference) (searchset bundle) and selecting the Service and Appointment.id to create the read request of the Appointment resource by .id. NB: If a match cannot be performed using this method, the processing of updating must be done manually.
-* Update the Appointment resource as required. There is only currently support to alter .status and .reasonCode. NB: The .slot element of the resource must not be updated, if an alternative slot is required either the {{pagelink:core-StandardPattern-appointment-reschedule-1.3.1, text:Reschedule}} or {{pagelink:core-StandardPattern-appointment-rebook-1.3.1, text:Rebook}} processes must be followed.
+* Perform a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) operation using the .id of the appointment to /Appointment/\{id\}. Alternatively, if the .id is not known, a search of the Registry can be undertaken following the {{pagelink:core-StandardPattern-document-reference-Sender-1.3.1, text: Document Reference Standard Pattern - Sender}}. NB: If a match cannot be obtained using this method the process of updating must be performed manually
+* Update the Appointment resource as required. There is only currently support to alter .status and .reasonCode. NB: The .slot element of the resource must not be updated, if an alternative slot is required either the {{pagelink:core-StandardPattern-appointment-reschedule-1.3.1, text:Reschedule}} or {{pagelink:core-StandardPattern-appointment-rebook-1.3.1, text:Rebook}} processes must be followed
* Perform a [PUT](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\}
resource returned:
@@ -79,5 +79,3 @@ Request Body
}
```
-
-Once the appointment is updated, the Receiver is responsible for managing the pointer in the central Registry, as described in {{pagelink:core-StandardPattern-document-reference-1.3.1, text: Document Reference Standard Pattern}}.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Introduction.page.md
index ee97dabb..5c9898d2 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Introduction.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Introduction.page.md
@@ -10,12 +10,12 @@ topic: core-StandardPattern-document-reference-Introduction-1.3.1
## Introduction
-In version 1.1.0 of the BaRS API Specification, functionality was added to accommodate the use of pointers (DocumentReference resources), to locate existing bookings and referrals.
+There is functionality in BaRS to accommodate the use of pointers (DocumentReference resources), to locate existing bookings and referrals from a central Registy.
-The FHIR DocumentReference resource allows you to reference and locate clinical documents or resources. This section will walk you through the process of using a FHIR DocumentReference to find a resource's location and retrieve it.
+This section will walk you through the process of using FHIR DocumentReferences, from the central Registry, to find and retrieve bookings and referrals held at Receiver services.
-The BaRS API acts as a gateway to the National Record Locator FHIR API for BaRS enabled Services. In the image below the BaRS API is interacted with by Consumers and Producers.
-* Consumer - Queries the API for existing DocumentReferences for use in finding existing Bookings and Referrals. This is usually a BaRS [Sender](https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Design/BaRS-Core?version=current#Core-functionality-requirements).
-* Producer - Posts and maintains DocumentReferences for Bookings and Referrals that they have received. This is invariably the BaRS [Receiver](https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Design/BaRS-Core?version=current#Core-functionality-requirements).
+The BaRS API acts as a gateway to the National Record Locator (NRL) FHIR API, for BaRS enabled Services. In the image below the BaRS API is called by Consumers and Producers.
+* Consumer - Queries the API for existing DocumentReferences for use in finding existing Bookings and Referrals. Usually a BaRS [Sender](https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Core/1.3.0/Core-Functionality-Requirements).
+* Producer - Posts and maintains DocumentReferences for Bookings and Referrals that they have received. Usually a BaRS [Receiver](https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Core/1.3.0/Core-Functionality-Requirements).
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Receiver-DocumentReference.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Receiver-DocumentReference.md
index 41011bb1..e6e8aae8 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Receiver-DocumentReference.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Receiver-DocumentReference.md
@@ -6,33 +6,63 @@ topic: core-StandardPattern-document-reference-Receiver-1.3.1
## Creating a DocumentReference.
-The FHIR DocumentReference resource allows you to create a reference to a clinical document or resource. This section describes the process of creating a FHIR DocumentReference for a resource. A DocumentReference will be created when a Receiver accepts a Booking or a Referral. Each request will warrant a distinct Document Reference.
+The FHIR DocumentReference resource allows you to create a reference to a clinical document or resource. This section describes the process of creating a FHIR DocumentReference (pointer) for a booking or referral resource on the central Registry. A DocumentReference will be created when a Receiver accepts a booking or referral. Each booking or referral request processed requires a distinct DocumentReference on the Registry.
-### Step 1: Understand the Document Reference Resource
-The Document Reference resource in FHIR represents a reference to a clinical document or resource. It contains metadata about the document, such as its type, author, and creation date, along with a reference to the actual document's location. Within BaRS the DocumentReference acts as a pointer towards ServiceRequests, or Appointment resources.
-### Step 2: Identify the Resource to Reference
-Determine the resource that you want to create a Document Reference for. This will be any ServiceRequest or Appointment Resource that has been created in the Receiver system by means of a booking request or a service request.
+### Step 1: Identify the booking or referral to create a pointer for
+When a Receiver processes a request for a booking (Appointment) or referral (ServiceRequest), the next step in the workflow is to create a pointer for the newly created resource (Appointment or ServiceRequest) on the central Registry. This will be undertaken via a POST [DocumentReference](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#post-/DocumentReference) request to the BaRS Proxy.
-The resources themselves will have unique identifiers upon creation in the receiver system.
-### Step 3: Set the Metadata of the Document Reference
-Create a new instance of the Document Reference resource and populate the relevant metadata fields. key fields to include are as follows:
+### Step 2: Set content of the DocumentReference (pointer)
+Create a new instance of the DocumentReference resource and populate the relevant fields. Key fields to include are as follows:
-type: Specify the type of document or resource being referenced. For example, if you are referencing a referral you would use the value `https://snomed.info/ict|736253002` or if it is a booking `https://snomed.info/ict|749001000000101`.
+**identifier:** The DocumentReference needs several identifiers which allow the booking or referral to be located at a Receiver service.
+
+The resource .id of the booking (Appointment) or referral (ServiceRequest) (created by the Receiver when processing the request) must be set in the 'value' element of an Identifier, clarified by the system '*https://fhir.nhs.uk/Id/BaRS-Identifier*'.
+
+```json
+"identifier": [
+ {
+ "system": "https://fhir.nhs.uk/Id/BaRS-Identifier",
+ "value": "8c63d621-4d86-4f57-8699-e8e22d49935d"
+ }
+```
+
+The second identifier of note is the Receiving service who own the resource. The 'system' indicates the Service Discovery tool and the 'value', the identifier. In the code snippet below, the system '*https://fhir.nhs.uk/Id/dos-service-id*' indicates the Receiver service is on the Urgent and Emergency Care Directory of Services (UEC DoS) as service 2000072491. The Sender of any request will use the 'system' and 'value' here to build the base64 encoded HTTP Header NHSD-Target-Identifier, as defined for the [booking](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) or [referral](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/ServiceRequest/-id-).
+
+```json
+"identifier": [
+ {
+ "system": "https://fhir.nhs.uk/Id/dos-service-id",
+ "value": "2000072491"
+ }
+```
+
+The third identifier (currently optional) relates to the product-id, system '*https://fhir.nhs.uk/id/product-id*'. This is forth coming functionality and further detail on its utility will follow but [working documentation] (https://github.com/NHSDigital/nhse-epr-integration/blob/main/pages/appendix1.md) is being actively updated.
+
+```json
+"identifier": [
+ {
+ "system": "https://fhir.nhs.uk/Id/product-id",
+ "value": "P.GH7-4TY"
+ }
+```
+
+**type:**, within the DocumentReference resource, indicates whether the pointer is for a booking or referral. BaRS currently only supports bookings (749001000000101) and referrals (736253002), described using SNOMED codes.
```json
"type": {
"coding": [
{
"system": "https://snomed.info/ict",
- "code": "736253002"
+ "code": "749001000000101"
}
]
}
```
-subject: Specify the subject of the document reference, which is typically the patient associated with the Resource.
+**subject:** specifies the subject of the DocumentReference, which will be the patient associated with the Resource. The patient's NHS number must be used to identify them, as outlined below.
+
```json
"subject": {
"identifier": {
@@ -42,7 +72,8 @@ subject: Specify the subject of the document reference, which is typically the p
},
```
-custodian: Set the author of the document reference, which will be the ODS code for the organisation writing the DocumentReference.
+**custodian:** Set the author of the DocumentReference, which will be the ODS code for the organisation writing the DocumentReference resource entry.
+
```json
"custodian": {
"identifier": {
@@ -53,53 +84,23 @@ custodian: Set the author of the document reference, which will be the ODS code
```
-### Step 4: Set the Content Reference
-The content element of the Document Reference resource contains the reference to the location of the actual resource. Create a new instance of the content element and set the attachment property. The attachment property has a URL field where you specify the location of the resource.
-
-Access the content element of the Document Reference. This element contains the reference to the location of the actual resource. The content element is typically an array, as a DocumentReference can reference multiple versions or representations of the same document. Each item in the array will have a URL element, which specifies the location of the resource.
-
-The content.attachment.URL element in this example is a URL friendly Target Identifier for the receiver endpoint, of which can be used to retrieve the resource via the BaRS proxy by a consumer/sender. This element can also contain a direct URL if appropriate.
-The content.format element will contain the coding that describes the format of the resource in question. In this instance this is a [BaRS message event](https://simplifier.net/nhsbookingandreferrals/message-events-bars) of "servicerequest-request". ensure you set the creation date of the resource.
-
-```json
-"content": [
- {
- "attachment": {
- "language": "en-UK",
- "URL": "http://fhir.nhs.uk/Id/dos-service-id|111111111",
- "title": "Physical",
- "creation": "2005-12-24T09:35:00+11:00"
- },
- "format": [
- {
- "coding": [
- {
- "system": "https://fhir.nhs.uk/CodeSystem/message-events-bars",
- "code": "servicerequest-request"
- }
- ]
- }
- ]
- }
-]
-```
-### Step 5: Save and Transmit the DocumentReference
-Once you have populated all the necessary fields, you will need to perform a POST of the DocumentResource to the /DocumentReference endpoint on the BaRS proxy. This will create a DocumentReference in the NRL.
+### Step 3: Save and Transmit the DocumentReference (pointer)
+Once all the necessary fields are populated, perform a [POST](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#post-/DocumentReference) of the DocumentReference to the /DocumentReference endpoint on the BaRS proxy. This will create a DocumentReference in the NRL.
-After saving, the DocumentReference will be assigned a unique id (e.g., DocumentReference/12345). You can use this identifier to reference or retrieve the DocumentReference in the future.
+After saving, the DocumentReference will be assigned a unique id (e.g., DocumentReference/12345). This can be used to reference or [retrieve](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/DocumentReference/-id-) the DocumentReference in the future.
-### Step 6: Verify the DocumentReference
-To ensure that the DocumentReference was created successfully, you can retrieve it using its identifier or search for it using relevant parameters. Make sure to validate the returned DocumentReference to confirm that all the metadata and content references are accurate.
+### Step 4: Verify the DocumentReference
+To ensure that the DocumentReference was created successfully, retrieve it using its [id](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/DocumentReference/-id-) or [search](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/DocumentReference) for it using relevant parameters. Make sure to validate the returned DocumentReference to confirm that all the contents are accurate.
### Updating a DocumentReference
-A DocumentReference can be updated by performing a PUT request with the updated resource to the /DocumentReference endpoint on the BaRS proxy with the appropriate id. A Read operation must be performed prior to this to ensure that the new DocumentReference is the most up to date.
+A DocumentReference can be updated by performing a [PUT](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/DocumentReference/-id-) request with the updated resource to the /DocumentReference endpoint on the BaRS proxy with the appropriate DocumentReference.id. A Read operation must be performed prior to this to ensure that the new DocumentReference is the most up to date.
-**Note**: You can only delete DocumentReference resources that you own and that you created.
+**Note**: A Receiver can only update DocumentReference resources that they created and own.
### Delete a DocumentReference
-A DocumentReference can be updated by performing a DELETE request with the resource to the /DocumentReference endpoint on the BaRS proxy with the appropriate id. A Read operation must be performed prior to this to ensure that the Action is appropriate.
+A DocumentReference can be removed by performing a [DELETE](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#delete-/DocumentReference/-id-) request to the /DocumentReference endpoint on the BaRS proxy with the appropriate DocumentReference.id. A Read operation must be performed prior to this to ensure that the action is appropriate.
-**Note**: You can only delete DocumentReference resources that you own and that you created.
+**Note**: A Receiver can only delete DocumentReference resources that they created and own.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Sender-DocumentReference.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Sender-DocumentReference.md
index b04c75c7..4b9aacb3 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Sender-DocumentReference.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Sender-DocumentReference.md
@@ -5,22 +5,21 @@ topic: core-StandardPattern-document-reference-Sender-1.3.1
# {{page-title}}
### Step 1: Understand the Document Reference Resource
-The Document Reference resource in FHIR represents a reference to a clinical document or resource. It contains metadata about the document, such as its type, author, and creation date, subject (the patients NHS number), as well as a reference to the actual document's location (URL) and markers for how the method needed to retrieve it.
+The FHIR DocumentReference resource represents a reference to a clinical document or resource, in the case of BaRS a pointer to an active booking or referral. It contains metadata about the booking or referral, such as its type (booking or referral), author, and subject (the patient's NHS number), as well as a reference to the actual document's .id and where it resides (the service who owns it); the two key data points needed to retrieve it.
-### Step 2: Search for the Document Reference
-To find a resource's location, you need to search for the appropriate DocumentReference resource. The most common way to search for Document References is by using search parameters.
+### Step 2: Search for the booking or referral pointer (DocumentReference)
+FHIR DocumentReference resources holding pointers for BaRS bookings and referrals are stored in a central Registry, within NRL (National Record Locator), as decribed above, and interrogated through the [BaRS API DocumentReference](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/DocumentReference).
-For example, if you are looking for a DocumentReference that represents a referral, you could use the following search query, where a snomed code is used to define the type of the document:
+To find a booking or referral location, you need to search for the appropriate DocumentReference resource from the Registry, using search parameters. It is mandatory to include the subject:identifier (the patient's NHS number), other parameters can be used to filter the response further e.g type of document (booking and referral).
-GET [base-URL]/DocumentReference?type=https://snomed.info/ict|736253002
+### Step 3: Inspect the booking or referral pointer (DocumentReference)
+Once you retrieve the Document Reference(s) (pointers) from the search, inspect the returned resources to identify the one you need. Look for relevant metadata, as described below, to confirm the correct resource.
-The Booking and Referrals API [v1.1.0 specification](google.com) has more information on search parameters available.
+**identifier:** The DocumentReference will have several identifiers which are required to locate the booking or referral at a Receiver service.
-### Step 3: Inspect the Document Reference
-Once you retrieve the Document Reference(s) from the search, inspect the returned resources to identify the one you need. Look for relevant metadata like the document type, author, creation date or format to confirm it is the correct resource.
+The .id of the booking or referral is indicated by the system '*https://fhir.nhs.uk/Id/BaRS-Identifier*'. The value can be used to directly request the [booking](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) or [referral](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/ServiceRequest/-id-) by .id, once you know Receiver service holding it (see next identifier).
-identifier: The DocumentReference will have an identifier stating the id of the resource.
-```
+```json
"identifier": [
{
"system": "https://fhir.nhs.uk/Id/BaRS-Identifier",
@@ -28,19 +27,41 @@ identifier: The DocumentReference will have an identifier stating the id of the
}
```
-type: Below you can see the type, within the DocumentReference Resource. Within BaRS there is currently only bookings (749001000000101) and Referrals (736253002), described using SNOMED codes.
+The second identifier, required to make the subsequent request for the booking or referral in question, has a system of '*https://fhir.nhs.uk/Id/dos-service-id*' and enables the Sender to direct their request to the Receiver service which owns it. The Sender will use the system and value here to build the base64 encoded HTTP Header NHSD-Target-Identifier, as defined for the [booking](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) or [referral](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/ServiceRequest/-id-).
+
+```json
+"identifier": [
+ {
+ "system": "https://fhir.nhs.uk/Id/dos-service-id",
+ "value": "2000072491"
+ }
+```
+
+The third identifier (currently optional) relates to the product-id, system '*https://fhir.nhs.uk/id/product-id*'. This is forth coming functionality and further detail on its utility will follow but [working documentation] (https://github.com/NHSDigital/nhse-epr-integration/blob/main/pages/appendix1.md) is being actively updated.
+
+```json
+"identifier": [
+ {
+ "system": "https://fhir.nhs.uk/Id/product-id",
+ "value": "P.GH7-4TY"
+ }
+```
+
+**type:** within the DocumentReference Resource, indicates whether the pointer is for a booking or referral. BaRS currently only supports bookings (749001000000101) and referrals (736253002), described using SNOMED codes. This information is required to direct the subsequent request to the correct endpoint for the [booking](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) or [referral](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/ServiceRequest/-id-)
+
```json
"type": {
"coding": [
{
"system": "https://snomed.info/ict",
- "code": "736253002"
+ "code": "749001000000101",
+ "display": "Appointment (record artifact)"
}
]
}
```
-subject: The subject will describe the patient, by means of an NHS number.
+**subject:** The subject will describe the patient, by means of an NHS number. This element is not explicitly required to request the specific resource dictated by the pointer but could be used to search a service more widely for related [bookings](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment) and [referrals](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/ServiceRequest), using the search by patient endpoints.
```json
"subject": {
@@ -50,7 +71,7 @@ subject: The subject will describe the patient, by means of an NHS number.
}
```
-custodian: The custodian element will describe the organization that owns the resource data. This will be a concatenation of ODS codes.
+**custodian:** The custodian element will describe the organisation that owns the resource data. This will be a concatenation of ODS codes.
```json
"custodian": {
@@ -60,51 +81,24 @@ custodian: The custodian element will describe the organization that owns the re
}
}
```
-### Step 4: Retrieve the Resource's Location
-Access the content element of the Document Reference. This element contains the reference to the location of the actual resource. The content element is typically an array, as a Document Reference can reference multiple versions or representations of the same document. Each item in the array will have a URL element, which specifies the location of the resource.
-The content.attachment.URL element in this example is a URL friendly Target Identifier, of which can be used to retrieve the resource. This element can also contain a direct URL if appropriate.
-The content.format element will contain the coding that describes the format of the resource in question. In this instance this is a [BaRS message event](https://simplifier.net/nhsbookingandreferrals/message-events-bars) of "servicerequest-request".
+### Step 4: Retrieve the booking or referral
+The booking or referral resource can be retrieved by making a GET request for the [booking](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) or [referral](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/ServiceRequest/-id-).
-```json
-"content": [
- {
- "attachment": {
- "language": "en-UK",
- "URL": "http://fhir.nhs.uk/Id/dos-service-id|111111111",
- "title": "Physical",
- "creation": "2005-12-24T09:35:00+11:00"
- },
- "format": [
- {
- "coding": [
- {
- "system": "https://fhir.nhs.uk/CodeSystem/message-events-bars",
- "code": "servicerequest-request"
- }
- ]
- }
- ]
- }
-]
-```
-### Step 5: Retrieve the Resource
-Retrieve the resource by making a GET request to the URL specified in the URL element of the Document Reference's content. Ensure that you have the necessary authorization and access privileges to retrieve the resource.
+The two key values required to make the request are the first two identifiers in the DocumentReference; the resource .id ('*https://fhir.nhs.uk/Id/BaRS-Identifier*') and service id ('*https://fhir.nhs.uk/Id/dos-service-id*'). Use the resource .id populate the location of the request and service id to populate the NHSD-Target-Identifier HTTP Header, as described in the worked example below.
-For BaRS, a GET of the relevant resource type using the Target Identifiers. In this simplified example the URL above containing a TargetIdentifier is used in the NHSD-Target-Identifier header to instruct the BaRS proxy to route to the request to that target **note**: The header is not base64Encoded in this example:
+For BaRS, a GET of the relevant resource using the Target Identifiers. In this simplified example, the identifier containing the service id is used in the NHSD-Target-Identifier header, instructing the BaRS proxy to route to the request to that target **note**: The header is not base64Encoded in this example:
-``` bash
-cURL --location 'https://int.api.service.nhs.uk/booking-and-referral/FHIR/R4/ServiceRequest/8c63d621-4d86-4f57-8699-e8e22d49935d' \
+```bash
+cURL --location 'https://int.api.service.nhs.uk/booking-and-referral/FHIR/R4/Appointment/8c63d621-4d86-4f57-8699-e8e22d49935d' \
--header 'X-Request-ID: {{X-Request-ID}}' \
--header 'X-Correlation-ID: {{X-Correlation-ID}}' \
--header 'NHSD-Target-Identifier: {system:"http://fhir.nhs.uk/Id/dos-service-id", value:"111111111"}' \
--header 'Accept: application/fhir+json' \
```
-Also, if the content element has a direct URL, this can be obtained using a direct GET request.
-
-### Step 6: Handle the Retrieved Resource
-Once you have retrieved the resource, you can process it according to your requirements. The format and structure of the resource will depend on the specific resource type, such as Patient or ServiceRequest. Refer to the FHIR documentation or resource-specific or application-specific guides for further information on handling the retrieved resource.
+### Step 5: Handle the Retrieved booking or referral
+Once you have retrieved the booking or referral resource, it can be used in subsequent workflows. Refer to the FHIR documentation or resource-specific or application-specific guides for further information on handling the retrieved resource.
**Note**: It's important to consider the security and privacy aspects when working with clinical documents and resources. Ensure that you adhere to applicable regulations and best practices to protect patient data.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Index.page.md
index f3e36952..bfcbc5e7 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Index.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Index.page.md
@@ -22,7 +22,7 @@ topic: design-core-1.3.1
-# BaRS Core 1.3.0
+# BaRS Core 1.3.1
BaRS consists of BaRS Core that provides a core set of functionality and BaRS Applications that provide distinct functionality for each use case.
@@ -211,12 +211,13 @@ For more detail please visit the {{pagelink:Core-StandardPattern-1.3.1, text: St
# Standard Pattern - Appointment
-There are 4 capabilities that are required surrounding appointments. This section will provide information on how to meet them.
+The key capabilities surrounding appointments are listed below. This section will provide information on how to meet them.
-* The ability to book an appointment.
-* The ability to cancel an appointment.
-* The ability to update an appointment.
-* The ability to rebook an appointment.
+* book
+* update
+* cancel
+* reschedule
+* rebook
For more detail please visit the {{pagelink:core-StandardPattern-appointment-1.3.1, text: Appointment Standard Pattern}} section.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Deploy/toc.yaml b/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Deploy/toc.yaml
index b01110cb..f62a5c9e 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Deploy/toc.yaml
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Deploy/toc.yaml
@@ -6,5 +6,3 @@
filename: KeyDeploymentActivities.page.md
- name: Roles & Responsibilities
filename: RolesAndResponsibilities.md
-- name: DoS Configuration
- filename: DirectoryOfServiceConfiguration.md
\ No newline at end of file
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Technical deployment/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Technical deployment/Index.page.md
index aa5a68e2..0b9e0759 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Technical deployment/Index.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Technical deployment/Index.page.md
@@ -1,6 +1,5 @@
---
topic: technical deployment
---
-# Index
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/TEMP-HOLDING-AREA/All-Payloads/999-AST-to-CAS-Referral.page.md b/guides/Live-ImplementationGuide-BaRS/Home/TEMP-HOLDING-AREA/All-Payloads/999-AST-to-CAS-Referral.page.md
deleted file mode 100644
index 0ec7d8d2..00000000
--- a/guides/Live-ImplementationGuide-BaRS/Home/TEMP-HOLDING-AREA/All-Payloads/999-AST-to-CAS-Referral.page.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## {{page-title}}
-
-This guidance is specific to the 999 AST to CAS Referral Application. It should be applied alongside the core guidance.
-
-#### UKcore-Encounter resource
-
-| FHIR Element | Cardinality | Element Guidance | Additional Guidance |
-|---------------------|--------------------|----------------------------------------------------------------------------------------------------------------------------------------------|----------------------------|
-| start | 0..1 | This SHOULD be populated with the Call Connect time (T0). If this is not available it SHOULD be populated with the Call Answer Time (T1) | |
-
-
-#### UKCore-CarePlan resource
-
-
-| FHIR Element | Cardinality | Element Guidance | Additional Guidance |
-|---------------------|--------------------|-----------------------------------------------------------------------------------------------------------|-------------------------|
-| system | 0..1 | * Pathways Symptom Group (SG) code use ‘https://fhir.nhs.uk/Id/pathways-sg-code’ value | |
-| code | 0..1 | When you are passing an SG code this MUST be populated with the SG code | |
-| display | 0..1 | When you are passing an SG code this MUST be populated the SG code description | |
-| system | 0..1 | * Pathways Symptom Discriminator (SD) code use ‘https://fhir.nhs.uk/Id/pathways-sd-code’ value | |
-| code | 0..1 | When you are passing an SD code this MUST be populated with the SD code | |
-| display | 0..1 | When you are passing an SD code this MUST be populated the SD code description | |
-| system | 0..1 | * Pathways Disposition (DX) code use ‘https://fhir.nhs.uk/Id/pathways-dx-code’ value | |
-| code | 0..1 | When you are passing an Dx code this MUST be populated with the Dx code | |
-| display | 0..1 | When you are passing an Dx code this MUST be populated the Dx code description | |
-| system | 0..1 | * Ambulance Response Programme (ARP) code use ‘https://fhir.nhs.uk/Id/pathways-arp-code’ value | |
-| code | 0..1 | When you are passing an ARP code this MUST be populated with the ARP code | |
-| display | 0..1 | When you are passing an ARP code this MUST be populated the ARP code description | |
-| system | 0..1 | * AMPDS Dispatch Code use ‘https://fhir.nhs.uk/Id/ampds-code’ value | |
-| code | 0..1 | When you are passing an AMPDS dispatch code this MUST be populated with the AMPDS dispatch code | |
-| display | 0..1 | When you are passing an AMPDS dispatch code this MUST be populated the AMPDS dispatch code description | |
-
-
-#### UKCore-Organisation resource
-
-| FHIR Element | Cardinality | Element Guidance | Additional Guidance |
-|---------------------|--------------------|--------------------------------------------------------------------------------|----------------------------|
-| value | 0..1 | Sender ODS code in the event that they need to receive an ambulance request. | |
-
-
-
-#### UKCore-QuestionnaireResponse resource
-
-This resource is used to communicate links to external sources of clinical information used in the triage/assessment of the patient that would be useful to the recipient.
\ No newline at end of file
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/TEMP-HOLDING-AREA/All-Payloads/999-AST-to-CAS-Validation.page.md b/guides/Live-ImplementationGuide-BaRS/Home/TEMP-HOLDING-AREA/All-Payloads/999-AST-to-CAS-Validation.page.md
deleted file mode 100644
index 0248c13d..00000000
--- a/guides/Live-ImplementationGuide-BaRS/Home/TEMP-HOLDING-AREA/All-Payloads/999-AST-to-CAS-Validation.page.md
+++ /dev/null
@@ -1 +0,0 @@
-## {{page-title}}
\ No newline at end of file
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/TEMP-HOLDING-AREA/All-Payloads/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/TEMP-HOLDING-AREA/All-Payloads/Index.page.md
deleted file mode 100644
index f7bdc30a..00000000
--- a/guides/Live-ImplementationGuide-BaRS/Home/TEMP-HOLDING-AREA/All-Payloads/Index.page.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## {{page-title}}
-
-