Connecting to FHIR

Set Url to the Service Base URL of the FHIR server. This is the address where the resources are defined in the FHIR server you would like to connect to.

Generic, Azure-based, AWS-based, and Google-based FHIR server implementations are supported.

Sample Urls for each implementation are found below:

• Generic: http://my_fhir_server/r4b/
• Azure: https://MY_AZURE_FHIR.azurehealthcareapis.com/
• AWS: https://healthlake.REGION.amazonaws.com/datastore/DATASTORE_ID/r4/
• Google: https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/fhirStores/FHIR_STORE_ID/fhir/

Authenticating to FHIR

Generic FHIR Instances

The provider supports connections to custom instances of FHIR.

Authentication to custom FHIR servers is handled via OAuth.

Before you can connect to custom FHIR instances, you must set ConnectionType to Generic.

OAuth

Set the AuthScheme to OAuth.

OAuth requires the authenticating user to interact with FHIR using the browser. The provider facilitates this in various ways as described in the following sections.

Before following the procedures below, you need to register an OAuth app with the service to obtain OAuthClientId and OAuthClientSecret.

Desktop Applications

Get and Refresh the OAuth Access Token

After setting the following, you are ready to connect:

• InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
• OAuthClientId: Set this to the client Id assigned when you registered your app.
• OAuthClientSecret: Set this to the client secret assigned when you registered your app.
• CallbackURL: Set this to the redirect URI defined when you registered your app. For example: https://localhost:3333
• OAuthAuthorizationURL: This is the URL where the user logs into the service and grants permissions to the application.
• OAuthAccessTokenURL: This is the URL where the request for the access token is made.
• OAuthRefreshTokenURL: This is the URL where the refresh token is exchanged for a new access token when the old one expires. Note that, for your data source, this may be the same as the access token URL.

When you connect, the provider opens FHIR's OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process:

1. The provider obtains an access token from FHIR and uses it to request data.
2. The OAuth values are saved in the location specified in OAuthSettingsLocation, to be persisted across connections.

The provider refreshes the access token automatically when it expires.

Web Applications

When connecting via a Web application, or if the provider is not authorized to open a browser window, use the provided stored procedures to get and manage the OAuth token values.

Note: You can extend the stored procedure schemas to set defaults for the OAuth URLs or other connection string properties.

Set Up the OAuth Flow

Provide the OAuth URLs to authenticate in the Web flow.

• OAuthAuthorizationURL: Required for OAuth 2.0. This is the URL where the user logs into the service and grants permissions to the application.
• OAuthAccessTokenURL: Required for OAuth 2.0. This is the URL where the request for the access token is made.
• OAuthRefreshTokenURL: Required for OAuth 2.0. In OAuth 2.0 this is the URL where the refresh token is exchanged for a new access token when the old one expires. Note that for your data source this may be the same as the access token URL.

Get an Access Token

In addition to the OAuth URLs, set the following additional connection properties to obtain OAuthAccessToken:

• OAuthClientId: Set this to the client Id in your app settings. This is also called the consumer key.
• OAuthClientSecret: Set this to the client secret in your app settings. This is also called the consumer secret.
• OAuthVersion: Set this to the OAuth version 2.0.

You can then call stored procedures to complete the OAuth exchange:

1. Call the GetOAuthAuthorizationURL stored procedure. Set the CallbackURL input to the Redirect URI you specified in your app settings. The stored procedure returns the URL to the OAuth endpoint.
2. Log in and authorize the application. You are redirected back to the callback URL.
3. Call the GetOAuthAccessToken stored procedure. Set the AuthMode input to WEB.

   In OAuth 2.0, set the Verifier input to the code parameter in the query string of the callback URL.

Connect to Data and Refresh the Token

The OAuthAccessToken returned by GetOAuthAccessToken has a limited lifetime. To automatically refresh the token, set the following on the first data connection. Alternatively, use the RefreshOAuthAccessToken stored procedure to manually refresh the token.

OAuth Endpoints

• OAuthAuthorizationURL
• OAuthAccessTokenURL
• OAuthRefreshTokenURL

OAuth Tokens and Keys

• OAuthClientId
• OAuthClientSecret
• OAuthRefreshToken
• OAuthAccessToken

Initiate OAuth

• OAuthVersion: Set this to 2.0.
• InitiateOAuth: Set this to REFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken.
• OAuthSettingsLocation: Set this to the location where the provider will save the OAuth values, to be persisted across connections.

On subsequent data connections, set the following:

• InitiateOAuth
• OAuthSettingsLocation
• OAuthRequestTokenURL
• OAuthAuthorizationURL
• OAuthAccessTokenURL
• OAuthRefreshTokenURL

Headless Machines

