# Building Interoperable Electronic Health Records as Purpose Driven Knowledge Graphs

Simone Bocca, Alessio Zamboni, Gábor Bella, Yamini Chandrashekar, Mayukh Bagchi, Gabriel Kuper, Paolo Bouquet, Fausto Giunchiglia

► To cite this version:

Simone Bocca, Alessio Zamboni, Gábor Bella, Yamini Chandrashekar, Mayukh Bagchi, et al. Build-
ing Interoperable Electronic Health Records as Purpose Driven Knowledge Graphs. Data Science
and Artificial Intelligence for Digital Healthcare, Springer International Publishing, pp.237-254, 2024,
Signals and Communication Technology, 10.1007/978-3-031-56818-3_14. hal-04741984

HAL Id: hal-04741984

https://hal.science/hal-04741984v1

Submitted on 17 Oct 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Building Interoperable Electronic Health Records as Purpose Driven Knowledge Graphs*

Simone Bocca, Alessio Zamboni, Gábor Bella, Yamini Chandrashekar, Mayukh Bagchi, Gabriel Kuper, Paolo Bouquet, and Fausto Giunchiglia

Department of Information Engineering and Computer Science (DISI),
University of Trento, Italy

**Abstract.** When building a new application we are increasingly confronted with the need of reusing and integrating pre-existing knowledge. Nevertheless, it is a fact that this prior knowledge is virtually impossible to reuse as-is. This is true also in domains, e.g., *eHealth*, where a lot of effort has been put into developing high-quality standards and reference ontologies, e.g. FHIR<fnref n="1" />. In this paper, we propose an integrated methodology, called *iTelos*, which enables data and knowledge reuse towards the construction of *Interoperable Electronic Health Records (iEHR)*. The key intuition is that the *data level* and the *schema level* of an application should be developed independently, thus allowing for maximum flexibility in the reuse of the prior knowledge, but under the overall guidance of the needs to be satisfied, formalized as *competence queries*. This intuition is implemented by codifying all the requirements, including those concerning *reuse*, as part of a *purpose* defined *a priori*, which is then used to drive a *middle-out* development process where the application schema and data are continuously aligned. The proposed methodology is validated through its application to a large-scale case study.

**Keywords:** Interoperable Electronic Health Record · Knowledge and Data Reuse · Knowledge Graphs.

## 1 Introduction

Once upon a time, one would design an application *top-down* starting from the requirements down to implementation, without thinking of the data: they would be generated by the system in production with, at most, the need of initializing them with data from the legacy systems being substituted. Nowadays, more and more, we are designing systems which, at the beginning but also when in production, must be integrated with data coming from other systems, possibly from third parties. Some examples are health systems that integrate personal

<footnote>* This paper is a major extension of the short paper [9]. Sections 1,2,6,7 are completely new while Sections 3,4,5 are major extensions of the work described in [9], largely focused of the application of *iTelos* in the Health domain.</footnote>

<footnote n="1">¹ https://hl7.org/fhir/.</footnote>
data coming from multiple institutions and B2C (Business-to-Consumer) appli-
cations exploiting the big data available on the Web, e.g., open data or streaming
data.

The key aspect of this reuse problem is how to handle the semantic het-
erogeneity which arise any time there is the need to perform data integration
across multiple sources [12]. This problem has been extensively studied in the
past and two main approaches have been proposed. The first is using ontolo-
gies to agree on a fixed language or schema to be shared across applications
[6]. The second is the use of Knowledge Graphs (KGs) and the exploitation
of the intrinsic flexibility and extensibility they provide [15], as the means for
facilitating the adaptation and integration of pre-existing heterogeneous data.
However, the problem is still largely unsolved. When developing an application,
no matter whether one exploits ontologies or KGs, it is impossible to reuse the
pre-existing knowledge as-is. There is always some specificity which makes the
current problem in need of dedicated development, with the further drawback
that the resulting application is, again, hardly reusable.

We propose a general purpose methodology, called *iTelos*, whose main goal is to minimize as much as possible the negative effects of the above phenomenon. *iTelos* exploits all the previous results, in particular, it is crucially based on the use of ontologies and KGs. At the same time, *iTelos* takes a step ahead by providing a precise specification of the process by which an application should be developed, focusing on how to effectively reuse data from multiple sources. *iTelos* is based on three key assumptions:

- the *data level* and the *schema level* of an application should be developed independently, thus allowing for maximum flexibility in the reuse of the prior data and schemas, e.g., ontologies, but under the overall guidance of the needs to be satisfied, formalized as *competence queries*;

- Data and schemas to be reused, as well as competence queries, should be decided before starting the development, as precisely as possible, and defined *a priori* as part of an application *purpose*. Additionally, the purpose is assumed to specify a set of constraints specifying how much the satisfaction of each of its three elements is allowed to influence the satisfaction of the other two;

- the purpose should be used to drive a *middle-out* development process where the successive evolutions of the application schema and data, both modeled as KGs, are continuously aligned *upwards* (bottom-up) with the reference schemas to be reused and *downwards* (top-down) with the data to be reused.

The three assumptions listed above, which are at the core of the *iTelos* methodology, fit well with applications which arise in the *eHealth* domain and in particular in the generation, integration and adaptation of *Interoperable Electronic Health Records* (*iEHRs* for short). First of all, the clear separation between data and schemas is intrinsic to all health applications for at least two reasons. The first is the richness of standards which exist both at the schema level and at the data level (see, e.g., [2,3]). Keeping them separated allows for the incremental
alignment of the KG modeling an iEHR. The second is that it allows for the incremental integration, first of the schemas and then of the data, the latter being much more critical being, differently from the schemas, highly sensible data, subject to very strict privacy rules. Moving to the second assumption listed above, the need for correctness and precision in the eHealth domain, is supported by *iTelos* through the definition of the application *purpose*. The definition of the purpose allows to define precisely which data and schema resources have to be considered for the production of a KG able to represent, and exploit an iEHR. Finally, the third assumption simply provides the guidelines for implementing the incremental generation of iEHRs, mentioned above, enabled by the separation between data and schemas.

The main goal of this paper is to report the lessons learned in the application of the *iTelos* methodology in the Health domain and in particular in the generation of *iEHRs*, as part of the European project *InteroEHRate*<fnref n="2" />. This paper is organized as follows. In Section 2 we provide a description of the purpose and of how it is organized. In Section 3 we provide a highlight of the *iTelos* middle-out process. In Section 4 we provide a detailed description of how *iTelos* enables the reusability of the available data. In Section 5 we describe how *iTelos* enables the sharability and future reusability of the application KG. In Section 6 we provide the main alignment metrics used to ensure that the *iTelos* middle-out process stays within the constraints specified by the purpose. Section 7 describes how *iTelos* has been adopted in the *InteropEHRate* EU project. Finally, Section 8 closes the paper with the conclusions.

<figure><img src="image_2.png" /><figcaption>Fig. 1: The *iTelos* approach.</figcaption></figure>

## 2 The purpose

The *iTelos* process is depicted at a very high level in Figure 1. The logical sequence, represented by the dashed lines, shows the *User* providing in input an informal specification of the problem she wants to solve, the *Purpose*, while receiving in output a KG, named, in Figure 1, the *Entity Graph (EG)*. The concrete

<footnote n="2">² The details of the project can be found at the URL https://www.interopehrate.eu/.</footnote>
process is represented by the four solid lines, indicating how the purpose leads to the reuse of prior knowledge, represented at the data level as *Datasets* and at the schema level as *Ontologies*, with the aim of building the Entity Graph.

The purpose, as the main input of the process, is composed of three elements:

- the functional requirements of the final application, in other words, the information that the final EG must be able to provide to satisfy the user's need. In the concrete example of the IEHR project, these requirements list the medical data to be included in an iEHR. We assume that such needs are formalized as a list of *competency queries (CQ)* [14].

- a set of datasets to be reused as already existing knowledge, thus, in turn, to be integrated into the final EG. A key assumption, as part of the overall *iTelos* strategy, is to handle such datasets as KGs, thus facilitating their future reuse. In the IEHR project, four different hospital partners provided the datasets to be considered for the purpose.

- a set of existing well-known *reference schemas*, i.e., ontologies, but not only, to be reused in order to develop the EG's purpose-specific schema, which can then be shared for future applications. It is important to notice that well-known schemas are already available; for instance, LOV, LOV4IoT, and DATAHUB,<fnref n="3" /> are three among the most relevant repositories. However, for the IEHR project, the reference schemas of the datasets provided by hospitals have been mainly considered with a strong adoption of the FHIR reference ontology. In line with the reuse approach, to support the *iTelos* process, a new repository, called *LiveSchema*,<fnref n="4" /> is under construction, where reference schemas are annotated by a very rich set of metadata, see, e.g., [5,11], with the goal of automating as much as possible the *iTelos* process.

A crucial design decision in the structure of the purpose, which reflects the *iTelos* process structure depicted in Figure 1, is the separation of the data and schema level, by keeping them distinct and independent, as well as modelled as two different types of KG. This major aspect allows splitting the problem of reusing the existing datasets during the integration process from the problem of developing a unique schema for the final EG which can be easily reused in future applications. The KGs considered for the data level, that we call *Entity Graphs (EGs)*, are graphs having *entities* as nodes (e.g., my dog *Pluto*). The entities are composed of data property values used to describe them. The links in the data layer KGs are object properties describing the relations between any two entities. The schema level KGs, instead, are called *Entity Type (etype) Graphs (ETGs)*, namely graphs defining the schema of an EG. Therefore, for each EG there is a corresponding ETG which defines its schema. The nodes of an ETG are *etypes*, namely classes of entities (e.g., the class *dog*). Each etype is described (and actually, represented) by a set of data properties and by a set of object properties, defining the schema of each single etype and the possible relations among them, respectively.

<footnote n="3">³ See, respectively: https://lov.linkeddata.es/, http://lov4iotSpot.com/, https://old.datahub.io/.</footnote>

<footnote n="4">⁴ See: http://liveschema.eu/.</footnote>
*Datasets* and *Ontologies* depicted in Figure 1 are examples of EGs and ETGs, respectively. *iTelos* use EGs to represent: (i) the entity graph produced as the outcome of the whole process (see Figure 1) and, if they are available in this specific form, (ii) the input datasets. The ETGs, instead are exploited to represent: (i) the schema of the final entity graph, (ii) the input reference schemas to be reused, as well as, after a formalization process, (iii) the functional requirements extracted from the initial competency queries. *iTelos* maintains this uniformity of representation in order to exploit, for both data and schema layer, the high capacity of KGs to be composed of each other, as well as to be extended and adapted to different purposes. In line with the underlying approach, these KG features allow *iTelos* to reuse not only existing knowledge but also produce reusable and interoperable data which, in turn, reduces the effort in building future applications.

