Page History
...
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.
Let's illustrate this brieflyview a high-level illustration of the mechanism behind a typical query. Here's that concept's definition from the procedures 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 | in the procedures table|
Acute tonsillitisTonsillectomy with adenoidectomy |
| ... | |
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 | in the concepts table|
|
| ... | |
...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 |
|---|
|
|
|
...
...
... ... |
105048
|
50256
|
|
| ... |
...
...
...
|
|
| ... |
118953
|
54877
|
|
| ... |
...
...
...
... 267169
39218
|
|
|
...
| ... |
|
...
...
|
| ... |
...and reports a count of those patients back to the user at the conclusion of the query. In this illustration, there were 3 patients 2 unique patients (over 6 encounters) that had this Concept Code in the facts table, so the user's query for patients with the "Tonsillectomy with adenoidectomy" procedure a diagnosis of "Acute tonsillitis" will return a count of 3 patients2 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. |
...
