## 2 Materials and Methods  
### Approach Overview  
Phenotypes are the observable characteristics [18; 19; 20] of an individual. These include clinical conditions [6] as they have been obtained from clinical patient care processes. Therefore, we consider \"phenotypic queries\" as queries that can be used to search for individuals (patients or study participants) with specific phenotypes. A scientist could be interested, for example, in finding male individuals 20-40 years old and having a BMI greater than 30 kg/m\({}^{2}\) and diagnosed heart failure.  
By building phenotypic queries in a machine-readable format, they become executable on electronically available data (e.g., electronic health records). Phenotypic queries return a set of individuals meeting the criteria described by the query. Thus, the goal of such phenotypic queries is to return a subset of the available individual's data mostly represented by a corresponding (patient) identifier. In a further step, this identifier set can be used to retrieve additional data for the selected individuals.  
Phenotypic queries can be used in the research context, in patient care, and in administrative processes. For example, cohorts for studies are definable [21], which may consist of complex concatenations of phenotype classes. On the other hand, treatment centres could implement queries to stratify patients into phenotype (sub)classes and thus provide the best available care for each of them [22]. Finally, phenotypic queries may be used as a data curation tool. Consider a scenario where (combinations of) implausible value ranges are specified in phenotypic queries that are used to search for corresponding (possibly incorrect) patient data in EHRs.  
We propose a multi-level approach allowing the specification of phenotypic knowledge on an abstract level first. The knowledge is then transformed into specific, already available, and often widely used query languages such as SPARQL for RDF- or OWL-based data, SQL for Relational Database Management Systems (RDMS), and HL7 FHIR Search for FHIR systems. Queries in these query languages can then be directly executed within specific data management systems. The advantage of this approach is twofold. First, phenotypic knowledge can be formally specified without any implementation-specific syntax necessary for the used data management system. By separating the formal aspect from implementation specialities, the end users (especially non-computer scientists) can model such knowledge without knowing the implementation syntax. By providing translator and adapter tools, the phenotypic knowledge can then be converted into desired query languages (e.g., SPARQL, SQL, or FHIR Search). Second, such ontological specifications and their parts (e.g., single classes) are reusable and applicable on different source systems by using suitable adapters.  
Following this multi-level approach (see Figure 1 for an overview), we use the Core Ontology of Phenotypes (COP) [23] on the top level as a general phenotypic model. The COP provides the basic building blocks (i.e., types of classes, properties, and axioms) and a common structure (i.e., taxonomy and other relations) which must be used by each use case's specific phenotypic model. Each specific model is in turn managed in a Phenotype Specification Ontology (PheSO) that integrates the COP and follows the structure the COP provides (e.g., the PheSO classes are subclasses of the COP classes). The translator tools are based on the COP (i.e., they know the general structure of all PheSOs) and can generate queries from PheSOs in a corresponding query language.  
We describe the COP and the query building process in more detail throughout the next subsections.