Abstract
Hospital buildings usually contain sophisticated facility systems and special medical equipment, strict security requirements, and business systems. Traditional methods such as BIM are becoming less capable of real-time updates of building status and big data volume. By proposing innovations both in technique and management—a “continuous lifecycle integration” method based on the concept of Digital Twin (DT) and “early movement” of the general contractor, this paper reported a successful project case in a large hospital in China. The case realized continuous, scheduled integration of static data and dynamic data of more than 20 management systems from the design, construction, pre-O&M phase up to the O&M phase. Then, a DT software system with real-time visual management and artificial intelligent diagnosis modules was developed and deployed in a newly built DT control center. Managers have the ability to grasp the detailed status of the whole hospital by visual management and receive timely facility diagnosis and operation suggestions that are automatically sent back from the digital building to reality. The case has been steadily running for more than a year in the hospital and achieved desired performance by reducing energy consumption, avoiding facility faults, reducing the number of requested repairs, and enhancing the quality of daily maintenance work.
1. Introduction
As the increasing volume or complexity of newly constructed building projects, daily management efficiency, and operational safety issues are becoming more important than ever. Difficulties arise from both static and dynamic factors: there are often hundreds of rooms in large public buildings, each with distinct use requirements. How to manage in a precise manner is a challenging puzzle. Besides, numerous mechanical and electrical systems are embedded, such as cold/heat sources, water supply and drainage, power transformation and distribution, lighting, weak current, ventilation/air conditioning, and elevator systems. Even for professional workers, to maintain and repair these systems is not far from tedious. Another challenge is managing people in the house—the most unpredictable factor of all, such as visitor behaviors or staff collaboration for different tasks.
Hospital buildings have not only common difficulties as public buildings but also have unique characteristics of the medical industry [1]. There are special systems in hospitals such as the medical gas system, pneumatic logistics system, medical sewage system, etc. According to the national standards of China, hospital space is strictly divided into public, medicine, clinical, surgery areas, and other special technical regions. These areas all have high-standard requirements for O&M quality—temperature, humidity, sewage, exhaust, and air exchange. In daily activities, all patients, family members, doctors, and administrative personnel may cause dense and complex intersections. Thus security requirement appears much more crucial than ordinary buildings. Another feature is, many operation tasks in Chinese hospitals are entrusted to the outsourcing team, which brings additional quality uncertainties and management problems.
Among all solutions towards management issues of large hospital buildings, BIM (Building Information Modeling) is one of the most promising and mature theories [2]. BIM provides a graphic platform with 3D building entities for facility managers to retrieve, analyze, and process various data in a unified software interface [3]. Some successful cases were reported about BIM-based facility management [4, 5], energy management [6], and safety management [7]. BIM platforms also coordinate well with the Computer Maintenance Manage System (CMMS), which addressed basic activity recording of routine maintenance.
Despite BIM’s achievements, three main concerns in building operation management, especially on large hospital buildings, remain unsolved:(1)Existing software platforms lack a constantly updated display of real-world buildings [8]. For example, sudden people flow at the entrance of hospitals is dangerous and should be immediately reported. Most building data on existing platforms are preimported then remain unchanged. Managers cannot inspect the truly up-to-date status as they wish.(2)There are still difficulties when gathering digital data from various sources. In a hospital, about 20 systems are potential dynamic data sources. Each system has unique hardware devices, interfaces, and data formats. Besides, sensor data can accumulate extremely fast. Data transformation strategies and storage work of such big data volume also need improvements [9].(3)Typical in-use management software like BIM platforms mainly focus on browsing or checking business data with a 3D model, but not mass analysis. If using a separate offline database analysis to fill this gap, it would be poor in timely feedback mechanisms. Therefore, advanced data analysis effort is required in the form of timely decision-making suggestions.
To address these problems, a relatively new concept—Digital Twin (DT)—has been borrowed from the manufacturing industry. Although manufacturing DT has been developing for about ten years, it was far less popular in the building industry, with only a few use cases related to AEC and O&M phases [10, 11].
When a DT is established, it aims to describe the real-time information mapping between virtual models and real products. Consider a certain hospital building as an example below. The real-world part of digital twin refers to a touchable building block that every day embraces all doctors, patients, pharmacists, and medical equipment. A “digital shadow” of this hospital building is the virtual part of the digital twin [12], automatically receiving data flow from the real hospital [13]. With the help of visual management functions and diagnosis algorithms linked to the digit shadow, hospital managers are capable of monitoring current operation status and make optimization decisions back to the real-world hospital. The above-mentioned feature of DT naturally addresses the first concern by providing a methodology of linkage from a virtual model to real building entities.
A survey shows more than half of declared DT research papers about manufacture only reached the digital shadow level of integration [13]. The situation was even more gloomy in the building industry. It is clear that similar studies usually took advantage of the same shortcut, which directly upgraded existing functional modules of a BIM system to a digital twin system [14–17]. Although this shortcut has brought significant convenience for the building industry to quickly accept the digital twin concept, BIM seems closer to a single digital shadow, thus only partially realizes a digital twin. In fact, DT can be much more powerful, enabling the whole lifecycle mirroring, supporting decision-making by timely optimization suggestions based on this mirror of current status [18]. DT improves common functions during the lifecycle service of buildings, such as real-time monitoring, energy consumption forecast, failure prediction, operation guide, etc. [19]. In this paper, the real-world part of DT is emphasized more than existing BIM systems.
Smart device integration is always a crucial but difficult step when establishing DT [15]. Modern smart sensors will produce valuable insights by generating extremely huge data. One of the main contributions of this paper is the continuous integration and manipulation method of device data through the whole lifecycle, which has addressed the second concern. Further, to analyze these data and feedback useful information back to reality, diagnosis functions should be tightly integrated into DT management systems. Artificial intelligence (AI) is naturally introduced in DT’s framework to make further analysis after data integration, including event identification, fault diagnosis, and automated decision-making. Analysis usually involves powerful machine learning models or deep neural networks. For example, some papers reported spatial models and a guiding system for movement/evacuation path management in large buildings [17, 20]. Natural Language Process (NLP) and clustering algorithms were employed to find fault patterns from routine repairs [21–23]. Based on collected up-to-date information flow, analysis results will be highly usable due to guaranteed synchronization [24]. In this paper, an intelligent diagnosis engine is embedded into the heart of the DT software system, which successfully addresses the third concern in Section 4.
For the exemplary case in this paper, a DT hospital building constructed by the concept of “continuous lifecycle integration” is proposed. In Section 2, the continuous lifecycle integration method is introduced. In Section 3, a concrete DT management system is developed. Section 4 presents detailed on-site applications of the DT hospital building. Discussions and conclusions are given in the end.
2. Case Background and Methodology
2.1. Case Background before Introducing DT
Shanghai East Hospital affiliated to Tongji University (generally known as East Hospital) is an A-grade general hospital located at Lujiazui business zone of Shanghai, East China. The case building was the new clinical center integrating medical treatment, teaching, scientific research, first aid, prevention, and health care. Compared to old clinical buildings, this new building mainly focused on major public medical security and high-level medical care services. The building consisted of 24 floors above ground and 2 floors underground with 500 beds, with a total construction area of about 83000 square meters.
Before constructing the new clinical building, East Hospital’s mechanical and electrical equipment involves separately working complex systems, including professional medical systems such as gas systems, sewage treatment systems, and the medical equipment system. The BA, maintenance, and space management system currently in use are independent of each other and cannot naturally integrate a unified system according to the medical service demand. It is not convenient for middle and high-level managers of East Hospital to make timely decisions, leading to low operation and maintenance efficiency. Also, the hospital building needs continuous running for 24 hours every day; therefore, O&M Management Department will be under great pressure. Traditional manual, book-keeping management strategies were obsolete and unintuitive because it was nearly impossible to monitor and analyze large data sets from numerous sources.
2.2. Innovation
The main technical innovation employed in this case study was called “continuous lifecycle integration method,” which refers to a detailed schedule guiding the integration of proper content gradually and punctually over the full lifecycle. The timeline of building projects usually involves AEC (Architecture, Engineering, and Construction) and O&M (Operation and Maintenance) activities. Accordingly, the full lifecycle can be divided into several phases, typically, the design phase, construction phase, O&M phase, etc. Among them, the O&M phase is of special importance as it occupies the majority of the building’s lifetime and budget cost. However, O&M cannot be isolated from AEC. Main static information like geometry, facility attached information, space division, electric system logic, and so on are determined in the design phase. Intelligent hardware devices that are utilized to collect dynamic operation data are equipped or preserved in the construction phase.
“Early movement” of general contractors was another innovation about management practice, which ensured data consistency of DT. The consistency from the digital model to the real-world conditions at any time, which is the exact meaning of the “twin” word, is a delicate feature of DT employed in this case. The fact of consistency is significant throughout the full lifecycle of buildings, especially in the O&M phase. For example, consistency in facility management refers to both static information and dynamic status. If digital models failed to update according to construction changes, workers would fail to locate an alarming air conditioner unit. If monitoring signals were inconsistent with the actual situation, workers might incorrectly operate an electric device, causing unexpected consequences. Traditionally, general contractors are only able to take control of the construction phase. In this paper, the general contractor’s DT consultant team involved early in the planning & design phase, directly submitting requests about data interfaces to owners and designers. They also collected important design metadata, such as serial codes of facilities and sensor position. Then in construction, the general contractor took the lead in coordinating contracts of various system suppliers, constructing networks of smart devices, tracking changes of point information, etc. By integrated project delivery (early movement), the general contractor guarantees that all DT information was consistent in the full building lifecycle, not limited to the construction phase.
2.3. Steps of Continuous Lifecycle Integration
Figure 1 shows the main steps to establish a DT for the hospital building, starting from a real-world hospital and end with a complete DT. The first step was to digitize the hospital through geometry modeling. Geometry modeling was mainly conducted with CAD drawings from the design phase, while the 3D point cloud method by laser scanning or photogrammetry [8] was tested upon complex mechanical rooms. After that, the modeling process of BIM was one of the main integration steps. Generally, splitting static ontology data and dynamically generated information is necessary to ensure system-inherent data security [25] and also to suit proper storage strategies. Therefore, a basic BIM was first built, integrating static models and ontology information. By monitoring processes through business systems and sensor devices, a dynamic BIM or digital shadow emerged. Analysis engines with predefined knowledge and AI model should be added right after monitor data coming. Finally, the object mapping process by the on-site investigation was important to link to the real-world hospital. All functional modules and diagnosis suggestions should be sent back to a real-world hospital building based on correct object mapping.
2.4. Detailed Contents of Integration
Doing the right things at the right time was the core idea when planning the DT schema. Beginning from the design phase, all contents (refer to static data, dynamic information, and possible diagnosis models from corresponding stakeholders in charge) should be integrated on schedule at different stages of the lifecycle. Table 1 gives some examples of integration contents. From a consistent point of view, critical information from one phase must have received from previous phases, not arbitrarily recollected and overwritten (some examples are marked triangles in Table 1). This would make sure only one copy of basic data at any time while saving lots of unnecessary modeling costs.
3. DT System Development
A unified DT system across desktop client, smartphone app, and tablet app was developed based on the continuous integration method. Figure 2 shows visual management-centered major components of the system and their operating logic. First, raw data from a real hospital and digital shadow were processed, some through Apache Kafka engine as high-density stream data (Step 1 and 2). Then, two kinds of big data methods, the Apache Flink engine and scheduled Extract-Transform-Load (ETL), both continuously transformed analysis data of building status into a predefined data warehouse—a tidy format suitable for AI training (Step 3). The data warehouse first provided proper training data to AI models. After proper training, these AI models formed a diagnosis engine and frequently received diagnosis data from the data warehouse (Step 4). Once a problem was detected by the engine, it should be immediately prompt back to visual management interfaces (Step 5). Finally, some targeted commands or suggestions were given towards the digital twin hospital building (Step 6). If any diagnosis suggestion was confirmed as incorrect, it was sent back to the engine as negative training sets. The AI algorithms should make corresponding adjustments (Step 7). Key aspects of system development are introduced in the following sections.
3.1. Data Processing during Design and Construction Integration
Data integration of DT lasted for about three years. Although most dynamic data were collected in the O&M phase, the design and construction phase had taken the most time. To make sure data from design and construction keep consistent for so many years and still fit the interface of the DT platform, the consultant group published a considerably thick booklet of interior data standards. Workers in the project department could collect various data in standard formats, and modeling workers produced easy-to-integrate digital models in a unified style.
During static modeling, geometry data were getting larger along with continuously integrated model files, especially HVAC elements. At the end of the construction phase, primary geometry data reached 15 GB, which was obviously too heavy for GPUs. A series of proposed original lightweight algorithms were executed, including merging linked pipe segments, eliminating minor details, and mesh grid simplification. They reduced file size, triangle face number, and element number to less than 20% (as shown in Figure 3).
3.2. Dynamic Operation System Integration
In the DT platform, six aspects of dynamic systems were integrated as data sources. Table 2 lists corresponding protocols used when connecting and data processing frameworks. Due to the budget limit, big data services were powered by free, open-source engines. Big data frameworks like Kafka and Flink were capable of transforming quick and dense stream data that were continuously sent from numerous sensors. Both frameworks have been widely adopted in the product industry for several years and are believed stable enough. As for repair business systems or armarium systems, far fewer records were sent. Therefore, some Python ETL scripts with Pandas managed by a schedule dispatcher APScheduler would do the work more concisely.
In East Hospital, the hardware networks of BA consisted of more than 1900 intelligent sensors from 13 subsystems including the elevator system, meanwhile about 230 digital meters from two energy monitoring systems (electricity and water supply), and 100 sensors from three medical gas systems. Because positions and serial codes of all sensors were already ensured consistent by early involvement of the general contractor, dynamic data could be integrated automatically into DT ruled by correct correspondence. These devices generated about 2 million records per day and more than 10 TB of record data in total. Despite the huge volume, the data format was relatively simple. The continuous integration worked smoothly with the help of steady networks. The only issue was database backup every three months. In contrast, records extracted from repair systems, armarium systems, or outpatient information systems contained quite complex properties, thus were far more difficult to develop flexible ETL scripts.
Safety issues about secret data, such as security monitoring videos and visiting records of patients, were also considered. According to the software development contracts, DT systems should only visit private cloud HTTP APIs inside hospital firewalls. This had caused enormous puzzles during the developing phase. Therefore, the security monitoring system and outpatient information were more or less the last coming data integrated. Finally, a private cloud was deployed in the DT control center and Oriental Hospital’s information department, which stored secret business data.
3.3. Mixed Reality (MR) Assisted Object Mapping: From Digital Shadow to DT
During the data period of system development, correct object mapping from the real hospital to digital shadow was of significant importance. If building elements’ position, size, properties, or relationships in the digital part were not consistent with the real-world part, workers would feel confused and corresponding diagnosis based on the wrong data would be consider useless. On-site investigations were carried out across the lifecycle but more frequently in the pre-O&M phase. In order to help to check object mapping, an MR app was developed on an iPad tablet. MR technology can seamlessly overlap virtual scenarios upon real entities and display in special optical equipment. As shown in Figure 4, through precise position matching, digital model shapes of critical rooms were displayed together with real scenes inside helmet glasses. Any differences in position were quite obvious from the MR point of view. Instant measurement was supported as well. Input property data such as material, type, or factory information could be called through apps and then compared with machine tags. Those necessary geometry and property data were automatically extracted from the digital shadow part. The MR app helped correctly modeling a DT.
3.4. Diagnosis Engine and Big Data Backend
Core algorithms of diagnosis were developed via Python language. AI models were implemented by popular frameworks like TensorFlow wrapping by Keras and Pytorch deep learning. Detailed applications of diagnosis engines are introduced in Section 4.
Big data services performed well upon stream data from sensor devices. In detail, first, a Java daemon process worked at background gathering different data sources to Kafka producer “topics.” Kafka then managed and sent raw data as streams. On the other hand, Flink constantly consumed each stream, transforming into standard formats according to the data warehouse. Big data services in the DT system managed to hide low-level manipulations such as keeping consistency, avoiding duplicate calculations, data-saving & backups. This simplified system development APIs.
4. On-Site Application
The management platform of DT hospital buildings was successfully developed right before construction delivery. Then it was deployed inside East Hospital. The operation department of the hospital had regrouped its personnel and arranged about ten members switching from traditional positions to DT management jobs. In addition, a consultant group from the DT product team took charge of training on-site workers and software users. By now, all DT applications have been steadily running for about 15 months.
4.1. DT Large Screen and Control Center
In the design phase, executive leaders of East Hospital had foreseen to reserve a 200 m2 region in the new clinical building for more advanced BA use. Then, a DT control center was built at the core region of B1 floor right next to HVAC and electric machine rooms, shown in Figure 5. The control center was equipped with perfect working conditions to ensure robust running, including server room, inner network, UPS (Uninterrupted Power Supply), individual office area, facial recognition access, communication lines, and environmental controls. With higher authority and full data access, the DT control center was not only a branch of building management offices but also had become a centralized brain that was able to harmonize daily activities over the hospital.
The main display device for the DT system was a large integral screen (height and width: ) in front of the command deck. For staff use, three graphic stations supported the DT software platform, one BA monitoring screen, two server terminal computers, and several regular office computers.
4.2. Hospital Visual Management
4.2.1. Hospital Overview Screen
When stepping into the control center every day, the default screen showed a large frontpage of a hospital overview. The left part was a full discipline 3D model, supporting visual transformation, free roam, element selection, and switching among facility systems. The right part listed the most critical information that should be checked by on-site managers, such as alarming sensors, predicted machine fault risks, unhandled repair requests, the trend of passenger flow, and monitoring video at the clinical areas, etc.
4.2.2. Space Management
Based on the hospital’s request, the spatial information of rooms and halls was established, which supports room allocation, statistical analysis, and other functions in the 3D view and list view. All spatial information was maintained here (Figure 6) as background knowledge for energy diagnosis in the next section. QR code or Bluetooth beacon for each space was generated as an indoor positioning tag, and support automatically positioning for repair workers. Some statistical analysis of space use was given as well. The space occupation and utilization rate of each medical department were calculated, and the space use efficiency was analyzed considering the operation of the hospital. This helped the planning of rooms and optimization of space.
4.2.3. Energy Management
This function constantly monitored the energy consumption of the hospital building, including water and electricity consumption. Water usage was divided into kitchens, toilets, medical water. Electricity usage was divided into standard categories like lighting & switches, power system, air conditioning, and special electric consumption. The absolute amount of energy consumption was shown by line charts, while the linked relative ratio was listed by categories. In the graphic platform of DT, red biased colors emphasized relatively dense energy usage (Figure 7).
4.2.4. Facility Management
Major facility information, logical structure, and physical structure of each system were displayed. Through seamless docking with BA, the operation status and alarm status of each device are displayed in the 3D model view. According to integration contents in Section 2, dynamic facility data streams covered HVAC, water supply and drainage, power distribution, and other systems.
The system displays the historical monitoring data of each monitoring point in the form of a list and trend chart to facilitate the backstage management personnel to directly grasp the operation of all key machines and evaluate its performance as well. Take the air conditioning system as an example. A high-level detailed monitoring model has been established for the air conditioning unit (Figure 8). The detailed model displayed 12 monitoring points such as filter status, air supply temperature and humidity, and CO2/CO concentration. After setting the threshold value of the temperature and humidity of the incoming air, CO2, and CO concentration monitoring value, if the real-time data is detected to exceed the threshold value, warnings or alarms were prompted in different colors (left part of Figure 8). Corresponding repair workers would receive a work assignment on their smartphone at the same time when workers needed to know the effect of upstream or downstream devices (In facility systems, an upstream/downstream device means where air or water flows to/from the current device. For instance, if water flows through A ⟶ B ⟶ C, we say A is the upstream device of B, and C is the downstream device of B), they acquired connection information from the DT control center. Information on pipe flow logic and controlling areas was already integrated into the pre-O&M phase. This additional knowledge greatly helped reasonable and timely reactions to facility failures. For example, the influence regions of an alarming air-handling unit (AHU) were displayed with moving arrows and sent to an on-site repair team (right part of Figure 8). Some workers took the responsibility of finding potential abnormal behaviors along air pipes. Other workers went to open windows of influenced rooms, enabling better air exchange while AHU was under repair.
Another highlight was the elevator system monitoring. The position signals of all 18 elevators were sent back every five seconds. In this way, the graphic system displayed a real-time animation for managers. When a busy elevator was observed, the DT control center would connect to nearby speakers and guide waiting for passengers to another available elevator.
4.2.5. Repair and Maintenance Subsystem
This subsystem was the service window of the DT system, which facilitates users at any level to initiate and handle repair requests or maintenance plans conveniently. Here included the emergency repair initiation, reception, task assignment, work order generation, maintenance processing, and maintenance calendar. Maintenance plans supported the customization of different emergency maintenance, daily maintenance, and on-demand maintenance processes according to different clinical departments or different machinery requirements, to support the adjustment of the task process according to actual situations. A regular user in the building could initiate a repair request via the mobile app, submitting multimedia descriptions and text messages of a question. App supported text, photos, voice recording, and videos. The system also collected requests from automatic fault diagnosis modules. Both manual and automatically generated tasks were assigned to the nearest worker in the hospital building. The DT model was employed to help locate the spatial position of faults, analyze, and then judge the influence range or key points of faults. This improved the efficiency of equipment maintenance and emergency repair.
4.2.6. Security Subsystem
The platform integrated all security cameras by docking with the video monitoring platform of the hospital. As shown in Figure 9, the system includes real-time monitoring, trajectory monitoring, and key area monitoring. By clicking the camera icons on the 3D building model, real-time videos were directly called, achieving seamless target tracking around 360 degrees. The advanced tracking function was running for important guests and dangerous persons as well. The problems of “medical dispute profiteer” seriously threatened medical order. With the help of the security subsystem, facial recognition warnings would be triggered as soon as medical dispute personnel invaded the range of any security cameras, based on their photo profiles. The DT control center would directly inform security guards on corresponding floors.
4.2.7. Guest Flow Management
Through facial recognition cameras at all entrances on each floor, real-time guest flow management was realized. The sum of flow was calculated every five minutes by ETL. As soon as average flow strength (defined as the percentage of incoming/outcoming flow to the current entrance’s maximum volume) exceeded a threshold of 0.25, a warning would be sent to the control center. Managers of security guards would receive a prompt on mobile apps as well. Vehicle license plate recognition was embedded into the main entrance cameras. Car number, entering time, leaving time, and parking lane of every visited car was recorded. Managers could check photos and accumulated numbers of car flow.
4.3. Intelligent Diagnosis for Hospital Optimization
4.3.1. Abnormal Electric Usage Detection
Various electrical circuits in the hospital show different laws of usage. For example, the lighting of the outpatient waiting area consumed less electricity in the daytime, more in the evening, and almost zero at night, while the consumption of the power system is higher in the morning and remains relatively low after that. The monitoring data of 230 smart meters were automatically classified by the k-means cluster algorithm. This method is unsupervised and fully automated, thus very suitable to find unknown patterns. Seven kinds of normal electricity consumption behaviors and corresponding groups of meters were obtained. The DT system continuously monitored the electricity usage and identified any abnormal meter that exceeds or falls below the 20% threshold from corresponding normal behavior. Abnormal circuits were displayed on a large screen, and check tasks were prompted via mobile app (left part of Figure 10). For confirmed abnormally high consumption hours, workers must locate related facilities and stop unnecessary energy consumption. As for confirmed abnormally low consumption, they should check if any machine stops working.
4.3.2. Air-Handling Unit Fault Prediction
The raw data comes from the combination of BA monitoring data and repair records. To be specific, after an AHU confirmed a real fault alarm, take out the monitoring data of the last 24 hours and take out the specific type of fault as a pair of training sets. To learn prediction rules from such time-series data, Long Term and Short Term Memory (LSTM) networks were employed. This kind of network has a flexible memory, tracking the abnormal data changes over time. The LSTM prediction model covered 10 types of faults in total, such as overheat and undercooling, low airflow, clogged filters, etc. On the other hand, the data warehouse continuously inputs the latest 24-hour monitoring data of all AHUs. If the predicted failure probability was greater than 0.6, an early warning would be issued in the system and mobile app (right part of Figure 10). As the number of real failures increases, the prediction model continued to receive new training data, which in turn increased its accuracy.
4.3.3. Frequent Repair Pattern Recognition
The maintenance requests of the repair service system were recorded in Chinese natural language. There were about 400 records per month, often in one or two short sentences describing the repair location and reasons, so the hidden laws behind these sentences could not be analyzed directly. Unlike English, word segmentation is a crucial preprocessing in Chinese language analysis. Therefore, an open-source Chinese NLP algorithm was adopted. Information including repair floor, department, room, and type of damage was extracted. The system automatically puts similar repairs in the same group as a repair pattern. These patterns were attached to the monthly report. When managers found interesting patterns, they would make some optimization decisions. For example, the washbasin faucets in two Intensive Care Unit (ICU) rooms had been damaged 4 times in December (detailed listed in Table 3). After inspection, it was found that they all belonged to the same brand, so they were all replaced. Despite additional cost, it ensured normal medical activities, and tens of hours of maintenance time were saved.
4.3.4. Low-Quality Maintenance Checking
Some outsourcing companies contracted the maintenance work of some main facility units of the hospital. In the past, there were only simple qualitative evaluation methods to judge the business quality of these outsourcing companies. After using the DT system to manage the maintenance work, the maintenance records of each equipment and its fault repair records could be automatically analyzed. Using the t-test of the hypothesis test method, if the mean value of the repair amount sequence after maintenance was greater than that before maintenance and statistically significant, the quality was considered low. Table 4 lists the fault numbers of two kinds of maintenance. A t-test was executed in three week’s range. The AHU maintenance team was believed of low quality because the value of the hypothesis test was less than 0.1, indicating significantly more faults happening even after maintenance. While maintenance work of elevators was considered normal as usual.
5. Discussion and Conclusion
The exemplary DT project in East Hospital has been running for more than a year and considered reaching desired performance: (1) A survey showed a 10 percent increment in management satisfaction compared to the old clinical building. (2) The overall energy consumption was estimated to save about 1% every year. (3) More than 10% of facility faults and requested repairs were avoided by DT diagnosis. Although the exemplary case was conducted in Shanghai, China, the “continuous lifecycle integration” concept is not limited to countries or regions. Because of common management requirements and similar electric systems, this case will provide some problem-solving references to other modern hospitals around the world.
In summary, according to the proposed concept of continuous lifecycle integration and early movement of the general contractor, a full functional DT was successfully established. This case mainly highlighted in (1) continuous integration of huge data throughout the lifecycle. From design, construction, pre-O&M phase all the way up to the O&M phase, terabytes of static information and dynamic data were managed to integrate as a unified DT system, including building geometry model, attached property information, common BA systems, repair and maintenance systems, security management system, and hospital’s special business systems. The continuous integration process over the full lifecycle and early movement of general contractors have both been proved valid in this paper. This method can be directly employed by similar hospital projects and partially imitated by other complex public buildings. (2) Real-time visual management—managers can grasp the detailed status of the whole hospital by visual management, which is far more efficient than manual work. Big data services were developed as a backend to consistently display high-density data streams. Now, the real-time status of the hospital building is displayed in a modern control center as operation brain guiding everyday management activities. With this real-time mechanism, DT has shown much more potential than traditional BIM technology, which will help professionals upgrade from BIM to DT. (3) Intelligent DT diagnosis functions—professional AI models were assembled as a diagnosis engine, and it works seamlessly with visual management functions. Huge amounts of dynamic integrated data supported timely facility diagnosis and operation suggestions that are automatically sent back to reality. This exemplary case showed the potential strength of AI and modern data analysis skills in DT applications. It is proved that an intelligent diagnosis module values the most, thus should be carefully developed.
During the implementation of the exemplary case, the consultant group found that DT is still not totally adapted to the need of building projects. At least, three aspects of shortages or puzzles required further research:(1)BA systems or medical systems were too professional for the DT platform to directly control. Therefore, the existing DT has not realized the automatic control of the faulty equipment. Now only the real-time alarm was sent back to the control center, and the management personnel will assign the task to the maintenance workers to manually solve the equipment failure. For example, this case did not try to link an automated energy-saving mechanism. All abnormal behaviors were directly processed by on-site works. If the control function was implemented, additional system debugging would be required, which would lead to an unaffordable expense. However, if DT can truly achieve the reliable automatic adjustment of critical machines and autonomously eliminate the fault state, say, reduce energy consumption, it will greatly enhance the practical value of DT.(2)Financial risks are still considerable when using DT widely among building projects. Establishing a DT involves large-scale construction of networks for intelligent sensors, cameras, wireless communicators, etc. Without careful planning at the beginning of the design phase, it will be very difficult or even impossible to add such hardware devices to an as-built building project. Control centers for the management system are also expensive. Therefore, proprietors must have strong motivation and clear foresight. One project should employ DT technologies with no hesitation if proved financially beneficial.(3)Although the early movement of general contractors was proved valid in data processing, system development afterward still involved tedious bargaining with proprietors of the building. There are always sensitive data integrated. If secret data, such as personal data of patients for facial recognition, was open to developers, the borders of safety responsibilities would not be so clear. If not open, the visual management functions of the DT system will be incomplete. Proprietors should find the balance between system function and information safety. Both technical and management innovations are required.
In future research, these puzzles are expected to be addressed by more advanced DT application cases. The practice is believed to be more convincing than pure theory in the DT field because major obstacles often emerge on management and budget issues but not technical issues. Along with accumulating cases, developers can even publish their successful software components as trendy “microservice” modules that can be distributed and downloaded individually. Building industry associations should also make data standards for diagnosis models. According to these public standards, other DT developers just need to process dynamic data from DT into standardized input and then choose a suitable as-built diagnosis model. Advanced AI coders can contribute model repositories like open-source communities, while nonprofessionals do not need to put extra effort into developing existing functions. Ideally, the ecosystem of DT applications will gradually emerge and benefit both users and software developers from the building industry.
Data Availability
The data used to support the case study are available from the corresponding author upon request or download from open data on the product website: https://www.ibuildingsh.com.
Conflicts of Interest
The authors declare no conflicts of interest.
Acknowledgments
This work was financially supported by the Shanghai Industry Internet Development Foundation (2019-GYHLW-01002), Shanghai Rising-Star Program (18QB1402300), and Shanghai Sailing Program (18YF1410400 and 19YF1421100). The authors would like to thank Shanghai East Hospital Affiliated to Tongji University for the authorization to report this case project.