HealthShare Health Connect Cloud Reference Information

In the Deployment Details section of the Overview page for your deployment, you can view the details of your deployment, including:

• Deployment size

• Creation date

• Deployment ID

• Cloud provider and region

• High Availability State

• Underlying InterSystems IRIS platform

The Interoperability Details section of the Overview page displays the File System Interoperability directory name to be used by Interoperability Productions Opens in a new tab that need to store files on the file system. If you have a High Availability configuration, files in this directory are copied automatically from the primary mirror member to the backup mirror member.

This section also displays the CIDR Block for the private network used for this deployment, as well as the Virtual IP Address of the deployment. This CIDR block defines the range of IP addresses used for the internal Health Connect Cloud components. The Virtual IP address is a static address within the CIDR block that you use to communicate with this Health Connect Cloud deployment. If you have a High Availability configuration, this Virtual IP address will continue to work no matter which mirror member is the primary member.

The External IP is displayed only if you have enabled external connections on the Firewall page.

If you have a High Availability configuration, the High Availability section of the Overview page displays whether or not your mirror is healthy, shows you the current state of each mirror member, and identifies which mirror member is the primary member and which mirror member is the backup member.

The Timezone section of the Overview page displays the current time zone for your deployment and lets you change it according to your preference. The default time zone is UTC.

To change the time zone for this deployment:

1. In the Timezone section of the Overview page, click Change.

2. Under Select New Time Zone, select a location that represents your desired time zone.

3. Click Change Timezone.

4. When asked to confirm the change, type change, and then click Change Time Zone.

   You are redirected to the list of deployments while the Health Connect Cloud deployment is updated. This may take a few moments.

5. When the status for your deployment changes from UPDATING back to COMPLETE, click the change is complete.

To create a user :

1. On the Connect Users page for your deployment, click Create User.

2. On the Create User dialog, type a Username and Email, and click Create.

   The user now appears in the list of Connect Users. However the user must create a permanent password to be able to log in to the Health Connect Cloud Management Portal, and the user must be granted access to at least one production.

3. Assign at least one production to the user. See Assign Production and Web App Access to a User.

4. Have the user check their email account for a temporary password.

5. Have the user click the Password Management Page link and log in with the username and temporary password.

6. When prompted to change their password, the user should type a permanent password, confirm the password, and click Send.

   The user is redirected to the Health Connect Cloud Management Portal.

7. Make sure the user can log in to the Health Connect Cloud Management Portal with their username and permanent password.

After creating a user, you need to specify which interoperability productions and web applications the user is allowed to access.

To grant interoperability production and web application access to a user:

1. In Connect Users list, in the row for that user, click Edit Productions in the Actions column.

2. On the Access to Productions dialog:

   • Select the Namespaces (productions) to which the user should have access.

   • Select the Web Apps to which the user should have access.

3. Click Apply.

   This list of productions and web apps is now displayed in the Productions column in the row for the user.

If you later add a production or web app and want to allow users to access it, return to the Connect Users page and use this same procedure to assign access to the new production or web app.

If you ever need to reset a user’s password:

1. Click the Password Management Page link.

2. If you see a dialog asking you to sign in with a specific username, click Sign In As a Different User? Otherwise, skip this step.

3. When asked to sign in with a username and password, click Forgot Your Password?

4. Type the user’s username, and click Reset My Password.

   A reset code will be sent to the user’s email address.

5. Have the user enter the reset code and select a new password. Then click Change Password.

To remove a user’s Health Connect Cloud Management Portal access, in Connect Users list, click the Delete User icon in the Actions column for that user.

Connect Users can also log in to the Message Bank Management Portal, if you have deployed one. The Message Bank Management Portal can also be launched from the System Management page.

Assign a Connect User permission to use a Message Bank the same way you would assign access to a production.

When you create an interoperability production, the Cloud Services Portal also creates a namespaceOpens in a new tab for the production, which includes a database for the code and data for that production. After creating a production, you can configure and manageOpens in a new tab it using the Management Portal.

