SALUS—A Study on Self-Tonometry for Glaucoma Patients: Design and Implementation of the Electronic Case File

Abstract

Background In times of omnipresent digitization and big data, telemedicine and electronic case files (ECFs) are gaining ground for networking between players in the health care sector. In the context of the SALUS study, this approach is applied in practice in the form of electronic platforms to display and process disease-relevant data of glaucoma patients.

Objectives The SALUS ECF is designed and implemented to support data acquisition and presentation, monitoring, and outcome control for patients suffering from glaucoma in a clinical setting. Its main aim is to provide a means for out- and inpatient exchange of information between various stakeholders with an intuitive user interface in ophthalmologic care. Instrument data, anamnestic data, and diagnostic assessments need to be accessible and historic data stored for patient monitoring. Quality control of the data is ensured by a reading center.

Methods Based on an intensive requirement analysis, we implemented the ECF as a web-based application in React with a Datomic back-end exposing REST and GraphQL APIs for data access and import. A flexible role management was developed, which addresses the various tasks of multiple stakeholders in the SALUS study. Data security is ensured by a comprehensive encryption concept. We evaluated the usability and efficiency of the ECF by measuring the durations medical doctors need to enter and work with the data.

Results The evaluation showed that the ECF is time-saving in comparison to paper-based assessments and offers supportive monitoring and outcome control for numerical and imaging-related data. By allowing patients and physicians to access the digital ECF, data connectivity as well as patient autonomy were enhanced.

Conclusion ECFs have a great potential to efficiently support all patients and stakeholders involved in the care of glaucoma patients. They benefit from the efficient management and view of the data tailored to their specific role.

 

MissingLinkText

Keywords

telemedicine - electronic case file - patient empowerment - glaucoma - trial management

Background and Significance

Over the past decade digitization has made significant inroads into the field of health care.[1] While all hospitals in SALUS that perform administrative tasks are equipped with an electronic hospital information system (Krankenhausinformationssystem), it is not uncommon for data to still be recorded in paper form or solitaire tabular files in CSV or excel formats. This concept not only seems outdated in the 21st century, but also has obvious disadvantages in patient care.[2] The electronic case file (ECF) contributes to better patient care and cost reduction by avoiding redundant diagnostics and increasing data quality due to the possibility of validation and limitation of entries. It is more transparent and offers, among many other advantages, the possibility of data exchange among stakeholders in the health care system[2] and new methods for improving health care research and quality assurance in worldwide ophthalmology.[3] [4] Ophthalmology is considered particularly rich in data, so there is a need for a clear and complete representation.[2] [5] [6]

As a consequence and conclusion of digitization in ophthalmology, telemedical approaches are increasingly derived. Accelerated by the coronavirus disease 2019 pandemic, telemedicine in ophthalmology not only offers better communication between stakeholders, but is also expected to relieve the health care system and facilitates access to medical care.[7] Telemedicine has a wide range of applications in ophthalmology, particularly for screening, for example, for diabetic retinopathy and age-related macular degeneration, thereby improving access.[8] [9] Noninvasive imaging and testing modalities, such as optical coherence tomography for imaging the retina and optic nerve head, and fundus photography, can be performed in a decentralized manner outside the practice by trained staff or the patient. This means, that diagnoses can be made over long distances, saving resources, and patients can be referred to specialists, if necessary.[8]

Chronic diseases, in particular, require regular checkups over many years and thus a great deal of data to keep track of in order to determine the progression of the disease. Glaucoma is one of the most common chronic eye diseases, leading to complete blindness without appropriate therapy. The SALUS project (www.salus-glaukom.de) contains a pioneering prospective, two-arm parallel group, open noninferiority, randomized controlled clinical trial focusing on the care of glaucoma patients in Germany.[10] The SALUS study targets the improvement of the health care situation for glaucoma patients in Germany. Glaucoma therapy response is generally controlled by monitoring the intraocular pressure (IOP), as this parameter is easily modifiable by a variety of medications. The assessment of treatment success is usually done by measuring structural parameters of the human retina, such as the thickness of the retinal nerve fiber layer (RNFL), using specialized tools, and by monitoring the levels of the IOP. In Germany the latter is commonly done by repetitive assessment in an inpatient clinic over the course of 24 hours.[11] Although some practitioners may attempt outpatient IOP profiling with repetitive measurements in their practice throughout the day, this approach has been challenging to include in daily practice routine. Thus, new concepts for outpatient IOP monitoring have been the focus of glaucoma experts. The aim of the SALUS study is to identify whether outpatient monitoring of IOP with self-tonometry is as effective as the current standard of care.

