Export one or more ViewDefinitions, SQLQuery Libraries and SQLView Libraries as a single asynchronous job, using the FHIR Asynchronous Interaction Request Pattern.

Execute a ViewDefinition, SQLQuery Library or SQLView Library and return the result in the requested output format.

A quantity- or range-valued use context assigned to the view definition

A use context assigned to the view definition

A use context type and quantity- or range-based value assigned to the view definition

A type of use context assigned to the view definition

A use context type and value assigned to the view definition

The view definition publication date

The description of the view definition

External identifier for the view definition

Intended jurisdiction for the view definition

Computationally friendly name of the view definition

A FHIR profile the view definition is intended to be executed against

Name of the publisher of the view definition

The FHIR resource type the view definition is based upon

The current status of the view definition

The human-friendly name of the view definition

The uri that identifies the view definition

The business version of the view definition

A ViewDefinition represents a tabular projection of a FHIR resource, where the columns and inclusion criteria are defined by FHIRPath expressions.

The SQLQuery profile represents a SQL query that runs against ViewDefinition tables. It bundles the SQL, dependencies, and parameters for sharing and versioning.

The SQLView profile represents a reusable, named SQL query that other queries reference as a virtual table source, analogous to a SQL view. It bundles the SQL and its dependencies for sharing and versioning. Unlike SQLQuery, an SQLView cannot declare parameters.

A profile for View Definitions intended to be shared between multiple systems. This requires that the View Definition have a defined URL and name. It also requires declaration of the FHIR version that the view is intended to be executed over, and the FHIR type of each column. This ensures consistent interpretation of the view across different view runner implementations.

A profile for View Definitions where each resulting field must contain only a simple scalar value. This is sometimes referred to as 'CSV Mode', but applies to any system that explicitly constrains its views or tables to tabular data.

Plain-text SQL query for human readability. Supplements the base64-encoded Attachment.data.

ValueSet of all codes from SQL Content Type Codes codesystem

Output format codes supported by the export operations. Excludes fhir, which applies to the run operations only; see Common Operation Behavior.

ValueSet of all codes from Export Status Codes codesystem

ValueSet of all codes from the Output Format Codes code system. Used by the synchronous run operations; see Common Operation Behavior.

Export status codes for SQL on FHIR.

Output format codes for SQL on FHIR.

Permitted contentType values for SQLQuery attachments, including dialect-specific variants.

Library types for SQL on FHIR.

A SQL query that composes the ActivePatientsView, demonstrating an SQLQuery that references an SQLView as a virtual table.

A reusable SQL view selecting active patients, intended to be referenced as a virtual table by other queries.

Annotated SQL query example demonstrating how tooling can derive Library metadata.

Demonstrates using repeat with nested select to traverse a CodeSystem concept hierarchy. This produces parent-child code pairs by using repeat to walk down the concept tree and a nested forEach to extract each child concept at every level. Useful for building concept maps or analysing hierarchical terminologies.

A simple view for flattening a Condition resource. Some of the more commonly used fields are included in this flat view. A notable point is flattening of category.coding fields with one forEach construct as FHIRPath will take care of handling of nested arrays.

A simple view for flattening an Encounter resource. Some of the more commonly used fields are included in this flat view. Note this is valid for an R4 Encounter resource but not R5 (hence the fhirVersion).

Disambiguates OMOP and FHIR Patient views and joins diagnoses for context.

An example of unnesting patient addresses into multiple rows. This view uses forEach to indicate we are unrolling these into separate rows. The join function is used to create a single address line.

A minimal example of a patient demographics view. This view uses the first 'official' patient name for our demographics table.

An example demonstrating the use of %rowIndex to capture the position of elements within a collection. This is useful for preserving FHIR ordering semantics and creating surrogate keys that combine resource ID with element position.

An example of unnesting patient addresses and contact addresss into multiple rows, which are unioned together into a single table.

Demonstrates using the repeat directive to recursively flatten nested QuestionnaireResponse items. Unlike forEach, which only unnests a single level, repeat traverses all levels of nesting to produce one row per item regardless of depth. This is useful for analysing survey responses where questions may be grouped into nested sections.

Creates the same view as the 'PatientDemographics' example, but applies both the ShareableViewDefinition and TabularViewDefinition profiles.

A simple view of blood pressure observations, with separate columns for systolic and diastolic values.

A SQL query that retrieves the most recent address per patient with a city filter.

All the ViewDefinition operations defined by this guide.