Versions Compared

Old Version 6

changes.mady.by.user Keith Dwyer

Saved on

compared with

New Version Current

changes.mady.by.user David Walend

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Depending on your site's current status, not all of these steps will be necessary to follow. For example, you may skip the first major i2b2 section of these instructions if i2b2 1.7.05 is already installed. However, all users should read through and follow the SHRINE 1.19.2 section of the instructions.

The end result , however, is that you will need all of these pieces of software (i2b2, SHRINE, SHRINE Data Steward) installed and upgraded to their indicated version.

...

These instructions are based on the instructions in the general Upgrading SHRINE to 1.22.8 (from 1.20-1.21) article. You will need to follow all the instructions provided in order to upgrade to SHRINE 1.19.2 and to properly configure the new SHRINE Data Steward. If you have previously installed SHRINE 1.19.1, you will need to follow these instructions. If you have not yet installed the SHRINE Data Steward, you will need to follow these instructions.

...

Next, download the upgrade script from the SHRINE installer and run it.

$ wget https--no-check-certificate https://open.med.harvard.edu/svn/shrine/releases/1.19.2/code/install/i2b2-1.7/shrine/upgrade_tomcat.sh
$ chmod +x upgrade_tomcat.sh
$ ./upgrade_tomcat.sh

The script should cleanly replace an existing Tomcat 6 installation with Tomcat 7, generating a new server.xml (based on tomcat7_server.xml) in the process. If you are already on Tomcat 7 (or newer), the script will exit and do nothing.

Deploy New shrine.war

Next, we will retrieve the new SHRINE webapp from the HMS Sonatype Nexus server at http://repo.open.med.harvard.edu/nexus/content/groups/public/net/shrine/shrine-war/. Navigate to the folder for 1.19.2. From there, download the shrine-war-1.19.2.war file to the webapps directory on the SHRINE server and rename it to shrine.war.

For example:

...

If Tomcat fails to start, check /opt/shrine/tomcat/logs/catalina.out. An error like this may appear in catalina.out, especially if you are using OpenJDK:

java.lang.ClassNotFoundException: org.apache.catalina.mbeans.ServerLifecycleListener

If this appears, comment out the following line in /opt/shrine/tomcat/

...

conf/server.xml:

<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>

Deploy New shrine.war

Next, we will retrieve the new SHRINE webapp from

Deploy New steward.war

Much like shrine.war, the SHRINE Data Steward can be found on the HMS Sonatype Nexus server at http://repo.open.med.harvard.edu/nexus/content/groups/public/net/shrine/stewardshrine-war/. Navigate to the folder for 1.19.2. From there, download the stewardshrine-war-1.19.2.war file to the webapps directory on the SHRINE server and rename it to stewardshrine.war.

For example:

$ cd /opt/shrine/tomcat/webapps
$ wget https--no-check-certificate http://repo.open.med.harvard.edu/nexus/content/groups/public/net/shrine/stewardshrine-war/1.19.2/stewardshrine-war-1.19.2.war -O stewardshrine.war

Deploy New

...

steward.war

Much like shrine.war

...

Like other SHRINE artifacts, the SHRINE proxy Data Steward can be found on the HMS Sonatype Nexus server at httpshttp://repo.open.med.harvard.edu/nexus/content/groups/public/net/shrine/shrine-proxysteward/. Navigate to the folder for 1.19.2. From there, download the shrinesteward-proxy-1.19.2.war file to the webapps directory on the SHRINE server and rename it to shrine-proxysteward.war.

For example:

$ cd /opt/shrine/tomcat/webapps
$ wget --no-check-certificate https://repo.open.med.harvard.edu/nexus/content/groups/public/net/shrine/shrine-proxysteward/1.19.2/shrinesteward-proxy-1.19.2.war -O shrine-proxysteward.war

Deploy New

...

shrine-proxy.war

Like other SHRINE artifacts and steward.war, the SHRINE webclient is retrieved from the releases folder of the HMS Subversion repository proxy can be found on the HMS Sonatype Nexus server at https://repo.open.med.harvard.edu/svnnexus/content/groups/public/net/shrine/releasesshrine-proxy/.  The webclient is found at Navigate to the folder for 1.19.2/code/shrine-webclient. Checkout or export this folder to /opt/shrine/tomcat/webapps. From there, download the shrine-proxy-1.19.2.war to the webapps directory on the SHRINE server and rename it to shrine-proxy.war.

For example:

$ cd /opt/shrine/tomcat/webapps
$ svn export wget --no-check-certificate https://repo.open.med.harvard.edu/svnnexus/content/groups/public/net/shrine/releasesshrine-proxy/1.19.2/code/shrine-webclient/

Restore Webclient Backups

After this, restore the previous i2b2_config_data.js and cell_config_data.js files from your backup and place them in the new shrine-webclient folder:

...

/shrine-proxy-1.19.2.war -O shrine-proxy.war

