i2b2 (Informatics for Integrating Biology and the Bedside): Star-Schema Architecture, Cohort Discovery, and SHRINE Federated Queries

i2b2 (Informatics for Integrating Biology and the Bedside) is an open-source clinical research data warehousing and cohort discovery platform maintained by the i2b2 tranSMART Foundation. Originally developed at Partners HealthCare (now Mass General Brigham) and Harvard Medical School by Shawn Murphy, Isaac Kohane, and colleagues under a National Institutes of Health (NIH) Roadmap National Center for Biomedical Computing (NCBC) grant (Murphy et al., JAMIA, 2010), i2b2 powers translational research repositories across hundreds of Clinical and Translational Science Award (CTSA) hubs and academic medical centers worldwide.

In hospital research informatics, i2b2 solves the structural mismatch between transactional EHR implementation databases—which are optimized for single-patient chart retrieval—and population-level clinical research queries that scan millions of longitudinal patient records to determine how many patients satisfy complex trial inclusion and exclusion criteria.

What Is i2b2 and How Does the “Hive” Architecture Work?

Rather than building a monolithic application, the i2b2 platform is engineered as a modular, service-oriented collection of independent web-service microservices known as the i2b2 Hive. Each functional module—called a Cell—communicates with other cells and the web client through standardized XML/REST messaging:

• Project Management (PM) Cell: Authenticates users and enforces role-based access control (RBAC) per research project—restricting whether a user can only view obfuscated aggregate patient counts, view de-identified row-level data, or access Protected Health Information (PHI) under an Institutional Review Board (IRB)-approved study.
• Ontology Management (ONT) Cell: Stores the hierarchical clinical terminology trees (such as ICD-10-CM, LOINC, RxNorm, CPT, SNOMED CT, and local institutional concepts) using hierarchical path strings (C_FULLNAME) that allow a single parent drag-and-drop query (e.g., Type 2 Diabetes Mellitus) to automatically expand to all descendant billing and clinical codes.
• Data Repository / Clinical Research Chart (CRC) Cell: Houses the relational star-schema database and executes Boolean and temporal SQL cohort queries.
• Identity Management (IM) Cell: A heavily restricted vault that maintains the encrypted crosswalk mapping between de-identified i2b2 PATIENT_NUM pseudo-identifiers and real hospital Medical Record Numbers (MRNs) for authorized chart review or trial recruitment.
• Workplace (WORK) Cell: Allows investigators and research coordinators to save, organize, and share query definitions and patient set pointers across a study team.

The i2b2 Star Schema and the observation_fact Table

Traditional Electronic Health Record databases contain thousands of normalized relational tables that change across vendor upgrades. i2b2 simplifies clinical data warehousing by combining Kimball dimensional star-schema modeling with an Entity-Attribute-Value (EAV) fact structure centered on a single core table: observation_fact.

Every clinical event—whether a diagnosis, a laboratory potassium value, an inpatient medication administration, a vital sign, a genomic variant, or a concept extracted by Natural Language Processing (NLP) from a pathology report—is stored as a row in observation_fact surrounded by four primary dimension tables:

i2b2 Star-Schema Table	Primary Key / Join Column	Core Columns & Informatics Role
observation_fact (Central Fact Table)	Composite PK: (ENCOUNTER_NUM, PATIENT_NUM, CONCEPT_CD, PROVIDER_ID, START_DATE, MODIFIER_CD, INSTANCE_NUM)	Stores every clinical event; holds VALTYPE_CD (numeric N, text T, NLP blob B), NVAL_NUM, TVAL_CHAR, UNITS_CD, and VALUEFLAG_CD (high/low abnormal flags).
patient_dimension	PATIENT_NUM	Stores one row per patient with de-identified demographics: BIRTH_DATE (often date-shifted), DEATH_DATE, SEX_CD, RACE_CD, LANGUAGE_CD, and MARITAL_STATUS_CD.
visit_dimension	ENCOUNTER_NUM, PATIENT_NUM	Represents healthcare encounters (inpatient admissions, emergency visits, ambulatory visits) with START_DATE, END_DATE, INOUT_CD, and length of stay.
concept_dimension	CONCEPT_CD	Maps hierarchical ontology paths (CONCEPT_PATH) to standardized vocabulary codes (e.g., ICD10CM:E11.9, LOINC:4548-4, RXNORM:6809).
provider_dimension	PROVIDER_ID	Organizes ordering and attending clinicians by clinical department and specialty hierarchy (PROVIDER_PATH).
modifier_dimension	MODIFIER_CD	Qualifies a base CONCEPT_CD without exploding the concept dictionary—such as distinguishing primary vs. secondary diagnosis, or medication dose, route, and frequency linked via INSTANCE_NUM.

