Best Practices

When you use 1up SQL on FHIR, we recommend that you use the following are best practices for writing your SQL queries to use SQL on FHIR. Whether you are familiar with SQL syntax, or new to writing SQL queries, this information is valuable because it describes the specific recommended methods of querying for 1up SQL on FHIR.

If you don’t follow these instructions, you might return incorrect results.

For all of the example queries and code snippets in this topic, make sure to replace the placeholder text in the brackets (<code> or {query} with the correct parameters for your use case.

SQL on FHIR is a columnar store. We recommend that you only query the fields that are required for efficient and optimized performance. For more information about columnar storage, see Columnar storage in the Amazon Redshift Database Developer Guide.

Reserved Words

Amazon Redshift has a list of reserved words. Some of the table fields that you use with SQL on FHIR might coincide with the reserved words. To successfully query the fields without encountering issues, make sure to include double quotes (“ “) around the field name.

For a comprehensive list of all reserved words, see Reserved words in the Amazon Redshift Database Developer Guide.

Case Sensitivity

Some fields in FHIR tables include mixed-case values. To make sure you can successfully query the fields without encountering issues, you can enable the case-sensitive identifier.

After you enable the case sensitive identifier, you can query mixed-case fields.

Use SUPER

You can use the SUPER data type to store semistructured data as values. FHIR data is highly nested. You can use the SUPER data type to more easily store and interact with these complex data types.

For more information about how to use the SUPER type with Redshift, see SUPER type in the Amazon Redshift Database Developer Guide.

Unnest

A common task in SQL on FHIR is to query array data. SQL on FHIR supports the unnest function, which is used to expand an array into a relation that can be queried.

For example, you can query a FHIR table for Practitioner names. The name column in the fhir_r4.practitioner table is an array of structs, which contains a nest array for the given name.

When you write a query for this example, you must consider that fhir_r4.practitioner.name is an array of varying length that contains 0 or more elements. If you query only the first element from the array, you lose all other values that might be present. To get every element in the array, you must use the unnest function.

For more examples, see Example Queries.

For more information about unnesting, see Querying semistructured data in the AWS documentation.

Using JSON Functions

You can use the following JSON Functions to convert SQL data from one type to another.

  • JSON_SERIALIZE — Convert the SUPER data type to the VARCHAR data type

    For more information, see JSON_SERIALIZE function in the Amazon Redshift Database Developer Guide.

  • JSON_PARSE — Convert the VARCHAR data type to the SUPER data type

    For more information, see JSON_PARSE function in the Amazon Redshift Database Developer Guide.

Join Patient Resources

Joins are used to combine records from two or more related using a common identifier. You can use a join to query for a patient and all of that patient’s observations. SQL on FHIR uses local resource identifiers, in the RESOURCE_TYPE/ID form.

For example, an Observation resource contains a reference to a patient with the Patient/123xyz resource identifier. The Patient resource uses only the ID portion of that reference, which means that before you can use join you must first separate the local resource identifier resource type from the ID.

You can separate the local resource identifier with the split_part function in SQL on FHIR. In the Observation FHIR resource, the Patient identifier is found in the reference nested attribute of subject, which you can call using dot notation.

This function separates the string in fhir_r4.observation.subject.reference on the / slash character, and returns the second part, which is the ID.

Another function used in this example is json_serialize. The split_part function uses varchar as the first argument. Because fhir_f4.observation.subject.reference is a SUPER data type, you can use the json_serialize function to convert it to a VARCHAR data type.