<figure><img src="image_3.png" /><figcaption>Fig. 2: The *iTelos* Process.</figcaption></figure>

## 3 *iTelos* as a process

Figure 2, freely adapted from [9], describes the key logical phases of the *iTelos* process (dashed line in Figure 1). The process depicted in Figure 2 is articulated in four phases generating an Entity Graph starting from the initial Purpose. The objective of each phase can be synthetically described as follows:

- *Inception*: the purpose, provided in input by the user, is formalized into a set of CQs, as well as used to identify and collect a set of existing, reusable, datasets and ontologies;

- *Modeling*: a purpose-specific model of the ETG is built by taking into account CQs and datasets;

- *Knowledge Alignment*: a reusable ETG is built, based on the model designed previously, by reusing the selected reference ontologies;

- *Data Integration*: the final EG is built by integrating the input datasets into the ETG.
Let us analyze these phases in detail. The *Inception* phase takes the purpose from the user, initially specified as a natural language description of the desired objective. The functional requirements are extracted from the purpose and formalized into a list of CQs. In the *Ontology Collection* and *Dataset Collection* activities, shown in Figure 2, the reusable datasets and ontologies, being part of the purpose, are matched with the CQs in order to select the most suitable resources to build up the final EG. The final collection of data and schema resources may be extended by resources initially not considered in the list provided by the initial purpose. The key observation is that matching CQs and (the schemas of the) datasets is crucial for the success of the project. A little coverage would mean that there are not enough data for the implementation of the EG, therefore a revision of the CQs, or a more refined data collection is required. If the former is the case the process we follow is inspired by the work in [13].

The *Modeling* phase receives in input the ontologies and datasets previously collected, as well as the CQ list. The main objective of this phase is to extract from the CQs a set of etypes, described by their relative properties, which are then used to build up the most suitable model for the ETG to be used as the schema of the final EG, which in Figure 2 is called the *ETG model*. The ETG model designed using the etypes and properties extracted from CQs can be then extended by extra etypes and properties suggested by the datasets. This extension is optional but suggested to allow for future expansions, as well as to increase the reuse of the available datasets. Notice that the availability of data would make this step low cost, in particular, if taken into account since the early stages. The *ETG Modeling* activity aims to design the ETG model by shaping it as an EER diagram, in other words transforming the CQs into the ETG model. In parallel, the *Dataset Selection* activity finalizes the selection of datasets, previously collected, by filtering out those that don't match the ETG model produced.