How Investigators Build Temporal Cohort Queries in i2b2

Using the i2b2 Web Client query builder, clinical investigators construct feasibility queries without writing SQL:

1. Boolean Panel Construction (AND / OR / NOT): The user drags ontology terms from the left-hand Navigate Terms hierarchy into vertical query panels. Terms placed inside the same panel are evaluated with logical OR; separate panels are joined with logical AND; any panel can be toggled to Exclude (logical NOT).
2. Value and Occurrence Constraints: When dragging a laboratory concept (such as Hemoglobin A1c, LOINC:4548-4), a modal prompts the user to constrain numeric values (e.g., > 8.0 %) or abnormal flags, and to specify minimum occurrence counts (e.g., at least 2 occurrences).
3. Temporal Sequence Constraints: Investigators can define multi-event temporal sequences—for example, requiring that Event 1 (initiation of an SGLT2 inhibitor) occurs at least 30 days after Event 2 (diagnosis of heart failure) within the same encounter or across encounters.
4. Obfuscated Aggregate Execution: Clicking Run Query returns the aggregate patient count plus optional demographic breakdowns (age, sex, race/ethnicity). To satisfy HIPAA Preparatory to Research (45 CFR § 164.512(i)(1)(ii)) and Safe Harbor rules without requiring per-query IRB review, the CRC cell automatically adds bounded Gaussian noise (typically ±3 patients) and masks counts below a configurable low-cell threshold (e.g., < 10 patients), locking out users who repeatedly run differencing queries.

Federated Multi-Site Discovery with SHRINE and Interoperability with OMOP / FHIR

While a single i2b2 instance queries one health system, multi-center clinical trials require estimating cohort availability across dozens of academic medical centers. The Shared Health Research Information Network (SHRINE) (Weber et al., JAMIA, 2009)—which underpins national CTSA federated networks such as the NCATS Accrual to Clinical Trials (ACT / ENACT) network—connects independent institutional i2b2 nodes into a federated query grid. When a researcher submits a query through SHRINE, a hub broadcaster distributes the query to each participating hospital’s local SHRINE adapter, translates network ontology terms into local CONCEPT_CD paths, executes the query behind each hospital’s firewall, and returns only obfuscated site-level aggregate counts.

In modern EHR integration architectures, i2b2 repositories also interoperate directly with the OHDSI OMOP Common Data Model (via the i2b2-on-OMOP ontology driver) and support automated ingestion and export of HL7 FHIR Bulk Data ($export) resources.

Frequently Asked Questions

What is i2b2 and how is it used in clinical research and healthcare?

i2b2 (Informatics for Integrating Biology and the Bedside) is an open-source clinical data warehousing and cohort discovery platform originally developed at Partners HealthCare and Harvard Medical School under an NIH National Center for Biomedical Computing grant. Academic medical centers use i2b2 to transform Electronic Health Record (EHR) data into a searchable star-schema repository so investigators can run self-service clinical trial feasibility queries and extract research datasets.

What standards or regulatory requirements govern i2b2?

Self-service aggregate cohort discovery in i2b2 operates under the HIPAA Safe Harbor de-identification standard (45 CFR § 164.514(b)) or the HIPAA Preparatory to Research provision (45 CFR § 164.512(i)(1)(ii)), using Gaussian count obfuscation, small-cell threshold suppression, and audit logging. Extraction of patient-level Limited Data Sets or identifiable cohorts from i2b2’s Identity Management (IM) cell requires an executed Data Use Agreement (DUA) or IRB protocol approval.

How does i2b2 integrate with EHR and health informatics workflows?

Hospital informatics teams run scheduled Extract-Transform-Load (ETL) pipelines that extract structured diagnoses (ICD-10-CM), procedures (CPT/HCPCS), laboratory results (LOINC), and medications (RxNorm) from enterprise EHR clinical data repositories or HL7 FHIR Bulk Data exports and load them into i2b2’s central observation_fact star schema and hierarchical ontology tables.