Tailored to capture the core dataset definitions pertinent to ophthalmology, the Ophthalmology Extension Module will ensure that data captured are consistent and interoperable across different systems within the EyeMatics project. The dataset will be planned and agreed upon primarily on the basis of clinical research needs by clinical experts from the German Ophthalmology Society and patient representatives. It will be technically specified within the HL7 FHIR standard with value sets and code systems such as Systemized Nomenclature of Medicine–Clinical Terms (SNOMED-CT) and Logical Observation Identifiers Names and Codes (LOINC) to ensure semantic interoperability. The process is further governed by the national steering committee of the MII to ensure alignment with interoperability needs across diseases. The extension module will be versionized and publicly available for reuse and commenting on the portal of Medical Data Models [10] and Art DÉCOR [11]. In the planning phase, the core data elements will be examination items such as tonometry, refraction, visual acuity, medication details, further surgeries (ie, cataract surgery), laboratory data including glycated hemoglobin, and OCT imaging details such as retinal thickness for each eye. These will be extended, further granularized, and technically specified in the first year of the project.

The existing DSF of the basic MII infrastructure will be utilized for data transfer between DICs. Each DIC has already implemented extracts, transforms, and loading procedures for the basic MII core datasets and provides local pseudonymization services. In order to add the ophthalmology extension module, further primary information systems are required to be connected to a project-specific HL7 FHIR repository of the DIC, including data from the electronic medical records, laboratory information system, and the OCT scans from the imaging archive of the ophthalmology department. Pseudonymization and record linkage on a cross-site level will be established by a global federated trusted third party [12]. In a first iteration, each DIC shares and stores the medical data of all DICs in periodic cycles. In further iterations, a caching mechanism and storage of aggregated values will be implemented to reduce data redundancy. The final goal is a real-time data exchange on request. In addition to the DSF, a mobile ePRO service must be installed and configured to link PRO data into the existing FHIR repository. The data items of PRO instruments will be developed as part of the project (see below, section Health Care Evaluation). Figure 2 illustrates the technical architecture within one DIC.

While a HL7 FHIR repository is employed to ensure a standardized exchange of clinical data, the Digital Imaging and Communications in Medicine (DICOM) standard is used for handling medical imaging information. DICOM plays a crucial role in managing the vast imaging data, similar to OCT, ensuring it is correctly linked to patient records. The strategy of bridging clinical and imaging raw data with HL7 FHIR and DICOM involves exporting DICOM metadata of OCT images into FHIR’s ImagingStudy resources, which will then be stored in the local FHIR repository, allowing for efficient querying of image metadata without the need to store large image files directly in the FHIR repositories. This approach will enable seamless interoperability between the medical imaging and clinical data domains, facilitating queries that link patient diagnoses with available imaging data, and ensuring that image data can be accessed through standardized DICOM services linked within the FHIR resources.

The clinical demonstrator is an advanced interface that is connected to the local DIC (Figure 3). It visualizes data at the level of individual patients as well as at the cohort level of all partners. The purpose is to present patient information and imaging data in an accessible manner. Individual and aggregated cohort data for comparison need to be visualized separately for the left and right eyes, an essential feature lacking in general electronic medical record systems. A close collaboration and feedback process with clinicians will enable a user-centric design. This especially includes formative and summative usability evaluations. During the project, the demonstrator is not intended as a medical device or clinical decision support as it only features an integrated view of previously isolated data and analyses results. None of its elements, including the artificial intelligence (AI) biomarkers, represent calculations or treatment advice for an individual patient but important associations on a cohort level. However, to prepare individual AI-based treatment predictions, the AI pipeline will already involve regulatory preparations in all the planning and development phases (see AI-Based Biomarkers and European Union Medical Devices Regulations).

Advanced data analysis aims to discover new imaging-based biomarkers indicative of therapy success by integrating monitoring tools and imaging-based biomarkers into the clinical dashboard. The goal is to create optimized treatment plans as a conceptual demonstration of the AI’s capabilities in precision medicine.

To do this, we will model patient trajectories based on OCT volumes, disease-relevant laboratory data such as glycated hemoglobin, treatment information, and general patient data. We will use deep learning models to extract the disease course of each patient in a latent space and model the trajectories of each patient, especially in response to interventions. The deep learning module will make use of recently published pretrained foundation models such as RetFound [13]. From this latent space, we will predict the evolution of visual acuity as one of the main patient outcomes. Subsequently, we will derive biomarkers for successful treatment by using gradient-based techniques to backpropagate the information about successful treatment to the input data. This way an AI model will be established that is able to optimize treatment plans for specific individual patients.

Within the project duration, the resulting biomarkers will be only utilized for scientific knowledge discovery and not as an interventional medical device for clinical decision-making. However, to prepare for the translation of the information into clinical routines, the relevant steps for the planning and development of the AI algorithms will be accompanied in accordance with European Union Medical Devices Regulation and the upcoming EU AI acts by strictly applying quality management according to EN-ISO 13485, technical documentation of software life cycles, and risk management. To do this, one of the core research partners is already certified according to EN-ISO 13485. Moreover, a medical device vendor will prepare all the necessary documentations along with the planning and development of AI software from the start of the project.