The referenced studies were carried out in adherence with the Declaration of Helsinki and approved by the local medical ethics committees of Kiel University (approval B279/18 and D596/22). Informed consent was obtained from all of the participants in the studies.

Our methodology is based on the Framework for Evaluation in Design Science Research (FEDS) by Venable et al [17], which describes the process from defining the problem, through deriving a solution based on requirement engineering (RE), evaluating the platform, and communicating the outcomes.

The FEDS consists of 4 components: problem, solution, evaluation, and communication.

The evaluation component involves a requirement-based artifact evaluation of the platform against the identified requirements. The primary focus lies on evaluating the functional aspects identified in the RE process. While detailed benchmarking of nonfunctional qualities (eg, performance or scalability) is beyond the current scope, quantitative insights (eg, volume of integrated laboratory data) are included. We use a technical artifact evaluation strategy guided by the quality model defined in International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 25010 [27], part of the ISO/IEC 25000 SQuaRE framework. This allows us to focus on relevant quality attributes such as interoperability, reusability, data consistency, and usability (see Key Aspects of the Platform section). The evaluation is accompanied by 2 real-world scenario-based assessments, each chosen for its distinct technical requirements:

To operationalize the qualitative scenario evaluation, we applied different evaluation activities depending on the nature of the requirement and its implementation status. These activities were selected to provide traceable evidence for requirement fulfillment, in line with the ISO/IEC 25000 standard framework. Specifically, the following evaluation activities were used:

These activities support a systematic evaluation of how well the platform meets the functional requirements derived from the RE process. All evaluation activities were conducted by the institution’s Data Integration Unit, a dedicated team of medical informatics experts, data engineers, and platform architects. An additional evaluation scenario is provided in Multimedia Appendix 2.

The final step involves disseminating results to relevant stakeholders. In our case, we communicate findings through this study and use them internally to inform researchers and clinicians to promote the platform and its functionalities.

Following these structured phases ensures that the platform’s development and evaluation align with its goal of enabling interoperability and the effective health care data use across multiple domains by leveraging data integration as a central strategy.

With more than 500,000 encounters (approximately 100,000 inpatients and approximately 400,000 outpatients) annually and about 17,000 employees, University Hospital Schleswig-Holstein (UKSH) is one of the largest university hospitals in Germany and the only hospital providing maximum medical care in the state of Schleswig-Holstein (Northern Germany) [28]. It operates across 2 locations, Kiel and Lübeck, in partnership with the Medical Faculty of Kiel University and the Medical Section of the Universität zu Lübeck, forming a central hub for academic medicine in Northern Germany.

The current IT system landscape at UKSH consists of different types of information systems. The CIS builds the core of the IT system landscape, provides a general overview of the patient’s history, and serves as a basis for documentation and communication across health care domains. In addition, there are specialized department-specific systems, such as radiology information systems (RIS) or echocardiography systems in cardiology. Finally, there are the function-specific specialized systems like LIS and ePMA that support specific workflows or tasks independent of the respective department. The existence of these various systems challenges data integration, harmonization, and coding and requires careful attention to ensure that all necessary information is captured and managed appropriately. The IT system landscape and its limited semantic interoperability between the different systems often result in patient data spreading across multiple systems, sometimes even redundantly. This fragmentation complicates timely access to required information and poses challenges for researchers who require timely access to relevant data, ultimately hindering effective data use and analysis.

Moreover, there is a client separation in health care, with patient care and research operating independently from an IT and data perspective. Typically, clinicians are responsible for treating patients and have access to patient-level data for that purpose only. The processes and IT systems used in patient care are often disjoint from those used for clinical and biomedical research. Accordingly, it is inherent in the nature of these IT systems that they are primarily designed for patient care purposes rather than research, that is, supporting patient-level data access, but not cohort-level access. The organizational separation between patient care and research is partly also mandated by regulation, requiring researchers to obtain patient consent and adhere to additional processes to access the necessary data. As a result, clinicians researching on patient data either request a data export from the clinical IT service provider or manually extract the data via the applications’ user interfaces (ie, redundant data entry). Both are time-consuming, highly inefficient, and prone to transmission errors, leading to potential inaccuracies in the data and generating irreproducible research findings. Data exports are often raw CSV files per IT system, which requires manual data linkage and transformations to ensure consistency in units of measurement, as well as annotations with appropriate terminologies before allowing effective data analysis. In addition to the client separation, there is also a significant lack of automatic knowledge transfer between patient care and research. However, there is a demand in patient care for access to the latest scientific discoveries and insights to inform and improve clinical decision-making.

This study presents the implementation and requirement-based evaluation of a health knowledge management platform at UKSH, assessed against 39 functional requirements and 2 real-world scenarios. To overcome the traditional separation between patient care and biomedical research, the platform integrates heterogeneous clinical data (eg, CIS, PACS, and LIS) into a structured, interoperable environment [50]. Requirements were derived through stakeholder focus groups, building upon the developed requirements catalog by Kinast et al (30/39, 77%) [25]. The catalog provided a comprehensive and systematically defined foundation for key interoperability and data integration requirements, enabling efficient requirements formalization and traceable coverage. In total, 9 of 39 (23%) additional requirements were specified using ISO 29148-compliant syntax to address context-specific needs. Overall, 30 of 39 (77%) requirements are fully implemented, while the cardiology scenario fulfills 26 of 39 (67%) and the radiology scenario fulfills 23 of 39 (59%).

However, its functional scope extends well beyond the functionalities necessary to support the selected scenarios. For example, the platform integrates radiological images (eg, x-ray, CT, and magnetic resonance imaging) together with corresponding free-text reports (DA-01-3) [48], although structured extraction and storage of report content in the CDR are not yet implemented. Two requirements stay partially or not yet fulfilled: single sign-on, which is currently limited to selected applications (eg, MTB; DSC-12), and linkage of external public data sources (DP-19). The latter, including integration of regional death registries, is on hold due to legal and organizational constraints.

The integration of patient profile-based information from public sources (DP-19), for example, to support advanced decision support use cases, remains conceptually defined but not yet operational due to legal and technical constraints. Together with the incomplete single-sign-on integration (DSC-12), these gaps reflect the current implementation status rather than architectural limitations.

Our platform supports a range of data-driven applications via the data access layer, although user group-specific interfaces for predictive data analysis (DR-03-1) have yet to be developed. A key challenge is the prevalence of unstructured clinical documentation, which limits structured reuse and data quality [51]. To address this, the normalization layer is being extended with natural language processing capabilities, and an initial pipeline for allergy information extraction from discharge letters (DP-02) has been implemented [31].

An MTB application has been deployed, enabling visualization of oncological histories, patient comparison and cohort identification, and analytical functionalities (DAS-03, DR-03, and DR-03-3) [39,52]. It is also in active use to support patient care as part of the MTB meetings. Additional functionalities include end-user cohort exploration (DR-01) and data entry (DR-05) that are planned but currently restricted to specific user groups, that is, system administrators or study nurses, respectively. Our platform shares its openEHR-based foundation with the system described by Biermann et al [53], whose work on patient trajectory analysis and predictive interfaces illustrates the extensibility of this architecture. However, some applications envisioned remain on the roadmap (eg, patients like mine and end user–enabled cohort exploration). The identified gaps highlight the need for further iterative development to realize the platform’s full potential. Its design was guided by defined key aspects (see Key Aspects of the Platform section), aiming to ensure relevant quality attributes such as interoperability, reusability, data consistency, and usability aligned with the specific requirements of the UKSH environment.

A key architectural decision was the adoption of an openEHR-based CDR instead of a FHIR-based repository. While FHIR primarily supports real-time data exchange, openEHR provides a semantically rich, longitudinal data model suitable for persistent storage and consistent querying across both patient and cohort levels, posing an essential requirement for secondary use and advanced analytics [54]. Its archetype-based approach enables explicit clinical content modeling, ensuring semantic consistency and modular reuse across use cases and front ends while maintaining interoperability via FHIR interfaces. This decision is supported by the growing adoption of openEHR across European health care systems, including countries such as Slovenia [55], Sweden [56], Norway, and Finland [57] as well as major academic hospitals such as Karolinska University Hospital and University Hospital Basel [58], and the region of Catalonia [59]. The approach also aligns with the open platform principles defined by the Aperta Foundation [60], which promote openness, semantic interoperability, and modularity.