For more information on developing productions, see the Health Connect documentation setOpens in a new tab.

If your Health Connect Cloud deployment was created with the High Availability configuration, the databases for your interoperability productions are automatically mirrored to the backup server.

If your Health Connect Cloud deployment was created with a Message Bank, all of the messages processed by each production, as well as any event log entries, are stored in the Default Message Bank. For details on creating additional Message Banks, see Create a Message Bank.

To create a production:

1. On the Productions page, under Create Interoperability Production, type the desired name of your production.

2. Click Create Production.

After you create a production, it shows up in the Productions list at the top of the page with a Production State of Stopped. When the creation process is finished, the Production State changes to Running. The Production Started column shows the time the production was started, in GMT. You may need to click Refresh to update the status.

To manage the production in the Management Portal, click Manage in the row for that production. You will need to log in as a user that you or a team member has created (and granted production access to) on the Connect Users page.

To delete an interoperability production:

1. On the Productions page, click the Delete Production icon in the Actions column for that production.

2. In the Delete Production dialog box, type Permanently Delete, and click Delete.

The production is removed from the Productions list at the top of the page.

To create a new SSL/TLS Configuration:

1. On the SSL/TLS Configurations page, under Create SSL/TLS Configuration, type the desired name of your SSL/TLS Configuration.

   Only alphanumeric characters are allowed. No spaces or special characters.

2. Type an optional Description.

3. If desired, check Enabled to enable the configuration after creating it.

   You can enable or disable it later by editing the configuration.

4. Choose a Type for the configuration.

   Client means that this configuration is used when Health Connect Cloud initiates a connection to another system, for example, in an outbound TCP adapter in a production’s business operation.

   Server means that this configuration used when another systems initiates a connection to Health Connect Cloud, for example, in an inbound TCP adapter in a production’s business service.

5. Choose the desired Certificate Verification for this configuration.

   If this is a Client configuration:

   • None means that the server does not need to provide a certificate and the client performs no verification.

   • Required means that the server must provide a certificate and the client verifies the certificate with the Certificate Authority that issued the certificate.

   If this is a Server configuration:

   • None means that the client neither requires or requests a certificate.

   • Request means that the client may or may not provide a certificate and the server verifies the certificate only if provided.

   • Required means that the client must provide a certificate and the server verifies the certificate with the Certificate Authority that issued the certificate.

6. Upload the file containing the trusted Certificate Authority certificate(s).

   This file contains the X.509 certificate(s) in PEM format of the Certificate Authority (CA) or Certificate Authorities that this configuration trusts. The configuration uses the certificates of the trusted CA(s) to verify peer certificates. Typically, a production system uses certificates from commercial CAs with publicly available certificates.

   This field does not appear if certificate verification is not needed for this configuration.

7. Upload the file containing configuration certificate.

   This is the configuration’s own X.509 certificate(s) in PEM format, if required.

8. Upload the file containing associated private key.

   This is the configuration’s private key file.

   If a configuration certificate is provided, a private key is required.

9. Select the Private Key Type.

   This is the algorithm used to generate the private key, where valid options are DSA (Digital Signature Algorithm) and RSA (Rivest, Shamir, and Adleman).

10. Type the Private Key Password.

    If the private key is password-protected and you do not enter a value here, Health Connect Cloud cannot confirm that the private key and the certificate’s public key match each other.

11. Select the Minimum Protocol Version supported by this configuration.

    This is the earliest version of the TLS protocol that this configuration supports.

12. Select the Maximum Protocol Version supported by this configuration.

    This is the latest version of the TLS protocol that this configuration supports.

13. If desired, edit the Enabled Cipherlist.

    The default set of cipher suites is:

    • ALL — Includes all cipher suites except the eNULL ciphers

    • !aNULL — Excludes ciphers that do not offer authentication

    • !eNULL — Excludes ciphers that do not offer encryption

    • !EXP — Excludes export-approved algorithms (both 40- and 56-bit)

    • !SSLv2 — Excludes SSL v2.0 cipher suites

