Page History
...
The converse is also true. Each CRC database is designed to be paired with only one ONT database. This is because the CRC database actually includes some very specific metadata that must match the metadata in the ONT database. There is an exception to this: if more than one ONT database share the same information that appears in the CRC database, then multiple projects can be supported by that single CRC database.
The instructions for creating multiple projects are outside the scope of this Ontologies tutorial page.
...
How does it work? How does the i2b2 ontology make the patient data queryable?
This is another key topic question/concept.
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. 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 defined in the metadata.
...
For instance, if the patient's electronic health record indicates that the patient had the procedure "tonsillectomy with adenoidectomydiagnosis "Acute tonsillitis," then that fact needs to be recorded in the CRC database using the standard code for that particular procedure diagnosis as defined in the ONT database. In the case of using the default i2b2 Procedures Diagnoses metadata tree, that code would be "ICD9:28.3463". When a researcher makes a query in the user interface for "tonsillectomy with adenoidectomyAcute tonsillitis," then i2b2 will query the CRC database for all patients who have the code ICD9:28.3463 in their data records.
| Info |
|---|
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 institutional protocols may use standard, non-standard, or proprietary codes. So, when loading patient data into the CRC database for i2b2, it's necessary for the data curators who perform the ETL process (extract-transform-load) to map the codes existing in the patient EHR into the codes that are defined in the i2b2 metadata (ONT database). 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 particular medication. Then the medication record from the EHR would need to be mapped into a patient record in the i2b2 CRC database in such a way that the ontology's RxNorm code (not the EHR's NDC code) appears in the patient record. If the patient record in the CRC database has the NDC code from the EHR, then it would not be matched in a query, since the i2b2 query would be using the RxNorm code. |
| 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. In this case, they can reduce the complexity of the ETL mapping, but this will surely increase the complexity of setting up the ontology tree. |
| Info |
|---|
What if my institution records new concepts into the EHR that are not already included in the ontology?
If your institution is using concepts or codes that are not reflected in your i2b2 ontology tree, the researchers will not be able to query for those concepts in i2b2.
...
Let's view a high-level illustration of the mechanism behind a typical query. Here's that concept's definition from the diagnoses table in the ONT (metadata) database:
Excerpt from Diagnoses Table in Demo Ontology (I2B2 table in ONT metadata database) | ||
|---|---|---|
| Concept Name, displayed to user | Concept Path, a unique identifier | other fields |
Acute tonsillitis |
| ... |
When the user selects that Concept Name in the user interface, the i2b2 Query Tool associates that with the Concept Path. When running the query, i2b2 looks for that path in the concepts table in the CRC database, which looks like this...
Excerpt from Concepts Table in Demo Ontology (CONCEPT_DIMENSION table in CRC database) | ||
|---|---|---|
| Concept Path, a unique identifier | Concept Code, used in facts table | other fields |
|
| ... |
...and i2b2 associates that Concept Path with the Concept Code for that concept. i2b2 then locates those patients in the facts table in the CRC database that share that Concept Code...
Excerpt from Facts Table in Demo Patient Data (OBSERVATION_FACTS table in CRC database) | |||
|---|---|---|---|
| Patient ID | Visit ID | Concept Code | other fields |
|
|
| ... |
|
|
| ... |
|
|
| ... |
|
|
| ... |
|
|
| ... |
|
|
| ... |
...and reports a count of those patients back to the user at the conclusion of the query. In this illustration, there were 2 unique patients (over 6 encounters) that had this Concept Code in the facts table, so the user's query for patients with a diagnosis of "Acute tonsillitis" will return a count of 2 patients.
| Info |
|---|
The query mechanism illustrated above applies to most queries, but not all. For more details, see Ontologies 103 – Ontology Table Structure and Query Mechanism. |
| Info |
|---|
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 institutional protocols may use standard, non-standard, or proprietary codes. So, when loading patient data into the CRC database for i2b2, it's necessary for the data curators who perform the ETL process (extract-transform-load) to map the codes existing in the patient EHR into the codes that are defined in the i2b2 metadata (ONT database). 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 particular medication. Then the medication record from the EHR would need to be mapped into a patient record in the i2b2 CRC database in such a way that the ontology's RxNorm code (not the EHR's NDC code) appears in the patient record. If the patient record in the CRC database has the NDC code from the EHR, then it would not be matched in a query, since the i2b2 query would be using the RxNorm code. |
| Info |
|---|
| For some institutions, the ETL mapping from the EHR to the i2b2 CRC database 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 will likely have to customize their i2b2 ontology to reflect the coding schemes present in their CRC database. In this case, they may reduce the complexity of the ETL mapping, but this will likely increase the complexity of setting up the ontology tree. For details on how to customize the ontology tree, see Ontologies 201 – Custom Metadata – Additions and Modifications. |
What if my institution records new concepts into the EHR that are not already included in the ontology?
If your new concepts are not proprietary, then we recommend that your institution contact the appropriate coding authority, and ask them to include your new concepts into the next release of their terminology.
What if my institution's EHR is missing concepts that are found in one of the ontology trees?
If your institution's patient data do not include concepts from one of the ontology trees, then queries made from that tree's concepts may come up with zero results.
Trees with zero matching patient records can be handled in these ways:
...
It's not unusual for institutions to include coding in their EHR to reflect novel diagnoses, new medications, etc. And some institutions prefer to use proprietary codes for some clinical information. If your institution is using concepts or codes that are not reflected in your i2b2 ontology tree, then your researchers will not be able to query for those concepts in i2b2.
The remedy for this is to customize your ontology trees to include the new concepts that are missing from the i2b2 ontologies. See Ontologies 201 – Custom Metadata – Additions and Modifications.
| Tip Box |
|---|
If your new concepts are not strictly proprietary, then please consider contacting the appropriate coding authority, asking them to include your new concepts into the next release of their terminology. |
What if my institution's EHR is missing concepts that are found in one of the ontology trees?
...
Never fear! No institution will be using all of the concepts in every ontology tree. It is normal to have concepts in the ontology tree that match none of your patient records.
...
