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
You have several configuration options to choose from when you're setting up the Azure API for FHIR or the FHIR Server for Azure (OSS). For open source, you'll need to create your own resource application registration. For Azure API for FHIR, this resource application is created automatically.
17
+
There are several configuration options to choose from when you're setting up the Azure API for FHIR® or the FHIR Server for Azure (OSS). For open source, you need to create your own resource application registration. For Azure API for FHIR, this resource application is created automatically.
18
18
19
19
## Application registrations
20
20
21
-
In order for an application to interact with Microsoft Entra ID, it needs to be registered. In the context of the FHIR server, there are two kinds of application registrations to discuss:
21
+
In order for an application to interact with Microsoft Entra ID, it needs to be registered. In the context of the FHIR server, there are two kinds of application registrations:
22
22
23
23
1. Resource application registrations.
24
24
1. Client application registrations.
25
25
26
-
**Resource applications** are representations in Microsoft Entra ID of an API or resource that is secured with Microsoft Entra ID, specifically it would be the Azure API for FHIR. A resource application for Azure API for FHIR will be created automatically when you provision the service, but if you're using the open-source server, you'll need to [register a resource application](register-resource-azure-ad-client-app.md) in Microsoft Entra ID. This resource application will have an identifier URI. It's recommended that this URI be the same as the URI of the FHIR server. This URI should be used as the `Audience` for the FHIR server. A client application can request access to this FHIR server when it requests a token.
26
+
**Resource applications** are representations in Microsoft Entra ID of an API or resource that is secured with Microsoft Entra ID. Here we discuss the Azure API for FHIR. A resource application for Azure API for FHIR is created automatically when you provision the service. If you're using the open-source server, you need to [register a resource application](register-resource-azure-ad-client-app.md) in Microsoft Entra ID. This resource application has an identifier URI. It's recommended that this URI be the same as the URI of the FHIR server. This URI should be used as the `Audience` for the FHIR server. A client application can request access to this FHIR server when it requests a token.
27
27
28
-
*Client applications* are registrations of the clients that will be requesting tokens. Often in OAuth 2.0, we distinguish between at least three different types of applications:
28
+
**Client applications** are registrations of the clients that will be requesting tokens. In OAuth 2.0, we distinguish between at least three different types of applications:
29
29
30
-
1.**Confidential clients**, also known as web apps in Microsoft Entra ID. Confidential clients are applications that use [authorization code flow](../../active-directory/develop/v2-oauth2-auth-code-flow.md) to obtain a token on behalf of a signed in user presenting valid credentials. They're called confidential clients because they're able to hold a secret and will present this secret to Microsoft Entra ID when exchanging the authentication code for a token. Since confidential clients are able to authenticate themselves using the client secret, they're trusted more than public clients and can have longer lived tokens and be granted a refresh token. Read the details on how to [register a confidential client](register-confidential-azure-ad-client-app.md). Note it's important to register the reply URL at which the client will be receiving the authorization code.
31
-
1.**Public clients**. These are clients that can’t keep a secret. Typically this would be a mobile device application or a single page JavaScript application, where a secret in the client could be discovered by a user. Public clients also use authorization code flow, but they aren't allowed to present a secret when obtaining a token and they may have shorter lived tokens and no refresh token. Read the details on how to [register a public client](register-public-azure-ad-client-app.md).
32
-
1. Service clients. These clients obtain tokens on behalf of themselves (not on behalf of a user) using the [client credentials flow](../../active-directory/develop/v2-oauth2-client-creds-grant-flow.md). They typically represent applications that access the FHIR server in a non-interactive way. An example would be an ingestion process. When using a service client, it isn't necessary to start the process of getting a token with a call to the `/authorize` endpoint. A service client can go straight to the `/token` endpoint and present client ID and client secret to obtain a token. Read the details on how to [register a service client](register-service-azure-ad-client-app.md)
30
+
1.**Confidential clients**, also known as web apps in Microsoft Entra ID. Confidential clients are applications that use [authorization code flow](../../active-directory/develop/v2-oauth2-auth-code-flow.md) to obtain a token on behalf of a signed in user presenting valid credentials. They're called confidential clients because they're able to hold a secret and will present this secret to Microsoft Entra ID when exchanging the authentication code for a token. Since confidential clients are able to authenticate themselves using the client secret, they're trusted more than public clients, can have longer lived tokens, and be granted a refresh token. Read the details on how to [register a confidential client](register-confidential-azure-ad-client-app.md). Note: It's important to register the reply URL at which the client will be receiving the authorization code.
31
+
1.**Public clients**. These are clients that can’t keep a secret. Typically this would be a mobile device application or a single page JavaScript application, where a secret in the client could be discovered by a user. Public clients also use authorization code flow. However, they aren't allowed to present a secret when obtaining a token, and may have shorter lived tokens and no refresh token. Read the details on how to [register a public client](register-public-azure-ad-client-app.md).
32
+
1.**Service clients**. These clients obtain tokens on behalf of themselves (not on behalf of a user) using the [client credentials flow](../../active-directory/develop/v2-oauth2-client-creds-grant-flow.md). They typically represent applications that access the FHIR server in a non-interactive way. An example would be an ingestion process. When using a service client, it isn't necessary to start the process of getting a token with a call to the `/authorize` endpoint. A service client can go straight to the `/token` endpoint and present the client ID and client secret to obtain a token. Read the details on how to [register a service client](register-service-azure-ad-client-app.md)
33
33
34
34
## Next steps
35
35
36
-
In this overview, you've gone through the types of application registrations you may need in order to work with a FHIR API.
36
+
In this overview, you reviewed the types of application registrations you may need in order to work with a FHIR API.
37
37
38
38
Based on your setup, refer to the how-to-guides to register your applications:
39
39
@@ -47,4 +47,4 @@ After you've registered your applications, you can deploy Azure API for FHIR.
47
47
>[!div class="nextstepaction"]
48
48
>[Deploy Azure API for FHIR](fhir-paas-portal-quickstart.md)
49
49
50
-
FHIR® is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.
Copy file name to clipboardExpand all lines: articles/healthcare-apis/azure-api-for-fhir/fhir-features-supported.md
+17-17Lines changed: 17 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ ms.author: kesheth
12
12
13
13
# Features
14
14
15
-
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 lists the main features of the FHIR Server.
15
+
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 lists the main features of the FHIR Server.
16
16
17
17
## FHIR version
18
18
@@ -22,30 +22,30 @@ Previous versions also currently supported include: `3.0.2`
22
22
23
23
## REST API
24
24
25
-
Below is a summary of the supported RESTful capabilities. For more information on the implementation of these capabilities, see [FHIR REST API capabilities](fhir-rest-api-capabilities.md).
25
+
Following is a summary of the supported RESTful capabilities. For more information on the implementation of these capabilities, see [FHIR REST API capabilities](fhir-rest-api-capabilities.md).
26
26
27
27
| API | Azure API for FHIR | FHIR service in Azure Health Data Services | Comment |
| chained search | Yes | Yes | See following Note. |
41
+
| reverse chained search | Yes | Yes | See following Note. |
42
+
| batch | Yes | Yes ||
43
+
| transaction | No | Yes ||
44
44
| paging | Partial | Partial |`self` and `next` are supported |
45
-
| intermediaries | No | No |
45
+
| intermediaries | No | No ||
46
46
47
47
> [!Note]
48
-
> In the Azure API for FHIR and the open-source FHIR server backed by Azure Cosmos DB, the chained search and reverse chained search is an MVP implementation. To accomplish chained search on Azure Cosmos DB, the implementation walks down the search expression and issues sub-queries to resolve the matched resources. This is done for each level of the expression. If any query returns more than 1000 results, an error will be thrown.
48
+
> In the Azure API for FHIR and the open-source FHIR server backed by Azure Cosmos DB, the chained search and reverse chained search is an MVP implementation. To accomplish chained search on Azure Cosmos DB, the implementation walks down the search expression and issues sub-queries to resolve the matched resources. This is done for each level of the expression. If any query returns more than 1000 results, an error is thrown.
49
49
50
50
## Extended Operations
51
51
@@ -70,27 +70,27 @@ Azure Cosmos DB is a globally distributed multi-model (NoSQL, MongoDB, and other
70
70
71
71
## Role-based access control
72
72
73
-
The FHIR Server uses [Microsoft Entra ID](https://azure.microsoft.com/services/active-directory/) for access control. Specifically, role-based access control (RBAC) is enforced, if the `FhirServer:Security:Enabled` configuration parameter is set to `true`, and all requests (except `/metadata`) to the FHIR Server must have `Authorization` request header set to `Bearer <TOKEN>`. The token must contain one or more roles as defined in the `roles` claim. A request will be allowed if the token contains a role that allows the specified action on the specified resource.
73
+
The FHIR Server uses [Microsoft Entra ID](https://azure.microsoft.com/services/active-directory/) for access control. Specifically, role-based access control (RBAC) is enforced if the `FhirServer:Security:Enabled` configuration parameter is set to `true`, and all requests (except `/metadata`) to the FHIR Server must have `Authorization` request header set to `Bearer <TOKEN>`. The token must contain one or more roles as defined in the `roles` claim. A request is allowed if the token contains a role that allows the specified action on the specified resource.
74
74
75
75
Currently, the allowed actions for a given role are applied *globally* on the API.
76
76
77
77
## Service limits
78
78
79
-
*[**Request Units (RUs)**](/azure/cosmos-db/concepts-limits) - You can configure up to 100,000 RUs in the portal for Azure API for FHIR. You'll need a minimum of 400 RUs or 40 RUs/GB, whichever is larger. If you need more than 100,000 RUs, you can put in a support ticket to have the RUs increased. The maximum available is 1,000,000. In addition, we support [autoscaling of RUs](autoscale-azure-api-fhir.md).
79
+
*[**Request Units (RUs)**](/azure/cosmos-db/concepts-limits) - You can configure up to 100,000 RUs in the portal for Azure API for FHIR. You need a minimum of 400 RUs or 40 RUs/GB, whichever is larger. If you need more than 100,000 RUs, you can put in a support ticket to have the RUs increased. The maximum available is 1,000,000. In addition, we support [autoscaling of RUs](autoscale-azure-api-fhir.md).
80
80
81
81
***Bundle size** - Each bundle is limited to 500 items.
82
82
83
-
***Data size** - Data/Documents must each be slightly less than 2 MB.
83
+
***Data size** - Data/Documents must each be less than 2 MB.
84
84
85
85
***Subscription limit** - By default, each subscription is limited to a maximum of 10 FHIR server instances. If you need more instances per subscription, open a support ticket and provide details about your needs.
86
86
87
-
***Resource size** - Individual resource size including history should not exceed 20GB.
0 commit comments