To configure the driver to use OAuth with a user account on a headless machine, you need to authenticate on another device that has an internet browser.

1. Choose one of two options:
   • Option 1: Obtain the OAuthVerifier value as described in "Obtain and Exchange a Verifier Code" below.
   • Option 2: Install the provider on a machine with an Internet browser and transfer the OAuth authentication values after you authenticate through the usual browser-based flow, as described in "Transfer OAuth Settings" below.
2. Configure the provider to automatically refresh the access token on the headless machine.

Option 1: Obtain and Exchange a Verifier Code

To obtain a verifier code, you must authenticate at the OAuth authorization URL.

Follow the steps below to authenticate from the machine with an Internet browser and obtain the OAuthVerifier connection property.

1. Choose one of these options:
   • Create the Authorization URL by setting the following properties:
     • InitiateOAuth: Set to OFF.
     • OAuthClientId: Set to the client Id assigned when you registered your application.
     • OAuthClientSecret: Set to the client secret assigned when you registered your application.
     Call the GetOAuthAuthorizationURL stored procedure with the appropriate CallbackURL. Open the URL returned by the stored procedure in a browser.
2. Log in and grant permissions to the provider. You are then redirected to the redirect URI, which contains the verifier code.
3. Save the value of the verifier code. Later you will set this in the OAuthVerifier connection property.

Next, you need to exchange the OAuth verifier code for OAuth refresh and access tokens. Set the following properties:

On the headless machine, set the following connection properties to obtain the OAuth authentication values.

• InitiateOAuth: Set this to REFRESH.
• OAuthVerifier: Set this to the verifier code.
• OAuthClientId: Set this to the Client Id in your custom OAuth application settings.
• OAuthClientSecret: Set this to the Client Secret in the custom OAuth application settings.
• OAuthSettingsLocation: Set this to persist the encrypted OAuth authentication values to the specified location.

After the OAuth settings file is generated, you need to re-set the following properties to connect:

• InitiateOAuth: Set this to REFRESH.
• OAuthClientId: Set this to the client Id assigned when you registered your application.
• OAuthClientSecret: Set this to the client secret assigned when you registered your application.
• OAuthSettingsLocation: Set this to the location containing the encrypted OAuth authentication values. Make sure this location gives read and write permissions to the provider to enable the automatic refreshing of the access token.

Option 2: Transfer OAuth Settings

Prior to connecting on a headless machine, you need to install and create a connection with the driver on a device that supports an Internet browser. Set the connection properties as described in "Desktop Applications" above.

After completing the instructions in "Desktop Applications", the resulting authentication values are encrypted and written to the location specified by OAuthSettingsLocation. The default filename is OAuthSettings.txt.

Once you have successfully tested the connection, copy the OAuth settings file to your headless machine.

On the headless machine, set the following connection properties to connect to data:

• InitiateOAuth: Set this to REFRESH.
• OAuthClientId: Set this to the client Id assigned when you registered your application.
• OAuthClientSecret: Set this to the client secret assigned when you registered your application.
• OAuthSettingsLocation: Set this to the location of your OAuth settings file. Make sure this location gives read and write permissions to the provider to enable the automatic refreshing of the access token.

Azure FHIR Instances

The provider supports connections to instances of FHIR hosted on Microsoft Azure.

You can authenticate with Azure Active Directory, an Azure Service Principal, or Azure MSI.

Before you can connect to FHIR instances hosted on Azure, you must set ConnectionType to Azure.

Azure Active Directory

You can connect to FHIR instances hosted on Azure using an OAuth app registered with Azure Active Directory.

Set AuthScheme to AzureAD.

Embedded App

CData provides an embedded OAuth application that simplifies OAuth desktop Authentication. To authenticate using the embedded OAuth app, connect without setting any additional connection properties.

Custom App

Alternatively, you can create a custom OAuth application. See Creating a Custom OAuth App for information about creating custom applications and reasons for doing so.

Once your OAuth app has been created, set the following to connect:

• OAuthClientId: Set this to the Application (client) ID, found on the Overview page of the OAuth app.
• OAuthClientSecret: Set this to the Value of the client secret, generated at the Certificates and secrets page of the OAuth app.
• AzureTenant (single tenant apps only): Set this to the Azure tenant Id, found on the Overview page of the OAuth app.
• CallbackURL: Set this to the value you specified for Redirect URI during the creation of your custom OAuth app.

Azure MSI

If you are running FHIR on an Azure VM, set AuthScheme to AzureMSI to authenticate using Managed Service Identity (MSI) credentials.

The MSI credentials will then be automatically obtained for authentication.

Azure Service Principal

You can authenticate to Azure-hosted instances of FHIR using an Azure service principal.

See Creating a Custom OAuth App for information about creating custom applications and reasons for doing so.