The *Knowledge Alignment* phase takes as input the ETG model previously generated, plus the selected set of datasets and reference ontologies. The main objective of this phase is to create the ETG for the final EG. The key observation is that the ETG is built to be as much as possible reusable, thus in turn enhancing the shareability of the whole EG. To this end, the input ETG model is itself a possible solution, nevertheless, it fits too much the CQs, by including definitions of etypes and properties less reusable for different purposes. To achieve the desired level of shareability, the more reused etypes and properties taken from the reference ontologies in inputs, are used to build the ETG (called ETG in Figure 2, without losing the purpose-specific semantic structure designed in the ETG model. This step is performed by the *ETG Alignment* activity, implemented via the Machine Learning algorithm described in [11]. The algorithm takes as input the set of reference ontologies and the ETG model while producing in output the final ETG. The resulting ETG is verified for compliance with the input datasets before the final approval. In parallel, the *Dataset Cleaning* activity applies cleaning and formatting operations over the datasets in order to align data types and data formats with the ETG produced.
In the last phase, called *Data Integration*, the inputs considered are the ETG and the datasets previously cleaned and formatted. The objective of this phase is to build the EG by integrating together the schema and data resources handled along the previous phases, according to the initial purpose. A single activity is present in this phase, called *EG Generation*, which aims to merge the ETG and the datasets, by using a data mapping tool called *KarmaLinker*, which consists of the *Karma* data integration tool [17] extended to perform Natural Language Processing on short sentences (i.e., what we usually call *the language of data*) [1]. Using the tool the data values, in the datasets, are mapped over the etypes and properties of the ETG. In this step, the final EG's entities are generated and, whenever they are discovered to be different representations of the same real-world entity, merged into a single valid representation. These activities are fully supported by *Karmalinker*. The process described in this phase is iteratively executed for the list of datasets selected in the previous phase, processed sequentially. The process concludes with the export of the EG into an RDF file.

The key observation is that the desired middle-out convergence, as described in the introduction, has been implemented in two separate sub-processes, executed in parallel within each phase, one operating at the schema level, the other at the data level (blue and green boxes in Figure 2). During this process, the initial purpose keeps evolving building the bridge between CQs, datasets and reference ontologies. To enforce the convergence of this process, and also to avoid making costly mistakes, each phase ends with an evaluation activity (*Eval* boxes in Figure 2). The specifics of this activity are described in Section 6. Here it is worth making two observations. The first is that this evaluation is driven by the non-functional requirements provided by the purpose. The second is that, within each phase, the evaluation aims to verify whether the target of that phase is met, namely: aligning CQs with datasets and ontologies in phase 1, thus maximizing the reuse of existing resources; aligning the ETG model with the datasets in phase 2, thus guaranteeing the success (purpose's specificity) of the project, and aligning ETG and ontologies in phase 3, thus maximizing EG sharability. The evaluation in phase 4 has the goal of checking that the final EG satisfies the requirements specified by the purpose. As from Figure 2, if the evaluation results don't satisfy acceptable thresholds, in any of the steps in which is expected, the process goes back to the evaluation step of the previous phase. In the extreme case of a major early design mistake, it is possible to go back from phase 4 to phase 1.

# 4 Data reuse in iTelos

During the Inception and Modeling phases, iTelos aims at enhancing the reuse of existing resources in order to reduce the effort in building the EG. The main goal of the first two phases, in this perspective, is to transform the specifications provided by the input purpose into the ETG model. The process achieves this objective by following five different steps, along the two phases:
1. initial formalization of the purpose into a list of natural language sentences, each informally defining a CQ;

2. extraction, from each CQ, of a list of relevant etypes, and corresponding properties, thus formalizing slightly more the initial purpose;

3. selection of the datasets whose schema matches the etypes extracted from the CQs in the previous step;

4. generation of the list of etypes and relative properties extracted from the dataset selected previously, by matching them with those extracted from the CQs;

5. construction of the ETG model by using the etypes, and properties, from the previous step.

Most of the work is done during the inception phase, which covers steps 1-4, while step 5 happens during the modeling phase, where the choices made during the previous phase are selected and exploited to build the ETG model. Nevertheless, if the modeling phase’s evaluation doesn’t produce the desired results, there is the opportunity of backtracking in order to fix wrong choices made during the inception phase. With the aim of enhancing the reusability, the key idea is to classify the three types of resources (CQs, ontologies, datasets) handled during the first two phases, into three categories defining how reusable such resources are. Moreover, along the execution of the two phases, the resources are handled through a series of three iterative executions each corresponding to a specific category, following a decreasing level of reusability. The categories are defined as follows (see [9] for a first description of this specific three-level categorization):

*Common*: the resources classified in this category are those used to express aspects that are common to all domains, even outside the purpose-specific domain of interest. Usually, these knowledge resources correspond to abstract etypes specified in *upper-level ontologies* [7], e.g., *person*, *organization*, *event*, *location*, or even etypes from very common domains, usually needed in most applications, e.g., *Space* and *Time*. Etypes and properties classified as common by *iTelos* correspond to what in knowledge organization are called *Common Isolates* [18]. Moreover, *iTelos* classifies as common data resources those that are provided by Open Data sites.

*Core*: the resources classified in the core category express the most core aspects in the purpose-specific domain of interest. The information carried by these resources is fundamental, given its relevance to the purpose, it would not be possible to develop EG without it. Consider for instance the following purpose:

> "There is a need to support the health of European citizens by opening up new ways to access their health data where needed (independently of the specific country's healthcare system). To this end, interoperable health data needs to be produced, by integrating local data from different countries, thus represented through different medical standards and languages."<fnref n="5" />

<footnote n="5">⁵ This example, as well as all the follow-up material, as described below in the paper, has been extracted from the InteropEHRate EU project.</footnote>
In this example, core resources could be those data values reporting patient's health information, like medication details, drugs, medical codes (e.g., Health, interoperability standards of various types). Examples of common resources, instead, are general information about the patient, like name, surname and date of birth, as well as upper-level ontologies that can be found in the repositories mentioned above. It is important to notice that in general, data are harder to find than ontologies, in particular when they are about sensible sectors like healthcare, where personal data is strongly considered.

*Contextual*: the resources classified in this category carry, possibly unique, information of the purpose-specific domain of interest. While the core resources contribute towards having a meaningful application, the contextual ones create added value in the EG developed, by making explicit the difference with respect to the competitors. In the example above, the resources classified as contextual can be the translations of health data which need to be included in the output interoperable health data in order to be exploited in different countries. At the schema level, contextual etypes and properties are those which differentiate the ontologies which, while covering the same domain, actually present major differences. [10] presents a detailed quantitative analysis of how to compare these ontologies. Data-level contextual resources are usually not trivial to find, given their specificity and intrinsic. In the various applications that we have developed in the past, this type of data has turned out to be a new set of resources that had to be generated on purpose for the application under development, in some cases while in production. In the above example, some contextual data resources are the mappings between different medical standards codes. They are not always available, with the direct consequence that the mappings have to be produced on purpose by hand.

The overall conclusive observation is that the availability, and thus the reusability, of resources, and of data in particular, decreases from common to contextual category, or in other words from more infrastructural data to more application-specific data. Moreover, as described in [9], the decrease in reusability goes in parallel with the increase of pre-processing required to create and handle more contextual data.

<table><caption>Table 1: CQs categorized in the three reusability categories.</caption><thead><tr><th>Number</th><th>Question</th><th>Action</th><th>Category</th></tr></thead><tbody><tr><td>1</td><td>Which is the patient's general information reported in the Patient Summary?</td><td>Return the interoperable Patient Summary</td><td>Common</td></tr><tr><td>2</td><td>Which are the medical information for a patient's medication?</td><td>Return the medication information, as well as the code of the involved drugs</td><td>Core</td></tr><tr><td>3</td><td>Which is the international version of an Italian medication?</td><td>Return multilingual interoperable medication information</td><td>Contextual</td></tr></tbody></table>

Let us see an example of how the five elaboration steps listed at the beginning of the section intermix with the three categories above. Table 1 shows some CQs, extracted from the case study introduced above (step 1). Notice how, already in
this step, CQs are categorized as being common, core or contextual (last column) and how this is done after transforming the text from the purpose (left column) into something much closer to a requirement for the EG (central column). Table 2 then reports the etypes and properties extracted from the CQs (step 2). While this is not reported in the table for lack of space, these etypes and properties inherit the category from the CQs. Notice that it is possible to have an etype that is core or common or contextual with properties in all three categories; this being a consequence of the fact that an etype can be mentioned in multiple (types of) CQs.

<table><caption>Table 2: Etypes and properties from the CQs.</caption><thead><tr><td>CQ Number</td><td>Etypes</td><td>Properties</td></tr></thead><tbody><tr><td>1</td><td>Patient, Vital_signs, Care_plan</td><td>Patient_identifier, Name, Surname, Date_of_birth, Blood Pressure, Care_plan_category</td></tr><tr><td>2</td><td>Medication, Drug</td><td>Medication_subject, Medication_date, Drug_identifier, Coding_system, Code_value</td></tr><tr><td>3</td><td>Medication, Translation</td><td>Target_language, Source_language, Medication_dosage zw instruction, Medication_text note,</td></tr></tbody></table>

The next step is to select the datasets (step 3). Let us assume that the dataset used to (partially) answer the queries in Table 1 generates the properties matching the CQs as in Table 3 (step 4). As an example of matching, compare the attribute *CD-ATC* in Table 3 with the property *Code_value* of CQ n°2 in Table 2. Notice how the ordering of the analysis (from common to core to contextual) creates dependencies that may drive the choice of one dataset over another. As an example, *Medication_dosage zw instruction* might be needed as a contextual property, but to properly define it, we also need the core etype *Medication*. Analysing the resources required following such an order over the three reusability categories implies a major usage of more reusable resources. Concluding the process in the first two *iTelos* phases, steps 5 builds the ETG model, reported in Figure 3, containing etypes and properties from the tables above.

<table><caption>Table 3: Dataset's attributes classified according to the reusability categories.</caption><thead><tr><td>Attributes</td><td>Description</td><td>Type</td><td>Category</td></tr></thead><tbody><tr><td>ID-PATIENT</td><td>identifier of a patient into the dataset</td><td>string</td><td>Common</td></tr><tr><td>firstname</td><td>name of a patient into the dataset</td><td>string</td><td>Common</td></tr><tr><td>familyname</td><td>surname of a patient into the dataset</td><td>string</td><td>Common</td></tr><tr><td>CD-ATC</td><td>drug's medical code specified in the dataset</td><td>string</td><td>Core</td></tr><tr><td>beginmoment/date</td><td>date of the medication specified in the dataset</td><td>date-time</td><td>Core</td></tr><tr><td>content/text</td><td>textual information about a medication</td><td>string</td><td>Contextual</td></tr></tbody></table>
## 5 Data sharing in *iTelos*

In the knowledge alignment phase, the main objective is to enhance the shareability of the EG to be produced, by building an ETG that can be shared for different future purposes. The approach followed by *iTelos* in order to achieve such a shareability is to build the ETG by reusing as much as possible the etypes and properties coming from well-formed standard reference ontologies, but under the overall guidance of the ETG model previously built. While the ETG model keeps the generation of the ETG focused on the initial purpose, the exploitation of reference ontologies improve the possibility to share it in different domains, where such ontologies are already involved in. The key observation is that the alignment mainly concerns the common and, possibly, the core types with much smaller expectations on contextual etypes. Notice that, in retrospect, the alignment with the most suitable ontology can enable the reuse of the data produced. As an example, the selection of FHIR⁶ as the reference ontology for medical data, ensures the compliance of the ETG produced with a huge amount of healthcare information which is already structured using FHIR. This type of decision should be made during the inception phase; if discovered here, it might generate backtracking.

*iTelos* implements the construction of a shareable ETG by adapting the *Entity Type Recognition (ETR)* process proposed in [11]. This process happens in three steps. The first step is the selection of ontologies. This step aims at selecting the set of reference ontologies that best fit the ETG model. As from [11], this selection step occurs by measuring each reference ontology according to two metrics, which allow:

- to identify how many etypes of the reference ontologies are in common with those defined in the ETG model, and

- to measure a property shareability value for each ontology etype, indicating how many properties are shared with the ETG model etypes.

The output of this first step is a set of selected ontologies that best cover the ETG model, and that have been verified to fit the dataset's schema, at both etypes and etype properties levels. The second step is the *Entity Type Recognition (ETR)*. The main goal of this step is to predict, for each etype of the ETG model, which etype of the previously selected ontologies, analyzed one at a time, best fits the ETG. In practice, the ETG model's etypes are used as labels of a classification task. Such execution, as mentioned in [11], exploits techniques that are very similar to those used in ontology matching (see, e.g., [8]). The final result for this step is a vector of prediction values, returning a similarity score between the ETG model's etypes and the selected ontology etypes. The third step is the *ETG generation*. This step identifies, by using the prediction vector produced in the previous step, those etypes and properties from the reference ontologies which will compose the final version of the ETG. It is important, in this activity, to preserve the mapping with the datasets' schemas; whenever this is problematic, this becomes a possible source of backtracking.
<figure><img src="image_4.png" /><figcaption>Fig. 3: Portion of ETG model.</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>Fig. 4: Portion of the FHIR reference ontology.</figcaption></figure>

The distinction, among common, core and contextual etypes and properties, as well as their processing order, plays an important role in this phase and can be articulated as follows:

- The common etypes should be adopted from the reference ontology, in percentage as close as possible to 100%. This usually results in an enrichment of the top level of the ETG model by reusing existing representations of general cross-domain etypes (e.g., *thing*, *product*, *event*, *location*) that are usually less considered by developers due to their abstract nature, but which are fundamental for building an ETG, having all properties positioned in the right place, that can be shared among different domains and for different purposes. Moreover, this allows for a cross-domain alignment of those *common isolates* (see Section 4) for which usually a lot of (open) data are publicly available (e.g., *street*);

- The core etypes are tentatively treated in the same way as common etypes, but the results highly depend on the reference ontologies available. Think for instance of the FHIR example above;

- Contextual etypes and, in particular, contextual properties are those most difficult to be found in existing reference ontologies. For this reason, such etypes and properties are mainly used for the high-level selection among the available ontologies, more than for the selection of single etypes inside those ontologies [11].

<footnote n="6">⁶ http://hl7.org/fhir/</footnote>
As an example of the process described above, compare the portion of ETG model as from Figure 3, with the portion of the FHIR reference ontology in Figure 4.<fnref n="7" /> As it can be noticed, the FHIR etypes *MedicationStatement*, *Medication* and *Patient* can be matched to the ETG model etypes *Medication*, *Drug* and *Patient*, respectively. As a consequence of such a matching, *iTelos* adopts the FHIR etypes and properties to compose the final version of the ETG. It is important to notice how the contextual etype, called *Translation* in the ETG model, don't have any reusable counterpart in the FHIR reference ontology. For this reason, such a purpose-specific etype is taken from the ETG model to be part of the final ETG.

# 6 Alignment Evaluation

The evaluation activities implemented in the *iTelos* process (see Section 3) are based on a set of metrics applied to the intermediate outputs of the different phases, such as CQs, ETG and datasets, as well as to the final EG. For lack of space, below we describe only the application of three metrics to the specific phases in which they are exploited. In order to describe the evaluation metrics, let $\alpha$ and $\beta$ be two generic *element* sets, where an element can be an etype or a property. We have the following:

*Coverage*. This metric is used to measure the overlap between two element sets. In detail, how many etypes and properties can be found in both the sets are analyzed. Such an evaluation is computed as the ratio between the intersection of $\alpha$ and $\beta$ and the whole $\alpha$.

$$Cov = (\alpha \cap \beta)/\alpha \qquad (1)$$

For instance, during the inception phase (*Eval(a)* in Figure 2), *Cov* plays a central role in evaluating the *reusability* of potential datasets (via dataset schemas) with respect to the CQs. For each dataset, a high value of *Cov*, both applied to etypes and properties, implies that the dataset is highly appropriate for the purpose. A low value of *Cov* implies minimal overlap between the purpose and the dataset, the consequence being non-consideration of the dataset for reuse, and possible modification of the (underspecified) CQs.

*Extensiveness*. This metric quantifies the proportional amount of knowledge provided by any element set (such as $\beta$), in terms of sets of etypes or sets of properties, with respect to the entire knowledge considered (here $\alpha$ and $\beta$)

$$Ext = (\beta - (\alpha \cap \beta))/(\alpha + \beta) - (\alpha \cap \beta)) \qquad (2)$$

During the Modeling phase (*Eval(b)* in Figure 2), the evaluation utilizes *Ext* to measure how much the ETG model extends the set of CQs, with the objective of building the most suitable model for the purpose. To that end, a high value of *Ext* is evaluative of the fact that the ETG extends the scope of the CQs,

<footnote n="7">⁷ In the InteropEHRate project, reported as a use case in this paper, the matching between FHIR and the ETG model has been done manually.</footnote>
by indicating a limited contribution of the CQs in generating the ETG model. On the other hand, low values of Ext are evaluative of the fact that CQs have contributed significantly towards the construction of the ETG model.

*Sparsity.* This metric quantifies the element-level difference between any number of similar element sets and is defined as the sum of the percentage of α not in β, and vice versa.

$$ Spr = ((\alpha + \beta) - 2(\alpha \cap \beta))/(\alpha + \beta) - (\alpha \cap \beta)) \quad (3) $$

