InterSystems FHIR Server Reference Information
This section describes how to perform various activities that are part of the day-to-day operations of InterSystems FHIR Server, organized by page. Use the links in the Deployments section of the main menu in the Cloud Services Portal to navigate from page to page.
For a high-level overview of setting up InterSystems FHIR Server, see Introducing InterSystems FHIR Server.
Some of the functionality described in this section may not be available to all users, depending on their role on the development team. For more information, see Tenants PageOpens in a new tab.
Overview Page
The Overview page contains the following sections:
-
The Deployment Details section lets you view the basic details of your deployment.
-
The FHIR Details section lets you view a summary of your deployment’s FHIR endpoints.
-
The xDBC Details section appears only if the deployment was created with the SQL Builder option. It provides you with information you can use to connect to FHIR Server with a JDBC or ODBC client.
View Deployment Details
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 platform
If a deployment has a status where you cannot access the deployment’s Overview page (for example, CREATING, UPDATING, DELETING, or FAILED), its card on the Deployments page will display the Deployment ID. The Deployment ID uniquely identifies your deployment.
View FHIR Details
In the FHIR Details section of the Overview page for your deployment, you can find the URLs of your deployment’s API Key Endpoint and OAuth 2.0 Endpoint.
If you are using API keys to control access to FHIR Server, click the FHIR Request Samples with API Key button to obtain sample cURL commands you can use as templates for constructing API requests to send to FHIR Server using the command line, a REST client, or an application. You can generate an API Key to use with these samples in the API Keys section of the Credentials page.
If you are using OAuth 2.0 to control access to FHIR Server, click the FHIR Request Samples with OAuth2 button to obtain sample cURL commands you can use as templates for constructing API requests to send to FHIR Server using the command line, a REST client, or an application. If you are using the integrated authentication server, you can generate a token to use with these samples on the Applications tab of the OAuth 2.0 page, as described in Configure an Application Using the Integrated Authentication Server.
You can also generate sample cURL commands on the API Development page, as described in Explore the Developer Portal.
View xDBC Details
In the xDBC Details section of the Overview page for your deployment, you can view information on how to connect to your deployment using JDBC or ODBC. This information is useful if you are using the SQL Builder option to create a SQL projection of your FHIR data.
Before you can connect a JDBC or ODBC client to your deployment, you must create a firewall rule to allow the connection. See Firewall Page.
Metrics Page
In contrast with the access logs, which show information regarding individual FHIR requests, the Metrics page for a deployment shows summary statics for a given route, including the overall count of requests made (either using an API Key or OAuth 2.0), the latency (in milliseconds), and the number of 4xx and 5xx status errors.
OAuth 2.0 Page
The OAuth 2.0 page allows you to manage the authentication servers and applications in your deployment.
The Authentication Servers tab of the OAuth 2.0 page lists all of the configured authentication servers for your deployment. These authentication servers can be either integrated (if you are not using an existing IdP to manage users) or external (if you are using an existing IdP to manage users). This tab also allows you to configure new authentication servers or delete existing authentication server configurations from your deployment.
The Applications tab of the OAuth 2.0 page lists all of the configured applications for your deployment and allows you to view their details. If you have more than one authentication server configured, you can filter the tab so that it displays only applications associated with a particular authentication server. This tab also allows you to configure new applications or delete existing application configurations.
For background information on how FHIR Server uses OAuth 2.0, see OAuth 2.0/OpenID Connect. For basic information on deciding how to set up your OAuth 2.0 strategy, see Set Up OAuth 2.0.
Configure an Authentication Server
To configure an authentication server:
-
In your deployment, click OAuth 2.0 on the main menu.
-
On the OAuth 2.0 page, click the Authentication Servers tab.
-
In the Configured Authentication Servers section, click CREATE AUTHENTICATION SERVER.
-
In the Create Authentication Server section, type a Name and optional Description for your authentication server.
-
Select an Authentication Server Type.
If you do not have (or do not want to use) an existing IdP, select the Integrated authentication server. Otherwise, select the platform that matches your existing IdP.
-
If you are using an external authentication server, type the Issuer Discovery URL for your IdP.
-
Click CREATE.
The authentication server now appears in the Configured Authentication Servers section.
If you want to delete your authentication server at any point, you can do so by clicking the trash icon next to your authentication server name.
You cannot delete an authentication server that has one or more applications associated with it. Delete any associated applications before deleting the authentication server.
You can configure a maximum of one integrated authentication server.
Configure an Application Using the Integrated Authentication Server
To configure an application when using the integrated authentication server:
-
On the OAuth 2.0 page for your deployment, click the Applications tab.
-
In the Configured Applications section, click CREATE APPLICATION.
-
In the Create Application section, under Authentication Server, select the integrated authentication server from the drop-down list.
This list contains all authentication servers you have configured, both integrated and external.
-
Type a Name for your application.
-
Select the Authentication Flow that is appropriate for your FHIR-enabled application.
-
Select the Grant Type that is appropriate for your FHIR-enabled application.
-
If you have already developed a FHIR-enabled application and want to connect it to FHIR Server, type its Redirect URL and Logout URL. Otherwise, use the default callback values.
-
Check the Generate Secret box, if you need to generate a Client Secret.
-
In the App Scopes Builder section:
-
Select a Launch Context.
This adds scopes to the Selected Scopes box, depending on the launch context you select.
-
Select Backend Service for testing purposes or to connect an application to FHIR Server without context.
-
Select Patient Standalone Launch to connect an application to FHIR Server with a patient context. This limits the scope to that specific patient.
-
-
Under Scope Context, Patient or Clinical is selected for you, depending on the Launch Context you selected.
-
Under Resources, select Enable All Resources on this Scope Context, or clear this option and select a single resource from the drop-down list.
-
Select the level of Permissions you want to allow for this resource.
-
Click ADD SCOPE.
This adds the specified scope to the Selected Scopes box.
-
If you are adding scopes for individual resources, you can add additional scopes in the same manner.
-
-
When you are done defining scopes, click CREATE.
The application now appears in the Configured Applications section. If you have multiple authentication servers, you can filter your applications by using the Authentication Server drop-down list.
Click an application to:
-
View the details of the application, including the scopes defined for the application.
-
Obtain the Client ID, Client Secret (if you generated one), and OpenID endpoints you may need to further configure your FHIR-enabled application.
If you want to delete your application at any point, you can do so by clicking the application and then clicking DELETE at the bottom of the page.
Configure an Application Using an External Authentication Server
To configure an application when using an external authentication server:
-
On the OAuth 2.0 page for your deployment, click the Applications tab.
-
In the Configured Applications section, click CREATE APPLICATION.
-
In the Create Application section, under Authentication Server, select an external authentication server from the drop-down list.
This list contains all authentication servers you have configured, both integrated and external.
-
Type a Name for your application.
-
Select the Authentication Flow that is appropriate for your FHIR-enabled application.
-
Select the Grant Type that is appropriate for your FHIR-enabled application.
-
Enter the Client ID and Client Secret for your application, as defined by your IdP.
If no Client Secret is necessary, leave the field blank or type NONE.
-
Click Create.
The application now appears in the Configured Applications section. If you have multiple authentication servers, you can filter your applications by using the Authentication Server drop-down list.
Click an application to view the details of the application, including the Client ID and Client Secret (if any) Click OPENID ENDPOINTS to view any OpenID endpoints you may need to further configure your FHIR-enabled application.
If you want to delete your application at any point, you can do so by clicking the application and then clicking DELETE at the bottom of the page.
If you are using an external authentication server, scopes need to set up for your application in the administrative console of your IdP.
Credentials Page
The Credentials page can be used to manage API keys, if you are using them as a mechanism to control access to the FHIR API. This page can also be used to manage users, if you are using the integrated authentication server for OAuth 2.0 authentication and authorization.
API Keys
To create an API key:
-
In your deployment, click Credentials on the main menu.
-
Under API Keys, click Create API Key.
-
On the Add API Key dialog, type the Key Name, and click Add.
The key name could be the name of a user or an application.
-
After the API Key is generated, copy and paste it to a safe location. You will not be able to retrieve it after closing the dialog.
-
Click Close.
The new API key now appears in the list of API keys on the page. It may take up to a minute for the key to become active.
If you want to delete an API key at any point, click the Delete icon in the Action column in the row for the API key.
Authentication Server Users
To create a user for the integrated authentication server :
-
In your deployment, click Credentials on the main menu.
-
Under Authentication Server Users, click Create User.
-
On the Create User dialog, type the Username and Password, and click Create.
The user now appears in the list of authentication server users.
If you want to remove a user’s access at any point, click Disable in the row for that user.
If you are using an external IdP to manage users for OAuth 2.0, add or delete users using the administrative console of your IdP
API Development Page
The API Development page, sometimes referred to as the Developer Portal, presents a Swagger specification for FHIR Server API. This provides you with documentation on the available FHIR resource types and the methods that can be used to access or manipulate resources of each type.
This page can also be used as an interactive development tool so that you can easily send a test API request to FHIR Server by using a handy form-based interface. You can then view the cURL command equivalent to your API request, including the headers and the body of the HTTP request sent to the API. You can also use the cURL command as a template in the code of your application. Using the Development Portal, you can also inspect the response code, headers, and body of the response (in JSON format) to learn about the data that is returned for that request.
For a quick hands-on tutorial of the API Development Page, see the Guided Tour, or continue reading the sections below.
You can also use the API to import resources by posting it to the root URL of your FHIR endpoint. For more in formation see Import Bundles Using the API.
Resources
The API Development page is organized by resource type, such as Patient, Claim, Encounter, or Medication.
For example, a Patient resource is a block of data that contains demographic or administrative information about a patient, either human or animal, such as name, address, birth date, or gender. A Patient also has a Resource Identifier, or id, that uniquely identifies the patient within the FHIR database. This id should not be confused with an identifier assigned by a business identity, though a Patient resource can contain these, as well.
A Patient resource can also contain metadata, which is data about the resource itself, not the patient. If you search for a patient in the FHIR database using the patient’s id, you might notice that the resource that is returned contains a metadata element that includes the version number of the resource or the last date and time the resource was updated. If you were to update the address of a patient and again search for that patient, you would see that the version number is incremented and the last updated date/time matches the time you made the change.
A collection of resources is called a bundle. If you do a search for all the patients in the FHIR database, these are returned as a bundle. If you request the history for a patient, you receive a bundle containing all the versions of that patient’s resource. If you want to add a number of patients to the FHIR database, you can upload a bundle of patients on the Data Management page or send the bundle using an API request. A bundle can also contain resources of many different types, such as a patient and the patient’s immunization resources.
Use the Select Resource drop-down list on API Development page to view the specification for a particular resource type or to test its available methods.
Authorization
You can view the documentation for any resource type on the API Development page without needing authorization, including sample data that might be returned if you used one of the available methods for that resource type. However, you need to have an API key to actually send an API request and access the data in the FHIR database.
To authorize your API requests:
-
Near the top of the API Development page, click Authorize.
-
On the Available Authorizations dialog box, in the Value field, paste a valid API key.
If you do not have an API key, a user with the admin role can create one on the Credentials page.
-
Click Authorize.
-
Click Close.
When you are done using the API Development page, click the Authorize button again, and then click Logout.
Methods
The top section of the API Development page lists the actions that can be performed for a given resource type. These actions are composed of a method (or verb) and an endpoint.
Common methods you will see in FHIR Server API include: POST (create), GET (read), PUT (update), or DELETE (delete).
The behavior of these methods depends on the endpoint listed next to the method. Some of the endpoints contain path parameters, which are indicated by curly brackets.
The table below summarizes the methods that are available for the Patient resource type, and a more detailed discussion follows the table. The methods for the other resource types are similar.
Method | Endpoint | Purpose | Notes |
---|---|---|---|
POST | /Patient | Adds a new patient to the database | Request body contains contents of Patient resource. |
GET | /Patient | Searches for patients | Optionally, use parameters to narrow search. Returns bundle of Patient resources in response body. |
GET | /Patient/{id} | Returns Patient resource of patient with resource identifier {id} | Returns most recent version of resource from the history. |
PUT | /Patient/{id} | Stores a new version of Patient resource for patient with resource identifier {id} | Stores new version of resource in the history, incrementing the version id. |
DELETE | /Patient/{id} | Deletes patient with resource identifier {id} from the database | History is also deleted and cannot be retrieved. |
GET | /Patient/{id}/_history | Returns version history of patient with resource identifier {id} | Returns bundle containing all versions of Patient resource for the patient. |
GET | /Patient/{id}/_history/{vid} | Returns version with version id {vid} from history of patient with resource identifier {id} | Returns an error if either patient or version not found. |
As mentioned earlier, the method and endpoint taken together define the behavior that results from an API request. For example, GET /Patient can retrieve all of the patients in the FHIR database, while GET /Patient/{id} returns only the patient with the specified id. The endpoint is appended to the server to form the request URL, for example, https://fhir.<deploymentid>.workload-prod-fhiraas.isccloud.io/Patient
Expand a method in the Development Portal to see the parameters that can be sent with the API request, as well as the data that can be sent in the body of the request.
Parameters are used to modify the API request, for example, to narrow the focus of the request. If you look at the available parameters for GET /Patient, you will see that you can filter the returned results by gender, birth date, family name, and many other fields. Parameters are appended to the request URL in the query string.
If you have authorized yourself to use the Development Portal, you will see a Try It Out button to the right of the Parameters heading. You can click this button to test a method. To search for all female patients in the database, expand GET /Patient, enter female in the Gender field, and click Execute.
In the Responses section, you can see the cURL command that is equivalent to the API request you just made:
curl -X GET "https://fhir.<deploymentid>.workload-prod-fhiraas.isccloud.io/Patient?gender=female"
-H "accept: application/fhir+json" -H "x-api-key: nnp4R6vkob7cvDmLfumE33gX7z4zlTgD29YIpybx"
Notice that the parameter you specified is appended to the request URL: https://fhir.<deploymentid>.workload-prod-fhiraas.isccloud.io/Patient?gender=female
Provided that no problems occur with the request, you should see that the server response includes the HTTP status code 200, meaning that the request was successful. In the response body, you will see a bundle of patient resources, one for each of the patients in the database who is female.
Conversely, when you send a request that stores data for a resource in the database, this data is usually contained in the body of the request. To add a new patient resource to the database, you send a POST /Patient request. If you expand this section in the Developer Portal, you can see that this request does not take any parameters, but it does require a request body, which contains the data to be stored for this resource. Select an example from the drop-down list to see the request body for a sample patient.
If you select a sample patient resource and use the Try It Out feature to send the post request, you should see the HTTP status code 201, meaning that the resource was created. This request returns no body, but it does return some headers. In particular, notice that the Location header contains a value that looks something like https://fhir.<deploymentid>.workload-prod-fhiraas.isccloud.io/Patient/8111/_history/1. This tells you that the patient was assigned an id of 8111 and that you stored version 1 of the resource in the history.
Now, you can retrieve this patient by executing GET /Patient/{id}, where id = 8111. If you make a PUT /Patient/8111 request and send a body containing a new version of the patient resource, it is stored as version 2 in the history.
Schemas
The Schemas section of the Developer Portal describes the data elements that can be contained in a resource of a given type. For example, a Patient resource can contain the birthDate and maritalStatus elements. Some elements, such as Address, can contain themselves contain elements. A patient’s Address can contain City and State, for example. The data type of each element is also given, such as string or boolean.
Access Logs Page
The Access Logs page provides valuable information on who is using your service and what FHIR requests they are making. For each request, the access log shows the fields listed below. For summary information, see the Metrics page.
The time the request was made, in UTC.
The endpoint called in this request. This can be either the FHIR Endpoint or the FHIR Oauth2 Endpoint, as listed on the Overview page for your deployment.
The source IP address from where the request was made.
The HTTP method used for the request, for example, POST (create), GET (read), PUT (update), or DELETE (delete). A given request is sometimes preceded by an OPTIONS request, which asks the server if it is acceptable to send the request.
The path of the request. This generally corresponds to the resource requested, for example, /Patient or /Account. A request sent using OAuth 2.0 will start with /oauth2, as in /oauth2/Patient or /outh2/Account.
The HTTP status code of the request. A successful request results in a status in the range 200-299. For example, a successful GET request might return a status of 200 (OK), while a successful POST request might return a status of 201 (Created). A status in the range 400-499 indicates a client error. For example, a status of 403 (Forbidden) generally indicates that the client is not authorized to make the request. A status in the range 500-599 indicates a server error. For example, if the request is sent to an unknown request path, it might return a status of 502 (Bad Gateway).
The column in the access log is actually composed to two statuses, the Status (shown in bold) and Integration Status (shown in normal text). These need to be considered together to form a complete picture. For example, an unauthenticated request might return a Status of 403, but show no Integration Status because the request was blocked from reaching the service. A request that is authenticated but does not have the proper scope might return a Status of 403, but an Integration Status of 200, meaning that the request reached the service, but the request could not be fulfilled due to the improper scope. A successful POST request might return a Status of 201 and an Integration Status of 200.
The API key used for the request, if applicable.
It can take a few minutes for a request to appear in the access log.
To sort the access log by any field, click the column header for that field.
To download the access log in JSON format, click Download Logs. The JSON file contains some additional information about each request, such as the User Agent (information on the browser or other client used to make the request).
The listing on the Access Logs page and the contents of JSON log file are currently limited to a maximum number of 5,000 requests, and the requests must have been sent in the past 8 hours.
Data Management Page
The Dashboard tab of the Data Management page lets you view the count of resources in the FHIR database.
The number of total resources and the number of resources of the main resource types are viewable in the top table. A more detailed breakdown of resources by type is given in the Extended Resource Counts table.
If you are in the process of importing a large number of bundles, you can watch the count of resources on this tab increase as they are imported. You may need to click Refresh to update the display.
Importing Bundles Using the API
You can use the FHIR Server API to import bundles of type transaction. To do this, send a POST / request to the root URL of your FHIR Server endpoint, for example, https://fhir.<deploymentid>.workload-prod-fhiraas.isccloud.io/, with the bundle in the body of the request. A transaction is treated as a single unit. For example, if transaction bundle creates a patient resource and an observation resource and the creation of one of the resource fails, the entire transaction is rolled back.
After you import bundles using the API, the count of resources in the FHIR Resources Count section of the Dashboard tab is updated to reflect the new count.
When you post a bundle to the root URL, it is processed as a series of create or update requests. When you post a bundle to the /Bundle endpoint, it is stored as is, without processing.
Resources Page
The Resources page allows you to monitor the amount of storage your deployment is using and expand the storage allocation if you need more space.
Monitor or Expand Storage Allocation
The Storage tab of the Resources page lets you monitor or expand the amount of storage your deployment is using.
The Storage Allocation section of the page shows you the amount of storage currently used by your deployment, the amount of storage available, and the total amount of storage allocated. If you are actively ingesting a lot of new data, you can click Refresh to update the display.
While you can use this display to monitor your storage visually, the tenant owner also receives an email when the deployment reaches 85% of the allocated capacity.
The Expand Storage section of the page allows you to request more storage when you need it, in increments of 10GB.
To expand your storage size:
-
Move the slider to the desired storage allocation after expansion.
-
Click Expand.
It can take a few moments for the expansion to complete. Do not navigate away from the page until the process is complete. The other Cloud Services Portal functions are not available while the expansion is in progress.
Due to AWS constraints, you can only expand your storage allocation once every six hours. After requesting an expansion, the Expand button is disabled until the end of this six-hour time period.
Expanding the storage allocation of your deployment will result in an additional cost on your subscription. You cannot reduce your storage allocation, so do not expand your allocation until you are sure you need more storage.
Packages Page
A FHIR Server deployment comes with the latest version of the core FHIR definitions, which includes the base set of FHIR resources, frameworks, and APIs. On the Packages page for your deployment, you will see a list of additional packages that can be used to extend or constrain the core package. For example, many jurisdictions around the world have their own FHIR profiles that you may need to use. For more information on profiles, see Profiling FHIROpens in a new tab.
On the Packages page is a list of packages that either have been deployed or are available for you to deploy to your FHIR endpoint. The Package Status column tells you if each package is DEPLOYED or AVAILABLE.
If you need to deploy a package that is AVAILABLE, see Getting HelpOpens in a new tab.
Firewall Page
The Firewall page allows you to manage the FHIR Server firewall, allowing traffic from JDBC or ODBC clients to reach your FHIR Server deployment. This page is enabled only if you have deployed FHIR Server with the SQL Builder option. InterSystems FHIR SQL Builder allows you to create a SQL projection of your FHIR data and enables you to query the data in your FHIR Server as if it were an SQL database.
The Firewall page lists all of the firewall rules you have created. Each rule includes the protocol used to connect to the deployment (must be TCP), the port to connect to (must be 1972), and the CIDR block that defines the IP addresses that are allowed to connect.
Managing External Firewall Rules
At this time, only the creation of external firewall rules has been implemented for FHIR Server.
Before creating the first external firewall rule, you must enable external connections:
-
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 FHIR Server deployment is updated. This may take a few minutes.
-
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 FHIR Server:
-
On the Firewall page, in the External Rules section, click Create Rule.
-
In the Add Firewall Rule dialog box:
-
In the Type box, select Custom.
-
In the Protocol box, select TCP.
-
In the Port Range box, type 1972.
-
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.
-
In the Description box, type the purpose of this rule.
-
Click Add.
-
You can have a maximum of 240 external firewall rules.
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 FHIR Server. 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 FHIR Server deployment may change when external connections are re-enabled.
SQL Builder
This page is enabled only if you have deployed FHIR Server with the SQL Builder option. The SQL Builder option lets use InterSystems FHIR SQL Builder to create custom SQL schemas from your FHIR data and query the data as you would query an SQL database.
Creating a SQL projection of your FHIR data includes three basic steps:
-
Analyze your FHIR repository.
-
Create a transformation specification.
-
Create a SQL projection using your transformation specification.
Analyze Your FHIR Repository
The first step in using FHIR SQL Builder is analyzing the contents of your FHIR repository to determine what FHIR resources and elements are represented in your data. If your FHIR database is large, you can choose to analyze just a portion of the data, enough to get a representative sample.
To create an analysis of your FHIR data:
-
On the main menu for your deployment, click SQL Builder.
-
On the InterSystems FHIR SQL Builder page, in the Analyses section, click New.
-
In the New FHIR Analysis dialog box, for the FHIR Repository, select localhost.
The only option currently implemented is to analyze the data in this deployment of FHIR Server.
-
Type a Selectivity Percentage or the Maximum Records to analyze.
-
Click Launch Analysis Task.
When the Percent Complete field reaches 100%, the analysis is done.
If your FHIR data changes significantly, you can create a new analysis at any time.
For more information on the analysis step, see the FHIR SQL Builder documentationOpens in a new tab.
Create a Transformation Specification
The next step is to create a transformation specification. This maps FHIR elements to SQL tables and columns.
To create a transformation specification:
-
On the InterSystems FHIR SQL Builder page, in the Transformation Specifications section, click New.
-
In the New Transformation Specification dialog box, type a Name for this specification.
-
In the Analysis field, select localhost.
-
Click Create Transformation Specification.
-
On the InterSystems FHIR SQL Builder page, in the Actions column for your transformation specification, click the Edit icon.
In the left pane, you will see a list of resource types and the number of each type in your FHIR repository.
-
Expand a resource you want to include in the transformation specification, and click an element you want to appear in the projection.
-
In the right pane, view the contents of the element, and add it (or any component elements it contains) by clicking Add Projection.
Elements you add will be added to the Currently Selected Items section of the screen, along with the resulting tables and columns that will be added to the schema.
-
Continue adding to the transformation specification, and when you are finished, click Done.
At any time, you can add to your transformation specification or remove tables and columns from the schema by clicking the Edit icon for your specification.
For more information on creating a transformation specification, see the FHIR SQL Builder documentationOpens in a new tab.
Project Your Data
The final step is to project your data into the SQL schema using your transformation specification.
To create a projection:
-
On the InterSystems FHIR SQL Builder page, in the Projections section, click New.
-
In the New Projection dialog box, for the FHIR Repository, select localhost.
-
For the Transformation Specification, select the transformation specification you created.
-
Type a Package Name for the package that will hold the tables created by the projection.
-
Click Launch Projection.
If you ever change your transformation specification, update your projection by clicking the Update icon for your projection.
For more information on projections, see the FHIR SQL Builder documentationOpens in a new tab.
Query Your Data
Once you have created a SQL projection from your FHIR data, you can connect to FHIR Server using JDBC or ODBC and query the data with standard SQL queries. But before you can do so, you need to create a firewall rule to enable a connection from the JDBC or ODBC client.
To connect a JDBC or ODBC client:
-
On the main menu for your deployment, click Overview.
-
In the Overview page, in the xDBC Details section, click the tab that corresponds to the type of client you are using (JDBC or ODBC).
-
Follow the instructions provided to connect your client.
Documentation
If you have any questions on how to use FHIR Server, on the main menu, click Documentation.
For documentation on all of the InterSystems cloud services, click your name at the top right of the Cloud Services Portal, and then click Documentation.
If you would like to submit any feedback to help InterSystems improve any of the InterSystems cloud services, click your name at the top right of the Cloud Services Portal, and then click Submit Feedback. While we cannot respond to all feedback we receive, we welcome your opinion and will take it into consideration when determining future directions.
If you need to contact support, see Getting HelpOpens in a new tab.
Common Cloud Services Portal Functionality
For information on common Cloud Services Portal functionality that is not specific to InterSystems FHIR Server, see Cloud Services Portal Reference InformationOpens in a new tab. This document includes material describing the top-level pages in the main menu: