On the Road to Hospital Digital Transformation:
Using Conceptual Modeling to Express Domain Ontology
Avi Shaked
a
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.
a
https://orcid.org/0000-0001-7976-1942
1
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)
1
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
Copyright
c
2020 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
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
2
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
2
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