To complement this foundation, FHIR-based applications could be integrated into the application layer, enabling patients to contribute personal health data (PGHD). Conceptually, such applications could also be considered part of the PEHR within the source layer, with data integrated bottom-up via the data lake. The platform architecture and interfaces are designed to support both integration options, allowing source systems either to maintain independent persistence or to rely on the platform’s normalization layer as a shared persistence layer. We did not consider integrating the knowledge management platform directly into the CIS, as CIS platforms are primarily designed for billing, individual patient-level care, and documentation rather than cohort-level analysis or research data export. Establishing a separate platform increases architectural flexibility, without interfering with clinical workflows or billing-related functionality constraints. This also ensures that patient care remains uncompromised, as CIS and corresponding systems are not burdened with additional loads from research-related queries. Furthermore, it aligns with Findable, Accessible, Interoperable, Reusable principles by enhancing data accessibility and promoting reuse in research contexts [24].

In the platform’s initial architectural design, IHE profiles played a significant role [15]. Currently, Patient Identifier Cross-Referencing [33] and Patient Demographics Query [34] are used within the MPI, along with Advanced Patient Privacy Consents [61] for consent management. Many openEHR compositions are additionally persisted as IHE XDS-compliant documents. However, as XDS-based access retrieval is not required for current scenarios, data retrieval is performed via openEHR AQL. The architectural separation of patient identifiers, consent data, and medical content supports data protection and enables modular governance. In alignment with IHE principles, our platform manages an MPI, a consent repository, and a CDR to persist the respective data types. This modular structure enables precise permission management via fine-grained consent enforcement [35]. Currently, the platform supports consents for the research-related use of patient care data, leftover biomaterial, recontact in case of incidental findings, and recontact for future research projects (ie, recruitment and follow-up) [35]. Because the platform processes both consented and nonconsented patient data, it can also support legally authorized research models beyond informed consent, such as opt-out–based research based on a specific regulation.

One limitation concerns the stakeholder selection in the requirements elicitation process, which primarily emphasized functional requirements. Nonfunctional aspects such as scalability, security, performance, and usability were considered at the architectural level but not systematically elicited as explicit requirements. The platform’s modular and layered architecture follows separation of concerns principles, allowing nonfunctional requirements to be addressed within specific components. However, these aspects were not formally evaluated in this study.

Although the requirements catalog by Kinast et al [25] facilitated the formalization and data integration requirements, it did not address user interface aspects. Consequently, 9 additional requirements had to be specified separately, expanding the scope of the RE process. The RE process did not include a dedicated study-specific stakeholder analysis. However, participation in the HiGHmed consortium ensured broad clinical domain representation across multiple use cases [15]. Additional requirements were elicited through engagement with clinicians involved in the evaluated scenarios.

The platform builds on an openEHR CDR, a technology traditionally applied to electronic health records in institutional or regional infrastructures [62-64]. Our application as a knowledge management platform integrating both research and patient care contexts represents an extended use of this technology.

Structured data are a prerequisite not only for research scenarios and applications but also for decision support. However, clinical documentation still heavily relies on unstructured free-text, either entered directly into the CIS or recorded through dictation and transcription. As a result, requirements such as DR-03-1 to DR-03-3 remain a challenge, as the respective functionalities depend on structured data. This highlights the need to establish structured data as a foundation before enabling advanced care functionalities. To address this, we plan to expand the platform’s normalization layer to further include natural language processing and information extraction features, enabling the processing and structuring of the large volume of free-text reports from the CIS and its subsystems [31].

