Building an Indoor Digital Twin—A Use-Case for a Hospital Digital Twin to Analyze COVID-19 Transmission

Abstract

As indoor space becomes more important in our daily life, the demand to build digital twins for indoor spaces is increasing accordingly. The properties of indoor spaces, however, differ from those of outdoor spaces, and we need to apply different approaches to build indoor digital twins. In our work, we propose a framework for building an indoor digital twin with a use case for hospitals in general and large hospitals in particular, which may be considered as one of the most complicated types of digital twin. One of our goals is to establish a framework for building indoor digital twins based on standards and our framework starts from OGC IndoorGML, which is a standard for indoor data models and encoding schemes for indoor spatial data. In this paper, each step of the framework is presented for the construction of an indoor hospital digital twin focusing on a use case of epidemic analysis of COVID-19 transmission in a hospital. The use case study covers the entire life cycle of the indoor spatial application from requirement analysis, data modeling, and building indoor spatial data to the development of a COVID-19 transmission analysis. Our work represents a use case for indoor digital twins based on the OGC IndoorGML standard and eventually may serve as a framework and reference for building indoor digital twins. As our work is mainly focused on the construction of hospital digital twins, the study on COVID-19 infection model itself is limited in this paper. Improvement of the infection models and validations will be the next step of our work. As HVAC (heat, ventilation, and air conditioning) was not fully considered in our use case, we also expect that it is possible to strengthen our use case by including HVAC for the analysis of airflow dynamics.

1. Introduction

As the demand for digital twins and smart cities increases, there is also a growing need for concrete methods of building and managing detailed applications. Among these, the importance of digital twins for indoor spaces is particularly growing due to urbanization and increasing complexity of indoor spaces, which have several different characteristics compared to outdoor spaces. The technology of spatial information and GIS, which has developed mostly focusing on outdoor spaces, must be extended to indoor spaces, and various application fields should be developed reflecting the characteristics of indoor spaces.

However, since indoor spaces have many different characteristics from outdoor spaces, the methodologies for outdoor spaces cannot be directly applied. The entire process of building data and developing and managing application services differs from the methodologies of spatial information targeting outdoor spaces. In particular, the application process of spatial information standards to ensure interoperability is significantly different from that for outdoor spaces. The OGC has published IndoorGML, a standard data model specifically targeting indoor spaces. However, IndoorGML is merely a standard for data models and encoding schemes, and it does not provide sufficient support from the perspective of developing and utilizing applications. In other words, there is a gap between IndoorGML and the utilization of indoor spatial information, necessitating methodologies for building and utilizing IndoorGML-based systems.

The main research questions for our work are focused on how to bridge the gap between IndoorGML and the requirements of practical applications and the establishment of a reference framework for constructing digital twin for indoor spaces. In this context, this study introduces a framework for building indoor digital twins and presents a use case based on IndoorGML. The use case selected in our study is a digital twin for a hospital, chosen for the following reasons: first, it is one of the most complex indoor spaces; and second, a wide range of indoor space services are provided, making it suitable for developing a methodology that covers the entire process of building and managing indoor spatial data and applications. The key contribution of this paper is to present the entire process of building an indoor digital twin for a hospital, providing a framework that can be referenced for building indoor digital twins. Specifically, it has the following contributions:

• A framework for building indoor digital twins with OGC IndoorGML.
• A reference use case for designing spatial data of indoor digital twin, called Indoor-H as an extension of OGC IndoorGML to meet the requirements from hospitals, and building and validating indoor spatial data for Indoor-H.
• A COVID-19 infection analysis tool as a service use case for this digital twin.

While our use case includes specific infection models of COVID-19, the infection model itself is not the main focus of our work and needs to be elaborated on and validated. Eventually, the COVID-19 infection models employed here may be replaced by more accurate models. The focus of our work is to study how to develop a framework for a hospital digital twin that supports the infection models. This framework can be used as an important reference case not only for digital twins for hospitals but also for digital twins targeting most indoor spaces. The rest of the paper is structured as follows. Section 2 reviews related researches and presents the motivations of our work. In Section 3, we propose a framework based on OGC IndoorGML for building indoor digital twins. The requirements are analyzed for indoor digital twins for hospitals in Section 4, focusing on two applications: COVID-19 infection spread analysis and mobile asset management. In Section 5, we define the indoor spatial data specifications for a hospital digital twin by extending OGC IndoorGML. We present the way in which IndoorGML data for the use case have been built in Section 6 and our application for analyzing COVID-19 transmission within a hospital in Section 7. This paper is concluded in Section 8.

2. Related Works and Motivations

2.1. Related Works

The research on digital twins of indoor spaces is more limited compared to that of outdoor spaces. In [1,2], the results of studies on the construction of digital twins of indoor spaces from the perspectives of disaster response and safety management have been thoroughly analyzed. Specifically, the authors detail the research on digital twins using BIM (Building Information Modeling). Ref. [2] proposes a framework that combines IoT, BIM, and the recently advancing artificial intelligence with the digital twin of indoor spaces and introduces the ISMS (Indoor Safety Management System) as a use case based on this framework. In this framework, the interface between the real world and the virtual world is implemented through 3D modeling like BIM, IoT data, and AI functions, and it is structured to provide services via Web technology. However, this framework remains at an abstract level, conceptually structured but without presenting specific methodologies, leaving the rest to be resolved during the actual implementation process.