14. For Server configurations only, select the size of Diffie-Hellman key (if using).

15. For Server configurations only, optionally enable and configure OSCP Stapling.

    OCSP (Online Certificate Status Protocol) is an internet protocol that checks the validity status of a certificate in real-time.

16. Click Create Configuration.

For more information on the fields on this page, see About ConfigurationsOpens in a new tab.

After you create a configuration, it shows up in the SSL/TLS Configurations list at the top of the page.

To edit an SSL/TLS Configuration:

1. On the SSL/TLS Configurations page, click the Edit Configuration icon in the Actions column for that SSL/TLS Configuration.

2. In the dialog box, edit any of the fields, and click Submit.

See Create an SSL/TLS Configuration for information on each field.

To delete an SSL/TLS Configuration:

1. On the SSL/TLS Configurations page, click the Delete Configuration icon in the Actions column for that SSL/TLS Configuration.

2. In the Delete Configuration dialog box, type Permanently Delete, and click Delete.

The configuration is removed from the SSL/TLS Configurations list at the top of the page.

To test an SSL/TLS Configuration (client configurations only):

1. On the SSL/TLS Configurations page, click the Test Connection icon in the Actions column for that SSL/TLS Configuration.

2. In the SSL/TLS Connection Test dialog box, type a Hostname (not its URL) and a Port.

3. Click Test Connection.

   The dialog box is updated with information saying whether the connection test succeeded or failed. If the test succeeded, additional details of the connection are provided, such as the protocol and ciphersuite that were used.

If you want to receive a notification when an SSL certificate is about to expire, you can configure a business service in a production to do this for you. See Configure a Production to Send SSL Certificate Expiration Alerts for more information.

To create a new SQL Gateway configuration:

1. On the SQL Gateways page, under Create SQL Gateway Configuration, type the Configuration Name of your SQL Gateway configuration.

   Only alphanumeric characters are allowed. No spaces or special characters.

2. Choose a Driver to use for the connection.

3. In the Server box, type the URL of the server to use for this connection.

4. In the Port box, type the port number to connect to on the server.

5. In the Database box, type the name of the external database.

6. In the User box, type the username to use to connect to the external database.

7. In the Password box, type the password to use to connect to the external database.

8. Click Create Configuration.

After you create a configuration, it shows up in the SQL Gateway Configurations list at the top of the page.

The SQL Gateway configuration to connect to a Snowflake data warehouse is a little bit different.

To connect to a Snowflake Data Warehouse:

1. On the SQL Gateways page, under Create SQL Gateway Configuration, type the Configuration Name of your SQL Gateway configuration.

   Only alphanumeric characters are allowed. No spaces or special characters.

2. In the Driver box, select Snowflake.

3. In the URL box, type the URL of the server to use for this connection.

   The URL takes the form:

   jdbc:snowflake://<account>.snowflakecomputing.com/?warehouse=<warehouse_name>&database=<db_name>
   

   

4. In the User box, type the username to use to connect to Snowflake.

5. In the Password box, type the password to use to connect to Snowflake.

6. Click Create Configuration.

After you create a configuration, it shows up in the SQL Gateway Configurations list at the top of the page.

For more information on using a Snowflake SQL gateway, see Configure a Production to Use Snowflake.

To test a SQL Gateway configuration:

On the SQL Gateways page, click the Test Configuration icon in the Actions column for that configuration.

You should see the message “Successfully connected to remote server.”

If you see the message “There was an issue testing configuration. Please double check configuration parameters.” then edit the SQL Gateway configuration and try again.

To edit a SQL Gateway configuration:

1. On the SQL Gateways page, click the Edit Configuration icon in the Actions column for that configuration.

2. In the dialog box, edit any of the fields, and click Save.

