Implementing, Connecting, and Evaluating a Standard-Based Integrated Operating Room within a German University Hospital

Background Digital operating rooms (ORs), when optimally designed and integrated, can reduce the complexity of the surgery suite. However, many integrated ORs are effectively isolated from other IT systems in the hospital because there is little or no connectivity with them. Within the German ﬂ agship project OR.NET, concepts and components were developed for a standard-based connection of the OR with hospital IT systems. Objectives The aim of this work was to implement and evaluate OR.NET concepts and components within the existing IT landscape of a German university hospital. This article describes and evaluates the implemented architecture and processes for connecting a demo OR to existing hospital ITsystems at Heidelberg University Hospital. Methods For the design, establishment, and evaluation of standard-based connections of the demo OR with hospital IT systems, the iterative method “ Design and Creation ” with four iterations was applied. Results A generic and a concrete architecture for several standard-based connection


Background and Significance
Integrated operating rooms (ORs), when optimally designed, can be very effective in increasing quality, risk reduction, and surgery time reduction. 1Integrated ORs are characterized by a functional connection of the OR environment that include audio and video information, surgical and room lights, building automation and medical equipment, as well as routing capabilities of audio/video sources, and the effective control of surgical devices from a central console/workstation/central monitor inside the OR.Over the last years, various medical device manufacturers specialized in integrated ORs across various disciplines.Integrated ORs also offer to connect the surgeon to the world outside the OR by exchanging data with a clinical information system (CIS), electronic medical record system, and a picture archiving and communication system (PACS) or by a remote real-time collaboration with another surgeon.However, a complete OR integration is most often not achieved.While highly coordinated internally, many integrated ORs are effectively isolated from the wider hospital and the wider world because there is little connectivity with other systems. 2 That is why one of the major challenges is the development of standard interfaces for both medical device interoperability and for the seamless integration of the OR with hospital information and communication technology. 3ver the past few years, many programs and projects have targeted medical device interoperability.Internationally, the Medical Device "Plug-and-Play" (MD-PnP) Interoperability Program 4 and the SCOT (Smart Cyber Operating Theater) 5 project have been initiated.MD-PnP promotes innovation in patient safety and clinical care by driving the adoption of patient-centric integration of medical devices and IT systems in clinical environments. 4The objective behind SCOT is to improve the precision and safety of surgery by collecting and integrating all sorts of information, including basic data from medical instruments, intraoperative images captured during surgery, positional data from surgical tools, and the patient's biological information. 5n Germany, innovative technology for planning and supporting specific operations was developed and implemented within the FUSION 6 and orthoMIT 7 projects as part of the guiding vision SOMIT. 8Other projects such as DOOP 9 and smartOR 10 developed and implemented solution strategies for a uniform plug-and-play concept for medical device networking.
The projects mentioned earlier developed innovative networking approaches in the field of medical technology, but only addressed partial aspects of medical device integration within the OR.Integrating medical devices in the OR with hospital information systems is challenging as hospital IT landscapes vary greatly.
The German flagship project "OR.NET -secure, dynamic networking in the operating room and clinic" 11 promoted connectivity of networked medical devices from a holistic point of view by proposing a standardized integration of the OR with hospital IT systems.The project started with a requirement analysis study.Sixteen requirements were formulated and were prioritized with reference to their clinical relevance by clinicians of six German university hospitals. 12Pertaining to the requirements, a high-level architecture based on "Integrating the Healthcare Enterprise" (IHE) integration profiles was defined by Pahontu et al. 13 Within OR.NET, concepts and mechanisms for both medical device-to-device communication and medical device-to-infrastructure (device to hospital IT infrastructure) communication were developed.The overall service-oriented architecture (SOA) for medical device-todevice communication described in the study of Kasparick et al 14 is based on the Device Profile for Web Services (DPWS) standard, 15 while medical device-to-infrastructure communication is presented in the study of Andersen et al. 16 Five demonstration sites with different main purposes were established for presenting and evaluating the concepts and mechanisms, for both medical device-to-device and device-toinfrastructure communications, developed within OR.NET.The following sections describe the objectives of this article, the method used for setting up the demo OR at Heidelberg University Hospital as well as the evaluation method.The result section describes the design and implementation of the demo OR architecture and shows the evaluation results for connecting medical devices with hospital information systems.After that follows a discussion section for our research methodology and evaluation.We conclude our results in the last section.

Objectives
The objective of this article was the evaluation of different connectivity concepts of the OR with hospital IT systems with regard to the fulfillment of requirements collected and prioritized in OR.NET 12 (►Table 1) and the technical feasibility of the proposed architecture for the integration of an OR with existing IT systems and medical devices of a hospital, for example, syntactic and semantic interoperability of used medical devices and software components.Furthermore, the main benefit of OR.NET was evaluated.

Relevant Standards Used for the Integration
In a clinical environment, both "Digital Imaging and Communications in Medicine"-DICOM 17 and "Health Level Seven International"-HL7 18 are the primarily used established communication standards.DICOM provides services for retrieving patient and order data and storing images and measurements from imaging modalities.HL7 is widely used in hospitals in version v2.It defines a protocol for transmitting different types of messages, in particular: • Values measured by medical devices (HL7 ORU-observation results unspecified).• Orders (HL7 ORM-order message).
The initiative "Integrating the Healthcare Enterprise" (IHE) 19 offers integration profiles for connecting medical devices to hospital ITsystems.These describe the information exchange in the form of transactions between at least two actors (roles of application systems) on the basis of existing standards.The IHE Device Enterprise Communication (DEC) integration profile within the Patient Care Device (PCD) domain 20 is available for communication of patient care device data to hospital IT systems.This profile describes how HL7 ORU messages should be used to transfer measured values from medical devices to hospital ITsystems.The used transaction is called IHE PCD-01-Communicate PCD Data.
For medical devices, the ISO/IEEE 11073 standard family is relevant.The IEEE 11073-10101 nomenclature provides standardized codes for the standardized description of medical device components and functionalities.Within OR.NET consortium, three IEEE 11073 extensions were developed for medical device communication:

Method for Setting Up and Evaluating the Demo OR
For setting up and evaluating the demo OR at Heidelberg University Hospital, the iterative design and creation method proposed by Oates 24 was used with the following four iterations: 1. Requirements analysis study-A requirements analysis study using questionnaires and working groups was conducted at the beginning of the OR.NET project.Sixteen clinical requirements (►Table 1) were formulated and prioritized by their clinical relevance 12 and served as demonstration targets.For setting up the demo OR, expert interviews were conducted and additional requirements were conditioned by the physicians of the Department of General, Visceral and Transplantation Surgery and information technology staff of Heidelberg University Hospital.2. Designing the demo OR-First of all, we derived a generic architecture from the high-level architecture plan described by Pahontu et al. 13 Second, we refined and adapted the generic architecture to the additional, spatial, and technical requirements resulting in a concrete architecture through a four-step process: • A medical device market analysis was performed and medical devices were selected in a way that all integration concepts (IHE-PCD, IEEE 11073 SDC, DICOM, and HL7) could be demonstrated and evaluated.Consequently, IHE-PCD-certified medical devices available on the market, medical devices featuring an OR.NET interface (IEEE 11073 SDC), a DICOM interface, and an HL7 interface were planned for equipping the demo OR.
• As a following step, planned medical devices were purchased.• Next, hospital IT systems at Heidelberg University Hospital necessary for connecting the OR were identified.• As a fourth step, data integration and networking paths from hospital IT systems to the OR and backward were defined.
3. Assembling the demo OR-Together with medical device manufacturers and information technology staff of the hospital, the procured medical devices were assembled and connected to the corresponding communication components.4. Evaluating the demo OR-The evaluation of OR.NET concepts was planned parallel to the realization of the demo OR.To evaluate our defined objectives, we checked if the demo OR matches the planned architecture and fulfills the collected requirements. 12Therefore, we defined 22 different test scenarios representing the whole process starting from ordering a surgery up to transmitting the generated data and documentation of the surgery to the hospital information systems.These scenarios include different methods for transmitting patient and order context to medical devices.
To prove interoperability, we performed the defined test scenarios, evaluated the interoperability, and gave feedback to the implementers.After partners had improved their systems, this technical evaluation was repeated.To evaluate the fulfillment of the requirements, we developed semistandardized questionnaires.These questionnaires could Table 1 Requirements sorted by their clinical relevance 12 Average rank Requirements For the assessment of the fulfillment, a quantitative discrete scale from 0 to 5 (0 ¼ requirement is not fulfilled, 5 ¼ requirement is completely fulfilled) was used.
The used questionnaires also offered the possibility to assess the different possibilities to transmit patient and order context to medical devices.Therefore, the clinicians were able to rate these possibilities and to choose which of these possibilities they preferred.
Finally, they were also able to record the main benefit of the OR.NET project.Possible answers were: • Remote control of surgical devices is possible.
• Work in the OR is easier.
• More data for providing healthcare to patients.
• More data for research.
• Basic requisites for improving the efficiency within the OR are established.• Other.
Sixteen clinicians from seven hospitals involved in OR.NET were invited to travel to Heidelberg and to participate in clinical evaluation.During evaluation, the planned test scenarios were performed, discussed, and the corresponding questionnaires were immediately filled in.
The answers captured in the questionnaires were manually transferred to an Excel file and analyzed using basic statistical functions, such as calculating the median or the relative frequency of the answers.

Results
This section presents the requirements analysis results, the planned architecture for designing and implementing the demo OR and the evaluation results.
The following requirements for designing the demo OR were collected: • The demo OR should be designed and equipped as a typical OR including patient monitoring system, ventilation/anesthesia machine, infusion pumps, surgical devices, and imaging devices.• The demo OR should be able to check the requirements that were set at the beginning of the project.• The demo OR should be able to compare different connection concepts for the transfer of patients/order contexts to medical devices.• The demo OR should be able to evaluate the integration of medical device measurements into hospital IT systems.• The demo OR should use the high-level architecture described by Pahontu et al. 13 • The demo OR should be connected to existing hospital's IT systems at Heidelberg University Hospital.

Architecture
This subsection describes the generic and concrete architecture of the demo OR, whereby the concrete architecture is presented on both an application and network level.

Generic Architecture
The generic architecture shown in ►Fig. 1 illustrates components such as hospital information system (HIS), patient data management system (PDMS), PACS, communication server, gateways, and medical devices within the OR.The generic procedure starts with transferring patient and order messages to a communication server.Messages are further transferred to both gateways (HL7 and DICOM) and passed on to medical devices in the OR.This allows data exchange between medical devices and the display of images and values on various displays.Furthermore, medical device images, measures, and surgery reports can be transferred back through the dedicated gateways to hospital information systems.The following application layer gateways for the connection of the demo OR with hospital IT systems were installed and properly configured: • HL7-Gateway and Connector IS (Connector Information Systems) for the translation and propagation of HL7 data from the hospital IT system to the OR using IEEE 11073 SDC and vice versa (detailed information can be found in the study of Andersen et al 16 ).• DICOM-Gateway for the translation and propagation of DICOM objects from hospital IT systems to the OR and vice versa and also for creating DICOM worklists from HL7 ADT/ORM messages.

Concrete Architecture
The demo OR shown in ►Fig. 2 was designed to fit a realistic OR equipped with all needed infrastructure for performing a real surgery, which included a Maquet Alphamaxx OR table in the middle of the room; two Dräger Agilia ceiling supply units, one for each anesthesia and surgical workplace; and KLS Martin marLED OR lights.Furthermore, medical devices (►Table 2) were integrated with hospital IT systems mentioned earlier.
The following integration scenarios were demonstrated: IEEE 11073 SDC integration by using the so-called connectors, which map proprietary messages to SDC, an IHE PCD-01, a DICOM, and an HL7 compliant integration.
The following relevant hospital IT systems of Heidelberg University Hospital were used for connecting the demo OR: • i.s.h.med/IS-H as the Hospital Information System (HIS), designed to manage all aspects of a hospital's operation, such as medical, administrative, and financial services.• Orchestra as communication server for orchestrating and mapping messages between hospital and clinic information systems.• GE-PACS as picture archive and communication system.
• COPRA6 as patient data management system (PDMS) for storing and displaying patient vital signs and medical device parameters like infusion drug and rate.
Test instances of these products were used for evaluation.These instances were clones of the productive ones mainly used for further feature and interface development but provided for a realistic setup of the evaluation.

Application Level
The concrete architecture on the application level is illustrated in separate figures for ease of understanding.►Fig.3 demonstrates HL7 and DICOM inbound interfaces.►Fig.4 depicts HL7 outbound interfaces, and ►Fig.5 shows DICOM outbound interfaces.
• Inbound interfaces (►Fig. 3).For transmitting patient and order context information to medical devices in the OR, HL7 ADT and ORM messages in the version 2.3 are sent from the hospital IT system i.s.h.med to the communication server orchestra.Within the demo OR, we demonstrated three ways to transmit patient and order context information to medical devices:    connection to the Mednovo HL7-Gateway 25 and represents the essential link between medical devices in the OR and hospital IT systems.This connector maps HL7 messages to IEEE 11073 SDC.The context manager groups medical devices into different sessions and sets various contexts depending on the context implementation degree supported by medical devices (detailed information on this component can be found in the studies of Kasparick et al 14 and Andersen et al 16 ).2. Transmitting patient and order information via DICOM.
The second possibility of receiving patient and order information to medical devices was by querying a previously created DICOM worklist.The DICOM-Gateway component of the vendor VISUS 26 created a DICOM worklist from received HL7 ADT and ORM messages.In our scenario, the C-arm retrieved this DICOM worklist.This possibility of transmitting patient and order information by retrieving a DICOM worklist serves also for integrating inventory medical devices at Heidelberg University Hospital that do not feature an IEEE 11073 SDC interface.3. Patient and order context set manually.The third possibility in our scenario is to set the patient context manually, either by configuring and adding the patient name to the patient list maintained by a server component and confirming patient information on the device itself (Philips patient monitoring system) or by hard coupling a medical device to its specific bed location in the case of the Fresenius Kabi infusion pumps.
During surgery, medical devices deliver relevant data for documentation purposes which has to be properly transmitted and integrated into hospital IT systems.For this reason, data emerging from medical devices supporting already established standards such as HL7 were transmitted and displayed to hospital IT systems (i.s.h.med and the COPRA6 PDMS).For example, IHE PCD-01 compliant data directly emerging from Philips patient monitoring system were integrated and displayed within the hospital PDMS COPRA6.For data from Dräger patient monitoring system and anesthesia machine, we implemented an indirect data transmission according to the Device Observation Reporter (DOR) mechanism described in the studies of Kasparick et al 14 and Andersen et al. 16 We implemented a component that collects all information of interest from the SDCcompliant device and performs the transformation of this information to IHE PCD-01 messages.By implementing the IHE PCD-01 transaction, we demonstrated a used case for a vendor-independent acquisition and transmission of medical device measurements to the hospital PDMS COPRA6.Measurements from surgical devices were also acquired by means of the DOR mechanism and stored for visualization and analytics purposes in a separate database.Furthermore, HL7 ORU observation result messages from four infusion pumps were also integrated and displayed in COPRA6.The transfer of IHE PCD-01 and HL7 ORU compliant messages from the medical device network to the hospital IT network was done by means of the HL7-Gateway of the vendor Mednovo Medical Solutions.
At the end of the surgery, a report was created partly semi-automatically (order, practitioner, images) and partly manually (duration, anesthesia, etc.).This report was sent via HL7 MDM message to the orchestra communication server and afterward displayed in i.s.h.med.
• DICOM outbound interfaces (►Fig. 5).DICOM images and videos were sent from the OR microscope, C-arm, and endoscope camera via the DICOM-Gateway to the GE-PACS.

Network Level
On the network level, the following data network concept was implemented (►Fig. 6).The dedicated medical device network (OR network) was connected to hospital IT test systems (Hospital network) via two application layer gateways (HL7 and DICOM) regulating the communication between both networks.Both gateways run on a redundant and virtualized infrastructure.All infrastructure components such as servers, patch panels, switch, and matrix switcher are located in a 19-in server rack in a dedicated, acclimatized technical room adjacent to the demo OR.

Results of the Technical Evaluation
In 19 of 22 test scenarios in ►Table 3, most of the relevant information (order data: 77.5%; results: 91%) was properly forwarded and displayed to corresponding recipients.Test scenarios 17, 21, and 22 failed on execution.
Syntactical and semantical interoperability of ORM and ORU messages were tested manually (ORM message between orchestra and the HL7-Gateway and ORU HL7 messages Table 3 Test scenarios for the evaluation transmitting the data of different patient care devices).ORM and ORU messages were syntactically correct.Tests proving the standard conformance of medical device modeling have been mainly performed with patient care devices (monitoring, ventilation, infusion pumps), as there are no standardized device specializations and IEEE 11073-10101 codes for surgical devices.The device containment tree of the Philips monitoring system was IHE compliant to IHE-TF3. 27To be compliant with the existing device specializations, the data received via SDC connectors from Dräger monitoring system and anesthesia machine had been transformed by other software components.Therefore, the data of Dräger devices could be transmitted to the hospital PDMS in an IHE conformant way.
Manually prompted network disconnections caused lack of transmitted messages (test numbers 21 and 22 in ►Table 3).

Results of the Clinical Evaluation
The evaluation was performed with five clinicians from four different OR.NET hospital partners.The main results were: • Eighty percent of participants missed important information about the planned surgery in the order message such as diagnosis, planned anesthesia method, planned patient position, and required reserves (devices, instrument trays).• All participants preferred to push the context to all devices in combination with a method to confirm the context at the device display due to safety and efficiency reasons.
►Table 4 shows the median of the assisted fulfillment of the collected requirements rated on a scale from 0 (requirement not fulfilled) to 5 (requirement fulfilled).
The fulfillment of the requirement "Transfer of alerts and warnings" was not estimated, as this was not supported by the libraries at the time of evaluation.
Nevertheless, the transmission and display of the surgery report within the EHR for testing purposes was demonstrated successfully various times before and after the clinical evaluation.However, it did not work during clinical evaluation.Thus, the requirement to store reports in the patient electronic health record (EHR) could not be evaluated by the clinicians.
Clinicians estimated the main usage of OR.NET as follows: • Remote control of surgical devices is possible (0%).
• Work in the OR is easier (0%).
• More data for providing healthcare to patients (20%).
• Basic requisites for improving the efficiency within the OR are established (60%).• Other: Easier operation of medical devices due to harmonized human-machine interfaces (20%).

Discussion
We demonstrated the access of preoperative documents and images from various displays in the OR except from the central monitor.However, the clinicians missed this functionality integrated within the overlay software of the central monitor.Clinicians gave poor rates for the requirement of appropriate visualization of data at the central monitor mainly due to the 2-second latency period between visualization at patient monitors and the central monitor.This might have been caused by the actual prototypical implementation.As the appropriate support of alerts was out of the scope of this demo OR, this was not rated in the evaluation.However, clinicians missed this functionality.
Systems developed for special tasks such as the workflow engine or the anesthesia workstation were out of the scope of this evaluation, as these systems were demonstrated and evaluated by other OR.NET demo locations that rather focused on the device-to-device communication than on the device-toinfrastructure communication.The requirement for remote control of medical devices has less priority for operators and clinicians. 12While this requirement involves many risks and uncertainties regarding patient safety and the regulation process, remaining requirements target an improved process optimization.
Test scenario 21 failed probably because the archive service, which stores measurements and resends them after the network connection is available again, was not supported by the device/SDC connector.
Test scenario 22 failed because there was still a need for optimization in the acknowledgment messages (HL7 ACK).
By choosing an iterative method for designing, implementing, and evaluating the demo OR, several issues during this process could be identified and short-term solutions and practices could be developed.
Experiences during the realization of the Heidelberg demo OR show that within such a complex system-ofsystems landscape, the identification of error sources and the determination of the current system state is very demanding.It should be kept in mind that the components developed within the OR.NET project are prototypical implementations without any quality management during implementation process.Some of the OR.NET concepts, such as the MDPWS (medical DPWS) mechanism called safety context, were not available/implemented in the libraries at the time of the evaluation.The OR microscope was still able to remotely control the electrosurgical unit even after completion of the session (test scenario 17 in ►Table 3) because the safety context was not implemented at the time of evaluation.Further details about the safety context mechanism can be found in the study of Kasparick et al. 14 In this article, we presented implementations of various connection concepts for the OR with hospital IT systems.However, these implementations are not synchronized among each other, as the distribution of the patient and order context was different for each integration scenario.
Five people from four different hospitals were able to participate in the clinical evaluation, limiting the statistical significance, but still giving initial insights.
Despite the synchronization issue among the implementations and the limited number of participants in the evaluation, we think that the presented connection concepts/best practices can be transferred and implemented in the future not only by major hospitals but also by smaller ones.

Conclusion
Most of the presented connection concepts of the OR with hospital IT systems were successfully implemented and evaluated within the established demo OR at Heidelberg University Hospital.
As OR.NET was a research project, most of the developed concepts and components were prototypically implemented.At the time of evaluation, the whole technology was not ready for market approval, as interface adaptions by medical device vendors had been still in progress.Also, there have been issues regarding the heterogeneity of SDC interface versions as well as security topics.
However, there is active development on all listed issues with the goal of pursuing a new market approval of standard-based networked medical devices in the near future.
As a result of our demonstration for the feasibility of the OR.NET concepts, parts of these concepts will be used as a blueprint for the equipment of the new surgery building at Heidelberg University Hospital at the end of 2019.

Clinical Relevance Statement
An open integration of medical devices within the OR and with hospital IT systems offers a broad spectrum of opportunities with regard to the digital transformation of the hospital.Practitioners will profit from the socalled smart services based on data emerging from various medical devices, such as the automatic phase recognition of surgery or an automatically created OR report.Operators of hospital information systems will be able to integrate medical devices from various device manufacturers on a uniform way, avoiding different integration solutions for each medical device manufacturer.

4
u t o m a t i c c o n t r o l 6 4.1 Data, image and video fusion 6 4 .2 W o r k flow control 5 1 .6 T e l e m e d i c i n Remote maintenance capture how clinicians rate the fulfillment of the corresponding requirements and note the missing functionality.

Fig. 3
Fig. 3 Inbound interfaces of the concrete architecture and process.

Fig. 4 Fig. 5
Fig. 4 HL7 outbound interfaces of the concrete architecture and process.

Fig. 6
Fig. 6 Data network concept for connecting the demo OR to Heidelberg University Hospital IT test systems.

Table 4 5 Appropriate storage of data of surgical devices 4 5 5
Median of the fulfillment of the collected requirements rated on a scale from 0 (requirement not fulfilled) to 5 (requirement fulfilled) by five clinicians (n i ¼ number of clinicians evaluating the requirement) from four different clinics Requirement Median n i Missed functionality information by the user Remote control of devices 4 5 Prohibition of unauthorized remote control; clarification of responsibility Appropriate storage of patient data 5 Storage and retrieval of pictures captured during surgery 4 5 No integration in devices Storage and retrieval of videos captured during surgery 4 Better usability; easier to sort

•
IEEE P11073-10207 21 -Standard for Domain Information & Service Model for service-oriented Point-of-Care medical device communication.• IEEE P11073-20701 22 -Standard for Service-oriented Medical Device Exchange Architecture and Protocol Binding.• IEEE 11073-20702 23 -Standard for Medical Device Profile for Web Services (MDPWS).

Table 2
Medical devices integrated with hospital IT systems at Heidelberg University Hospital