Merge pull request #313626 from evachen96/evach_20260324releasenotes

Update release notes and fix acrolinx

Author: prmerger-automator[bot]

articles/healthcare-apis/azure-api-for-fhir/release-notes-2026.md

@@ -28,6 +28,10 @@ Azure API for FHIR® provides a fully managed deployment of the Microsoft FHI
   - Cancelling a queued or running export job returns "202 Accepted"; no behavior change.
   - Trying to get the status of a user-requested cancelled job returns "404 Job Not Found."
 
+
+#### Bug fixes:
+**Fix for versioning configuration issue**:  On 10 March 2026, a release rolled out that fixed a bug that prevented the resource versioning policy default setting from being honored in the FHIR server. This fix revealed another bug involving a bad configuration setting value that resulted in some requests failing with 500 errors. The issue was fixed on 10 March 2026.
+
 ## February 2026
 ### FHIR service
 

articles/healthcare-apis/release-notes-2026.md

@@ -22,17 +22,21 @@ Release notes describe features, enhancements, and bug fixes released in 2026 fo
 
 **Token search behavior update**: After 2 March 2026, the Azure FHIR service was updated so that token values longer than 128 characters are no longer truncated during indexing. If your workspace is affected, you may notice changes in the number of resources returned for token-based queries, along with improved overall query performance. The goal for this update is to improve search behavior accuracy and strengthen service reliability. An Azure service notification was sent to affected accounts with more details.
 
-**Bulk Export cancellation behavior update**: Added updates to align the FHIR server to support [Bulk Data Access 2.0](https://hl7.org/fhir/uv/bulkdata/STU2/export.html#bulk-data-delete-request). This includes a change to bulk export cancellation behavior. Previously, cancellation request of an already completed, cancelled, or failed export job returned "200 OK." The behavior is now updated to return more informative operation outcomes:
+**Bulk Export cancellation behavior update**: Added updates to align the FHIR server to support [Bulk Data Access 2.0](https://hl7.org/fhir/uv/bulkdata/STU2/export.html#bulk-data-delete-request). This includes a change to bulk export cancellation behavior. Previously, cancellation request of an already completed, canceled, or failed export job returned "200 OK." The behavior is now updated to return more informative operation outcomes:
   - Cancelling an already-cancelled export job returns "404 Job Not Found."
-  - Cancelling a completed or failed export job returns "404 Job Not Found" if the job has already been cancelled or failed; otherwise returns "202 Accepted."
+  - Cancelling a completed or failed export job returns "404 Job Not Found" if the job has already been canceled or failed; otherwise returns "202 Accepted."
   - Cancelling a queued or running export job returns "202 Accepted"; no behavior change.
-  - Trying to get the status of a user-requested cancelled job returns "404 Job Not Found."
+  - Trying to get the status of a user-requested canceled job returns "404 Job Not Found."
 
 #### Bug fixes:
+**Fix for token search with system values only**: A regression was introduced in the 12 March 2026 release where searches for token search parameters that only included a system value, and not a code, were returning incorrect results. The  issue was fixed on 14 March 2026.
+
+**Fix for versioning configuration issue**:  On 10 March 2026, a release rolled out that fixed a bug that prevented the resource versioning policy default setting from being honored in the FHIR server. This fix revealed another bug involving a bad configuration setting value that resulted in some requests failing with 500 errors. The issue was fixed on 10 March 2026.
+
 
 **Bug fix for `$bulk-delete` with `_remove-references`**: Previously, there was an issue when using `$bulk-delete` with `_remove-references` where the version number wasn't being displayed in the resources after they had their references removed. This issue is fixed.
 
-**Versioning policy regression fix**: Versioning policy behavior was not consistently enforced following infrastructure changes introduced after September 1, 2025. Beginning with the February 20th FHIR service release, a regression in how the service enforces configured FHIR resource versioning policies has been corrected. This update restores behavior so that it aligns with the versioning configuration already set on your FHIR service. An Azure service notification was sent to affected accounts with more details.
+**Versioning policy regression fix**: Versioning policy behavior wasn't consistently enforced following infrastructure changes introduced after 1 September 2025. Beginning with the 20 February 2026 FHIR service release, a regression in how the service enforces configured FHIR resource versioning policies has been corrected. This update restores behavior so that it aligns with the versioning configuration already set on your FHIR service. An Azure service notification was sent to affected accounts with more details.
 
 ## February 2026
 ### FHIR service
@@ -46,7 +50,7 @@ Release notes describe features, enhancements, and bug fixes released in 2026 fo
 
 **Pagination bug in FHIR search fix**: There was an issue where a pagination bug in FHIR search queries caused resources to be intermittently skipped when results span multiple pages and use continuation tokens. The issue is fixed.
 
-**Allow `_meta-history` in transaction bundles**: Previously, there was a limitation where `_meta-history` parameter was not working in [transaction bundles](./fhir/rest-api-capabilities.md#batch-and-transaction-bundles). This issue has been fixed, and the `_meta-history` parameter can now be used in transaction bundles.
+**Allow `_meta-history` in transaction bundles**: Previously, there was a limitation where `_meta-history` parameter wasn't working in [transaction bundles](./fhir/rest-api-capabilities.md#batch-and-transaction-bundles). This issue has been fixed, and the `_meta-history` parameter can now be used in transaction bundles.
 
 **Soft deletes in transaction bundles**: For a [transaction bundle](./fhir/rest-api-capabilities.md#batch-and-transaction-bundles), all supported interactions or operations either succeed or fail together. When a transaction bundle fails, the FHIR service returns a single OperationOutcome. Previously, there was an issue where soft delete operations were not being considered for the transaction bundle scope, which could cause a discrepancy in the all-or-nothing behavior of the transaction bundle if soft delete operations were part of the transaction bundle. The issue has been fixed.