On the Road to Hospital Digital Transformation:

Using Conceptual Modeling to Express Domain Ontology

Avi Shaked

Cyber Division, Israel Aerospace Industries, Ashdod, Israel

Keywords: Metamodeling, Ontology, Domain-Specific Models, Digital Transformation, Eclipse Modeling.

Abstract: During the COVID-19 pandemic, Israel Aerospace Industries engaged with hospitals with the goal of

promoting their effective operation by means of digital transformation, and particularly by designing an

information system in support of the hospital operational processes. In this short paper we report our use of

conceptual modeling to capture and communicate the organizational and operational ontology of the

problem domain, based on a requirements specification for the system. We discuss how the derived

ontology relates to metamodeling, and discuss some practical and theoretical implications of using

metamodeling to document ontology.

https://orcid.org/0000-0001-7976-1942

http://hl7.org/fhir/toc.html, last accessed: 17/9/2020.

1 INTRODUCTION

Hospitals in Israel are faced with the need to manage

their operations and resources more efficiently

(Chernichovsky and Kfir, 2019). This has increased

due to the COVID-19 pandemic, with the need to

treat isolated patients with limited means.

Information Technologies (IT) systems play an

enabling role in modern healthcare (Meydan et al.,

2015; Topaz et al., 2020) as well as impact its

organizational structure (Moreno-Conde et al.,

2019). Accordingly, some hospitals expressed

interest in promoting their digital transformation for

treating COVID-19 patients. Israel Aerospace

Industries (IAI) engaged with these hospitals to

utilize its technological and engineering knowledge

for the development of information systems that may

assist the hospitals to operate better.

Information systems rely extensively on data. In

order to effectively communicate the data with

various stakeholders, to produce insights with

respect to the data and to support data-based

collaborative work, data should be well structured

and clear, preferably standardized (Schulz et al.,

2019; Moreno-Conde et al., 2019; Husáková and

Bureš, 2020). The use of ontologies in the

engineering of systems is an enabler of good

knowledge management and is essential to

establishing explicit, sharable, reusable and

interoperable knowledge representations (Yang et

al., 2019; Husáková and Bureš, 2020). Ontologies

also contribute to the explainability of machine

learning models (Panigutti et al., 2020).

Research efforts has produced a multitude of

healthcare related ontologies, such as an ontology

for healthcare technology innovation (Moreno-

Conde et al., 2019), ontologies describing

ubiquitous computing environment for healthcare

(Ko et al., 2007; Kim et al., 2014), ontology for

health care networks (Dieng-Kuntz et al., 2006) and

breast cancer imaging ontology (Hu et al., 2007).

While crucial for the organization of knowledge,

such research derived ontologies typically remain

theoretical. For example, a pertinent ontology for

medical services (Zeshan and Mohamad, 2012),

which was designated to be used by IT systems, has

only been theoretically checked for consistency.

HL7 – a not-for-profit organization – leads a

data standardization effort from a practitioners’

perspective, and its current “Fast Healthcare

Interoperability Resources” (FHIR)

specification

offers some ontology-related concepts. These,

however, are offered from a technical,

implementation point of view, requiring significant

effort to analyse and review for use; and was

deemed inappropriate for addressing the

Shaked, A.

On the Road to Hospital Digital Transformation: Using Conceptual Modeling to Express Domain Ontology.

DOI: 10.5220/0010213602650269

In Proceedings of the 12th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2020) - Volume 3: KMIS, pages 265-269

ISBN: 978-989-758-474-9

265

aforementioned operational challenges rapidly. As

an illustration, in FHIR, a patient relation to a

doctor (“physician” in FHIR terminology) is not

directly expressed but is represented by a relation

between a patient and the more generic entity

“practitioner,” with the doctor being a type of a

practitioner. This relation is directional, from the

patient to the practitioner; meaning that a

stakeholder that wishes to explore the ontological

concepts of a doctor as a practitioner cannot

identify this relation to a patient without exploring

the underlying resource model from a patient

perspective (i.e., the doctor and patient relations is

not accessible from the doctor perspective).

Furthermore, the relations are not graphically

depicted, and this hinders the communicability of

the ontological concepts.

In this paper we share our experience using

conceptual modeling to capture a primal ontology

for hospital operations, while developing a

prototype for a hospital IT system. We demonstrate

a bottom-up approach to defining ontologies, which

– we believe – can encourage and promote their

practicality. In Section 2 we explain our approach.

Then, in Section 3, we introduce the derived

ontology of hospital operations. Finally, in Section

4, we reflect on our conceptual model and the

represented ontology as well as on the advantages

and limitations of our approach, setting the stage for

further research.

2 ONTOLOGY DERIVATION

