Search on this blog

Search on this blog

View Categories

Data Exporter (v 1.8.2)

16 min read

Overview #

The Data Exporter functionality enables an i2b2 user to create a data table definition and request patient data for a desired cohort. First, a table of variables is designed using create data table for export tool. The defined data tables are then displayed under the Data Request(s) breakdown types that can be selected in the Run Query dialog, After the query run, the Manager user can view and manage the data requests under the Data Request Manager tool. i2b2 Users will be able to view their data requests  status and details .  An e-mail is generated for the Data Manager when the request is submitted. The Data Manager processes the request by generating the data file under the Data Request Manager tool. The patient data is exported as a file and stored in a specified location for retrieval, and the user is notified by e-mail.

The patient data file  is generated as per the data table definition design specification

Data Export Workflow

Data Table Creation – User process #

The Create Data Table for export feature allows User to design a table of variables of interest using the Design table feature. The table design can then be saved as a template  that can be loaded and used to request data export.

Design Table #

The DESIGN TABLE panel allows i2b2 User to create a data table definition with list of variables of interest.

  1. User logs into the web client and accesses create data table for export tool under the Tools plugin

  2. The DESIGN TABLE panel displays list of predefined variables that will be included by default in the data export file. These predefined variables are (by default) Gender, Age, Race

  3. From the Ontology Terms tab, drag and drop additional variables of interest onto the DESIGN TABLE grid. These variables will be added as a list of variables included in the data export. The predefined variables are locked and cannot be unchecked since they are required for every data table.  Other variables can be deleted under Actions column to exclude them from the data file.

  4. Aggregation method for the variable can be applied by clicking on the drop down box in the Aggregation Method column to assign aggregate options to each variable 

Aggregate Options #

The availability of aggregation options depends on the type of concept it aggregates on.

Example:

  • Aggregation options for a non-numeric variable such as Diagnosis are Existence (Yes/No), Count: Number of Concepts, Count: Number of Dates, Count Number of Encounters, Count Number of Facts, Count Number of Providers, Date (First), Date (Most Recent), Most Frequent Concept (Codes)

  • Aggregation options for concepts that support numeric values such as labs include Average, Min, Max, etc. in addition to all the functions available to normal variables

Aggregation Options

Explanation

Existence (Yes/No)

Whether the patient has an observation of this concept. This is the default option.

Count: Number of Concepts

Total number of concepts

Count: Number of Dates

Total number of dates for the participant

Count: Number of Encounters

Total number of encounters for the participant

Count: Number of Facts

Total number of observations

Count: Number of Providers

Total number of providers for the participant

Date: First Date

Date of earliest observation

Date: Last Date

Date of the most recent observation

Calc: First Value

Minimum value of all numeric values observations

Calc: Last Value

Maximum value of all numeric values observations

Calc: Number of Values

Total numbe of all numeric values observations

Calc: Average Value

Average value of all numeric values observations

Calc: Minimum Value

Lowest value of all numeric values observations

Calc: Maximum Value

Highest value of all numeric values observations

Calc: Median Value

Median value of all numeric values observations

Preview Table #

Table Design can be previewed to get a preview of the data export file that will be generated.

  1. User clicks on PREVIEW TABLE to verify the variables added are displayed in the data columns in the format desired.

Design and Preview is an interactive, iterative process where User can add and remove variables as well as assign or edit Aggregate options

Save Table #

  1. Click on Save
  2. The table definition can be either saved under MY TABLES or PROJECT SHARED TABLES

MY TABLES are editable and will appear as Run Query options only for the current user

PROJECT SHARED TABLES are editable and will appear as Run Query options for any user in the current i2b2 project

SYSTEM SHARED TABLES is editable only for Admins and are templates for i2b2 users’ tables

Load Table #

Load table definition enables the User to Load a saved table definition 

  1. User clicks on Load menu option to display Load Table Definition with  list of user saved definitions
  2. Select desired table definition and clicks on LOAD button

Data file definitions from Load Table definitions can be further refined and saved 

Data Request – User process #

Request 1.8.2 data exports  #

  1. User logs into web client and creates a query.
  2. In the Run Query dialog box, User created table definitions are displayed under Data Request(s) section
  3. Select one or more data request checkboxes.
    1. 1.8.2 requests (custom tables) appear as  User Created:
      checkboxes
    2. 1.8.1 data requests (long fact-oriented tables) appear as Request Data checkboxes.
    3. 4. Click run query 

      5. An email is automatically sent to the data manager to inform them of a new data request.

      6. The table definition name with the FINISHED status is displayed as one of the breakdown items in the previous query results.

      Data Request Manager  #

      User’s Data Requests List #

      User-submitted data requests (both 1.8.2 and 1.8.1) are logged under the Data Request Manager tool.

      1. Click on Tools=> Data Request Manager plugin

      The Data Request Manager displays  data requests along with their status and details

      For non-managers, only the user’s data requests are displayed under the Request Data Manager.

      View Data Request Details #

      2. Click on View Details

      View Details displays the Request details  and Request status as well as other options 

      • Query Name (Click on Query ID number to display the previous query in the Find Patients window)
      • Data Table Definition (Click on View under Data Request Type drop down Request item)
      • Option to Withdraw Request 
      • Option to enter Comments
      • Log info box displays the User’s actions. and log of the Request status

      Data Export – Manager process #

      The User-created data requests are managed by the Data Manager using the Data Request Manager tool. 

      Data Request Manager  #

      Data Requests List #

      1. Click on Tools=> Data Request Manager plugin.

      List of User submitted data requests are displayed . The initial status of the requests is Submitted. 

      The Manager User can view the details of the Requests using VIEW DETAILS button and generate the Data files using Create File(s) button)

      View Data Request Details #

      Click on View Details. 

      The View Details panel is similar in display  for non-Manager user, except the Manager User can change the Data Request Status..

      The Log info box displays the status of the Data Request as well as the Data File creation status.

      Create Data File(s) #

      Click on Create File(s) on the Data Request Manager page

      The data export runs in the background and the file is generated in a specified folder defined in the HIVE_CELL_PARAMS (see Configuration below). Data file generation status is displayed under the Status column under Data Request Manager

      Status is updated as the data file is processed, from Submitted to File in Progress to File Available. When the file is available, an e-mail notification may be sent to the site’s configured Data Request Email Address (for example, a data manager or project mailbox), depending on local configuration. The process for giving the user access to the file is site-specific.

      Example Export files (all data are fake)

      Two files are generated for each data table exported. 

      Definition file: has the variable names and data types for the data file

      Data file: has the values for the variables

      User-created Demographics #

      Definition file

      Example:1969_Definition_For_Demographics_8_5_25.csv

      TABLE_INSTANCE_ID TABLE_INSTANCE_NAME USER_ID GROUP_ID SET_INDEX C_FACTTABLECOLUMN C_TABLENAME COLUMN_NAME C_FULLPATH C_COLUMNNAME C_COLUMNDATATYPE C_OPERATOR C_DIMCODE AGG_TYPE CONSTRAIN_BY_DATE_TO CONSTRAIN_BY_DATE_FROM CONSTRAIN_BY_VALUE_OPERATOR CONSTRAIN_BY_VALUE_CONSTRAINT CONSTRAIN_BY_VALUE_UNIT_OF_MEASURE CONSTRAIN_BY_VALUE_TYPE CREATE_DATE
      7 DEM_6_27 demoManager SQLServerLarge 0 sex_cd patient_dimension Gender @ @ @ @ @ Value 37:14.3
      7 DEM_6_27 demoManager SQLServerLarge 1 age_in_years_num patient_dimension Age @ @ @ @ @ Value 37:14.3
      7 DEM_6_27 demoManager SQLServerLarge 2 race_cd patient_dimension Race @ @ @ @ @ Value 37:14.3
      7 DEM_6_27 demoManager SQLServerLarge 3 patient_num patient_dimension (children) < 18 years old \ACT_DEMOACTDemographicsAge< 18 years old birth_date N > dateadd(YY, -18, GETDATE())  Exists 37:14.3

Data file

Example: 1969_Demographics_8_5_25_08052025.csv

patient_num Gender Age Race (children) < 18 years old 75-84 years old >= 65 years old
26 M 72 @ No Yes Yes
53 F 55 WHITE No No No
87 F 59 WHITE No No No
92 F 88 DECLINED No No Yes
94 F 67 ASIAN No No Yes
153 M 77 @ No Yes Yes

User-created Labs #

Definition file

Example: 2282_Definition_For_LAB_TESTS_HUGEPT_AGGOPTIONS

TABLE_INSTANCE_ID TABLE_INSTANCE_NAME USER_ID GROUP_ID SET_INDEX C_FACTTABLECOLUMN C_TABLENAME COLUMN_NAME C_FULLPATH C_COLUMNNAME C_COLUMNDATATYPE C_OPERATOR C_DIMCODE AGG_TYPE CONSTRAIN_BY_DATE_TO CONSTRAIN_BY_DATE_FROM CONSTRAIN_BY_VALUE_OPERATOR CONSTRAIN_BY_VALUE_CONSTRAINT CONSTRAIN_BY_VALUE_UNIT_OF_MEASURE CONSTRAIN_BY_VALUE_TYPE CREATE_DATE
310 LAB_TESTS_HUGEPT_AGGOPTIONS act NODE9 0 sex_cd patient_dimension Gender @ @ @ @ @ Value 25:57.3
310 LAB_TESTS_HUGEPT_AGGOPTIONS act NODE9 1 age_in_years_num patient_dimension Age @ @ @ @ @ Value 25:57.3
310 LAB_TESTS_HUGEPT_AGGOPTIONS act NODE9 2 race_cd patient_dimension Race @ @ @ @ @ Value 25:57.3
310 LAB_TESTS_HUGEPT_AGGOPTIONS act NODE9 3 race_cd patient_dimension Ethnicity @ @ @ @ @ Value 25:57.3
310 LAB_TESTS_HUGEPT_AGGOPTIONS act NODE9 4 concept_cd concept_dimension Cholesterol (Group:CHOL) \i2b2_LABSi2b2LabtestsLAB(LLB16) Chemistry(LLB17) Lipid TestsCHOL concept_path N like i2b2LabtestsLAB(LLB16) Chemistry(LLB17) Lipid TestsCHOL NumFacts 25:57.3

Data file

Example: 2282_LAB_TESTS_HUGEPT_AGGOPTIONS_08122025

patient_num Gender Age Race Ethnicity Cholesterol (Group:CHOL)
9 M 49 white white 1
89 F 57 white white 1
13 F 53 white white 1
21 F 72 white white 7
77 F 80 white white 1

Data Export Configuration #

Data file format/location and Email parameters set-up #

HIVE_CELL_PARAMS #

The generated Data file format, location and email server parameters are configurable in the HIVE_CELL_PARAMS. 

Wildfly must be restarted for changes to the HIVE_CELL_PARAMs to take effect.

Cell ID Parameter Name Example Value Notes
CRC edu.harvard.i2b2.crc.smtp.host smtp.partners.org SMTP host
CRC edu.harvard.i2b2.crc.smtp.port 25 SMTP port
CRC edu.harvard.i2b2.crc.smtp.ssl.enabled FALSE TRUE will enable SSL
CRC edu.harvard.i2b2.crc.smtp.auth FALSE TRUE will enable SMTP authentication
CRC edu.harvard.i2b2.crc.smtp.username none SMTP username (required for SMTP authentication)
CRC edu.harvard.i2b2.crc.smtp.password none SMTP password (required for SMTP authentication)
CRC edu.harvard.i2b2.crc.smtp.enabled FALSE TRUE will enable e-mails
CRC edu.harvard.i2b2.crc.exportcsv.defaultescapecharacter Escape character for export files
CRC edu.harvard.i2b2.crc.exportcsv.maxfetchrows -1 Maximum number of rows to export, or -1 for no limit
CRC edu.harvard.i2b2.crc.exportcsv.defaultlineend n Line ending for export files
CRC edu.harvard.i2b2.crc.exportcsv.defaultseperator t Field separator for export files
CRC edu.harvard.i2b2.crc.exportcsv.resultfetchsize 50000 Number of records retrieved during each database fetch.
CRC edu.harvard.i2b2.crc.exportcsv.filename {{{PROJECT_ID}}}/{{{DATE_yyyyMMdd}}}_{{{FULL_NAME}}}.tsv Parameterized template for export file names. If the extension is .zip, the file is zipped.
CRC edu.harvard.i2b2.crc.exportcsv.defaultquotechar Quote character for export files
CRC edu.harvard.i2b2.crc.exportcsv.workfolder /tmp/i2b2 Folder on the i2b2 server for data exports
CRC edu.harvard.i2b2.crc.exportcsv.zipencryptmethod none Encryption method for the exported ZIP file. One of STANDARD, NONE, or AES.

PM_PROJECT_PARAMS #

The parameters for the emails sent to the project’s Data Manager about a data request and to the requesting user when export is complete are set on a per-project basis.

Parameter Name Example Value Notes
Data Request Template This user {{{USER_NAME}}} in project {{{PROJECT_ID}}} requested ...

Template text for the body of the request notification email. This email is sent to the site’s configured Data Request Email Address. Supports template variables.

Data Request Email Address someone@somewhere.org

Email address that receives the data export notifications. This is typically a data manager or project mailbox.

Data Request Letter "Results of the i2b2 request entitled - '{{{QUERY_NAME}}}', ..."

Template text for the export-completion notification email body, to be sent to the configured Data Request Email Address (not directly to the requesting user). Supports variables like {{{QUERY_NAME}}}.

Data Request Subject i2b2 Data Request

Subject line used for both the request notification email and the export-completion notification email.

Template Substitution Variables #

Variable Description Example / Source
{{{USER_NAME}}} Display name or username of the requester Jon Smith
{{{FULL_NAME}}} The full legal name of the requester Jonathan Smith
{{{QUERY_STARTDATE}}} Timestamp when the query was submitted 2025-09-19
{{{QUERY_ENDDATE}}} Timestamp when the file was generated 03/11/2026, 4:47 PM
{{{QUERY_NAME}}} Name/title of the query executed Hypertension Adults
{{{QUERY_MASTER_ID}}} Internal i2b2 Query Master ID 5412
{{{QUERY_INSTANCE_ID}}} Internal i2b2 Query Instance ID 7721
{{{PROJECT_ID}}} i2b2 project ID (e.g., ACT, DEMO) ACT
{{{PATIENT_COUNT}}} Number of patients/records returned 1999
{{{RESULT_INSTANCE_ID}}} Specific ID for the result instance 99432

Design and Architecture #

The i2b2 breakdown architecture is modified to support the data table definition and new breakdown types for User created data requests. The database tables have been modified to support the data table definitions.

  • RPDO_TABLE_REQUEST table stores the data table definitions
  • HIVE_CELL_PARAMS has new parameters for global and email configurations and the data file generation location (defaults to the server’s drive)
  • PM_PROJECT_PARAMS has new parameters for e-mail notifications of data export
  • QT_RESULT_TYPE table will contain a new entry for each data table definition
  • QT_BREAKDOWN_PATH will contain a new entry for each data table definition which has the data export execution details.
  • QT_XML_RESULT contains metadata about each data request, such as status and e-mail details.  

User Roles and Actions #

User visibility to Data Table Creation, Data Request and Data Export is based on User role configuration. Configuration is managed by the Admin user using Admin Dashboard plugin.

Below is the list of Actions available based on the User role. 

User Role Create Data Table Data Request Data Request Manager View Details Data Export/Generate Data file  Change Request Status
Obfuscated
Aggregate
Protected Enabled Enabled Enabled
LDS Enabled Enabled Enabled
Manager/No LDS Enabled Enabled Enabled
Manager/LDS Enabled Enabled Enabled Enabled Enabled
Admin Enabled Enabled Enabled Enabled Enabled

Database Configuration changes #

RPDO_TABLE_REQUEST #

In order to support the data Table design, a new table RPDO_TABLE_REQUEST is added.  The metadata in Data Table design is stored in the table when the data Table is saved.

Three default rows are initially loaded into the RPDO_TABLE_REQUEST, defining patient_dimension columns which are required in every export table. These are:  race_cd, age_in_years_num, and sex_cd

QT_BREAKDOWN_PATH #

QT_Breakdown_Path table has been modified to include a new column Group_id. It stores the Project ID, in order to support project-scoped data table definitions.

Column Name Data Type
Group_Id Varchar (50)

Database updates- Data table definition creation #

The database is dynamically modified when the user creates the data table definition or submits a data request 

RPDO_TABLE_REQUEST  #

Rows for the data table design are dynamically inserted in the RPDO_TABLE_REQUEST when a data table is saved.  

RPDO_TABLE_REQUEST PARAMETERS DATA TABLE Values
TABLE_REQUEST_ID

auto generated incremental value, corresponding to each concept in the data table. Unique for each concept

example: 1282,1283, 1284

TABLE_INSTANCE_ID

unique for each Data table ( same value for all the concepts underneath)

example: 17

TABLE_INSTANCE_NAME Data table definition name
USER_ID data request user
GROUP_ID project id
SET_INDEX auto incremented for each concept row for the table instance
C_FACTTABLECOLUMN “concept_cd” for the fact table or “patient_num” for the patient_dimension
C_TABLENAME corresponds to table storing concept_cd/patient_num( concept_dimension or patient_dimension )
COLUMN_NAME The column name of the data table definition
C_FULLPATH corresponds to the concept’s c_fullname in the ontology table
C_COLUMNNAME usually “concept_path” for concept_dimension
C_COLUMNDATATYPE corresponds to ontology table  column value
C_OPERATOR corresponds to ontology table  column value
C_DIMCODE corresponds to ontology table  column value
AGG_TYPE corresponds to Aggregate option selection in data table definition
CONSTRAIN_BY_DATE_TO corresponds to date constraint option selection in data table definition
CONSTRAIN_BY_DATE_FROM corresponds to date constraint option selection in data table definition
CONSTRAIN_BY_VALUE_OPERATOR corresponds to set value constraint selection in data table definition
CONSTRAIN_BY_VALUE_CONSTRAINT corresponds to set value constraint selection in data table definition
CONSTRAIN_BY_VALUE_UNIT_OF_MEASURE corresponds to set value constraint selection in data table definition
CONSTRAIN_BY_VALUE_TYPE corresponds to set value constraint selection in data table definition
SHARED Y (for project and system shared table definitions); N (User table definition)
DELETE_FLAG Y (if deleted) or N 
C_VISUALATTRIBUTES values are LA  or LH  (based on visibility table definitions in the panel)
REQUIRED Y for default variables ( race, age, sex); N for other variables
JSON_DATA

logs the table definition variables details needed for the  execution of the stored procedure to create the data file

GENERATED_SQL logs the SQL query that is generated by stored procedure call  for each variable
DELETE_DATE date of table definition deletion
CREATE_DATE date of table definition creation
UPDATE_DATE date table last updated
USE_AS_COHORT N by default; not used currently

Example:

#

QT_QUERY_RESULT_TYPE #

The data table is logged as a breakdown type  in the QT_QUERY_RESULT_TYPE table when the user saves the data table definition.

RESULT_TYPE_ID NAME DESCRIPTION DISPLAYTYPE_ID VISUAL_ATTRIBUTE_TYPE_ID USER_ROLE_CD CLASSNAME

Auto generated number

example : 144

RPDO_

example: RPDO_17

User-created Request CATNUM

LU (User tables)

LP (Project shared tables)

DATA_LDS edu.harvard.i2b2.crc.dao.setfinder.QueryResultPatientRequest

Example:

We recommend data requests be limited to DATA_LDS users and data exports be limited to MANAGER users. The user role determines if exports/requests are visible and runnable. Refer to section on User Roles and Actions

QT_BREAKDOWN_PATH  #

A new row is also added here when the user saves the data table definition. 

  • Name column references the  Table_instance_id when the user saves the table_definition. 
  • Value column contains the command to run the stored procedure that generates the data file.
  • Group_id has the project ID
  • The result_instance_id parameter gets the numeric value from the QUERY_RESULT_INSTANCE for the patientset (result_type_id =1) when the export file is created.

Example:

NAME VALUE Group_id

RPDO_

Example: RPDO_17

EXEC i2b2synthea8.dbo.usp_rpdo2 @TABLE_INSTANCE_ID= @RESULT_INSTANCE_ID={{{RESULT_INSTANCE_ID}}} @MIN_ROW=0 @MAX_ROW=10000

SQLServerLarge

Example:

Database updates- Data request submission #

1.8.2 requests #

QT_QUERY_RESULT_INSTANCE #

When the User runs a query with User created Data Request breakdown option selected, a row is logged in the QT_Query_Result_Instance for the  result_type_id generated in the QT_RESULT TYPE

Column Name Value (Example)
Result_Type_ id 144
Result_instance_id 1729

Example:

QT_BREAKDOWN_PATH  #

The EXEC statement in Value column is updated with value for table_instance_id

Example:

NAME VALUE

RPDO_

Example: RPDO_144

EXEC i2b2synthea8.dbo.usp_rpdo2 @TABLE_INSTANCE_ID=17 @RESULT_INSTANCE_ID={{{RESULT_INSTANCE_ID}}},@MIN_ROW=0 @MAX_ROW=99999999

{{{RESULT_INSTANCE_ID}}} gets replaced with QT_QUERY_RESULT_INSTANCE.Result_instance_id  as the stored-procedure in the back-end gets executed.

at the time of data file creation.

QT_XML_RESULT #

A row is logged for the result_instance_id of the data request submitted at the time of query run. Metadata about data request queries are stored in the QT_XML_RESULT table, in the XML_VALUE field. The metadata  gets updated as the data export process is completed (from data request submission to data file creation)

Column Name  Value (example)
Result_Instance_Id 1729
XML_Value  
http://www.i2b2.org/xsd/cell/crc/psm/analysisdefinition/1.1/” xmlns:ns5=”http://www.i2b2.org/xsd/hive/msg/1.1/” xmlns:ns8=”http://www.i2b2.org/xsd/cell/pm/1.1/” xmlns:ns7=”http://www.i2b2.org/xsd/cell/crc/psm/querydefinition/1.1/” xmlns:ns9=”http://www.i2b2.org/xsd/cell/ont/1.1/” xmlns:ns10=”http://www.i2b2.org/xsd/hive/msg/result/1.1/” xmlns:ns2=”http://www.i2b2.org/xsd/hive/pdo/1.1/” xmlns:ns4=”http://www.i2b2.org/xsd/cell/crc/psm/1.1/” xmlns:ns3=”http://www.i2b2.org/xsd/cell/crc/pdo/1.1/“>
   
       
            20250808_125429
            rmetta@mgb.org
            20250808_125631
            20250808_125631
            /opt/dataexport/SQLServerLarge/724
            20250808_125633
            demoManager
       

   

Example:

#

 

1.8.1 Requests #

3 new default rows are logged in RPDO_TABLE_REQUEST when user runs a query and submits 1.8.1 data request for the first time . This will enable the 1.8.1 requests to be displayed on data request Manager panel along with 1.8.2 requests. Subsequent requests utilize the same default rows for display.

RPDO_TABLE_REQUEST #

QT_QUERY_RESULT_TYPE #

A row is logged in QT_RESULT_TYPE for the default table definition. Subsequent data request submissions utilize the same row for the  default rows result_type_id

QT_RESULT_INSTANCE #

A row is logged in the QT_Query_Result_Instance for the  same  result_type_id generated in the QT_RESULT TYPE every time user submits a request

QT_XML_RESULT #

A row is logged for the result_instance_id of the data request submitted at the time of query run. Metadata about data request queries(including user email address) are stored in the QT_XML_RESULT table, in the XML_VALUE field. The metadata  gets updated as the data export process is completed (from data request submission to data file creation) 

Data file creation #

1.8.2 Data file creation #

CREATE FILES(s)  executes usp_rpdo2 stored procedure in the back end by calling the EXEC statement in QT_BREAKDOWN_PATH to create the data file.

  • The select statement in the VALUE column is executed to create the data file The result_instance_id value of the query is inserted  dynamically  each time of data file is created for the same table_instance_id. and does not store in the QT_BREAKDOWN_PATH 

1.8.1 Data file creation #

CREATE FILES(s)  executes the .csv  in QT_BREAKDOWN_PATH.

  • The select statement in the VALUE column is executed for the default table data file creation. The result_instance_id value of the query is inserted  dynamically  each time of data file is created for the same table_instance_id. and does not store in the QT_BREAKDOWN_PATH 
  • The select statement in the VALUE column  of the .CSV for the data request is executed to create the data file. 

Currently,1.8.1 request submission send out one email per request selected to the User.  

Software Changes: #

  • Data: Entries in RPDO_TABLE_REQUEST, HIVE_CELL_PARAMS, PM_PROJECT_PARAMS, QT_QUERY_RESULT_TYPE, and QT_BREAKDOWN_PATH, QT_XML_RESULT define the data exporter functionality.
  • Java code: New breakdown classes and updates to existing java classes to support the data exporter functionality.