See Create a SQL Gateway Configuration for information on each field.

To delete a SQL Gateway configuration:

1. On the SQL Gateways page, click the Delete Configuration icon in the Actions column for that configuration.

2. In the Delete Configuration dialog box, type Permanently Delete, and click Delete.

The configuration is removed from the SQL Gateway Configurations list at the top of the page.

Before creating a private firewall rule, you must create a InterSystems Network ConnectOpens in a new tab deployment to create a VPN hub and then connect a VPN gateway device (or Direct Connection) and your Health Connect Cloud deployment.

To add a private firewall rule to Health Connect Cloud:

1. On the Firewall page, in the Private Rules section, click Create Rule.

2. In the Add Firewall Rule dialog box:

   1. In the Type box, select Custom.

   2. In the Protocol box, select either TCP or UDP, depending the type of traffic to allow using this rule.

   3. In the Port Range box, type the port number(s) or range(s) to use for this rule.

      Use port 443 to allow a user to log into the Health Connect Cloud Management Portal or a port in the range 1025 through 65535 for other connections. Use a hyphen to specify a contiguous range of port numbers (for example, 1040-1050). Use commas to separate multiple non-contiguous port numbers (for example, 1040, 1050, 1060). When using commas, do not specify more than 50 port numbers at a time.

   4. In the CIDR Block box, type the CIDR block that defines the source IP addresses allowed using this rule.

      Public CIDR blocks are not permitted in private firewall rules.

   5. In the Description box, type the purpose of this rule.

   6. Click Add.

To delete a private firewall rule, click the Delete Configuration icon in the Actions column for that rule.

Before creating the first external firewall rule, you must enable external connections:

1. On the Firewall page, in the External Rules section, slide the Enable External Connections slider to the right.

   You are redirected to the list of deployments while the Health Connect Cloud deployment is updated. This may take a few minutes.

2. When the status for your deployment changes from UPDATING back to COMPLETE, click the card and navigate back to the Firewall page.

To add an external firewall rule to Health Connect Cloud:

1. On the Firewall page, in the External Rules section, click Create Rule.

2. In the Add Firewall Rule dialog box:

   1. In the Type box, select Custom.

   2. In the Protocol box, select either TCP or UDP, depending the type of traffic to allow using this rule.

   3. In the Port Range box, type the port number(s) or range(s) to use for this rule.

      Use port 443 to allow a user to log into the Health Connect Cloud Management Portal or a port in the range 1025 through 65535 for other connections. Use a hyphen to specify a contiguous range of port numbers (for example, 1040-1050). Use commas to separate multiple non-contiguous port numbers (for example, 1040, 1050, 1060). When using commas, do not specify more than 50 port numbers at a time.

   4. In the CIDR Block box, type the CIDR block that defines the source IP addresses allowed using this rule.

      Private CIDR blocks are not permitted in external firewall rules.

   5. In the Description box, type the purpose of this rule.

   6. Click Add.

To delete an external firewall rule, click the Delete Configuration icon in the Actions column for that rule.

If you are no longer using any external firewall rules, slide the Enable External Connections slider to the left to disable all external connections to the deployment. Any existing external rules are hidden on the Firewall page, but they are not deleted and will be displayed again if you re-enable external connections. Note that the external IP address of the deployment will change when external connections are re-enabled.

To enable DNS forwarding:

1. On the DNS Forwarding page, move the slider to the right to Enable the feature.

2. Wait 5 minutes to make sure that the feature is fully enabled in the background. You will not see any visual indication that this is complete.

   Important:

   If you don’t wait until the feature is fully enabled, any mappings you attempt to create will fail.

To add a mapping:

1. On the DNS Forwarding page, click New.

2. On the Add Mapping dialog, in the DNS Servers box, type the IP addresses of one or more DNS servers.

   To add multiple DNS servers, press the Enter key after each IP address.