Finally, the evaluation has primarily focused on research-oriented scenarios. Broader deployment in routine care, especially for real-time decision support, remains to be assessed. Although the platform provides the necessary technical interfaces, additional application development is required to evaluate clinical integration at scale, fully demonstrating the platform’s potential in both biomedical research and patient care settings.

Every modification of an IT system poses risks to data consistency, availability, and quality, particularly when integrating heterogeneous source systems via different interfaces [65]. Each data transformation step introduces the potential for errors, and repeated transformation increases the risk of inconsistencies between datasets. Our approach of acquiring raw data and transforming them centrally only once reduces repeated transformations but still introduces transformation risks. To mitigate these, we use automated processing, code reviews, and structured testing procedures [66]. Nevertheless, occasional errors occur. Once identified, the corresponding extract-transform-load process is corrected, and the affected data are reintegrated from the original S3 storage. Although issues in the source data itself cannot be resolved, detected anomalies can be flagged within the integrated data view.

Data reliability varies by type and depends on the original purpose of documentation. For example, laboratory measurements are typically generated through standardized processes, whereas billing-related data such as diagnoses or procedures follow regulatory and reimbursement-driven documentation logic. Platform transparency regarding data provenance and quality is therefore essential. Each newly integrated data source typically includes the complete dataset of the corresponding system, including live and legacy data, rather than cohort-specific subsets. This “integrate once, use many” strategy promotes long-term sustainability and data reuse.

Beyond technical risks, governance and long-term maintenance represent additional challenges. Sustainable operation depends on strong organizational support and compliance with data privacy regulations. At UKSH, the platform is institutionally anchored through a board resolution and supported by internal funding as well as national initiatives (Network University Medicine), which adds to its long-term stability.

Our health knowledge management platform integrates both health care and research functionalities within a unified architecture. This contrasts with many existing initiatives that focus either on specific use cases or predominantly on research-oriented data integration [67-69].

In Germany, initiatives such as the Medical Informatics Initiative and Network University Medicine [16] have significantly advanced health care data integration. As part of the HiGHmed consortium, we set the foundation for our platform by introducing open platforms and interoperability principles to enhance health care and research across institutional boundaries [15]. Building on this foundation, our platform extends these concepts by integrating both research and health care functionalities within a single integrated platform. Similarly, MIRACUM and DIFUTURE focus on cross-institutional data integration and secondary analyses to inform clinical practice and medical innovation [70,71]. While these initiatives emphasize research data use, our platform bridges the gap by unifying research and health care workflows, enabling bidirectional data reuse.

Internationally, comparable efforts exist. For instance, the Mayo Clinic Platform facilitates secure access to deidentified clinical data for research and innovation [72]. Unlike Mayo’s Enterprise Data Trust, which primarily functions as a nontransactional analytics repository, our platform additionally supports real-time clinical workflows (eg, MTB) and research data capture directly from patient care processes, enabling immediate translational use within UKSH. Similarly, the World Health Organization’s Integrated Data Platform supports large-scale population health monitoring [73] but does not integrate institutional patient care and research workflows within a unified platform.

Overall, while prior initiatives have significantly contributed to secondary use of health care data, our platform emphasizes the operational integration of health care and research through centralized consent management and a layered architecture based on separation of concerns principles.

This study describes and evaluates the UKSH health knowledge management platform, demonstrating how its multistandards approach effectively addresses interoperability challenges while ensuring data consistency. The scenario-based evaluation illustrates the platform’s capability to support research based on real-world health care data. Its layered architecture and harmonization processes provide a structured data access layer that enables both clinical and research applications.

Future developments will focus on (1) expanding the application layer with cohort exploration tools and AI-supported data analysis tools [18] and (2) developing user-specific interfaces to enhance clinical usability. Hereby, we expect benefits through a reduction of manual data preparation for cohort identification, enabling more efficient study planning and data-driven health care. These applications will be developed to create a direct impact on patient care based on the partially and unfulfilled requirements, which will undergo further evaluation. Inspired by the “Ten Topics to Get Started in Medical Informatics Research” [74], our platform has the potential to improve several key areas in medical informatics, pushing the boundaries of both clinical practice and research capabilities.