Once your OAuth app has been created, set the following to connect:

• AuthScheme: Set this to AzureServicePrincipal.
• OAuthClientId: Set this to the Application (client) ID, found on the Overview page of the OAuth app used to authenticate to FHIR on Azure.
• OAuthClientSecret: Set this to the Value of the client secret, generated at the Certificates and secrets page of the authenticating OAuth app.
• CallbackURL: Set this to the value you specified for Redirect URI during the creation of your custom OAuth app.
• OAuthJWTCert: Set this to the path of your service principal's certificate.
• OAuthJWTCertType: Set this to your service principal's certificate type.

AWS FHIR Instances

The provider supports connections to instances of FHIR hosted on AWS.

You can authenticate with AWS Root Keys, AWS EC2 Roles, or AWS IAM Roles.

Before you can connect to FHIR instances hosted on AWS, you must set ConnectionType to AWS.

AWS Root Keys

You can authenticate using the access keys for the root AWS user. Set the following:

• AuthScheme: Set this to AwsRootKeys.
• AWSAccessKey: Set this to your AWS account access key. This value is accessible from your AWS security credentials page.
• AWSSecretKey: Set this to your AWS account secret key. This value is accessible from your AWS security credentials page.

AWS IAM Roles

To authenticate to your AWS-hosted FHIR using IAM roles, set the following:

• AuthScheme: Set this to AwsIAMRoles.
• AWSAccessKey: Set this to your AWS account access key. This value is accessible from your AWS security credentials page.
• AWSSecretKey: Set this to your AWS account secret key. This value is accessible from your AWS security credentials page.
• AWSRoleARN: Set this to the Amazon Resource Name of the role you want to use when authenticating.

AWS EC2 Roles

If you are using the provider from an EC2 Instance and have an IAM Role assigned to the instance, you can use the IAM role to authenticate.

Set AuthScheme to AwsEC2Roles.

If you are also using an IAM role to authenticate, you must additionally set AWSRoleARN to the Role ARN for the role you'd like to authenticate with. This will cause the provider to attempt to retrieve credentials for the specified role.

Google FHIR Instances

The provider supports connections to instances of FHIR hosted on Google Cloud Platform.

You can authenticate with standard OAuth or Service account authentication (with a JWT).

Before you can connect to FHIR instances hosted on Google Cloud Platform, you must set ConnectionType to Google.

OAuth

Set AuthScheme to OAuth.

Embedded App

CData provides an embedded OAuth application that simplifies OAuth desktop Authentication. To authenticate using the embedded OAuth app, connect without setting any additional connection properties.

Custom App

Alternatively, you can create a custom OAuth application. See Creating a Custom OAuth App for information about creating custom applications and reasons for doing so.

Unlike the Generic connection type, when ConnectionType is set to Google, OAuthAuthorizationURL, OAuthRefreshTokenURL, and OAuthAccessTokenURL are not required to be set.

This is because, when connecting to an instance of FHIR hosted on Google Cloud Platform, these properties have default values embedded in the provider.

Aside from omitting those properties, follow the same procedures for configuring OAuth authentication as with generic implementations of FHIR (see the "OAuth" section under the "Generic FHIR Instances" section above).

Service Accounts (OAuth JWT)

To authenticate using a service account, you must create a new service account and have a copy of the accounts certificate.

Google JSON Certificates

If you would like to use a JSON file as the certificate, you need to set these properties:

• AuthScheme: Set this to OAuthJWT.
• InitiateOAuth: Set this to GETANDREFRESH.
• OAuthJWTCertType: Set this to GOOGLEJSON.
• OAuthJWTCert: Set this to the path to the .json file provided by Google.
• OAuthJWTSubject (optional): Only set this value if the service account is part of a GSuite domain and you want to enable delegation. The value of this property should be the email address of the user whose data you want to access.

PFX File Certificates

If you would like to use a PFX file as the certificate, you need to set these properties instead:

• AuthScheme: Set this to OAuthJWT.
• InitiateOAuth: Set this to GETANDREFRESH.
• OAuthJWTCertType: Set this to PFXFILE.
• OAuthJWTCert: Set this to the path to the .pfx file provided by Google.
• OAuthJWTCertPassword (optional): Set this to the .pfx file password. In most cases, you will need to set this since Google encrypts PFX certificates.
• OAuthJWTCertSubject (optional): Set this only if you are using a OAuthJWTCertType which stores multiple certificates. Should not be set for PFX certificates generated by Google.
• OAuthJWTIssuer: Set this to the email address of the service account. This address will usually include the domain iam.gserviceaccount.com.
• OAuthJWTSubject (optional): Only set this value if the service account is part of a GSuite domain and you want to enable delegation. The value of this property should be the email address of the user whose data you want to access.