In the knowledge alignment phase (Eval(c) in Figure 2), our principal focus is to utilize *Spr* for ensuring the *shareability* of the ETG. We incrementally enforce shareability by ensuring a required threshold of *Spr* between the ETG and each of the reference ontology. Such a threshold indicates that the ETG contains axioms reflective of *contextual knowledge*. Nevertheless, this evaluation aims at maximizing the adoption of reference ontology's knowledge for common and core elements.

All the above metrics operate at the schema level. But they do not say anything about the results of integrating the datasets as caused by the semantic heterogeneity existing among them. Let's assume the following situation, in order to describe the data level evaluation criteria adopted by *iTelos*. Using *Karma-Linker*, we are going to integrate a new dataset $D_1$ into a partially built EG. Moreover, $D_1$ has an etype $E_1$, with its property set $A_1$ and the EG already contains an etype $E_2$, with its property set $A_2$. Then we have the following possible situations:

- ($E_1 = E_2$) The etype $E_1$ in $D_1$ is already integrated in the EG. As a consequence of integrating $D_1$ into the EG, there is an increase in the number of entities represented through the etype $E_1$, and the EG, after the integration, will be enriched by the connections of the new entities. Nevertheless, this situation includes two different sub-cases: (i) When $A_1 = A_2$, i.e., the two etypes share the same set of properties, conflicts (different values for the same property) are possible between the value set of $A_1$ and $A_2$. In this case, *iTelos* aims at identifying how many of such conflicts appear during the integration, as well as the number of properties remaining without a value (null or insignificant value) as a result of the integration. (ii) In the second sub case, i.e., $A_1 \neq A_2$, the two etypes have different sets of properties. As a consequence, there are no conflicts between the value set of $A_1$ and $A_2$, and we obtain a greater integration over the entities of $E_1$.