3. In the Domains box, type one or more domain names.

   To add multiple domains, press the Enter key after each domain name.

4. On the Add Mapping dialog, click Save.

   Press the Enter key after entering the last domain name to enable the Save button.

5. On the DNS Forwarding page, click New to add additional mappings, if needed.

6. On the DNS Forwarding page, click Save Changes to save all of your new mappings.

   Note:

   If you navigate to another page without saving your new mappings, they will be lost.

7. After saving your changes, wait 5 minutes for the new mappings to be fully processed before making any other changes.

To delete a mapping:

1. On the DNS Forwarding page, in the row for the mapping you want to delete, click the Delete Configuration icon in the Actions column.

2. Delete any other mappings, if needed.

3. Click Save Changes to save all of your deletions.

   Note:

   If you navigate to another page without saving your deletions, they will be lost.

4. After saving your changes, wait 5 minutes for the deletions to be fully processed before making any other changes.

If your Health Connect Cloud deployment was created with the Message Bank option, all messages and other data processed by the connected productions are stored in the default Message Bank. This Message Bank has a namespaceOpens in a new tab of BANK.

To create a new Message Bank:

1. On the Message Banks page, under Create Message Bank, type the desired name of your Message Bank.

2. Click Create Message Bank.

After you create a production, it shows up in the Message Banks list at the top of the page with a Production State of Stopped. When the creation process is finished, the Production State changes to Running. The Production Started column shows the time the production was started, in GMT. You may need to click Refresh to update the status.

To manage the Message Bank in the Management Portal, click Manage in the row for that Message Bank. If you are not already logged in to the Management Portal, you will need to log in with a username and password that you or a team member has created (and assigned message bank access to) on the Connect Users page.

For more details on Message Banks, see Configuring the Enterprise Message BankOpens in a new tab.

To delete a message bank:

1. On the Message Banks page, click the Delete Message Bank icon in the Actions column for that Message Bank.

2. In the Delete Message Bank dialog box, type Permanently Delete, and click Delete.

The Message Bank is removed from the Message Banks list at the top of the page.

The Network Connectivity Test section of the Network page allows you to test connectivity from this deployment to a particular server and port. The server could be an external server or an on-premise server accessed over your company’s VPN.

To perform a connectivity test:

1. In the Network Connectivity Test section of the Network page, in the IP or Hostname box, type the IP address (such as 203.0.113.0) or hostname (such as example.com) of the server to which you want to connect.

2. In the Port box, type the port number to which you want to connect on that server.

   You can specify one of the following ports: 21, 22, 53, 443, 465, 587, or a port in the range 1024-65535.

3. Click Test Connection.

   You will see either a success or failure message.

The VPC Flow Logs section of the Network page allows you to monitor the traffic coming in and out of this deployment. This allows you to confirm that your network configuration is correct, debug network issues, monitor traffic patterns, or identify unauthorized access attempts.

To view flow log entries:

1. In the VPC Flow Logs section of the Network page, optionally filter the log by entering one or more of the following fields:

   • Actions — Choose ACCEPT to see only traffic that was permitted to flow from the source to the destination or REJECT to see only traffic that was blocked from reaching its intended destination.

   • Host IP — Type the IP address of either the source or destination.

   • Host Port — Type the port of either the source or destination.

2. Enter the Start Time and End Time of the period of time you want to examine.

   The default window is the most recent 10 minutes. The maximum window is 30 minutes in duration.

3. Click Find.

   Flow log entries matching the entered criteria are displayed.

4. Optionally, click Load More to load more log entries.

   This button only appears if more log entries remain to be loaded.

Before creating a web application, complete the following prerequisite steps.

1. On the Productions page, create a production and namespace to host the web application.

2. On the Firewall page, create firewall rules for ports 443, 9080, and 9443 to allow IP addresses in a given CIDR block to connect to the web application.

3. On the Connect User page, create a Connect User you can use to connect to the web application, and make sure the user has access to the production and namespace you created.

