- The Penn TURBO (Transforming and Unifying Research with Biomedical Ontologies) project aims to accelerate finding and connecting key information from clinical records for research through semantic associations to the processes that generated the clinical data. Major challenges to using clinical data for research are integrating data from different sources which may contain multiple references to the same entity (e.g., person, health care encounter) and incomplete or conflicting information (e.g., gender, BMI). There is also the need to track the provenance of information used when making decisions on what is the actual phenotype of a person. We take a realism-based ontology approach to address these problems through transformation and instantiation of clinical data with an OBO-Foundry based application ontology in a semantic graph database. We have developed an application stack and used it on an 11,237 whole exome sequencing patient cohort capturing key demographics, diagnosis codes, and prescribed medications. The anticipated payoff is to be able to make use of inferencing provided by the semantics to classify and search for instances of people and specimens with desired characteristics.
The goal of the TURBO project is to transform and unify
research data with biomedical ontologies. Typically data are
obtained in tabular form often from relational databases. The
column headers and row values are often idiosyncratic and even
when based on a standard may be malformed, incomplete, and
contradictory. Dependencies and deep relations between the
headers (data variables) and values are rarely explicit.
Transforming the data into a semantic graph instantiating a
realism-based ontology allows us to state what is known about
people and what has happened to them, what information is
available about them, and what conclusions can be drawn based
on that information. Clinical data often comes from multiple
sources (e.g., EPIC, REDCap). Instantiation of data from
different sources in the same realism-based ontology [
The Open Biomedical Ontologies Foundry [
An application stack called Drivetrain was developed to
perform part of the transformation, the unification, referent
tracking, and generating conclusions as RDF statements about
people and their qualities. Currently the Karma tool [
Ontotext GraphDB (version 8.4.1) [
The TURBO ontology was generated following the
approach described in [
Data on a whole exome sequencing cohort of 11,237 participants (‘biobank consenters’) have been used to populate a GraphDB database. The data include information on gender identity, date of birth, and body mass index (BMI, calculated from height and weight) collected during 14,450 biobank encounters and 98,585 health care encounters. In addition, 181,420 diagnosis codes and 136,249 medications were obtained during health care encounters. The data was obtained from relational tables provided by the Penn Medicine Biobank from two sources, a data warehouse and REDCap.
In addition to RDF triples generated from the data,
individual ontologies and terminologies were also loaded into
the GraphDB database. The ontologies included the TURBO
application ontology, RDF representations of ICD9 and ICD10
codes obtained from the NCBO Bioportal [
The Karma application (version 2.1) was used to generate RDF triples from the tabular data for loading into the GraphDB database. Karma models were based on the TURBO ontology.
The code base for the Drivetrain component is available at GitHub including documentation of the full TURBO stack and description of ontology modeling. https://pennturbo.github.io/Turbo-Documentation/
A technology stack has been developed for the TURBO
project that implements a pipeline to transform tabular data into
semantic triples, stored in a Resource Description Framework
(RDF) triple store, using terms from the TURBO Ontology
(https://raw.githubusercontent.com/PennTURBO/TurboOntology/master/ontologies/turbo_merged.owl). The TURBO
ontology at time of writing consists of 727 terms (415 classes,
41 individuals, 271 properties). These are primarily drawn from
25 ontologies with 161 new terms created for TURBO (69
classes, 19 individuals, 73 properties). URIs and all labels of
terms instantiated in the current TURBO semantic repository are
listed at the bottom of:
https://pennturbo.github.io/TurboDocumentation/turbo-ontology.html (along with a discussion
and an example of an instantiated triple higher on the page).
Terms in the TURBO ontology are focused on patients and their
qualities along with information collected on them, ‘health care
encounter’s (http://purl.obolibrary.org/obo/OGMS_0000097)
and their outputs (diagnoses, measurements), and biobank
encounters and their outputs. The new terms mainly cover
shortcut relations utilized in the Karma mapping and for
managing UUIDs during referent tracking. At the Penn
Medicine Biobank, data are collected when participants are
consented at which time they have not yet donated a specimen
but have been assigned an ID. To capture this case, a ‘biobank
consenter’ term has been generated defined as a participant in a
biobank consenting process (Figure1). Incorporating the essence
of this term is in progress with ICO [
The Karma tool was used to map relational data to ontology terms saved with an extended version of the R2RML language. The mappings were then used to publish the data as RDF triples. The initial RDF triples make use of shortcut relation properties to simplify the manual mapping. The essence of TURBO shortcut relations is to allow a minimal number of classes to be instantiated – frequently just one. For example, an input table nominally about health care encounters may include height, weight and body mass index (BMI) values. Those data items are not values of the encounters, but rather values of properties borne by the people who participated in the encounters. The shortcut relation “shortcut health care encounter to BMI” eliminates the need to instantiate a class that represents the encounter participants and instead says that there is some path from the encounter to the BMI value. The Drivetrain application (described next) contains all of the logic necessary to expand the shortcut into a semantically complete description of reality.
The Drivetrain application was built to load and process the RDF triples with the following steps:
During the data import step, the input data are written to an isolated section of the graph. The triples are not expected to have globally unique identifiers and so must be sectioned off from all other data in the triple store.
The shortcut expansion phase takes all triples in the input data that use shortcut relations and expands them to fully ontologized forms. A single shortcut triple will likely expand to multiple ontologized triples. In addition to expanding the triples, the Internationalized Resource Identifiers (IRIs) in the imported data are made unique using Universally Unique Identifiers (UUIDs). After this phase is complete, the data in the isolated import graph have globally unique identifiers and are fully ontologized, though they may not yet be ready to be incorporated into the rest of the triple store.
Data integrity rules are applied to all triples in the isolated import graph to assure that the data meet the minimum level of integrity required by the Drivetrain application. Several conditions must be met to pass, including checks that all classes and properties present in the incoming data must also be present in the TURBO ontology, all denoted registries must be represented in the ontology, and all dates must be parseable, reasonable, and be typed as dates. If all integrity checks have passed, then the data are ready to be connected to the rest of the graph.
During the Referent Tracking phase, all instantiated IRIbearing terms that singularly and uniquely refer to a single thing in reality are replaced with a single Instance Unique Identifier (IUI), which is implemented by Drivetrain as an IRI that specifically contains a Universally Unique Identifier value (UUID). After this phase is complete, the RDF data are normalized such that all entities in reality can be identified by a single unique identifier that is independent yet connected to the source relational data (Figure 2).
Since our data comes from many sources, it is possible that the same ‘biobank consenter’ may appear in multiple data sources, each of which may contain different or contradicting information. It is the goal of the Referent Tracker to apply custom rules in order to determine when two consenters must be combined into one. Likewise, the same encounter may also appear in multiple data sources. A simple rule is that the identifier and identifier source (central registry ID symbol and registry) associated with the entity are the same.
Entity Linking is a generic term used here to mean the process of attaching consenters to their encounters based on data provided by a relational Join table. This process is necessary because consenters and their encounters may be received in separate files. Drivetrain can make matches by comparing the literal values of encounter symbols and consenter symbols, and the values of the respective registries.
During the conclusionating phase, rules are applied to the data to generate statements about a person or event. Currently this is done to resolve potentially conflicting data to single conclusions, which can be used for querying purposes. The potentially conflicting data derived from the sources remain in the graph and can be queried. In the future, it will be used to combine data of different types (e.g., diagnosis code, medication, lab test result) to make a single statement (e.g., a person is diabetic). To facilitate easy querying, the conclusions, which are RDF triples, are placed in a separate named graph. After this phase is complete, there will be a named graph of conclusions, which contains simplified non-conflicting statements. Conclusionating is applied to generate statements about the consenter’s biological sex, date of birth, and BMI at the date of each biobank encounter. The rules used for drawing conclusions are currently very simple, but the system is envisioned to handle more complex rules and be able to draw on a library of different rules in the future.
One way to calculate BMI is by performing a computation over a person’s height and weight, which can be measured during a health care encounter or recorded on a case report form during study recruitment during a biobank encounter (when a person becomes a ‘biobank consenter’). It is useful to know the BMI of biobank consenters at their date of recruitment.
It is not guaranteed that the source data required to calculate BMI at date of biobank encounter will be both available and of sufficient quality. It may be that height and weight measurements were recorded at the health care encounter, the biobank encounter, neither, or both. Further, the data may have been recorded improperly, which would result in a calculated BMI that is outside the acceptable range.
The following rules are currently applied to account for these situations: For each date of recruitment for each person: • If there are in-range height and weight measurements recorded in the health care encounter on the date of recruitment, compute the BMI and conclude that it is the person’s BMI at the given date of recruitment. • •
If the BMI cannot be computed from the health care encounter, but there are valid height and weight measurements records on the case report form filled out as part of the study recruitment process, compute the BMI from the case report form data and conclude that it is the person’s BMI at the given date of recruitment.
If neither the health care encounter nor the study recruitment encounter yield a BMI conclusion, then record that BMI for this given date of recruitment is inconclusive.
Diagnosis codes come to TURBO in the form of ICD9 and
ICD10 codes [
using Solr indexed text search and a Support Vector
Medication orders are provided primarily as free text, often
including dosage and route of administration information.
Associating these orders to terms in ChEBI (Chemical Entities
of Biological Interest) would enable searches based on the
parent classes of active ingredients and their roles. To
accomplish this, the orders are computationally mapped to
terms from the Drug Ontology (DRON) which provides
crossreferences to ChEBI. About 30% of the distinct medications
prescribed to our WES cohort also came with RxNorm
identifiers [
The complete Drivetrain stack was run on a linux application server with 8 GB RAM and 2 processors and a GraphDB database server with 64 GB RAM and 4 processors.
The run from loading of graph through medication mapping (steps described in sections A through G above) took 82 minutes for the WES cohort data and supportive ontologies. It resulted in 25,521,235 triples. About 3.6 million triples were initially loaded and then expanded to about 12 million triples. Additional triples resulted from referent tracking, conclusionating, and adding diagnosis and medication terms and associations.
Searches for diagnosis classes take approximately a second. For example, a search for all participants in a health care encounter which resulted in a diagnosis that mentions ‘myocardial infarction’ will return those assigned a ICD10 code of I21.3 (acute myocardial infarction).
Searches for medications also take on the order of seconds. A search for all participant prescribed a ‘statin’ returned all appropriate statins and no inappropriate ones based on drug name matches and their active ingredients with one important exception. Crestor contains rosuvastatin but is not identified as a statin. That is because rosuvastatin while present in both DRON and ChEBI have different IRIs. We are able to address this issue locally by using equivalence statements between the two (we are also following up with DRON to resolve this issue).
The TURBO project is currently in active development as a demonstration project for the Penn Institute for Biomedical Informatics. We have a stable application stack, Drivetrain, that combined with the Karma tool, enabled us to transform, load, referent track, and make conclusions related to a real dataset of interest, a WES cohort of 11,237 participants. Unlike traditional data warehousing, the TURBO system performs integration through rules applied during referent tracking and conclusionating. The processes used to determine when entities are the same (people, encounters) in referent tracking or make statements about a person (e.g., BMI) in conclusionating are modeled in the ontology and stored in the graph for provenance. Thus, Drivetrain provides an ontology-supported knowledge layer along with the loaded data.
User stories, common requests by researchers searching clinical data, are driving TURBO development. Competency questions based on these user stories are then used to evaluate the system. Examples include identification of people of specified age, biological sex, and BMI. These are possible as is finding those who have been prescribed a particular class of drugs and assigned a diagnosis code linked to a particular class of disease. We are currently working on adding genotype data resulting from exome sequencing. Future additions will include laboratory tests.
Scalability of the system remains to be determined. We plan to expand both the number of participants and type of data instantiated in the semantic graph database. At 25 million triples, our current graph database has room to grow. We run Drivetrain with reasoning off but can then load into a graph database with RDFS+ or OWL-Horst reasoning turned on. For the current datasets this takes less than an hour. We are also exploring loading shortcut triples generated by alternative methods to Karma that are less manual.
Our efforts at medication mapping have used standard tools
with good success but we would like to improve coverage as
much as possible. Some prescriptions are not medications at all
(e.g., wheelchairs, saline solutions, etc.) and we can generate
lists to recognize these. We will explore use of other
terminologies (e.g., NDFRT [
The TURBO project represents a new direction in applying
ontologies to clinical data. Most efforts do not explicitly involve
realism-based ontologies or if they do use them it is in the form
of associations and not instantiations. However, there are related
projects instantiating OBO and realism-based ontologies. These
include ones by William Duncan (Roswell Park) [
Ultimately, we intend for the TURBO project to provide a Phenotype Storefront that users can query to find participants and specimens of interest. The current plan is to just return the number of hits as results and require IRB approval for accessing identifiable data. We also want to learn from searches made by investigators in order to generate defined classes of participants and specimens. For example, equivalence axioms for someone who has had a particular disease course could include an appropriate diagnosis code but also a relevant prescription and laboratory test result. Inferencing applications of this nature will bring to bear the power of ontologies to provide what can’t be done by traditional relational systems.
All the authors have been approved under IRB protocol 813913 from the University of Pennsylvania to work with the described patient data. We thank Werner Ceusters and William Hogan for their advice and feedback on implementation of referent tracking. We also thank Jason Moore, Scott Damrauer, Michael Feldman, Peter Gabriel, John Holmes, and Daniel Rader for their support and guidance as the TURBO governance board.