Release Date: April 27, 2018
Release 1.7.10 contains several new enhancements to the i2b2 kernel, many of which improve the security around signing into the i2b2 Web Client. We have included some Auditing features like logging all successful and attempted logins into the i2b2 Web Client or keeping a log of all the Admin functions performed with the Admin Module.
|
This release note applies to you if you are upgrading your i2b2 to 1.7.10 from and earlier 1.7.xx version of the i2b2 software. Please see the Upgrade Notes section for any information that is specific to the upgrade process.
If you are upgrading your i2b2 in a SHRINE network please read the information in the SHRINE Networks section before proceeding.
If you are installing a new instance of the i2b2 we recommend you refer to the i2b2 Installation Guide found on the i2b2 Community Wiki. This documentation will guide you through the entire installation process. If you run into issues or have questions you can reach out to the community by joining and emailing the google group called i2b2 Install Help.
WARNING Release 1.7.10 has not been tested within a SHRINE network. Therefore, i2b2 Release 1.7.10 should not be installed within a SHRINE network. It can be installed independently of SHRINE. However because it has not been tested with SHRINE we can not guarantee all of the new enhancements will continue to work correctly when implemented within a SHRINE environment. |
It is important when you upgrade your "i2b2 software" that you upgrade all the components that make up the software package. In release 1.7.10 the following i2b2 components contain changes and therefore must be upgraded when upgraded your i2b2 environment.
The i2b2 now provides two options for sites to update their i2b2 server.
Both are acceptable paths and depending on your sites needs will determine where you will go to obtain the zip file containing the appropriate software. The following table will guide you to the appropriate location.
Description | Where to find it | Requirements |
---|---|---|
Files to upgrade the i2b2 Database to 1.7.10 | i2b2 Web Site - software page | |
Files to upgrade the i2b2 Web Client to 1.7.10 | i2b2 Web Site - software page | |
Files to upgrade the i2b2 Server to 1.7.10 - Source code | i2b2 Web Site - software page | |
Files to upgrade the i2b2 Server to 1.7.10 - JAR files | Upgrade to latest version page on the Community Wiki | See Technical Details section on the i2b2 Upgrades page. |
Documentation | Where to find it | Website |
---|---|---|
Database changes included in this release | Database Changes | |
List of core changes included in this release | Change Summary - i2b2 Kernel (Core Software) | |
List of Web Client changes included in this release | Change Summary - i2b2 Web Client | |
Details about the new features | Details about New Features in Release 1.7.10 | |
Technical details and notes about upgrading the i2b2 server | Upgrade i2b2 page | i2b2 Community Wiki |
Upgrade Instructions (server) | Upgrade to latest version page (Instructions section) | i2b2 Community Wiki |
Core documentation - Technical doc for i2b2 cells | In the i2b2core-doc zip file located on the software page of the i2b2 website | i2b2 Website |
Release 1.7.10 involves a few changes to the i2b2 Database. Some are simple an addition to the sample data that is included in the demo data that is delivered with the software while others are changes to the database structure to support new features that are included in 1.7.10
QT_BREAKDOWN_PATH
QT_QUERY_RESULT_TYPE
PM_USER_LOGIN table
Additional information about each of these features can be found in the Details about New Features in Release 1.7.10 section located after the Change Summary section for the Web Client.
Additional information about each of these features can be found in the Details about New Features in Release 1.7.10 section located after this section.
For the purpose of these release notes the new features in the 1.7.10 release have been categorized into four categories.
As part of the Auditing improvements and overall security enhancements included in the 1.7.10 release all
The auditing improvements category contains two new features; with the first feature the i2b2 logs all attempts to sign into the i2b2 Web Client and the second one logs all activity within the i2b2 Admin module.
The auditing improvements are strictly server and database security enhancements to capture the information for auditing purposes. The audit information is logged in the PM_USER_LOGIN table for both features. Due to different security requirements on who can access this type of database information we have chosen to not include a way for i2b2 users to view or print the audit information from within the i2b2. This decision may be reviewed again for a future release. For now, if a site wants to obtain the logged information they can query their i2b2 database and retrieve the information directly from the PM_USER_LOGIN table. |
JIRA Issue: CORE-285
All successful and failed login attempts to sign into the i2b2 Web Client will be logged in the PM_USER_LOGIN table.
Sample data from PM_USER_LOGIN table
|
JIRA Issue: CORE-286
Functions performed within the Admin module will be logged within the PM_USER_LOGIN table.
ExampleFor the purpose of this documentation the basic steps an i2b2 Admin takes to add a new user are outlined below: Step 1: Signs into the i2b2 Web Client & selects the Administrator project Step 2: Selects Manager Users from the Navigation Panel Step 3: Clicks on the Add User button Step 4: Enters the information about the user and clicks on Save. Step 5: Clicks on Manage Users to refresh the list and display the new user.
As each steps was performed, the service and USER_ID was logged in the PM_USER_LOGIN table along with date & time.
|
The password management improvements is comprised of four new features that all revolve around improving the i2b2 security in regards to how users log into the i2b2 Web Client.
JIRA Issue: CORE-287
Accounts are locked and users are not able to sign into the i2b2 after a specific number of failed login attempts have been made.
Two new Global Parameters were created as part of the new lockout feature. These parameters must be defined in the PM_GLOBAL_PARAMS table for users to be locked out after the defined number of failed attempts and number of minutes they must wait before attempting to try again.
JIRA Issue: CORE-287
Require users to change passwords after a specified interval of time. The i2b2 Administrator controls the number of days allowed before a password must be changed. If a user attempts to sign on after their password has expired, the i2b2 Change Password window will open and the user must change their password before they can sign on.
The system uses the value in the global parameter to calculate the next expiration date and adds the appropriate user parameter to the table.
|
Two new parameters were created as part of the Mandatory password change feature. Both parameters are called PM_EXPIRED_PASSWORD however one is set within PM_GLOBAL_PARAMS and the other within PM_USER_PARAMS. Each parameter has a different function in the password expiration process and is further defined below.
The new Global Parameter called PM_EXPIRED_PASSWORD must be added to the PM_GLOBAL_PARAMS table to define the password change interval. Once this parameter has been set the mandatory password change feature will be turned on. If this parameter is not added as a global parameter then passwords will never expire.
The new User Parameter, PM_EXPIRED_PASSWORD, is automatically added to the PM_USER_PARAMS table the first time a user successfully changes their expired password. When they change their password, the system will look to the PM_EXPIRED_PASSWORD parameter in the PM_GLOBAL_PARAMS table to see the change interval defined and then calculate the new expiration date to add to the user parameter.
As soon as you add the PM_EXPIRED_PASSWORD to your PM_GLOBAL_PARAMS table, ALL passwords will expire except the i2b2 AGG_SERVICE_ACCOUNT. To prevent service accounts from expiring you need to add the user parameter as soon as the feature is turned on or even before it. Set the expiration date for a date in the distant future. The following steps outline how to do this.
|
Notice in the example provided above, the year was set to 3018. By manually setting the expiration date this far in the future will prevent the password from expiring and thus triggering the system to calculate the next expiration date and automatically update the user parameter. |
JIRA Issue: CORE-300
Prevent users from using their current password as their new password when required to change it.
JIRA Issue: CORE-288
Enforce complex passwords
Passwords must meet complexity requirements defined by the i2b2 Administrator. The requirements will be enforced when users change their passwords. They are not enforced when the i2b2 Administrator first enters their password from within the i2b2 Admin Module.
A new Global Parameter was created to support the Enforce Complex Passwords feature. The new parameter is set within PM_GLOBAL_PARAMS table and will define the password complexity requirements. Once the parameter has been entered the feature will be turned on and all users will be required to follow the new requirements the next time they change their password. The only exception is when the password is set by the i2b2 Administrator from within the i2b2 Admin Module.
Global Parameter: PM_COMPLEX_PASSWORD
Each requirement as an independent variable however they are concatenated and stored as a single "value" in the table.
When setting the parameter value for PM_COMPLEX_PASSWORD, each requirement is defined as an independent variable that is stored as a string in the VALUE column of the PM_GLOBAL_PARAMS table. The table shown below lists each of the variables and the associated requirement that will be enforced.
Variables | Requirement |
---|---|
(?=.*[0-9]) | Numbers (0-9) |
(?=.*[a-z]) | Lower case letters (a-z) |
(?=.*[A-Z]) | Upper case letters (A-Z) |
(?=.*[!@#$%^&+=]) | Special characters (!@#$%^&+=) |
(?=\S+$).{8,} | Password is a string and must be 8 characters |
The requirements can be used in any combination. If all the requirements in the table were to be used, the following would be entered as the Parameter Value:
(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#$%^&+=])(?=\S+$).{8,}
The (?=\S+$).{8,} variable is always required when setting the PM_COMPLEX_PASSWORD parameter. The system needs to know that password is a string and the length of password. You do have the option to change the length to be greater or lesser than 8 characters. |
Two new features are included in the query improvements category.
New breakdowns based on SQL Query
Can now have custom breakdowns based on SQL Query
Four examples provided with the i2b2 demo software
Length of stay breakdown
Top 20 medications breakdown
Top 20 diagnoses breakdown
Inpatient and outpatient breakdown
Example
Take a look at the Length of stay breakdown provided with the demo data.
SQL defined in QT_BREAKDOWN_PATH table
INSERT IMAGE of TABLE
SELECT length_of_stay AS patient_range, COUNT(DISTINCT a.PATIENT_num) AS patient_count FROM visit_dimension a, DX b WHERE a.patient_num = b.patient_num GROUP BY a.length_of_stay ORDER BY 1 |
Run a query for all diagnoses
JIRA Issue: WEBCLIENT-226
The i2b2 Admin module no longer needs to be setup on the i2b2 server and results in the following benefits.
To sign into the i2b2 Admin module, Administrators will go to the same location as their i2b2 Web Client and enter their login credentials. Provided their user is setup as an Admin they will be able to select "Administrator" from the list of projects in the project dialog. The Administrator project will launch the Admin module.
INSTALLATION INSTRUCTIONS
JIRA Issue: CORE-129
On certain occasions a database connection in a pool would go bad and the i2b2 would continue to use the connection which would cause errors in the i2b2. To resolve this problem database connections will now be validated and checked that the connection is valid. If a connection in the pool goes bad the i2b2 will not continue using it.
<validation> <validate-on-match>true</validate-on-match> <check-valid-connection-sql>SELECT 1 FROM DUAL</check-valid-connection-sql> <use-fast-fail>true</use-fast-fail> </validation> |