"Ontology" represents the branch of Philosophy that discusses "existence." But in Information Science, an "ontology" is a way of listing the attributes of a subject area and showing how they are related. An ontology for a subject area or "domain" consists of a set of terms that represent the entities in that domain, along with a set of expressions that define how the entities are related to each other.
In i2b2's domain of Clinical Research Informatics, an ontology is a collection of healthcare-related "concepts" or terms. These terms represent the various categories of information in clinical and translational science. Categories such as demographics, diagnoses, procedures, laboratory tests, and medications are described using hierarchical lists of "concepts" in an i2b2 ontology.
Unlike some other ontologies in Information Science, an i2b2 ontology does not define relational expressions among the concepts or terms. Therefore, strictly speaking, an i2b2 ontology is actually a "taxonomy," which is a hierarchical group of terms or concepts, without any relational expressions among them.
For instance, if you recall (from your high-school biology class) Linnaeus's "binomial nomenclature" model of how to name living organisms, then you already know what a taxonomy is. For instance, the common house fly Musca domestica and other flies in the family Muscidae are members of the order Dipte ra, which are organisms in the class Insecta, phylum Arthropoda, kingdom Animalia. A taxonomy defines the hierarchical "is-a" relationship between two concepts. Similarly, a Camry is a Toyota, which is an automobile, which is a type of motorized, wheeled conveyance.
An i2b2 instance requires an ontology so that researchers can locate "concepts" of interest and locate patients whose medical records contain these "concepts."
The healthcare concepts contained in the ontology are the building blocks of an i2b2 query. The i2b2 ontology is represented in the upper-left corner of the i2b2 webclient (user interface). See the screenshot below.
These concepts are rendered as a collection of nested folders and generally represent child-parent (or is-a) relationships. Researchers locate these concepts by using a hierarchical tree, or taxonomy. When you log in to the demo i2b2 site (username "demo", password "demouser" are already filled in), you will see the i2b2 ontology tree on the upper-left side of the user interface. We also refer to that listing as a group of ontologies, where each category or top-level taxonomy is called an ontology in its own right.
In this screenshot, we would say that i2b2 is displaying an ontology with 13 top-level ontology trees or categories, namely: Clinical Trials, Custom Metadata, Demographics, Diagnoses, etc.
For instance:
Here is another screenshot, where you can see the expansion for "Race" in the "Demographics" tree:
Typically, the concepts that make up the various categories or "domains" are based on medical terminology standards published by various institutions. Concepts can also be created ad hoc for a specific i2b2 instance by the i2b2 administrator at that site. (For more information on custom metadata, please see Ontologies 201.)
The commonly used standards representing basic structured clinical patient data are represented by a number of different "coding schemes" — ICD-9, ICD-10, CPT-4, HCPCS, SNOMED CT, LOINC, RxNorm, UMLS, and VA Classes. See Appendix B for further information.
First, a little more terminology. The i2b2 "patient data" are stored in the i2b2 Clinical Research Chart database, or "CRC database." The concepts that describe those patient data are known as the "metadata." The metadata are stored in the i2b2 Metadata database, or "ONT database."
The i2b2 metadata in the ONT database work together with the patient data in the CRC database. Each patient "observation" in the CRC database must have a code associated with it, and that code must match a healthcare concept — diagnosis, procedure, medication, lab test, demographic descriptor, etc. — that exists in the ONT database. So the CRC patient data will be queryable in i2b2 only if the patient facts in the CRC database are recorded utilizing standard codes that are referenced in the i2b2 metadata (ONT database).
For instance, if the patient's electronic health record indicates that the patient had the procedure "tonsillectomy with adenoidectomy," then that fact needs to be recorded in the CRC database using the standard code for that particular procedure. In the case of using the default i2b2 Procedures metadata tree, that code would be "ICD9:28.3". When a researcher makes a query in the user interface for "tonsillectomy with adenoidectomy," that query will be translated by i2b2 into a query for patients in the CRC database who have the code ICD9:28.3 in their data records.
| It's important to understand that each institution will have its own protocols for coding diagnoses, procedures, medications, etc., in the patient electronic health records (aka EHR, as in Cerner or Epic databases), and that these protocols may use standard or non-standard codes. So, when preparing the CRC database for i2b2, it's necessary for the ETL process (extract-translate-load) to map the codes from the patient EHR into the codes that are present in the i2b2 metadata. For instance, let's say a patient's EHR record includes an NDC code for a medication. And let's say that your institution's i2b2 ontology tree only has an RxNorm code for that type of medication. Then the surgery record from the EHR should be mapped into a patient record in the i2b2 CRC database that uses the appropriate RxNorm code. If the patient record in the CRC database has the NDC code from the EHR, then it would not be matched in a query when the query is using the RxNorm code. |
Yes! Here is a Glossary that provides explainers for many of the key terms related to i2b2 ontologies and the i2b2 architecture.
No. Several i2b2 ontologies have been developed and are openly available for use. Any organization may also modify an existing ontology for its own use, or develop a new ontology. (See Ontologies 201.)
The i2b2 software includes i2b2 ontologies that you can use right away. There are additional ontology trees that can substitute for, or can be added to, the standard i2b2 ontology trees. (See Appendix E – Advanced Ontologies.)
The i2b2 database-loading modules come with at least 3 sets of "metadata" or ontology trees. These are the demo ontology, the ACT ontology, and the ACT-on-OMOP ontology.
| Name | Description | Target Data Model |
|---|---|---|
| i2b2 Demo Ontology | default metadata from i2b2 authors | i2b2 Common Data Model (star-schema); default CRC demo database has matching concepts |
| ACT Ontology | ENACT project | i2b2 Common Data Model (star-schema); ACT CRC demo database has matching concepts |
| ACT-on-OMOP Ontology | ENACT project | i2b2 Common Data Model (star-schema), but modified with views into the OMOP Common Data Model; the CRC database loaded with SYNPUF demo data has matching concepts |
The table below outlines the domains and coding schemes included in each ontology.
| Domain / Coding Scheme | i2b2 Demo Ontology | ACT Ontology | ACT-on-OMOP Ontology |
|---|---|---|---|
| Demographics | |||
Diagnoses | |||
| ICD-9-CM |  | | |
| ICD-10-CM | Out of date | | |
| SNOMED CT | | ||
Medications | Homegrown? | ||
RxNorm | | ||
NDC | | ||
SNOMED CT | | ||
| Procedures | |||
| ICD-9-CM | | | |
| ICD-10-PCS | | ||
| CPT-4 | | ||
| HCPCS | | ||
| SNOMED CT | | ||
| Lab Tests / Vital Signs | Homegrown? | ||
| LOINC | | ||
| SNOMED CT | |
| If your local institution does not have data in the CRC database for a certain domain in your chosen i2b2 ontology, then user queries referencing that domain may come back empty. To avoid that, you can exclude that domain from the i2b2 user interface, so that the domain without matching data in the CRC database is never used in a query. |
This is the most important question on this page.
The ontology you choose depends on your institution's goals and patient data. If your goal is simply to understand and show how i2b2 works, then the i2b2 demo ontology is sufficient. If your goal is to set up i2b2 for research use, one of the ACT ontologies will be far more useful. The ACT ontologies are more modern, more robust, and will satisfy the needs of more researchers.
Furthermore, any institution that is planning to join the ENACT Network will need to use an ACT ontology to ensure compatibility with the other institutions in the network.
When setting up the patient data for i2b2, your institution needs to decide how it will conduct the ETL mapping from the EHR to the i2b2 CRC database. If your patient data are going to be set up only for i2b2 and SHRINE use, then many institutions set up the patient data in the default i2b2/tranSMART Common Data Model (CDM). In this case, they typically use the ACT Ontology with all its various coding standards; the patient data from the EHR system need to be mapped to the multiple coding schemes in the ACT Ontology as they are loaded into the CRC database.
If your patient data are going to be set up in a database for queries by other systems besides i2b2, then many institutions use the OMOP Common Data Model (CDM) for their patient data in the CRC database. In this case, they typically use the ACT-on-OMOP Ontology, which relies chiefly on the SNOMED CT coding standard; the patient data from the EHR system need to be mapped to the SNOMED CT coding scheme as they are loaded into the CRC database.
| For some institutions, the ETL mapping from the EHR to the i2b2 CRC databases is the most problematic process in the setup. Those institutions may decide to minimize the complexity of their ETL, and simply copy the coding scheme from their EHR into the patient records in the CRC database. If the coding schemes in their EHR are not standard coding schemes, then they may have to customize their i2b2 ontology to reflect the coding schemes present in their CRC database. |
Setting up i2b2 can be a complex undertaking. You can learn a lot about how it works, and get the system up and running most quickly, by first setting up your i2b2 instance with the i2b2 Demo Ontology and demo patient data. Those databases will comprise a "demo" project in your i2b2 instance. When you have proven the deployment with the demo project, you can add a separate, new project for research. In this case you could use actual patient data in a second CRC database and an ACT Ontology in a second ONT database. Those new databases will comprise a "research" project in your i2b2 instance. |
This is the second most important question on this page.
The earlier question about "How does it work? How does the i2b2 ontology make the patient data queryable?" introduced the concept of how the patient data in the CRC database work in tandem with the metadata in the ONT database to allow i2b2 to conduct queries for the researcher.
As a reminder from the earlier answer: the metadata spell out all the various healthcare concepts or terms that a researcher may wish to query for in the user interface, and the patient data must be coded in such a way that they reflect the codes found in the metadata. Only when a patient's codes match the codes in the query terms from the ontology will the patient be counted as part of a query result.
But there is more to the relationship between the ONT and CRC databases. One additional topic is the i2b2 "project." The other additional topic is the "secret sauce" of the relationship.
The pairing of a metadata database with a patient database (ONT plus CRC) defines a "project" in i2b2. For instance, the pairing of the i2b2 demo ontology with the i2b2 demo patient data would define a "demo" project in i2b2. In that same i2b2 instance, an institution could create a second ONT database for the ACT ontology, and a second CRC database for the institution's actual patient data; the pairing of those two new databases would define a genuine research project in i2b2.
It's important to note that each ONT database is designed to be associated with only one CRC database; that is, each ONT database is designed to belong to only one i2b2 project.
The converse is not true. Each CRC database is designed to be paired with any number of ONT databases; that is, each CRC database may belong to multiple i2b2 projects.
The instructions for creating multiple projects are outside the scope of this Ontologies tutorial page.
There is a special metadata table that resides in the CRC database. This metadata table is called the CONCEPT_DIMENSION table. It resides in the CRC patient database, and it is part of the i2b2/tranSMART patient CDM, but it is still definitely metadata. You may consider this the "secret sauce" that joins the metadata with the patient data.
So what is the role of this metadata in the CRC database?
The ONT database provides a hierarchy of healthcare concepts, and each concept is identified in the ONT database by a unique "path." The concept's path resembles the path of a file in a computer filesystem. Just as directories in a computer filesystem are hierarchical, so the paths of the concepts reflect the hierarchy of healthcare concepts. In the CRC database, all the healthcare concepts (diagnoses, medications, procedures, and measurements) are coded in the patient records using coding schemes like ICD, RxNorm, CPT, and LOINC; the patient data do not include the hierarchical paths from the ONT database. The role of the CONCEPT_DIMENSION table is to map each hierarchical path from the ONT database to its matching code in the CRC patient data. It's this mapping that allows a path from the ONT database to be used in a query on the CRC database; without this mapping, i2b2 would not be able to match ONT concepts with CRC patients.
The CONCEPT_DIMENSION table provides the mapping between all the healthcare concepts (paths) present in an ONT database and the diagnosis, procedure, medication, and measurement codes present in that ONT database's associated CRC patient data. (If a CRC database is associated with more than one ONT database — more than one project — then the CONCEPT_DIMENSION table would need to include the mappings for all the relevant hierarchical paths from all the associated ONT databases for that CRC database.)
<Add links here to link to the appropriate sections of the installation instructions>
When your metadata database is installed, it will have the following tables:
This table shows all the metadata tables you should expect to have in your ONT database when you have loaded your i2b2 ontology (per i2b2 v1.8.1):
| i2b2 Demo Ontology | ACT Ontology | ACT-on-OMOP Ontology |
|---|---|---|
BIRN CUSTOM_META I2B2 ICD10_ICD9 ONT_PROCESS_STATUS PHI SCHEMES TABLE_ACCESS totalnum totalnum_report | ACT_COVID_V41 ACT_CPT4_PX_V41 ACT_DEM_V41 ACT_HCPCS_PX_V41 ACT_ICD10_ICD9_DX_V4 ACT_ICD10CM_DX_V41 ACT_ICD10PCS_PX_V41 ACT_ICD9CM_DX_V4 ACT_ICD9CM_PX_V4 ACT_LOINC_LAB_V4 ACT_LOINC_LAB_PROV_V41 ACT_MED_ALPHA_V41 ACT_MED_VA_V41 ACT_RESEARCH_V41 ACT_SDOH_V41 ACT_VAX_V41 ACT_VISIT_DETAILS_V41 ACT_VITAL_SIGNS_V4 ACT_ZIPCODE_V41 BIRN CUSTOM_META I2B2 ICD10_ICD9 ONT_PROCESS_STATUS SCHEMES TABLE_ACCESS totalnum totalnum_report | ACT_COVID_V41_OMOP ACT_CPT4_PX_V41_OMOP ACT_DEM_V41_OMOP ACT_HCPCS_PX_V41_OMOP ACT_ICD10_ICD9_DX_V4_OMOP ACT_ICD10CM_DX_V41_OMOP ACT_ICD10PCS_PX_V41_OMOP ACT_ICD9CM_DX_V4_OMOP ACT_ICD9CM_PX_V4_OMOP ACT_LOINC_LAB_V4_OMOP ACT_LOINC_LAB_PROV_V41_OMOP ACT_MED_ALPHA_V41_OMOP ACT_MED_VA_V41_OMOP ACT_RESEARCH_V41_OMOP ACT_SDOH_V41_OMOP ACT_VAX_V41_OMOP ACT_VISIT_DETAILS_V41_OMOP ACT_VITAL_SIGNS_V4_OMOP ACT_ZIPCODE_V41_OMOP BIRN CUSTOM_META I2B2 ICD10_ICD9 ONT_PROCESS_STATUS SCHEMES TABLE_ACCESS totalnum totalnum_report |
In addition, in your CRC database, there should be a CONCEPT_DIMENSION table.
totalnum") to learn how to add patient counts to your ontology concepts in the user interface.