Create a destination for Microsoft Azure + Health Data Services

To populate your Microsoft Azure + Health Data Services (HDS) repository with healthcare data from an EHR system via Redox, you must configure a specific Redox cloud destination. A Redox destination represents where a message is delivered (e.g., like the address in the “To” line of an email header). Learn more about connecting Redox to your cloud repository.

You’ll need to perform some steps in your cloud product(s) and some in Redox. You can perform Redox setup in our dashboard or with the Redox Platform API.

• Establish a connection with your preferred EHR system. Learn how to request a connection.
• Complete your Azure and HDS configuration before creating your Redox destination. Save any downloads with secret values, since you’ll need to enter some of these details into the Redox dashboard.
• Grant access to Redox from Azure (and any other cloud product) to authorize Redox to push data to your cloud repository.

1. Navigate to the Microsoft Azure dashboard and log in. Review Azure’s quickstart guide to get started.
2. Create an application through Microsoft Entra ID. Review Azure’s help article. This is where you’ll get a client ID and tenant ID, which you’ll need for Redox setup later.
3. Create a new secret for your application. This is where you'll get client secret value, which you'll need for Redox setup later.
4. Use Postman to access the FHIR® service in Azure Health Data Services.
5. For Redox configuration later, get the capability statement.
6. Get an access token for the FHIR® server.

Next, create a cloud destination in your Redox organization. This destination will be where your data is pushed to.

1. For the select destination step, follow the instructions for creating a cloud destination.
2. From the Product type field, select Health Data Services.
3. For the configure destination step, populate these fields. Then click the Next button.
   1. FHIR® URL: Enter the Azure FHIR® endpoint where data should be sent.
4. For the auth credential step, either a drop-down list of existing auth credentials displays or a new auth credential form opens. Learn how to create an auth credential for OAuth 2.0 Two-legged.

   Token endpoint URL

   To avoid running into validation errors when sending data to your Azure cloud destination, your auth credential should have a token endpoint URL that matches this structure:

   https://login.microsoftonline.com/<tenant id from azure console step 1>/oauth2/v2.0/token

   Existing or new auth credential

   Your existing auth credentials will only display if they're supported for the cloud product type you selected. If you don't have any supported auth credentials for the cloud type in the current Redox environment, you'll have to create a new auth credential.

5. For the verify step, follow the instructions for verifying a destination.

1. Review the Create auth credential endpoint.
2. In your terminal, prepare the /v1/authcredentials request.
3. Specify these required values in the request. These may not be noted as required fields in our API spec, but these are what’s required for working with Azure.
   • Locate the audience (FHIR® metadata endpoint) and clientID (Application ID) on the Overview page of the Microsoft Azure dashboard. The audience value is equivalent to the FHIR® metadata endpoint value. However, you must remove metadata at the end and replace it with either Bundle or fhir. For Redox, you should use Bundle.
   • Locate the clientSecret value on the Certificates & Secrets page of the Microsoft Azure dashboard when you’re creating a user. This value only displays once, so make sure you store it. Note that this isn’t the same as the secret ID value.

     Example: Create auth credential for Azure + Health Data Services

     json

     Copy

     1
     curl 'https://api.redoxengine.com/platform/v1/authcredentials' \
     2
     --request POST \
     3
     --header 'Authorization: Bearer $API_TOKEN' \
     4
     --header 'accept: application/json' \
     5
     --header 'content-type: application/json' \
     6
     --data '{
     7
         "organization": "<Redox_organization_id>"
     8
         "name": "<human_readable_name_for_auth_credential>"
     9
         "environmentId": "<Redox_environment_ID>"
     10
         "authStrategy": "OAuth_2.0_2-legged"
     11
         "audience": "<FHIR_metadata_endpoint_from_Azure>" 
     12
         "resourceURI": "<FHIR_metadata_endpoint_from_Azure>"
     13
         "clientId": "<client_id_from_Azure>"
     14
         "clientSecret": "<client_secret_from_Azure>"
     15
         "grantType": "client_credentials"  
     16
         "url": "https://login.microsoftonline.com/<tenant id from azure console_step-1>/oauth2/v2.0/token"
     17
         "scope": "https://storage.azure.com/.default"
     18
       }
4. You should get a successful 200 response and a payload populated with the details of the new auth credential.
5. Review the Create destination endpoint.
6. In your terminal, prepare the /v1/environments/{environmentId}/destinations request with these values:
   • Set authCredential to the auth credential ID from the response you received in step #4.
   • Populate cloudProviderSettings with the settings below.
     • Enter the Azure FHIR® endpoint to send to for the FHIR® base URL.

       Example: Values for Azure + HDS cloudProviderSettings

       json

       Copy

       1
       {
       2
         "cloudProviderSettings": {
       3
           "typeId": "azure",
       4
           "productId": "health-data-services", 
       5
           "settings": {
       6
             "fhirBaseUrl": "<FHIR_endpoint>"
       7
            }
       8
         }
       9
       }
7. You should get a successful 200 response with a payload populated with the details of the new Azure cloud destination. Specifically, the verified status of the destination should be set to true.
8. Your new destination will now be able to receive messages. FHIR® data is validated against the FHIR® standard schema to ensure compliance since HDS enforces strict adherence to FHIR® rules. Once validated, data is securely stored in Azure’s FHIR® datastore, which can be queried.