Most studies on indoor digital twins focus on specific application fields. For example, ref. [3] introduces a case study on building a digital twin to analyze the movements of robots and humans indoors, while ref. [4] presents a case for using digital twins to manage indoor air quality. Ref. [5] deals with the application of digital twins in optical design for indoor farming. Similarly, ref. [2] introduces a digital twin case for indoor disaster response.

Refs. [6,7,8] comprehensively introduce cases of digital twins for hospitals and healthcare. These include not only digital twins for hospitals but also various digital twin examples for healthcare. A hospital digital twin is a type of indoor digital twin and must provide specific functions required by hospitals. Various studies and use cases have been developed, for example, ref. [9] presents a comprehensive use case. This research builds the indoor space of a typical digital twin based on BIM and introduces use cases that additionally support functions and services in hospitals. Ref. [10] also introduces a case study called HispiT’Win, which constructs a digital twin for hospitals to track patients’ movements and patterns within the hospital, allowing for appropriate action. Refs. [11,12] present proof-of-concept cases applying a real-time digital twin to Shanghai Municipal Hospital, focusing on real-time monitoring of patients and hospital logistics.

These studies introduce various use cases for hospitals and healthcare. However, none of these studies presents a framework based on standards. Most indoor digital twins are located in complex buildings and building an effective digital twin requires the use of resources such as BIM (Building Information Modeling), 3D city models, or indoor space models. Standards play a crucial roles in using BIM, 3D city models, and indoor space models as standard exchange data formats but also as the basis of data models and data specifications. For example, IFC (Industrial Foundation Classes) as a standard of BIM [13], CityGML by the OGC (Open Geospatial Consortium) [14] for 3D city models, and OGC IndoorGML, a data model and exchange standard for indoor spaces, have all been proposed as well as other standards for indoor spaces introduced in [15,16,17]. This study intends to use IndoorGML as the base standard, and the reasons for this will be explained in Section 2.2.

The use case of this study is a digital twin for analyzing the spread of respiratory diseases in hospitals. Therefore, research on the spread of infectious diseases [18,19] serves as an important starting point. In these studies, the transmission of COVID-19 is classified into three models: Person-to-Person (P2P), Person-to-Air (P2A), and Person-to-Surface (P2S). These three models are crucial for analyzing the transmission of COVID-19, and this study also develops analysis models and tools based on these three models. The requirements for a digital twin to apply these three models were analyzed, and the results were implemented. Notably, ref. [20] is a study on the spread of infectious diseases in indoor spaces. The authors developed a system for tracking the indoor transmission of COVID-19 by applying the P2P and P2A models using IndoorGML standards, although they did not include P2S transmission. In our work, we included the P2S model in addition to the P2P and P2A models.

To accurately analyze the transmission of COVID-19, it is necessary to have analytical models for all three transmission types. Many studies have been conducted on each type. The P2P transmission model via droplets is well explained by [21,22,23], while studies like [21,22,24] present the P2A transmission model via aerosols. Refs. [25,26] applied computational fluid dynamics (CFD) for accurate simulation of COVID-19 virus spread in an aircraft cabin and a concert hall. However, these works are limited to a single closed space and did not include an entire indoor space such as a hospital. For P2S transmission via surface contact, the probability of transmission varies depending on the material of the surface being contacted. Ref. [27] analyzed the survival period of the COVID-19 virus and transmission probability based on the characteristics of the material.

2.2. Motivations

The purpose of this study is to build an indoor digital twin based on the data model provided by standards, which differs from the studies reviewed earlier. Specifically, the study aims to propose a methodology for constructing indoor digital twins based on OGC IndoorGML, which includes a fundamental standard model for indoor spaces. We have selected OGC IndoorGML among several standards covering indoor space such as IFC [28] and CityGML [29] because it meets the requirements of our use case that it supports 3D indoor data models as well as the navigation network model. IFC and OGC CityGML support 3D building and indoor models, however, the navigation network model is not included as a native model. Although OGC IndoorGML provides a basic data model for indoor space data, additional specifications need to be created by incorporating the requirements from each application domain for practical use. To address this issue, this study seeks to bridge the gap between OGC IndoorGML and digital twins for indoor applications. The objectives of our study are summarized as follows;

• To develop an OGC IndoorGML-based use case of an indoor digital twin for a hospital focusing on COVID-19 transmission analysis.
• To provide a reference framework for an OGC IndoorGML application to build indoor digital twins. As OGC IndoorGML is a standard for indoor space modeling, which provides a generic spatial framework for indoor digital twins, we aim to build a reference framework for indoor digital twin applications based on a use case of a hospital.

It is worth noting that discovering the COVID-19 infection model itself is not within the scope of our work although several infection models are studied in our work. They are only for deriving the requirements of the digital twin and may be replaced with alternative models if necessary.

3. A Framework for Building OGC IndoorGML-Based Indoor Digital Twins

For the reason of simplicity, we have chosen the waterfall model [30] as the framework for the data construction process for our digital twin. The waterfall model is the most classic software development life cycle model and suitable for application to the development of systems for which procedures are relatively well-established such as indoor spatial digital twins. It is, however, possible to apply other software development life cycle models such as the V-model [31], or spiral model [32] and we leave the choice of life cycle model as a future work. The framework that we propose in the paper is shown in Figure 1.

