Establishing a Connection

With the CData Cmdlets users can install a data module, set the connection properties, and start scripting. This section provides examples of using our FHIR Cmdlets with native PowerShell cmdlets, like the CSV import and export cmdlets.

Installing and Connecting

If you have PSGet, installing the cmdlets can be accomplished from the PowerShell Gallery with the following command. You can also obtain a setup from the CData site.

Install-Module FHIRCmdlets

The following line is then added to your profile, loading the cmdlets on the next session:

Import-Module FHIRCmdlets;

You can then use the Connect-FHIR cmdlet to create a connection object that can be passed to other cmdlets:

$conn = Connect-FHIR -URL "http://test.fhir.org/r4b/" -ConnectionType "Generic" -ContentType "JSON" -AuthScheme "None"

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 cmdlet 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 cmdlet 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:

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 cmdlet opens FHIR's OAuth endpoint in your default browser. Log in and grant permissions to the application. The cmdlet refreshes the access token automatically when it expires.

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.

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 cmdlet 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.
Configure the cmdlet 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.

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.
Log in and grant permissions to the cmdlet. You are then redirected to the redirect URI, which contains the verifier code.
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 cmdlet 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 cmdlet to enable the automatic refreshing of the access token.

Azure FHIR Instances

The cmdlet 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 cmdlet 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 cmdlet 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 cmdlet to attempt to retrieve credentials for the specified role.

Google FHIR Instances

The cmdlet 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 cmdlet.

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.
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.
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.

Retrieving Data

The Select-FHIR cmdlet provides a native PowerShell interface for retrieving data:

$results = Select-FHIR -Connection $conn -Table "Patient" -Columns @("Id, [address-city]") -Where "[name-use]='Bob'"

The Invoke-FHIR cmdlet provides an SQL interface. This cmdlet can be used to execute an SQL query via the Query parameter.

Piping Cmdlet Output

The cmdlets return row objects to the pipeline one row at a time. The following line exports results to a CSV file:

Select-FHIR -Connection $conn -Table Patient -Where "[name-use] = 'Bob'" | Select -Property * -ExcludeProperty Connection,Table,Columns | Export-Csv -Path c:\myPatientData.csv -NoTypeInformation

You will notice that we piped the results from Select-FHIR into a Select-Object cmdlet and excluded some properties before piping them into an Export-CSV cmdlet. We do this because the CData Cmdlets append Connection, Table, and Columns information onto each row object in the result set, and we do not necessarily want that information in our CSV file.

However, this makes it easy to pipe the output of one cmdlet to another. The following is an example of converting a result set to JSON:

 
PS C:\> $conn  = Connect-FHIR -URL "http://test.fhir.org/r4b/" -ConnectionType "Generic" -ContentType "JSON" -AuthScheme "None"
PS C:\> $row = Select-FHIR -Connection $conn -Table "Patient" -Columns (Id, [address-city]) -Where "[name-use] = 'Bob'" | select -first 1
PS C:\> $row | ConvertTo-Json
{
  "Connection":  {

  },
  "Table":  "Patient",
  "Columns":  [

  ],
  "Id":  "MyId",
  "[address-city]":  "My[address-city]"
}

Cmdlets for FHIR

Establishing a Connection

Installing and Connecting

Connecting to FHIR

Authenticating to FHIR

Generic FHIR Instances

OAuth

Desktop Applications

Headless Machines

Azure FHIR Instances

Azure Active Directory

Azure MSI

Azure Service Principal

AWS FHIR Instances

AWS Root Keys

AWS IAM Roles

AWS EC2 Roles

Google FHIR Instances

OAuth

Service Accounts (OAuth JWT)

Google JSON Certificates

PFX File Certificates

Retrieving Data

Piping Cmdlet Output