Abstract
Objective
Design, implement and evaluate eHealth4U, a prototype national electronic health record (EHR) system for Cyprus, so that the national eHealth law of Cyprus is operationalised into a citizen-centred service that remains interoperable with myHealth@EU and the International Patient Summary (IPS).
Methods
The provisions of the Cyprus eHealth law were analysed and translated into functional and non-functional requirements that structured the system's architecture, services and user-facing workflows. eHealth4U was implemented as a cloud-based microservices platform with authentication and authorisation controls, and interoperability based on the Fast Healthcare Interoperability Resources of Health Level Seven, including the IPS. The system verification comprised more than 400 unit test cases. Usability was assessed through task-based testing and questionnaires with 30 medical doctors and 57 patients, using key performance indicators such as task success, satisfaction and observed error occurrence. Interoperability was assessed using two x-eHealth hackathons and three IPS Connectathons.
Results
eHealth4U supports the IPS and myHealth@EU cross-border service requirements. Usability was rated 4.5/5, with a task success rate of 98% for doctors and 99% for patients, and an overall satisfaction of 95%. The observed error occurrence affected approximately 10% of doctors and 15% of patients at least once during task execution, whereas tasks were typically completed successfully after correction within the session. The IPS exchange was demonstrated with foreign partners in Connectathons, with successful participation documented through certificates issued by HL7 and Integrating the Healthcare Enterprise.
Conclusion
eHealth4U provides a legally grounded, citizen-centred and interoperable national EHR prototype for Cyprus, combining an implementable architecture with demonstrated cross-border interoperability and positive early usability outcomes, thereby supporting the establishment of the Cyprus Health Data Space.
Introduction
In this article, we introduce eHealth4U, 1 the first and only prototype of the national Electronic Health Record (EHR) system of Cyprus, in response to the provisions outlined in the national eHealth law. eHealth4U was designed and developed as an integrated, citizen-centred EHR to serve citizens’ healthcare needs by facilitating prevention, promoting well-being and supporting treatment at the national, European and international levels. Cyprus has taken only tentative strides towards digital governance across all sectors. This is evidenced by its low eGovernment maturity, as benchmarked biennially by the European Commission, averaging 53 points out of 100 in 2021 and 2022, placing Cyprus 32nd among 36 countries. 2
The healthcare sector mirrors this trend, 3 albeit with some efforts to establish a robust foundation for the national eHealth ecosystem. Notably, in 2019, the General Healthcare System of Cyprus (GHS) 4 commenced its implementation with universal coverage for the Cypriot population. 5 Concurrently, a Health Insurance System was developed for healthcare providers and beneficiaries 4 to address the financial aspects of healthcare service provision in GHS, primarily for reimbursement purposes. 6 However, Cyprus serves as an illustrative case in which the implementation of a national EHR system supporting the national eHealth ecosystem remains deficient. Progress in this domain necessitates addressing the six fundamental pillars crucial for securely facilitating the effective and efficient design of the ecosystem: (1) the catholic nature of the ecosystem, (2) mutual guarantee, (3) universal accessibility, (4) economic viability, (5) high service quality and (6) establishment of an eHealth authority. 7 In pursuit of these objectives, the national Cyprus Law 59 (I)/2019, also known as the national eHealth Law of Cyprus (henceforth referred to as the law), was enacted in 2019, mandating the establishment of a dedicated National eHealth Authority (NeHA). 8
Among its various responsibilities, NeHA is tasked with defining the operating framework and setting up the Single e-Health Records Bank (SeHRB). According to the law, the SeHRB forms the core of the Cypriot national eHealth ecosystem, serving as a repository for every citizen's EHR, created, maintained and stored at a national scale.
An inherent function of the SeHRB is to ensure interoperability between each citizen's EHR and other e-health systems on both national and cross-border fronts.
The pressing need to enhance interoperability across healthcare systems has been widely acknowledged by stakeholders worldwide. The shift from a traditional paper-based, doctor-centric healthcare service delivery model to a citizen-centred eHealth ecosystem that facilitates the advancement of personalised medicine relies heavily on achieving higher levels of interoperability. 9 This imperative is underscored in the European Health Data Space (EHDS), which outlines provisions to promote interoperability and strengthen individuals’ rights to data portability in the health sector, ensuring secure access to and control over their personal electronic health data. 10
To this end, EHDS advocates for the adoption of the European Electronic Health Record Exchange Format (EEHRxF) standards 11 and specifications by Member States (MS), leveraging the European Interoperability Framework (EIF) 12 and mandating MS to implement the MyHealth@EU platform. 13
The X-eHealth project acknowledged the need to leverage existing EU cross-border healthcare services to lay the foundation for a functional, interoperable and secure EEHRxF. 14 Launched in 2020, the X-eHealth project aimed to lay the groundwork for a standardised framework across the EU MS for medical imaging, discharge letters, laboratory results and rare diseases, 15 building upon the European Patient Summary (referred to herein as EPS) service as its cornerstone.
A year later, in 2021, the International Standard ISO 27269, titled ‘Health Informatics International Patient Summary’ (referred to herein as IPS), was published to primarily facilitate citizens’ receipt of unplanned care, while also supporting planned care across national borders. 16 The IPS initiative provides a reference standard defining the core dataset for a patient summary document that supports the continuity of care for an individual and the coordination of their healthcare internationally.
With the vision of developing a prototype for a national EHR system as the core component of the Cyprus Health Data Space (CHDS) and integral to shaping the European Health Union, eHealth4U was structured around three main design and implementation axes:
Define the structure and content of the Cyprus national EHR, serving as the cornerstone of the CHDS. Develop a reference implementation of the SeHRB aligned with the provisions outlined in the law. Create a user-friendly web portal that enables seamless access and efficient data management for both healthcare professionals and EHR holders.
By undertaking these goals, the eHealth4U project seeks to contribute significantly to the further advancement and success of the national eHealth ecosystem in Cyprus and actively engage in initiatives aimed at fostering interoperability. These endeavours extend far beyond the national landscape, with eHealth4U encompassing interoperability efforts at both the European and international levels.
This involves designing its interoperability framework based on the EIF governance model (Figure 1), 17 tailored to the specific requirements of a national EHR, and implementing interoperability with myHealth@EU services, including EPS and ePrescription.
Interoperability model as given by European Interoperability Framework (EIF).
Furthermore, as a strategic measure to strengthen the support for EEHRxF, eHealth4U was developed to ensure alignment with the X-eHealth Fast Healthcare Interoperability Resources (FHIR) implementation guides (IGs). Concurrently, to expand interoperability horizons internationally, eHealth4U was designed to conform to the IPS standard.
The primary objective of this article is to present the design and implementation methodology of eHealth4U, developed as the sole prototype that fulfils the requirements of Cyprus's national EHR prototype in accordance with the relevant provisions of the national eHealth law. These legal provisions were analysed and translated into a set of actionable requirements, guiding each phase of design and development to ensure the creation of a solid, lawful, citizen-centred and resilient foundation upon which the Cyprus-integrated national EHR system can be established and expanded to encompass the full range of healthcare services available to citizens. This methodology operates within a robust legal framework that integrates national eHealth regulations, the GDPR and other pertinent EU directives. Special emphasis is placed on three core dimensions of national eHealth law and the EHDS: interoperability across national, European and international levels; enhancement of citizens’ ownership and control over their health data; and stringent data protection and security.
The remainder of this article is structured as follows: The section Methodology details the approach adopted for analysing the national eHealth law and deriving a set of actionable requirements for implementing eHealth4U, which are also used as a reference guide throughout the article, linking each article with a particular feature of the system. The User Roles section defines the primary actors within eHealth4U and outlines their respective roles within the system. The Structure and Content of eHealth4U section presents an analysis of the EHR structure, including interoperability, data privacy and security considerations. The Technical Framework section provides an in-depth overview of the technical specifications and architecture that underpin eHealth4U's development. The Evaluation section describes the methodology and results based on feedback from healthcare providers and citizens. In the section Discussion, we explored the key dimensions and broader implications of eHealth4U's implementation. Finally, the Conclusions section presents insights into the status and future directions of the eHealth4U system within the broader context of the CHDS and the EHDS.
Methodology
eHealth4U was intentionally developed as a prototype implementation aligned with national eHealth law, methodically integrating and activating various associated provisions to establish its legal framework and promote legal interoperability at the national level.
The foundational components of the eHealth4U legal framework encompass both the national eHealth law and GDPR, 18 with the latter's regulations seamlessly integrated into the former. The fundamental aspects are outlined in Table 1.
Main axes of the legal framework regarding the eHealth4U implementation based on the national eHealth law of Cyprus. 8
Subsequent sections of this article, detailing various design and implementation aspects of eHealth4U, will link each action to the actionable requirements derived from the legal framework, with specific references to articles on national eHealth law.
The multifaceted components of the eHealth4U legal framework formed the foundation for the system's implementation methodology. In line with this, the initial phase of the process focused on identifying the user roles required for the system's functionality, as outlined in LF1 in Table 1. For the next step, the focus transitioned to defining the structure and content of the EHR aligned with the LF2 requirements. Concurrently, efforts have focused on formulating the interoperability framework for eHealth4U (derived from LF3) and ensuring alignment with cross-border healthcare services (LF4). This orchestrated alignment aimed to facilitate harmonisation in data exchange and collaborative synergy in the provision of healthcare services, both nationally and across borders. Ultimately, the technical implementation framework was developed based on the actionable requirements stemming from LF5, supporting the robustness and efficacy of the eHealth4U system.
User roles
In the eHealth4U system, two distinct categories of actors emerge: human actors and third-party systems. A short description of each user role built into eHealth4U is presented in Table 2. The principal human users consist of citizens who serve as EHR holders and healthcare providers (LF1, Article 18). Among healthcare providers, two essential roles are critical for the functionality of a prototype national EHR system: medical doctors and nurses.
Short description of each user role built in eHealth4U.
Conversely, third-party systems encompass systems and applications that utilise Application Programming Interfaces (APIs) to enable communication and data exchange with the national EHR of Cyprus.
For each user role within the eHealth4U system, a distinct registration process was implemented to capture the essential information required for the establishment and upkeep of the two foundational registries mandated by the NeHA for the functionality of the national EHR system: the register of EHR holders and the register of healthcare providers (LF1, Article 18).
Registration for EHR holders requires providing a unique citizen identifier, such as a national identity number, passport number or Alien Resident Card Number. Additionally, for the first two identifiers, the issuing country is solicited in accordance with the provisions delineated in the eHealth law. This allowance caters to individuals residing outside the borders of the Republic of Cyprus, including tourists, foreign diplomats and non-registered immigrants, thereby facilitating their inclusion in Cyprus's national EHR system.
For registration in the register of healthcare providers, medical doctors are obliged to provide their distinctive Cyprus Medical Register numbers, conferred by the Cyprus Medical Council. Similarly, nurses and midwives must supply the corresponding registration number issued by the Cyprus Nursing and Midwifery Council, which includes three nursing registers: general nursing, psychiatric nursing and the midwifery nursing register. Moreover, both medical doctors and nurses/midwives must provide their respective legal licence numbers granted by the Cyprus Medical Association and the Cyprus Nurses and Midwives Association, respectively. In instances where a medical doctor or nurse/midwife lacks legal authorisation, their licence is revoked by the corresponding association. Consequently, this identifier serves as a determinant of the system's authorisation status for healthcare practitioners, discerning those who are legally permitted to access and utilise the EHR system as active healthcare professionals. Accordingly, individuals without active legal practice licences have their access to citizens’ national EHR revoked, rendering them inactive.
Electronic health record structure and content
The ethos of the Cyprus eHealth law is governed by a citizen-centred philosophy that places paramount importance on advancing citizens’ health and well-being, aligning with the spirit of Hippocrates’ dictum: ‘Prevention is better than treatment’.
Prevention is intertwined with primary care and serves as a fundamental pillar of the healthcare landscape. Workshops involving the project's business analysts and medical experts from the primary care sector were organised to understand doctors’ perspectives on effectively and efficiently using an EHR system. Topics included everyday medical practices, challenges faced and the potential benefits of EHR use.
A key outcome of these workshops was that the EHR requirements gathered for primary care formed the basis of the national integrated EHR system. Therefore, prioritising primary care in the national EHR prototype lays the groundwork for future specialty integration, while effectively addressing a substantial portion of citizens’ healthcare needs in the interim.
The requirements collected from the medical team regarding general (internal) medicine, family medicine and paediatrics were used to design the EHR structure and to define the content of the EHR core dataset (LF2, Article 19). Several key insights were obtained through a thorough analysis of these requirements:
Identification of basic sections within the EHR. Collection of clinical requirements from doctors for each section. Identification of unique complex parameters used by doctors to describe various healthcare concepts. Analysis and conversion of complex parameters into a set of simplified parameters and their corresponding values.
A critical aspect of the requirements analysis process involves studying the workflow of doctors during patient visits, outlined as follows:
First phase: Reviewing the medical history of the patient: Utilising the EHR, doctors can access and review patient histories both before and during encounters, enhancing the quality of care and potentially reducing the encounter duration. Second phase: Recording current health data: Including presenting conditions, complaints, examination outcomes and evaluation results. Subsequently, doctors assessed all available patient information and proceeded to a differential diagnosis. Third phase: Planning actions for citizens’ health management: Including treatment prescriptions, referrals to specialists, lifestyle recommendations, goal settings and requests for further investigations.
Figure 2 illustrates the typical pathway a doctor follows during a visit to a citizen to enhance the citizen's health status. The information gained from the clinical examination process must be integrated with the patient's history. 19 As Dam et al. point out, a well-structured medical history forms the backbone of clinical reasoning, which can lead to prioritised differential diagnosis. 20 It is important to note that in 60% of cases, a complete, well-structured patient history can provide a diagnosis. 21 This fact underscores the need to design EHRs to be user-friendly for medical history editing and retrieval. In addition, a well-targeted clinical examination can double the diagnostic value of a patient's history. 21 Recording the patient's medical history and clinical examination comprises the cornerstone of safe and effective clinical practice.
Three main phases describing the doctor's workflow during a patient visit.
In eHealth4U, we integrate these two medical aspects into the first part of the EHR system, which houses all the information needed for citizens’ medical history. The second part contains the physical findings and signs, and currently only records vital signs and somatometric measurements. Consequently, EHR is separated into three main sections: (A) Medical History, (B) Clinical Examination and (C) Laboratory and Imaging Results. There is also a section dedicated to visits’ history, including information such as the potential and differential diagnosis recorded during each visit, along with therapeutic recommendations.
The content of the EHR mirrors the outcome of medical examinations conducted and utilised by healthcare providers. Assessing citizens’ health status in their biological, social and environmental contexts is essential in primary care. In clinical practice, the doctor initially interviews the patient using guided questions to elicit comprehensive information about different aspects of citizens’ health status. This information is then organised and reported in the medical history section, which provides an extensive collection of information for doctors to make differential diagnoses.
A comprehensive medical history comprises structured diagnostic information drawn from the patient's personal health history, categorised and sub-categorised to facilitate the analysis. The EHR content hierarchy, as depicted in Figure 3, breaks down into primary categories and is further analysed into sub-categories. Each sub-category comprises complex parameters that, when analysed, offer a nuanced understanding of citizens’ health status. These parameters serve as the foundational elements of eHealth4U and provide multidimensional insights into citizens’ health. As fundamental elements, complex parameters within the eHealth4U interconnect to capture various dimensions of a citizen's health. Consequently, the requirements for each complex parameter were established, following a comprehensive review of all pertinent use cases.
An example of a citizen’s national electronic health record (EHR) structure and content as implemented in eHealth4U.
The eHealth4U prototype of the SeHRB was constructed based on these complex parameters, which define different sub-sections and, consequently, the primary sections of the national EHR. The eHealth4U medical experts reviewed each complex parameter individually and determined the desired value format. In this context, SeHRB was designed to accommodate a diverse array of health data types, encompassing structured data formats that use coding systems and classifications in the healthcare sector, as well as options for free-text input and PDF reports (LF3, Article 29).
This iterative process was extended to all data blocks recorded for the requirements of all EHR sections. Therefore, using eHealth4U, each citizen has a unique national EHR containing comprehensive information relevant to their care and medical history, with limited information on clinical examinations, laboratory results and imaging results (LF2, Article 30).
This structure is illustrated in Figure 4, where the section Alerts has also been added to highlight critical citizens’ health information, including Allergies, Major Medical Problem, Procedures, Drug use and Tobacco use. Arithmetic measurement values under the sub-sections of Clinical Examination are presented either as a table or a chart, depending on the doctor's preference (Figure 5).
The initial screen displayed when a doctor access a patient's electronic health record (EHR).
The vital signs sub-section under the clinical examination.
Another requirement stipulated that all health data entered into a citizen's EHR must be contextualised within a visit. Consequently, every bit of health data in the EHR is associated with a specific visit, and based on this, a visit summary is automatically generated upon the conclusion of each visit. This summary encompasses all new health data recorded during the visit. It includes information such as visit initiation and completion date and time, attending healthcare providers, visit location and, if applicable, the admission cause, presenting conditions, diagnosis, differential diagnosis, therapeutic recommendations and course of disease (Figure 6).
Section of a visit summary.
In addition to visit-related information, the concept of Episode of Care (EoC) was introduced to describe a citizen's path during their healthcare journey. This framework enables doctors to aggregate all visits and related health data pertinent to a specific medical case for citizens. Every visit is nested within an EoC, which can be either an existing active EoC or a newly created one, depending on the medical context of the visit. Doctors have the flexibility to organise visits to EoC for a specific citizen in a manner that aligns with their medical practice preferences and optimises patient care. Figure 7 depicts an EoC for a patient with an intestinal infection, including three visits.
An example from episodes of care record.
Interoperability
Interoperability is a vital pillar within citizen-centred ICT systems, facilitating continuous data portability, transferability and communication. Within eHealth4U, emphasis has been placed on establishing a robust interoperability framework that empowers the system's users, whether healthcare providers or citizens, to access optimal healthcare services, irrespective of their geographic location within the Republic of Cyprus or across the EU (LF3, Article 19).
The foundation of this framework is based on the layers of the EIF interoperability model (Figure 1). This strategic alignment ensures coherence and compatibility with established interoperability standards, laying solid groundwork for effective data exchange and collaboration within the eHealth4U ecosystem.
Legal interoperability
Legal interoperability is upheld at the national level, as explained in the previous section, because eHealth4U serves as the reference implementation of the national EHR system and adheres to all stipulations outlined in the national eHealth law.
Technical interoperability
Fast Healthcare Interoperability Resources of Health Level Seven (HL7 FHIR) R4 22 is the cornerstone of the eHealth4U interoperability framework, which strategically addresses the complex challenges of technical interoperability by offering standardisation, granularity and simplicity in application. To construct interoperability for eHealth4U, we set forth two primary objectives: (1) to facilitate seamless data transferability in both national and cross-border healthcare contexts and (2) to ensure the interoperability of eHealth systems through the implementation of acceptable integration profiles adhering to relevant European Union legislation and standards (LF3, Article 30). To realise these objectives, we embarked on developing FHIR profiles and extensions tailored to accommodate the specific custom requirements of eHealth4U.
Based on the requirements analysis, the FHIR profiles and FHIR Terminology of eHealth4U were implemented using a structured methodology following four distinct steps:
Step 1: Creation of the SeHRB prototype base
Mandated by national eHealth law, the SeHRB prototype is designed to facilitate data transfer and ensure interoperability of eHealth systems both nationally and across borders. This imperative aligns closely with EU directives, particularly Directive 2011/24/EU, 23 which aims to enhance access to high-quality health care services across European borders.
Facilitating cross-border data exchange within the EU, the eHealth Network (eHN) issues guidelines for EPS. 24 These guidelines are instrumental in standardising the electronic exchange of health data and fostering interoperability among the MS. Additionally, the ‘ISO 27269:2021: Health Informatics-International Patient Summary’ standardises the Patient Summary dataset provided by the eHN, ensuring implementation independence and compatibility with diverse terminologies. 16
In adherence to the ISO 27269:2021 guidelines and the terminology defined by the eHN in PS guidelines release 3, the SeHRB prototype, as part of eHealth4U, ensures conformity with established standards for the electronic exchange of health data. By leveraging the eHN guidelines for the EPS in conjunction with the related value sets for eHealth4U terminology, interoperability with eHealth systems operating in the EU cross-border healthcare services sector can be achieved (LF4, Article 17).
This approach not only facilitates continuous integration with EU cross-border healthcare systems but also endeavours to expand opportunities for global interoperability with eHealth systems, thereby enhancing data transferability regardless of individuals’ hardware, software or national language preferences (LF3, Articles 29–30).
To ensure compliance with the IPS, entities within eHealth4U that correspond to the IPS specification were identified. For each entity, a logical model was constructed to align with the IPS requirements and the custom requirements of eHealth4U. To ensure consistency throughout this process, a set of guiding rules was established and applied to each patient summary section/entity within the eHealth4U logical model. The details of these rules are listed in Table 3.
International Patient Summary (IPS) conformance rules for building eHealth4U FHIR profiles.
Step 2: Expansion of the eHealth4U base to accommodate all requirements
In this framework, the requirements gathered from meetings and workshops conducted by the eHealth4U medical team are analysed. In this systematic process, data from the eHealth4U base dataset were excluded. For the remaining requirements, the rules outlined in Table 4 are applied to each data element, thereby formalising the expanded eHealth4U dataset. The output of this process describes all entities implicated in the eHealth4U workflow as per the requirements analysis. It is noteworthy that while using Table 4, there exist two methodologies for incorporating a data element into a profile: a) utilising an element from the core FHIR resource to represent the additional data element, and b) employing an extension to represent the added data element (either utilising an existing extension or developing a new one).
eHealth4U expanded data set rules.
Step 3: Creation of eHealth4U profiles
A national integrated EHR system requires a design that can adapt to evolving requirements while accounting for scalability and extensibility. As eHealth4U accrues knowledge and experience over its lifespan, the maturity level of its profiles is expected to increase. Consequently, the profiling process for SeHRB is envisioned to be iterative and enduring. For every emerging requirement (following the rules outlined in Table 4), the following strategic approach is employed:
Thoroughly review the documentation of the corresponding FHIR core resource. Examine all linked documentation webpages comprehensively. Conduct targeted searches within the FHIR community:
Relevant keywords were used to identify parameters requiring profiling, leveraging discussions among other implementers to inform decisions. Explore platforms such as Simplifier
25
or other IGs
26
to evaluate existing implementations. Employ the name of the corresponding FHIR core resource as a keyword. If the parameter belongs to a broader category (e.g., vital signs), the family name of the parameter is used as a keyword. Document any emerging profiling guidelines during the pre-profiling phase for inclusion in the eHealth4U profiling guidelines to foster knowledge sharing.
By executing these steps, the interoperability level of eHealth4U profiles is enhanced, drawing upon shared experiences and knowledge from national and international implementations within the FHIR community.
The primary authoring tool for constructing FHIR profiles was the Forge provided by fire.ly. 27 Following their creation, the profiles were validated through two methods: (a) Validation against the FHIR R4 core IG to ensure compliance with base resource constraints and conformance rules. For this type of validation, the JAVA FHIR Validator package was used via command line (b) validation of real data instances/examples against the instantiated profile to verify the proper representation of eHealth4U data. This validation process was conducted using the Simplifier platform, 28 which involved entering the JSON representation of a profile instance and validating it against the corresponding profile.
Step 4: Development of eHealth4U FHIR profiles
The FHIR profiles yield JSON-formatted definitions primarily comprising structure definitions, value sets and coding systems. These profiles are uploaded to the FHIR Server using a dedicated internal tool known as ‘EHealth4U.iguploader’. This utility, integral to the eHealth4U project, simplifies uploading conformance resources to the FHIR server, ensuring efficiency and accuracy in managing FHIR resources. To facilitate the implementation of the EHR Backend, eHealth4U.Fhir.Lib was utilised. This comprehensive repository plays a vital role in the efficient management of FHIR resources within the EHR Backend by offering functions for reading, updating, searching and creating bulk FHIR resources. Furthermore, it facilitates transforming the FHIR objects retrieved from the FHIR server into Data Transfer Objects (DTOs), which are essential for communication with the frontend and other necessary services. During the mapping process facilitated by eHealth4U.Fhir.Lib, each value in the DTOs is translated into an FHIR object using the appropriate Uniform Resource Identifier (URI) for that value. The resulting FHIR resources are defined in JSON and posted to the FHIR server. The integration of a schema validator into the FHIR server ensures that each value in the generated FHIR resource conforms to the specified value sets outlined in the profiles, particularly Structure Definitions. In cases where errors, such as invalid values, are detected in the data definitions, the Validator rejects the resource and returns an error to the client. This highlights the non-conformant fields that deviate from the Structure Definitions and Value Sets, ensuring the integrity and reliability of the EHR system.
Semantic interoperability
Sharing data meaningfully is the aspiration of an interoperable system. This necessitates a mutual understanding of the exchanged data between the sender and the receiver. Central to this goal is the implementation of a semantic interoperability layer, which revolves around terminology usage. Terminology serves as a contextual framework for interpreting data representations, thus establishing a shared understanding of data communication across diverse systems.
Following the logical modelling of each eHealth4U data entity, structured data elements were identified and associated with specific sets of codes known as value sets.
Implementation of the EPS within the eHealth4U data infrastructure required adopting its semantic representation, including the Master Value Catalogue (MVC) value sets published by the eHealth Digital Service Infrastructure (eHDSI) initiative.
To incorporate MVC value sets, two approaches were prioritised within eHealth4U:
Direct usage is the primary bound value set for coded data elements within the EPS dataset. Utilisation of mappings between eHealth4U value sets and corresponding MVC value sets, employing FHIR ConceptMaps, when constraints within FHIR core resources prohibited direct binding (e.g., the data element ‘gender’ of the core FHIR resource ‘Patient’ defines the binding strength of the corresponding value set as ‘required’, which does not allow the binding of any other value set).
Despite the official publication of MVC value sets on the art décor platform 29 by the eHDSI community, direct downloading in the FHIR format was unavailable. To address this, a script was developed to retrieve MVC value sets in the FHIR JSON representation using FHIR URIs. These representations were subsequently edited in accordance with the eHealth4U profiling guidelines to ensure consistency and quality, with disclaimers added regarding their source and retrieval methods.
By adhering to the IPS guidelines and leveraging MVC value sets, eHealth4U established a solid foundation as the core of the national SeHRB. This conformity extends eHealth4U's interoperability capabilities at both the European and international levels.
In addition to the eHDSI MVC value sets, the eHealth4U Terminology was expanded to include custom value sets explicitly designed for the eHealth4U project. These custom value sets were created to align with the project's unique needs and characteristics, ensuring that the data and terminology used were appropriately defined and consistent with the project's workflows and use cases (LF3, Article 29).
Furthermore, as part of the HAPI FHIR server implementation for eHealth4U, 30 a built-in terminology server was incorporated, and the terminologies presented in Table 5 are loaded to support project operations.
eHealth4U terminology server content.
Organisational interoperability
In pursuit of organisational interoperability, eHealth4U leveraged the collaboration platform Simplifier to register its FHIR resources, including structure definitions, value sets, concept maps and examples. This platform serves as a real-time communication node for all stakeholders involved in the design and implementation of the eHealth4U project, enabling online updates, change-tracking and version management for each profile.
As the first initiative of its kind implemented on a national scale, eHealth4U integrates EHR-related provisions of the national eHealth law with requirements derived from the EPS and IPS specifications. Stakeholders of the Cyprus national eHealth ecosystem who are interested in or even affected by the application of the national eHealth law can review the project's implementation via Simplifier, fostering collaboration and alignment with future organisational plans.
To support knowledge sharing about the system's functionalities for both patient and doctor users, an online wiki was created to provide comprehensive documentation and general information about the project.
In addition, pharmaceutical integration was added as new system functionality, allowing the loading of medications from the official Cyprus Pharmaceuticals Database.
Bilateral workshops have been conducted to elucidate the eHealth4U interoperability schema and its alignment with national eHealth law, thereby facilitating collaborative efforts with organisations such as the State Health Services Organisation, Hippocrateon Private Hospital, the Cyprus Institute of Neurology and Genetics and the German Medical Institute and biobank.cy.
The collaborative endeavour between eHealth4U and biobank.cy holds notable significance, as it assessed the interoperability between the national HER prototype and a population-based biobank infrastructure developed within the EU-funded project ‘CY-Biobank’. 31 This partnership provides a distinctive opportunity to investigate the integration prospects between the national EHR and external systems, capitalising on the eHealth4U robust interoperability framework.
Data privacy and security
In the digital medicine era, citizens’ health data hold profound significance, transcending mere information to encompass their health narrative, journey and enduring legacy. Dr Eric Topol's advocacy emphasises the role of citizens as the central hub in this evolving healthcare landscape. 32 Consequently, citizens must embrace ownership, control and guardianship of their health data, recognising it as a vital asset for their well-being and as capable of shaping their health trajectory. Empowering citizens through health data ownership and governance necessitates establishing an eHealth ecosystem rooted in core principles such as privacy, security, confidentiality, accountability, transparency and data integrity, all of which are enshrined within the national eHealth law of Cyprus.
Within the eHealth4U framework, strict adherence to the legal framework ensures the implementation of provisions related to citizen empowerment through a prototype of the national EHR. This initiative aims to cultivate a healthcare environment in which citizens are not merely passive recipients but empowered stewards of their health data.
The priority of our implementation was to provide citizens with an accessible opt-out process for being registered as national EHR holders (LF1, Article 20). This opt-out mechanism empowers citizens to decline participation after receiving comprehensive information about potential health consequences, thereby safeguarding their autonomy and privacy rights.
Active EHR holders can afford unrestricted access to their health data from any location and at any time (LF1, Article 25, LF5 Article 23). To ensure accessibility, eHealth4U has implemented robust authentication and authorisation mechanisms in line with data protection and security standards (LF1, Article 22, LF5, Article 33). Each EHR holder is assigned unique access codes that are distinct from those used by other authorised individuals within the national EHR system (LF5, Article 23). A dedicated portal has been established, enabling citizens to log in using their unique access codes to view their EHR data and manage consent.
Moreover, EHR holders have sole control over how healthcare providers can access their EHR. Providers can access a citizen's EHR under two specific conditions: (1) the EHR holder must authorise them, and (2) their identity, role and access code must be confirmed. In eHealth4U, citizens explicitly grant authorisation through the provided EHR portal, select healthcare providers and provide access authorisation consent (LF1, 24–25, LF5, 23,25). Several considerations regarding access authorisation consent were addressed during implementation, including the duration of consent, the scope of accessed health data and the management of the doctor's medical team.
Regarding the duration of consent, eHealth4U balances health data control with practicality. The consent's lifetime duration depends on updates to a specific EoC, initially set for a defined period (e.g., three months) after its creation. With each new visit under a certain EoC, the consent duration was renewed, ensuring healthcare continuity. Consent automatically expires after a predefined period following the date of the last recorded visit to the EHR under a specific EoC, provided that no other EoCs are active with the same doctor as their creator (LF1 Article 22, LF5 Article 33). Citizens also have the option to manually revoke consent, immediately revoking the doctor's access rights via the consent management wizard available in the citizens’ EHR eHealth4U portal (Figure 8).
The consent management component.
Regarding the scope of accessed health data, eHealth4U enables citizens to lock specific health data, thereby restricting access by authorised healthcare providers (LF1, Article 24). Citizens have the autonomy to conceal their chosen health data. However, eHealth4U notifies authorised healthcare providers that specific data within a particular citizen's EHR is locked without revealing its content (LF5, Article 24).
The final aspect of access authorisation consent pertains to managing the access rights of the authorised doctor's medical team. Doctors often collaborate with other healthcare professionals, such as nurses and medical secretaries. Upon authorisation to access a citizen's EHR for healthcare service provision, the entire medical team may require access to the EHR to coordinate care effectively. To facilitate this, eHealth4U has developed a dedicated feature in the doctors’ EHR portal that allows doctors to configure their medical teams. This feature enables doctors to designate members of their medical teams, who will then be granted access to every citizen's EHR, authorising the doctor (via access authorisation consent). Consequently, when the lead doctor is authorised to access a citizen's EHR, all designated team members are automatically granted access, with permissions tailored to their respective roles (e.g., doctors and nurses have different access and editing permissions than medical secretaries).
Finally, two additional data privacy and security measures merit discussion within the context of the eHealth4U implementation. The first measure focuses on ensuring data integrity, requiring that once health data are entered into a citizen's EHR, they become immutable (LF1, Article 25, LF5 Article 33). Any updates or findings regarding existing health information in the EHR must be recorded as new health data within a new visit. The second measure involves maintaining an audit log, which records all instances of EHR access by users, serving accountability and auditing purposes (LF5, Articles 29 and 32–33).
eHealth4U technical framework
eHealth4U leverages cutting-edge technologies, including cloud-based infrastructure bolstered by a microservices software architecture and Kubernetes, to develop a cloud software-as-a-service platform.
The need for a highly stable, scalable, observable and recoverable infrastructure has led us to investigate and invest in building the reference implementation of a cloud-based Kubernetes installation hosted by the national telecommunications provider, Cyprus Telecommunications Authority (CYTA) (LF5, Article 30).
A high-level representation of the eHealth4U software infrastructure architecture is shown in Figure 9. The eHealth4U infrastructure comprises four layers, as outlined in Table 6.
Technical architecture of eHealth4U.
eHealth4U architecture levels.
The backend consists of several components, the most significant of which are the eHealth4U FHIR Library, the API Controller and the eHealth4U engine. These components were built in a modular way to allow the segregation of concerns, which helps with rapid application development and the ability to unit-test each function separately in the backend. Furthermore, DTOs were developed, which are a simplified representation of the data used for direct integration with the frontend, allowing the frontend development team to focus on the User Interface (UI) implementation rather than on the technical specifications surrounding the FHIR standard. The programming language of choice is C# from Microsoft, as it is widely adopted and the world's largest company develops and backs the technology. In recent years, the language has evolved into a cross-platform language, allowing us to compile binaries on Linux and build code with friendly tooling on Microsoft Windows.
The eHealth4U backend also utilises a well-known database management system, PostgreSQL, an advanced open-source Relational Database Management System, renowned for its robustness, scalability and adherence to SQL standards. PostgreSQL supports complex queries, ACID compliance and full-text search, making it an ideal choice for managing diverse, extensive health data on the eHealth4U platform.
With the ability to build and deploy the solution using containerisation technology such as Docker, we consistently built the backend. We later utilised the same container images for deployment in our cloud-hosted Kubernetes cluster.
eHealth4U frontend development uses the React Frontend Development Framework to build a web-based portal for patients and doctors, adhering to User Experience (UX) design principles of clarity, consistency, efficiency, flexibility, hierarchical structure, data visualisation, feedback and confirmation. The TypeScript language was used as the programming language of choice to enable type checking and enhance the reliability of front-end development with React. Furthermore, in the ‘New Visit’ section, the system was enhanced to create and store new data in a patient's EHR. The ‘redux’ library is utilised to ensure secure and correct data storage in the React application. Owing to the complexity of the data involved in creating a new visit, the decision was made to use Redux State to temporarily manage the data on the frontend until its finalisation and storage on the FHIR Server. This offers the user the best experience in terms of stability, security and speed. Notably, new health data added to a patient's EHR are always created during a new visit and are stored in the FHIR server only when the visit is closed and saved by the doctor who initiated it (LF5, Articles 29, 33). Finally, various libraries sourced from the Node Package Manager are used to apply styling and design principles.
Design patterns
Repository pattern
The Repository Pattern is implemented in the eHealth4U EHR Backend to create an abstraction layer between the data access layer and the business logic of the RESTful APIs and the storage of data. This pattern enhances maintainability, flexibility and testability by isolating the data-access logic in a dedicated component. It provides a standard interface for data operations, making it easier to manage data access and modify underlying data stores without affecting business logic. This pattern also facilitates unit testing by enabling mock repositories, ensuring that business logic can be tested independently of the data access layer. eHealth4U implemented over 400 test cases, greatly facilitated by the repository pattern.
In the context of eHealth4U, the Repository Pattern is particularly beneficial for managing interactions with PostgreSQL databases and the HAPI FHIR server. By encapsulating data access within the repositories, the system can ensure data consistency and integrity. This approach also supports the use of complex queries and transactions to improve the efficiency and reliability of data-management processes.
Dependency injection
Dependency Injection (DI) is crucial for developing loosely coupled systems. In the eHealth4U system, DI is used to manage dependencies between components, ensuring that changes in one part of the system do not necessitate changes in others through standardised interfaces. This approach enhances modularity and maintainability by allowing the components to be easily replaced or updated.
In eHealth4U, DI is used to manage services, repositories and other components, thus promoting a clear separation of concerns. This allows efficient and accurate unit testing by enabling the substitution of real components with mock objects. For example, during testing, a mock database context can be injected into the repository, allowing business logic to be tested without relying on the actual database. This approach improves test coverage and reliability, ensuring the system behaves as expected across different scenarios.
Security infrastructure
To ensure secure handling, storage and sharing of health information while complying with data protection regulations and safeguarding patient privacy, eHealth4U implements security measures based on GDPR and national eHealth law requirements involving:
The exploitation of authentication and authorisation open standards, such as the OAuth2 protocol described in RFC-5849 and the JSON Web Tokens provided in RFC 7519 (LF5, Article 33). Utilisation of identity and access management (IAM) solutions (i.e., Keycloak) to gain authentication, authorisation and user management capabilities in a centralised and scalable manner. A Keycloak Identity Provider is built for user authentication and authorisation, ensuring that only authorised users can access and modify patient records (LF5, Articles 25, 33). The construction of consent management mechanisms allows for the creation, revocation and preview of consent information (LF5, Articles 24, 25). The creation of logs for auditing all actions that take place on the platform, in combination with a notification system to inform about essential actions, the patients and healthcare professionals, where appropriate (LF5, Articles 25, 29, 32, 33).
Log and security monitoring services
The eHealth4U platform implements log monitoring to maintain the security, performance and reliability of its system. The system has implemented cloud-native monitoring solutions to monitor its components, including operating system logs, Kubernetes logs and server logs (LF5, Articles 25, 29, 32, and 33). Integration with Prometheus and Grafana enables centralised, comprehensive monitoring, providing real-time visibility into system performance and health. Grafana dashboards display key metrics and logs, allowing the team to quickly identify and address issues that alert system operators to unexpected events or resource pressure, such as disk space depletion. The use of a Kafka bus for log processing enables scalable, efficient log management, supporting the high volume of log data generated by the system.
Logs are essential for detecting and responding to security incidents. They provide a detailed record of system activities, including user actions, system events and errors. This information helps to identify the root cause of issues and detect potential security breaches. The eHealth4U platform uses a variety of log sources, including application, database and system logs, to provide a comprehensive view of system activities.
Encryption of data
Data in transit
Transit data are encrypted using secure protocols to prevent interception and unauthorised access during transmission. This includes data exchanged between clients and servers as well as between different components of the eHealth4U system (LF5, Article 33).
Transport Layer Security (TLS) is implemented to ensure secure communication channels, protecting data in transit from interception and tampering. A minimum version of TLS 1.2 is enforced, thereby disabling insecure protocols and cipher suites. The TLS is a widely adopted encryption protocol that provides confidentiality, integrity and authenticity of data exchanged over networks. In the eHealth4U system, TLS is used to secure communication between clients and servers, as well as among different system components. This prevents unauthorised access and ensures that sensitive health information remains confidential during transmission both internally and externally.
Data at rest
For data at rest, robust encryption mechanisms are applied to protect the stored data from unauthorised access and breaches. This includes encrypting file systems and backups by using strong encryption algorithms (LF5, Article 33).
Infrastructure access
To achieve security monitoring in the system, collaboration with CYTA was established to handle security responsibilities. The project implemented a VPN connection with FortiClient to secure system access. Operating System (OS) security and hardening measures, including regular patching, secure configurations, access control, monitoring and incident response planning, further enhance the system security (LF5, Articles 29, 33). Docker Scout is utilised to scan for insecure libraries and components, providing security reports and mitigation actions (LF5, Articles 29, 33).
High availability
The eHealth4U system leverages a highly available and fault-tolerant Kubernetes cluster to manage containerised applications and services. The eHealth4U cluster is deployed on virtualised servers using a bare-metal methodology, ensuring cloud-agnosticism and scalability.
Key features of Kubernetes deployment include horizontal scaling, automatic load balancing, self-healing and name-spaced service segregation. Horizontal scaling allows the system to add or remove nodes as demand varies, ensuring resources are available to handle varying workloads (LF5, Article 29). Automatic load balancing distributes incoming traffic across multiple instances of services, prevents overload and ensures optimal performance.
Self-healing capabilities enable Kubernetes to automatically detect and replace failed containers, ensuring that the system remains operational even in the event of failure. Namespaced service segregation enhances security by isolating different services and environments within the cluster, preventing unauthorised access and reducing the risk of security breaches.
The eHealth4U platform employs a persistent storage cluster solution called Rook-Ceph, which is renowned for its high-throughput data transfer and robust data replication capabilities. Ceph ensures that the data remains intact and accessible even if individual nodes fail, thereby providing a highly reliable storage solution. The system's redundancy mechanisms involve maintaining at least three live copies of each piece of data. This replication strategy offers significant protection against data loss, ensuring data can be recovered quickly and efficiently in the event of a failure. By leveraging Rook-Ceph, the eHealth4U platform guarantees data availability and reliability, which are crucial for maintaining the integrity of sensitive healthcare information.
Backup
Regular backup procedures were implemented to ensure data integrity and availability. These procedures involve creating periodic backups for the entire system, including databases, configuration files and application data. Backups are stored in secure, geographically distributed locations to protect against data loss owing to hardware failures, natural disasters or other catastrophic events (LF5, Articles 30, 33).
The eHealth4U platform employs incremental and differential backup strategies to optimise storage usage and reduce backup time. Incremental backups capture only the changes made since the last full backup, whereas differential backups capture only the changes made since the previous full backup. This approach minimises the amount of data that must be backed up and reduces the time required to perform backups.
Disaster recovery
A comprehensive disaster recovery plan is in place to ensure business continuity and rapid recovery from catastrophic events (LF5; Article 29). This plan includes detailed procedures for restoring systems and data, prioritising critical services and minimising downtime. The disaster recovery plan was regularly tested and updated to ensure its effectiveness and alignment with the evolving needs of the eHealth4U platform.
The key components of the disaster recovery plan include data replication, failure mechanisms and emergency response procedures. Data replication ensures that copies of critical data are maintained in multiple locations, providing redundancy and enabling rapid recovery in the event of data loss. Failover mechanisms, such as load balancers and backup servers, ensure that services can be quickly redirected to alternative resources in the event of a failure.
Emergency response procedures outline the steps to be taken in the event of a disaster, including communication protocols, roles, responsibilities and recovery timelines. These procedures are designed to ensure a coordinated and efficient response, thereby minimising the impact of disruptions on system operations and user access.
User experience and design
The eHealth4U platform adheres to the UX design principles that emphasise ease of use and accessibility. The key aspects of UX design include intuitive navigation, responsive layouts and clear visual hierarchies. Intuitive navigation ensures that users can easily access the information and features that they need. Responsive layouts adapt to different devices and screen sizes, providing a consistent, user-friendly experience.
Clear visual hierarchies help users understand the relationships among elements and prioritise important information. Data visualisation techniques such as charts and graphs are used to present complex data in an easily digestible format. Feedback mechanisms, such as notifications, provide users with real-time updates on their actions and the system status.
Dedicated UX sprints were conducted throughout the development lifecycle, with close collaboration between business analysts and UX designers to deliver the final UI screens for implementation in Figma. These sprints focus on gathering user feedback, testing prototypes and refining designs to ensure the platform meets users’ needs and expectations.
The UX of the implemented eHealth4U interface was tested and evaluated with primary users using task-based scenarios and structured questionnaires. The detailed findings from this usability evaluation, including the main challenges identified and planned design improvements, are presented in the subsequent evaluation section.
Figures 4 to 8 present some of the basic functionality of the eHealth4U system and illustrate core screens that are discussed in the section ‘EHR Structure and Content’.
Building on this, Figures 10 to 16 provide additional screenshots depicting the main workflow from the doctor's perspective (from sign-in to viewing a patient's record, clinical examination and visit documentation) and selected basic functions from the patient's perspective, including the configuration of full and partial consent and the patient's own view of the EHR.
eHealth4U clinician home screen after sign-in. Initial screen shown to the doctor after logging into the system, including access to authorised patients and navigation to core clinical functions.
Doctor’s view of the patient’s electronic health record (EHR). Initial view of a selected patient’s record, showing the main sections of the longitudinal electronic health record (EHR) and navigation to episodes of care, visits and clinical information.
Doctor’s view of the clinical examination section. Screen displaying structured clinical examination data for the selected patient, illustrating how findings are organised within the electronic health record (EHR).
Creating a new visit in eHealth4U. Interface for opening a new visit either within an existing episode of care or as part of a new episode, showing the options available to the doctor.
Adding structured data during a visit. Example of the data-entry view used by doctors to record clinical information as part of a visit, including problems, measurements and other structured fields.
Patient consent options for full or partial access. Patient-facing screen showing how a patient can grant full or partial access to a doctor for viewing the national electronic health record (EHR), including the configuration of consent options.
Patient’s view of the eHealth4U electronic health record (EHR). Overview of how patients see their own health data in the eHealth4U portal, including access to episodes of care, visits and key clinical information.
eHealth4U evaluation
The evaluation process for the eHealth4U system is an endeavour to assess its core functionalities, usability and alignment with user expectations. A systematic approach adopted to comprehensively evaluate the eHealth4U EHR system is outlined.
Primary users' evaluation
The first step of the eHealth4U evaluation strategy was to map out the user journey for two core eHealth4U user groups, medical doctors and patients and translate this journey into concrete interaction phases and tasks. For each group, the typical sequence of actions in routine use was decomposed into discrete steps, and specific test scenarios were designed to guide evaluators through the main functions of the system, such as data entry during an encounter, consent management, review of longitudinal health information and navigation between sections of the EHR. The overarching goal was to ensure that the primary users’ evaluations captured the system's full capabilities, which are relevant to everyday clinical work and citizen access.
To facilitate the evaluation process, evaluation scenarios were created using Google Docs. After completing these scenarios, the evaluators provided feedback using a structured questionnaire based on the DIPSA evaluation framework. 33 This validated framework encompasses evaluation categories, such as satisfaction, collaboration, safety, system quality and procedures. Prior research and consultations with medical doctors informed the questionnaire used in this study. It was tailored to reflect their perceptions and expectations regarding an EHR implemented as a national platform. Respondents used a five-point Likert scale to express agreement or disagreement on a scale from ‘Strongly Disagree’ to ‘Strongly Agree’, with opportunities for free-text responses to elaborate on their views.
Ethical approval for the eHealth4U project was obtained from the National Bioethics Committee of Cyprus. The primary user evaluation focused on the usability and perceived usefulness of the eHealth4U interface and did not involve the processing of identifiable records or accounts. All task scenarios for doctors and patients were executed using synthetic data and fictional test accounts created by the project team, which included mythical patients and doctors. Participants logged into the system with these test credentials and were asked only to view and enter information from the fictional records described in the scenarios. At no point were participants asked to access their own records or to enter their personal clinical data into the prototype system. The participation of doctors and patients in the usability tests and questionnaires was voluntary and anonymised, and responses were collected and analysed in aggregate form without linking results to named individuals. Therefore, no written consent forms were collected, as the evaluation was conducted as minimal-risk usability testing on synthetic data under this project-level approval.
The evaluation process involved two distinct cohorts: 30 medical doctors and 57 patients. Each cohort was tasked with specific interactions using the eHealth4U system. Evaluators gave feedback using the questionnaire, which assessed various dimensions, including the following:
Task Success: Evaluating the system's effectiveness in achieving specific tasks. Ease of Use: Assessing the system's user-friendliness. Safety: Ensuring patient data security and privacy. Overall Satisfaction: Capturing evaluators’ overall impression of the system.
Additionally, Key Performance Indicators related to usability, system performance and efficiency were systematically measured.
The evaluation yielded significant insights into the eHealth4U system's performance, which are presented in Table 7 and Figure 17.
Summary of usability and performance evaluation metrics for eHealth4U.
Key results of eHealth4U evaluation.
Overall, the quantitative questionnaire results are in line with the aggregated indicators reported in Table 7. Doctors reported high perceived usefulness and impact of eHealth4U on the quality of their work and the quality of information stored and expressed overall satisfaction with the system as a prototype of the national EHR, while recognising that the platform can help reduce medical errors and improve patient health. Similarly, patients rated the system as helpful in understanding their health status, navigating their history and laboratory results and supporting a good doctor–patient relationship. They expressed high satisfaction with eHealth4U as a citizen-facing portal.
Simultaneously, both groups identified specific weaknesses. From task-based observations, approximately 10% of doctors and 15% of patients committed at least one error during task execution, while task success was defined as eventual completion within the session; therefore, errors could occur and be corrected without lowering task success. These errors can be grouped into three categories based on observations of the combined task and user feedback. First, a substantial proportion of errors reflect UI and workflow design issues, such as difficulty locating specific items in long, alphabetically ordered lists, uncertainty about the meaning of particular headings and labels (such as the use of ‘admission’ where doctors expected ‘visit’) and the need to navigate between several sections to reconstruct a complete view of the patient. These design characteristics increase the cognitive and time burdens on users, making navigation and data entry more error prone. Second, a smaller subset of errors was technical in nature, including temporary problems when saving or updating a visit or interacting with specific functions, which users experienced as instability in critical actions. Subsequently, these issues were isolated and addressed through targeted testing and fixation. Third, several errors can reasonably be interpreted as human and learning-curve related in the sense that unfamiliarity with a new system and limited exposure to the scenarios led some participants to choose a less appropriate option when several similar values were presented, even though the required functionality was present and behaved as designed. In this sense, the reported error rates do not point to fundamental flaws in the clinical content or architectural approach, but rather to the interaction between the current interface design, residual technical defects and the early stage of user adaptation.
Based on this analysis, the following design iterations of eHealth4U will prioritise reducing navigation and data-entry errors by restructuring menus and lists and improving how structured values are presented to users. In practice, this means refining searches in structured lists by complementing the underlying terminology with the words and phrases that doctors and patients use in their everyday practice (e.g., synonyms or lay expressions for the same concept) and collapsing similar or hierarchically related values so that the list presented to the doctor is shorter, more intuitive and faster to scan. This is expected to reduce the time required to locate specific items and, therefore, lower the risk of navigation and selection errors during routine use. The initial stability issues identified (such as problems when saving or updating a visit) have already been addressed and resolved through dedicated testing scenarios focusing on these specific functions, and the same components will continue to be monitored in subsequent releases. The workload associated with mandatory fields will be addressed in alignment with the NeHA, which, under national law, will define the exact health data elements that must be recorded in the national EHR. This process is in progress, and the eHealth4U system will be finalised and configured in accordance with the Authority's final specification, so that mandatory data entry is limited to the legally required core dataset and does not impose an unnecessary burden on clinicians.
Interoperability evaluation
In the same spirit of seizing any opportunity to engage with stakeholders and key players in the healthcare domain nationally and at the cross-border level, eHealth4U actively participated in two hackathons and three Connectathon events.
In 2022, the X-eHealth project hosted two hackathons, focusing on Chronic Disease Management and Rare Diseases and Cancers.34–36 The eHealth4U actively engaged in both events, demonstrating SeHRB's reference implementation in alignment with the directives of the X-eHealth project. This project garnered notable acclaim and positive feedback, underscoring its role in promoting interoperability across Europe. However, the most significant contributions stemmed from participation in Connectathons, where real-time health data exchanges occur within structured frameworks that validate adherence to interoperability standards and foster collaboration and learning opportunities. These events facilitate the comprehensive testing and optimisation of the system's interoperability capacities alongside diverse stakeholders in the healthcare domain.
In this direction, eHealth4U participated in the IPS track of two official HL7 FHIR Connectathon events 37 in January 2023 and January 2024, and in the Integrating the Healthcare Enterprise (IHE) Connectathon 38 in September 2023. These involvements resulted in successful IPS document exchanges with organisations beyond EU borders, demonstrating eHealth4U's adeptness in integrating with third-party systems.
During the interoperability evaluation, participation in FHIR Connectathons and project hackathons mainly served to exercise the eHealth4U implementation of the IPS against the HL7 FHIR IPS IG and x-eHealth profiles in realistic exchange scenarios. No significant semantic or workflow challenges were identified because our profiles were already well aligned with these specifications. A key lesson from these events was the need for an IG that is understandable not only to FHIR experts but also to other stakeholders, which led us to clarify the guide's structure and add more narrative explanations and worked IPS examples, thereby strengthening both the robustness and usability of our interoperability documentation.
For eHealth4U, successful participation in the three Connectathons validates development efforts, amplifies industry recognition and contributes to feedback mechanisms for continuous improvement, thereby advancing interoperability in healthcare.
Discussion
Building a national eHealth ecosystem aligned with the state's national eHealth law is essential for securing health data sharing among healthcare providers. Ensuring interoperability, safeguarding citizens’ rights and privacy in the digital healthcare environment and promoting transparency, accountability and trust among stakeholders is crucial39,40; thus, it becomes a critical foundation for establishing a national health data space and, by extension, contributing to the construction of the EHDS. 41
The eHealth4U serves as a reference implementation, establishing the core components of the CHDS by integrating legal and technical frameworks. This cohesive approach has laid the foundation for a citizen-centred national eHealth ecosystem by embedding actionable legal provisions into the system's design and implementation.
Electronic health record structure and content definition via doctor’s active participation
Involving doctors in EHR development has shown numerous benefits, particularly in reducing their burden and improving clinical workflow.42–44 Through collaborative workshops with primary care doctors, eHealth4U designed the national EHR prototype to address the needs and preferences of doctors, thereby improving the effectiveness of EHRs in everyday medical practice.
Interoperability
Interoperability in healthcare is globally recognised as a complex challenge. 45 In Europe, interoperability has become a priority, particularly through the EHDS proposal, which aims to establish a harmonised framework for health data management across EU MS.46,47 In this direction, the EIF is used to ensure legal, technical, semantic and organisational interoperability. 10
To establish a citizen-centred eHealth ecosystem, the eHealth4U adopted the EIF framework. Legal interoperability was realised through alignment with the national eHealth law and compliance with the EU directive, facilitating legal interoperability with the myHealth@EU framework,13,48 especially for cross-border health data exchange in patient summaries and e-prescription services. 49
In terms of technical interoperability, the use of standardised health informatics protocols with a centralised data communication point has been shown to enhance interoperability, scalability and data availability. 50 The eHealth4U utilises standardised health informatics protocols and adopts a cloud-based architecture built on the HL7 FHIR standard. This approach enables seamless data integration from healthcare providers into a single national communication point, creating a SeHRB prototype. The profiling strategy optimised interoperability by leveraging existing profiles and ensuring conformance with the IPS FHIR IG and EPS, thereby enhancing both European and international interoperability.
To enhance semantic interoperability, eHealth4U adopted default FHIR value sets aligned with national EHR requirements. To comply with EU cross-border services under myHealth@EU, MVC was integrated into eHealth4U terminology. To semantically represent MVC, custom FHIR value sets were developed as needed. The FHIR resource ConceptMaps 51 was utilised to map the default FHIR value sets to the customised MVC-specific FHIR value sets where necessary.
Finally, to ensure organisational interoperability, eHealth4U used the Simplifier collaboration platform to publish its IG, organise workshops with national eHealth stakeholders and participate in hackathons and Connectathons to validate its interoperability solutions. 52
Technical infrastructure
Successful eHealth system implementation requires legal compliance, adherence to interoperability standards and a robust technical infrastructure that ensures data availability, scalability, extensibility and redundancy. 53 The benefits of using cloud computing for eHealth systems have been underlined, 54 especially in terms of data availability, with eHealth4U utilising this infrastructure to ensure efficiency and resource utilisation. Security mechanisms, such as access control, GDPR compliance, consent management, real-time system monitoring, data encryption and secure communication, are integral components of the eHealth4U system, ensuring data integrity and availability.
Data protection and security
Data privacy and security are paramount in EHR systems to ensure their success and trustworthiness. Rezaeibagha et al. identified key features that are essential to EHR security. 55 These features, some of which have also been discussed in more contemporary research,56,57 are integrated into the national eHealth law.
The eHealth4U addresses security concerns with advanced authentication and authorisation standards, centralised monitoring, data encryption, secure communication channels and high-availability infrastructure, ensuring the protection of sensitive healthcare information.
Beyond interoperability, EHDS aims to empower citizens to own and control their health data.58,59 Cyprus’ national eHealth Law supports this by allowing citizens to control which healthcare providers can access their data and to lock specific data from providers. The eHealth4U implements a consent management system embedded in the EHR, enabling citizens to view and manage their health data and monitor their access through an audit log. This balanced approach promotes data privacy while also advancing data-driven healthcare. 60
Project limitations and future considerations
The present work has several limitations that need to be acknowledged to shape the priorities for future development. First, the evaluation reported here provides an initial picture based on a defined group of doctors and patients under controlled conditions; however, more extensive and structured feedback is required from the wider Cypriot medical community. There is a need to investigate in greater depth how eHealth4U fits into everyday clinical workflows across different specialties, how much documentation burden it introduces in real practice, how steep the learning curve is for professionals with varying levels of digital literacy and how the system integrates existing clinical information systems and organisational routines. Future work is therefore planned to involve the Pancyprian Medical Association and other professional bodies in a more organised way, for example, through workshops and hands-on sessions in which clinicians can use eHealth4U in realistic cases, provide structured feedback and discuss concrete adoption barriers. In parallel, pilot groups of doctors of different ages, specialties and levels of experience with technology are expected to use eHealth4U in their routine work for a defined period, with feedback collected through questionnaires, interviews and usage data. The overarching goal of these activities will be to evolve the system so that it minimises the burden on healthcare professionals while maximising efficiency and health benefits for citizens, in line with national legislation, the EHDS framework and interoperability requirements at the national and cross-border levels.
The second set of limitations relates to the alignment of eHealth4U with the National Health Insurance System and existing information systems in the Cypriot health sector. The eHealth4U is conceived as the national EHR platform serving the health of Cypriot citizens and, in that sense, should function as the ‘heart’ of the national health system. Alignment with the National Health Insurance System is therefore not only desirable but also inevitable if doctors are to avoid duplicating work across parallel systems. However, this alignment presents non-trivial policy and integration challenges. In the absence of a national EHR, the National Health Insurance system had to develop its own reimbursement and recording mechanisms that were largely disconnected from the clinical EHR functionality. Moving towards a model in which doctors can record clinical and administrative information once in eHealth4U and have this reused for reimbursement will require a transition period during which the National Health Insurance System and other existing EHRs are progressively integrated with the national platform. Although eHealth4U already provides interoperability capabilities that can support this transition, additional work is needed on outreach to healthcare providers, the preparation of clear, comprehensive IGs and technical support for vendors and organisations so that these capabilities are understood and effectively used in practice.
Finally, there are limitations related to the legal and international contexts. The current design of eHealth4U is grounded in the national eHealth law, which is already well-aligned with the EHDS principles and objectives. Nevertheless, full legal and operational compliance with the final EHDS regulation will require a detailed impact assessment by the NeHA, systematic mapping of EHDS requirements to the national legal framework, and, on this basis, targeted adjustments to eHealth4U and its governance to close any remaining gaps. The outcomes of initiatives such as the Extended EHR (Xt-EHR) are expected to provide further implementation guidance to strengthen the alignment of the national EHR with EHDS.
The eHealth4U has been designed as a national EHR platform tailored to the specific features, legal requirements and clinical practices of the Cypriot health system, and its primary purpose is to serve these national needs. Once the system has been fully deployed and evaluated in Cyprus, it would be of interest to explore its use in collaboration with health systems in other countries that share similar organisational characteristics, legal frameworks and medical culture, to examine whether and how the underlying design approach and solution can be adapted beyond the Cypriot context.
Conclusion
The implementation of eHealth4U marks a crucial milestone in the development of CHDS, establishing the foundations of a robust national eHealth ecosystem. At its core, the prototype embraces a citizen-centred approach, placing individuals at the heart of healthcare decision-making processes. With a prototype of the national EHR system that addresses the requirements of the primary care sector, eHealth4U ensures the availability of accurate, up-to-date health information for citizens across all participating healthcare providers, enabling personalised care and improved clinical outcomes.
In line with EHDS vision, the prototype incorporates cutting-edge technologies to ensure a secure, scalable and future-proof infrastructure validated through rigorous unit testing with over 400 test cases. The prototype employs consent management in accordance with stringent data protection regulations, such as the GDPR, as well as related provisions of the national eHealth Law of Cyprus, to safeguard data confidentiality and privacy and empower citizens’ data ownership.
Future developments aim to further enhance citizen engagement by implementing FAIR (Findable, Accessible, Interoperable, and Reusable) principles, fostering greater accessibility, interoperability, reusability and transparency of health data. Additionally, planned enhancements include components that facilitate citizen–provider interaction and communication, such as the implementation of the Ideas, Concerns, and Expectations consultation model, Patient-Reported Outcome Measures and Patient-Reported Experience Measures.
In anticipation of the enactment of the EHDS law, efforts are being made to incorporate new requirements into the legal framework of eHealth4U. Moreover, several initiatives related to EEHRxF are underway, presenting opportunities to align eHealth4U implementation with EHDS objectives. This alignment aims to fortify the CHDS, advance interoperability at both the national and EU levels, enhance data security and foster citizen-centred healthcare delivery.
A significant ongoing endeavour within this framework is the Joint Action, Extended EHR@EU Data Space for Primary Use (Xt-EHR), which focuses on delivering technical specifications and implementation guidelines for the primary use of health data and on establishing a conformity assessment framework for the adoption of EEHRxF. The Xt-EHR prioritises interoperability across national and cross-border contexts with due consideration for telemedicine initiatives. With Cyprus leading coordination efforts in this collaborative project, our involvement allows for the swift alignment of eHealth4U implementation with project outcomes, facilitating optimisation based on emerging insights and best practices.
Another crucial initiative that leverages the eHealth4U foundation and expands into the secondary use of health data is the EU-funded direct grant project (CY-EHDS-2nd). Essentially, this project is coordinated by the NeHA and utilises the eHealth4U infrastructure to establish a framework for the secondary use of health data at both national and European levels. Expected to conclude in 2027, the project positions the SeHRB as one of the significant health data holders in Cyprus, and thus, an integral part of the national ecosystem for the secondary use of health data.
Similarly, the active participation of Cyprus in projects such as MyHealth@EU, X-Share, XpanDH and TEHDAS2 paves the way for meaningful advancements in the healthcare system. By tapping into the insights gained from these initiatives, we can strengthen eHealth4U implementation and thus support the establishment of the CHDS. This collaboration not only enhances our capabilities but also fosters cross-border partnerships, ultimately improving healthcare for everyone in the EHDS.
This steadfast commitment underscores Cyprus’ dedication to progressing digital transformation in healthcare within its jurisdiction, leveraging every avenue to enhance health quality and overall well-being for its citizens.
Footnotes
Acknowledgements
The authors would like to express their sincere appreciation to Dr Ioannis Chatziminas, Paediatrician, and Dr Christos Th. Nikolaou, a consultant radiologist and deputy director of the radiology department at the State Health Services Organisation, for their invaluable guidance during the requirements gathering and analysis phases. The authors would also like to thank all partners of the eHealth4U project (3AHealth, International Institute of Compassionate Care, Ubitech, Iron Mountain, CYTACOM, Private Hospital Hippocrateion, CYTA and the State Health Services Organisation) for their cooperation and support in implementing and completing this initiative.
ORCID iDs
Ethical considerations
Formal project-level approval for the eHealth4U project was obtained from the National Bioethics Committee of Cyprus; however, the specific usability evaluation reported here used only synthetic data and anonymised participation and therefore did not require separate study-specific ethical approval.
Contributorship
MP contributed to writing – original draft, conceptualisation, methodology, project administration, software and visualisation. AN contributed to writing – review & editing, conceptualisation, methodology, project administration and software. PS contributed to writing – original draft, methodology and software. CY contributed to writing – review & editing, methodology and software. CM contributed to writing – review & editing, methodology and software. ICC contributed to writing – review & editing, methodology and software. IC contributed to writing – review & editing, conceptualisation, funding acquisition, methodology and software. GA contributed to writing – review & editing, methodology and software. FG contributed to writing – review & editing, methodology and software. AP contributed to writing – review & editing, conceptualisation, funding acquisition and methodology. ZA contributed to writing – review & editing, conceptualisation, funding acquisition and software. ES contributed to writing – review & editing and conceptualisation. GP contributed to writing – review & editing, conceptualisation, methodology, resources and validation. GS contributed to writing – review & editing, conceptualisation, funding acquisition, resources and validation. CSP contributed to writing – review & editing, conceptualisation, funding acquisition, methodology, project administration and supervision. CNS contributed to writing – review & editing, conceptualisation, funding acquisition, methodology, project administration and supervision.
Funding
The authors disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was co-funded by the European Regional Development Fund and the Republic of Cyprus through the Research and Innovation Foundation (Project: INTEGRATED/0916/0030).
Declaration of conflicting interests
The authors declared no potential conflicts of interest with respect to the research, authorship and/or publication of this article.