In our framework, the phases for system requirements, software requirements, and requirement analysis of the original waterfall model are merged into a requirement analysis of an indoor digital twin in the proposed framework. The reason for this is that, unlike software development, there is no need to distinguish these phases in the construction of a digital twin, as they refer to the same task.

There are two key points to note in this requirement analysis phase. The first is the presence of indoor points of interest (PoIs) and indoor facilities. Since indoor PoIs and facilities are not explicitly included in the model in OGC IndoorGML, it is necessary to incorporate the required indoor PoIs and facilities by reflecting these in the requirements. The second point to note is indoor positioning. Most indoor digital twins require indoor positioning functionality and explicit requirements for this need to be included.

In the design phase, the first issue to focus on is to define extensions to IndoorGML. IndoorGML only provides the core and navigation modules, which are not sufficient to fully express the requirements of a given application. Therefore, based on the requirement analysis, it is necessary to define an extended data specification on the top of IndoorGML. Generally, there are two main methods to define extensions from IndoorGML. The first method is to define a subclass to include additional associations or properties to the classes provided in IndoorGML to meet the required details of an application. For example, we may define a subclass of CellSpace [15], which is one of basic feature type in IndoorGML, by adding required properties. The second method is to include associations from external object types to a class in IndoorGML. For example, if we need detailed information on a room where a piece of medical equipment is located, we navigate via the reference to the CellSpace to obtain the information.

The second design issue involves the selection of tools and environments to build the data represented by the extension of IndoorGML. If there are no tools available to directly construct the required objects for the target application, a simple editing tool may need to be developed, or conversion tools can be used to reflect the necessary information. For the rest of the phases of the framework shown in Figure 1, we will discuss them in subsequent sections together with the use case.

The use case experiment starts with the requirement analysis. This step is crucial as it provides essential inputs for designing the overall data construction, infrastructure installation, service development directions, and the validation of the data. The next stage involves designing the data specifications based on the analyzed requirements, which is performed by extending OGC IndoorGML. This extended data model is called Indoor-H. Indoor-H precedes two main tasks. First, data is constructed based on Indoor-H. Second, Indoor-H is used to define the inspection criteria for data validation.

Separate from Indoor-H, building a digital twin for a hospital requires hardware infrastructure for indoor positioning as the most critical component. Many digital twin-based services in hospitals require indoor positioning. Once the indoor spatial data are constructed and validated, and indoor positioning is installed, various indoor digital twin-based application services are developed. The building blocks in Figure 2 represent the core content of this work, and each component will be examined in the following sections.

4. Requirement Analysis on Hospital Digital Twins

Large hospitals operate much like cities with diverse types of activities taking place and spatial data infrastructure to support them. For instance, inpatient wards for patients function like residential areas, while there are labs for human tissue analysis, operating rooms, pharmacies, and various testing rooms, which are interconnected by a complex network. Similar to urban digital twins, a hospital digital twin can provide significant benefits. It supports various analyses for efficient hospital operation and safe management. This paper focuses on a case study of respiratory infection spread analysis, such as COVID-19. This will be discussed in detail in the following subsection.

4.1. COVID-19 Infection Models

The target function of our use case for a hospital digital twin is the spread analysis of infectious diseases, such as COVID-19, within a hospital. The objectives of infectious disease spread analysis are primarily twofold. The first is epidemiological investigation to trace the source of infection when an infected person is identified. The second is to identify vulnerable points in a hospital to prevent infections in advance. This infectious disease analysis for these two purposes starts with defining an infection probability model. As classified by [18,19], there are three main models of COVID-19 virus transmissions.