Deploy New SHRINE Webclient

Unlike shrine.war and steward.war, the SHRINE webclient is retrieved from the releases folder of the HMS Subversion repository at https://open.med.harvard.edu/svn/shrine/releases/. The webclient is found at 1.19.2/code/shrine-webclient. Checkout or export this folder to /opt/shrine/tomcat/webapps

...

.

For example:

$ cpcd /opt/shrine/upgrade-backups/shrine-webclient/js-i2b2/cells/SHRINE/cell_config_data.js /opt/shrine/tomcat/webappstomcat/webapps
$ svn export https://open.med.harvard.edu/svn/shrine/releases/1.19.2/code/shrine-webclient/js-i2b2/cells/SHRINE/

Restore Webclient Backups

After this, restore the previous i2b2_config_data.js and cell_config_data.js

...

files from your backup and place them in the new shrine-webclient folder:

$ cp /opt/shrine/upgrade-backups/shrine-webclient/i2b2_config_data.js /opt/shrine/tomcat/webapps/shrine-webclient/i2b2_config_data.js
$ cp /opt/shrine/upgrade-backups/shrine-webclient/js-i2b2/cells/SHRINE/cell_config_data.js /opt/shrine/tomcat/webapps/shrine-webclient/js-i2b2/cells/SHRINE/cell_config_data.js

Configure the SHRINE Data Steward

Database - i2b2

The SHRINE Data Steward is typically backed by the i2b2 PM cell used by SHRINE. From the steward application's point of view, all users on the SHRINE project are considered Researchers (except for the Steward and QEP users!). However, there is some additional work that has to be done to the i2b2 user list to accommodate the SHRINE Data Steward.

QEP User

The Steward application requires set of user credentials that the application will use to submit queries through to

Configure the SHRINE Data Steward

Database - i2b2

The SHRINE Data Steward is typically backed by the i2b2 PM cell used by SHRINE. From the steward application's point of view, all users on the SHRINE project are considered Researchers. However, there is some additional work that has to be done to the i2b2 user list to accommodate the SHRINE Data Steward.

QEP User

The Steward application requires set of user credentials that it will use to submit queries through to SHRINE. It is recommended that this be a dedicated system user separate from any other account. Additionally, it will need to have the parameter "qep" defined (name: qep, value: true, type: text), which can be set in the Manage Users section of the i2b2 Admin Panel. Make sure to add this user to the SHRINE project in the i2b2 Admin Panel as well.

In In shrine.conf, make sure there is a shrineSteward block in the queryEntryPoint section, and that the qepUserName and qepPassword properties match the user with the qep parameter.

...

In Steward application deployments that require manual involve topic approval, a trusted human user will have to be given permission to review proposed research topics and approve/reject them. To mark a user as such, add the "DataSteward" parameter (name: DataSteward, value: true, type: text) to that user in the Manage Users section of the i2b2 Admin Panel.

Database - Steward

The SHRINE Data Steward application uses a separate database to store its logging information, similar to how the core SHRINE application keeps its own query log.

This step should be handled by install-steward-only.sh, but instructions to manually perform it can be found below:

 Make sure to add this user to the SHRINE project in the i2b2 Admin Panel as well.

Note that this user is meant solely to monitor and review, and thus cannot create its own query topics! If you are both a steward and a researcher, you will need to create two separate i2b2 users.

All Other Users (Researchers)

NOTE: The current SHRINE Data Steward webclient transforms usernames to all-lowercase! As such, any i2b2 usernames that use both uppercase and lowercase letters will not be able to use the SHRINE Data Steward properly. Please make sure any users that intend to use SHRINE have a username with all lowercase letters. We apologize for any inconvenience this may cause.

Database - Steward

The SHRINE Data Steward application uses a separate database to store its logging information, similar to how the core SHRINE application keeps its own query log.

This step should be handled by install-steward-only.sh, but instructions to manually perform it can be found below:

  1. Create a database (typically stored in MySQL alongside the existing shrine_query_history database, but this is just a suggestion). The installer by default calls it stewardDB.
  2. Grant a shrine/steward-specific user full access to this database. The installer by default uses the same credentials as it does for the SHRINE query history database, but you are welcome to (and encouraged to!) change this.
  3. Run the appropriate schema script included with the steward application
    1. For MySQL, this is https://open.med.harvard.edu/svn/shrine/releases/1.19.2/code/steward/src/main/sql/mysql.ddl
    2. For SQL Server, this is https://open.med.harvard.edu/svn/shrine/releases/1.19.2/code/steward/src/main/sql/
  4. Create a database (typically stored in MySQL alongside the existing shrine_query_history database, but this is just a suggestion). The installer by default calls it stewardDB.
  5. Grant a shrine/steward-specific user full access to this database. The installer by default uses the same credentials as it does for the SHRINE query history database, but you are welcome to (and encouraged to!) change this.
  6. Run the appropriate schema script included with the steward application
    1. For MySQL, this is https://open.med.harvard.edu/svn/shrine/releases/1.19.2/code/steward/src/main/sql/mysql.ddl
    2. For SQL Server, this is https://open.med.harvard.edu/svn/shrine/releases/1.19.2/code/steward/src/main/sql/sqlserver.ddl

