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
Prospective Collection
User
Query
Retrospective Sample Collections
i2b2
LIMS
Reg
Cell
IRB
IRB
Sample
List
Sample
Request
List
Cohort
EMSI
Crimson
Reg
Cell
i2b2
Prospective
Sample
Collection
User
Query
Interrogate a retrospective repository
(place request or generate sample list
for other purposes)
CRIMSON Apiary
Regulatory
Subject Cohort Management
Sample Registry
Issues, Challenges & Discussion Points
• Scalability & Extensibility
• Managing PHI Information – Honest Broker
• Development, Deployment & Maintenance
• Reusing Existing i2b2 Functionality
Scalability & Extensibility
Queen
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.
Drone
Cell
Worker
Cell
Each drone consists of a set of queen cell specific web
service interfaces and a second part, customized to
perform a specific function
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.
Scalability & Extensibility - Example
LIMS System exports samples as a tabular text file on an FTP Server
for collection and import into i2b2.
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
11179 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 projectspecific 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?
ONT
Cell
PM
Cell
Master
CRC
Child1
CRC
Child2
CRC
VS.
ONT
Cell
PM
Cell
Master
CRC
ONT
Cell
PM
Cell
Child1
CRC
Source
LIMS
OR - maintain the
map in the EMSI
ONT
Cell
PM
Cell
Master
CRC
Child1
CRC
EMSI
ONT
Cell
Child2
CRC
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).
PM
Cell
Master
CRC
EMSI
ONT
Cell
PM
Cell
EMSI
Child
CRC
Potentially more cumbersome to
implement and maintain..