Application of openEHR Platform for Data Exchange in Ophthalmology Stefan Velikov 1, Kostadin Merdzhanov 1, Nikoleta Leventi 1 and Todor Kundurdzhiev 2 1 MU – Sofia, FPH “Prof. Dr. Tzecomir Vodenicharov”, Dept. Health Technology Assessment, Bialo more str. 8, Sofia, 1527, Bulgaria 2 MU – Sofia, FPH “Prof. Dr. Tzecomir Vodenicharov”, Dept. Occupational Medicine, Bialo more str. 8, Sofia, 1527, Bulgaria Abstract The Digital Europe Program (DEP) is concentrated on bringing digital technology to businesses and citizens in five main areas: High Performance Computing (HPC), Artificial Intelligence (AI), Cybersecurity and Trust, Advanced Digital Skills, and the Deployment and Best Use of Digital Capacity and Interoperability. Thus, defining a rigorous and generic Reference Model that is suitable for every kind of information and data structures within an electronic health record (EHR) is key focus for DEP. Open specifications and clinical models in healthcare applications are often accustomed create and build interoperability solutions, to process safely EHR data that have come from heterogeneous sources. The aim of this paper is to present a model of openEHR standard specification and the use for data representation and exchange about Intraocular Pressure (IOP), which is one of the most vital modifiable risk factor for the event of glaucoma. At this stage the focus is on establishing collaboration between engineers and clinicians, thus the proposed model does not claim to be exhaustive. Keywords openEHR, data representation, data exchange, ophthalmology, intraocular pressure 1. Introduction Technologies are the fastest growing area within the present time. In practice, there’s a widespread trend of knowledge and communication technologies devel- opments and implementation and medicine is not any exception. A wide combi- Information Systems & Grid Technologies: Fifteenth International Conference ISGT’2022, May 27–28, 2022, Sofia, Bulgaria EMAIL: s.velikov@foz.mu-sofia.bg (S. Velikov); 113563@students.mu-sofia.bg (K. Merdzhanov); n.leventi@foz.mu- sofia.bg (N. Leventi); t.kondurdzhiev@foz.mu-sofia.bg (T. Kondurdzhiev) ORCID: 0000-0002-1140-1227 (S. Velikov); 0000-0002-5801-980X (N. Leventi) © 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings (CEUR-WS.org) nation of applications and relevant things are driving towards the rework of the health services delivery. Today, healthcare is directly linked with the utilization of recent information and communication technologies (ICT), and other engineering developments in medical and diagnostic practice, ensuring optimal activities – di- agnosis, treatment, financing, reporting, and information exchange [1]. The pandemic crisis caused by COVID19 has influenced the emergence of applications within the health care sector. Both web-based applications and indi- vidual mobile applications are available. Based on all the mentioned we can see a clear trend that m-Health will cover an increasing share of e-Health. The increase in coverage of 5G networks ends up in rapid implementation of mobile technologies in health services and enhances the impact of m-Health. The fast development of electronics and telecommunication technologies defines new dimensions for the methods and tasks of medication and therefore the role and the tasks of the medical doctor specifically. It is often argued with full force that the introduction of technologies in medicine lags behind their de- velopment. This puts the health profession in front of the requirement to acquire, develop, and master new knowledge and skills to fit in the new information and technological environment. In this paper it will be emphasized the growing use of data and communication technologies in medicine, underlining the need of col- laboration between engineers and clinicians and a cross-disciplinary approach. 2. Standards for interoperability One of the European Union’s (EU) objectives for digitalization is to form one electronic health framework. The aim of the EU framework for e-Health in- teroperability is to define a collection of standards and tools for the presentation of individual elements associated with health and health systems. There are vari- ety of large-scale open platforms implementations supporting millions of patients based on compliance built and supported with the HL7 FHIR, SNOMED CT, openEHR and IHE-XDS standards, delivering open platforms at scale across the world. Below are presented in short a number of standards and their characteris- tics, which are important when considering the representation of clinical content within an open platform: • openEHR is that the only currently available open standard specification for the representation of fine-grained structured clinical content that’s suffi- ciently mature and proven at scale. Thus, it’s the sole contender because the standard for the storage of fine-grained computable data in an open platform. • openEHR encompasses a well-established worldwide community togeth- er with a well-developed set of software tools for creating and maintaining content. This puts openEHR in a superb position to deal with the challenge of making and curating of fine-grained computable content at scale. 127 • openEHR has been adopted as a standard for the representation of clinical content in the Norwegian hospital sector and as a national standard in India, Slovenia and Brazil and is employed for standards development in Australia, Finland, Sweden, Russia, Philippines and Canada [as part of a foundation – defining of open platform][2]. IHE-XDS is an open standard that provides a mechanism designed for shar- ing documents and pictures together with relevant metadata in health and care environment. IHE-XDS provides structures in which data may be stored in open formats and a registry, which stores metadata. Although primarily used for docu- ments and pictures, they may also be used for managing any form of unstructured or semi-structured data. IHE-XDS is well supported by the seller community and has been used at scale in many places both standalone and in combination with openEHR [12]. SNOMED CT – Terminologies play a vital role within the definition of clini- cal content. Here the recognized standard is SNOMED CT, although such a plat- form may have to support other classification systems in order to both support legacy systems’ interfaces and use cases, where SNOMED CT isn’t universally used. Ideally a platform should provide terminology services supporting stan- dard terminologies and locally defined terminologies together with mechanisms to support mappings between them where this is often relevant. SNOMED CT is the first terminology employed in an open platform and plays a vital role in achieving interoperability [13]. HL7 FHIR is a crucial standard primarily concerned with the specification of common open APIs for EHR systems and it should be supported by any open platform implementation. FHIR was designed to support interoperability between systems and focuses on a little number of profiles to support common interoper- ability requirements. It had been not intended as a standard for knowledge reposi- tory of big scale clinical content systems [14]. ISO 13606-2 – EHR communication – Part 2: Archetype interchange speci- fication. Specifies the knowledge architecture required for interoperable commu- nications between systems and services that require or provide EHR data. This part of ISO 13606 isn’t intended to specify the interior architecture or database design of such systems. Uses of healthcare records for other purposes like administration, manage- ment, research and epidemiology, which require aggregations of individual peo- ple’s records, aren’t the main focus of this a part of ISO 13606. This part of ISO 13606 defines an archetype model and it is used to represent archetypes when they are communicated between repositories, and between archetype services. It defines an optional serialized representation, which can be used as an exchange format for communicating individual archetypes. Such communication might, for instance, be between archetype libraries or between an archetype service and an EHR persistence or validation service [15]. 128 Open platforms liberate both data and applications making them portable and interoperable across different platform implementations. Often the extraction of information from such structures has no connection and influence on the way the structure was generated. At best, knowledge analy- sis and retrieval systems could choose between arrays of already accumulated data. The challenge is to construct a mechanism in which data collections are often adapted in terms of modeled results [3]. The somewhat extraordinary boom within the exchange of knowledge on the online, on the order of zetta Byte by 2017, per CISCO [4], brings to the eye of data extraction systems a substantial amount of knowledge. At the identical time, about half the information resulting from medical studies and clinical trials remains unpublished and unrepresented. This is a major issue that needs the at- tention and the collaboration between engineers and clinicians. 3. Data transfer mechanism The mentioned briefly standards HL7 FHIR, SNOMED CT, openEHR and IHE-XDS used in various large-scale open platforms rely on reliable transfer information methods. Such methods strong points vary in many aspects and procedural steps. For the purpose the mechanism of transfer of the information is then realized bidirectional covering the application area needs (see Figure 1). Figure 1: The information transfer mechanism 4. Development of an archetype for Intraocular Pressure (IOP) As pilot field to develop a collaboration schema between engineers and cli- nicians we will use here the case of elevated intraocular pressure (IOP). IOP is a major risk factor for development and/or progression of glaucoma, and IOP 129 reduction is a well-known treatment strategy for slowing the progression of the disease. However, due to the fact that IOP is not a constant value and it is affected by many internal and environmental factors, many glaucoma researchers have conducted studies to characterize its circadian rhythm and short/long-term varia- tions [5]. Research has been done in order to investigate short- and long-term IOP fluctuations and further ocular and demographic parameters as predictors for normal tension glaucoma (NTG) progression [6]. Additional research has been done for the correlation between short-term and long-term intraocular pressure (IOP) fluctuations [7]. In the design and development of archetypes and operational templates, the aim is to use ADL (Archetype Definition Language) and therefore the develop- ment environment to model accurately and very well all possible parameters of the clinical condition in order that it corresponds to the important situation. Good work style also implies the likelihood of information validation at the input stage, which might reduce the likelihood of errors [8, 9, 10]. Archetypes are described in ADL, which is an XML-like language, and oper- ational templates are XML documents prepared in accordance with the openEHR reference model, represented by a set of XML schemas /XSD files in XML for- mat/. Mind map of an example of such archetype is presented in Figure 2. Figure 2: Mind map of IOP test Results 130 An example of a clinical description, expressing the overall interpretation of the clinical observation as a coded text will be described in short. Here are pre- sented only part of the usually used data group of elements, including some of the elements that normally must be part of events, protocol and state sets of elements. Further more, details regarding for example the concrete device used details. For simplicity reasons also the applied in the different cases tonometry methods are not included in the presented set of elements. Taking under consideration the openEHR model [2, 11] and the fact that from a medical point of view pressure is an indicator that’s taken into consider- ation during a standard examination, pressure level archetypes are presented with OBSERVATION type from the openEHR reference model (see Table 1). Table 1 Example of pressure level archetypes presented with OBSERVATION type, and in openEHR reference model pressure level archetypes OBSERVATION type openEHR reference model Left eye [The left eye was ex- Eye examined Identification of the eye under ex- amined.] Coded Text amination. Right eye [The right eye was Optional examined.] Pressure Property: Pressure Quantity Measured intraocular pressure. Arithmetic Units in mm[Hg] Optional Corrected pressure Corrected value for intraocular Quantity pressure. Optional Correction description Narrative description about the Text method used to correct the original Optional intraocular pressure measurement. The time taken for a non-contact Applanation time tonometer to flatten the cornea, Property: Time Quantity used to calculate intraocular pres- Aritmetic Units in ms Optional sure. Single word, phrase or brief de- Clinical interpretation scription that represents the clini- Text cal meaning and significance of the Optional physical examination findings. Comment Additional narrative about the Text measurement, not captured in Optional other fields. Description of any incidental Confounding factors factors related to the state of the Text subject which may affect clinical Optional, repeating interpretation of the measurement. 131 Choice of: Coded Text Goldmann [Goldmann tonom- etry.] Perkins [Perkins tonometry.] Tono-Pen [Tono-Pen tonom- etry.] Tonometry method Icare (Rebound) [Icare (Re- Text Type of tonometery used to mea- bound) tonometry.] Choice sure intraocular pressure. Dynamic Contour [Dynamic Optional Contour tonometry.] Ocular Response Analyzer [Oc- ular Response Analyzer.] TGDc-01 [A TGDc-01 device was used to perform the test.] Non-contact tonometry [Non- contact tonometry was used to perfrom the test.] Device details Details about the tonometry de- Text vice used to measure intraocular Optional pressure. 5. Conclusions COVID-19 During the pandemic lockdown, the virtual medicine trajectory in Europe made substantial progress during a matter of months. Still, the longer- term outlook and lasting impacts remain uncertain. A hybrid model is probably going to be implemented in Europe as certain segments of consumers still value the in-person physician relationships. Also the health care structures don’t seem to be yet ready for full virtual care as a replacement for in-person visits. At the same time, many European countries have updated their regulations and protocol to acknowledge and expand telehealth/telemedicine, opening the doors to more virtual care than ever before. The healthcare system in Europe is facing unprecedented challenges. 5G is positioned to play a critical role in meeting these demands by unlocking the net of Medical Things and providing better, cheaper services and treatment across the continuum of care. This can improve patient outcomes and therefore the lives of European consumers, and provides the healthcare system the resiliency it must face the challenges of our time. The realization of operational compatibility, which might allow integration and inclusion of the realized projects to the general strategy for e-government, is extremely important. The further development and acceleration of such projects and services, caused by the pandemic changes, and the level of their development 132 of the priorities of the national strategy depend on the level of collaboration be- tween engineers and clinicians. The presented work provides a simplified clilnician description pilot model of intraocular pressure as a factor in the development of glaucoma. The proposed pilot model does not claim to be exhaustive, but is an attempt to establish collabo- ration between engineers and clinicians and to present to clinicians opportunities for digitization of clinical information. 6. Acknowledgements This research is supported by the National Scientific Program “е-Health in Bulgaria”, contract number: D01-200/16.11.2018. 7. References [1] I. Patias, V. Georgiev, The Use of Big Data in Medicine and Public Health Policy-Making: Opportunities and Challenges, Proceedings of the thir- teenth International Conference on Information Systems and Grid Technol- ogies (ISGT’2020), Sofia, Bulgaria, May 29–30, 2020, Publisher: CEUR Workshop Proceedings (CEUR-WS.org), 2020, pages: 7–13, ISSN (on- line): 1613-0073. [2] Ivan Stanev, Maria Koleva, Bulgarian Health Information System based on the Common Platform for Automated Programming, Proceedings of the 10th Mediterranean Conference on Information Systems, Publisher: Uni- versity of Nicosia / AISeL 2016, 2016, ISBN:978-9963-711-42-0. [3] Kalinka Kaloyanova, Improving Medical Data Modeling Using Standards (in the book: Knowledge, Languages, Models), ISBN: 978-954-452-062-5, INCOMA Ltd, 2020. [4] Barnett, Th. Jr., The Zettabyte Era Officially Begins (How Much is That), 2016, https://blogs.cisco.com. [5] Song, Y.K., Lee, CK., Kim, J. et al. Instability of 24-hour intraocular pres- sure fluctuation in healthy young subjects: a prospective, cross-sectional study. BMC Ophthalmol 14, 127 (2014). https://doi.org/10.1186/1471- 2415-14-127. [6] Susanne Hopf, Doris Schwantuschke, Irene Schmidtmann, Norbert Pfei- ffer, Esther Maria Hoffmann “Impact of intraocular pressure fluctuations on progression of normal tension glaucoma” INTERNATIONAL JOURNAL OF OPHTHALMOLOGY (OCT 2021), DOI https://doi.org/10.18240/ ijo.2021.10.12 Journal volume & issue Vol. 14, no. 10 pp. 1553–1559 [7] Tojo N, Abe S, Miyakoshi M, Hayashi A. Correlation between short-term and long-term intraocular pressure fluctuation in glaucoma patients. Clin 133 Ophthalmol. 2016;10:1713-1717. Published 2016 Sep 2. doi:10.2147/ OPTH.S116859. [8] Tcharaktchiev D, Krastev E, Petrossians P, Abanos S, Kyurkchiev H, Ko- vatchev P. Cross-Border Exchange of Clinical Data Using Archetype Con- cepts Compatible with the International Patient Summary. Stud Health Technol Inform. 2020 Jun 16; 270: 552–556. doi: 10.3233/SHTI200221. PMID: 32570444. [9] Evgeniy Krastev, Dimitar Tcharaktchiev, Lyubomir Kirov, Petko Kovatchev, Simeon Abanos, and Alexandrina Lambova, “Software Implementation of the EU Patient Summary with Archetype Concepts”, In Proceedings of GLOBAL HEALTH 2019, The Eighth International Conference on Global Health Challenges, Porto, Portugal, from September 22, 2019 to September 26, 2019 pp. 8–13 ISSN: 2308-4553, ISBN: 978-1-61208-742-9. [10] Evgeniy Krastev, Dimitar Tcharaktchiev, Petko Kovatchev, Simeon Aba- nos, “International Patient Summary Standard Based on Archetype Con- cepts” International Journal on Advances in Life Sciences, ISSN 1942- 2660 vol. 12, no. 1 & 2, year 2020, 34:46. [11] openEHR Foundation. What is openEHR. Available at: https://www.opene- hr.org/what_is_openehr, accessed May 2022. [12] Koninklijke Philips N.V., IHE-XDS, IHE XDS: Sharing medical docu- ments across enterprises, https://www.philips.com/interoperability-solu- tions, 2019, accessed May 2022. [13] SNOMED International – the not-for-profit organization that owns and maintains SNOMED CT, https://www.snomed.org, accessed May 2022 [14] Health Level Seven International®, or HL7 – the member-driven nonprofit organization dedicated to creating and maintaining standards that bridge the gap in healthcare technology, https://info.hl7.org, accessed May 2022. [15] ISO 13606-2:2019, Health informatics – Electronic health record commu- nication – Part 2: Archetype interchange specification, https://www.iso.org/ standard/62305.html, accessed May 2022. 134