4. Create a dispatch class to define the routes of the web application API and associate each with a method in the class.

5. If you are using mTLS, make sure you have the required certificates.

From the System Management page, log in to the Health Connect Cloud Management Portal.

In the namespace you created to host the web application, create a dispatch class using Microsoft VS Code and GitLab. The dispatch class must extend %CSP.RESTOpens in a new tab.

The following sample class, Sample.RestApp, has three routes that all map to the class method Test().

Class Sample.RestApp Extends %CSP.REST
{

XData UrlMap [ XMLNamespace = "http://www.intersystems.com/urlmap" ]
{
<Routes>
<Route Url="/test" Method="GET" Call="Test" Cors="true"/>
<Route Url="/test/:name" Method="GET" Call="Test" Cors="true"/>
<Route Url="/test/:name/:name2" Method="GET" Call="Test" Cors="true"/>
</Routes>
}

ClassMethod Test(name = "World", name2 = "") As %Status
{
    write "Hello ", name_" "_name2, "!<br/>", !
    quit 1
}

}

Before setting up the optional mTLS configuration, make sure you have a Certificate Authority (CA) certificate containing the entire certificate chain and a client certificate signed by the CA.

If you need certificates for testing purposes you can create them with openssl using a procedure like the one below. This example was created on Linux.

First, create a private key (ca.key) for the root CA and a self-signed x.509 certificate (ca.crt) for the CA:

$ openssl genrsa -out ca.key 4096
$ openssl req -x509 -new -key ca.key -sha256 -days 3650 -out ca.crt -subj "/CN=MyTestRoot"

Then, create a private key (client.key) for the client, a certificate signing request (client.csr), and a client certificate (client.crt) that is signed by the root CA:

$ openssl genrsa -out client.key 2048
$ openssl req -new -key client.key -out client.csr -subj "/CN=MyTestClient"
$ openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out client.crt -days 365 -sha256
Certificate request self-signature ok
subject=CN = MyTestClient

Finally, verify the client certificate to make sure it is properly signed by the CA:

$ openssl verify -CAfile ca.crt client.crt
client.crt: OK

Upload the CA certificate to Health Connect Cloud on the mTLS Client CAs tab of the Web Apps page:

1. On the mTLS Client CAs tab of the Web Apps page, click Upload CA Cert.

2. In the Upload Client CA Cert for mTLS dialog, in the Hostname Prefix box, type a prefix to distinguish requests that will be handled for the web app with mTLS.

   The prefix will be added to the base URL shown on the Web Apps page in the Cloud Services Portal, for example,<hostname_prefix>.api.<deployment_id>.<server_name>.

3. In the Client Certificate Authority Contents textbox, copy and paste the contents of your ca.crt file.

4. Click Save.

   Your CA will appear in the list on the mTLS Client CAs tab of the Web Apps page.

After you create the web application, send the client certificate and key along with each request to the web application and Health Connect Cloud will authenticate it against the CA. See Test a Web Application with mTLS for more information.

After performing the prerequisite steps and creating a dispatch class, you are ready to create your web application, which includes a built-in web gateway to receive requests and direct them to your web app.

1. On the Web Apps page, enable the Web App feature, if it is not already enabled, by moving the Enable slider to the right.

   It will take a few seconds for the feature to be enabled.

2. On the Web Apps tab, click Create Web App.

3. On the Create Web App dialog:

   1. Type the Web App Name.

      This is the path representing the endpoint of your REST API, for example, /hcc/api.

   2. Check the Enabled box to enable the web application.

   3. Select the Namespace you created to host the web application.

   4. Type the name of the Dispatch Class you created, for example, Sample.RestApp.

   5. Under Security Settings, type the Rate Limit Count and the Rate Limit Time Window for your web application.

      For example, entering 1000 and 10 for these settings, respectively, means that you are limiting the number of API requests allowed through the web gateway to 1,000 in a 10-second window.

   6. Select an IP Restrict Mode:

      • None means allow requests from all IP addresses.

      • Allow means allow requests only from the IP addresses and CIDR blocks on the Allow List.

      • Deny means deny requests only from the IP addresses and CIDR blocks on the Deny List.

   7. If applicable, on the Allow List or Deny List, type single IP addresses or CIDR blocks, one per line.

      See the textbox for examples.

   8. If you are using mTLS, select the hostname prefix associated with a CA certificate you uploaded earlier.

   9. Click Save.