APPROACH

We approached the derivation of an ontology for

hospital operations primarily by examining a set of

requirements and identifying the relevant ontological

entities and their relationships within this set.

Further details follow.

The requirements set was delivered to us as a

preliminary specification for a hospital management

IT system. While the requirements specification is

considered intellectual property – and therefore

cannot be reproduced here – we address some

relevant aspects. The specification was in Hebrew,

and included three sections: a mission statement,

describing the system’s objectives and a basic

narrative; an illustration referring to the operational

scenario; and a list of high level, natural language

requirements describing both medical and technical

needs.

We – as the development team’s systems

engineering function – reviewed the specification

and attempted to derive relevant domain entities and

their relations. This was done in accordance with a

model-based design approach, which we assumed

for the development of the said information systems.

While some entities and relations were mentioned

explicitly, others were mentioned implicitly, e.g., by

a business process description. Furthermore, during

our analysis of the specification we identified some

additional gaps, implying that some of the domain

knowledge remained tacit, i.e., it was not stated in

the requirements. Whenever deemed critical, we

filled in the gaps, by suggesting additional entities

and relations.

The aforementioned approach was a part of an

overall rapid prototyping approach, which we took

due to the circumstances in question: urging hospital

needs due to the COVID-19 pandemic and the low

availability of relevant hospital personnel to provide

us feedback on system design documentation drove

us to communicate our understanding of the

requirements and its solution on the basis of a

system prototype artifacts, and specifically using a

formal metamodel. We captured the ontology

formally using an ECORE metamodel, which is used

within the Eclipse Modeling Framework for

describing models

based on the standard EMOF

specification (Object, Management Group, 2016).

3 DERIVED ONTOLOGY

The derived hospital operations ontology is

represented in Figure 1, using an ECORE

metamodel. This standardized representation shows

the ontological entities as box nodes colored either

yellow or grey; and their relations using edges

between nodes. Relations take various forms: a

directed arrow with a diamond source depicts

composition, i.e., the source contains the target; a bi-

directional arrow depicts a bi-directional relation;

and a hollow-headed arrow depicts a “type-of”

relationship to depict the source entity is a type of

the target entity. For example, many of the entities

are – each by itself – a type of a general entity,

which is used purely from a modeling perspective to

add generic features (e.g., the “name” attribute,

contained within the “GeneralEntity” box).

Cardinality is marked as a textual tag on the

opposing end of the relation edge (for example:

doctor relations to multiple patients is denoted

Eclipse Foundation website, https://wiki.eclipse.org/

Ecore, last accessed 2020/9/16.

KMIS 2020 - 12th International Conference on Knowledge Management and Information Systems

266

“[0..*] patient”), while the patient’s singular location

is denoted “[0..1] location” (with no location

denoting a location has not been assigned yet).

We identify eight entity types: hospital, location,

health indicator, patient, temperature, medical file,

doctor, and department. While all of these entities

appear explicitly in the requirements specification,

some of these appear using redundant terms.

Specifically, those redundancies (in Hebrew

language) exist in references to the patient (2 terms),

location (4 terms) and doctor (2 terms).

The relations between the entities and their

cardinalities are not as explicit in the specification as

the entities, and specifying many of them involved

interpretation of the specification’s text. Few

exceptions are: 1) temperature is explicitly

mentioned as a type of a health indication; 2)

location is specifically mentioned in relation with

the patient and with the doctor (although the nature

of these relations is not explicitly stated); 3) location

is specifically mentioned as “inside the hospital,”

which, implicitly leads to a composition relationship

(i.e., the hospital has locations); 4) doctors are

implicitly mentioned in one statement as “belonging

to the hospital,” which, implicitly leads to a

composition relationship (i.e., the hospital has

doctors); 5) health indictors and patient are explicitly

mentioned as a construct state, implying a

composition relation, i.e., a patient has health

indicators.

Figure 1: A formal conceptual metamodel representing the

derived hospital ontology (in ECORE Tools).

4 DISCUSSION

A formal ontology is crucial to establishing systems

and specifically to capturing and communicating

related domain knowledge. We used a conceptual

model in the form of a metamodel to a capture

domain-specific ontology for hospital operations,

derived from a requirements specification.

Using a well-defined, standardized conceptual

model was shown to contribute to formalizing

pertinent knowledge, which is intended for use

within an information system. Conceptual entities

were identified and reduced from redundant natural

language terms to singular ontological entities.

Furthermore, relations between entities were both

concretized from somewhat implicit definitions, and

their cardinality was explicitly state. While the

improvement of relationship definitions reflects

design decisions and is therefore subjective, it

promotes ontology related discussion with

stakeholders, specifically with respect to the review,

