## 2 Materials and Methods
### From Idea to Result Set  
This section outlines the steps and expected effort required by a facility holding patient data to define phenotypic knowledge, generate and execute the queries, and obtain a resulting data set. Each step has individual requirements for the expertise of the person performing it. The premise here is that a facility stores its patient data in a database system or software component with an application programming interface (API). APIs are softwareinterfaces that can be used by other software components to access functionalities. We will use them to search and access the facility's data.  
First, there must be an interface in place which is capable of converting a PheSO into appropriate queries that are further on executed on the underlying patient data store. This interface must be implemented by a software developer. One can implement different translators or adapters from the ontological model to the respective query languages or just one translator (e.g., for SPARQL) but with different mappings of the respective data sources to a suitable representation (e.g., using OBDA [15,16] or direct transformation in RDF or OWL). This makes no difference in our approach. For instance, the developer can use the Phenotype Ontology Manager Core API (PhenoMan) [23], which is implemented in Java using the OWL API. PhenoMan was initially developed in the SMITH project [26], and it provides simple methods to read, write, and reason with phenotype classes in PheSOs. PhenoMan can be used to access the phenotype classes in a PheSO and convert them into API calls to the facility data store (e.g., FHIR Search queries). In case the data store supports standardised interfaces such as FHIR Search, such an interface may already exist and will only require a few customisations. An example of an FHIR Search connection is described in the results section.  
Before queries can be generated and executed, a PheSO must be modelled by a domain expert. Depending on the patient cohort to be described by the query, additional literature research may be required to carefully collect phenotypes from previous scientific findings. By using tools such as Protege [25] or the Phenotype Editor [23], and with the help of ontologists, domain experts create several single phenotype classes that serve as basic components for modelling composite phenotype classes. By marking specific classes as inclusion or exclusion criteria, a coherent description of the desired cohort is produced.  
The amount of time required to build a PheSO highly depends on the complexity of the phenotype classes describing the cohort and varies from some minutes to a few hours. Formalised algorithms already available (e.g., Type 2 Diabetes Mellitus in PheKB [27]) can significantly simplify the modelling process, and previously built PheSOs may be reusable for multiple queries. Domain experts could also prepare a set of frequently used phenotype classes to streamline and speed up the modelling process.  
Ideally, the patient data store interface has a graphical user interface through which domain experts can upload--or even build--their PheSO and execute it. The PheSO is then converted to one or multiple internal queries (i.e., API calls), and the resulting patient cohort is returned to the user. The user does not need to know the underlying query language used by the data store. The execution time depends on the type of the data store as well as the implementation of the interface and complexity of the query. Figure 4 shows the layout of a potential architecture for building PheSOs in a graphical user interface, transforming them into data source queries and retrieving the resulting data sets.