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

Co-authored-by: Kendal Bond <[email protected]>

Author: evachen96

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

@@ -18,7 +18,7 @@ ms.author: kesheth
 Azure API for FHIR® provides a fully managed deployment of the Microsoft FHIR Server for Azure. The server is an implementation of the [FHIR](https://hl7.org/fhir) standard. This document provides details about the features and enhancements made to Azure API for FHIR.
 
 ## April 2025
-**Enhanced error handling for READ operations with wrong cases on resource types**: Added validation on the resource type with wrong casing for READ operations (e.g. GET /patient/ instead of GET /Patient/). In the past, a request with the wrong casing resource type was causing 500 status code (InternalServerError) in API for FHIR (CosmosDB). After this change, a request with the wrong casing resource type will be rejected with 400 status code (ResourceNotSupported) as the resource type in any request should be validated in the case-sensitive manner. 
+**Enhanced error handling for READ operations with wrong cases on resource types**: Added validation on the resource type with wrong casing for READ operations (for example, GET /patient/ instead of GET /Patient/). In the past, a request with the wrong casing resource type was causing 500 status code (InternalServerError) in API for FHIR (Cosmos DB). After this change, a request with the wrong casing resource type will be rejected with 400 status code (ResourceNotSupported) as the resource type in any request should be validated in the case-sensitive manner.
 
 #### Bug fixes:
 **Custom search parameters with same "code" value on different resource types fix**: An issue was discovered where upon running a delete or update search parameter operation, all of the other related search parameters that matched on the same "code" value, even those for other resource types, were being removed. This issue was fixed, and users will now be able to update and delete custom search parameters without affecting other search parameters that have the same "code" value on other resource types.