- ($E_1 \neq E_2$) The etype $E_1$ in $D_1$ is not yet present in EG. The consequence is that by integrating $D_1$ into the EG, we are increasing the number of etypes (and of the entities of such an etype) in the final EG. Once again, in this situation, we can differentiate two sub-cases: (i) When $E_1$ and $E_2$ are linked by at least one object property, the resulting EG, after the integration of $D_1$, will be a connected graph. In this sub-case, *iTelos* aims at evaluating the level of connectivity of the graph by identifying how many entities of $E_1$ have not null values for the object properties linking $E_1$ with the rest of the EG's entities. In the second sub-case, there are no object properties linking
$E_1$ and $E_2$ (or $E_1$ with any other etype in EG). As a consequence, the EG after the integration of $D_1$, will not be connected and the information carried by $D_1$ cannot be reached navigating the EG. Therefore, the integration of $D_1$ doesn't increase the EG's connectivity.

The data driven criteria briefly introduced above are crucial for the evaluation of the quality of the final EG. At the moment, these characteristics of the EG have been evaluated by considering the above criteria during the process as well as over the final EG. However, a more precise set of metrics for the evaluation of the quality of the final EG is under definition.

# 7 The InteropEHRate case study

The *iTelos* methodology has been applied to the InteropEHRate EU project. The objective of the project was to keep European citizens fully in control of their own medical data. To achieve this goal, the partners put their focus on two key aspects:

