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
title: Overview of selectable search parameter functionality in Azure Health Data Services
3
-
description: This article describes an overview of selectable search parameter that is implemented in Azure Health Data Services
2
+
title: Selectable search parameters for the FHIR service in Azure Health Data Services
3
+
description: Learn how to use selectable search parameters in the FHIR service of Azure Health Data Services to customize and optimize your searches on FHIR resources. Save storage space and improve performance by enabling only the search parameters you need.
4
4
author: expekesheth
5
5
ms.service: healthcare-apis
6
6
ms.subservice: fhir
7
7
ms.topic: reference
8
-
ms.date: 07/24/2023
8
+
ms.date: 01/24/2023
9
9
ms.author: kesheth
10
10
---
11
11
12
-
13
-
# Selectable search parameter capability
14
-
Searching for resources is fundamental to FHIR. Each resource in FHIR carries information as a set of elements, and search parameters work to query the information in these elements. As the FHIR service in Azure health data services is provisioned, inbuilt search parameters are enabled by default. During the ingestion of data in the FHIR service, specific properties from FHIR resources are extracted and indexed with these search parameters. This is done to perform efficient searches.
15
-
16
-
The selectable search parameter functionality allows you to enable or disable inbuilt search parameters. This functionality helps you to store more resources in allocated storage space and have performance improvements, by enabling only needed search parameters.
12
+
# Selectable search parameters (Preview)
17
13
18
14
> [!IMPORTANT]
19
-
> selectable search capability is currently in preview.
20
-
> 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.
21
-
> For more information, review [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
15
+
> The selectable search parameter capability is available for preview. Preview APIs and SDKs are provided without a service-level agreement (SLA). 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, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
22
16
23
-
This article provides a guide to using selectable search parameter functionality.
17
+
Searching for resources is fundamental to the FHIR® service. Each resource in the FHIR service carries information as a set of elements. Search parameters work to query the information in these elements. When the FHIR service is deployed, [inbuilt search parameters](https://www.hl7.org/fhir/searchparameter-registry.html) are enabled by default. The FHIR service performs efficient searches by extracting and indexing specific properties from FHIR resources during the ingestion of data.
24
18
25
-
## Guide on using selectable search parameter
19
+
Selectable search parameters allow you to enable or disable inbuilt search parameters. This capability helps you store more resources in allocated storage space and improve performance by enabling only the search parameters you need.
26
20
27
-
To perform status updates on search parameter(s), you need to follow the steps:\
28
-
Step 1: Get status of search parameter(s)\
29
-
Step 2: Update status of search parameter(s)\
30
-
Step 3: Execute a reindex job
21
+
To perform status updates on search parameters, follow these main steps:
31
22
32
-
Throughout this article, we demonstrate FHIR search syntax in example API calls with the {{FHIR_URL}} placeholder to represent the FHIR server URL.
23
+
1.[Get the status of search parameters](#get-the-status-of-search-parameters).
24
+
1.[Update the status of search parameters](#update-the-status-of-search-parameters).
25
+
1.[Execute a reindex job](#execute-a-reindex-job).
33
26
34
-
### Step 1: Get status of search parameter(s)
35
-
An API endpoint (‘$status’) is provided to view the status of search parameters.
27
+
In this article, we demonstrate FHIR search syntax in example API calls with the {{FHIR_URL}} placeholder to represent the FHIR server URL.
36
28
37
-
There are four different statuses that are seen in the response:
38
-
***Supported**: This status indicates that the search parameter is supported by the FHIR service, and the user has submitted requests to enable the search parameter. Note: Reindex operation needs to be executed to run from supported to enabled.
39
-
***Enabled**: This status indicates that the search parameter is enabled for searching. This is the next step after the supported status.
40
-
***PendingDisable**: This status indicates that search parameter will be disabled after execution of the reindex operation.
41
-
***Disabled**: This status indicates that the search parameter is disabled.
29
+
## Get the status of search parameters
30
+
An API endpoint (‘$status’) is provided to view the status of search parameters. There are four statuses for the response:
42
31
32
+
| Status | Description |
33
+
| --- | --- |
34
+
| Supported | The search parameter is supported by the FHIR service, and you submitted requests to enable the search parameter. Execute the reindex operation to run from supported to enabled. |
35
+
| Enabled | The search parameter is enabled for searching. This status is the next step after the supported status. |
36
+
| PendingDisable | Disabling the search parameter is pending after execution of the reindex operation. |
37
+
| Disabled | The search parameter is disabled. |
43
38
44
-
To get the status across all search parameters, use the following request
39
+
To get the status across all search parameters, use the following request. This request returns a list of all the search parameters and their status. Scroll through the list to find the search parameter you need.
45
40
```rest
46
41
GET {{FHIR_URL}}/SearchParameter/$status
47
42
```
48
43
49
-
This returns a list of all the search parameters with their individual statuses. You can scroll through the list to find the search parameter you need.
50
-
51
-
To identify status of individual or subset of search parameters you can use the filters listed.
52
-
***Name**: To identify search parameter status by name use request,
44
+
To identify the status of individual or a subset of search parameters, use these filters:
45
+
***Name**. To identify search parameter status by name, use this request:
53
46
```rest
54
47
GET {{FHIR_URL}}/SearchParameter/$status?code=<name of search parameter/ sub string>
55
48
```
56
-
***URL**: To identify search parameter status by its canonical identifier use request,
49
+
***URL**. To identify search parameter status by its canonical identifier, use this request:
57
50
```rest
58
51
GET {{FHIR_URL}}/SearchParameter/$status?url=<SearchParameter url>
59
-
```
60
-
***Resource type**: In FHIR, search parameters are enabled at individual resource level to enable filtering and retrieving specific subset of resources. To identify status of all the search parameters mapped to resource, use request.
52
+
```
53
+
***Resource type**. In FHIR, search parameters are enabled at the individual resource level to allow filtering and retrieving of a specific subset of resources. To identify the status of all the search parameters mapped to a resource, use this request:
61
54
```rest
62
55
GET {{FHIR_URL}}/SearchParameter/$status?resourcetype=<ResourceType name>
63
56
```
64
57
65
-
In response to the GET request to $status endpoint, you'll see Parameters resource type returned with the status of the search parameter. See the example response:
58
+
In response to the GET request to $status endpoint, the parameters resource type is returned with the status of the search parameter. See the example response:
66
59
```rest
67
60
{
68
61
"resourceType" : "Parameters",
@@ -81,14 +74,19 @@ In response to the GET request to $status endpoint, you'll see Parameters resour
81
74
]
82
75
}
83
76
```
84
-
Now that you're aware on how to get the status of search parameters, lets move to the next step to understand on updating the status of search parameters to 'Supported' or 'Disabled'.
85
77
86
-
### Step 2: Update status of search parameter(s)
87
-
Note: To update the status of search parameters you need to have Azure RBAC role assigned: Search Parameter Manager.
78
+
## Update the status of search parameters
79
+
80
+
After you get the status of search parameters, update the status of search parameters to `Supported` or `Disabled`.
88
81
89
-
Search Parameter Status can be updated for single search parameter or in bulk.
90
-
#### 1. Update Single search parameter status.
91
-
To update the status of single search parameter, use the API request.
82
+
> [!NOTE]
83
+
> To update the status of search parameters, you need the **Search Parameter Manager** Azure RBAC role.
84
+
85
+
Search parameter status can be updated for a single search parameter or in bulk.
86
+
87
+
#### Update a single search parameter status
88
+
89
+
To update the status of a single search parameter, use this API request:
92
90
93
91
```rest
94
92
PUT {{FHIR_URL}}/SearchParameter/$status
@@ -112,12 +110,11 @@ PUT {{FHIR_URL}}/SearchParameter/$status
112
110
}
113
111
```
114
112
115
-
Depending on your use case, you can choose to keep the status state value to either ‘Supported’ or ’Disabled’ for a search parameter.
116
-
Note when sending state 'Disabled' in the request, the response returns in the response as 'PendingDisable', since a reindex job needs to be run to fully remove associations.
113
+
Depending on your use case, you can keep the status state value to either ‘Supported’ or ’Disabled’ for a search parameter. When you send the state `Disabled` in the request, the response returns as `PendingDisable` because a reindex job must run to fully remove associations.
117
114
118
-
If you receive a 400 HTTP status code in the response, it means there is no unique match for identified search Parameter. Check the search parameter ID.
115
+
If you receive a 400 HTTP status code in the response, it means there's no unique match for identified search Parameter. Check the search parameter ID.
119
116
120
-
#### 2. Update search parameter status in bulk
117
+
#### Update search parameter status in bulk
121
118
To update the status of search parameters in bulk, the ‘PUT’ request should have the ‘Parameters’ resource list in the request body. The list needs to contain the individual search parameters that need to be updated.
122
119
123
120
```rest
@@ -151,20 +148,19 @@ PUT {{FHIR_URL}}/SearchParameter/$status
151
148
}
152
149
```
153
150
154
-
After you have updated the search parameter status to 'Supported' or 'Disabled', the next step is to execute reindex job.
151
+
## Execute a reindex job
155
152
156
-
### Step 3: Execute a reindex job.
157
-
Until the search parameter is indexed, the 'Enabled' and 'Disabled' status of the search parameters aren't activated. Reindex job execution helps to update the status from 'Supported' to 'Enabled' or 'PendingDisable' to 'Disabled'.
158
-
Reindex job can be executed against entire FHIR service database or against specific search parameters. Reindex job can be performance intensive. [Read guide](how-to-run-a-reindex.md) on reindex job execution in FHIR service.
153
+
After you update the search parameter status to `Supported` or `Disabled`, the next step is to execute a reindex job.
159
154
160
-
Note: A Capability Statement documents a set of capabilities (behaviors) of a FHIR Server. Capability statement is available with /metadata endpoint. 'Enabled' search parameters are listed in capability statement of your FHIR service
155
+
Until the search parameter is indexed, the `Enabled` and `Disabled` status of the search parameters aren't activated. Reindex job execution updates the status from `Supported` to `Enabled` or `PendingDisable` to `Disabled`.
161
156
162
-
## Next steps
157
+
A reindex job can be executed against the entire FHIR service database or against specific search parameters. A reindex job can be performance intensive. For more information, see [Run a reindex job](how-to-run-a-reindex.md).
163
158
164
-
In this article, you've learned how to update status of built-in search parameters in your FHIR service. To learn how to define custom search parameters, see
159
+
> [!NOTE]
160
+
> A capability statement document is a set of behaviors for a FHIR server. A capability statement is available for the /metadata endpoint. `Enabled` search parameters are listed in the capability statement for your FHIR service.
Copy file name to clipboardExpand all lines: articles/healthcare-apis/release-notes.md
+13-5Lines changed: 13 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,25 +1,25 @@
1
1
---
2
2
title: Azure Health Data Services monthly releases
3
-
description: Find out about new capabilities and enhancements released monthly for Azure Health Data Services.
3
+
description: Stay updated with the latest features and improvements of Azure Health Data Services. Read the monthly release notes and learn how to get the most out of healthcare data.
4
4
services: healthcare-apis
5
5
author: kgaddam10
6
6
ms.service: healthcare-apis
7
7
ms.subservice: workspace
8
8
ms.topic: reference
9
-
ms.date: 01/22/2023
9
+
ms.date: 01/24/2023
10
10
ms.author: kavitagaddam
11
11
ms.custom: references_regions
12
12
---
13
13
14
14
# Release notes: Azure Health Data Services
15
15
16
-
> Azure Health Data Services is generally available.
17
-
>For more information about Azure Health Data Services Service Level Agreements, see [SLA for Azure Health Data Services](https://azure.microsoft.com/support/legal/sla/health-data-services/v1_1/).
18
-
19
16
Azure Health Data Services is a set of managed API services based on open standards and frameworks for the healthcare industry. They enable you to build scalable and secure healthcare solutions by bringing protected health information (PHI) datasets together and connecting them end-to-end with tools for machine learning, analytics, and AI.
20
17
21
18
This article provides details about the features and enhancements made to Azure Health Data Services, including the different services (FHIR service, DICOM service, and MedTech service) that seamlessly work with one another.
22
19
20
+
> [!IMPORTANT]
21
+
> Azure Health Data Services is generally available. For more information, see the [Service Level Agreement (SLA) for Azure Health Data Services](https://azure.microsoft.com/support/legal/sla/health-data-services/v1_1/).
22
+
23
23
## January 2024
24
24
25
25
### DICOM service
@@ -36,6 +36,14 @@ Learn more:
36
36
37
37
### FHIR service
38
38
39
+
**Selectable search parameter capability is available for preview**
40
+
41
+
The selectable search parameter capability allows you to customize and optimize searches on FHIR resources. The capability lets you choose which inbuilt search parameters to enable or disable for the FHIR service. By enabling only the search parameters you need, you can store more FHIR resources and potentially improve performance of FHIR search queries
42
+
43
+
Learn more:
44
+
45
+
-[Selectable search parameters for the FHIR service](fhir/selectable-search-parameters.md)
46
+
39
47
**FHIR service integration with Azure Active Directory B2C is generally available**
40
48
41
49
Healthcare organizations can use the FHIR service in Azure Health Data Services with Azure Active Directory B2C (Azure AD B2C). This capability gives organizations a secure and convenient way to grant access to the FHIR service in Azure Health Data Services with fine-grained access control for different users or groups, without creating or comingling user accounts in their organization’s Microsoft Entra ID tenant. With this integration, organizations can:
0 commit comments