refinement and/or reconsideration of our design. The

communication of our design decisions with

stakeholders forms a basis not only for the

information system specification, but also for

understanding and possibly even improving

operations. For example, our model depicts a

scenario in which the hospital manages its doctors as

a common resource (expressed by compositional

relation of the hospital in Figure 1) and assigns them

(dynamically) to hospital departments (the bi-

directional relation between “Department” and

“Doctor” in Figure 1). This centralized approach can

be contrasted with an alternative approach, in which

doctors are a dedicated resource of the department.

The conceptual model is a highly communicable

representation of domain knowledge, which can be

used to discuss the ontology with multiple, technical

and nontechnical stakeholders. Furthermore, its

standardized metamodel implementation (using the

EMOF compliant ECORE) forms a basis for a

rigorous information systems implementation. Our

ongoing effort concentrates on developing such an

information system (in Eclipse) while elaborating

and refining the ontology – as new requirements are

specified and analyzed – and by identifying the

required dynamic behavior of the entities (e.g.,

processes).

Our hospital operations ontology – based

exclusively on requirements from a practitioner’s

viewpoint – directly corresponds with the previously

conceived, theoretical ontology for medical services

(Zeshan and Mohamad, 2012). Specifically the

following ontological concepts are common to both

ontologies and are termed identically: “doctor,”

“patient”; and the “health indicator” is also a

common concept, termed “vital sign” by the

ontology for medical services, with both ontologies

On the Road to Hospital Digital Transformation: Using Conceptual Modeling to Express Domain Ontology

267

describing “temperature” as a type of indicator.

Also, both ontologies identify similar relations

between the common concepts: a doctor relates to a

patient, and a patient has health indicators. The

cardinalities of these relations only appears in our

ontology.

Furthermore, whereas the ontology for medical

services is more comprehensive with respect to the

services, our hospital operations ontology includes

other hospital organization related concepts (e.g.,

“location”, “department”, “hospital” and their

relations), corresponding with the need to reflect and

impact organizational structure design and resource

allocations (as suggested by Moreno-Conde et al.

(2019)). The lack in some service related concepts is

likely due to the minimal requirements specification,

which was designed to support the development of a

minimum viable product. We can share that

subsequent requirements sets for our designated

information system include additional concepts that

are common to the ontology for medical services

(e.g., “device”).

Our approach has several limitations. First, the

representation of the ontology using a metamodel

only captures direct relations between entities, and

does not capture nor communicate implicit

ontological relations. Specifically, structural

relations (composition) mask possible behavioral

interactions between the ontological entities. For

example, a particular use case may exist in the form

of a doctor examining a patient’s temperature, and

yet there is no direct relation between “doctor” and

“temperature.” We note that information system

implementations that use our metamodel can support

such interactions (and – thereby – the

implementation of support for such behavioral use

cases), e.g., by allowing a doctor to query all/some

of the patient’s relations. Regardless, we advise

further research to consider enhancing metamodel

representations with behavioral related relations, to

support a more comprehensive representation of

ontologies. Addressing this gap may also facilitate

the development of systems based on metamodels,

reducing the need in some additional behavioral

descriptions – such as sequence diagrams – for

basic, ontology-derived functions. A possible

approach may be in the form of incorporating

explicit ontological relations into a metamodel. For

example, an ontological relation between “doctor”

and “temperature” may be introduced to the

metamodel as a new type of relation. This

ontological relation can then be further specified as a

composition of several metamodel relations: the bi-

directional relation between “doctor” and “patient,”

the compositional relation between “patient” and

“health indicator,” and the type relation between the

latter and “temperature.” This is illustrated in Figure

2, on top of our original metamodel (Figure 1). The

“examines” ontological relation (in dashed blue

arrow) is added to the metamodel, depicting the

doctor ability to examine the temperature. This

suggestion also opens up an opportunity for

verifying the completeness of the conceptual model

based on the ontology. For example, red dashed

arrows in Figure 2 denote the relation trajectory that

implements the aforementioned “examines”

ontological relation: a doctor relates to a patient,

which has a health indicator of type temperature. If,

hypothetically, one of the concrete metamodel

relations was missing, then the composite relation

trajectory from “doctor” to “temperature” could not

have been realized, indicating a gap in the design of

the metamodel.

Figure 2: An illustration of using an ontological layer on

top of a formal metamodel.

Second, with respect to the derivation of an

ontology based on specifications without

considering existing ontologies, a critique may be

raised claiming our somewhat bottom-up approach

can lead to an inflation of domain-specific

ontologies. However, in agreement with a grass

roots approach to modeling (Sandkuhl et al., 2018),

we argue that it is a trade-off to use the ontology and

conceptual modeling as a basis for application, even