The web application now appears in the list at the top of the screen.

Use the icons in the Actions column of the list to edit the settings for a web application or to delete a web application.

Before using the web app, go to the Connect User page and give your Connect User access to the web application.

Using a web application can be broken down into two parts, represented by the following HTTP requests.

The first request is sent to the built-in Cognito instance to authenticate the user and obtain a bearer token:

POST / HTTP/2 
Host: cognito-idp.<aws_region>.amazonaws.com 
x-amz-target: AWSCognitoIdentityProviderService.InitiateAuth 
content-type: application/x-amz-json-1.1 

Once the bearer token is received, it can be used to make subsequent requests to the web app API:

GET /hcc/api/test/<arg1>/<arg2> HTTP/2 
Host: api.<deployment_id>.<server_name>:9443 
authorization: Bearer ******

The section below gives an example of how to test your web application from the command line. If you use an API client, such as Postman, you can use it for testing, as well.

Before testing a web application, go to the Connect User page and give your Connect User access to the web app.

Test a Web App from the Command Line

The following example demonstrates how to test a web application from the command line, using curl. It is an annotated version of the one shown on the Help tab of the Web Apps page in the Cloud Services Portal. On the Help tab, select your web app from the dropdown at the top of the page to enable easier copy and paste from the displayed content.

The example uses jq to make the handling of JSON objects easier. If you don’t have jq, you can download it from https://github.com/jqlangOpens in a new tab.

Perform this workflow from a POSIX-compliant shell. The following example was run in Git Bash for Windows, with POSIX mode turned on.

Make sure shell is POSIX compliant:

$ echo "$SHELLOPTS" | grep -o posix
posix

Set a variable to the cognitoClientId shown on the Help tab of the Web Apps page in the Cloud Services Portal.

$ connectClientId=<cognitoClientId>

Set variables to hold the username and password of your Connect User:

$ connectUsername="<username>"

$ connectPassword="<password>"

Set a variable to the web app name you chose when you created your web application:

$ webAppName="/hcc/api"

Use jq to format the body of the request to be sent to Cognito. The arguments in the jq command are passed into the body of the JSON string of the request. The line below is broken for readability.

$ BODY=$(jq -n --arg user "$connectUsername" --arg pwd "$connectPassword" --arg clientId "$connectClientId" \
'{"AuthParameters":{"USERNAME":$user,"PASSWORD":$pwd},"AuthFlow":"USER_PASSWORD_AUTH","ClientId":$clientId}')

Confirm that the JSON string of the body looks good:

$ printf "%s\n" "$BODY"
{
  "AuthParameters": {
    "USERNAME": "<connectUsername>",
    "PASSWORD": "<connectPassword>"
  },
  "AuthFlow": "USER_PASSWORD_AUTH",
  "ClientId": "<connectClientId>"
}

Send the authentication request to Cognito. The <aws_region> in the URL is shown in the example on the Web Apps page in the Cloud Services Portal. The line below is broken for readability.

