Package org.linuxforhealth.fhir.schema.control

Class FhirSchemaGenerator

  • public class FhirSchemaGenerator
extends java.lang.Object
    Encapsulates the generation of the FHIR schema artifacts

    • Constructor Detail

      • FhirSchemaGenerator

        public FhirSchemaGenerator​(java.lang.String adminSchemaName,
                           java.lang.String schemaName,
                           SchemaType schemaType)
        Generate the IBM FHIR Server Schema for all resourceTypes
        Parameters:
        adminSchemaName -
        schemaName -

      • FhirSchemaGenerator

        public FhirSchemaGenerator​(java.lang.String adminSchemaName,
                           java.lang.String schemaName,
                           SchemaType schemaType,
                           java.util.Set<java.lang.String> resourceTypes)
        Generate the LinuxForHealth FHIR Server Schema with just the given resourceTypes
        Parameters:
        adminSchemaName -
        schemaName -
        resourceTypes -
        Throws:
        java.lang.IllegalArgumentException - if one or more of the resource types are not valid FHIR resource types

    • Method Detail

      • buildAdminSchema

        public void buildAdminSchema​(PhysicalDataModel model)
        Build the admin part of the schema. One admin schema can support multiple FHIRDATA schemas. It is also possible to have multiple admin schemas (on a dev system, for example, although in production there would probably be just one admin schema in a given database
        Parameters:
        model -

      • addTenantTable

        protected void addTenantTable​(PhysicalDataModel model)
        Create a table to manage the list of tenants. The tenant id is used as a partition value for all the other tables
        Parameters:
        model -

      • addTenantKeysTable

        protected void addTenantKeysTable​(PhysicalDataModel model)
        Each tenant can have multiple access keys which are used to authenticate and authorize clients for access to the data for a given tenant. We support multiple keys per tenant as a way to allow key rotation in the configuration without impacting service continuity
        Parameters:
        model -

      • addTenantSequence

        protected void addTenantSequence​(PhysicalDataModel pdm)
            CREATE SEQUENCE fhir_sequence
             AS BIGINT
     START WITH 1
          CACHE 1000
       NO CYCLE;
        Parameters:
        pdm -

      • buildSchema

        public void buildSchema​(PhysicalDataModel model)
        Create the schema using the given target
        Parameters:
        model -

      • buildDatabaseSpecificArtifactsPostgres

        public void buildDatabaseSpecificArtifactsPostgres​(PhysicalDataModel model)

      • buildDatabaseSpecificArtifactsCitus

        public void buildDatabaseSpecificArtifactsCitus​(PhysicalDataModel model)
        Add stored procedures/functions for Citus (largely based on PostgreSQL, but some functions are distributed based on a parameter to make them more efficient.
        Parameters:
        model -

      • addLogicalResources

        public void addLogicalResources​(PhysicalDataModel pdm)
        Add the system-wide logical_resources table. Note that LOGICAL_ID is denormalized, stored in both LOGICAL_RESOURCES and _LOGICAL_RESOURCES. This avoids an additional join, and simplifies the migration to this new schema model.
        Parameters:
        pdm -

      • addCommonCanonicalValues

        public void addCommonCanonicalValues​(PhysicalDataModel pdm)
        Create the COMMON_CANONICAL_VALUES table. Used from schema V0014 to normalize meta.profile search parameters (similar to common_token_values). Only the url is included by design. The (optional) version and fragment values are stored in the parameter mapping table (logical_resource_profiles) in order to support inequalities on version while still using a literal CANONICAL_ID = x predicate. These canonical ids are cached in the server, so search queries won't need to join to this table. The URL is typically a long string, so by normalizing and storing/indexing it once, we reduce space consumption.
        Parameters:
        pdm -

      • addLogicalResourceProfiles

        public Table addLogicalResourceProfiles​(PhysicalDataModel pdm)
        A single-parameter table supporting _profile search parameter values Add the LOGICAL_RESOURCE_PROFILES table to the given PhysicalDataModel. This table maps logical resources to meta.profile values stored as canonical URIs in COMMON_CANONICAL_VALUES. Canonical values can include optional version and fragment values as described here: https://www.hl7.org/fhir/datatypes.html#canonical
        Parameters:
        pdm -
        Returns:

      • addLogicalResourceTags

        public Table addLogicalResourceTags​(PhysicalDataModel pdm)
        A single-parameter table supporting _tag search parameter values. Tags are tokens, but because they may not be very selective we use a separate table in order to avoid messing up cardinality estimates in the query optimizer.
        Parameters:
        pdm -
        Returns:

      • addLogicalResourceSecurity

        public Table addLogicalResourceSecurity​(PhysicalDataModel pdm)
        Add the dedicated common_token_values mapping table for security search parameters
        Parameters:
        pdm -
        Returns:

      • addResourceChangeLog

        public void addResourceChangeLog​(PhysicalDataModel pdm)
        Add the resource_change_log table. This table supports tracking of every change made to a resource at the global level, making it much easier to stream a list of changes from a known point.
        Parameters:
        pdm -

      • addLogicalResourceCompartments

        public Table addLogicalResourceCompartments​(PhysicalDataModel pdm)
        Adds the system level logical_resource_compartments table which identifies to which compartments a give resource belongs. A resource may belong to many compartments.
        Parameters:
        pdm -
        Returns:
        Table the table that was added to the PhysicalDataModel

      • addResourceStrValues

        public Table addResourceStrValues​(PhysicalDataModel pdm)
        Add system-wide RESOURCE_STR_VALUES table to support _profile properties (which are of type REFERENCE).
        Parameters:
        pdm -
        Returns:
        Table the table that was added to the PhysicalDataModel

      • addResourceDateValues

        public Table addResourceDateValues​(PhysicalDataModel model)
        Add the table for data search parameters at the (system-wide) resource level
        Parameters:
        model -
        Returns:
        Table the table that was added to the PhysicalDataModel

      • addResourceTypes

        protected void addResourceTypes​(PhysicalDataModel model)
                CREATE TABLE resource_types (
            resource_type_id INT NOT NULL
            CONSTRAINT pk_resource_type PRIMARY KEY,
            resource_type   VARCHAR(64) NOT NULL
        );

        -- make sure resource_type values are unique
        CREATE UNIQUE INDEX unq_resource_types_rt ON resource_types(resource_type);
        Parameters:
        model -

      • addResourceTables

        protected void addResourceTables​(PhysicalDataModel model,
                                 IDatabaseObject... dependency)
        Add the collection of tables for each of the listed FHIR resource types
        Parameters:
        model -

      • addParameterNames

        protected void addParameterNames​(PhysicalDataModel model)
        CREATE TABLE parameter_names ( parameter_name_id INT NOT NULL CONSTRAINT pk_parameter_name PRIMARY KEY, parameter_name VARCHAR(255 OCTETS) NOT NULL ); CREATE UNIQUE INDEX unq_parameter_name_rtnm ON parameter_names(parameter_name) INCLUDE (parameter_name_id);
        Parameters:
        model -

      • addCodeSystems

        protected void addCodeSystems​(PhysicalDataModel model)
        Add the code_systems table to the database schema CREATE TABLE code_systems ( code_system_id INT NOT NULL CONSTRAINT pk_code_system PRIMARY KEY, code_system_name VARCHAR(255 OCTETS) NOT NULL ); CREATE UNIQUE INDEX unq_code_system_cinm ON code_systems(code_system_name);
        Parameters:
        model -

      • addCommonTokenValues

        public void addCommonTokenValues​(PhysicalDataModel pdm)
        Adds the appropriate common_token_values table depending on the schema type
        Parameters:
        pdm -

      • addCommonTokenValuesStandard

        public void addCommonTokenValuesStandard​(PhysicalDataModel pdm)
        Table used to store normalized values for tokens, shared by all the _TOKEN_VALUES tables. Although this requires an additional join, it cuts down on space by avoiding repeating long strings (e.g. urls). This also helps to reduce the total sizes of the indexes, helping to improve cache hit rates for a given buffer cache size. Token values may or may not have an associated code system, in which case, it assigned a default system. This is why CODE_SYSTEM_ID is not nullable and has a FK constraint. We never need to find all token values for a given code-system, so there's no need for a second index (CODE_SYSTEM_ID, TOKEN_VALUE). Do not add it. Because different parameter names may reference the same token value (e.g. 'Observation.subject' and 'Claim.patient' are both patient references), the common token value is not distinguished by a parameter_name_id. From V0027, token values are no longer used to represent relationships between resources. When using a distributed database (Citus), this table is distributed as a REFERENCE table, meaning that all records will exist on all nodes.
        Parameters:
        pdm -

      • addCommonTokenValuesDistributed

        public void addCommonTokenValuesDistributed​(PhysicalDataModel pdm)
        The common_token_values definition used for the distributed (Citus) variant of the schema. Because this table may contain one or more values per resource (e.g. identifier), we need to distribute it somehow.
        Parameters:
        pdm -
        See Also:
        addCommonTokenValuesStandard(PhysicalDataModel)

      • addResourceTokenRefs

        public Table addResourceTokenRefs​(PhysicalDataModel pdm)
        Add the system-wide RESOURCE_TOKEN_REFS table which is used for _tag and _security search properties in R4 (new table for issue #1366 V0006 schema change). Replaces the previous TOKEN_VALUES table. All token values are now normalized in the COMMON_TOKEN_VALUES table. Because this is for system-level params, there's no need to support composite params
        Parameters:
        pdm -
        Returns:
        Table the table that was added to the PhysicalDataModel

      • addErasedResources

        public void addErasedResources​(PhysicalDataModel pdm)
        The erased_resources table is used to track which logical resources and corresponding resource versions have been erased using the $erase operation. This table should typically be empty and only used temporarily by the erase DAO/procedures to indicate which rows have been erased. The entries in this table are then used to delete any offloaded payload entries.
        Parameters:
        pdm -

      • addFhirSequence

        protected void addFhirSequence​(PhysicalDataModel pdm)
            CREATE SEQUENCE fhir_sequence
             AS BIGINT
     START WITH 1
          CACHE 20000
       NO CYCLE;
        Parameters:
        pdm -

      • addFhirChangeSequence

        protected void addFhirChangeSequence​(PhysicalDataModel pdm)
        Adds a new sequence required for distributed databases like Citus
        Parameters:
        pdm -

      • addReferencesSequence

        protected void addReferencesSequence​(PhysicalDataModel pdm)
        Add the sequence used by the new local/external references data model
        Parameters:
        pdm -

      • addWiths

        protected java.util.List<With> addWiths()
        The defaults with addWiths. Added to every table in a PostgreSQL schema
        Returns: