Package com.ibm.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,
                           boolean multitenant)
        Generate the IBM FHIR Server Schema for all resourceTypes
        Parameters:
        adminSchemaName -
        schemaName -

      • FhirSchemaGenerator

        public FhirSchemaGenerator​(java.lang.String adminSchemaName,
                           java.lang.String schemaName,
                           boolean multitenant,
                           java.util.Set<java.lang.String> resourceTypes)
        Generate the IBM FHIR Server Schema with just the given resourceTypes
        Parameters:
        adminSchemaName -
        schemaName -

    • 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 -

      • addVariable

        public void addVariable​(PhysicalDataModel model)
        Add the session variable we need. This variable is used to support multi-tenancy via the row-based access control permission predicate.
        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 -

      • buildDatabaseSpecificArtifactsDb2

        public void buildDatabaseSpecificArtifactsDb2​(PhysicalDataModel model)

      • buildDatabaseSpecificArtifactsPostgres

        public void buildDatabaseSpecificArtifactsPostgres​(PhysicalDataModel 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)
        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. Where common token values are used to represent local relationships between two resources, the code_system encodes the resource type of the referenced resource and the token_value represents its logical_id. This approach simplifies query writing when following references.
        Parameters:
        pdm -

      • 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 -

      • 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: