CRIMSON: Sample Management in i2b2 Dr. Lynn Bry Oct 2010

Sample handling in i2b2 1. Mechanism for a source LIMS (Crimson, caTissue, other..) to broadcast sample data into i2b2. –Webservice or tool to load data (flat file) from the source LIMS. –Available for query in the i2b2 Query Tool 2. Forward i2b2 cohorts to a source LIMS. –Initiate prospective collection –Interrogate retrospective repositories –Requires that the source LIMS can receive/process the cohort, or an adapter is available to facilitate communication. Project materials posted to i2b2crimson.partners.org

Workflows i2b2 Crimson Cohort Prospective Sample Collection IRB LIMS i2b2 EMSI Reg Cell Sample List IRB User Query Sample Request List Reg Cell Interrogate a retrospective repository (place request or generate sample list for other purposes) Prospective Collection Retrospective Sample Collections User Query

Regulatory Subject Cohort Management Sample Registry CRIMSON Apiary

Scalability & Extensibility Managing PHI Information – Honest Broker Development, Deployment & Maintenance Reusing Existing i2b2 Functionality Issues, Challenges & Discussion Points

Scalability & Extensibility Queen Cell Drone Cell A crimson queen (parent) cell cannot directly contact an external system, instead it uses proxy or drone cells which act as the conduit to one of those systems. A drone cell is ‘hive active’ and can invoke services exposed by its queen cell. Drone cells are typically restricted to operating within the firewall. Each drone consists of a set of queen cell specific web service interfaces and a second part, customized to perform a specific function Worker Cell A worker cell is ‘hive passive’. Every worker cell for a specific queen cell exposes the same web services which can only be invoked by its queen. As with the drone cell, it also consists of a second part, customized to perform a specific function.

LIMS System exports samples as a tabular text file on an FTP Server for collection and import into i2b2. Scalability & Extensibility - Example Part A – Sample Registry Worker Cell Web Services Update Worker Cell Properties Including Data Encryption Keys Fetch List of New Sample Batches To Import Update Local Sample Metadata Ontology Purge / Delete Sample Batches Part B – Custom Code Fetch Files From FTP Site File Parser Schedular

Managing PHI Information – Honest Broker Data Transfer –i2b2 Project to External LIMS –External LIMS/Repository to Sample Registry –Sample Registry to i2b2 Project De-Identifying

Development, Deployment & Maintenance Single WAR File JERSEY REST Frame Work Crimson Data Object –Loosely based on Common Data Element: ISO/IEC Standard for Metadata RegistriesISO/IEC Standard for Metadata Registries

Reusing Existing i2b2 Functionality Storing Sample Data Using Ontology/Workplace Cell Searching For Samples Using Existing i2b2 Query GUI Track patient participation and sample reuse across projects

Find Patients Associated With a Parent Sample Find Patients With Samples Associated With a Collection Event

Find Patients Who Have Withdrawn From a Study Find Patients Who Have A DNA Sample

Time Line Release 1.0 –Alpha: End Oct 2010 –Beta: March 2011 –RC1: May 2011

Final Question Will sites use a single i2b2 instance to support multiple project- specific CRCs, or support each datamart on a standalone i2b2 instance? Parent CRC (identified or de-ID) -> Child datamart/CRC (de-ID). For prospective sample collection or maintenance of coded links to child datamarts - where would the cohort map be retained? Master CRC PM Cell ONT Cell Child1 CRC Child2 CRC Master CRC PM Cell ONT Cell Child1 CRC PM Cell ONT Cell VS.

Master CRC PM Cell ONT Cell Child1 CRC Child2 CRC EMSI If on one i2b2 instance, maintain cohort maps in the MasterCRC PATIENT_MAP table (need an extra column to list project CRC where the project PATIENT_NUM/“subjectID” is valid). OR - maintain the map in the EMSI Master CRC PM Cell ONT Cell Child CRC PM Cell ONT Cell EMSI Source LIMS Potentially more cumbersome to implement and maintain..