=Paper=
{{Paper
|id=Vol-3191/paper11
|storemode=property
|title=Application of openEHR Platform for Data Exchange in Ophthalmology (short paper)
|pdfUrl=https://ceur-ws.org/Vol-3191/paper11.pdf
|volume=Vol-3191
|authors=Stefan Velikov,Kostadin Merdzhanov,Nikoleta Leventi,Todor Kundurdzhiev
}}
==Application of openEHR Platform for Data Exchange in Ophthalmology (short paper)==
https://ceur-ws.org/Vol-3191/paper11.pdf
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