1. To support the citizens and healthcare practitioners through a cross-country digital health infrastructure, composed of mobile applications as well as hospital and third-party digital services [16]. Nevertheless, such an infrastructure is not sufficient to completely achieve the objective of the project.

2. The second key aspect considered in the project was the production and exploitation of interoperable Electronic Health Records (iEHRs). An iEHR is a medical data resource that can be exploited by citizens and healthcare practitioners (as well as researchers), regardless of the European country they are in, even if the country is different from what they are used to living. In detail, IEHR aims at aligning the heterogeneity currently present in medical data of different countries (or even within a single country) into a single multilingual data format (adopting the FHIR medical standard) easily exploitable in Europe thanks to the infrastructure provided by the project.

In the context described above, *iTelos* has been exploited for the integration of local medical data coming from different European countries. In detail, some test sets of local data provided by four different hospitals located in Italy, Belgium, Romania, and Greece, respectively, have been used as input for the methodology, together with their reference schemas. The main problem to be solved, dealing with such local data, was the high level of heterogeneity between the data provided. A concrete example was the differences between the data provided by the Italian hospital, expressed using the HL7-CDA standard <fnref n="8" />, and the Belgian hospital's data expressed through a Belgian medical standard called *SumEHR*<fnref n="9" />. The CDA data are structured in XML format, while the SumEHR are instead JSON files using different attributes to express the same medical information.

<footnote n="8">⁸ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</footnote>

<footnote n="9">⁹ https://www.ehealth.fgov.be/standards/kmehr/en/transactions/summarised-electronic-healthcare-record-v20</footnote>
Another major difference, between the two kinds of data, concerns the medi-
cal coding system adopted by the different standards. While the CDA supports
the LOINC<sup>10</sup> codes, the SumEHR uses a local coding system not recognized
outside Belgium. Moreover, as described in [3], another issue to be considered,
in such a context, is the natural language heterogeneity leading to the need to
produce multilingual iEHRs. As the main input regarding the schema layer, the
FHIR medical ontology has been adopted as the reference ontology for the con-
struction of an ETG structuring a KG able to maintain iEHRs. *iTelos* has been
implemented in the project, by a semi-automatic process of building a KG able
to maintain an interoperable and multilingual version of the local information
provided by the involved hospitals. The data, extracted from such a KG, form
iEHRs satisfying the project's requirements.

During the final phase of IEHR, the project's pilots have been executed to
test, in real-case scenarios, if the project's results have been able to meet the
initial requirements. From the partners involved in the pilots, we collected feed-
back, which helped us to understand some strengths and weak points regarding
the methodology applied in the IEHR context. The descriptions of such feedback
are reported below:

- (Strength) The methodology, thanks to its focus on the reuse of existing data, helped in discovering data heterogeneity, over the medical data, between different countries, as well as in finding solutions to make such data interoperable within Europe. During the project, some suggestions, about how to improve the FHIR standard for a better level of interoperability, have been submitted to the HL7 association.

- (Strength) The mapping between local and international knowledge, and data, existing resources are onerous to bootstrap but lightweight to maintain. In other words from a methodological point of view, a good modeling phase is hard to be executed, but it leads to building KGs easy to maintain and evolve. This enforces the reuse and share approach adopted by *iTelos* in building KG.

- (Weakness) The input standards knowledge and the support of the tools, provided by *iTelos*, are necessary but not sufficient. In the healthcare domain, the need for precision and correctness in producing and converting data from one context to one another (local to international) always requires human supervision.

- (Weakness) The required human intervention limits the scalability of system-
atic approaches for KGs building. To this end, the *iTelos* methodology needs
to be improved in order to provide the highest level of (semi)automation with
the least human intervention required.

<footnote n="10">10 https://loinc.org/</footnote>
# 8 Conclusion

In this paper we have introduced *iTelos*, a novel methodology for the creation of purpose-specific KGs, adopting a *circular* development process. By this, we mean that the implicit goal of *iTelos* is to enable the development of KGs via the *reuse* of already existing resources, thereby, reducing the effort in building new data (KG based) which can be, in turn, highly *reused* by other applications in future. Further, we have also described how *iTelos* has been used in the context of the InteropEHRate EU project, with the objective of producing multilingual iEHRs.

# Acknowledgements

The research described in this paper was supported by the InteropEHRate project, a project of the EC Horizon 2020 programme, grant number 826106. We thank all the people from the University of Trento who supported us in the execution of this project, in particular: Danish Asghar Cheema, Ronald Chenu Abente. The acronym IEHR from the InteropEHRate project, has been freely adapted in this paper as iEHR which stands for *interoperable Electronic Health Records*.

# References

1. Bella, G., Zamboni, A., Giunchiglia, F.: Domain-based sense disambiguation in multilingual structured data. In: DIVERSITY Workshop at ECAI 2016 (2016)

2. Bella, G., Elliot, L., Das, S., Pavis, S., Turra, E., Robertson, D., Giunchiglia, F.: Cross-border medical research using multi-layered and distributed knowledge. In: Proceedings of Prestigious Applications of Intelligent Systems (PAIS@ECAI). Santiago de Compostela, Spain (2020)

3. Bocca, S., Bella, G., Giunchiglia, F.: Interoperating vocabularies in multilingual domain data. In: International Workshop on Vocabularies, Ontologies and Rules for the Enterprise (VORTE) (2022)

4. Bouquet, P., Giunchiglia, F.: Reasoning about theory adequacy. A new solution to the qualification problem. Fundamenta Informaticae 23(2, 3, 4), 247–262 (1995)

5. Dutta, B., Nandini, D., Shahi, G.K.: Mod: metadata for ontology description and publication. In: International Conference on Dublin Core and Metadata Applications. pp. 1–9 (2015)

6. Ekaputra, F., Sabou, M., Serral Asensio, E., Kiesling, E., Biffl, S.: Ontology-based data integration in multi-disciplinary engineering environments: A review. Open Journal of Information Systems 4(1), 1–26 (2017)

7. Gangemi, A., Guarino, N., Masolo, C., Oltramari, A., Schneider, L.: Sweetening ontologies with dolce. In: International Conference on Knowledge Engineering and Knowledge Management. pp. 166–181. Springer (2002)

8. Giunchiglia, F., Autayeu, A., Pane, J.: S-match: an open source framework for matching lightweight ontologies. Semantic Web 3(3), 307–317 (2012)
9. Giunchiglia, F., Bocca, S., Fumagalli, M., Bagchi, M., Zamboni, A.: Popularity driven data integration. In: Iberoamerican Knowledge Graphs and Semantic Web Conference. pp. 277–284. Springer (2022)

10. Giunchiglia, F., Fumagalli, M.: Teleologies: Objects, actions and functions. In: ER - International Conference on Conceptual Modeling. pp. 520–534 (2017)

11. Giunchiglia, F., Fumagalli, M.: Entity type recognition – dealing with the diversity of knowledge. In: Knowledge Representation Conference (KR). Rhodes, Greece (2020)

12. Giunchiglia, F., Zamboni, A., Bagchi, M., Bocca, S.: Stratified data integration. In: 2nd International Workshop On Knowledge Graph Construction (KGCW), Co-located with the Extended Semantic Web Conference (ESWC) 2021. Online (2021)

13. Grüninger, M.: Ontology validation as dialogue (2019)

14. Grüninger, M., Fox, M.S.: The role of competency questions in enterprise engineering. In: Benchmarking—Theory and practice, pp. 22–31. Springer (1995)

15. Kejriwal, M.: Domain-specific knowledge graph construction. Springer (2019)

16. Kiourtis, A., Mavrogiorgou, A., Mavrogiorgos, K., Kyriazis, D., Graziani, A., Symvoulidis, C., Bella, G., Bocca, S., Torelli, F.: Electronic health records at people’s hands across europe: The interopehrate protocols. In: pHealth 2022, pp. 145–150. IOS Press (2022)

17. Knoblock, C.A., Szekely, P.: Exploiting semantics for big data integration. Ai Magazine 36(1), 25–38 (2015)

18. Ranganathan, S.R.: Prolegomena to library classification. Asia Publishing House London, 3rd ed. edn. (1967)