gms | German Medical Science

In the Medical Informatics Initiative (MII) innovative IT solutions are developed to support medical research and enhance patient care. An important aspect of this is the automatic detection of diseases, risks for the same and adverse events of medications. For the implementation of such detection, patient data must be extracted from electronic health records (EHR) or research databases and evaluated. This may involve machine-interpretable phenotype algorithms, which use structured filter criteria and rules to detect individuals with specific properties (phenotypes) and derive further properties. With this, computer-assisted algorithms can, among other things, improve clinical trial recruitment [1]. The National Portal for Medical Research Data (FDPG) was recently developed in the MII [2]. It provides scientists with federated access to 31 German university hospitals, enabling them to perform feasibility queries and submit data use proposals. The query interface allows relatively simple matching criteria to be defined.

In this work, we want to focus on a more general approach of defining shareable models that can be used to perform complex queries and calculations in order to find matching individuals and infer additional characteristics. For this, we distinguish between three core notions: phenotype, phenotype model and phenotype algorithm.

We use the definition of ‘phenotype‘ as a ‘(combination of) bodily feature(s) of an organism determined by the interaction of its genetic make-up and environment’ by Scheuermann et al. [3]. And in a broader sense, we also consider all observable human characteristics to be phenotypes.

A phenotype model is a formal representation of phenotypic knowledge. We hereby distinguish between general and specific phenotype models [4]. The general model provides a basic classification of phenotypes, the required attributes of phenotype classes (e.g., labels, data types, codes, units of measurement, derivation rules/formulas etc.), relation types and rules (axioms), which must be used/followed by developing specific models. A specific phenotype model represents phenotypic knowledge by defining specific phenotype classes (such as ‘weight’, ‘height’, ‘BMI’, ‘obesity’, etc.) according to the general model. This means, all required attributes of the classes (e.g., including the formula for calculating BMI from weight and height, as well as the ranges to classify the BMI value in categories from underweight to obesity) and relations between the classes (e.g., weight and height values are required for calculating BMI) are specified.

A phenotype algorithm is generally understood as an algorithm designed to identify or classify phenotypic traits [5], [6]. Specifically, we consider a phenotype algorithm to be a sequence of instructions to

1.

query data representing phenotypes,

2.

derive additional properties (derived/composite phenotypes) from other phenotypes,

3.

classify phenotypes into phenotype classes, and

4.

provide results in a machine- and human-readable format.

A generic phenotype algorithm is model-driven (i.e., it can be configured by a phenotype model). This means, the algorithm always performs the same (generic) steps (see above) and uses the specific phenotype definitions specified in a phenotype model (e.g., identifying obese patients based on weight and height or identifying patients with acute kidney injury based on creatinine).

The effort required to design algorithms can be very high depending on the complexity [7] and typically requires a close collaboration between domain and IT experts. To support domain experts in creating phenotype models and executing phenotype algorithms, we developed a framework, the Terminology- and Ontology-based Phenotyping (TOP) Framework, which will be presented in this work. The goal was for the framework to allow domain experts to define phenotypes with respective filters and roles on their own, and to be embeddable by IT experts into the hospital’s information system, thus allowing the execution of algorithms on patient data from routine patient care and medical research.

We use the Core Ontology of Phenotypes (COP) [8] as the generic phenotype model and as a basis for developing specific models. COP specifies that all phenotypes of organisms are instances of one or more phenotype classes. These classes are distinguished into single and composite phenotype classes. Single phenotypes (e.g., height or weight of a person) are atomic and can be components/parts of composite phenotypes (e.g., BMI). The two described class types can further be subdivided into unrestricted and restricted phenotype classes. A restricted class (e.g., ‘height above 150 cm’) is always a subclass of an unrestricted class (‘height’) and possess a value restriction so that only a subset of the corresponding unrestricted class instances belongs to the restricted class. For example, the phenotype ‘height’ with value 180 cm of the individual John Doe is an instance of the unrestricted single phenotype class ‘height’ and, at the same time, of the restricted single phenotype class ‘height above 150 cm’.

