For a list of the supported upgrade paths, see Supported Upgrade Paths.
To upgrade the OHF Data Model, follow the instructions below:
| Make sure the OBIEE service is shut down. | |
| Make sure Oracle Database 12.2.0.1 Enterprise Edition is installed. | |
Make sure that the database compatible parameter is set to 12.2.0.1.0 by connecting to the DBA user and running the query below:
select * from v$parameter where name = 'compatible'; If the parameter is not set to 12.2.0.1.0, ask your database administrator to set it. |
|
| If you are upgrading OHF on an Exadata environment, make sure the Oracle database patch 19562381 (Doc ID >19562381.8) is applied. | |
| Create a container database with a single pluggable database instance with the help of a Database Administrator. | |
| Make sure the database initialization parameter MAX_STRING_SIZE is set to STANDARD (default value). | |
| Make sure Java Virtual Machine is installed on the database server. | |
| Set the NLS_LENGTH_SEMANTICS parameter to either CHAR or BYTE based on your requirements.
For Oracle Healthcare Foundation Globalization Support information, see Oracle Database Globalization Support Guide and set your database character set accordingly. |
|
| Enable database connection through SERVICE_NAME. Make sure that you are connecting to the pluggable database instance.
Verify the database connectivity using the following command: SQL>connect <username>@<hostname>:<port number>/<service name> or sqlplus <username>@'(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<dbhost>)(PORT=<dbport>))(CONNECT_DATA=(SERVICE_NAME=<dbservicename>)))' |
|
| Make sure the Sqlplus utility is available on the installation server. | |
| Make sure the password expiry notification message does not display for the Sys, system and all OHF schemas. | |
| If you have OHTR 3.1.x installed, make backups of the CDM, ODB, Enterprise, Job Engine and Apps schemas. Import CDM, ODB, Enterprise, Job Engine, and Apps schemas in the Pluggable database instance created for OHF.
The CDM, ODB, Enterprise, and Job Engine schemas are updated as part of the OHF 7.2.1 upgrade. The Apps schema is upgraded during the OHTR 3.2 upgrade. If you are importing existing OHTR schemas into different schemas, update the tables below after importing the dump. Connect to the ODB schema and run the following commands:
|
|
| Before you upgrade to Oracle Healthcare Foundation 7.2.1, back up the data model schemas of the existing Oracle Healthcare Data Warehouse Foundation (HDWF) environment and the OHTR schemas (if you have installed older versions of OHTR). | |
| During the upgrade, certain objects are dropped irrespective of prefixes or naming conventions. This includes objects such as packages, stored procedures, views, materialized views, scheduler jobs, and synonyms.
Make a backup of the custom scripts before the upgrade and re-execute the custom scripts for all custom objects after the upgrade. |
|
| Set the GLOBAL_NAMES database initialization parameter to false. | |
For remote upgrades, make sure the following are available on the client machine:
|
|
| Before you run the OHF installer to upgrade the existing schema, execute the following query as a SYSTEM user to validate if the data model user has OHF_APPLICATION_ROLE as the default role.
Data model users are schema users that are used during the installation of the OHF Data Model. If this is not a default role, execute the following command as a SYSTEM user to set this as a default role:
Where
Note: If you don't have OHTR products installed, assign |
|
| Make sure that the SELECT privilege on the ALL_TAB_COLS view is granted to the PUBLIC role.
Log in as SYS user and execute the following query: select * from dba_tab_privs where table_name = 'ALL_TAB_COLS'; If the privilege is not found, execute the below query as SYS user to grant the privileges to the PUBIC role: grant select on SYS.ALL_TAB_COLS to PUBLIC with grant option; |
|
| Table compression strategy is decided based on the number of updates in tables. If the number of updates is high, select the Advanced compression option instead of HCC (QUERY HIGH). Also, cross-check the compression used in the previous version. | |
| Make sure that you have an appropriate database license for the compression methods you choose. | |
| The installer does not validate the tablespace data files location. If the database server is on the remote server, make sure the location physically exists or the installer will fail. |
For the list of supported upgrade paths, see Supported Upgrade Paths.
If you are upgrading from Healthcare Data Warehouse Foundation (HDWF) 6.1 to Oracle Healthcare Foundation, you must install Oracle Healthcare Analytics Data Integration (OHADI) 3.1.
Note:
After upgrading, continue to Data Migration (Not Applicable When Upgrading from OHF 7.1) for instructions on how to migrate data from HDWF to OHF.To upgrade from HDWF 6.1 to OHF, upgrade the HDWF 6.1 database instance to the Oracle Database 12.2.0.1 Enterprise Edition.
Make sure that all the OHF schemas are disconnected from the database by querying gv_$session from the sys user:
select * from sys.gv_$session where status <> 'KILLED' and username in ('<OHF Schemas>');
|
|
| Extract the contents of the OHF media pack to your system. | |
| Open the <media_pack_location>/ folder. | |
| Unzip the OHF_721_Linux-x64.zip file where you want to launch the installer using the following command:
|
|
| Open the Disk1/install folder. | |
| Change the protection on files as follows:
|
Start the Oracle Universal Installer (OUI) using the following command:
If the database server (Exadata or non-Exadata) is on the machine where the installer is running, execute:
sh runInstaller.sh -local
If the database server is on a different machine, execute:
sh runInstaller.sh -local remote_installation=true
where, the -local option is to install on the local node irrespective of the cluster nodes specified on the installer machine.
| Screen | Action | |
|---|---|---|
| Welcome | Click Next. | |
| Select a Product to Install | Select the Oracle Healthcare Foundation Data Model 7.2.1.0.0 option. | |
| Specify Home Details | Enter the installation home name and location. | |
| Verify Installation Prerequisites | Verify if all the prerequisites are met before proceeding. | |
| Oracle Client Home Configuration | Specify the Oracle (version 12.2.0.1.0) client home path. The installer validates this path. | |
| Database Configuration | Enter values for the following fields:
|
|
| Table Compression | On an Exadata setup, use the following compression options:
Interface Tables schema
Data Warehouse schema
Common Data Mart schema
Cohort Data Mart schema
Omics Data Bank schema
On a non-Exadata setup, for each of the above schemas, choose either No Compression (default) or Advanced Compression. |
|
| Data Model Configuration | Enter values for the pre-created schemas:
|
|
| Data Model Configuration | Enter values for the pre-created schemas. If OHTR schemas exist, provide the existing schema names, otherwise provide new schema names.
|
|
| Data Model Configuration | Enter values for the following fields:
|
|
| Data Model Configuration Verification | Click Next. | |
| Omics Data Bank and Cohort Data Mart Parameters | Enter values for the following fields. Make sure you use the same values you are currently using for: Result Partition, Promoter Offset, Flanking Offset and Job Store Name. If you don't have existing OHTR schemas, then choose appropriate options.
Execute the following query to find all store names in the database (created by all previous installations) by connecting to the SYS user:
Note: If you have store names in the database that do not match the
Note: If you are using the same database instance for multiple environments, enter a unique job store name for each job schema. |
|
| Summary | Click Install. | |
| End of Installation | Click Exit after reviewing the installation information. At the confirmation prompt, click Yes to exit the installer. |
| Review the generated installation log files for errors. For details, see Installation Log Files. | |
| Contact Oracle support, if necessary, to resolve any errors. |
Note:
Data Migration is not required for OHF 7.1.To upgrade from a previous OHF version (other than 7.1.x) or to migrate the data from Healthcare Data Warehouse Foundation 6.1, follow the steps below:
Data migration for interface tables and data warehouse schema is not performed by the installer. You need to review the data migration scripts in <INSTALL_HOME>/dm/hdi_install/post_ddl_upgrade.sql and <INSTALL_HOME>/dm/hdm_install/post_ddl_upgrade.sql (note that there are references to other scripts within the main script). You can modify the scripts before executing them.
Note:
Migration scripts execution is mandatory and needs to be completed before the ETL execution.Note:
Both sections below (HDWF 6.1 to OHF 7.0.1 Data Migration Summary and OHF 7.0.1 to 7.1.1 Data Migration Summary) are applicable for migrating from HDWF 6.1 to OHF 7.1.1.Specimen.Intervention ID/VN is deprecated and data is migrated to Intervention Specimen.
Specimen Processing Procedure. Specimen Processing Procedure Subtype is added as a mandatory attribute to Specimen Processing Procedure. This is initialized with the appropriate seed data coded value 'SPP_SUBTYP_GEN' during the migration.
Schedule Block.Schedule Block Subtype is added as a mandatory attribute to Schedule Block. This is initialized with the appropriate seed data coded value 'SCH_BLCK_SUBTYP_GEN' during the migration.
Schedule.Service Provider is deprecated and data is transferred to Schedule Service Provider.
Observation. Specimen ID/VN is deprecated and data is transferred to Observation Specimen. On the interface tables schema, data is transferred from Observation, Assessment, and Image Instance to Observation Specimen.
Data is migrated from Encounter Service Provider to Encounter.Responsible Service Provider for Encounter Service Provider Relationship Type="Responsible Service Provider". If the same encounter is associated to multiple service providers for a given value of Encounter and Relationship Type="Responsible Service Provider", the service provider that was inserted last will be migrated to Encounter.
The integration ID of the parent table is used wherever a new table is populated based on an existing table.
The migration scripts use the seed data values given below provided by Oracle. If you have used a different set of seed data values in Encounter Service Provider to represent a Responsible Service Provider relationship, change it in the migration script for both Interface Tables and Data Warehouse schema, and run post_ddl_upgrade.sql.
The following are the seed data values that are used for filtering Encounter Service Provider. Encounter Service Provider Relationship Type in the migration scripts:
HDI_ENC_SVCPRV.ENC_SVCPRV_RLTYP_CD='ENC_SVCPRV_RLSHPTYP_RSPNSBL_SVCPRV' (CD_NM='Responsible Service Provider' AND INTEGRATION_ID='ENC_SVCPRV_RLSHPTYP_RSPNSBL_SVCPRV~EHA_CUSTOM_CD_SYS~1.0' AND SYS_INT_ID='EHA_CUSTOM_CD_SYS~1.0' AND SYS_DAT_SRC_NUM_ID=1 AND CREATED_BY_USER_ID='EHA_USER' AND CREATED_BY_USER_DS_NUM_ID=1)
On the Data Warehouse schema, it corresponds to HDM_ENC_SVCPRV.ENC_SVCPRV_RLSHPTYP_ID/VN resolving to the following code:
CD='ENC_SVCPRV_RLSHPTYP_RSPNSBL_SVCPRV' AND CD_NM='Responsible Service Provider' AND INTEGRATION_ID='ENC_SVCPRV_RLSHPTYP_RSPNSBL_SVCPRV~EHA_CUSTOM_CD_SYS~1.0'
The values mentioned above are presented in a logical way and is not the exact physical representation of the values present in the migration scripts. See sql files <INSTALL_HOME>/dm/hdi_install/pkb/hdi_upgrade_7_0.pkb and <INSTALL_HOME>/dm/hdm_install/pkb/hdm_upgrade_7_0.pkb for the exact seed data values.
Key steps related to data migration are logged into the HDI_RSLT_LOG and HDM_RSLT_LOG tables in the respective schemas.
Bill Line Item.Bill Diagnosis ID/VN is deprecated and the corresponding data is migrated to Bill Diagnosis as new records.
Claim Line Item.ClaimDiagnosis ID/VN is deprecated and the corresponding data is migrated to Claim Diagnosis as new records.
The values mentioned above are presented in a logical way and is not the exact physical representation of the values in the migration scripts. For exact details, see the SQL files:
<INSTALL_HOME>/dm/hdi_install/pkb/hdi_upgrade_7_1.pkb and <INSTALL_ HOME>/dm/hdm_install/pkb/hdm_upgrade_7_1.pkb.
HDM_INTVN_SPCMN. INTVN_SPCMN_RLSHPTYP_ID/VN is populated with the value -1 corresponding to the default value of CODEID_NAV configured in the HMC schema. If you have modified the seed data, change the script <INSTALL_HOME>/dm/hdm_install/post_ddl_upgrade.sql accordingly.
Review the integration ID pattern for records populated using the migration scripts and change it accordingly if needed.
It is assumed that the time stamps for SRC_CHANGED_ON_DT, match from the parent to the child reference on the interface schema. For example, the value of HDI_ENC_SVCPRV. ENC_SRC_CHANGED_ON_DT should be same as that of the parent, that is, HDI_ENC.SRC_CHANGED_ON_DT for the same record being referred in both tables right up to the seconds. If it is not the same, change the migration script accordingly.
Follow the instructions below to migrate the Interface Tables schema:
| Open the command prompt and navigate to the <INSTALL_HOME>/dm/hdi_install/ folder. | |
Connect to the Interface Tables schema using the SQL*Plus utility. |
|
Execute the script using the command '@post_ddl_upgrade.sql'. |
Follow the instructions below to migrate the Data Warehouse schema:
| Open the command prompt and navigate to the <INSTALL_HOME>/dm/hdm_install/ folder. | |
Connect to the Data Warehouse schema using the SQL*Plus utility. |
|
Execute the script using the command '@post_ddl_upgrade.sql'. |