After patient inclusion and randomization into either the control (inpatient), or intervention (outpatient; self-tonometry) group, each participating patient undergoes an initial baseline examination, followed by either in- or outpatient IOP and blood pressure measurements, three checkups and one final examination over a period of 12 months. For the outpatient measurements, patients get self-tonometer and 24-hour blood pressure devices from the ophthalmologists who initialize the devices and set the use periods. Patients were enrolled by local ophthalmologists or by eye hospitals participating in the study. If a local ophthalmologist includes a patient, evaluation of the self-tonometry measurements, therapy adjustment, and checkups take place in the medical practice. Initial and final examinations are always carried out in the eye hospital. If patient inclusion took place in the eye hospital, all examinations and evaluations are done in the hospital. An overview of the study design is presented in [Fig. 1].

Fig. 1 Study setup for the intervention group. IOP, intraocular pressure.

Within the SALUS project, an ECF was developed, in which all measured values, the medical history, and the imaging are either manually entered or uploaded by the participating clinicians and resident ophthalmologists. This centralized platform is accessible to practitioners, hospitals, and study participants and provides seamless exchange between all parties involved, which is of outstanding relevance for the German health care system.[12] [13] Patients are usually initially seen by a local ophthalmologist and referred to a specialized clinic if necessary. This often results in the loss of information, overdiagnosis, and delay of treatment. The ECF can also be used by local ophthalmologists to request consultation with a glaucoma specialist and senior resident from the University of Muenster Medical Center. The ophthalmologists at this specialized center are also responsible for the evaluation of data generated at the different visits of the SALUS study in the integrated reading center. Patients are granted read access to their own ECF, enabling them to stay informed about their condition. The close integration of all roles and the reading center are not covered by other tools, such as REDCap ( https://www.project-redcap.org ), or too expensive for small- to mid-size research projects and clinics.

 

MissingLinkText

Objectives

The overall goal of this work was to support the complete workflow of the SALUS study digitally and enable efficient data exchange between all stakeholders involved. To that end, an ECF was implemented that addresses the following specific challenges:

• Data should be provided and monitored by a diverse user group in various locations, including patients themselves, which requires a role-specific user interface design.

• Data should be uploaded from network-enabled commercial medical devices (IOP and blood pressure) automatically, which requires an open communication architecture.

• The system architecture should be suitable both, to support the SALUS study (including data quality control) and to support future patient monitoring processes in case the SALUS study is positively evaluated, which requires a modular and flexible design.

 

MissingLinkText

Methods

Requirements Analysis

In the beginning of the project a detailed requirements analysis was carried out. Functional and nonfunctional requirements were elicited in workshops and weekly meetings throughout the entire project time with doctors and study managers by the product owner and developers. In these meetings, requirements were iteratively refined and compared with the current implementation. In the following, the most important requirements identified are described.

Access and Usage Control

Due to the many roles (=12) involved in management, data acquisition, processing, and quality control, the definition of roles and the assignment of users to roles has to be simple and flexible. The role not only determines which tasks a user is allowed to execute in the web interface, but also restricts the visibility and manipulation of certain parts of the data. The data access also depends on the user's organization, i.e., a clinic or a practice (organizations are only allowed to see data from their own patients).

 

MissingLinkText

User Interface

The study comprises organizations and users from different sites and geographic locations in Germany with highly varying technical literacy. Consequently, the application needs to be user-friendly, easily accessible without much setup effort, and easily maintainable. The application is hosted and monitored on servers located at Fraunhofer FIT. Moreover, the patient user group comprises specifically elderly and visually impaired persons. Hence, the user interface needs to address requirements, for example, on the level of contrast or the font size. The user interface must be easily adaptable and extendable to address the different roles and additional requirements that might come up in the course of the study. The functional requirements of the user interface are tight to the roles of the users and were analyzed for each role in very detail using the data to be acquired in the study and identifying processes in the study, such as including or excluding a patient into/from the study.

 

MissingLinkText

External Sources and Devices

A fundamental aspect of SALUS is the comparison of home monitoring versus clinical monitoring of the IOP, blood pressure, and other parameters relevant to the progression of glaucoma. Accordingly, it is required that the measurements of the home monitoring devices are imported into the ECF using standardized protocols. In addition, data from further sources, such as the FIDUS system used in hospitals, should be importable into the ECF to reduce manual steps. We can integrate data from home monitoring devices, i.e., self-tonometer and blood pressure device, depending solely on the export format. Each format requires a wrapper to seamlessly transform the data into the desired format.

 

MissingLinkText

Data Management

Data entered into the user interface must be stored efficiently and securely as the data are sensitive. Master data (comprising the personal information of the patient) must be stored separately. The data schema should apply to common standards and be flexible, as requirements may change in the beginning of and during the study. Moreover, data auditing is needed to track the changes that have been made to the data by a user. All users should have a restricted view specific to their role on the same data.

 

MissingLinkText

Data Security

Due to the sensitive nature of the data, specific requirements regarding data security apply. All data, including files, need to be stored encrypted. In addition, access to the data needs to be restricted and controlled based on the role. Furthermore, the data transmission between the ECF and external parties must be secured using certificates and security tokens.

 

MissingLinkText

 

MissingLinkText

Architecture and Design

The SALUS ECF is implemented as a web application. Its architecture, depicted in [Fig. 2], consists of (1) a back-end server maintaining the master data, examination data, and other appointment related data encrypted at rest. The data are stored in a Datomic (https://www.datomic.com) database as immutable atomic facts. Datomic employs a universal schema in which attributes describe entities and can take a value. Each entity can then be assigned arbitrary attributes, which makes the schema highly flexible. The definition of entities and attributes in the schema have been inspired by the Apple HealthKit (https://developer.apple.com/documentation/healthkit) data model, for example, using the correlation type for measurements with multiple parameters. Metadata, such as the unit or the measuring device, also are recorded. The database used in this project maintains a complete history of all changes and can therefore provide an audit trail if necessary. Even deleted data will remain available unless explicitly excised (when patient revokes his participation). The back-end server is written in Clojure (Clojure is a functional programming language of the Lisp family: https://clojure.org) using Pedestal (Pedestal is a set of Clojure for building web services and applications: http://pedestal.io) and Lacinia (Lacinia is a Clojure library implementing the GraphQL specification: https://github.com/walmartlabs/lacinia). It exposes REST and GraphQL (https://graphql.org/) APIs for data access and updating. GraphQL directives were used to implement fine-grained access control and encryption on the attribute level. Access control is role based; a user with the patient role, for example, may only execute a method to retrieve her own appointment data, where the study lead role can access data from all patients. Files, such as images, are stored as well encrypted in an (2) S3 file store. Only when data or files are retrieved by the web front-end, they will be decrypted.

Fig. 2 Architecture of the SALUS electronic case file.

User access control is realized via (3) an Identity Management Server, enabling the login for health professionals, such as ophthalmologists, project management, or quality assurance, as well as for patients. In the Identity Management Server users get a role and are assigned to an organization. This information is encoded in the user handle and can be utilized by the application to control access to user screens and data. The user interface of the SALUS ECF is provided by (4) a web server that lies behind the external firewall, it is exposed to the internet, but located in a separate network from the actual services, where (5) the front-end is implemented in React (https://react.dev/) using JavaScript. Furthermore, there are several interfaces to import measurement data from external devices, i.e., the iCare self-tonometer and the 24-hour blood pressure device. Both are performed by ophthalmologists or clinicians in private practices. IOP data are transferred from the (6) iCare mobile devices via a client software to the (7) iCare CLINIC server and subsequently imported by the ophthalmologists in the FHIR (Fast Healthcare Interoperability Resources) format into the ECF via a REST API provided by iCare CLINIC. Similarly, data from (8) 24-hour blood pressure measurements are imported as CSV files into the ECF.

Encryption uses the libSodium (https://doc.libsodium.org) library and a password stored only in memory of the running process. This password is only known to few individuals leading the study. This password has to be entered by them after the service has (re-)started. The password is never stored on disk and is neither known to technical personal nor developers.

 

MissingLinkText

Development

An agile method was used for software development and project management to deliver updates more quickly.[14] For development, testing, and production, three different instances of the system architecture were created. With this approach, domain experts and study managers continuously could compare the documented requirements against the current implementation and give feedback in weekly meetings. As a code repository and for a collaborative software development, we used GitLab to track issues and related commits, making the development fully transparent and enabling smooth collaboration between all stakeholders in the development process. Moreover, we used the Continuous Integration and Deployment features of GitLab with a pipeline to deploy to the three instances.

Each new function was tested thoroughly by at least two persons including domain experts to ensure a high-quality system aligned with the posed requirements. Furthermore, we carried out automated user interface tests based on a comprehensive test plan with test cases using Selenium (https://www.selenium.dev). For example, we tested for an examination, the cases for mandatory fields not filled, only mandatory fields filled, all fields filled. Finally, we also implemented automated testing for the back-end.

 

MissingLinkText

User Interface

To enable the access for several stakeholders involved in the clinical trial, dedicated views for each role are implemented in the application and support the differing tasks of the users. For example, the local ophthalmologists are the only ones who may include the patient into the study and do the randomization and form printing over the ECF based on the master data of the patient, such as the insurance company ([Fig. 3]). To support the study design consisting of multiple regular appointments, a workflow and corresponding validation steps have been implemented into the ECF. Hence, doctors and the project management, which includes the back-office study nurses, always know the current status of the patient in the study workflow and can interfere if necessary. The back-office study nurses, located in the Department for Ophthalmology at the University Hospital Muenster, have the most detailed view of the ECF, and therefore, a corresponding list view that shows open tasks or problems for each patient. A red mark ([Fig. 4]) appears next to the appointment in three different scenarios: firstly, when the appointment took place but the entries are incomplete; secondly, in instances where the appointment is overdue and did not take place so far; and finally, when the appointment did not take place so far, but at least one of the subsequent appointments took place (for instance, a red mark will appear for the “FollowUp 2” appointment if it did not take place so far and either “FollowUp 3” or “Final” appointments took place). An explanatory error message is shown upon hovering over the aforementioned red mark.

Fig. 3 Patient list in the doctor view.

Fig. 4 (A) Patient master data and appointment list (left side of patient view). (B) Graph with single attributes of 24-hour blood pressure measurements (right side of patient view). Patient view of 24-hour blood pressure measurement of self-measurements of the intervention group (fictive demo data on the test server entered for test reasons, no real patient data).

To support the quality assurance in the clinical trial, we added a reading center to the ECF user interface that complements all relevant clinical data and images. The completeness and plausibility of the examination results from the participating hospitals and local ophthalmologists are checked by a data entry manager and two glaucoma experts upholding the four-eye principle. Patients can access their own verified data over a dedicated patient view ([Fig. 4]) designed toward their potential visual impairment. Additionally, they can print out examination results for their practitioners.

The web front-end was implemented along the Model-View-Controller pattern, separating business logic and user interface. The forms are mainly dynamically created based on the data delivered by the GraphQL interface.

 

MissingLinkText

User Evaluation

The SALUS ECF was tested in clinical practice by ophthalmologists of the Department for Ophthalmology at the University Hospital Muenster, Germany. Two trained clinicians with a focus on glaucoma diagnostics and treatment used the ECF for all patients that were included in the SALUS study since February 2021. The duration for the inclusion of a SALUS patient into the SALUS case file in a real-world clinical setting was assessed for 19 patients. This encompasses the explanation of the study design to the patient, the transfer of general patient information into the ECF, the obtaining of written consent, the randomization process, the clinical examination of the patient, as well as the time required for entry of clinical information, and clarification of pending questions. Data were recorded in a spreadsheet file. Descriptive data are presented as mean ± standard deviation (SD). Furthermore, the logins to the patient view were analyzed to determine the acceptance of patients for the ECF.

 

MissingLinkText

 

MissingLinkText

Results

User Evaluation

While on average the entire process of patient inclusion, consisting of seven steps, took 16:27 minutes, almost half of that time was spent on clinical assessment alone (7:58 ± 1:00 minutes; 48.5%). Time related to the SALUS case file accounted for approximately 20% of the entire process (3:18 ± 0:41 minutes). The average duration for each step of the inclusion of patients into the SALUS ECF and for the process as a whole are displayed in [Table 1].

Table 1 Average duration for patient recruitment for the SALUS study including assessment and entry of patient data into the SALUS electronic case file in seconds and as percentage of entire recruitment process (n = 19).

	Mean duration ± SD (seconds)	Percentage (%)
Procedural steps
(1) Introduction	158 (± 56)	16.0
(2) Adding general information to ECF	48 (± 31)	4.9
(3) Obtaining consent	54 (± 19)	5.4
(4) Randomization process	28 (± 7)	2.8
(5) Clinical assessment	478 (± 60)	48.5
(6) Data entry	122 (± 26)	12.4
(7) Clarification of remaining questions	99 (± 249)	10.0
Total	986 (± 277)	100.0

Abbreviations: ECF, electronic case file; SD, standard deviation.

Data are displayed as mean ± SD. The various steps of the inclusion process are listed in a chronological order from top to bottom. Procedural steps that were carried out exclusively in the ECF encompass adding general information to the case file (step 2), randomization (step 4), and entry of clinical data (step 6). These accounted for a total of 198 (±41) seconds, equaling 20.0% of total time spent on patient inclusion. In the subjective view of the clinicians who worked with the ECF, the application is described to be time-saving in comparison to a paper-based assessment or to other ECFs at hand in the Department for Ophthalmology at the University Hospital Muenster. The design facilitates a quick and precise entry of relevant data for glaucoma patients. They praised the possibility to look up patient data in the system simultaneously with other professionals and that the web-based application enables the display of information on various types of electronic devices. Likewise, the clinicians regarded the possibility for patients to look up their clinical data from outside the clinic, for example, at the office of another ophthalmologist, to be of high value for an ample medical treatment.

A total of 133 patients that belong to the intervention group had the possibility to use the patient view and got the log in details via letter. [Fig. 5] shows that 40% of them logged in at least one time within the first 3 months after implementation and receiving the letter. Most of these patients logged in one to three times. Analyzing the state of the study of the patients that logged in, it can be noticed that 50% of the people recently had one of their checkups at their local ophthalmologist or in the eye hospital. Twelve persons completed their initial examination and 10 persons finished all the examinations.

Fig. 5 Number of logins to the patient view within 3 months after implementation.

 

MissingLinkText

Role and Data Management Evaluation

The implemented role management and the rights connected to it, turned out to be flexible enough to enable the required functionality for each role. However, each user could only take one role at a time as the role determined the user interface capabilities, but it sometimes would have been necessary to assign several roles and then switch between them in the user interface. The different views of the roles on the same data also proved to be helpful and accelerated development, as we only needed to adapt the user interface where necessary for the roles; for example, for the patient view only a very limited view on the data was provided per patient. In most cases, no or very limited training was necessary for the local ophthalmologists and clinicians.

The underlying data model was very flexible and helped us to address new requirements regarding additional examinations very easily. Although we strove for maximum flexibility in the user interface to create user interface controls for new data and values dynamically, it was not always possible without additional adaptions and customization.

 

MissingLinkText

Connectivity Evaluation

For the IOP device, we created a dedicated connection to the manufacturer cloud. We could easily identify devices and automatically transfer data to our database. We used FHIR as a data exchange format for the transfer. Although we are not using a native FHIR database, a FHIR mapping for our data model could be added with reasonable effort in the future.

 

MissingLinkText

 

MissingLinkText

Discussion

During the course of the project it proved to be helpful that the development was carried out iteratively with feedback loops. Many requirements were not recognized right from the beginning and needed to be added later on (such as allowing physician assistants to include patients into the study). We decided for a Datomic database and not a native FHIR database to exploit the data versioning of Datomic. Further, we wanted a lean data format for data exchange, which is better suited for mobile applications. The shared usage of the data by the different stakeholders turned out also to speed up the trial management and data acquisition tremendously.

The average time spent on a patient visit in the SALUS study setting was longer than described by previous studies, which report durations of 11.2 minutes in an ophthalmologic setting to 13.9 minutes in a nonophthalmologic setting.[15] [16] This can be explained by the very broad clinical assessment regimen within the SALUS study, which accounted for approximately 8 minutes alone. Similar to previous works, however, the time spent on the actual work with the ECF was small in comparison to the total consultation time. Considering the comparably long time that was dedicated to patient examination, the 20% spent on ECF use in the present study appear comparable to the reports by Read-Brown et al, who describe that ECF use accounted for 27% in their investigation.[16]

It is desirable to increase the use of the ECF by patients in future studies. Patients were enrolled at different sites. Although all staff were equally trained to teach patients how to use the ECF, differences in quality between sites cannot be ruled out. In principle, every effort should be made by health professionals to work with patients to ensure that they are informed about their own condition.

The present study adds to the understanding that the introduction of ECFs can alter visit durations, yet consultation times are most strongly influenced by other factors.

Up to half of all patients with early-stage glaucoma suffer from progressing visual field loss,[17] which makes it relevant to investigate physiological changes in the retina. We plan to support doctors in the analysis of ophthalmologic images by artificial intelligence algorithms and integrate these into the user interface. Schiesser et al[18] preparatory developed a model for blood vessel segmentation to observe vascular changes and therefore to assist doctors with the diagnosis of glaucoma.

 

MissingLinkText

Conclusion

Digital case files have the potential to improve the management of glaucoma by providing ophthalmologists with quick and easy access to patient data. Our study group has developed an ECF specifically for patients with glaucoma. The system allows for the centralized storage and sharing of patient data, including IOP and RNFL measurements. The system is accessible to external ophthalmologists through an online server, which enables them to view the results of their patients' measurements carried out externally.

In conclusion, digital case files, such as the SALUS system, have great potential in the management of glaucoma. The ability to store and share patient data across multiple clinics can improve the monitoring of IOP and RNFL thickness and ultimately lead to better outcomes for patients with glaucoma. The SALUS system also promotes collaboration and communication between ophthalmologists, further improving the care of glaucoma patients.

 

MissingLinkText

Clinical Relevance Statement

The clinical relevance of digital case files in the management of glaucoma should not be underestimated. Glaucoma is a disease that progresses slowly, and changes in IOP and RNFL thickness can be subtle. Therefore, frequent monitoring is necessary to detect changes early and prevent further vision loss. The SALUS system allows for easy and frequent monitoring of these parameters by providing ophthalmologists with access to patient data from other clinics. In addition, the SALUS system promotes collaboration and communication between ophthalmologists. In the past, ophthalmologists may have had to rely on patients to bring their medical records from one clinic to another. This process can be time-consuming and error-prone. With SALUS, ophthalmologists can access patient data quickly and easily, without relying on the patient to provide it.

 

MissingLinkText

Multiple Choice Questions

1. What is the SALUS system, developed by the study group, used for?

   • Storing patient data for all types of eye diseases

   • Monitoring blood pressure and cholesterol levels in patients

   • Providing ophthalmologists with easy access to patient data for glaucoma

   • Tracking patient data for diabetes management

   • All of the above

   Correct Answer: The correct answer is option c. The SALUS system enables to store, read, and assess data from glaucoma patients included into the SALUS study.

2. Which database has been used as back-end storage in SALUS?

   • Datomic

   • MongoDB

   • Neo4j

   • SQL Server

   • None of the above

   Correct Answer: The correct answer is option a. Datomic stores data as immutable atomic facts. It employs a universal schema in which attributes describe entities and can take a value. It provides the possibility to create an audit trail if necessary.

3. Which of the following statements about the SALUS ECF architecture is NOT true?

   • The back-end server stores data in an immutable atomic facts database

   • Files, such as images, are stored encrypted in an S3 file store

   • User access control is managed via an Identity Management Server

   • The front-end of the SALUS ECF is implemented in Ruby on Rails

   • All data changes are recorded in an audit trail and can be rolled back anytime

   Correct Answer: The correct answer is option d. The front-end is implemented in React using JavaScript.

 

MissingLinkText

 

MissingLinkText

Conflict of Interest

None declared.

Acknowledgments

We would like to thank all funded partners of the SALUS project: Bielefeld University, statutory health insurers (DAK-Gesundheit, BARMER, AOK NordWest, IKK classic), and Association of Statutory Health Insurance Physicians Westphalia-Lippe (KVWL). Furthermore, we thank the participating clinicians, resident ophthalmologists, study nurses, and students, as well as the cooperating statutory health insurers, who supported the study. Parts of the implementation and design were provided by ysura GmbH, Munich. Gratitude is also dedicated to iCare, providing infrastructure, interfaces, and trainings for the self-tonometers, as well as to Dörnemann Medizintechnische Service GmbH, Dinslaken, for supporting us in the data export of the 24-hour blood pressure devices.

Protection of Human and Animal Subjects

The SALUS study has been approved by the Ethics Committees of the University of Muenster, Germany, and follows the guidelines of the Declaration of Helsinki and current German and European Union legislation on data protection.

• References

• 1 Bowman S. Impact of electronic health record systems on information integrity: quality and safety implications. Perspect Health Inf Manag 2013; 10 (Fall): 1c
• 2 Mir Mohi Sefat A, Patermann K, von Ohlen L. et al. [Electronic patient files in hospital information systems]. Ophthalmologe 2020; 117 (10) 1015-1024
• 3 Day AC, Donachie PH, Sparrow JM, Johnston RL. The Royal College of Ophthalmologists' National Ophthalmology Database study of cataract surgery: report 1, visual outcomes and complications. Eye (Lond) 2015; 29 (04) 552-560
• 4 Parke Ii DW, Lum F, Rich WL. The IRIS registry: purpose and perspectives. Ophthalmologe 2017; 114 (Suppl. 01) 1-6
• 5 Baro E, Degoul S, Beuscart R, Chazard E. Toward a literature-driven definition of big data in healthcare. BioMed Res Int 2015; 2015: 639021
• 6 Cheng CY, Soh ZD, Majithia S. et al. Big data in ophthalmology. Asia Pac J Ophthalmol (Phila) 2020; 9 (04) 291-298
• 7 Choritz L, Hoffmann M, Thieme H. [Telemedical applications in ophthalmology in times of COVID-19]. Ophthalmologe 2021; 118 (09) 885-892
• 8 Parikh D, Armstrong G, Liou V, Husain D. Advances in telemedicine in ophthalmology. Semin Ophthalmol 2020; 35 (04) 210-215
• 9 Rathi S, Tsui E, Mehta N, Zahid S, Schuman JS. The current state of teleophthalmology in the United States. Ophthalmology 2017; 124 (12) 1729-1734
• 10 Oldiges K, Steinmann M, Duevel JA. et al SALUS Study Group-a non-inferiority trial to compare self-tonometry in glaucoma patients with regular inpatient intraocular pressure controls: study design and set-up. Graefes Arch Clin Exp Ophthalmol 2022; 260 (12) 3945-3955
• 11 Ho CH, Wong JKW. Role of 24-hour intraocular pressure monitoring in glaucoma management. J Ophthalmol 2019; 2019: 3632197
• 12 Kohli R, Tan SSL. Electronic health records. Manage Inf Syst Q 2016; 40 (03) 553-574
• 13 Cowie MR, Blomster JI, Curtis LH. et al. Electronic health records to facilitate clinical research. Clin Res Cardiol 2017; 106 (01) 1-9
• 14 Schmidt C. Agile Software Development. Springer International Publishing; 2016: 2-35
• 15 Jabour AM. The impact of electronic health records on the duration of patients' visits: time and motion study. JMIR Med Inform 2020; 8 (02) e16502
• 16 Read-Brown S, Hribar MR, Reznick LG. et al. Time requirements for electronic health record use in an academic ophthalmology center. JAMA Ophthalmol 2017; 135 (11) 1250-1257
• 17 Gupta N, Weinreb RN. New definitions of glaucoma. Curr Opin Ophthalmol 1997; 8 (02) 38-41
• 18 Schiesser L, Storp JJ, Yildirim K. et al Blood vessel segmentation using U-Net for glaucoma diagnosis with limited data. Stud Health Technol Inform 2023; 302: 581-585

Publikationsverlauf

Eingereicht: 24. Oktober 2023

Angenommen: 22. April 2024

Artikel online veröffentlicht:
19. Juni 2024