Page History
...
How should I choose which ontology to use?
That is the most important question on this page.
The ontology you choose to use depends on your local institution's goals and local patient data. As long as your primary purpose is If your goal is simply to understand and show how the i2b2 webclient 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. In general, to set up an i2b2 instance to support research, start with the ACT Ontology. This Ontology includes a wide range of terminologies that should cover most code-sets you'll find in your EMR data. OMOP refers to a Common Data Model, so if you are using this model locally, then ACT on OMOP will be the most relevant. 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 in addition to 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.
| Info |
|---|
| 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. |
| Tip Box |
|---|
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. |
What's the relationship between the metadata and the patient data?
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?" introduces the concept of how the patient data (CRC database) work in tandem with the metadata (ONT database) to allow i2b2 to conduct queries for the researcher.
As a reminder from the question above: 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.
i2b2 Projects
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 is outside the scope of this Ontologies tutorial page.
Metadata "Secret Sauce"
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.
The ONT database provides the hierarchy of concepts, and each concept is identified 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 a hierarchy of healthcare terms. In the i2b2/tranSMART patient CDM, all the healthcare concepts (diagnoses, medications, procedures, and measurements) are coded using the coding schemes like ICD, RxNorm, CPT, and LOINC; the patient data are unaware of the hierarchies in the ONT database. The role of the CONCEPT_DIMENSION table is to map each hierarchical path to its matching code. 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 codes.
The CONCEPT_DIMENSION table provides the mapping between all the healthcare concepts from the diagnosis, procedure, medication, and measurement hierarchical coding standards present in the CRC database's associated ONT database to the codes present in the 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 all the relevant hierarchical paths from all the associated ONT databases.)
How do I deploy my chosen ontology tree?
<Add links here to link to the appropriate sections of the installation instructions>
What should my metadata database look like when I am done?
When your metadata database is installed, it will have the following tables:
- TABLE_ACCESS: a configuration table that tells i2b2 which ontology tables to load into the user interface
- SCHEMES: a configuration table that tells i2b2 which coding schemes are being used in the ontology tables
- one or more ontology tables:
- each ontology table will typically consist of a hierarchy of concepts for a particular category or domain of healthcare data; for instance:
- in the i2b2 demo ontology, the I2B2 table contains concepts for diagnoses
- in the ACT ontology, the ACT_DEMOGRAPHICS table contains concepts for patient demographics
- each ontology table will typically consist of a hierarchy of concepts for a particular category or domain of healthcare data; for instance:
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.
Suggested Next Steps?
- Visit Appendix C – Ontology Tables to learn more about the structure of the ontology database.
- Visit Appendix D – Test Queries to learn how to run some "sanity check" queries on your new database.
- Visit Ontologies 102 – Patient Counts ("
totalnum") to learn how to add patient counts to your ontology concepts in the user interface.