Single phenotype classes must be annotatable with terms of standard terminologies like Logical Observation Identifiers Names and Codes (LOINC) or Systematized Nomenclature of Medicine and Clinical Terms (SNOMED CT). These annotations are used to assign the phenotype classes with corresponding data from the source systems. For instance, the phenotype ‘height’ is annotated with code ‘LOINC:3137-7’. With this annotation in place, a mapping can be provided to assign all height values from electronic health records to the phenotype ‘height’, which makes them available for classifications and calculations.

As composite phenotypes result from calculations and compositions of single phenotypes, constants and other composite phenotypes, we developed a generic specification to express these cases. According to the specification, all composite phenotype classes have exactly one expression representing either a phenotype, a constant, or exactly one function with a set of arguments. Expressions can be nested because arguments are also expressions. Functions convert argument sets into a single expression (usually a value), though they are not limited to mathematical functions and the available set of functions is extensible. For instance, the expression of the phenotype ‘Body Mass Index’ can be expressed as follows: ‘quotient(weight, power(height, 2))’.

The TOP Framework implements a generic phenotype algorithm, which can be executed by selecting a desired phenotype model and defining (single or composite) phenotype classes as in- or exclusion criteria. Composite phenotypes can be traced back to singles from which they are derived. This results in a set of single phenotypes, which all have terminology annotations. For each of them, queries can be inferred that are translated to the respective query language of the source system and executed on the system. We assume that relevant data elements are available in structured form and are retrievable from data-holding systems (source system) with respective query languages. In the MII, Fast Healthcare Interoperability Resources (FHIR, https://www.hl7.org/fhir), by the standardisation organisation Health Level 7, is used to make patient data from electronic health records accessible. And also, many research data management systems are using databases based on the Structured Query Language (SQL). We therefore focused on SQL database management systems and FHIR servers with FHIR Search (https://www.hl7.org/fhir/search.html) support. The inference is done by generic or source system-specific adapters. For SQL and FHIR, we provide generic Java-based adapters based on [4], which are configurable by a mapping file. The query results are subsequently used to evaluate expressions of composite phenotypes.

The whole process of modelling phenotypes and executing phenotype algorithms is depicted in Figure 1 [Fig. 1] and can be carried out by domain experts. Only adapters and an optional source system mapping must be provided by IT specialists. The mapping associates the terminology codes of the phenotype classes in the phenotype model with the corresponding data elements contained in the source system, e.g. FHIR resource types like ‘Observation’ and ‘Condition’ or SQL database tables and columns. In addition, value ranges contained in the phenotype algorithm can be modified. This is especially helpful to customise an algorithm to facility-specific norm values like laboratory thresholds. If the terminology codes and also value ranges in the phenotype model and in the source system are identical, the mapping can be omitted.

Based on the described methodological blueprint, we have developed an interactive web application, the TOP Framework (see Figure 2 [Fig. 2]). The framework is used by domain experts to develop phenotype models and execute phenotype algorithms. It consists of a JavaScript-based frontend, a Java Spring Backend, and a vendor-independent database. The framework can optionally be connected to an Ontology Lookup Service (version 3) [9]. The main functions provided by the corresponding user interface elements or API are the following:

1.

Developing phenotype models: Phenotype classes, attributes, relations, ranges, and expressions/formulas can be structurally defined.

2.

Storing and exporting phenotype models: Phenotype models are stored in a relational database and can be exported in different formats (e.g., Ontology Web Language, CSV or Decision Model and Notation).

3.

Execution of phenotype algorithms: Phenotype algorithms can be initiated by selecting a phenotype model (in-/exclusion criteria) and a source system. Depending on the selected source system, a suitable adapter is used to translate and execute queries in source system-specific language.

4.

Providing results: The number of patients/probands who fulfil all criteria of the phenotype model or also the corresponding data are provided in a machine and human readable format (e.g., CSV).

Furthermore, the framework allows search in existing phenotype models and supports, among other things, the creation of expressions for composite phenotypes and thus ensures syntactic correctness. Frontend and backend communicate over an API (the API’s OpenAPI specification is available in [10]), which can also be used to integrate backend functionalities into other software applications.

The framework was tested with randomly generated test data consisting of 10,000 patients with about 50,000 visits. We provided the data both in an SQL database and via a FHIR server and created corresponding mapping configurations. Queries to both source systems yielded identical result sets.

Typically, bioinformaticians, statisticians and comparable groups of people are tasked with implementing algorithms to detect individuals with specific traits. Since domain experts (i.e., medical staff) must provide the knowledge to implement such algorithms, very close collaboration between both groups is required [11]. Algorithms are often written in programming languages such as R, Python, Clinical Quality Language, which are more powerful and expressive than the TOP Framework but are not familiar to domain experts. As a result, there is no clear separation between modelling and implementation tasks. In addition, access to the source data must be implemented separately, e.g. using libraries such as FHIRcrackr [12] or FHIR-PYrate [13]. The TOP Framework can solve these issues by the described separation between phenotype models and phenotype algorithms. Consider phenotype models as different configurations applied to the generic phenotype algorithm described earlier. The framework provides a user interface suitable for domain experts to create such models and use them to compute or infer complex phenotypes for a given set of patient data, and to query patient data management systems for individuals with matching characteristics. Query results can be numbers of individuals or data sets containing selected patient characteristics for further statistical analysis. The approach of separating modelling and implementation tasks has been used previously by Uciteli et al. [14], [15], where ontological models built by domain experts were used to search text corpora and to identify perioperative risks.

The expressions used in the TOP Framework for modelling composite phenotypes are generic and thus suitable for mapping a large part, but not all, of the calculations and rules that occur in practice in algorithms. Some phenotypes can only be assessed using complex computations (e.g., Python and R scripts) or trained models (e.g., from machine learning). They are therefore not yet supported by the framework. In the future, we would like to integrate such complex calculations into the TOP Framework as external services.

The TOP Framework is a platform for easy definition of reusable phenotype models. All models can be accessed and referenced via URLs. However, the model is only partially standards compliant and introduces a proprietary format. To overcome this, we plan to extend the model with additional audit and metadata, and to enable automated transformation into community standard formats such as RDF with common annotations. This is in line with our commitment to the FAIR data principles [16].

The focus of our work was not to provide yet another query tool for patient and trial data, but to enable and encourage domain experts to build machine-readable and richly annotated models of phenotypes that can later be used to build queries. An initial overhead is required to build these models. Therefore, the framework does not support rapid query building as provided by tools such as FDPG [2], i2b2 [17], or tranSMART [18]. But there is no need for complex ETL jobs to pre-process patient or trial data. All queries are generated in the source-specific language and can be executed directly on the source system. In this work, we have focused on the query languages FHIR Search and SQL. However, the concept described here can also be used in conjunction with other query languages by implementing appropriate query adapters. Admittedly, the required mapping to source systems may be difficult for some database schemas or APIs – or even impossible in some cases if essential data is missing (e.g., terminology codes). However, the resulting framework is lightweight and has no requirements for the storage of patient data, and aspects such as data privacy can be handled by the source systems.

We have developed a methodology for modelling phenotypes and retrieving the corresponding data elements from patient data management systems and clinical research systems. The required tasks are clearly divided between domain experts and IT specialists. This computer-assisted approach can improve disease detection and clinical trial recruitment.

Source code for frontend and backend is available at https://github.com/Onto-Med/top-frontend and https://github.com/Onto-Med/top-backend. A user manual can be found at https://onto-med.github.io/top-deployment.

The authors declare that they have no competing interests.

This work was supported by the German Federal Ministry of Education and Research as part of the projects SMITH TOP (reference number: 01ZZ2018) and SMITH (reference number: 01ZZ1803A).