• Person-to-Person (P2P): This involves direct infection through droplets, occurring when infected and uninfected person are in close proximity in the same room. The transmission model is given as equation below and shown in Figure 3.

  $$p(a,b)=\left\{\begin{array}{c}0,ifa\in C_a,b\in C_b,\mathrm{and}{C}_a\ne C_b\hfill \\ 2p_d\left(d\right)·1/(e^x+1),\mathrm{if}a,b\in C\hfill \end{array}\right.$$

  (1)

  where a and b are infected and uninfected persons, respectively, and $x={\mathrm{dist}}^2(a,b)$, $C_a$ and $C_b$ are the cells where a and b are located. The maximum infection probability $p_d\left(b\right)$ of b is determined by the individual profile of b.
  Infection does not occur if a and b are staying in different rooms and the probability $p(a,b)$, therefore, becomes 0. Otherwise, the infection probability model is inversely proportional to the square of distance between a and b. In our model, we assumed that the base infection probability $p_d$ is determined by the personal profile of each uninfected individual as shown in Figure 3. Note that the logistic function is applied instead of $1/{\mathrm{dist}}^2(a,b)$ to make the probability curve smooth.
• Person-to-Surface (P2S): The second infection model is indirect contact, such as touching doorknobs or elevator buttons. This varies greatly depending on the material of the contact surface. For example, it is reported in [27] that on wood, the virus can survive up to a day, and the infection probability decreases to a ${log}_{10}$ order reduction by 2.18 within three hours in a 0.05 TCID 50/mL environment. The survival period of the virus differs for other materials, but the infection probability generally decreases on a logarithmic scale similar to that of wood.
• Person-to-Air (P2A): The third infection route is indirect transmission through airborne particles. If an infected person stays in one place, the virus can remain airborne and spread according to air flow. To accurately analyze this model, indoor air flow must be examined, typically using computational fluid dynamics (CFD). Airborne density is estimated over time through air flow analysis, and an infection model is applied based on this density.

  $$p(a,b)=p_d\left(b\right)·\varphi (\int F_A\left(d_c\right)dt)$$

  (2)

  where $p(a,b)$ represents the probability that b is infected by a and $p_d\left(b\right)$ is the base probability of infection. $d_c$ is the density of the virus left airborne by the infected person, $F_A\left(d\right)$ is the infection probability based on the density d, and $\varphi$ is the logistic function providing a smooth transition from low to high probability. In any case, the infection probability cannot exceed $p_d\left(b\right)$ as in the P2P infection model.

4.2. 3D Digital Twin for Analyzing COVID-19 Transmission

The requirements for hospital digital twins can in general be classified into three categories as below;

• Indoor positioning: the location $p(x,y,f)$ of each individual at time t, where f is floor.
• Indoor maps: 2D and 3D cell geometries including doors and windows, horizontal and vertical connections between cells to compute routes, and touch surfaces.
• Infection models.

To apply the infection models explained in Section 4.1, a digital twin model of the hospital indoor space must be provided. This section examines the functional requirements for this digital twin in detail. We focus on the requirements for a digital twin particularly for COVID-19 transmission analysis, as listed by

Table 1. Functional Requirements of Hospital Digital Twins.

Infection	Requirements	Description
P2P	location tracking of individual	$(p,t)$ to compute the distance between two persons at time t
	room-level tracking of individual	identifying room where each individual is staying
	computing or generating routes	route from point p to q
	P2P infection model	parameter values for P2P infection model such as personal profile
P2S	location tracking individual	$(p,t)$ to find the trajectory of each individual
	computing or generating routes	route from point p to q
	indoor maps including touch surfaces	2D indoor map with door handle materials
	P2P infection model	parameter values for P2S infection model such as personal profile
P2A	tracking each individual	$(p,t)$ to find the position p of each individual at time t
	airflow simulation	input for CFD
	P2A infection model	parameter values for P2A infection model such as personal profile

.

Based on the findings from Table 1, we derived the functional requirements for indoor maps, which will be applied to the indoor spatial modeling for our use case as listed in 

Table 2. Requirements for Indoor Map Modeling.

Functional Specification	Requirements for Indoor Maps
location tracking	2D layout of each floor
room-level tracking	2D cell geometry (room or hallway)
computing routes	connectivity network:
	- connectivity network: horizontal and vertical connection
	- hash-grid network for smooth and realistic routing
touch surfaces	door handle material attached cell boundary surface
airflow simulation	3D geometry including doors and windows
Level of Details (LoD)	- LoD 0 for 2D indoor maps and LoD 2 for 3D indoor maps
	- LoD 2 for 3D indoor maps such as windows and doors
	to analyze airflow

.

OGC IndoorGML supports not only 2D but also 3D spatial indoor models. If we construct 3D indoor maps, the requirements for 2D indoor maps can be also covered by 3D indoor maps in our case study. For example, the navigation networks are represented by 2D indoor maps as well as 3D maps. Two LoDs are required for indoor maps. LoD 0 is applied to 2D indoor map modeling while LoD 2 is required for 3D indoor map modeling as we need features on walls such as windows and doors for analyzing indoor airflow. Note that HVAC (heat, ventilation, and air conditioning) was not considered for CFD for our use case. It may be included in our future work.

These requirements served as the starting points in designing the specifications of indoor digital twins for hospitals. We expect that the requirements and specifications can be also applied to other types of indoor digital twins as well.

4.3. Indoor Positioning

In order to support the models presented in Section 4.1 and Section 4.2, indoor positioning must be provided. The common requirement is to track the location $(x,y,f)$ of each individual at each time t. In some cases, room numbers may replace $(x,y,f)$ coordinates, however, for applying the P2P model, distance is needed, so coordinate information is preferable.

Indoor positioning can be briefly divided into server-side and client-side positioning. An example of server-side positioning is RTLS or RFID, where a receiver captures signals from tags attached to the target object, and the server aggregates the signals to track, for example, the location of medical devices with attached Tags. In contrast, client-side positioning, for example, involves a smartphone analyzing signals from various sensors to estimate its location autonomously. In this case, each smartphone calculates its location, and there is no need for the server to calculate these locations. Typically, server-side positioning involves attaching tags to equipment or helmets and it is scalable due to the relatively low cost of batteries and tags. Client-side positioning, primarily using smartphones, tracks the location of the person carrying the smartphone and is advantageous from a privacy perspective as long as we keep the tracked location only in the smartphone. P2A and P2S, excluding P2P, also require room-level indoor positioning. Generally, indoor positioning provides 2D coordinates with floor data and it is, therefore, necessary to convert $(x,y)$ and floor information into room numbers [33].

The analysis of this use case requires not only the actual location of people but also virtual trajectories. The reason is that the actual location of people includes only limited cases and diverse scenarios cannot be examined. For analyzing the vulnerability of indoor structures to COVID-19 virus infection, it is necessary to consider diverse cases, which may not be collected from real-world data. We need to generate synthetic trajectory data for virtual persons in addition to the actual trajectories. Of course, the virtual trajectories should be as realistic as possible, reflecting the characteristics of the given hospital. For example, trajectories should be generated considering the work patterns of doctors and nurses, as well as the characteristics of patients and the regulations for visitors.

5. IndoorH: Data Specification of Indoor Digital Twins for Hospitals

To build a digital twin for a hospital, as examined in Section 4, three main components are needed. In this section, we present a data specification for constructing 2D or 3D indoor spatial data for the first component to meet the requirements discussed in Section 4 for a hospital digital twin.

The data specification, called $IndoorH$, was developed using OGC IndoorGML, which is the international standard for indoor spatial data models and encoding schemes. The reasons for using IndoorGML are as follows: firstly, the use of international standard models and encoding places the digital twin in an ecosystem built around standards such as various tools and cases within the ecosystem. Secondly, OGC IndoorGML provides the basic primitive feature types for geometric and semantic models and facilitates the definition of data specification for given applications of indoor digital twins. In our use case study, we, therefore, built IndoorH as an extension of IndoorGML for the data specification of a hospital digital twin.

5.1. Extending IndoorGML

The basis of IndoorH is IndoorGML 1.1. As illustrated in Figure 4, it specifically extends the Core Module of IndoorGML, which is also an application schema of OGC GML 3.2.1.

In general, there are two ways to extend IndoorGML. The first is to define a specialization from IndoorGML by adding subclasses with proper attributes and relationships to meet the requirements of a given application. The second is to support the case where none of the feature types in IndoorGML satisfies the requirements for the application. The external classes must be defined outside IndoorGML and references to feature types of IndoorGML must be set. For our use case, we applied the first approach and as explained in Section 5.5.

5.2. Geometry

The core module of IndoorH includes a geometric model as shown in Figure 5. This geometric model comprises Solid, Surfaces, Curves, and Point defined in GML [34] as illustrated in Figure 5. These geometric types are used for CellSpace, CellSpaceBoundary, and the geometry of nodes (States) and links (Transitions) included in the core module of IndoorGML [15]. Geometric representations are either of 2D or 3D. If represented in 2D, CellSpace and CellSpaceBoundary are expressed as surfaces and lines, respectively, while in 3D, they can be expressed as Solid and Surfaces.

In IndoorH, geometric objects are defined as 3D objects since the geometric model is based on LoD 2. Specifically, CellSpace is represented as Solid and CellSpaceBoundary as Surfaces. Similarly, the geometric types of nodes and links are defined as Curve and Point in 3D, respectively. For the infection models that require LoD 0, we convert 3D geometry to 2D geometry with floor data.

5.3. Topology

In addition to the geometric model, IndoorH also includes a topological model as shown in the dual-space part of Figure 5. The topological relationship between CellSpace and CellSpaceBoundary in primal space is defined and it is projected to the association between Stat and Transition in the dual space of Figure 5. This duality is represented by the topological relationship between nodes and links as Poincaré Duality.

The topological model of IndoorH allows the description of the connectivity between rooms and doors. An example of connectivity in indoor space is shown in Figure 6, which includes two types of connectivities. The first type is via a cell such as a door cell, which is defined as ConnectionSpace in IndoorGML as indicated by the red arrows of Figure 6. The second type is via a surface, which is defined as ConnectionBoundary. In most cases, the connection boundaries are used to connect two cells partitioned for subspacing via the virtual boundaries indicated by the blue arrows in Figure 6.

The connectivity in an indoor space can be described as a graph formed by a set of State and Transition of the topological model. Any additional information can be attached as properties of State and Transition, such as direction and accessibility.

5.4. Semantic Model

In addition to geometry and topology models, we need a semantic model to complete IndoorH. The semantics of IndoorH can be represented either by the classification of feature types or the properties of feature objects. We classify the cells in IndoorH as a code list, as shown in

Table 3. Code list of cell types in IndoorH.

Type	Code	Description
room	11000–11199	room types (room subtypes are defined)
hallway	21000	corridor
outdoor hallway	21010	corridors without ceiling
lobby	21020	lobby space
hash grid node	21020	node for hash grid network
elevator	21110	elevator shaft
stairs	21120	stair cell
door	31000	door space and node
gate	31010	gate space and node
emergency exit	31030	emergency exit space and node

.

In addition to cell types, we need also to classify the materials for door handles for the P2S infection model. Following [27], the materials for door handles are classified as shown in 

Table 4. Code list of door handle materials in IndoorH [27].

Type	Code
wood	101
plastic	102
glass	103
stainless steal	104
copper	105
others	100

.

A set of common properties of each feature in IndoorH are inherited from the abstract feature class of GML.

Table 5. Properties of the Abstract Feature class in GML.

Property	Types and Cardinality
GMLid	ID [1..1]
identifier	String [0..1]
name	GenericName [1..1]
description	String [0..1]

shows the properties defined in GML’s abstract feature class. Among these properties, the GMLid is a unique identifier generated when a GML object is created. identifier is defined appropriately according to application type and is used as a UFID (Unique Feature Identifier) in IndoorH.

5.5. Overall UML Data Modeling for IndoorH

Figure 7 shows the integral data model with the extension IndoorH, which reflects the discussion in the precedent subsections. The extension for IndoorH includes two additional subclasses - H:HospitalCellSpace and H:HospitalCellSpaceBoundary inherited from CellSpace and CellSpaceBoundary, respectively. These contain properties to specify the classification of cell types and door handle materials, based on the code lists shown in Table 3 and Table 4.

H:HospitalCellSpace and H:HospitalCellSpaceBoundary are actually navigable in our use case and may be defined as subclasses of NavigableCellSpace and NavigableCellSpaceBoundary in the IndoorGML Navigation module rather than CellSpace and CellSpaceBoundary in the IndoorGML Core module of the current version 1. However, only NavigableCellSpace and NavigableCellSpaceBoundary are defined and NonNavigableCellSpace and NonNavigableCellSpaceBoundary are not yet developed in the current version of the IndoorGML Navigation module. This means that the cell spaces in IndoorGML of the current version are assumed to be navigable cell spaces, and cell space boundaries to be navigable cell space boundaries. Based on this observation, we extended the IndoorGML Core module for IndoorH to avoid IndoorH having a complex module structure.

The UML diagram in Figure 7 is implemented in XSD as its encoding scheme. A part of the XSD is shown in Figure 8, where the enumeration type is defined for handleMaterialType in Figure 7.

6. Building IndoorH Data for a Hospital

According to the data specification IndoorH defined in the previous section, we build the IndoorGML data specification from 2D floorplans of the target sites comprising two hospitals, Severance Hospital in Yongin and Pusan National Univsity Hospital in Yangsan. The pipeline for building the data is presented as the following subsections.

6.1. Step 1—Extraction of Cell Geometry from Source Data Sets

We prepare source data sets, given as floorplans in DWG for the target sites as shown Figure 9. These floorplans provide the basic geometry data, from which we extract the 2D or 3D data of cells as well as several annotations such as room names.

From this source data set, we edited and extracted the geometry of each cell. Since the floorplan does not contain any 3D geometry data, we edited it with an open-source Sketchup plugin tool (this plugin is available at https://github.com/une-young/indoorgml-modeler (accessed on 16 December 2024)). This tool allows the editing of the geometry of each cell in 2D and extruding of this geometry into a 3D solid object.

6.2. Step 2—Cleaning the Geometry

As the source data may contain noise and the first IndoorGML geometry data from Step 1 may include erroneous data, cleaning is required. Common error types found during Step 1 are as follows:

• Non-closed geometry: the ending point of linear ring has to meet the starting point and the solid geometry of each cell must be a closed solid.
• Overlapping cells: no overlapping between cells is allowed, which forms a fundamental requirement of IndoorGML [15].
• Long hallways and large halls: we need to partition long hallways and large halls for efficient representation of indoor space into subspaces [35].

In order to remove all these noisy data and complement any missing information, we scanned and cleaned the IndoorGML data sets produced in Step 1 and carried out the subspacing using an open-source editing tool for 3D geometry of IndoorGML, called TICA (triangle-based IndoorGML construction authoring tool). This tool provides several geometry editing functions including subspacing. We developed this software and released it as open-source software (this tool is available at https://github.com/stemlab/TICA (accessed on 16 December 2024)). Figure 10 shows the geometry model of the ground floor at the use-case site in Yongin Hospital.

6.3. Step 3—Floor Determination

The height of each floor is not fixed and is sometimes ambiguous due to architectural irregularities; thus, we need to determine it manually. For example, it is not easy to determine the floor of an atrium located at the center of the building as a single floor. For this reason, we need a visual determination of the floors by providing the height profile of each floor. This profile consists of height intervals $(minH,maxH)$ for each floor, such that the cell whose heights contain a height interval is assigned the corresponding floor.

6.4. Step 4—Semantic Data

The next step of the IndoorGML building procedure is to assign the values of semantic properties such as the type and name of each cell. If we possess cell profiles, this process would be straightforward; however, this may not be available in most cases. We developed a simple tool to manually provide the property values of each cell from the floorplan such as cell ID, name, floor, and room type as shown Figure 11.

6.5. Step 5—Network Setup

The final step for building IndoorGML data is to setup the network connections between cells. Two types of connectivity are included in IndoorH data in our use case. The first is the connectivity for the duality such as connectivity between a room and a door. Second, our use case also includes the connectivity for hash grid networks as shown in Figure 12, which allows smoother and more realistic movements in indoor space [36].

To make a hash grid network, we first divide the space into a set of grids connected with neighbors. If there are constraints such as the walls or partitions shown in Figure 12, then the connectivity is removed accordingly.

6.6. Step 6—Validation

After having built IndoorH data, we need to carry out the validation of the data set, which should be based on the IndoorH data specification defined in Section 5. The validation specification is to facilitate the quality control according to an international standard ISO 19157-1 [37], which defines the quality control standard for geospatial data.

In ISO 19157-1, five elements of quality are identified: completeness, logical consistency, positional accuracy, thematic accuracy, and temporal accuracy. In our work, we define the quality control process for these elements except temporal accuracy and suggest quality evaluation methods for each element. The quality check should be carried out with the list of checking elements predefined from the data specification.

• Completeness of Data: The first quality control element is the completeness of data to check whether there is any missing cell. As this check cannot be carried out in automated way, we examine the IndoorH data with the source data set to check any missing entities.
• Logical Consistency and Thematic Accuracy: The first step of the logical consistency check is carried out using oXygen, which is a widely used XML tool, which checks the syntax according to the XML schema of IndoorGML. It also examines the cardinalities of association and aggregation. Conversely, we manually examined the thematic accuracy by checking the classification, properties, and names of cells, as we do not have any cell profiles.
• Network Connectivity: Unlike checking geometric errors and cross references, many other items are difficult to validate in an automated way and we need to validate these in a manual and visual way. This means that only a small number of samples may be tested instead of checking the complete set of entities. An example of these items to be checked is the network connectivity. In order to make sure that indoor cells are correctly connected, we check the following items:

  –

  Navigable cells: Checking if any navigable cell has at least a connection space (door) or connection boundary. This can be done in an automated way by scanning all navigable cells. For example, cell-211 in Figure 13 is a navigable space but has no connection to neighboring cells.

  –

  Routes to entrance: Checking whether every cell is accessible from the entrance. This test can be also conducted in an automated way by computing the route from each cell to one of the entrance cells, which are called anchor cells in IndoorGML.

  –

  Correct routing: Checking whether the routing from cell A to cell B can be correctly derived from the network connectivity. As the number of combinations of two cells is very large, a certain number of pairs of cells have to be pre-selected with the routes of ground truth. We validate whether the routes of ground truth are identical to the derived routes.

• Geometric errors and cross references: Geometric errors and cross references between XML elements are validated in an automated way by an open-source tool, called val3dity [38]. Figure 14 shows an example of the result reported by val3dity including a number of geometric errors such as self-intersection, a non-closed shell, and overlapping. It is expected that these errors come from floating point errors.

7. InCOVID⁺: COVID-19 Transmission Analysis Tool

The primary reason for building a digital twin is to simulate real-world phenomena. In many cases, this requires 3D spatial information as well as real-world laws, such as physical, chemical, or biological models for the simulation. For the use case of COVID-19 transmission analysis in a hospital digital twin, we have established an epidemic model and a supporting 3D digital twin indoor model as discussed in Section 6. This section introduces a simulation tool for COVID-19 transmission analysis, called InCOVID⁺, supporting the P2P, P2S, and P2A infection models. This is an improved version of a previous tool, InCOVID [39], and the differences will be explained in Section 7.4.

7.1. InCOVID⁺/P2P

The system overview of InCOVID⁺/P2P supporting the P2P infection model is as follows. First, the movement patterns of each moving object are given by a movement profile containing parameter values of the movement of each agent, such as doctors, nurses, patients, and visitors, such as the number of each agent type, attendance time of nurses, and movement pattern of each patient. Second, a synthetic trajectory data generator, called SIMOGEN (the source code is available at https://github.com/STEMLab/SIMOGen (accessed on 16 December 2024)) (Synthetic Indoor Moving Object GENerator), receives the movement profile and generates virtual trajectories using the network provided by IndoorGML.

Third, the InCOVID⁺/P2P module applies the P2P infection model to the synthetic trajectories to determine the spread of infection using the P2P infection model explained in Section 4.1. The user interface of this tool is shown in Figure 15. In the dialog box at the top right, the user can select the parameter values required for the P2P infection model. Yellow dots represent uninfected people, red dots represent infected individuals, and red circles indicate the areas where virus transmission has occurred. By clicking on these areas, the user can find more information about the infection in the dialog box at the top left. The scroll bar below allows the time to check the infection status to be specified.

7.2. InCOVID⁺/P2S

InCOVID+/P2S is designed and implemented in a similar way to InCOVID⁺/P2P except in the infection media and infection model employed. The most fundamental function of this module is to estimate the probability that an infected person has transmitted the infection to another person via surface contact. Given a and b infected and non-infected persons, respectively, the infection probability from a to b is computed as follows assuming that $T{R}_a$ and $T{R}_b$ are trajectories of a and b, respectively,

• Step 1: $T{R}_c=T{R}_a\cap T{R}_a$ // compute the overlapping trajectories.
• Step 2: $S=\left\{s\right|s$ is a touch surface on $T{R}_c\}$ // such as door handles.
• Step 3: $p_i=F_S({\tau }_i,d_t)$ // $F_S$ is the infection probability function of material type $\tau$ of i-th surface touch and time difference $d_t$ between two contacts.
• Step 4: $P(a,b)=P_d·\varphi (\Sigma p_i)$ // the infection probability is less than $P_d$ determined by personal profiles of a and b.

$p_i$ is the probability of infection via the i-th contact on the overlapping trajectory $T{R}_c$. To perform the above process, the IndoorH data must provide the information on contact surfaces. For example, objects such as door handles or elevator buttons should be included in IndoorH so that they can be searched when a trajectory is identified. In this use case, Transition of IndoorH class includes a link to contact surfaces where any indoor movement occurs. To carry out step 2, additional information is included as a property of the contact surface. By incorporating contact surfaces into the digital twin, we expect that the system can accurately estimate the probability of transmission through surface contact in hospital environments.

7.3. InCOVID⁺/P2A

The application of P2A is similar to P2S and the key difference is that the transmission medium is airborne. To accurately reflect this type of transmission, it is necessary to understand how the virus spreads through the air. For our use case, computational fluid dynamics (CFD) was applied. A 3D model of the test space was constructed using IndoorGML, and the air diffusion model was applied. IndoorGML provides a 3D spatial model that offers the geometric model necessary for applying CFD. Figure 16 represents the speed of air flow in a given space from an oblique view. In this figure, we observe that the air flow of this floor spread through doors and the speeds are high at two areas due to air ducts, where door features are represented in IndoorGML.

The virus density d at a given point is estimated over time through the airflow. P2A estimates the probability of infection by applying the P2A model described in Section 4.1 as a function of virus density and staying time that the infected and a susceptible individual spent in the common space. The maximum value of this probability cannot exceed the $p_d$ determined by the individual profile.

7.4. Application of InCOVID+ and Comparison with Previous Works

The InCOVID⁺ tool enables simulations through virtual movement of people and also allows searching for infections if they occur. Specifically, it can be applied for the following purposes:

• Preemptive measures by predicting vulnerable areas: As shown by Figure 15, we can see the areas where infections may happen frequently, such as the nurse station and staircases. This helps in predicting vulnerable areas and taking appropriate preemptive measures in design or construction phases as well as in maintaining phase of the building. For example, we may recommend checking the vulnerable spots of virus transmission in a new building with InCOVID+ during the design process. If vulnerable areas are found around elevator banks, then it may be better to design alternative routes or improve HVAC systems.
• Epidemiological investigation of infected individuals: When an infection occurs, it is possible to trace the infection path, identifying the infection point, infected individuals, and the time of infection.

The key advance of our work over the previous tools and works is the rigorous consideration of indoor spatial structure to analyze the transmission of the COVID-19 virus. For example, the studies in [25,26,40] only considered a single cell for airborne transmission and did not consider indoor structures such as doors, windows, and stairs, while COVID⁺ covers the entire indoor space of given building as illustrated by Figure 17, which shows the movement of a virus particle in an indoor space through doors.

As mentioned earlier, InCOVID⁺ is an improved version of InCOVID [39], which was developed for COVID-19 spread analysis in indoor spaces. Like InCOVID⁺, InCOVID considers indoor structures such as cell-based geometries and an indoor connectivity network represented by IndoorGML. Since it is a prototype tool for indoor COVID-19 spread analysis to test the feasiblity of IndoorGML, it has limited functionalities compared with InCOVID⁺. First of all, the target site was a shopping mall and no consideration was given to the movement patterns of the individuals, while InCOVID⁺ considers a diverse set of movement patterns such as nurses, patients, medical doctors, and visitors. InCOVID only supports P2P unlike InCOVID⁺, which supports the P2P, P2S, and P2A infection models. Furthermore, InCOVID⁺ has been developed to trace an individual based on a real indoor positioning module, while InCOVID only supports synthetic trajectories.

8. Conclusions

Hospitals are an important type of indoor digital twin where complex and numerous activities are happening just like in cities. It is, therefore, important to study how to build a digital twin for hospitals. In this study, an indoor digital twin was built for a hospital. In the process, a framework for building an indoor digital twin was also created. As indoor spaces have various characteristics that are different from outdoor spaces, the methodology for outdoor spaces cannot be applied as is. To overcome this problem, this study starts based on OGC IndoorGML, a standard for indoor space data specification. IndoorGML provides a basic standard spatial data model and also provides a specific XML-based encoding method. However, IndoorGML provides only the basics, so in order to apply it to indoor digital twins for actual applications, the gap between IndoorGML and the conditions required by the application must be bridged. In this study, a digital twin was created based on a framework designed to build an indoor digital twin for a hospital. Specifically, the analysis of indoor infections of COVID-19 in a hospital was selected as an application, and the requirements for this were analyzed. The requirements served as the starting point of our use case development from data specification definition to data construction and application service development. Through this case study, our work makes the following important contributions.

• Consideration of the presentation of an indoor digital twin construction framework based on OGC IndoorGML, an international indoor spatial information standard. This is the main academic contribution of our work.
• Construction of an indoor digital twin for COVID-19 transmission analysis covering the entire life cycle of the procedure from the analysis of COVID-19 transmission requirements and definition of indoor spatial data specifications, called IndoorH, for a hospital as an extension of OGC IndoorGML, construction and validation of indoor space data satisfying IndoorH specifications, and development of an indoor space COVID-19 infection analysis tool as a service case of this digital twin.
• Consideration of indoor structures for COVID-19 analysis, while previous works have instead focused on the infection model itself. Our work shows how the spread of COVID-19 can be analyzed in a given indoor space.

The first and second contributions are practical contributions, while the third is a methodological improvement. The study introduced in this paper is expected to be a reference use case for constructing digital twins of indoor spaces, particularly for developing an indoor digital twin service based on OGC IndoorGML.

As this work is a starting point for use case development of the IndoorGML standard, many studies may be included as future work. First, we may convert the extension of IndoorH from IndoorGML 1.1 to IndoorGML 2.0, which is under development. Once IndoorGML 2.0 is officially published, it will be necessary to extend IndoorH from this new version because it is expected to be a significant improvement from the previous version. Second, we expect to include HVAC in the P2A infection model, which is not yet developed in our use case but is an important aspect to make COVID-19 transmission analysis more accurate. Third, a survey report on InCOVID⁺ by its users is required, which will be analyzed to validate the usability and served as inputs for further improvement. We leave this as a future work.