if these are proprietary or redundant with respect to

existing ontologies; and that this is preferable to

developing applications without establishing clear

understanding and formal representation of the

pertinent ontology. While existing ontologies may

be used as a stepping stone for identifying domain-

specific ontology, a full investigation and/or

implementation of existing ontologies can be a

examines

KMIS 2020 - 12th International Conference on Knowledge Management and Information Systems

268

hurdle in practice; and this should therefore not be a

barrier for ontology-based engineering (Hu et al.,

2007). In the hospital operations ontology case, for

example, the ontological concept of “device” –

which exists in the ontology for medical services –

was not considered essential for the minimum viable

product prototype. Furthermore, from a technical

implementation point of view, translation

technologies can be used to harmonize different

ontologies, and specifically to translate a uniquely

defined (proprietary) ontology with a standardized

ontology. For example, entities of the hospital

operations ontology can be translated to a standard

definition (e.g., “health indicator” can be translated

to the ontology for medical services’ “vital sign”).

Particularly, with respect to our Eclipse-based

conceptual modeling, the standardized,

automatically generated XMI technical

representation of our metamodel facilitates such

translation capabilities.

REFERENCES

Chernichovsky, D., & Kfir, R, 2019. The State of the

Acute Care Hospitalization System in Israel: The

Current Situation.

Dieng-Kuntz, R., Minier, D., Růžička, M., Corby, F.,

Corby, O. and Alamarguy, L., 2006. Building and

using a medical ontology for knowledge management

and cooperative work in a health care network.

Computers in Biology and Medicine, 36(7-8), pp.871-

892.

Hu, B., Dasmahapatra, S., Dupplaw, D., Lewis, P. and

Shadbolt, N., 2007. Reflections on a medical ontology.

International journal of human-computer studies,

65(7), pp.569-582.

Husáková, M. and Bureš, V., 2020. Formal Ontologies in

Information Systems Development: A Systematic

Review. Information, 11(2), p.66.

Kim, J., Kim, J., Lee, D. and Chung, K.Y., 2014.

Ontology driven interactive healthcare with wearable

sensors. Multimedia Tools and Applications, 71(2),

pp.827-841.

Ko, E.J., Lee, H.J. and Lee, J.W., 2007. Ontology-based

context modeling and reasoning for u-healthcare.

IEICE TRANSACTIONS on Information and Systems,

90(8), pp.1262-1270.

Meydan, C., Haklai, Z., Gordon, B., Mendlovic, J. and

Afek, A., 2015. Managing the increasing shortage of

acute care hospital beds in Israel. Journal of

evaluation in clinical practice, 21(1), pp.79-84.

Moreno-Conde, A., Parra-Calderón, C.L., Sánchez-Seda,

S., Escobar-Rodríguez, G.A., López-Otero, M., Cussó,

L., del-Cerro-García, R., Segura-Sánchez, M.,

Herrero-Urigüen, L., Martí-Ras, N. and Albertí-Ibarz,

M., 2019. ITEMAS ontology for healthcare

technology innovation. Health research policy and

systems, 17(1), p.47.

Object Management Group, 2016. Meta Object Facility

formal specification, version 2.5.1.

Panigutti, C., Perotti, A. and Pedreschi, D., 2020. Doctor

XAI: an ontology-based approach to black-box

sequential data classification explanations. In

Proceedings of the 2020 Conference on Fairness,

Accountability, and Transparency (pp. 629-639).

Sandkuhl, K., Fill, H.G., Hoppenbrouwers, S., Krogstie, J.,

Matthes, F., Opdahl, A., Schwabe, G., Uludag, Ö. and

Winter, R., 2018. From expert discipline to common

practice: a vision and research agenda for extending

the reach of enterprise modeling. Business &

Information Systems Engineering, 60(1), pp.69-80.

Schulz, S., Stegwee, R. and Chronaki, C., 2019. Standards

in healthcare data. In Fundamentals of Clinical Data

Science (pp. 19-36). Springer, Cham.

Topaz, M., Bar-Bachar, O., Admi, H., Denekamp, Y. and

Zimlichman, E., 2020. Patient-centered care via health

information technology: a qualitative study with

experts from Israel and the US. Informatics for Health

and Social Care, 45(3), pp.217-228.

Yang, L., Cormican, K. and Yu, M., 2019. Ontology-

based systems engineering: A state-of-the-art review.

Computers in Industry, 111, pp.148-171.

Zeshan, F. and Mohamad, R., 2012. Medical ontology in

the dynamic healthcare environment. Procedia

Computer Science, 10, pp.340-348.

On the Road to Hospital Digital Transformation: Using Conceptual Modeling to Express Domain Ontology

269