Merge pull request #267714 from EXPEkesheth/patch-154

Added bundle parellization information for Azure API for fhir

Author: prmerger-automator[bot]

articles/healthcare-apis/azure-api-for-fhir/fhir-rest-api-capabilities.md

@@ -67,7 +67,72 @@ For example: `https://myworkspace-myfhirserver.fhir.azurehealthcareapis.com/Pati
 After you've found the record you want to restore, use the `PUT` operation to recreate the resource with the same ID, or use the `POST` operation to make a new resource with the same information.
 
 > [!NOTE]
-> There is no time-based expiration for history/soft delete data. The only way to remove history/soft deleted data is with a hard delete or the purge history operation.
+> There is no time-based expiration for history/soft delete data. The only way to remove history/soft deleted data is with a hard delete or the purge history operation.\
+
+## Batch Bundles 
+In FHIR, bundles can be considered as a container that holds multiple resources. Batch bundles enable users to submit a set of actions to be performed on a server in single HTTP request/response.
+
+A batch bundle interaction with FHIR service is performed with HTTP POST command at base URL.  
+```rest
+POST {{fhir_url}} 
+{ 
+  "resourceType": "Bundle", 
+  "type": "batch", 
+  "entry": [ 
+    { 
+      "resource": { 
+        "resourceType": "Patient", 
+        "id": "patient-1", 
+        "name": [ 
+          { 
+            "given": ["Alice"], 
+            "family": "Smith" 
+          } 
+        ], 
+        "gender": "female", 
+        "birthDate": "1990-05-15" 
+      }, 
+      "request": { 
+        "method": "POST", 
+        "url": "Patient" 
+      } 
+    }, 
+    { 
+      "resource": { 
+        "resourceType": "Patient", 
+        "id": "patient-2", 
+        "name": [ 
+          { 
+            "given": ["Bob"], 
+            "family": "Johnson" 
+          } 
+        ], 
+        "gender": "male", 
+        "birthDate": "1985-08-23" 
+      }, 
+      "request": { 
+        "method": "POST", 
+        "url": "Patient" 
+      } 
+    } 
+   } 
+  ] 
+} 
+```
+
+In the case of a batch, each entry is treated as an individual interaction or operation. 
+> [!NOTE]
+> For batch bundles there should be no interdependencies between different entries in FHIR bundle. The success or failure of one entry should not impact the success or failure of another entry.
+
+### Batch bundle parallel processing in public preview 
+
+Currently batch bundles are executed serially in FHIR service. To improve performance and throughput, we're enabling parallel processing of batch bundles in public preview.  
+To use the capability of parallel batch bundle processing-
+* Set header “x-bundle-processing-logic” value to “parallel”. 
+* Ensure there's no overlapping resource ID that is executing on DELETE, POST, PUT or PATCH operations in the same bundle.
+
+> [!IMPORTANT]
+> Bundle parallel processing is currently in public preview. Preview APIs and SDKs are provided without a service-level agreement. We recommend that you don't use them for production workloads. Some features might not be supported, or they might have constrained capabilities. For more information, review Supplemental Terms of Use for Microsoft Azure Previews 
 
 ## Patch and Conditional Patch
 
@@ -162,7 +227,8 @@ Content-Type: `application/json`
 ```
 
 ## Performance consideration with Conditional operations
-Conditional interactions can be complex and performance-intensive. To enhance the latency of queries involving conditional interactions, you have the option to utilize the request header **x-conditionalquery-processing-logic** . Setting this header to **parallel** allows concurrent execution of queries with conditional interactions.
+1. Conditional interactions can be complex and performance-intensive. To enhance the latency of queries involving conditional interactions, you have the option to utilize the request header **x-conditionalquery-processing-logic** . Setting this header to **parallel** allows concurrent execution of queries with conditional interactions.
+2. **x-ms-query-latency-over-efficiency** header value when set to "true", all queries are executed using maximum supported parallelism, which forces the scan of physical partitions to be executed concurrently. This feature was designed for accounts with a high number of physical partitions which queries can take longer due to the number of physical segments that need to be scanned. 
 
 ## Next steps