...

This document describes the steps to install and deploy the v1.8+ i2b2 Web Client under Apache.

Anchor
_v7dtrus4lox2 _v7dtrus4lox2

INTRODUCTION TO I2B2

Anchor
_tidzvniw93u1 _tidzvniw93u1

Usage

The Informatics for Integrating Biology & the Bedside ("i2b2") project i2b2 Web Client is an easy to use data query and retrieval platform that is used by researchers to perform searches on electronic health records. This is done using a simple drag-and-drop interaction whereas where users browse (or search) a list of medical diagnoses and then drag those terms into various areas of a query builder window. The general layout is shown below:

On the upper left is the "Terms" window which contains search terms. On the upper right is the "Find Patients" window which is used to build the query. Also on the upper right is the "Analysis Tools" window which displays a list of plugins (both new and legacy) that a user can access by clicking on the title. This "Analysis Tools" window is where you go to access your plugin in development.

...

In general, i2b2 is designed to operate using a services-oriented architecture. An i2b2 "hive" is a collection of services called "cells". The primary i2b2 services are: PM / Project Management which manages projects/users in the hive, ONT / Ontology which stores all the terms that are used to select patients, CRC / Clinical Research Chart which is the central repository of patient data within the hive, WORK / Workplace which allows users to store information for later use. On the server, each one of these cells exposes their services through a different URL. Because of this the i2b2 web client requires the use of a proxy service to overcome the "same-origin" security restrictions that exist within all web browsers. This means that users of the i2b2 web client access the web client when it is hosted on a web server which also has some kind of proxy service capability, connecting the in-browser code to the i2b2 hive of services.

Anchor
_52j3c58b0474 _52j3c58b0474

WEB CLIENT HOSTING VIA APACHE

...

To edit the whitelist when the web client is hosted in Apache you will need to edit the values within the proxy.php file. At the top of the file will be a PHP variable called $WHITELIST which will contain an array of URLs. You will need to enter the protocol, hostname and port (if any) for all i2b2 hive services that the web client will need access to. You can see an example of a proper whitelist configuration below:

Anchor
_ohr8jvvt7ibi _ohr8jvvt7ibi

