You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/healthcare-apis/azure-api-for-fhir/release-notes-2025.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,9 +21,9 @@ Azure API for FHIR® provides a fully managed deployment of the Microsoft FHI
21
21
**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.
22
22
23
23
#### Bug fixes:
24
-
**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.
24
+
**Custom search parameters with same "code" value on different resource types fix**: An issue was discovered when running a delete or update search parameter operation. All matched related search parameters on the same "code" value were being removed, regardless of resource type. This issue was fixed, and users are now able to update and delete custom search parameters without affecting other search parameters or resource types with the same "code" value.
25
25
26
-
**Fix for deleting and uploading custom search parameters**: An issue was discovered where deleting a custom search parameter and then subsequently using PUT operation to re-upload that same search parameter could potentially cause a 424 Failed Dependency error. We have fixed this issue by adding a check to ensure that if the previous version of the search parameter was already deleted, it will be properly handled. Users will now be able to delete a custom search parameter and then re-upload that search parameter using PUT.
26
+
**Fix for deleting and uploading custom search parameters**: An issue when deleting a custom search parameter and then using the PUT operation to reupload that same search parameter potentially causes a 424 Failed Dependency error. This issue is fixed. A check was added to ensure that if the previous version of the search parameter was already deleted, it's properly handled. Users are now able to delete a custom search parameter and then reupload that search parameter using PUT.
Copy file name to clipboardExpand all lines: articles/healthcare-apis/release-notes-2025.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,23 +18,23 @@ This article describes features, enhancements, and bug fixes released in 2025 fo
18
18
## April 2025
19
19
### FHIR service
20
20
21
-
**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.
21
+
**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.
22
22
23
23
**Stability improvements**: Introduced merge throttling to manage code execution waits, improving system stability under high concurrency conditions.
24
24
25
-
**Custom error container for $import**: Added ability for users to specify the name of the container where errors encountered during $import are logged. If not specified, the default container will be used. More information [here](/articles/healthcare-apis/fhir/import-data.md).
25
+
**Custom error container for $import**: Added ability for users to specify the name of the container where errors encountered during $import are logged. If not specified, the default container is used. More information [here](/articles/healthcare-apis/fhir/import-data.md).
26
26
27
-
**Search for not referenced resources**: Added functionality to search for resources that are not referenced by other resources.
27
+
**Search for not referenced resources**: Added functionality to search for resources that aren't referenced by other resources.
28
28
29
-
**Improved search error handling**: Previously, a search query with too many parameters would return a 500 error without any error message. Now, if a search query has too many parameters, the FHIR server will return a 400 error with the error message: "The incoming request has too many parameters. Reduce the number of parameters and resend the request."
29
+
**Improved search error handling**: Previously, a search query with too many parameters returns a 500 error without any error message. Now, if a search query has too many parameters, the FHIR server will return a 400 error with the error message: "The incoming request has too many parameters. Reduce the number of parameters and resend the request."
30
30
31
-
**Search with _include and _revinclude enhancements**: Previously, searches with _include and _revinclude were limited to return a maximum of 100 items, meaning that results would get truncated at 100 _include and _revinclude items. Now, we have removed that 100 item limit, through the introduction of a "Related" link with the $includes operation, and a new search result parameter called _includesCount that will allow customers to page through the _include and _revinclude items. The parameter _includesCount, which is set by default to the maximum value of 1000, can be used to configure how many _include and _revinclude items are on each page. Customers can use the "Related" link in the original search response and the "Next" link in the response from the "Related" link to page through the _include and _revinclude items. More infromation[here](/articles/healthcare-apis/fhir/overview-of-search.md).
31
+
**Search with _include and _revinclude enhancements**: Previously, searches with `_include` and `_revinclude` were limited to return a maximum of 100 items, possibly truncating results. That limit has been removed through the introduction of a "Related" link with the $includes operation, and a new search result parameter called `_includesCount` that allows customers to page through the `_include` and `_revinclude` items. The parameter `_includesCount`can be used to configure how many `_include` and _`revinclude` items are on each page. Its default value is 1000. Customers can use the "Related" link in the original search response, and the "Next" link in the response from the "Related" link to page through the `_include` and `_revinclude` items. More information[here](/articles/healthcare-apis/fhir/overview-of-search.md).
32
32
33
33
34
34
#### Bug fixes:
35
-
**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.
35
+
**Custom search parameters with same "code" value on different resource types fix**: An issue was discovered when running a delete or update search parameter operation. All matched related search parameters on the same "code" value were being removed, regardless of resource type. This issue was fixed, and users are now able to update and delete custom search parameters without affecting other search parameters or resource types with the same "code" value.
36
36
37
-
**Fix for deleting and uploading custom search parameters**: An issue was discovered where deleting a custom search parameter and then subsequently using PUT operation to re-upload that same search parameter could potentially cause a 424 Failed Dependency error. We have fixed this issue by adding a check to ensure that if the previous version of the search parameter was already deleted, it will be properly handled. Users will now be able to delete a custom search parameter and then re-upload that search parameter using PUT.
37
+
**Fix for deleting and uploading custom search parameters**: An issue when deleting a custom search parameter and then using the PUT operation to reupload that same search parameter potentially causes a 424 Failed Dependency error. This issue is fixed. A check was added to ensure that if the previous version of the search parameter was already deleted, it's properly handled. Users are now able to delete a custom search parameter and then reupload that search parameter using PUT.
0 commit comments