SPHN Connector - A scalable pipeline for generating validated knowledge graphs from federated and semantically enriched health data

SPHN Connector - A scalable pipeline for generating validated knowledge graphs from federated and semantically enriched health data | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF software SPHN Connector - A scalable pipeline for generating validated knowledge graphs from federated and semantically enriched health data Vasundra Touré, Deepak Unni, Philip Krauss, Andrea Brites Marto, and 4 more This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-7930982/v1 This work is licensed under a CC BY 4.0 License Status: Published Journal Publication published 13 Feb, 2026 Read the published version in BMC Medical Informatics and Decision Making → Version 1 posted 9 You are reading this latest preprint version Abstract Background: The integration and reuse of heterogeneous health data, including clinical records, cohort studies, and omics datasets, are essential for advancing modern biomedical research. Knowledge graphs offer a powerful means to semantically link such data, enabling interoperability and reuse. The Swiss Personalized Health Network has developed a comprehensive semantic interoperability framework to implement the FAIR (Findable, Accessible, Interoperable, Reusable) principles at a national level. Methods: This paper presents the adopted strategy and the resulting tool for building such federated knowledge graphs, marking a shift from centralized approaches to a model where hospitals and research partners semantically enrich and produce their own data locally. Results: A core component enabling the implementation of this strategy is the SPHN Connector, a tool designed to tackle the technical challenges of this process. It converts diverse data formats into semantically enriched RDF, and offers capabilities for data transformation, de-identification, and validation, particularly for iterative delivery in a federated context. Conclusion: These generated datasets can then either be integrated centrally or used in a federated way, allowing for the linkage of information from the same patient, for example, clinical routine data and omics metadata, as well as the combination of data from different patients across sites. Knowledge graphs Semantic Web Linked Data Data Provisioning Clinical Real-World Data Figures Figure 1 Figure 2 Figure 3 Figure 4 Background The integration and reuse of heterogeneous health data, ranging from clinical routine records to cohort studies and omics datasets, has become central to modern biomedical research [1]. Semantic knowledge graphs (KGs) have emerged as a powerful paradigm to link data, harmonizing data structure while preserving meaning through semantic representations. Within the Swiss Personalized Health Network (SPHN), a comprehensive semantic interoperability framework has been developed to support the FAIR (Findable, Accessible, Interoperable, Reusable) principles [2]. This framework is centered around the SPHN RDF (Resource Description Framework [3]) Schema [4], defining the blueprint for health data representation using Semantic Web technologies. Beyond the core schema, project-specific extensions enrich the SPHN RDF Schema with additional field-specific semantics. Whether core or extended, the RDF Schema is complemented by Semantic Web artefacts such as Shapes Constraint Language (SHACL [5]) validation rules and SPARQL Protocol and RDF Query Language (SPARQL [6]) data exploration queries, which are automatically generated with the SPHN Schema Forge tool [7]. Standard terminologies, such as Systematized Nomenclature of Medicine - Clinical Terms (SNOMED CT) [8], Logical Observation Identifiers Names and Codes (LOINC), Anatomical Therapeutic Chemical (ATC) [9], and International Statistical Classification of Diseases and Related Health Problems 10th revision German modification (ICD-10-GM) [10], are provided in RDF with the DCC Terminology Service [11]. Leveraging these resources, data providers transform their local datasets into RDF representations that conform with the SPHN RDF Schema for interoperable, consistent and reusable datasets. Several leading initiatives build biological and biomedical KGs using an Extract-Transform-Load (ETL) approach where data from heterogeneous sources are extracted, semantically enriched and harmonized using domain-specific ontologies, and loaded into a graph-based store for querying and analysis. Bio2RDF [12] is an early effort that converts resources like UniProt [13] and DrugBank [14] into RDF, mapping identifiers to URIs and linking datasets for querying. The Monarch Initiative [15], which focuses on integrating cross-species genotype-phenotype data from various sources, harmonized with the Open Biological and Biomedical Ontologies (OBO) Foundry ontologies for phenotype-driven rare disease diagnosis and translational research [16,17]. The Knowledge Graph Hub [18] offers reusable ETL components, where data sources are mapped to the Biolink Model [19], to generate a KG enriched with biomedical associations. PheKnowLator [20] is another example that automates the construction of semantically rich KGs using ontologies and OWL reasoning. The Blue Brain Nexus [21] offers a scalable, provenance-aware linked data platform designed for neuroscience but also supporting the broader biomedical domain. While these examples demonstrate the diversity and maturity of tools for biomedical KG construction, very few target routine clinical data where privacy, heterogeneity, and governance make the integration challenging. Most existing biomedical KGs are generated centrally, with source data aggregated into a single repository before, during, or after transformation. Some Initiatives that deal with clinical data include the Observational Health Data Sciences and Informatics (OHDSI) network that harmonizes distributed clinical databases into the Observational Medical Outcomes Partnership (OMOP) Common Data Model [22,23] and enables federated analytics; and the European Health Data & Evidence Network (EHDEN) which operates a large-scale OMOP-based privacy-preserving network for real-world evidence data. SPHN takes a federated approach in which the KG is conceptually unified but generated locally at participating data providers (i.e. university hospitals). This ensures semantic interoperability without centralizing the sensitive patient-level information, while remaining consistent with the Swiss-specific ethical and legal framework. Resulting datasets can be subsequently integrated within trusted research environments tailored for processing health-related data (i.e. BioMedIT [24]), where information about the same patient from multiple sources can be linked for research purposes. For instance, combining clinical routine data across hospitals with omics metadata generated by research platforms. Building federated KGs in healthcare however presents several challenges. Data providers must extract, transform, and deliver locally maintained data according to national or project-specific standards, which is a technically demanding task. Data comes in diverse formats (CSV, relational databases, JSON [25], FHIR [26]) making RDF transformation complex. Data providers are further responsible for ensuring data quality, performing technical validation, and applying privacy-preserving measures such as patient de-identification, all at scale [27]. Additionally, expertise in KG technologies can be rare among data providers, which poses additional challenges when implementing these processes. To meet these demands, stakeholders have expressed a strong need for structured guidance and practical tools. In response, SPHN developed a methodology that enforces schema-driven transformation and reduces the burden on data providers. This methodology laid the foundation for the SPHN Connector, a unified tool that implements various strategies to realize the goal of consistent schema-driven transformation. The SPHN Connector supports data providers in producing semantically structured and valid data aligned with the SPHN Semantic Interoperability Framework. By automating key steps such as de-identification for privacy-preserving, conversion, and validation, it lowers technical barriers to semantic data processing and enables scalable production of FAIR, high-quality data for federated KG construction within the SPHN ecosystem. Methods To support the creation of semantically rich KGs aligned with the SPHN Semantic Interoperability Framework, we established a methodology integrating conceptual foundations with technical design decisions. This approach was driven by the need to address key challenges and stakeholder requirements for facilitating downstream integration of heterogeneous health data across institutions. These methods have driven the implementation of the SPHN Connector for a successful deployment and use in university hospitals. The technical challenges in distributed KG creation can be characterized along three, often interrelated, dimensions: Data heterogeneity: Distributed KG generation involves the integration of data from diverse sources which often differ in format and layout. Further complications arise from differences in language, variation in semantic representation, and data quality. Heterogenous infrastructures and tooling: In distributed environments, data and processing pipelines are often heterogeneous even when built to generate data conforming to a prescribed data model. The tools used for data extraction and transformation each have their own internal data models which can affect how source data is mapped and transformed. Variability in user tool usage: The stakeholders involved in KG generation are often data engineers, data scientists, and software developers. Their approach to KG generation varies depending on their expertise, appreciation of the semantics, and understanding of the target data model. These challenges were identified through stakeholder discussions and requirements gathering. Moreover, the SPHN Connector is operated by personnel at the data-providing institutions, often without direct supervision of the transformation process, highlighting the need for robust, automated, and reproducible workflows. Here we describe both the conceptual strategies and corresponding technical implementations built on the SPHN framework. General tool requirements 1.1 Data ingestion aligned with data provider’s input SPHN requires that project data is delivered in RDF. Data providers expressed the need for a tool that would facilitate this process by enabling data transformation from input formats that are closely aligned with their existing systems. This would minimize the need for them to acquire in-depth knowledge of RDF. To address this, the SPHN Connector provides dedicated ingestion interfaces for JSON, tabular formats (CSV/Excel), and relational databases (RDBMS). While the syntactical format in RDF is less of an issue, the way information is structured according to a specific schema (e.g. the SPHN RDF Schema) in RDF is critical. 1.2 Multi-project handling As the SPHN RDF Schema continues to evolve and projects have the possibility to define their own semantics, an important requirement was to support multiple projects within a single instance of the SPHN Connector. To meet this requirement, projects are strictly isolated from one another with respect to their schema definitions, patient identifiers, database views, and populated tables. Patient information is not shared across projects but must instead be duplicated within each project context to reduce complexity and ensure project independence. However, within a project, project configurations and de-identifications rules persist across data deliveries. 1.3 Minimize dependencies on manual work Parts of the data processing pipeline (i.e. population of data ingestion interfaces, along with the transformation and validation rules) are automatically derived from the SPHN RDF Schema and optionally a compliant project schema (see Figure 1). This approach ensures that compliant project schemata can be directly used without requiring additional manual or central effort. In addition, this reduces the potential source for errors in the long term as schema modeling patterns and their combination stabilize over time, not every project combination needs to be tested exhaustively. 1.4 Data protection and maintenance considerations Data providers handle sensitive patient data, including real patient identifiers in some cases. Given the potentially large number of patients and extensive data points, ensuring robust security and maintainability is critical. To address these concerns, the tool must be installed and operated by the data provider in their local environment. The setup and deployment process is designed to be transparent and compliant with the data provider’s security requirements. Key technical features supported in the SPHN Connector include: Ability to run in Docker rootless mode; Compatibility with Windows and Linux systems; Ability to support offline and air-gapped execution, where runtime changes are forbidden; A dedicated API, enabling the automation of various processes within a workflow; User and password management for access. These choices ensure secure and reliable operation of the tool in line with institutional policies. 1.5 Computational performance and scaling A key requirement was the need for a tool that runs efficiently, even on limited computational infrastructures without requiring specialized hardware or complex system dependencies. The SPHN Connector is designed to operate on standard environments with a minimum of 16 GB RAM, 4 CPUs, and 500 GB of disk space. Additionally, from an operational perspective, it was necessary to avoid generating overlapping patient files. To achieve this, the SPHN Connector adopts a patient-oriented workflow, which processes the data on a per-patient basis. This design choice ensures adoption across all partners, where each environment can vary in capacity and configuration but also to ensure consistency and simplification of data handling. To meet this requirement, core libraries were carefully selected and optimized: For parsing and validating RDF data, we integrated a high-performance RDF parser implemented in Rust and accessed through Python bindings (LightRDF [28]). For JSON Schema validation, several alternatives were benchmarked and found unreliable. The jsonschema [29] library was selected as the most reliable in ensuring correctness while maintaining efficiency. For the RDF conversion, RML [30] (RMLmapper-java [31]) was chosen to convert the internal JSON files into RDF files based on the RML configuration created. The library was selected for the implementation of the flexible RML language for the mapping (unlike R2RML, which only supports relational databases to RDF transformation; RML extends it to also supports multiple data sources such as JSON, CSV and XML), its performance and scaling capabilities. For RDF validation, the SPHN Connector leverages the SPHN RDF Quality Control (QC) framework to adhere to the workflow [32], a Java-based solution that performs two key operations: 1) checking RDF data compliance with the schema based on SHACL constraints and generating a comprehensive report, and 2) calculating quantitative statistics to evaluate data completeness using SPARQL queries. An adapted version of the QC tool is integrated. For example, external terminologies are defined as constants and modeled as static elements to reduce computational overhead and improve validation performance. Finally, to address storage scalability, the SPHN Connector supports data integration with external S3 storage for handling large datasets efficiently. On the compute side, the pipeline offers capabilities for multi-processor and multi-threaded runs across all steps, especially beneficial for computationally intensive phases such as de-identification and validation. These optimizations ensure scalability without overloading the local infrastructure and ensure a reliable performance across diverse environments. Knowledge Graph architectural decisions The production and long-term management of a KG requires the design of clear architectural principles. The following subsections describe some of the key decisions embedded in the SPHN Connector that go beyond the semantic definitions of the SPHN RDF Schema. 2.1 IRI naming convention to prevent clashes In a federated setting with multiple institutions contributing data independently, a consistent and collision-free identification of data instances is essential for a reliable graph construction. To avoid ambiguity and preserve data integrity, the SPHN framework defines a structured Internationalized Resource Identifier (IRI) convention documented in [33] and composed of: i. The data provider identifier, based on the unique identifier number for enterprises applied in Switzerland (UID [34]) ii. A prefix specifying the schema from which the instance data originates (e.g. SPHN or project-specific prefix) iii. A class name reflecting the type of the instance (defined in the schema) iv. A unique identifier defined by the data provider for that particular instance data. Technically, the SPHN Connector automatically fills i, ii and iii. This leaves only the last part of the identifier as input to the data provider. This convention guarantees globally unique IRIs, avoiding collisions when decentralized data is merged. 2.2 Linking patient/sample information across providers In real-world scenarios, research projects often require linking data elements across institutions (e.g. routine clinical data from multiple hospitals) and domains (e.g. linking electronic health records with laboratory results or imaging data). In Switzerland, no national unique patient identifier exists for research purposes, meaning each institution assigns its own identifier. Without coordination, these identifiers remain distinct, preventing linkage across datasets. Within SPHN projects, when legally and ethically approved, participating data providers may agree on and use a shared identifier for linkage. This identifier enables the association of common elements across datasets, indicating that they refer to the same patient or sample, even though they originate from different sources. To support this process, the SPHN RDF Schema includes the property sphn:hasSharedIdentifier, which institutions populate during data transformation. Note that the mapping is managed by the data providers themselves: the SPHN Connector does not perform linkage across patients but enables providers to include the agreed identifier. 2.3. Streamline data updates and deletions using named graphs Supporting evolving patient records by enabling delta loads without reprocessing entire datasets was a crucial design goal. For instance, when a patient has a new hospital visit or additional lab results become available, only the newly acquired information needs to be added. In contrast, if a patient revokes consent, it becomes important for data users to delete all data associated with that patient. This is facilitated by organizing RDF data into named graphs, with each patient’s data encapsulated within a separate “subgraph”, which enforces patient atomicity. As a result, updates are more efficient because they are applied to individual patient graphs without having to reload data for all patients. While there’s no support in the SPHN Connector for incremental updates to a patient's information, named graphs allow for updates in downstream systems. This structure enhances scalability during iterative data deliveries as it doesn’t affect unrelated patient records. On the data user side, this design also makes revocation handling straightforward: deleting a patient’s data simply involves removing their corresponding named graph via a SPARQL update. The SPHN Connector supports multiple RDF serialization formats, including TriG and N-Quads, ensuring compatibility with triplestores and downstream pipelines. While architectural choices improve scalability and data management, ensuring patient data privacy and integrity remains critical. The following section details measures implemented in the SPHN Connector to address these aspects. Measures for data integrity and privacy 3.1 De-identification While not mandated within SPHN, integrated de-identification capabilities are crucial to provide a practical solution for users beyond the core five university hospitals, thereby addressing the critical requirement of handling the privacy of personally identifiable information. By default, de-identification is not applied, leaving control to the user, who must explicitly configure it. De-identification is currently supported for data ingested via RDBMS, JSON, CSV, and Excel formats. The de-identification rules must be specified in a JSON configuration file when setting up a project in the SPHN Connector. At a minimum, SPHN recommends specifying parameters for fields related to Subject Pseudo Identifier, Administrative Case, and Sample (concepts defined in the SPHN RDF Schema) along with date-shift rules. The SPHN Connector supports four de-identification strategies, each designed to protect sensitive data: Field scrambling: This method generates unique, pseudonymized identifiers for selected fields. The uniqueness is parallelizable and is not based on any content information of the patient. The scrambling ensures that values cannot be traced back to their original form but still remain consistent across datasets. Field scrambling is typically applied to fields that have unique identifiers as their value. Date shift: All date values associated with concepts, such as Birth, Admission, and Diagnosis, can be shifted by a random number of days selected from a range defined in the configuration. However, the shift is consistently applied across all records of a given patient, such that temporal relationships are preserved. Field substitution list: For one or more fields, this method allows sensitive values to be replaced with a sensible substitution or a placeholder string. The field(s), list of sensitive values, and replacement string are configured by the user. Field substitution regex: This method is similar to the field substitution list but uses regular expression (regex) patterns to detect values that match a certain structure. Matching values are replaced with a corresponding replacement string. The SPHN Connector applies de-identification to specified concepts using a Universally Unique Identifier (UUID)-based function [35] with a salting mechanism, and maintains a comprehensive log of data modifications, reported to the user. The logs enable users to apply the same de-identification to subsequent data submissions for the same patient, thereby ensuring data consistency and privacy. Alternatively, the SPHN Connector offers an option to disable logging, which is suitable only for one-off de-identified data preparation and export. 3.2 Data integrity through validation Data validation is crucial to guarantee both syntactic correctness and semantic coherence, ensuring consistent modeling and interpretation of heterogeneous data. The SPHN Connector implements multiple validation steps throughout the data processing workflow. The first layer of validation ensures that incoming data conforms to the expected structure and basic constraints before any transformation occurs. For JSON data, this is achieved through JSON Schema validation, which verifies data types, required fields, and structural rules. For relational tables, Structured Query Language (SQL) constraints in the table and type definitions enforce similar checks. For example, value sets defined in the RDF schema are mapped to specific data types in PostgreSQL [36], restricting ingestion to permitted values only. This pre-validation catches structural inconsistencies or type mismatches early, reducing downstream errors during data transformation and RDF generation. In addition, a pre-check step is performed to ensure that certain fields are correctly formatted. For instance, it verifies that a value is a valid IRI (without spaces or invalid characters). While the SPHN RDF Schema defines the expected structure (blueprint), it does not enforce compliance. This is where SHACL plays a crucial role by translating the RDF schema rules into machine-actionable validation constraints. SHACL constraints define allowed values, cardinalities, and coding expectations, enabling the automated detection of both structural (e.g. missing mandatory metadata) and semantic inconsistencies (e.g. use of outdated or incorrect codes in the data). RDF validation ensures data integrity and compliance with the schema restrictions. These SHACL rules are automatically generated during project setup, whether the schema is the core SPHN RDF Schema or a project-specific one, using the Python-based SHACLer tool [37]. To further ensure semantic precision, versioned terminologies for ATC, Swiss Classification of Surgical Interventions (CHOP) and ICD-10-GM (with French and Italian translations, version provided by the Swiss Federal Office of Statistics) [38] are integrated into the validation process to ensure data is aligned with the correct vocabulary version. Together, schema enforcement and terminology validation guarantee that the transformed RDF data adheres to the specifications and supports interoperability. With validation and de-identification strategies in place, the SPHN Connector orchestrates a structured workflow to transform and deliver semantically compliant RDF data. The following section outlines this workflow from data ingestion to data export. Data workflow in SPHN Connector The SPHN Connector follows a structured workflow to transform patient data into semantically validated and possibly de-identified RDF data aligned with the SPHN Semantic Interoperability Framework (see Figure 2). The API, built using FastAPI [39], is the entry point for most operations in the SPHN Connector. At project setup, users provide the SPHN RDF Schema, possibly complemented by a project-specific RDF Schema extension, to which their data should conform, along with external terminologies from the SPHN core or project-specific extensions, for code validation and the expected RDF output format (e.g. Turtle, N-Quads, Trig). Optionally, a de-identification file in JSON format may be supplied as described in the section above. From the data schema, the SPHN Connector automatically generates all components, including the input mapping interfaces, and SHACL queries using the SPHN SHACLer, used in the validation step (see Figure 1). The SPHN Connector automatically generates templates (i.e. JSON Schema, CSV/Excel templates, and Data Definition Language (DDL) statements) based on the SPHN RDF Schema (see Figure 3). The design and structure of these templates are documented in the SPHN Connector user guide, updated with each release [40]. These templates allow users to prepare their local data marts in alignment with SPHN semantics. The API supports five ingestion interfaces: RDF, JSON, CSV, Excel, and relational database (RDBMS). The schema defines concepts, including those directly linked to the patient (i.e. the Subject Pseudo Identifier concept), which are considered “core concepts”. For example, in the SQL DDL (tabular) template, each core concept is represented as a separate table. These tables contain one column for each associated metadata defined in the schema. When a core concept is linked to another core concept, the relationship is captured by including only the identifier of the linked concept in the referencing table. The full metadata for the linked concept is stored in its own dedicated table. For example, ‘Birth’ and ‘Body Height Measurement’ are two concepts that are each directly linked to the ‘Subject Pseudo Identifier’. As such, the SPHN Connector generates separate tables for each of these concepts. The ‘Body Height Measurement’ concept is associated with the ‘Birth’ concept to capture height measurements taken at birth. In this case, the ‘Body Height Measurement’ table includes a column for the identifier of a ‘Birth’ instance. This identifier should correspond to one of the entries in the ‘Birth’ table, which contains all associated metadata for that birth event. This identifier linkage between the two tables is taken care of by the user of the SPHN Connector. The ‘Body Height Measurement’ concept is further associated with the ‘Body Height’ concept, which is not a core concept. In this case, all the metadata of the ‘Body Height’ is directly embedded in the ‘Body Height Measurement’ table. These approaches enable the reflection of graph-like relationships in a tabular structure, where links between entities are represented through identifiers rather than nested or interconnected data while optimizing the number of columns populated. Data can be submitted patient by patient or in batches via (external) S3-compatible or MinIO (within the SPHN Connector) storage when not using the Database ingestion mode. The SPHN Connector also provides a pgAdmin interface for database management and monitoring. The interface allows users to securely connect to the underlying PostgreSQL database, explore the database and manage tables. Typically, users find pgAdmin to be a useful debugging tool for investigating and resolving potential issues in their data after it has been ingested via the ingestion interface. The process in the SPHN Connector follows a data lake architecture, where records move through clearly defined zones and are stored as files, enabling users to view content at different stages without the need for dedicated tools. After ingestion, data is normalized into a JSON structure, which serves as an intermediate format to support automated quality-control checks when data reaches the Landing Zone, including validation of Code and Terminology mappings and verification of IRIs. At this stage, de-identification rules can also be applied, ensuring pseudonymization or anonymization in line with project specifications. Data is then converted into RDF using RML mappings, ensuring alignment with the SPHN RDF Schema defined during configuration. The transformed data undergoes SHACL and SPARQL-based validation against SPHN semantics and standard terminologies provided during the project setup. A detailed log is generated allowing users to track errors, warnings, and failing patient records. The generated RDF patient data (even those failing validation) are transferred to the Release Zone, where users can download RDF data and associated quality control reports. Finally, RDF patient files can be shared with research projects through secure infrastructures such as BioMedIT. Throughout the workflow, processes are monitored and orchestrated using Apache Airflow, a workflow execution and management platform, for better traceability and supporting systematic debugging. Results Knowledge graph The proposed strategy for federating KGs through localized RDF data production and centralized combination addresses several core challenges in cross-institutional biomedical data integration. The design was evaluated based on its ability to meet key criteria for semantic interoperability, identifier uniqueness, updatability, and patient-level data governance. Results are summarized across the following focus areas: Identifier management to ensure global data uniqueness and prevent collisions Cross-provider linkage of patients and samples via shared identifiers, to bridge otherwise siloed records Modular updates and deletions using named graphs, to support delta loads and consent revocation management Tracking versions of specific terminology codes, to track semantic integrity across heterogeneous terminology practices SPHN Connector The SPHN Connector is developed for enabling a schema-driven data transformation, as defined by the SPHN Semantic Interoperability Framework, and provided under the GNU General Public License v3.0 (GPLv3) open-source license. It transforms heterogeneous health data from different input formats (e.g. CSV, Excel, JSON, relational databases) into semantically enriched RDF data conforming to the SPHN RDF Schema [Touré et al, 2023]. Guided by the SPHN-specific schema provided as input, the tool interprets and maps the source elements to RDF triples using an RML mapping mechanism. The generated triples are then validated for semantic correctness, including adherence to SPHN naming conventions and alignment with international terminologies such as SNOMED CT, LOINC, and ICD-10-GM, using SHACL constraints. The resulting RDF graphs are constructed using W3C standards for linked data, including RDF, RDFS, and OWL, ensuring interoperability and enabling data integration into a unified federated KG. This approach supports data linkage across different modalities (e.g. clinical, omics) and institutions, enabling advanced querying and applications in biomedical research. Although the SPHN Connector operates as a fully automated system from the user’s perspective, it remains fully documented and transparent, allowing detailed inspection and analysis of its internal processes. As of 2025, the SPHN Connector is deployed in production across the clinical data platforms of all Swiss university hospitals (University Hospital Basel, University Hospital Bern, Geneva University Hospitals, University Hospital of Lausanne, University Hospital Zurich, and the University Children’s Hospital Zurich) as well as in additional Swiss cantonal hospitals (e.g. Ente ospedaliero cantonale, Cantonal Hospital Baden, Cantonal Hospital Aargau, Cantonal Hospital Lucerne, and Cantonal Hospital St. Gallen). In a real-world scenario, we benchmarked the SPHN Connector at the University Hospital Zurich (USZ). The system was run in production with 8 CPUs, 48 GB RAM, and 500 GB disk space to transform 120,203 patients from a local relational database into PostgreSQL. From PostgreSQL to JSON conversion (including de-identification with date shift) through validation and delivery into RDF, the process required 3 days and 19 hours (see Table 1.). Without de-identification, the conversion completed in 2 days and 20 hours. This resulted in the production of two billion RDF triples across all patients, with individual patient RDF files (in TriG format) averaging 1 MB. The variation in file size reflects clinical data heterogeneity, from patients with minimal encounter records to those with comprehensive longitudinal data spanning multiple clinical domains. On average, each patient required approximately 2.7s (with de-identification) or 2.1s (without) of processing time. Validation is the most time-consuming step (48% without de-identification, 36% with) and its duration is correlated with the number of schema violations detected, making data quality a key determinant for an efficient processing of data. De-identification is also a time-consuming step (0.8s vs. 0.1s pre-check time for one patient on average with and without de-identification). Since this step is optional, data providers may use their own solutions (maybe more efficient) to de-identify data prior to ingestion into the SPHN Connector to accelerate the transformation process. Table 1. Duration of each SPHN Connector phase at USZ in two separate runs. a) Run 1 Duration all patients Duration all patients (in seconds) Average duration per patient (in seconds) PostgreSQL to JSON conversion 01d 01:43:49 92 629 0.771 Pre-check & de-identification 01d 01:48:45 92 925 0.773 Integration 00d 06:35:21 23 721 0.197 Validation 01d 09:00:16 118 816 0.988 Total 03d 19:08:11 328 091 2.729 b) Run 2 Duration all patients Duration all patients (in seconds) Average duration per patient (in seconds) PostgreSQL to JSON conversion 01d 01:43:49 92 629 0.771 Pre-check 00d 03:13:36 11 616 0.097 Integration 00d 06:35:21 23 721 0.197 Validation 01d 09:00:16 118 816 0.988 Total 02d 20:33:02 246 782 2.053 This table reports the execution time of each phase (PostgreSQL to JSON conversion, Pre-check, Integration and Validation), as well as the total processing time for 120,000 patients processed in 12 batches. The average duration of each phase for each patient is also calculated. Two runs were performed: one including de-identification (a) and one without (b). Both runs were executed on an infrastructure with 8 CPUs, 48 GB RAM and 500 GB of disk space. The processing generated approximately two billion RDF triples, with an average RDF file size per patient of 1MB (minimum: 12KB; maximum: 107MB). Ingestion into PostgreSQL is ignored as this step is heavily dependent on the provider setup and tooling. Discussion The implementation of the above-mentioned strategies reduces operational complexity, lowers the risk of transformation errors, and enhances reproducibility across data deliveries. By embedding validation rules directly into the tool and ensuring that all transformations follow a predictable and version-controlled path, the SPHN Connector fosters institutional trust in the data production process. Integration with external tools is intentionally modular, enabling the SPHN Connector to operate within diverse workflows while minimizing the impact of changes in external systems. Ultimately, this approach not only reduces the technical burden on hospital IT teams but also improves the quality and interoperability of the data. Once transformed into RDF KGs, data can be utilized in different architectural setups depending on governance and analysis needs. While these choices define how data can be stored and queried, practical deployment decisions are shaped by operational constraints and stakeholder feedback. In one approach, the data can be centralized within a trusted research environment (see Figure 4A), where central quality control, additional data curation and linking with other data, such as genomics or cohort data, is possible. Alternatively, a federated model can be employed (see Figure 4B), in which each institution maintains its own local triplestore. In this scenario, queries can be executed across distributed data sources, allowing analyses to be performed without requiring sensitive patient-level data to leave institutional boundaries. Both approaches ensure that the semantic richness of KGs can be exploited for downstream research while respecting local constraints. However, while the SPHN Connector addresses a broad range of challenges, it is important to clarify its intended scope and limitations to avoid misinterpretation or unrealistic expectations. The SPHN Connector focuses on data transformation and validation. It is not a triplestore as it does not provide capabilities for RDF storage, querying, merging, or reasoning over graphs. In addition, the SPHN Connector does not aim to correct data errors from the source. It validates and reports inconsistencies with the definitions of the schema and terminologies but it is the responsibility of the data provider to ensure the accuracy and completeness of the source data. Finally, mapping of local terms to standard terminologies also remains the responsibility of the data provider as this requires domain-specific knowledge. Mapping involves decisions about clinical meaning, local coding practices, and institutional semantics, which cannot be automated or standardized centrally without risking misinterpretation or loss of critical information. Hence, this mapping must be done before using the tool and lies within the responsibility of the data provider. While emerging approaches such as artificial intelligence and large language models could potentially assist with these tasks. During the design and implementation of the SPHN Connector, several discussions were held with stakeholders on possible alternative approaches, some of which are discussed below. These revealed opportunities for improvement as well as important constraints to consider. Despite the support provided by the SPHN Connector, stakeholders have expressed that transforming data from clinical data warehouses into SPHN-compatible semantics remains a significant challenge, particularly when ingesting tabular data. This is primarily due to the integration of heterogeneous data sources into their pipelines but also the complexity of the SPHN RDF Schema, which represents healthcare concepts with rich contextual detail to support research needs. As a result, the SPHN Connector generated tabular DDL templates often lead to extensive tables with a high number of columns to be filled, reflecting the flat nature of tabular formats compared to the interconnected structure of RDF graphs. Nevertheless, most stakeholders acknowledge that the SPHN Connector offers substantial support as it reduces the burden of directly mapping their data to Semantic Web technologies but also developing means locally to validate their data. It also simplifies the migration of their pipelines from one schema version to the next. By offering an intermediate acceptable layer (tabular, JSON, CSV, Excel) as input, the tool simplifies the transformation process at the source. Currently, three university hospitals ingest data in tabular form, while two use JSON. Many stakeholders also recognize the value of knowledge graphs in achieving semantic interoperability, especially when supported with the SPHN RDF Schema, which ensures consistent understanding and sharing of data across Swiss institutions. To ensure long-term maintainability and alignment with evolving semantic standards, we are committed to supporting, with each SPHN Connector release, at the latest version of the SPHN RDF Schema, along with project-specific and other actively used schemas within the SPHN ecosystem. Backward compatibility is maintained whenever possible. Actively used SPHN RDF Schemas are always supported. For example, the 2024.1 SPHN RDF Schema underwent a major restructuring that introduced new semantic patterns, nevertheless backward compatibility in the SPHN Connector was ensured between schema versions prior to 2024.1 and versions from 2024.1 onwards. One frequently mentioned topic was the horizontal scaling of the tool. While this approach could increase throughput for large datasets, the diversity in environments poses challenges for deploying such methods in practice. Stakeholders also discussed the possibility of connecting the tool directly to the hospital's clinical data platforms (CDPs), avoiding intermediate data pushes and streamlining workflows. However, this would require highly customized versions of the SPHN Connector for each CDP. In this case, hospitals also expressed concerns about the security implications of granting such direct access, as this may bypass established governance. Hence, a more decoupled approach was considered safer and broadly acceptable, as reflected in the current implementation. Finally, we considered the processing of all data collectively, without splitting it into patient-specific workflows. While this approach appears advantageous from a performance perspective, it increases the risk of generating overlapping or inconsistent patient files and complicates debugging. The decision to adopt a patient-oriented workflow was motivated by the need for operational simplicity and consistency of data handling across the different sites. Overall, the decisions implemented represent a balance between technical robustness and operational feasibility, ensuring stakeholders’ trust while building a reliable and transparent RDF data transformation. Conclusion The SPHN Connector exemplifies how from an architecture- and use case-driven approach, we implemented a tool that facilitates the construction of KGs from heterogeneous health data systems across Swiss healthcare institutions. Its development goes beyond simple data transformation, integrating KG-focused design principles to address the challenges of cross-institutional biomedical data integration in a consistent and maintainable way. Looking forward, the federated integration of knowledge graphs across domains and institutions represents a promising direction to not only enable broader data reuse but also address complex governance and data-sharing challenges. Abbreviations ATC – Anatomical Therapeutic Chemical CDP – Clinical Data Platforms CHOP – Swiss Classification of Surgical Interventions CPUs – Central processing units CSV – Comma Separated Values DDL – Data Definition Language EHDEN – European Health Data & Evidence Network ETL – Extract Transform Load FAIR – Findable Accessible Interoperable Reusable FHIR – Fast Healthcare Interoperability Resources GB – Gigabyte KB – Kilobyte KG(s) – Knowledge Graph(s) ICD-10-GM – International Statistical Classification of Diseases and Related Health Problems 10th revision German modification IRI - Internationalized Resource Identifier JSON – JavaScript Object Notation MB – Megabyte OBO – Open Biological and Biomedical Ontology OHDSI – Observational Health Data Sciences and Informatics OMOP – Observational Medical Outcomes Partnership RAM – Random Access Memory RDF – Resource Description Framework SHACL – Shapes Constraint Language SQL – Structured Query Language SPARQL – SPARQL Protocol and RDF Query Language SPHN – Swiss Personalized Health Network UID – Unternehmens-Identifikationsnummer (in english: standardised business identification number) Declarations Ethics approval and consent to participate Not applicable. Consent for publication All authors have consented for publication of the manuscript. Availability of data and materials Tool name: SPHN Connector Tool home page: https://git.dcc.sib.swiss/sphn-semantic-framework/sphn-connector Operating system(s): Linux, Windows Main programming language: Python Other requirements: Docker License: GNU GPL v3.0 Funding This work was funded by the Swiss State Secretary of Research and Innovation (SERI) through the Swiss Personalized Health Network (SPHN). Competing Interests The authors have no conflict of interest. Authors’ contributions SOE; PK; VT; DU; NS; MP; KK designed the strategy for the knowledge graph and conceptualized the SPHN Connector. PK; ABM; NS; MP; KK developed the SPHN Connector. KK tested the SPHN Connector in a real-world setting. SOE led the project. VT; PK; DU; SOE wrote the manuscript. All authors contributed to and approved the final version of the manuscript. Acknowledgments We would like to acknowledge the five project teams at the Swiss University Hospitals for regularly installing and testing the tool in a production environment, and providing feedback. We also would like to acknowledge the BioMedIT team and especially the security working group for checking the coverage of the security requirements of the tool and providing us with a test environment. We thank Clément Parisato for his guidance regarding legal aspects, as well as the de-identification working group for defining the de-identification rules which we applied in the SPHN Connector, especially Dr. Julia Maurer, Dr. Jan Armida, Dr. Jean Louis Raisaro and Prof. Fabian Prasser. We would like to thank the SPHN IT Architecture working group for identifying the necessary requirements for such a tool which were addressed in the current SPHN Connector implementation, especially a big thank you to Markus Obreiter. Finally, we would like to acknowledge Patrick Hirschi and Nadine Thenée for actively supporting this project. References Fröhlich H, Balling R, Beerenwinkel N, Kohlbacher O, Kumar S, Lengauer T, et al. From hype to reality: data science enabling personalized medicine. BMC Med 2018;16:150. Wilkinson MD, Dumontier M, Aalbersberg IjJ, Appleton G, Axton M, Baak A, et al. The FAIR Guiding Principles for scientific data management and stewardship. Sci Data 2016;3:160018. https://doi.org/10.1038/sdata.2016.18. RDF 1.1 Concepts and Abstract Syntax. https://www.w3.org/TR/rdf11-concepts/ (accessed October 22, 2025). Touré V, Krauss P, Gnodtke K, Buchhorn J, Unni D, Horki P, et al. FAIRification of health-related data using semantic web technologies in the Swiss Personalized Health Network. Sci Data 2023;10:127. https://doi.org/10.1038/s41597-023-02028-y. SHACL. https://www.w3.org/TR/shacl/ (accessed October 22, 2025). SPARQL 1.1 Query Language. https://www.w3.org/TR/sparql11-query/ (accessed October 22, 2025). Touré V, Unni D, Krauss P, Abdelwahed A, Buchhorn J, Hinderling L, et al. The SPHN Schema Forge–transform healthcare semantics from human-readable to machine-readable by leveraging semantic web technologies. J Biomed Semantics 2025;16:9. Benson T, Grieve G. SNOMED CT. In: Benson T, Grieve G, editors. Principles of Health Interoperability: SNOMED CT, HL7 and FHIR, Cham: Springer International Publishing; 2016, p. 155–72. https://doi.org/10.1007/978-3-319-30370-3_9. ATCDDD – Home. https://atcddd.fhi.no (accessed October 22, 2025). ICD-10-GM. https://www.bfarm.de/EN/Code-systems/Classifications/ICD/ICD-10-GM/_node.html.7 (accessed October 22, 2025). Krauss P, Touré V, Gnodtke K, Crameri K, Österle S. DCC terminology service—an automated CI/CD pipeline for converting clinical and biomedical terminologies in graph format for the Swiss personalized health network. Applied Sciences 2021;11:11311. https://doi.org/10.3390/app112311311. Belleau F, Nolin M-A, Tourigny N, Rigault P, Morissette J. Bio2RDF: towards a mashup to build bioinformatics knowledge systems. J Biomed Inform 2008;41:706–16. The UniProt Consortium. UniProt: the universal protein knowledgebase. Nucleic Acids Res 2017;45:D158–69. https://doi.org/10.1093/nar/gkw1099. Knox C, Wilson M, Klinger CM, Franklin M, Oler E, Wilson A, et al. DrugBank 6.0: the DrugBank knowledgebase for 2024. Nucleic Acids Res 2024;52:D1265–75. Putman TE, Schaper K, Matentzoglu N, Rubinetti VP, Alquaddoomi FS, Cox C, et al. The Monarch Initiative in 2024: an analytic platform integrating phenotypes, genes and diseases across species. Nucleic Acids Res 2024;52:D938–49. Jackson R, Matentzoglu N, Overton JA, Vita R, Balhoff JP, Buttigieg PL, et al. OBO Foundry in 2021: operationalizing open data principles to evaluate ontologies. Database 2021;2021:baab069. Smith B, Ashburner M, Rosse C, Bard J, Bug W, Ceusters W, et al. The OBO Foundry: coordinated evolution of ontologies to support biomedical data integration. Nat Biotechnol 2007;25:1251–5. https://doi.org/10.1038/nbt1346. Caufield JH, Putman T, Schaper K, Unni DR, Hegde H, Callahan TJ, et al. KG-Hub—building and exchanging biological knowledge graphs. Bioinformatics 2023;39:btad418. Unni DR, Moxon SAT, Bada M, Brush M, Bruskiewich R, Caufield JH, et al. Biolink Model: A universal schema for knowledge graphs in clinical, biomedical, and translational science. Clin Transl Sci 2022;15:1848–55. Callahan TJ, Tripodi IJ, Stefanski AL, Cappelletti L, Taneja SB, Wyrwa JM, et al. An open source knowledge graph ecosystem for the life sciences. Sci Data 2024;11:363. Sy MF, Roman B, Kerrien S, Mendez DM, Genet H, Wajerowicz W, et al. Blue Brain Nexus: An open, secure, scalable system for knowledge graph management and data-driven science. Semant Web 2023;14:697–727. OMOP Common Data Model. https://ohdsi.github.io/CommonDataModel (accessed October 22, 2025). Hripcsak G, Duke JD, Shah NH, Reich CG, Huser V, Schuemie MJ, et al. Observational Health Data Sciences and Informatics (OHDSI): opportunities for observational researchers. Stud Health Technol Inform 2015;216:574. Coman Schmid D, Crameri K, Oesterle S, Rinn B, Sengstag T, Stockinger H, et al. SPHN–The BioMedIT Network: a secure IT platform for research with sensitive human data. Digital personalized health and medicine, IOS Press; 2020, p. 1170–4. Bray T. The javascript object notation (json) data interchange format. 2014. Braunstein ML, Braunstein ML. Health Informatics on FHIR: How HL7’s API is Transforming Healthcare. Springer; 2022. Ormond K, Bavamian S, Becherer C, Currat C, Joerger F, Geiger TR, et al. What are the bottlenecks to health data sharing in Switzerland? An interview study. Swiss Med Wkly 2024;154:3538. LightRDF. https://github.com/ozekik/lightrdf (accessed October 22, 2025). Berman J, Sterling C, Taprest R, Nezbeda H, Rosen S, chen wilson, et al. python-jsonschema/jsonschema: v4.25.1 2025. https://doi.org/10.5281/zenodo.16896019. Dimou A, Vander Sande M, Colpaert P, Verborgh R, Mannens E, Van de Walle R. RML: A generic language for integrated RDF mappings of heterogeneous data. Ldow 2014;1184. Heyvaert P, Van Assche D, De Meester B, Haesendonck G, de Vleeschauwer E, Sitt Min Oo. RMLMapper. https://doi.org/10.5281/zenodo.3929132. SPHN RDF Quality Check Tool. https://git.dcc.sib.swiss/sphn-semantic-framework/sphn-rdf-quality-check-tool (accessed October 22, 2025). Naming convention for SPHN data instances. https://www.bfs.admin.ch/bfs/en/home/registers/enterprise-register/enterprise-identification/uid-general.html (accessed October 22, 2025). The UID in general. https://www.bfs.admin.ch/bfs/en/home/registers/enterprise-register/enterprise-identification/uid-general.html (accessed October 22, 2025). Davis KR, Peabody B, Leach P. Universally Unique IDentifiers (UUIDs) 2024. https://doi.org/10.17487/RFC9562. PostgreSQL. https://www.postgresql.org/ (accessed October 22, 2025). Touré V, Unni D, Krauss P, Abdelwahed A, Buchhorn J, Hinderling L, et al. The SPHN Schema Forge–transform healthcare semantics from human-readable to machine-readable by leveraging semantic web technologies. J Biomed Semantics 2025;16:9. Unni D, Touré V, Krauss P, Crameri K, Österle S. SPHN strategy to unravel the semantic drift between versions of standard terminologies 2023. FastAPI. https://github.com/fastapi/fastapi (accessed October 22, 2025). SPHN Connector User Guide documentation. https://git.dcc.sib.swiss/sphn-semantic-framework/sphn-connector/-/blob/main/docs/SPHN-Connector_User-Guide.pdf (accessed October 22, 2025). Additional Declarations No competing interests reported. Cite Share Download PDF Status: Published Journal Publication published 13 Feb, 2026 Read the published version in BMC Medical Informatics and Decision Making → Version 1 posted Editorial decision: Revision requested 01 Dec, 2025 Reviews received at journal 28 Nov, 2025 Reviews received at journal 06 Nov, 2025 Reviewers agreed at journal 04 Nov, 2025 Reviewers agreed at journal 28 Oct, 2025 Reviewers invited by journal 27 Oct, 2025 Editor assigned by journal 24 Oct, 2025 Submission checks completed at journal 24 Oct, 2025 First submitted to journal 23 Oct, 2025 You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-7930982","acceptedTermsAndConditions":true,"allowDirectSubmit":false,"archivedVersions":[],"articleType":"software","associatedPublications":[],"authors":[{"id":537293074,"identity":"02d7b188-c96b-4e3e-a875-c33fc436e45f","order_by":0,"name":"Vasundra Touré","email":"","orcid":"","institution":"SIB Swiss Institute of Bioinformatics","correspondingAuthor":false,"prefix":"","firstName":"Vasundra","middleName":"","lastName":"Touré","suffix":""},{"id":537293075,"identity":"26b98b81-7e77-4a7e-9dd0-864f69a4c4d8","order_by":1,"name":"Deepak Unni","email":"","orcid":"","institution":"SIB Swiss Institute of Bioinformatics","correspondingAuthor":false,"prefix":"","firstName":"Deepak","middleName":"","lastName":"Unni","suffix":""},{"id":537293076,"identity":"adbc4b51-3498-4ea3-aba2-fcf1825a6201","order_by":2,"name":"Philip Krauss","email":"","orcid":"","institution":"Accenture AG","correspondingAuthor":false,"prefix":"","firstName":"Philip","middleName":"","lastName":"Krauss","suffix":""},{"id":537293077,"identity":"0ac37931-9d03-4db6-ae99-6a7d5fad5048","order_by":3,"name":"Andrea Brites Marto","email":"","orcid":"","institution":"SIB Swiss Institute of Bioinformatics","correspondingAuthor":false,"prefix":"","firstName":"Andrea","middleName":"Brites","lastName":"Marto","suffix":""},{"id":537293078,"identity":"ddd30227-fcc6-48b8-99d6-8b6690ee04fc","order_by":4,"name":"Katie Kalt","email":"","orcid":"","institution":"University Hospital Zurich","correspondingAuthor":false,"prefix":"","firstName":"Katie","middleName":"","lastName":"Kalt","suffix":""},{"id":537293080,"identity":"4dfd9ccb-3f36-4474-bf0d-c58aa17b5dde","order_by":5,"name":"Nicola Stoira","email":"","orcid":"","institution":"Accenture AG","correspondingAuthor":false,"prefix":"","firstName":"Nicola","middleName":"","lastName":"Stoira","suffix":""},{"id":537293081,"identity":"03859639-6736-4820-8b8c-122db9f96c92","order_by":6,"name":"Maximilian Pickl","email":"","orcid":"","institution":"Accenture GmbH","correspondingAuthor":false,"prefix":"","firstName":"Maximilian","middleName":"","lastName":"Pickl","suffix":""},{"id":537293082,"identity":"593bcecc-1e16-4fa5-828d-50876eeec2be","order_by":7,"name":"Sabine Österle","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAABCUlEQVRIie2RsWrDMBRFnxAkixyvymL9wgteMoT2V2QMyVKXjB5KEBSc0Wu2/oInr7URdHLI6jV0LYXSpV7aynRICBF47KADAklwdO9DAA7Hv4RBdTqsIQDK+h0folCzEMJBCpwrkTrdXEds97VepxD4/qF+TXGxetp6Femy+a1Q1xVs7qXeNRBOdzGdNbhMCj2R1Mt4VFQWBe5QexlERUtHU4U6KShDSkou0VYsfzPKN0TPBz3uFP6sxCND0pXcWgzaPkWZFIhHRGElQTMEr+RE2Yq171KzFx7yNg5NsXjWz2Jy7bOIPNGf7GER+Hl9/FDpjRD5vj5+NRt7sT8uPs7yvsPhcDiG8gs25lZvJ5WXjAAAAABJRU5ErkJggg==","orcid":"","institution":"SIB Swiss Institute of Bioinformatics","correspondingAuthor":true,"prefix":"","firstName":"Sabine","middleName":"","lastName":"Österle","suffix":""}],"badges":[],"createdAt":"2025-10-23 09:53:33","currentVersionCode":1,"declarations":"","doi":"10.21203/rs.3.rs-7930982/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-7930982/v1","draftVersion":[],"editorialEvents":[{"content":"https://doi.org/10.1186/s12911-026-03383-7","type":"published","date":"2026-02-13T15:58:45+00:00"}],"editorialNote":"","failedWorkflow":false,"files":[{"id":95119401,"identity":"a46ed54e-b392-4da1-8916-3044c96f10be","added_by":"auto","created_at":"2025-11-04 13:41:54","extension":"docx","order_by":1,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":130961,"visible":true,"origin":"","legend":"","description":"","filename":"20251022ManuscriptSPHNConnector.docx","url":"https://assets-eu.researchsquare.com/files/rs-7930982/v1/167e12b5c0e519a06fffabbb.docx"},{"id":95119402,"identity":"fc450b13-16cb-43ac-91bd-1eb62e30141a","added_by":"auto","created_at":"2025-11-04 13:41:54","extension":"json","order_by":5,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":9805,"visible":true,"origin":"","legend":"","description":"","filename":"df360a2d280a46c69d07c2ab5dca6679.json","url":"https://assets-eu.researchsquare.com/files/rs-7930982/v1/965919d8bbd6a8c1eea7d6ea.json"},{"id":95119403,"identity":"9ca859ed-2ab7-478c-aabf-d3bc9311b6c6","added_by":"auto","created_at":"2025-11-04 13:41:54","extension":"xml","order_by":6,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":114241,"visible":true,"origin":"","legend":"","description":"","filename":"df360a2d280a46c69d07c2ab5dca66791enriched.xml","url":"https://assets-eu.researchsquare.com/files/rs-7930982/v1/5d66b6b2d009bb7a46335600.xml"},{"id":95225436,"identity":"a219ceda-7ffa-4264-9b9d-c07a7b155773","added_by":"auto","created_at":"2025-11-05 16:25:05","extension":"pdf","order_by":7,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":1114827,"visible":true,"origin":"","legend":"","description":"","filename":"Figure1.pdf","url":"https://assets-eu.researchsquare.com/files/rs-7930982/v1/a14b5f59d967cc35741c4cbd.pdf"},{"id":95225643,"identity":"33a2441d-870e-49bb-b520-892f89d7afaa","added_by":"auto","created_at":"2025-11-05 16:25:21","extension":"pdf","order_by":8,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":127647,"visible":true,"origin":"","legend":"","description":"","filename":"Figure2.pdf","url":"https://assets-eu.researchsquare.com/files/rs-7930982/v1/64abf3e0dc2f1f2d7fed3412.pdf"},{"id":95119406,"identity":"7e59f289-ff94-490c-a493-e0bcebcb0eb9","added_by":"auto","created_at":"2025-11-04 13:41:54","extension":"pdf","order_by":9,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":7004940,"visible":true,"origin":"","legend":"","description":"","filename":"Figure3.pdf","url":"https://assets-eu.researchsquare.com/files/rs-7930982/v1/1c93749aa4ef10e52e8ed893.pdf"},{"id":95119405,"identity":"babd29c6-213e-47ed-9b95-648afcb1bd08","added_by":"auto","created_at":"2025-11-04 13:41:54","extension":"pdf","order_by":10,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":566629,"visible":true,"origin":"","legend":"","description":"","filename":"Figure4.pdf","url":"https://assets-eu.researchsquare.com/files/rs-7930982/v1/6ed82162d08294d71fd19af5.pdf"},{"id":95119407,"identity":"49f8c803-aea6-46fd-873d-18e601f7196b","added_by":"auto","created_at":"2025-11-04 13:41:54","extension":"xml","order_by":11,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":112959,"visible":true,"origin":"","legend":"","description":"","filename":"df360a2d280a46c69d07c2ab5dca66791structuring.xml","url":"https://assets-eu.researchsquare.com/files/rs-7930982/v1/9e8e37ca09c59be5590c12b0.xml"},{"id":95119410,"identity":"2adac1ce-3400-4e98-bf87-63d26b2e405d","added_by":"auto","created_at":"2025-11-04 13:41:54","extension":"html","order_by":12,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":124402,"visible":true,"origin":"","legend":"","description":"","filename":"earlyproof.html","url":"https://assets-eu.researchsquare.com/files/rs-7930982/v1/c963976eaac11800e5f13d7b.html"},{"id":95224649,"identity":"f09ca2d4-ceac-4bd2-b55b-ee1fa67ca086","added_by":"auto","created_at":"2025-11-05 16:24:06","extension":"png","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":118257,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cstrong\u003eConfiguration step with Create_project API endpoint.\u003c/strong\u003e From the RDF schema (SPHN or project-specific) provided by the user, the SPHN Connector generates the input template interfaces for each of the following supported format: JSON, CSV/Excel, RDBMS (with an SQL Data Definition Language (DDL) template) using an RML mapping. Additionally, SHACL rules are derived using the SPHN SHACLer.\u003c/p\u003e","description":"","filename":"Binder21.png","url":"https://assets-eu.researchsquare.com/files/rs-7930982/v1/fde27c7f766ee30bec0c21b8.png"},{"id":95119397,"identity":"1cc2fbfc-d3b3-4518-b6cc-c7541a4e6e23","added_by":"auto","created_at":"2025-11-04 13:41:54","extension":"png","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":24952,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cstrong\u003eData architecture and workflow in the SPHN Connector.\u003c/strong\u003e Patient data from diverse sources (RDF, JSON, CSV/Excel, RDBMS) can be ingested into the SPHN Connector and transformed via RML into RDF aligned with the SPHN Schema provided during Project Setup. Validation through SHACL and SPARQL ensures semantic compliance before datasets are sent to projects via secure infrastructures.\u003c/p\u003e","description":"","filename":"Binder22.png","url":"https://assets-eu.researchsquare.com/files/rs-7930982/v1/1e4b27104e2d79a0a6ab97c7.png"},{"id":95119400,"identity":"71458867-d616-470e-aa91-25cdf51b4293","added_by":"auto","created_at":"2025-11-04 13:41:54","extension":"png","order_by":3,"title":"Figure 3","display":"","copyAsset":false,"role":"figure","size":194734,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cstrong\u003eSPHN Connector ingestion interfaces. \u003c/strong\u003eThe figure shows ingestion interfaces for JSON, CSV and Database (three of the five possible interfaces) provided by the SPHN Connector API and how data in the Landing Zone could look like once it has been ingested by the API.\u003c/p\u003e","description":"","filename":"Binder23.png","url":"https://assets-eu.researchsquare.com/files/rs-7930982/v1/bec127151b4ae53be5856103.png"},{"id":95119398,"identity":"808dbe0f-e97e-46f2-a249-0734ca9af306","added_by":"auto","created_at":"2025-11-04 13:41:54","extension":"png","order_by":4,"title":"Figure 4","display":"","copyAsset":false,"role":"figure","size":82545,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cstrong\u003eCentralized versus federated approach for the use of knowledge graphs generated by the SPHN Connector. \u003c/strong\u003e(A) Centralized analysis of the RDF files generated by data providers. Data is transferred to a Trusted Research Environment (e.g. BioMedIT) where users can safely perform their research studies. (B) Federated analysis of knowledge graphs built at the data providing institutions. These graphs are stored in a triplestore locally and aggregated results can be accessed in a federated manner, allowing users to assess the feasibility of research projects based on the data available at each institution.\u003c/p\u003e\n\u003cp\u003e\u003cbr\u003e\u003c/p\u003e","description":"","filename":"Binder24.png","url":"https://assets-eu.researchsquare.com/files/rs-7930982/v1/80fd8cd0c1b9819d83b50295.png"},{"id":102785735,"identity":"5ae4c5cb-40b8-4388-90e0-03da1efeed88","added_by":"auto","created_at":"2026-02-16 16:09:23","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":1564997,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-7930982/v1/13599cbc-b31f-4dc4-a2fa-a89bdd832b26.pdf"}],"financialInterests":"No competing interests reported.","formattedTitle":"SPHN Connector - A scalable pipeline for generating validated knowledge graphs from federated and semantically enriched health data","fulltext":[{"header":"Background","content":"\u003cp\u003eThe integration and reuse of heterogeneous health data, ranging from clinical routine records to cohort studies and omics datasets, has become central to modern biomedical research [1]. Semantic knowledge graphs (KGs) have emerged as a powerful paradigm to link data, harmonizing data structure while preserving meaning through semantic representations. Within the Swiss Personalized Health Network (SPHN), a comprehensive semantic interoperability framework has been developed to support the FAIR (Findable, Accessible, Interoperable, Reusable) principles [2]. This framework is centered around the SPHN RDF (Resource Description Framework [3]) Schema [4], defining the blueprint for health data representation using Semantic Web technologies. Beyond the core schema, project-specific extensions enrich the SPHN RDF Schema with additional field-specific semantics. Whether core or extended, the RDF Schema is complemented by Semantic Web artefacts such as Shapes Constraint Language (SHACL [5]) validation rules and SPARQL Protocol and RDF Query Language (SPARQL [6]) data exploration queries, which are automatically generated with the SPHN Schema Forge tool [7]. Standard terminologies, such as Systematized Nomenclature of Medicine - Clinical Terms (SNOMED CT) [8], Logical Observation Identifiers Names and Codes (LOINC), Anatomical Therapeutic Chemical (ATC) [9], and International Statistical Classification of Diseases and Related Health Problems 10th revision German modification (ICD-10-GM) [10], are provided in RDF with the DCC Terminology Service [11]. Leveraging these resources, data providers transform their local datasets into RDF representations that conform with the SPHN RDF Schema for interoperable, consistent and reusable datasets.\u003c/p\u003e\n\u003cp\u003eSeveral leading initiatives build biological and biomedical KGs using an Extract-Transform-Load (ETL) approach where data from heterogeneous sources are extracted, semantically enriched and harmonized using domain-specific ontologies, and loaded into a graph-based store for querying and analysis. Bio2RDF [12] is an early effort that converts resources like UniProt [13] and DrugBank [14] into RDF, mapping identifiers to URIs and linking datasets for querying. The Monarch Initiative [15], which focuses on integrating cross-species genotype-phenotype data from various sources, harmonized with the Open Biological and Biomedical Ontologies (OBO) Foundry ontologies for phenotype-driven rare disease diagnosis and translational research [16,17]. The Knowledge Graph Hub [18] offers reusable ETL components, where data sources are mapped to the Biolink Model [19], to generate a KG enriched with biomedical associations. PheKnowLator [20] is another example that automates the construction of semantically rich KGs using ontologies and OWL reasoning. The Blue Brain Nexus [21] offers a scalable, provenance-aware linked data platform designed for neuroscience but also supporting the broader biomedical domain.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eWhile these examples demonstrate the diversity and maturity of tools for biomedical KG construction, very few target routine clinical data where privacy, heterogeneity, and governance make the integration challenging. Most existing biomedical KGs are generated centrally, with source data aggregated into a single repository before, during, or after transformation. Some Initiatives that deal with clinical data include the Observational Health Data Sciences and Informatics (OHDSI) network that harmonizes distributed clinical databases into the Observational Medical Outcomes Partnership (OMOP) Common Data Model [22,23] and enables federated analytics; and the European Health Data \u0026amp; Evidence Network (EHDEN) which operates a large-scale OMOP-based privacy-preserving network for real-world evidence data.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eSPHN takes a federated approach in which the KG is conceptually unified but generated locally at participating data providers (i.e. university hospitals). This ensures semantic interoperability without centralizing the sensitive patient-level information, while remaining consistent with the Swiss-specific ethical and legal framework. Resulting datasets can be subsequently integrated within trusted research environments tailored for processing health-related data (i.e. BioMedIT [24]), where information about the same patient from multiple sources can be linked for research purposes. For instance, combining clinical routine data across hospitals with omics metadata generated by research platforms. Building federated KGs in healthcare however presents several challenges. Data providers must extract, transform, and deliver locally maintained data according to national or project-specific standards, which is a technically demanding task. Data comes in diverse formats (CSV, relational databases, JSON [25], FHIR [26]) making RDF transformation complex. Data providers are further responsible for ensuring data quality, performing technical validation, and applying privacy-preserving measures such as patient de-identification, all at scale [27]. Additionally, expertise in KG technologies can be rare among data providers, which poses additional challenges when implementing these processes. To meet these demands, stakeholders have expressed a strong need for structured guidance and practical tools.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eIn response, SPHN developed a methodology that enforces schema-driven transformation and reduces the burden on data providers. This methodology laid the foundation for the SPHN Connector, a unified tool that implements various strategies to realize the goal of consistent schema-driven transformation. The SPHN Connector supports data providers in producing semantically structured and valid data aligned with the SPHN Semantic Interoperability Framework. By automating key steps such as de-identification for privacy-preserving, conversion, and validation, it lowers technical barriers to semantic data processing and enables scalable production of FAIR, high-quality data for federated KG construction within the SPHN ecosystem.\u003c/p\u003e"},{"header":"Methods","content":"\u003cp\u003eTo support the creation of semantically rich KGs aligned with the SPHN Semantic Interoperability Framework, we established a methodology integrating conceptual foundations with technical design decisions. This approach was driven by the need to address key challenges and stakeholder requirements for facilitating downstream integration of heterogeneous health data across institutions. These methods have driven the implementation of the SPHN Connector for a successful deployment and use in university hospitals.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eThe technical challenges in distributed KG creation can be characterized along three, often interrelated, dimensions:\u003c/p\u003e\n\u003cul\u003e\n \u003cli\u003e\u003cstrong\u003eData heterogeneity:\u003c/strong\u003e Distributed KG generation involves the integration of data from diverse sources which often differ in format and layout. Further complications arise from differences in language, variation in semantic representation, and data quality.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eHeterogenous infrastructures and tooling:\u003c/strong\u003e In distributed environments, data and processing pipelines are often heterogeneous even when built to generate data conforming to a prescribed data model. The tools used for data extraction and transformation each have their own internal data models which can affect how source data is mapped and transformed.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eVariability in user tool usage:\u003c/strong\u003e The stakeholders involved in KG generation are often data engineers, data scientists, and software developers. Their approach to KG generation varies depending on their expertise, appreciation of the semantics, and understanding of the target data model.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThese challenges were identified through stakeholder discussions and requirements gathering. Moreover, the SPHN Connector is operated by personnel at the data-providing institutions, often without direct supervision of the transformation process, highlighting the need for robust, automated, and reproducible workflows. Here we describe both the conceptual strategies and corresponding technical implementations built on the SPHN framework.\u003c/p\u003e\n\u003col\u003e\n \u003cli\u003e\n \u003ch3\u003eGeneral tool requirements\u003c/h3\u003e\n \u003c/li\u003e\n\u003c/ol\u003e\n\u003ch4\u003e1.1 Data ingestion aligned with data provider\u0026rsquo;s input\u003c/h4\u003e\n\u003cp\u003eSPHN requires that project data is delivered in RDF. Data providers expressed the need for a tool that would facilitate this process by enabling data transformation from input formats that are closely aligned with their existing systems. This would minimize the need for them to acquire in-depth knowledge of RDF. To address this, the SPHN Connector provides dedicated ingestion interfaces for JSON, tabular formats (CSV/Excel), and relational databases (RDBMS). While the syntactical format in RDF is less of an issue, the way information is structured according to a specific schema (e.g. the SPHN RDF Schema) in RDF is critical.\u0026nbsp;\u003c/p\u003e\n\u003ch4\u003e1.2 Multi-project handling\u003c/h4\u003e\n\u003cp\u003eAs the SPHN RDF Schema continues to evolve and projects have the possibility to define their own semantics, an important requirement was to support multiple projects within a single instance of the SPHN Connector. To meet this requirement, projects are strictly isolated from one another with respect to their schema definitions, patient identifiers, database views, and populated tables. Patient information is not shared across projects but must instead be duplicated within each project context to reduce complexity and ensure project independence. However, within a project, project configurations and de-identifications rules persist across data deliveries.\u0026nbsp;\u003c/p\u003e\n\u003ch4\u003e1.3 Minimize dependencies on manual work\u003c/h4\u003e\n\u003cp\u003eParts of the data processing pipeline (i.e. population of data ingestion interfaces, along with the transformation and validation rules) are automatically derived from the SPHN RDF Schema and optionally a compliant project schema (see Figure 1). This approach ensures that compliant project schemata can be directly used without requiring additional manual or central effort. In addition, this reduces the potential source for errors in the long term as schema modeling patterns and their combination stabilize over time, not every project combination needs to be tested exhaustively.\u0026nbsp;\u003c/p\u003e\n\u003ch4\u003e1.4 Data protection and maintenance considerations\u003c/h4\u003e\n\u003cp\u003eData providers handle sensitive patient data, including real patient identifiers in some cases. Given the potentially large number of patients and extensive data points, ensuring robust security and maintainability is critical. To address these concerns, the tool must be installed and operated by the data provider in their local environment. The setup and deployment process is designed to be transparent and compliant with the data provider\u0026rsquo;s security requirements. Key technical features supported in the SPHN Connector include:\u003c/p\u003e\n\u003cul\u003e\n \u003cli\u003eAbility to run in Docker rootless mode;\u003c/li\u003e\n \u003cli\u003eCompatibility with Windows and Linux systems;\u003c/li\u003e\n \u003cli\u003eAbility to support offline and air-gapped execution, where runtime changes are forbidden;\u003c/li\u003e\n \u003cli\u003eA dedicated API, enabling the automation of various processes within a workflow;\u003c/li\u003e\n \u003cli\u003eUser and password management for access.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThese choices ensure secure and reliable operation of the tool in line with institutional policies.\u003c/p\u003e\n\u003ch4\u003e1.5 Computational performance and scaling\u003c/h4\u003e\n\u003cp\u003eA key requirement was the need for a tool that runs efficiently, even on limited computational infrastructures without requiring specialized hardware or complex system dependencies. The SPHN Connector is designed to operate on standard environments with a minimum of 16 GB RAM, 4 CPUs, and 500 GB of disk space. Additionally, from an operational perspective, it was necessary to avoid generating overlapping patient files. To achieve this, the SPHN Connector adopts a patient-oriented workflow, which processes the data on a per-patient basis. This design choice ensures adoption across all partners, where each environment can vary in capacity and configuration but also to ensure consistency and simplification of data handling.\u003c/p\u003e\n\u003cp\u003eTo meet this requirement, core libraries were carefully selected and optimized:\u003c/p\u003e\n\u003cul\u003e\n \u003cli\u003eFor parsing and validating RDF data, we integrated a high-performance RDF parser implemented in Rust and accessed through Python bindings (LightRDF [28]).\u0026nbsp;\u003c/li\u003e\n \u003cli\u003eFor JSON Schema validation, several alternatives were benchmarked and found unreliable. The jsonschema [29] library was selected as the most reliable in ensuring correctness while maintaining efficiency.\u0026nbsp;\u003c/li\u003e\n \u003cli\u003eFor the RDF conversion, RML [30] (RMLmapper-java [31]) was chosen to convert the internal JSON files into RDF files based on the RML configuration created. The library was selected for the implementation of the flexible RML language for the mapping (unlike R2RML, which only supports relational databases to RDF transformation; RML extends it to also supports multiple data sources such as JSON, CSV and XML), its performance and scaling capabilities.\u003c/li\u003e\n \u003cli\u003eFor RDF validation, the SPHN Connector leverages the SPHN RDF Quality Control (QC) framework to adhere to the workflow [32], a Java-based solution that performs two key operations: 1) checking RDF data compliance with the schema based on SHACL constraints and generating a comprehensive report, and 2) calculating quantitative statistics to evaluate data completeness using SPARQL queries. An adapted version of the QC tool is integrated. For example, external terminologies are defined as constants and modeled as static elements to reduce computational overhead and improve validation performance.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eFinally, to address storage scalability, the SPHN Connector supports data integration with external S3 storage for handling large datasets efficiently. On the compute side, the pipeline offers capabilities for multi-processor and multi-threaded runs across all steps, especially beneficial for computationally intensive phases such as de-identification and validation. These optimizations ensure scalability without overloading the local infrastructure and ensure a reliable performance across diverse environments.\u003c/p\u003e\n\u003col start=\"2\"\u003e\n \u003cli\u003e\n \u003ch3\u003eKnowledge Graph architectural decisions\u003c/h3\u003e\n \u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eThe production and long-term management of a KG requires the design of clear architectural principles. The following subsections describe some of the key decisions embedded in the SPHN Connector that go beyond the semantic definitions of the SPHN RDF Schema.\u003c/p\u003e\n\u003ch4\u003e2.1 IRI naming convention to prevent clashes\u0026nbsp;\u003c/h4\u003e\n\u003cp\u003eIn a federated setting with multiple institutions contributing data independently, a consistent and collision-free identification of data instances is essential for a reliable graph construction. To avoid ambiguity and preserve data integrity, the SPHN framework defines a structured Internationalized Resource Identifier (IRI) convention documented in [33]\u0026nbsp;and composed of:\u003c/p\u003e\n\u003cp\u003ei. The data provider identifier, based on the unique identifier number for enterprises applied in Switzerland (UID [34])\u003c/p\u003e\n\u003cp\u003eii. A prefix specifying the schema from which the instance data originates (e.g. SPHN or project-specific prefix)\u003c/p\u003e\n\u003cp\u003eiii. A class name reflecting the type of the instance (defined in the schema)\u003c/p\u003e\n\u003cp\u003eiv. A unique identifier defined by the data provider for that particular instance data.\u003c/p\u003e\n\u003cp\u003eTechnically, the SPHN Connector automatically fills i, ii and iii. This leaves only the last part of the identifier as input to the data provider. This convention guarantees globally unique IRIs, avoiding collisions when decentralized data is merged.\u003c/p\u003e\n\u003ch4\u003e2.2 Linking patient/sample information across providers\u003c/h4\u003e\n\u003cp\u003eIn real-world scenarios, research projects often require linking data elements across institutions (e.g. routine clinical data from multiple hospitals) and domains (e.g. linking electronic health records with laboratory results or imaging data). In Switzerland, no national unique patient identifier exists for research purposes, meaning each institution assigns its own identifier. Without coordination, these identifiers remain distinct, preventing linkage across datasets. Within SPHN projects, when legally and ethically approved, participating data providers may agree on and use a shared identifier for linkage. This identifier enables the association of common elements across datasets, indicating that they refer to the same patient or sample, even though they originate from different sources. To support this process, the SPHN RDF Schema includes the property sphn:hasSharedIdentifier, which institutions populate during data transformation. Note that the mapping is managed by the data providers themselves: the SPHN Connector does not perform linkage across patients but enables providers to include the agreed identifier.\u003c/p\u003e\n\u003ch4\u003e2.3. Streamline data updates and deletions using named graphs\u003c/h4\u003e\n\u003cp\u003eSupporting evolving patient records by enabling delta loads without reprocessing entire datasets was a crucial design goal. For instance, when a patient has a new hospital visit or additional lab results become available, only the newly acquired information needs to be added. In contrast, if a patient revokes consent, it becomes important for data users to delete all data associated with that patient. This is facilitated by organizing RDF data into named graphs, with each patient\u0026rsquo;s data encapsulated within a separate \u0026ldquo;subgraph\u0026rdquo;, which enforces patient atomicity. As a result, updates are more efficient because they are applied to individual patient graphs without having to reload data for all patients. While there\u0026rsquo;s no support in the SPHN Connector for incremental updates to a patient\u0026apos;s information, named graphs allow for updates in downstream systems. This structure enhances scalability during iterative data deliveries as it doesn\u0026rsquo;t affect unrelated patient records. On the data user side, this design also makes revocation handling straightforward: deleting a patient\u0026rsquo;s data simply involves removing their corresponding named graph via a SPARQL update. The SPHN Connector supports multiple RDF serialization formats, including TriG and N-Quads, ensuring compatibility with triplestores and downstream pipelines.\u003c/p\u003e\n\u003cp\u003eWhile architectural choices improve scalability and data management, ensuring patient data privacy and integrity remains critical. The following section details measures implemented in the SPHN Connector to address these aspects.\u003c/p\u003e\n\u003col start=\"3\"\u003e\n \u003cli\u003e\n \u003ch3\u003eMeasures for data integrity and privacy\u0026nbsp;\u003c/h3\u003e\n \u003c/li\u003e\n\u003c/ol\u003e\n\u003ch4\u003e3.1 De-identification\u003c/h4\u003e\n\u003cp\u003eWhile not mandated within SPHN, integrated de-identification capabilities are crucial to provide a practical solution for users beyond the core five university hospitals, thereby addressing the critical requirement of handling the privacy of personally identifiable information. By default, de-identification is not applied, leaving control to the user, who must explicitly configure it. De-identification is currently supported for data ingested via RDBMS, JSON, CSV, and Excel formats. The de-identification rules must be specified in a JSON configuration file when setting up a project in the SPHN Connector. At a minimum, SPHN recommends specifying parameters for fields related to Subject Pseudo Identifier, Administrative Case, and Sample (concepts defined in the SPHN RDF Schema) along with date-shift rules. The SPHN Connector supports four de-identification strategies, each designed to protect sensitive data:\u003c/p\u003e\n\u003cul\u003e\n \u003cli\u003e\u003cstrong\u003eField scrambling:\u003c/strong\u003e This method generates unique, pseudonymized identifiers for selected fields. The uniqueness is parallelizable and is not based on any content information of the patient. The scrambling ensures that values cannot be traced back to their original form but still remain consistent across datasets. Field scrambling is typically applied to fields that have unique identifiers as their value.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eDate shift:\u003c/strong\u003e All date values associated with concepts, such as Birth, Admission, and Diagnosis, can be shifted by a random number of days selected from a range defined in the configuration. However, the shift is consistently applied across all records of a given patient, such that temporal relationships are preserved.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eField substitution list:\u003c/strong\u003e For one or more fields, this method allows sensitive values to be replaced with a sensible substitution or a placeholder string. The field(s), list of sensitive values, and replacement string are configured by the user.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eField substitution regex:\u003c/strong\u003e This method is similar to the field substitution list but uses regular expression (regex) patterns to detect values that match a certain structure. Matching values are replaced with a corresponding replacement string.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe SPHN Connector applies de-identification to specified concepts using a Universally Unique Identifier (UUID)-based function [35] with a salting mechanism, and maintains a comprehensive log of data modifications, reported to the user. The logs enable users to apply the same de-identification to subsequent data submissions for the same patient, thereby ensuring data consistency and privacy. Alternatively, the SPHN Connector offers an option to disable logging, which is suitable only for one-off de-identified data preparation and export.\u003c/p\u003e\n\u003ch4\u003e3.2 Data integrity through validation\u003c/h4\u003e\n\u003cp\u003eData validation is crucial to guarantee both syntactic correctness and semantic coherence, ensuring consistent modeling and interpretation of heterogeneous data. The SPHN Connector implements multiple validation steps throughout the data processing workflow.\u003c/p\u003e\n\u003cp\u003eThe first layer of validation ensures that incoming data conforms to the expected structure and basic constraints before any transformation occurs. For JSON data, this is achieved through JSON Schema validation, which verifies data types, required fields, and structural rules. For relational tables, Structured Query Language (SQL) constraints in the table and type definitions enforce similar checks. For example, value sets defined in the RDF schema are mapped to specific data types in PostgreSQL [36], restricting ingestion to permitted values only. This pre-validation catches structural inconsistencies or type mismatches early, reducing downstream errors during data transformation and RDF generation. In addition, a pre-check step is performed to ensure that certain fields are correctly formatted. For instance, it verifies that a value is a valid IRI (without spaces or invalid characters).\u003c/p\u003e\n\u003cp\u003eWhile the SPHN RDF Schema defines the expected structure (blueprint), it does not enforce compliance. This is where SHACL plays a crucial role by translating the RDF schema rules into machine-actionable validation constraints. SHACL constraints define allowed values, cardinalities, and coding expectations, enabling the automated detection of both structural (e.g. missing mandatory metadata) and semantic inconsistencies (e.g. use of outdated or incorrect codes in the data). RDF validation ensures data integrity and compliance with the schema restrictions. These SHACL rules are automatically generated during project setup, whether the schema is the core SPHN RDF Schema or a project-specific one, using the Python-based SHACLer tool [37].\u003c/p\u003e\n\u003cp\u003eTo further ensure semantic precision, versioned terminologies for ATC, Swiss Classification of Surgical Interventions (CHOP) and ICD-10-GM (with French and Italian translations, version provided by the Swiss Federal Office of Statistics) [38] are integrated into the validation process to ensure data is aligned with the correct vocabulary version. Together, schema enforcement and terminology validation guarantee that the transformed RDF data adheres to the specifications and supports interoperability.\u003c/p\u003e\n\u003cp\u003eWith validation and de-identification strategies in place, the SPHN Connector orchestrates a structured workflow to transform and deliver semantically compliant RDF data. The following section outlines this workflow from data ingestion to data export.\u003c/p\u003e\n\u003ch3\u003eData workflow in SPHN Connector\u0026nbsp;\u003c/h3\u003e\n\u003cp\u003eThe SPHN Connector follows a structured workflow to transform patient data into semantically validated and possibly de-identified RDF data aligned with the SPHN Semantic Interoperability Framework (see Figure 2). The API, built using FastAPI [39], is the entry point for most operations in the SPHN Connector. At project setup, users provide the SPHN RDF Schema, possibly complemented by a project-specific RDF Schema extension, to which their data should conform, along with external terminologies from the SPHN core or project-specific extensions, for code validation and the expected RDF output format (e.g. Turtle, N-Quads, Trig). Optionally, a de-identification file in JSON format may be supplied as described in the section above. From the data schema, the SPHN Connector automatically generates all components, including the input mapping interfaces, and SHACL queries using the SPHN SHACLer, used in the validation step (see Figure 1).\u003c/p\u003e\n\u003cp\u003eThe SPHN Connector automatically generates templates (i.e. JSON Schema, CSV/Excel templates, and Data Definition Language (DDL) statements) based on the SPHN RDF Schema (see Figure 3). The design and structure of these templates are documented in the SPHN Connector user guide, updated with each release [40]. These templates allow users to prepare their local data marts in alignment with SPHN semantics. The API supports five ingestion interfaces: RDF, JSON, CSV, Excel, and relational database (RDBMS). The schema defines concepts, including those directly linked to the patient (i.e. the Subject Pseudo Identifier concept), which are considered \u0026ldquo;core concepts\u0026rdquo;.\u003c/p\u003e\n\u003cp\u003eFor example, in the SQL DDL (tabular) template, each core concept is represented as a separate table. These tables contain one column for each associated metadata defined in the schema. When a core concept is linked to another core concept, the relationship is captured by including only the identifier of the linked concept in the referencing table. The full metadata for the linked concept is stored in its own dedicated table. \u0026nbsp;For example, \u0026lsquo;Birth\u0026rsquo; and \u0026lsquo;Body Height Measurement\u0026rsquo; are two concepts that are each directly linked to the \u0026lsquo;Subject Pseudo Identifier\u0026rsquo;. As such, the SPHN Connector generates separate tables for each of these concepts. The \u0026lsquo;Body Height Measurement\u0026rsquo; concept is associated with the \u0026lsquo;Birth\u0026rsquo; concept to capture height measurements taken at birth. In this case, the \u0026lsquo;Body Height Measurement\u0026rsquo; table includes a column for the identifier of a \u0026lsquo;Birth\u0026rsquo; instance. This identifier should correspond to one of the entries in the \u0026lsquo;Birth\u0026rsquo; table, which contains all associated metadata for that birth event. This identifier linkage between the two tables is taken care of by the user of the SPHN Connector. The \u0026lsquo;Body Height Measurement\u0026rsquo; concept is further associated with the \u0026lsquo;Body Height\u0026rsquo; concept, which is not a core concept. In this case, all the metadata of the \u0026lsquo;Body Height\u0026rsquo; is directly embedded in the \u0026lsquo;Body Height Measurement\u0026rsquo; table. These approaches enable the reflection of graph-like relationships in a tabular structure, where links between entities are represented through identifiers rather than nested or interconnected data while optimizing the number of columns populated.\u003c/p\u003e\n\u003cp\u003eData can be submitted patient by patient or in batches via (external) S3-compatible or MinIO (within the SPHN Connector) storage when not using the Database ingestion mode. The SPHN Connector also provides a pgAdmin interface for database management and monitoring. The interface allows users to securely connect to the underlying PostgreSQL database, explore the database and manage tables. Typically, users find pgAdmin to be a useful debugging tool for investigating and resolving potential issues in their data after it has been ingested via the ingestion interface. The process in the SPHN Connector follows a data lake architecture, where records move through clearly defined zones and are stored as files, enabling users to view content at different stages without the need for dedicated tools.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eAfter ingestion, data is normalized into a JSON structure, which serves as an intermediate format to support automated quality-control checks when data reaches the Landing Zone, including validation of Code and Terminology mappings and verification of IRIs. At this stage, de-identification rules can also be applied, ensuring pseudonymization or anonymization in line with project specifications.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eData is then converted into RDF using RML mappings, ensuring alignment with the SPHN RDF Schema defined during configuration. The transformed data undergoes SHACL and SPARQL-based validation against SPHN semantics and standard terminologies provided during the project setup. A detailed log is generated allowing users to track errors, warnings, and failing patient records. The generated RDF patient data (even those failing validation) are transferred to the Release Zone, where users can download RDF data and associated quality control reports.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eFinally, RDF patient files can be shared with research projects through secure infrastructures such as BioMedIT. Throughout the workflow, processes are monitored and orchestrated using Apache Airflow, a workflow execution and management platform, for better traceability and supporting systematic debugging.\u003c/p\u003e"},{"header":"Results","content":"\u003ch3\u003eKnowledge graph\u003c/h3\u003e\n\u003cp\u003eThe proposed strategy for federating KGs through localized RDF data production and centralized combination addresses several core challenges in cross-institutional biomedical data integration. The design was evaluated based on its ability to meet key criteria for semantic interoperability, identifier uniqueness, updatability, and patient-level data governance. Results are summarized across the following focus areas:\u003c/p\u003e\n\u003cul\u003e\n \u003cli\u003eIdentifier management to ensure global data uniqueness and prevent collisions\u003c/li\u003e\n \u003cli\u003eCross-provider linkage of patients and samples via shared identifiers, to bridge otherwise siloed records\u003c/li\u003e\n \u003cli\u003eModular updates and deletions using named graphs, to support delta loads and consent revocation management\u003c/li\u003e\n \u003cli\u003eTracking versions of specific terminology codes, to track semantic integrity across heterogeneous terminology practices\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003eSPHN Connector\u003c/h3\u003e\n\u003cp\u003eThe SPHN Connector is developed for enabling a schema-driven data transformation, as defined by the SPHN Semantic Interoperability Framework, and provided under the GNU General Public License v3.0 (GPLv3) open-source license. It transforms heterogeneous health data from different input formats (e.g. CSV, Excel, JSON, relational databases) into semantically enriched RDF data conforming to the SPHN RDF Schema [Tour\u0026eacute; et al, 2023]. Guided by the SPHN-specific schema provided as input, the tool interprets and maps the source elements to RDF triples using an RML mapping mechanism. The generated triples are then validated for semantic correctness, including adherence to SPHN naming conventions and alignment with international terminologies such as SNOMED CT, LOINC, and ICD-10-GM, using SHACL constraints. The resulting RDF graphs are constructed using W3C standards for linked data, including RDF, RDFS, and OWL, ensuring interoperability and enabling data integration into a unified federated KG. This approach supports data linkage across different modalities (e.g. clinical, omics) and institutions, enabling advanced querying and applications in biomedical research. Although the SPHN Connector operates as a fully automated system from the user\u0026rsquo;s perspective, it remains fully documented and transparent, allowing detailed inspection and analysis of its internal processes.\u003c/p\u003e\n\u003cp\u003eAs of 2025, the SPHN Connector is deployed in production across the clinical data platforms of all Swiss university hospitals (University Hospital Basel, University Hospital Bern, Geneva University Hospitals, University Hospital of Lausanne, University Hospital Zurich, and the University Children\u0026rsquo;s Hospital Zurich) as well as in additional Swiss cantonal hospitals (e.g. Ente ospedaliero cantonale, Cantonal Hospital Baden, Cantonal Hospital Aargau, Cantonal Hospital Lucerne, and Cantonal Hospital St. Gallen).\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eIn a real-world scenario, we benchmarked the SPHN Connector at the University Hospital Zurich (USZ). The system was run in production with 8 CPUs, 48 GB RAM, and 500 GB disk space to transform 120,203 patients from a local relational database into PostgreSQL. From PostgreSQL to JSON conversion (including de-identification with date shift) through validation and delivery into RDF, the process required 3 days and 19 hours (see Table 1.). Without de-identification, the conversion completed in 2 days and 20 hours. This resulted in the production of two billion RDF triples across all patients, with individual patient RDF files (in TriG format) averaging 1 MB. The variation in file size reflects clinical data heterogeneity, from patients with minimal encounter records to those with comprehensive longitudinal data spanning multiple clinical domains. On average, each patient required approximately 2.7s (with de-identification) or 2.1s (without) of processing time. Validation is the most time-consuming step (48% without de-identification, 36% with) and its duration is correlated with the number of schema violations detected, making data quality a key determinant for an efficient processing of data. De-identification is also a time-consuming step (0.8s vs. 0.1s pre-check time for one patient on average with and without de-identification). Since this step is optional, data providers may use their own solutions (maybe more efficient) to de-identify data prior to ingestion into the SPHN Connector to accelerate the transformation process.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTable 1. Duration of each SPHN Connector phase at USZ in two separate runs.\u003c/strong\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003ea)\u003c/p\u003e\n\u003ctable border=\"0\" cellspacing=\"0\" cellpadding=\"0\" width=\"623\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd valign=\"bottom\" style=\"width: 203px;\"\u003e\n \u003cp\u003e\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003e\u003c/p\u003e\n \u003cp\u003e\u003cstrong\u003eRun 1\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 120px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eDuration all patients\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 134px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eDuration all patients (in seconds)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 166px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eAverage duration per patient (in seconds)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"bottom\" style=\"width: 203px;\"\u003e\n \u003cp\u003ePostgreSQL to JSON conversion\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 120px;\"\u003e\n \u003cp\u003e\u003cstrong\u003e01d 01:43:49\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 134px;\"\u003e\n \u003cp\u003e92 629\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 166px;\"\u003e\n \u003cp\u003e0.771\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"bottom\" style=\"width: 203px;\"\u003e\n \u003cp\u003ePre-check \u0026amp; de-identification\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 120px;\"\u003e\n \u003cp\u003e\u003cstrong\u003e01d 01:48:45\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 134px;\"\u003e\n \u003cp\u003e92 925\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 166px;\"\u003e\n \u003cp\u003e0.773\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"bottom\" style=\"width: 203px;\"\u003e\n \u003cp\u003eIntegration\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 120px;\"\u003e\n \u003cp\u003e\u003cstrong\u003e00d 06:35:21\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 134px;\"\u003e\n \u003cp\u003e23 721\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 166px;\"\u003e\n \u003cp\u003e0.197\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"bottom\" style=\"width: 203px;\"\u003e\n \u003cp\u003eValidation\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 120px;\"\u003e\n \u003cp\u003e\u003cstrong\u003e01d 09:00:16\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 134px;\"\u003e\n \u003cp\u003e118 816\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 166px;\"\u003e\n \u003cp\u003e0.988\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"bottom\" style=\"width: 203px;\"\u003e\n \u003cp\u003eTotal\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 120px;\"\u003e\n \u003cp\u003e03d 19:08:11\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 134px;\"\u003e\n \u003cp\u003e328 091\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 166px;\"\u003e\n \u003cp\u003e2.729\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eb)\u003c/p\u003e\n\u003ctable border=\"0\" cellspacing=\"0\" cellpadding=\"0\" width=\"623\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd valign=\"bottom\" style=\"width: 203px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eRun 2\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 117px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eDuration all patients\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 137px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eDuration all patients (in seconds)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 166px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eAverage duration per patient (in seconds)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"bottom\" style=\"width: 203px;\"\u003e\n \u003cp\u003ePostgreSQL to JSON conversion\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 117px;\"\u003e\n \u003cp\u003e\u003cstrong\u003e01d 01:43:49\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 137px;\"\u003e\n \u003cp\u003e92 629\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 166px;\"\u003e\n \u003cp\u003e0.771\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"bottom\" style=\"width: 203px;\"\u003e\n \u003cp\u003ePre-check\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 117px;\"\u003e\n \u003cp\u003e\u003cstrong\u003e00d 03:13:36\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 137px;\"\u003e\n \u003cp\u003e11 616\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 166px;\"\u003e\n \u003cp\u003e0.097\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"bottom\" style=\"width: 203px;\"\u003e\n \u003cp\u003eIntegration\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 117px;\"\u003e\n \u003cp\u003e\u003cstrong\u003e00d 06:35:21\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 137px;\"\u003e\n \u003cp\u003e23 721\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 166px;\"\u003e\n \u003cp\u003e0.197\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"bottom\" style=\"width: 203px;\"\u003e\n \u003cp\u003eValidation\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 117px;\"\u003e\n \u003cp\u003e\u003cstrong\u003e01d 09:00:16\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 137px;\"\u003e\n \u003cp\u003e118 816\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 166px;\"\u003e\n \u003cp\u003e0.988\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"bottom\" style=\"width: 203px;\"\u003e\n \u003cp\u003eTotal\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 117px;\"\u003e\n \u003cp\u003e02d 20:33:02\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 137px;\"\u003e\n \u003cp\u003e246 782\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"bottom\" style=\"width: 166px;\"\u003e\n \u003cp\u003e2.053\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eThis table reports the execution time of each phase (PostgreSQL to JSON conversion, Pre-check, Integration and Validation), as well as the total processing time for 120,000 patients processed in 12 batches. The average duration of each phase for each patient is also calculated. Two runs were performed: one including de-identification (a) and one without (b). Both runs were executed on an infrastructure with 8 CPUs, 48 GB RAM and 500 GB of disk space. The processing generated approximately two billion RDF triples, with an average RDF file size per patient of 1MB (minimum: 12KB; maximum: 107MB). Ingestion into PostgreSQL is ignored as this step is heavily dependent on the provider setup and tooling.\u003c/p\u003e"},{"header":"Discussion","content":"\u003cp\u003eThe implementation of the above-mentioned strategies reduces operational complexity, lowers the risk of transformation errors, and enhances reproducibility across data deliveries. By embedding validation rules directly into the tool and ensuring that all transformations follow a predictable and version-controlled path, the SPHN Connector fosters institutional trust in the data production process. Integration with external tools is intentionally modular, enabling the SPHN Connector to operate within diverse workflows while minimizing the impact of changes in external systems. Ultimately, this approach not only reduces the technical burden on hospital IT teams but also improves the quality and interoperability of the data.\u003c/p\u003e\n\u003cp\u003eOnce transformed into RDF KGs, data can be utilized in different architectural setups depending on governance and analysis needs. While these choices define how data can be stored and queried, practical deployment decisions are shaped by operational constraints and stakeholder feedback. In one approach, the data can be centralized within a trusted research environment (see Figure 4A), where central quality control, additional data curation and linking with other data, such as genomics or cohort data, is possible. Alternatively, a federated model can be employed (see Figure 4B), in which each institution maintains its own local triplestore. In this scenario, queries can be executed across distributed data sources, allowing analyses to be performed without requiring sensitive patient-level data to leave institutional boundaries. Both approaches ensure that the semantic richness of KGs can be exploited for downstream research while respecting local constraints.\u003c/p\u003e\n\u003cp\u003eHowever, while the SPHN Connector addresses a broad range of challenges, it is important to clarify its intended scope and limitations to avoid misinterpretation or unrealistic expectations. The SPHN Connector focuses on data transformation and validation. It is not a triplestore as it does not provide capabilities for RDF storage, querying, merging, or reasoning over graphs. In addition, the SPHN Connector does not aim to correct data errors from the source. It validates and reports inconsistencies with the definitions of the schema and terminologies but it is the responsibility of the data provider to ensure the accuracy and completeness of the source data. Finally, mapping of local terms to standard terminologies also remains the responsibility of the data provider as this requires domain-specific knowledge. Mapping involves decisions about clinical meaning, local coding practices, and institutional semantics, which cannot be automated or standardized centrally without risking misinterpretation or loss of critical information. Hence, this mapping must be done before using the tool and lies within the responsibility of the data provider. While emerging approaches such as artificial intelligence and large language models could potentially assist with these tasks.\u003c/p\u003e\n\u003cp\u003eDuring the design and implementation of the SPHN Connector, several discussions were held with stakeholders on possible alternative approaches, some of which are discussed below. These revealed opportunities for improvement as well as important constraints to consider.\u003c/p\u003e\n\u003cp\u003eDespite the support provided by the SPHN Connector, stakeholders have expressed that transforming data from clinical data warehouses into SPHN-compatible semantics remains a significant challenge, particularly when ingesting tabular data. This is primarily due to the integration of heterogeneous data sources into their pipelines but also the complexity of the SPHN RDF Schema, which represents healthcare concepts with rich contextual detail to support research needs. As a result, the SPHN Connector generated tabular DDL templates often lead to extensive tables with a high number of columns to be filled, reflecting the flat nature of tabular formats compared to the interconnected structure of RDF graphs. Nevertheless, most stakeholders acknowledge that the SPHN Connector offers substantial support as it reduces the burden of directly mapping their data to Semantic Web technologies but also developing means locally to validate their data. It also simplifies the migration of their pipelines from one schema version to the next. By offering an intermediate acceptable layer (tabular, JSON, CSV, Excel) as input, the tool simplifies the transformation process at the source. Currently, three university hospitals ingest data in tabular form, while two use JSON. Many stakeholders also recognize the value of knowledge graphs in achieving semantic interoperability, especially when supported with the SPHN RDF Schema, which ensures consistent understanding and sharing of data across Swiss institutions.\u003c/p\u003e\n\u003cp\u003eTo ensure long-term maintainability and alignment with evolving semantic standards, we are committed to supporting, with each SPHN Connector release, at the latest version of the SPHN RDF Schema, along with project-specific and other actively used schemas within the SPHN ecosystem. \u0026nbsp;Backward compatibility is maintained whenever possible. Actively used SPHN RDF Schemas are always supported. For example, the 2024.1 SPHN RDF Schema underwent a major restructuring that introduced new semantic patterns, nevertheless backward compatibility in the SPHN Connector was ensured between schema versions prior to 2024.1 and versions from 2024.1 onwards.\u003c/p\u003e\n\u003cp\u003eOne frequently mentioned topic was the horizontal scaling of the tool. While this approach could increase throughput for large datasets, the diversity in environments poses challenges for deploying such methods in practice. Stakeholders also discussed the possibility of connecting the tool directly to the hospital\u0026apos;s clinical data platforms (CDPs), avoiding intermediate data pushes and streamlining workflows. However, this would require highly customized versions of the SPHN Connector for each CDP. In this case, hospitals also expressed concerns about the security implications of granting such direct access, as this may bypass established governance. Hence, a more decoupled approach was considered safer and broadly acceptable, as reflected in the current implementation.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eFinally, we considered the processing of all data collectively, without splitting it into patient-specific workflows. While this approach appears advantageous from a performance perspective, it increases the risk of generating overlapping or inconsistent patient files and complicates debugging. The decision to adopt a patient-oriented workflow was motivated by the need for operational simplicity and consistency of data handling across the different sites.\u003c/p\u003e\n\u003cp\u003eOverall, the decisions implemented represent a balance between technical robustness and operational feasibility, ensuring stakeholders\u0026rsquo; trust while building a reliable and transparent RDF data transformation.\u003c/p\u003e"},{"header":"Conclusion","content":"\u003cp\u003eThe SPHN Connector exemplifies how from an architecture- and use case-driven approach, we implemented a tool that facilitates the construction of KGs from heterogeneous health data systems across Swiss healthcare institutions. Its development goes beyond simple data transformation, integrating KG-focused design principles to address the challenges of cross-institutional biomedical data integration in a consistent and maintainable way. Looking forward, the federated integration of knowledge graphs across domains and institutions represents a promising direction to not only enable broader data reuse but also address complex governance and data-sharing challenges.\u003c/p\u003e"},{"header":"Abbreviations","content":"\u003cp\u003eATC \u0026ndash; Anatomical Therapeutic Chemical\u003c/p\u003e\n\u003cp\u003eCDP \u0026ndash; Clinical Data Platforms\u003c/p\u003e\n\u003cp\u003eCHOP \u0026ndash; Swiss Classification of Surgical Interventions\u003c/p\u003e\n\u003cp\u003eCPUs \u0026ndash; Central processing units\u003c/p\u003e\n\u003cp\u003eCSV \u0026ndash; Comma Separated Values\u003c/p\u003e\n\u003cp\u003eDDL \u0026ndash; Data Definition Language\u003c/p\u003e\n\u003cp\u003eEHDEN \u0026ndash; European Health Data \u0026amp; Evidence Network\u003c/p\u003e\n\u003cp\u003eETL \u0026ndash; Extract Transform Load\u003c/p\u003e\n\u003cp\u003eFAIR \u0026ndash; Findable Accessible Interoperable Reusable\u003c/p\u003e\n\u003cp\u003eFHIR \u0026ndash; Fast Healthcare Interoperability Resources\u003c/p\u003e\n\u003cp\u003eGB \u0026ndash; Gigabyte\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eKB \u0026ndash; Kilobyte\u003c/p\u003e\n\u003cp\u003eKG(s) \u0026ndash; Knowledge Graph(s)\u003c/p\u003e\n\u003cp\u003eICD-10-GM \u0026ndash; International Statistical Classification of Diseases and Related Health Problems 10th revision German modification\u003c/p\u003e\n\u003cp\u003eIRI - Internationalized Resource Identifier\u003c/p\u003e\n\u003cp\u003eJSON \u0026ndash; JavaScript Object Notation\u003c/p\u003e\n\u003cp\u003eMB \u0026ndash; Megabyte\u003c/p\u003e\n\u003cp\u003eOBO \u0026ndash; Open Biological and Biomedical Ontology\u003c/p\u003e\n\u003cp\u003eOHDSI \u0026ndash; Observational Health Data Sciences and Informatics\u003c/p\u003e\n\u003cp\u003eOMOP \u0026ndash; Observational Medical Outcomes Partnership\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eRAM \u0026ndash; Random Access Memory\u003c/p\u003e\n\u003cp\u003eRDF \u0026ndash; Resource Description Framework\u003c/p\u003e\n\u003cp\u003eSHACL \u0026ndash; Shapes Constraint Language\u003c/p\u003e\n\u003cp\u003eSQL \u0026ndash; Structured Query Language\u003c/p\u003e\n\u003cp\u003eSPARQL \u0026ndash; SPARQL Protocol and RDF Query Language\u003c/p\u003e\n\u003cp\u003eSPHN \u0026ndash; Swiss Personalized Health Network\u003c/p\u003e\n\u003cp\u003eUID \u0026ndash; Unternehmens-Identifikationsnummer (in english: standardised business identification number)\u003c/p\u003e"},{"header":"Declarations","content":"\u003ch2\u003eEthics approval and consent to participate\u003c/h2\u003e\n\u003cp\u003eNot applicable.\u003c/p\u003e\n\u003ch2\u003eConsent for publication\u003c/h2\u003e\n\u003cp\u003eAll authors have consented for publication of the manuscript.\u003c/p\u003e\n\u003ch2\u003eAvailability of data and materials\u003c/h2\u003e\n\u003cul class=\"decimal_type\"\u003e\n \u003cli\u003eTool name: SPHN Connector\u003c/li\u003e\n \u003cli\u003eTool home page: https://git.dcc.sib.swiss/sphn-semantic-framework/sphn-connector\u0026nbsp;\u003c/li\u003e\n \u003cli\u003eOperating system(s): Linux, Windows\u003c/li\u003e\n \u003cli\u003eMain programming language: Python\u003c/li\u003e\n \u003cli\u003eOther requirements: Docker\u003c/li\u003e\n \u003cli\u003eLicense: GNU GPL v3.0\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003eFunding\u003c/h2\u003e\n\u003cp\u003eThis work was funded by the Swiss State Secretary of Research and Innovation (SERI) through the Swiss Personalized Health Network (SPHN).\u003c/p\u003e\n\u003ch2\u003eCompeting Interests\u003c/h2\u003e\n\u003cp\u003eThe authors have no conflict of interest.\u003c/p\u003e\n\u003ch2\u003eAuthors\u0026rsquo; contributions\u003c/h2\u003e\n\u003cp\u003eSOE; PK; VT; DU; NS; MP; KK designed the strategy for the knowledge graph and conceptualized the SPHN Connector. PK; ABM; NS; MP; KK developed the SPHN Connector. KK tested the SPHN Connector in a real-world setting. SOE led the project. VT; PK; DU; SOE wrote the manuscript. All authors contributed to and approved the final version of the manuscript.\u003c/p\u003e\n\u003ch2\u003eAcknowledgments\u003c/h2\u003e\n\u003cp\u003eWe would like to acknowledge the five project teams at the Swiss University Hospitals for regularly installing and testing the tool in a production environment, and providing feedback. We also would like to acknowledge the BioMedIT team and especially the security working group for checking the coverage of the security requirements of the tool and providing us with a test environment. We thank Cl\u0026eacute;ment Parisato for his guidance regarding legal aspects, as well as the de-identification working group for defining the de-identification rules which we applied in the SPHN Connector, especially Dr. Julia Maurer, Dr. Jan Armida, Dr. Jean Louis Raisaro and Prof. Fabian Prasser. We would like to thank the SPHN IT Architecture working group for identifying the necessary requirements for such a tool which were addressed in the current SPHN Connector implementation, especially a big thank you to Markus Obreiter. Finally, we would like to acknowledge Patrick Hirschi and Nadine Then\u0026eacute;e for actively supporting this project.\u003c/p\u003e"},{"header":"References","content":"\u003col\u003e\n\u003cli\u003eFr\u0026ouml;hlich H, Balling R, Beerenwinkel N, Kohlbacher O, Kumar S, Lengauer T, et al. From hype to reality: data science enabling personalized medicine. BMC Med 2018;16:150.\u003c/li\u003e\n\u003cli\u003eWilkinson MD, Dumontier M, Aalbersberg IjJ, Appleton G, Axton M, Baak A, et al. The FAIR Guiding Principles for scientific data management and stewardship. Sci Data 2016;3:160018. https://doi.org/10.1038/sdata.2016.18.\u003c/li\u003e\n\u003cli\u003eRDF 1.1 Concepts and Abstract Syntax. https://www.w3.org/TR/rdf11-concepts/ (accessed October 22, 2025).\u003c/li\u003e\n\u003cli\u003eTour\u0026eacute; V, Krauss P, Gnodtke K, Buchhorn J, Unni D, Horki P, et al. FAIRification of health-related data using semantic web technologies in the Swiss Personalized Health Network. Sci Data 2023;10:127. https://doi.org/10.1038/s41597-023-02028-y.\u003c/li\u003e\n\u003cli\u003eSHACL. https://www.w3.org/TR/shacl/ (accessed October 22, 2025).\u003c/li\u003e\n\u003cli\u003eSPARQL 1.1 Query Language. https://www.w3.org/TR/sparql11-query/ (accessed October 22, 2025).\u003c/li\u003e\n\u003cli\u003eTour\u0026eacute; V, Unni D, Krauss P, Abdelwahed A, Buchhorn J, Hinderling L, et al. The SPHN Schema Forge\u0026ndash;transform healthcare semantics from human-readable to machine-readable by leveraging semantic web technologies. J Biomed Semantics 2025;16:9.\u003c/li\u003e\n\u003cli\u003eBenson T, Grieve G. SNOMED CT. In: Benson T, Grieve G, editors. Principles of Health Interoperability: SNOMED CT, HL7 and FHIR, Cham: Springer International Publishing; 2016, p. 155\u0026ndash;72. https://doi.org/10.1007/978-3-319-30370-3_9.\u003c/li\u003e\n\u003cli\u003eATCDDD \u0026ndash; Home. https://atcddd.fhi.no (accessed October 22, 2025).\u003c/li\u003e\n\u003cli\u003eICD-10-GM. https://www.bfarm.de/EN/Code-systems/Classifications/ICD/ICD-10-GM/_node.html.7 (accessed October 22, 2025).\u003c/li\u003e\n\u003cli\u003eKrauss P, Tour\u0026eacute; V, Gnodtke K, Crameri K, \u0026Ouml;sterle S. DCC terminology service\u0026mdash;an automated CI/CD pipeline for converting clinical and biomedical terminologies in graph format for the Swiss personalized health network. Applied Sciences 2021;11:11311. https://doi.org/10.3390/app112311311.\u003c/li\u003e\n\u003cli\u003eBelleau F, Nolin M-A, Tourigny N, Rigault P, Morissette J. Bio2RDF: towards a mashup to build bioinformatics knowledge systems. J Biomed Inform 2008;41:706\u0026ndash;16.\u003c/li\u003e\n\u003cli\u003eThe UniProt Consortium. UniProt: the universal protein knowledgebase. Nucleic Acids Res 2017;45:D158\u0026ndash;69. https://doi.org/10.1093/nar/gkw1099.\u003c/li\u003e\n\u003cli\u003eKnox C, Wilson M, Klinger CM, Franklin M, Oler E, Wilson A, et al. DrugBank 6.0: the DrugBank knowledgebase for 2024. Nucleic Acids Res 2024;52:D1265\u0026ndash;75.\u003c/li\u003e\n\u003cli\u003ePutman TE, Schaper K, Matentzoglu N, Rubinetti VP, Alquaddoomi FS, Cox C, et al. The Monarch Initiative in 2024: an analytic platform integrating phenotypes, genes and diseases across species. Nucleic Acids Res 2024;52:D938\u0026ndash;49.\u003c/li\u003e\n\u003cli\u003eJackson R, Matentzoglu N, Overton JA, Vita R, Balhoff JP, Buttigieg PL, et al. OBO Foundry in 2021: operationalizing open data principles to evaluate ontologies. Database 2021;2021:baab069.\u003c/li\u003e\n\u003cli\u003eSmith B, Ashburner M, Rosse C, Bard J, Bug W, Ceusters W, et al. The OBO Foundry: coordinated evolution of ontologies to support biomedical data integration. Nat Biotechnol 2007;25:1251\u0026ndash;5. https://doi.org/10.1038/nbt1346.\u003c/li\u003e\n\u003cli\u003eCaufield JH, Putman T, Schaper K, Unni DR, Hegde H, Callahan TJ, et al. KG-Hub\u0026mdash;building and exchanging biological knowledge graphs. Bioinformatics 2023;39:btad418.\u003c/li\u003e\n\u003cli\u003eUnni DR, Moxon SAT, Bada M, Brush M, Bruskiewich R, Caufield JH, et al. Biolink Model: A universal schema for knowledge graphs in clinical, biomedical, and translational science. Clin Transl Sci 2022;15:1848\u0026ndash;55.\u003c/li\u003e\n\u003cli\u003eCallahan TJ, Tripodi IJ, Stefanski AL, Cappelletti L, Taneja SB, Wyrwa JM, et al. An open source knowledge graph ecosystem for the life sciences. Sci Data 2024;11:363.\u003c/li\u003e\n\u003cli\u003eSy MF, Roman B, Kerrien S, Mendez DM, Genet H, Wajerowicz W, et al. Blue Brain Nexus: An open, secure, scalable system for knowledge graph management and data-driven science. Semant Web 2023;14:697\u0026ndash;727.\u003c/li\u003e\n\u003cli\u003eOMOP Common Data Model. https://ohdsi.github.io/CommonDataModel (accessed October 22, 2025).\u003c/li\u003e\n\u003cli\u003eHripcsak G, Duke JD, Shah NH, Reich CG, Huser V, Schuemie MJ, et al. Observational Health Data Sciences and Informatics (OHDSI): opportunities for observational researchers. Stud Health Technol Inform 2015;216:574.\u003c/li\u003e\n\u003cli\u003eComan Schmid D, Crameri K, Oesterle S, Rinn B, Sengstag T, Stockinger H, et al. SPHN\u0026ndash;The BioMedIT Network: a secure IT platform for research with sensitive human data. Digital personalized health and medicine, IOS Press; 2020, p. 1170\u0026ndash;4.\u003c/li\u003e\n\u003cli\u003eBray T. The javascript object notation (json) data interchange format. 2014.\u003c/li\u003e\n\u003cli\u003eBraunstein ML, Braunstein ML. Health Informatics on FHIR: How HL7\u0026rsquo;s API is Transforming Healthcare. Springer; 2022.\u003c/li\u003e\n\u003cli\u003eOrmond K, Bavamian S, Becherer C, Currat C, Joerger F, Geiger TR, et al. What are the bottlenecks to health data sharing in Switzerland? An interview study. Swiss Med Wkly 2024;154:3538.\u003c/li\u003e\n\u003cli\u003eLightRDF. https://github.com/ozekik/lightrdf (accessed October 22, 2025).\u003c/li\u003e\n\u003cli\u003eBerman J, Sterling C, Taprest R, Nezbeda H, Rosen S, chen wilson, et al. python-jsonschema/jsonschema: v4.25.1 2025. https://doi.org/10.5281/zenodo.16896019.\u003c/li\u003e\n\u003cli\u003eDimou A, Vander Sande M, Colpaert P, Verborgh R, Mannens E, Van de Walle R. RML: A generic language for integrated RDF mappings of heterogeneous data. Ldow 2014;1184.\u003c/li\u003e\n\u003cli\u003eHeyvaert P, Van Assche D, De Meester B, Haesendonck G, de Vleeschauwer E, Sitt Min Oo. RMLMapper. https://doi.org/10.5281/zenodo.3929132.\u003c/li\u003e\n\u003cli\u003eSPHN RDF Quality Check Tool. https://git.dcc.sib.swiss/sphn-semantic-framework/sphn-rdf-quality-check-tool (accessed October 22, 2025).\u003c/li\u003e\n\u003cli\u003eNaming convention for SPHN data instances. https://www.bfs.admin.ch/bfs/en/home/registers/enterprise-register/enterprise-identification/uid-general.html (accessed October 22, 2025).\u003c/li\u003e\n\u003cli\u003eThe UID in general. https://www.bfs.admin.ch/bfs/en/home/registers/enterprise-register/enterprise-identification/uid-general.html (accessed October 22, 2025).\u003c/li\u003e\n\u003cli\u003eDavis KR, Peabody B, Leach P. Universally Unique IDentifiers (UUIDs) 2024. https://doi.org/10.17487/RFC9562.\u003c/li\u003e\n\u003cli\u003ePostgreSQL. https://www.postgresql.org/ (accessed October 22, 2025).\u003c/li\u003e\n\u003cli\u003eTour\u0026eacute; V, Unni D, Krauss P, Abdelwahed A, Buchhorn J, Hinderling L, et al. The SPHN Schema Forge\u0026ndash;transform healthcare semantics from human-readable to machine-readable by leveraging semantic web technologies. J Biomed Semantics 2025;16:9.\u003c/li\u003e\n\u003cli\u003eUnni D, Tour\u0026eacute; V, Krauss P, Crameri K, \u0026Ouml;sterle S. SPHN strategy to unravel the semantic drift between versions of standard terminologies 2023.\u003c/li\u003e\n\u003cli\u003eFastAPI. https://github.com/fastapi/fastapi (accessed October 22, 2025).\u003c/li\u003e\n\u003cli\u003eSPHN Connector User Guide documentation. https://git.dcc.sib.swiss/sphn-semantic-framework/sphn-connector/-/blob/main/docs/SPHN-Connector_User-Guide.pdf (accessed October 22, 2025). \u003c/li\u003e\n\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":true,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":false,"hideJournal":false,"highlight":"","institution":"","isAcceptedByJournal":true,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"bmc-medical-informatics-and-decision-making","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"midm","sideBox":"Learn more about [BMC Medical Informatics and Decision Making](http://bmcmedinformdecismak.biomedcentral.com/)","snPcode":"","submissionUrl":"https://www.editorialmanager.com/midm/default.aspx","title":"BMC Medical Informatics and Decision Making","twitterHandle":"BMC_series","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"em","reportingPortfolio":"BMC Series","inReviewEnabled":true,"inReviewRevisionsEnabled":true},"keywords":"Knowledge graphs, Semantic Web, Linked Data, Data Provisioning, Clinical Real-World Data","lastPublishedDoi":"10.21203/rs.3.rs-7930982/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-7930982/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003cp\u003e\u003cstrong\u003eBackground:\u003cbr\u003e\n \u003c/strong\u003eThe integration and reuse of heterogeneous health data, including clinical records, cohort studies, and omics datasets, are essential for advancing modern biomedical research. Knowledge graphs offer a powerful means to semantically link such data, enabling interoperability and reuse. The Swiss Personalized Health Network has developed a comprehensive semantic interoperability framework to implement the FAIR (Findable, Accessible, Interoperable, Reusable) principles at a national level.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eMethods:\u003cbr\u003e\n \u003c/strong\u003eThis paper presents the adopted strategy and the resulting tool for building such federated knowledge graphs, marking a shift from centralized approaches to a model where hospitals and research partners semantically enrich and produce their own data locally.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResults:\u003cbr\u003e\n \u003c/strong\u003eA core component enabling the implementation of this strategy is the SPHN Connector, a tool designed to tackle the technical challenges of this process. It converts diverse data formats into semantically enriched RDF, and offers capabilities for data transformation, de-identification, and validation, particularly for iterative delivery in a federated context.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eConclusion:\u003cbr\u003e\n \u003c/strong\u003eThese generated datasets can then either be integrated centrally or used in a federated way, allowing for the linkage of information from the same patient, for example, clinical routine data and omics metadata, as well as the combination of data from different patients across sites.\u003c/p\u003e","manuscriptTitle":"SPHN Connector - A scalable pipeline for generating validated knowledge graphs from federated and semantically enriched health data","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2025-11-04 13:41:49","doi":"10.21203/rs.3.rs-7930982/v1","editorialEvents":[{"type":"communityComments","content":0},{"type":"decision","content":"Revision requested","date":"2025-12-01T10:09:56+00:00","index":"","fulltext":""},{"type":"editorInvitedReview","content":"","date":"2025-11-28T17:04:31+00:00","index":"hide","fulltext":""},{"type":"editorInvitedReview","content":"","date":"2025-11-06T16:10:46+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"72460885579715364470847295492822946911","date":"2025-11-04T12:04:37+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"148131813552148088435209632499183577334","date":"2025-10-28T08:27:34+00:00","index":"hide","fulltext":""},{"type":"reviewersInvited","content":"","date":"2025-10-27T09:59:29+00:00","index":"","fulltext":""},{"type":"editorAssigned","content":"","date":"2025-10-24T08:14:50+00:00","index":"","fulltext":""},{"type":"checksComplete","content":"","date":"2025-10-24T08:12:25+00:00","index":"","fulltext":""},{"type":"submitted","content":"BMC Medical Informatics and Decision Making","date":"2025-10-23T09:51:08+00:00","index":"","fulltext":""}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"bmc-medical-informatics-and-decision-making","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"midm","sideBox":"Learn more about [BMC Medical Informatics and Decision Making](http://bmcmedinformdecismak.biomedcentral.com/)","snPcode":"","submissionUrl":"https://www.editorialmanager.com/midm/default.aspx","title":"BMC Medical Informatics and Decision Making","twitterHandle":"BMC_series","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"em","reportingPortfolio":"BMC Series","inReviewEnabled":true,"inReviewRevisionsEnabled":true}}],"origin":"","ownerIdentity":"93559477-d016-4961-a8bd-f29882e2ad4d","owner":[],"postedDate":"November 4th, 2025","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"published-in-journal","subjectAreas":[],"tags":[],"updatedAt":"2026-02-16T16:07:18+00:00","versionOfRecord":{"articleIdentity":"rs-7930982","link":"https://doi.org/10.1186/s12911-026-03383-7","journal":{"identity":"bmc-medical-informatics-and-decision-making","isVorOnly":false,"title":"BMC Medical Informatics and Decision Making"},"publishedOn":"2026-02-13 15:58:45","publishedOnDateReadable":"February 13th, 2026"},"versionCreatedAt":"2025-11-04 13:41:49","video":"","vorDoi":"10.1186/s12911-026-03383-7","vorDoiUrl":"https://doi.org/10.1186/s12911-026-03383-7","workflowStages":[]},"version":"v1","identity":"rs-7930982","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-7930982","identity":"rs-7930982","version":["v1"]},"buildId":"8U1c8b4HqxoKbykW_rLl7","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}