The most well-known example of a centralized terminology service is the BioPortal [12] repository, from the National Center for Biomedical Ontology (NCBO), which provides over 900 biomedical ontologies. Another example is Ontoserver [13], which is based on the Fast Health Interoperability Resources (FHIR) standard and includes a syndication mechanism to facilitate the versioning of terminologies. Ontoserver is available via a commercial software license and has been selected by NHS Digital UK and Nictiz Netherlands [14]. Several organizations make use of the HL7 \({}^{\text{\textregistered}}\) FHIR \({}^{\text{\textregistered}}\) Application Programming Interface (API) to enable access to current terminology content, e.g., LOINC is offering the LOINC FHIR Terminology Server [15] based on the HL7 \({}^{\text{\textregistered}}\) FHIR \({}^{\text{\textregistered}}\) API. However, this solution provides access to one single standard and only the current version. The Unified Medical Language System (UMLS) offers a meta-level view on concepts from many biomedical vocabularies and provides a crosswalk between them [16]. It can also be observed that hospitals start to develop their own terminology server in order to increase the quality of the clinical data [17]. All of these solutions have their benefits and advantages specifically targeted to certain application scenarios and they support semantic interoperability. Figure 1: Two possible options for the architecture of a terminology service. Option 1 shows a centralized terminology service while Option 2 shows a federated terminology service (the SPHN-preferred option). For the SPHN DCC Terminology Service, the following five main requirements have been identified: the terminology service must fit into the distributed project setting of the SPHN; comply with the stringent security requirements necessary to analyze clinical data; support the local Swiss setting and at the same time, ensure it is compatible with the SPHN Resource Description Framework (RDF) schema; deal with the continuous change in the terminologies and cope with the different license models of the terminologies. Distributed project setting in the SPHN: The distributed project setting demands that a data producer, for example, a hospital, can obtain the terminologies in RDF (Turtle and OWL format); therefore, they can also use the data for validating the data assets being submitted. A data consumer, for example, a research project, needs the terminologies in an RDF format to link the terminologies to the hospital data. To avoid increasing the volume of the hospital data and to reduce the possibility of errors, the terminology data, such as hierarchy or property information, should not be sent by hospitals to the research project space together with the patient data, but should be provided to the researcher separately through the terminology service. Security requirements: SPHN projects are hosted on the BioMedIT network [18], a service provider infrastructure for research with sensitive data built as an integral part of the SPHN. Each project is provided with a secure isolated project space for data storage and analysis on a BioMedIT node. A project space in BioMedIT is set up to fulfill the stringent security requirements to ensure the necessary data protection. The connection from the project space to the internet is limited and data, as well as other resources such as terminologies, need to come from a trusted source. A similar setup is observed in the hospitals. Additionally, when sending a SPARQL Protocol and RDF Query Language (SPARQL) query to a SPARQL endpoint, a SPARQL federation blends the data; therefore, it is important to ensure that no confidential data are sent to the SPARQL interface outside an institution.