Page History
...
Info |
---|
It's important to understand that each institution will have their its own protocols for coding diagnoses, procedures, medications, etc., in the patient electronic health records (aka EHR) such , as in Cerner or Epic databases), and that these protocols may use standard or non-standard codes. But 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 a CPT-4 an NDC code for a surgerymedication. And let's say that the your institution's i2b2 ontology tree your institution is using has codes only has an RxNorm code for that same type of surgery as ICD-9, ICD-10, CPT-4, and HCPCS codesmedication. Then the surgery record from the EHR would have to be mapped to 4 records in the i2b2 CRC database: one record that reflects the original CPT-4 code from the EHR, and 3 additional records where that CPT-4 code is mapped to the appropriate ICD-9, ICD-10, and HCPCS codesshould 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. |
There are many terms related to i2b2 ontologies that are new to me. Is there a Glossary?
...
How should I choose which ontology to use?
That This is the most important question on this page.
...
If your patient data are going to be set up in a database for queries by other systems in addition to 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.
...
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 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 Ontology in a second ONT database. Those new databases will comprise a "research" project in your i2b2 instance. |
What's the relationship between the metadata and the patient data?
...
The earlier question about "How does it work? How does the i2b2 ontology make the patient data queryable?" introduces 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 question aboveearlier 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.
...
The instructions for creating multiple projects is 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 the 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 a the hierarchy of healthcare termsconcepts. In the i2b2/tranSMART patient CDMCRC database, all the healthcare concepts (diagnoses, medications, procedures, and measurements) are coded in the patient records using the coding schemes like ICD, RxNorm, CPT, and LOINC; the patient data are unaware of the hierarchies in 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 codespatients.
The CONCEPT_DIMENSION table provides the mapping between all the healthcare concepts from (paths) present in an ONT database and the diagnosis, procedure, medication, and measurement hierarchical coding standards codes present in the CRC that ONT 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 the mappings for all the relevant hierarchical paths from all the associated ONT databases for that CRC database.)
How do I deploy my chosen ontology tree?
...