steward.conf - Application config

  1. Start with a sample steward.conf from the installer: https://open.med.harvard.edu/svn/shrine/releases/1.19.2/code/install/i2b2-1.7/shrine/skel/steward.conf
    1. If using the JDBC driver (for example, SQL Server users), make sure slickProfileClassName is set to "scala.slick.driver.JdbcDriver$" (mind the lowercase "dbc"!)
  2. Substitute the following variables with their appropriate value. (see common.rc and shrine.rc for reference, as well as the listing of configuration variables in the installer)
    1. SHRINE_ADAPTER_I2B2_DOMAIN
    2. SHRINE_STEWARD_DB_NAME
    3. I2B2_PM_IP
    4. KEYSTORE_FILE
    5. KEYSTORE_PASSWORD
    6. KEYSTORE_ALIAS
  3. Save this file to /opt/shrine/tomcat/lib/steward.conf

Make sure that the keystore{} block in steward.conf exactly matches the keystore{} block in shrine.conf!

An important An important setting in steward.conf which should be manually set by a site administrator is createTopicsMode. By default, this is set to "Pending", which means that topic requests submitted in the Data Steward application will have to be manually approved by a user with DataSteward privileges.

...

In webapps/shrine-webclient/js-i2b2/cells/SHRINE/cell_config_data.js, make sure newTopicURL is and readApprovedURL are set to something like the following:

      newTopicURL: "https://your.hostname.here:6443/steward/client/index.html#/topics"

Make the following change in webapps/shrine-webclient/i2b2_config_data.js:

    isSHRINE: true

The above may already be present in i2b2_config_data.js, but commented out. (there may be a /* on the previous line) If so, uncomment it. If isSHRINE is not already present, add it to the main entry in lstDomains.

shrine.conf Changes

SHRINE Data Steward Integration

, /* this URL should be accessible from the client */
    readApprovedURL:"https://your.hostname.here:6443/shrine/rest/i2b2/request" /* this URL should be accessible from the SHRINE server */

Make the following change in webapps/shrine-webclient/i2b2_config_data.js:

    isSHRINE: true

The above may already be present in i2b2_config_data.js, but commented out. (there may be a /* on the previous line, as well as a */ or // on the "isSHRINE" line) If so, uncomment it. If isSHRINE is not already present, add it to the main entry in lstDomains.

shrine.conf Changes

SHRINE Data Steward Integration

In order to make SHRINE aware of the steward, you will need to change the authorizationType value In order to make SHRINE aware of the steward, you will need to change the authorizationType value and add the following shrineSteward block to the queryEntryPoint block of shrine.conf:

...

<versionInfo>
  <shrineVersion>1.19.2</shrineVersion>
  <ontologyVersion>UNKNOWN</ontologyVersion>
  <adapterMappingsVersion>Unknown</adapterMappingsVersion>
  <scmRevision>(not available)</scmRevision>
  <scmBranch>UNKNOWN_BRANCH</scmBranch>
  <buildDate>2015-06-30 18:03:57</buildDate>
</versionInfo>

Creating a Query Topic

Upon logging in to the SHRINE webclient for the first time after installation of the SHRINE Data Steward, the user should see a new dropdown list and button at the bottom of the query construction panel. This is where a user sets which query topic will be associated with their query when it enters the SHRINE system. If no topic is selected, then query execution will fail.

Initially, a user will not have any approved query topics, so they must first click on the "Request New Topic" button, which will take them to the SHRINE Data Steward webclient. Log in using the same set of credentials used to log in to the SHRINE webclient, and request a new topic from there. On this network, all query topics are automatically approved. After creating a query topic, log out and back in to the SHRINE webclient, and the recently-created topic should be available in the dropdown list at the bottom of the query construction panel.

SHRINE operation continues as normal from this point onward.

Verify SHRINE Data Steward Query Logging

After creating a query topic and logging back in to the SHRINE webclient, try selecting a topic and executing a query. The query should come back with a list of sites and patient counts (or issues) as usual. After this, verify that the SHRINE Data Steward is also logging these queries.

Check the SHRINE Data Steward client (either click on Request New Topic or go to https://your.host.here:6443/steward/client/), log in with the user you ran the query as, and then check the Query History section of the client. If you need help navigating the application, check the Help file in the upper right (also available at https://your.host.here:6443/steward/client/src/assets/img/SHRINE-Data-Steward-Help.pdf)

The recently-executed query should show up in that list, with the same query name that was entered in the SHRINE webclient. If it does not show up, verify that your configuration settings for both the SHRINE Data Steward as well as SHRINE itself match the values suggested in this documentation.