$ RESPONSE=$(curl -X POST --data "$BODY" -H 'X-Amz-Target: AWSCognitoIdentityProviderService.InitiateAuth' \
-H 'Content-Type: application/x-amz-json-1.1' https://cognito-idp.<aws_region>.amazonaws.com/)

Verify that the response looks good. The following JSON string is formatted for readability.

$ echo $RESPONSE
{
  "AuthenticationResult": {
    "AccessToken": "******",
    "ExpiresIn": 3600,
    "IdToken": "******",
    "RefreshToken": "******",
    "TokenType": "Bearer"
  },
  "ChallengeParameters": {}
}

Use jq to extract the ID token from the response:

$ ID_TOKEN=$(echo $RESPONSE | jq -r ".AuthenticationResult.IdToken")

Send a request to the web application. This example uses the dispatch class above . The <base_url> is the webAppBaseURL shown on the Web Apps page in the Cloud Services Portal and takes the form https://api.<deployment_id>.<server_name>. The variable $webAppName is the one set near the start of this example.

$ curl -H "Authorization: Bearer $ID_TOKEN" -vv <base_url>:9443${webAppName}/test/world

The verbose option (-vv) allows you to see the entire handshake, which can be useful for debugging your configuration.

The response to the request, minus the handshake, is as follows:

Hello world!

Test a Web Application with mTLS

Sending a request to a web application that uses mTLS is the same as for regular web apps, with the following differences:

• The hostname prefix is added to the base URL, so requests are sent to <hostname_prefix>.api.<deployment_id>.<server_name>, instead of api.<deployment_id>.<server_name>, where <hostname_prefix> is the prefix you specified when you uploaded the CA certificate associated with this web application.

• The client certificate (--cert client.crt, in the example below) and client private key (--key client.key) are sent with the request.

• Since authentication goes both ways in mTLS, the client must have the server’s CA certificate in its certificate store. For testing purposes, this cert can be downloaded and then included with the request (--cacert <server_ca>, in the example below).

If the web application in the example above were created with mTLS, a request to the web app might look something like:

$ curl -H "Authorization: Bearer $ID_TOKEN" -vv --cert client.crt --key client.key  --cacert <server_ca> \
https://<hostname_prefix>.api.<deployment_id>.<server_name>:9443${webAppName}/test/world

Again, the verbose option (-vv) allows you to see the entire handshake, which can be useful for debugging your configuration.

Health Connect Cloud comes with a built-in web application that returns interoperability metrics on a deployment. This web app can also be used for testing purposes and is available from any namespace.

To use the interoperability web app, create a web app, giving it a web app name of your choosing (for example, /hcc/monitor) and using the built-in dispatch class ISCCD.RestMetrics.

The route for this web app is /metrics, so if you created the web app with the web app name /hcc/monitor, you would test the web app by sending requests the URL below. The <base_url> is the webAppBaseURL shown on the Web Apps page in the Cloud Services Portal and takes the form https://api.<deployment_id>.<server_name>.

<base_url>:9443/hcc/monitor/metrics

To filter metrics by namespace, use:

<base_url>:9443/hcc/monitor/metrics/<namespace>

The <namespace> is not case sensitive.

The Logs and Metrics tab of the Web Apps page lets you view metrics and access logs for a particular web app over a given time period. The Metrics section shows you the number of total requests received by the web app during that time period and gives a breakdown of the total by HTTP status code. The Logs section shows you a list of the requests received by the web app during the time period. For each request, the log shows the:

• timestamp (in UTC)

• IP Address of the client making the request

• HTTP status code (for example, 200 for success or 401 for unauthorized)

• method (for example, GET or PUT)

• URI, including any query parameters (for example, /hcc/api/test/hello/world)

An entry is only shown in the access log if the web app received the request. If a valid endpoint is used, but the web app does not accept the connection, no log entry is displayed (for example, if you configure the web app to use mTLS, and the mTLS connection does not succeed).

To request metrics and logs for a web app:

1. On the Web Apps page, click the Logs and Metrics tab.

2. In the Search section of the page:

   1. In the WebApp dropdown, select a web application.

   2. Specify a Start Time and End Time of the time period for which you want to view metrics and logs (in UTC).

   3. Optionally, filter the search by Status Code, Client IP, and/or URI Prefix.

   4. Click Search.

The search results appear in the Metrics and Web App Logs sections of the page.