| Oracle® Health Sciences Information Manager Health Record Locator Installation and Configuration Guide Release 3.0 E61286-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Health Sciences Information Manager Health Record Locator Installation and Configuration Guide Release 3.0 E61286-01 |
|
|
PDF · Mobi · ePub |
This chapter provides the instructions to install and configure the OHIM Health Record Locator.
This chapter includes the following sections:
Section 2.2, "Upgrading from Version 1.2.8.x or Higher up to 2.0.2.x"
Section 2.3, "Installing the Oracle Health Sciences Information Manager Health Record Locator"
Section 2.12, "Setting up Keystore and Truststore for TLS Communication"
If you have 1.2.X HRL installed, and if required, back up config/xconfig.xml and codes/codes.xml files. These files are located in <GlassFish_Home>/domains/<domain_name>/config/hrl/.
Note:
If you are migrating from 1.2.8.X and 2.0.2.1, skip to Section 2.2.2.Section 2.1.2.1 and Section 2.1.2.2 are only applicable if you are migrating data from 1.2.7.3 and earlier releases.
Note:
It is assumed that the patient merge and unmerge operations do not happen during data migration.Execute the following command from sys db user:
> sqlplus system as sysdba
...
Enter password: <password>
SQL>GRANT SELECT ON OMAR.EXTERNALIDENTIFIER TO ADT;
Connect to adt db user:
> sqlplus adt
...
Enter password: <password>
Execute the following command:
SQL>@<temp>/ADT_Patient_Migration.sql"
where, <temp> is the file path where the <install_dir>/ohim_hrl_installer/addons/recordlocator/oracle_db/rls_oracle_db_scripts.zip file is extracted.
Execute the following command:
SQL>@<temp>/ADT_MergeddObjects_Migration.sql
where, <temp> is the file path where the <install_dir>/ohim_hrl_installer/addons/recordlocator/oracle_db/rls_oracle_db_scripts.zip file is extracted.
Execute the following command from sys db user:
> sqlplus system as sysdba
...
Enter password: <password>
SQL>REVOKE SELECT ON OMAR.EXTERNALIDENTIFIER FROM ADT;
Perform the following steps to migrate DocumentEntry, SubmissionSet, Folder, and Association registry objects metadata:
To configure the Oracle database with Health Record Locator, perform the following steps:
Copy the file from <install_dir>/ohim_hrl_installer/addons/recordlocator/oracle_db/rls_oracle_db_scripts.zip to the host where the SQL Plus client is present in the PATH. Unzip the contents.
Log in to the host having SQL Plus and change the directory to where you have copied or extracted the files in step 1.
Update the create_tblspc_hrlcore_user.sql file with the Oracle DB specific Tablespace information and new password for the user HRLCORE (&hrlcorepswd). Also, update scripts createadtddl.sql, createlogddl.sql, createhrlcoreddl.sql, and create_hrlcore_indexes.sql based on your environments and requirements. Consider recommendations in Section 2.9.7 while updating these scripts.
Through SQL Plus, use admin or an ID in the Oracle DB having access to create table spaces and users to execute create_tblspc_hrlcore_user.sql.
Execute the following command through SQL Plus using the ID created in step 4.
createhrlcoreddl.sql using HRLCORE
After creating HRLCORE schema successfully, remove the create_tblspc_hrlcore_user.sql file.
Connect to omar DB using the following script:
> sqlplus omar
...
Enter password: <password>
Execute the following SQL query to find duplicate SubmissionSets that exist in omar schema. The select query returns the SubmissionSet UID and the SubmissionSet ID.
> SELECT EI.VALUE,EI.REGISTRYOBJECT FROM EXTERNALIDENTIFIER EI WHERE EI.VALUE IN (SELECT EID.VALUE FROM EXTERNALIDENTIFIER EID WHERE EID.IDENTIFICATIONSCHEME='SU' GROUP BY EID.VALUE HAVING COUNT(*) > 1) ORDER BY EI.VALUE ASC, EI.REGISTRYOBJECT ASC;
Note:
It is assumed that you will manually delete the duplicate SubmissionSet and its contents after obtaining the list of such IDs by using the above query.If document metadata is registered in the registry before HRL 1.2.1.1 patch, execute the following steps:
Run the following queries to determine the record counts:
SELECT COUNT(*) ASSOC_COUNT FROM ASSOCIATION WHERE VERSIONNAME='1.1';
SELECT COUNT(*) EO_COUNT FROM EXTRINSICOBJECT WHERE VERSIONNAME='1.1';
SELECT COUNT(*) RP_COUNT FROM REGISTRYPACKAGE WHERE VERSIONNAME='1.1';
SELECT COUNT(*) CLS_COUNT FROM CLASSIFICATION WHERE VERSIONNAME='1.1';
SELECT COUNT(*) EI_COUNT FROM EXTERNALIDENTIFIER WHERE VERSIONNAME='1.1';
If the record count is greater than zero, execute the following PLSQL script to change the version of registry objects.
SQL>@<temp>/update_regob_versioninfo.sql
where, <temp> is the file path where the <install_dir>/ohim_hrl_installer/addons/recordlocator/oracle_db/rls_oracle_db_scripts.zip file is extracted.
Run the following steps to ensure that Extrinsicobject or Registrypackage LID value is updated with ID when LID is not in the UUID format:
Run the following queries to determine the record counts where registry LID of the object is not in the UUID format:
SELECT COUNT(*) EO_COUNT FROM EXTRINSICOBJECT WHERE LID NOT LIKE 'urn:uuid:%';
SELECT COUNT(*) RP_COUNT FROM REGISTRYPACKAGE WHERE LID NOT LIKE 'urn:uuid:%';
If the record count is greater than zero, execute the following PLSQL script to update the LID value.
SQL>@<temp>/update_non_urn_lid_value.sql
where, <temp> is the file path where the <install_dir>/ohim_hrl_installer/addons/recordlocator/oracle_db/rls_oracle_db_scripts.zip file is extracted.
Execute the following command from system user:
> sqlplus system as sysdba
...
Enter password: <password>
SQL>GRANT CONNECT, RESOURCE TO hrlcore IDENTIFIED BY <hrlcore_password>;
SQL>GRANT SELECT ON OMAR.ASSOCIATION TO HRLCORE;
SQL>GRANT SELECT ON OMAR.CLASSIFICATION TO HRLCORE;
SQL>GRANT SELECT ON OMAR.DESCRIPTION TO HRLCORE;
SQL>GRANT SELECT ON OMAR.EXTERNALIDENTIFIER TO HRLCORE;
SQL>GRANT SELECT ON OMAR.EXTRINSICOBJECT TO HRLCORE;
SQL>GRANT SELECT ON OMAR.NAME_ TO HRLCORE;
SQL>GRANT SELECT ON OMAR.REGISTRYPACKAGE TO HRLCORE;
SQL>GRANT SELECT ON OMAR.SLOT TO HRLCORE;
Create the following database types by connecting to hrlcore db user:
> sqlplus hrlcore
...
Enter password:<password>
create or replace TYPE HRL_QRY_ONE_PARAM_TYPE AS OBJECT (ONE VARCHAR2(256));
/
create or replace TYPE HRL_QRY_ONE_PARAM_TYPE_TABLE AS TABLE OF HRL_QRY_ONE_PARAM_TYPE;
/
Navigate to the migration directory using the following steps:
Execute the following command:
> cd <install_dir>/ohim_hrl_installer/addons/recordlocator
Extract the contents of the migration-bin.tar.gz file by executing the following command:
> tar -zxvf migration-bin.tar.gz
Execute the following command:
> cd migration
In the rls_migration.properties file, edit the DB and number of threads information.
Note:
Before running the migration tool, in the logging.properties file, ensure to set the java.util.logging.FileHandler.level to
SEVERE. This avoids generating detailed log statements.Execute the following commands to create the credential store that holds the HRLCORE DB user's password. Ensure that you provide correct value for hrlcore database user to have the next migration process steps work properly.
For Linux: a) sh createCredentialStore.sh
For Windows: a) createCredentialStore.cmd
Execute the following consolidated command to store DocumentEntry IDs, Association IDs, Folder IDs, and SubmissionSet IDs to different files:
For Linux: a) sh runStoreRegObjIdsToFile.sh
For Windows: a) runStoreRegObjIdsToFile.cmd
This command internally calls separate scripts, which store registry object IDs to different files.
The following is the mapping between scripts that are called internally and the corresponding output files generated:
runStoreDocIdsToFile.sh (runStoreDocIdsToFile.cmd, for Windows) - DocumentEntryUUIDs.txt
runStoreAssocIDsToFile.sh (runStoreAssocIDsToFile.cmd, for Windows) - HasMemberAssocUUIDs.txt (for Has Member associations) and OtherAssocUUIDs.txt (for all the other association types)
runStoreFolderIdsToFile.sh (runStoreFolderIdsToFile.cmd, for Windows) - FolderUUIDs.txt
runStoreSubmissionSetIdsToFile.sh (runStoreSubmissionSetIdsToFile.cmd, for Windows) - SubmissionSetUUIDs.txt
Note:
If DocumentEntryUUIDs.txt already exists, the tool renames it as DocumentEntryUUIDs_timestamp.txt and recreates DocumentEntryUUIDs.txt. This process applies to all the other runStore*.sh scripts.Execute the following consolidated command to migrate metadata of all the registry objects:
For Linux: a) sh runAllRegObjsMetadataMigration.sh
For Windows: a) runAllRegObjsMetadataMigration.cmd
This command internally calls separate scripts that carry out the actual metadata migration for that particular registry object type.
The following is the mapping between the scripts that are called internally and the corresponding registry object type whose metadata is migrated:
runDocEntryMigration.sh (runDocEntryMigration.cmd, for Windows) - Document Entries' metadata
runHMAssociationMigration.sh (runHMAssociationMigration.cmd, for Windows) - Has Member Associations' metadata
runOtherAssociationMigration.sh (runOtherAssociationMigration.cmd, for Windows machine) - Other [APND, RPLC, XFRM, XFRM_RPLC, Signs] Associations' metadata
runFolderMigration.sh (runFolderMigration.cmd, for Windows) - Folders' metadata
runSubmissionSetMigration.sh (runSubmissionSetMigration.cmd, for Windows) - SubmmissionSets' metadata
Note:
All successfully processed DocumentEntry, Association, Folder, SubmissionSet UUIDs, latest deprecated DocumentEntry UUIDs are recorded to the SuccessfulTransactions_DE.txt, SuccessfulTransactions_HM_Assoc.txt, SuccessfulTransactions_OTH_Assoc.txt, SuccessfulTransactions_FL.txt, SuccessfulTransactions_SS.txt, and SuccessfulTransactions_DE_Deprecated.txt files.Failures are recorded in the FailedTransactions_DE.txt, FailedTransactions_HM_Assoc.txt, FailedTransactions_OTH_Assoc.txt, FailedTransactions_FL.txt, FailedTransactions_SS.txt, and FailedTransactions_DE_Deprecated.txt files.
The RECORD_SUCCESSFUL_TRANSACTIONS_FLAG in rls_migration.properties indicates whether to record successfully processed UUIDs in the SuccessfulTransactions_*.txt file.
Execute the following command to get the IDs of registry objects whose statuses are updated in omar schema after metadata migration:
For Linux: a) sh runStoreRegObjIdsOfStatusUpdatesToFile.sh
For Windows: a) runStoreRegObjIdsOfStatusUpdatesToFile.cmd
This command internally calls separate scripts that identifies the registry objects whose statuses are updated in the DB, and write their IDs to different files.
The following is the mapping between the scripts that are called internally and the corresponding output files generated:
runStoreDocIdsOfStatusUpdatesToFile.sh (runStoreDocIdsOfStatusUpdatesToFile.cmd, for Windows) - DocumentEntryUUIDs.txt
runStoreAssocIDsOfStatusUpdatesToFile.sh (runStoreAssocIDsOfStatusUpdatesToFile.cmd, for Windows) - HasMemberAssocUUIDs.txt (for Has Member associations), and OtherAssocUUIDs.txt (for all the other association types)
runStoreFolderIdsOfStatusUpdatesToFile.sh (runStoreFolderIdsOfStatusUpdatesToFile.cmd, for Windows) - FolderUUIDs.txt
Execute the following script to synchronize the status of registry objects between hrlcore and omar DB schemas:
For Linux: a) sh runAllRegObjsStatusUpdate.sh
For Windows: a) runAllRegObjsStatusUpdate.cmd
This command internally calls separate scripts that carry out the actual status synchronization activity for the registry objects.
The following is the mapping between the scripts that are called internally and the corresponding registry object type whose statuses get synchronized between hrlcore and omar DB:
runUpdateDocEntryStatus.sh (runUpdateDocEntryStatus.cmd, for Window) - Document Entries statuses
runUpdateHMAssociationStatus.sh (runUpdateHMAssociationStatus.cmd, for Windows) - Has Member Associations' statuses
runUpdateOTHAssociationStatus.sh (runUpdateOTHAssociationStatus.cmd, for Windows) - Other [APND, RPLC, XFRM, XFRM_RPLC, Signs] Associations' statuses
runUpdateFolderStatus.sh (runUpdateFolderStatus.cmd, for Windows) - Folders' statuses
To check if migration is completed, run the following script:
For Linux: a) sh validateMigration.sh
For Windows: a) validateMigration.cmd
Note:
Before performing the next steps, use the create_hrlcore_indexes.sql file to create indexes. The file can be found under the directory where the <install_dir>/ohim_hrl_installer/addons/recordlocator/oracle_db/rls_oracle_db_scripts.zip file is extracted.Also, ensure that steps 11 and 12 are executed during production system downtime.
Execute the following command to store the latest deprecated DocumentEntry IDs to a file:
For Linux: a) sh runStoreLatestDeprecatedDocIdsToFile.sh
For Windows: a) runStoreLatestDeprecatedDocIdsToFile.cmd
This command produces a file, LatestDeprecatedDocEntryUUIDs.txt that will be used as input in the next step.
Execute the following command to update the DocumentEntry status to L:
For Linux: a) sh runUpdateLatestDeprecatedDocEntryStatus.sh
For Windows: a) runUpdateLatestDeprecatedDocEntryStatus.cmd
Perform the following steps to terminate the ongoing migration process:
Navigate to the migration directory and execute the following command:
> cd migration
Open the polledFile.txt file in a text editor and change the file content to stop.
Press Enter and save the file.
The application polls the polledFile.txt file every two minutes to check if it is changed. If it determines the entered text is stop, the migration activity is terminated and the application is closed.
Note:
The stop and resume functionalities will work only for runAllRegObjsMetadataMigration.sh (runAllRegObjsMetadataMigration.cmd) and runAllRegObjsStatusUpdate.sh (runAllRegObjsStatusUpdate.cmd) commands.Perform the following steps to resume the migration process:
Navigate to the migration directory and execute the following command:
> cd migration.
Open the polledFile.txt file in a text editor and change the file content to resume.
Press Enter and save the file.
The tool determines the count of successfully processed records from the SuccessfulTransactions_*.txt file, skips these records in DocumentEntryUUIDs.txt, HasMemberAssocUUIDs.txt, OtherAssocUUIDs.txt, FolderUUIDs.txt, SubmissionSetUUIDs.txt, and LatestDeprecatedDocEntryUUIDs.txt, and continues to process the remaining records.
Note:
The stop and resume functionalities will work only for runAllRegObjsMetadataMigration.sh (runAllRegObjsMetadataMigration.cmd) and runAllRegObjsStatusUpdate.sh (runAllRegObjsStatusUpdate.cmd) commands.The following are the commands used in the polledFile.txt file:
run followed by Enter. This string indicates that you can:
Execute the runStore*.sh scripts to get the registry objects IDs to file from the database.
Execute the run*Migration.sh or runUpdate*.sh scripts to perform the actual data migration or registry objects status synchronization that rely on the IDs in the file that was created in the previous step.
stop followed by Enter.
This string instructs the application to stop as soon as possible after committing currently migrated objects and not proceeding further to complete the migration of the remaining objects from the input file.
resume followed by Enter.
This string indicates that application will continue processing the metadata migration of registry objects from where it was stopped.
If required, back up config/xconfig.xml and codes/codes.xml files. These files are located in the <WebLogic_Home>/user_projects/domains/<domain_name>/config/hrl/ or <GlassFish_Home>/domains/<domain_name>/config/hrl/ directory.
If you are planning to use the existing WebLogic Server 11g Release 1 (10.3.6.0) instance where you installed the 2.0.2.1 HRL, perform the following:
Undeploy Enterprise Application, hrlapp.
If required, back up JDBC and JMS resource configurations.
The installer re-creates these resources in the application server.
Remove the following resources if they exist from the application server instance
JDBC Data Sources for rls-adt-pool, rls-log-pool, rls-registry-pool, and rls-dsub-pool
JMS Module XLoggerJmsSystemResource
JMS Server XLoggerJMSServer
If required, back up conifg/xconfig.xml and codes/codes.xml files.
These files are located in the <WebLogic_Home>/user_projects/domains/<domain_name>/config/hrl.
If optional components Document Metadata Subscription (DSUB) and XAD-PID Change Management (XPID) are installed, undeploy Enterprise Applications NotificationBroker and xpid.
Execute the following commands by connecting to hrlcore user:
> sqlplus hrlcore ... Enter password:<password>
SQL>ALTER TABLE DOC_ENTRY RENAME COLUMN SOUCE_PATIENT_ID TO SOURCE_PATIENT_ID;
SQL>CREATE TABLE REFERENCE_ID_LIST_DE ( DOC_ID VARCHAR2(64) NOT NULL, PATIENT_ID VARCHAR2(256) NOT NULL, SEQUENCEID NUMBER(4) NOT NULL, VALUE VARCHAR2(256) NOT NULL );
SQL>ALTER TABLE REFERENCE_ID_LIST_DE ADD CONSTRAINT REFERENCE_ID_LIST_DE_PK PRIMARY KEY (DOC_ID, SEQUENCEID);
Perform the following steps to install OHIM HRL:
Extract the installer file.
Copy or download the file ohim_hrl_installer.tgz to where you want to install HRL.
Extract the contents of the file either by using the unzip utility or the following command:
$ tar -zxvf ohim_hrl_installer.tgz
Note:
If you have existing Record Locator database schemas, follow steps in Section 2.1.2 and Section 2.2.2, and skip rest of the section. For a fresh installation, follow the instructions below.For using SQL scripts with SQL Plus in the Windows environment, refer to Section 2.4.2.
To configure Oracle database to be used with Health Record Locator, perform the following steps:
Copy the file from <install_dir>/ohim_hrl_installer/addons/recordlocator/oracle_db/rls_oracle_db_scripts.zip to the host where the SQL Plus client present in the PATH and Bash or Sh shell is available. Unzip the contents.
Log in to the host having SQL Plus and change the directory to where you have copied or extracted the files in step 1.
Update the SQL script create_tblspc_users.sql with your Oracle DB specific Tablespace information. Also, update scripts createadtddl.sql, createlogddl.sql, createhrlcoreddl.sql, and create_hrlcore_indexes.sql based on your environments and requirements. Consider recommendations in Section 2.9.7 while updating these scripts.
Ensure that SQL Plus is available in the PATH, then run the script create_tblspc_users.sh as follows:
> bash create_tblspc_users.sh
When, prompted, enter information for registry database host, SID or Service Name, port, admin user ID, password, ADT user password, HRLCORE user password and log user password.
To configure Oracle database to be used with Health Record Locator, perform the following steps:
Copy the file from <install_dir>/ohim_hrl_installer/addons/recordlocator/oracle_db/rls_oracle_db_scripts.zip to the host where you have a SQL Plus client is present in the path.
Log in to the host where you copied rls_oracle_db_scripts.zip and extract its contents.
Change the directory to the path where you extracted the files in step 2.
Update create_tblspc_users.sql with the Oracle DB specific Tablespace information and new passwords for the users ADT (&adtpswd), HRLCORE (&hrlcorepswd), and LOG (&logpswd). Also, update scripts createadtddl.sql, createlogddl.sql, createhrlcoreddl.sql, and create_hrlcore_indexes.sql based on your environments and requirements. Consider recommendations in Section 2.9.7 while updating these scripts.
Through SQL Plus, use admin or an ID in the Oracle DB with access to create table spaces and users to execute create_tblspc_users.sql.
Execute the following scripts through SQL Plus using the IDs created in step 5.
createadtddl.sql using ADT createlogddl.sql using LOG createhrlcoreddl.sql using HRLCORE create_hrlcore_indexes.sql using HRLCORE
After creating schemas successfully, remove create_tblspc_users.sql.
To configure Oracle database to be used with DSUB optional component, perform the following steps:
Copy the file from <install_dir>/ohim_hrl__ installer/addons/recordlocator/dsub/oracle_db/dsub_oracle_db_scripts.zip to the host where the SQL Plus client present in the PATH and Bash or Sh shell is available. Unzip the contents.
Log in to the host having SQL Plus and change the directory where you have copied or extracted the files as mentioned in step 1.
Update the SQL script create_tblspc_users.sql with your Oracle database-specific Tablespace information.
Ensure that SQL Plus is available in the PATH, then run the script create_tblspc_users.sh as follows:
> bash create_tblspc_users.sh
When prompted, enter information for registry database host, SID or Service Name, port, admin user ID, password, and DSUB user password.
To configure Oracle database to be used with DSUB optional component, perform the following steps:
Copy the file from <install_dir>/ohim_hrl__ installer/addons/recordlocator/dsub/oracle_db/dsub_oracle_db_scripts.zip to the host where the SQL Plus client is present in the path.
Log in to the host where you copied dsub_oracle_db_scripts.zip and extract its contents.
Change the directory to the path where you extracted the files in step 2.
Update create_tblspc_users.sql with the Oracle database-specific Tablespace information and new passwords for the user dsub (&dsubpswd).
Through SQL Plus, use admin or an ID in the Oracle database with access to create table spaces and users to execute create_tblspc_users.sql.
Execute the following script through SQL Plus using the IDs created in step 5:
createdsubddl.sql using dsub
After creating schemas successfully, remove create_tblspc_users.sql.
To configure Oracle database to be used with XPID optional component, perform the following steps:
Copy the file from <install_dir>/ohim_hrl__ installer/addons/recordlocator/xpid/oracle_db/xpid_oracle_db_scripts.zip to the host where the SQL Plus client is present in the PATH and Bash or Sh shell is available. Unzip the contents.
Log in to the host having SQL Plus and change the directory where you have copied or extracted the files in step 1.
Update the SQL script create_tblspc_users.sql with your Oracle database-specific Tablespace information.
Ensure that SQL Plus is available in the PATH, then run the script create_tblspc_users.sh as follows:
> bash create_tblspc_users.sh
When prompted, enter information for registry database host, SID or Service Name, port, admin user ID, password, and XPID user password.
To configure Oracle Database to be used with XPID optional component, perform the following steps:
Copy the file from <install_dir>/ohim_hrl__ installer/addons/recordlocator/xpid/oracle_db/xpid_oracle_db_scripts.zip to the host where the SQL Plus client is present in the path.
Log in to the host where you copied dsub_oracle_db_scripts.zip and extract its contents.
Change the directory to the path where you extracted the files in step 2.
Update create_tblspc_users.sql with the Oracle database-specific Tablespace information and new passwords for the user xpid (&xpidpswd).
Through SQL Plus, use admin or an ID in the Oracle database with access to create table spaces and users to execute create_tblspc_users.sql.
Execute the following script through SQL Plus using the IDs created in step 5:
createxpidddl.sql using xpid
After creating schemas successfully, remove create_tblspc_users.sql.
In OHIM HRL 3.0, the HRL supports DSUB and XPID transactions. Each XPID server and DSUB Notification Broker is implemented in separate optionally deployable components. Core HRL component is required for both DSUB and XPID support.
The XPID component must be deployed on the same application server instance as the core HRL component. However, the DSUB Notification Broker can be deployed either on the same application server instance as core HRL component or on a separate one. DSUB Publisher is part of the core HRL component and can be enabled through the configuration parameter.
This section describes how to run the HRL installer. When the installer prompts, select recordlocator to install core HRL component, dsub for DSUB Notification Broker, and xpid for XPID HL7v2 server.
Execute the following commands:
$cd <install_dir>/ohim_hrl_installer $java -jar ohim_hrl_installer.jar
To follow prompts, refer to Appendix A.
The configuration file is located under config/hrl/config directory of the Application Server domain directory.
WebLogic:
<Weblogic_Middleware_Home>/user_projects/domains/<domain_name>/config/hrl/config/xconfig.xml
Restart the application server for xconfig.xml changes to take effect.
The following is the structure of the xconfig.xml file where, some configuration properties are specified under HomeCommunity and Registry elements.
<?xml version="1.0" encoding="utf-8"?>
<Config>
<HomeCommunity name="home">
<Property name="propName1">propVal1</Property>
...
</HomeCommunity>
<Registry name="localregistry">
<Property name="propName2">propVal2</Property>
...
</Registry>
</Config>
To enable sending ATNA UDP or TLS messages, edit the value of the following properties under HomeCommunity element and specify ATNA UDP or TLS server details:
ATNAPerformAudit: Set this value to true to enable sending ATNA audit messages. By default, this value is set to false.
ATNAsyslogProtocol: Set this value to UDP or TLS (default value).
ATNAsyslogHost: Specify the ATNA UDP or TLS server host name or IP address.
ATNAsyslogPort: Specify the ATNA UDP or TLS server port number.
ATNAMessageType: Set this value to RFC3881 or DICOM. This property indicates what audit message format should be generated by the system.
Ensure to configure the following properties when you use TLS for ATNAsyslogProtocol:
KeyStore: Enter the file path of the keystore. For example, /home/common/cert/keystore.jks.
KeyStoreType: Specify the type of the keystore. By default, the value is set to JKS.
TrustStore: Enter the file path of the truststore. For example, /home/common/cert/keystore.jks.
TrustStoreType: Specify the type of the truststore. By default, the value is set to JKS.
CredentialStore: Enter the directory where Oracle wallet is created. For example, /home/common.
For configuring KeyStore and TrustStore passwords, see Section 2.13.
ValidatePatientId: Set this value to true (default value) to validate known patient IDs before registering DocumentEntry.
XMLSchemaValidationEnabled: Set this value to true (default value) to schema validate incoming messages.
LogEnabled: Set this value to true (default value) to enable logging registry request and response messages in Log schema tables.
Note:
This parameter is different from enabling ATNA audit log messages.ReceiverDeviceId: Set this value to construct response messages in HL7v2 services.
ReceiverDeviceName: Set this value to construct response messages in HL7v2 services. By default, this value is set to ORACLE_HIA_RLS_XDSbRegistry.
AcceptPIDOnlyFrom: Set this property to let registry accept patient feed only from the specified domain. Comment or delete this property to let registry accept patient feed from all domain.
MaxLeafObjectsAllowedFromQuery: Specify an integer value that determines the maximum number of document entries returned with Registry Stored Query response messages. By default, this value is set to 25.
Note:
This property is applicable only when query request contains return type valueLeafClass.TrimLogQueueMessages: Set this value to true (default value) to trim the messages logged in log schema tables.
MaxLeafObjectsPerLogQueueMsg: Specifies the maximum number of Leaf objects to be logged per message.
MaxObjectRefsPerLogQueueMsg: Specifies the maximum value of Object references to be logged per message.
ValidateCodeDisplayName: Set this value to true to let HRL validate the code display names in the registry metadata of the request against the codes.xml file. By default, this value is set to false.
ValidateDocEntryURISlotValue: Set this value to true to let HRL validate the URI slot value in the document metadata of the request. By default, this value is set to false.
AffinityDomainPIDAssigningAuthorityID: Set this property to let registry append the Assigning Authority ID to the received Patient ID, which does not have this value. After updating the configured Assigning Authority Id value, the registry persists the Patient ID in the database.
By default, this property is commented. To let HRL employ the above specified behavior, uncomment this property.
The format of this property value is: &OIDOfAssigningAuthorityID&ISO
For example:
<Property name="AffinityDomainPIDAssigningAuthorityID"> &1.3.6.1.4.1.21367.2005.3.7&ISO</Property>
AllowDuplicateUniqueIdInSubmission: Set this value to true to let HRL duplicate unique IDs in a submission. By default, this value is set to false.
NotificationEnabled: Set this value to true to enable publishing registry events to the DSUB Notification Broker. By default, this value is set to false.
PublishEndPoint: Specify the publish endpoint URL of the DSUB Notification Broker.
DsubValidateCodeAndCodingScheme: Set this value to true (default value) to validate code and coding scheme containing DSUB subscription message against codes file of the registry.
DefaultDaysBeforeExpiryOfSubscription: Enter an integer value that indicates the number of days after which the subscription will expire. By default, this value is set to 30.
NotificationBrokerSubscribeEndPoint: Specify the Subscribe endpoint URL of the DSUB Notification Broker.
DeleteExpiredSubscriptionsIntervalDuration: It indicates the number of milliseconds between successive invocations of the batch job to delete expired subscriptions (if any) from the database. Enter an integer value specifying milliseconds interval. The default value is 86400000 (1 day).
DeleteExpiredSubscriptionsTimerStartInterval: It indicates the duration in milliseconds after the receipt of the first subscribe request to the Notification Broker. The batch job to delete the expired records becomes active at this point. Enter an integer value specifying milliseconds interval. The default value is 86400000 (1 day).
xpid.classification.scheme: Content type classification coding scheme. This scheme should be present in the codes file.
xpid.classification.code: Content type code for the coding scheme. This code should be present in the codes file.
XPID server related configuration are stored in <domain_name>/config/hrl/ xpid.properties. The following is the description of properties in this file:
RLS_IHE_HL7V2_HOME: Path to directory where XPID server files are extracted.
RLS_IHE_HL7V2_URL: URL of XPID HL7v2 service.
Perform the following steps to configure Log4j:
Set the JVM system property log4j.configuration pointing to the log4j.properties file.
For example,
-Dlog4j.configuration=file:<AppServer_domain_config_dir>/hrl/config/log4j.properties
In WebLogic application server, set the JVM system property log4j.configuration. The following is an example of one of the ways to set the property. For details, refer to WebLogic Administration Guide.
For example,
If you are deploying HRL to AdminServer, edit the <WL_domain>/bin/startWebLogic.sh. Change the below line from
SAVE_JAVA_OPTIONS="${JAVA_OPTIONS}"
to
SAVE_JAVA_OPTIONS="${JAVA_OPTIONS} -Dlog4j.configuration=file:<AppServer_domain_config_dir>/hrl/config/log4j.properties"
If you are deploying HRL to Managed WebLogic Server, edit the <WL_domain>/bin/startManagedWebLogic.sh. Change the following line from
JAVA_OPTIONS="${JAVA_OPTIONS}"
to
JAVA_OPTIONS="${JAVA_OPTIONS} -
Dlog4j.configuration=file:<AppServer_domain_config
dir>/hrl/config/log4j.properties"
Before staring the application server, verify and update log4j.properties to contain proper log level and log file paths. Replace the string ${com.sun.aas.instanceRoot} with ${user.dir}.
The following are the recommendations and optional configuration:
Oracle recommends partitioning the tables under HRLCORE schema for scaling with large volume of data. It is recommended to hash partition tables on PATIENT_ID column where this column exists. For ASSOCIATION_HM and ASSOCIATION_OTH tables, you may want to hash partition on ID column.
Oracle recommends you to use Oracle database secure file and compression to store CLOB data and reduce the storage size without impacting the performance significantly.
Although returning sorted document IDs in the Find Document query is supported, the provided script does not create indexes to optimize this query type to save disk space. If you use this feature, you must create composite index(es) on DOC_ENTRY with keys PATIENT_ID, ID, and sort attribute.
Since this release enables DocumentEntry XML fragments to be stored in CLOB columns, improving CLOB data read performance between the database and application server improves overall Registry query performance, especially where the response type is LeafClass. Oracle 11.2 JDBC driver lets you increase default LOB prefetch size from 4k. You can configure this parameter through a JVM option.
For example,
-Doracle.jdbc.defaultLobPrefetchSize=32000
The codes file is located under config/hrl/codes directory of the application server domain directory.
WebLogic:
<Weblogic_Middleware_Home>/user_projects/domains/<domain_name>/config/hrl/codes/codes.xml
You can update these files with new codes as applicable. Restart the application server for new codes to take effect.
Use the endpoints in Table 2-1 to configure XDS.b Document Repository, Document Consumer as needed.
Table 2-1 Record Locator Transactions and Web Service URLs
| Transaction | Sync | Async | Endpoint URL |
|---|---|---|---|
|
Register Document Set-b[ITI-42] |
Yes |
Yes |
http(s)://<HRL_HOST>:<PORT>/hrl/regsvc |
|
Registry Stored Query[ITI-18] |
Yes |
Yes |
http(s)://<HRL_HOST>:<PORT>/hrl/regsvc |
|
Patient Identity Feed(HL7 V3)[ITI-44] |
Yes |
Yes |
http(s)://<HRL_HOST>:<PORT>/hrl/regsvc |
|
Multi Patient Query[ITI-51] |
Yes |
Yes |
http(s)://<HRL_HOST>:<PORT>/hrl/regmpqsvc |
|
Metadata Update - Update[ITI-57] |
Yes |
Yes |
http(s)://<HRL_HOST>:<PORT>/hrl/regupdsvc |
|
Metadata Update - Delete[ITI-62] |
Yes |
Yes |
http(s)://<HRL_HOST>:<PORT>/hrl/regupdsvc |
Use the endpoints in Table 2-2 to configure your Document Metadata publisher and subscribers as needed.
Table 2-2 DSUB Transactions and Endpoint URLs
| Transaction | Endpoint URL |
|---|---|
|
Document Metadata Publish[ITI-54] |
http(s)://<DSUB_HOST>:<PORT>/WS-BrokeredNotificationPubl ish_Service/Publish |
|
Document Metadata Subscribe[ITI-52] |
http(s)://<DSUB_HOST>:<PORT>/WS-BrokeredNotificationSubscribe_Service/Subscribe |
|
Document Metadata Unsubscribe[ITI-52] |
http(s)://<DSUB_HOST>:<PORT>/WS-BrokeredNotificationUnSubscribe_Service/Unsubscribe?subscriptionId=<UUID> <UUID> should be a valid value as assigned by DSUB Notification Broker. |
HRL requires certificates to be loaded into Keystore and Truststore of WebLogic Sever or Managed WebLogic Server for TLS communication with Web Service client.
For configuring Identity and Trust for WebLogic Server or Managed WebLogic Server, follow the steps provided in http://docs.oracle.com/middleware/1212/wls/SECMG/identity_trust.htm#SECMG367.
Enable SSL to secure communication between client and HRL application. For configuring the SSL, follow the steps provided in http://docs.oracle.com/middleware/1212/wls/SECMG/ssl.htm#i1194343.
Under Advanced section of SSL configuration, perform the following:
Set Hostname Verification to None.
Enable Use Server Certs.
Set the Two Way Client Cert Behavior option to Client Certs Requested and Enforced.
Restart the WebLogic Server or Managed WebLogic Server after configuring the Keystore and Truststore values.
To send audit messages using TLS protocol, perform the following steps:
Navigate to the audit-oss directory using the following steps:
Execute the following command:
> cd <install_dir>/ohim_hrl_installer/addons/recordlocator
Extract the contents of the audit-oss-bin.tar.gz file by executing the following command:
> tar -zxvf audit-oss-bin.tar.gz
Execute the following command:
> cd audit-oss
Execute the following command. When prompted, enter the values for the wallet output directory, wallet password, keystore password, and truststore password. Ensure that you provide the correct passwords.
> sh setupCredentialStoreForATNA.sh
Configure the following properties in the <WebLogic_Home>/user_projects/domains/<domain_name>/config/hrl/config/xconfig.xml file:
<Property name="KeyStore">/home/common/cert/keystore.jks</Property>
<Property name="KeyStoreType">JKS</Property>
<Property name="TrustStore">/home/common/cert/keystore.jks </Property>
<Property name="TrustStoreType">JKS</Property>
<Property name="CredentialStore">/home/common</Property>
Restart the WebLogic Server or Managed WebLogic Server after configuring the preceding properties.
|
 Copyright © 2012, 2015, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|