$WHITELIST = array(

...

In the PHP proxy service file (proxy.php) you will also have the ability to set blacklist entries. These entries will prevent proxying of any requests whose URLs begin with any of the values listed in the $BLACKLIST variable. You can see an example of a proper blacklist configuration below:

Anchor
_cjz2b4nghhbx _cjz2b4nghhbx

$BLACKLIST = array(

...

It is possible for you in Apache to run a security check against the Project Manager for each i2b2 request. These options are within the proxy.php file as follows:
$pmURL = "http://127.0.0.1:8080/i2b2/rest/PMService/getServices";
$pmCheckAllRequests = true;
The $pmURL variable should be set to the URL used to validate the security credentials in the request before it is forwarded on to the requested cell service. It usually ends in "/getServices".
The $pmCheckAllRequests variable is used to turn on or turn off the extra per-request security check. It is a boolean value and should be set to true or false only.

Anchor
_vsirl66huujr _vsirl66huujr

SAML AUTHENTICATION

...

In addition to configuring the web server and proxy service you will need to configure the i2b2 domain instance within the web client. Once again, all i2b2 domains are configured within the i2b2_config_domains.json file. Specifically you will need to add a "saml" object within the SAML-enabled domain entry. Within the saml object will be another object named with the name of the SAML-enabled service (for example "shibboleth" as shown below). When you are using the NodeJS-based proxy server you can set the value of the object to true or null. When hosting your web client deployment under Apache you will need to specify the URLs for the redirect and logout services within the saml object. Example configurations are as follows:
{
"urlProxy": "/proxy.php",
"urlFramework": "js-i2b2/",
"lstDomains"

: \[

{
"domain": "i2b2demo",
"name": "Shibboleth (localhost)",
"urlCellPM": "http://127.0.0.1/i2b2/services/PMService/",
"allowAnalysis": true,
"debug": false,
"saml" : {
"shibboleth": {
"redirect": "saml-redirect.php",
"logout": "saml-logout.php"
}
}
}
]
}

...

When the i2b2 web client is loaded into a web browser it loads the configuration file i2b2_config_domains.js located in the root of the hosting directory. This file contains (among other things discussed below) an entry called urlProxy that configures the URL that the web client will use to access the proxy service to communicate with the i2b2 hive. By default the is configured for self-hosting using the NodeJS i2b2-webclient-proxy server. To host the web client under Apache you will need to change this from the default as shown below:.
For hosting via NodeJS
{
"urlProxy": "/~proxy",
"urlFramework": "js-i2b2/",
"lstDomains"

: \[

...]
}

For hosting via Apache + PHP
{
"urlProxy": "/proxy.php",
"urlFramework": "js-i2b2/",
"lstDomains"

: \[

...]
}

...

All configurations to connect to i2b2 servers are stored within the configuration file i2b2_config_domains.js and are contained within the lstDomains array. By default a connection to the demonstration server at http://services.i2b2.org is configured for testing purposes and is shown below:
{
"urlProxy": "/proxy.php",
"urlFramework": "js-i2b2/",
"lstDomains"

{*}{_}: \[_*

{
"domain": "i2b2demo",
"name": "i2b2.org Demo",
"urlCellPM": "http://services.i2b2.org/i2b2/services/PMService/",
"allowAnalysis": true,
"debug": false
},
{...},
{...},
]
}
The domain value contains the domain name that is configured within an i2b2 instance.
The name value contains the text that is displayed in the login window for the user to identify the instance.
The urlCellPM value contains the URL that is used to contact the i2b2 server which contains the configured domain. The hostname of the server must also be added to the whitelist configuration used by the proxy service. See the related whitelist documentation in the NodeJS/Apache Hosting section.
The allowAnalysis boolean value configures whether a user will be able to use analysis plugins when logged into the i2b2 domain.
The debug boolean value configures whether the user will be able to use debugging tools when logged in. This value is deprecated and will be removed in the future.

...

For plugins to operate properly when hosted by Apache you will need to manually edit a file called plugins.json that exists within the root /plugins directory containing an array of plugin names as shown below.

*\[*

"edu.harvard.catalyst.example",
"edu.harvard.WeberLab.ExportPatientset"
]
If you are using the i2b2-webclient-proxy service to host your web client UI it will automatically generate the plugins.json file based on the directory structure if the file does not exist (not manually created). The Github repository for this proxy server is at _https://github.com/hms-dbmi/i2b2-webclient-proxy_

...

Just like in the legacy web client, any plugins that are added must have an entry within the i2b2_loader.js file that is in the root of the execution environment. This file would be located at /js-i2b2/cells/LEGACYPLUGIN/legacy_plugin/js-i2b2/i2b2_loader.js with an example listing of the configuration lines shown below:
//==========================================================================//
// THESE ARE ALL THE CELLS THAT ARE INSTALLED ONTO THE SERVER
i2b2.hive.tempCellsList

= \[

{ code: "PM", ...},
{ code: "ONT", ...},
{ code: "CRC", ...},
{ code: "WORK", ...},
{ code: "PLUGINMGR", ...},
{ code: "Dem1Set",
forceLoading: true,
forceConfigMsg: { params

{*}: \[\] \},*

roles

{*}: \[*

"DATA_LDS", "DATA_DEID", "DATA_PROT" ],
forceDir: "cells/plugins/standard"
},
{ code: "ExportXLS",
forceLoading: true,
forceConfigMsg: { params

{*}: \[\] \},*

roles

{*}: \[*

"DATA_LDS", "DATA_DEID", "DATA_PROT" ],
forceDir: "cells/plugins/community"
}
];
//==========================================================================//
Each plugin will have a configuration object within the defined i2b2.hive.tempCellsList array variable. The meaning of the configuration object's attributes is as follows:
The code attribute is the name of the plugin as well as the name of the directory containing the plugin's code and assets.
The forceLoading attribute notifies the legacy i2b2 plugin execution environment that the plugin should be loaded upon environment creation. For the plugin to work correctly this must be set to true.
The forceConfigMsg attribute contains configuration information that is passed to the plugin. It is an object which must contain an array named params.
The roles attribute contains the roles which can use the plugin. The rolls are as follows: DATA_OBFSC for Obfuscated, DATA_AGG for Aggregated, DATA_LDS for Limited Data Set, DATA_DEID for De-identified Data, DATA_PROT for Protected.
The forceDir attribute points to the parent directory that the plugin's directory exists within.

Anchor
_g870cp37imp _g870cp37imp

MODIFYING OF LOGIN SCREEN

...