CC-BY 4.0 · ACI Open 2018; 02(01): e10-e20
DOI: 10.1055/s-0038-1639604
Original Article
Georg Thieme Verlag KG Stuttgart · New York

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

Raluca Dees
1  Department of Medical Information Systems, Heidelberg University Hospital, Heidelberg, Germany
,
Angela Merzweiler
1  Department of Medical Information Systems, Heidelberg University Hospital, Heidelberg, Germany
,
Gerd Schneider
1  Department of Medical Information Systems, Heidelberg University Hospital, Heidelberg, Germany
,
Martin Kasparick
2  Institute of Applied Microelectronics and Computer Engineering, University of Rostock, Rostock, Germany
,
Lars Mündermann
3  Department of Research and Technology, Karl Storz GmbH and Co. KG, Tuttlingen, Germany
,
Janko Ahlbrandt
4  Center for Information and Medical Technology, Heidelberg University Hospital, Heidelberg, Germany
,
Martin Wagner
5  Minimally Invasive Surgery Section, Department of General, Visceral and Transplantation Surgery, Heidelberg University Hospital, Heidelberg, Germany
,
Hannes Kenngott
5  Minimally Invasive Surgery Section, Department of General, Visceral and Transplantation Surgery, Heidelberg University Hospital, Heidelberg, Germany
,
Beat P. Müller-Stich
5  Minimally Invasive Surgery Section, Department of General, Visceral and Transplantation Surgery, Heidelberg University Hospital, Heidelberg, Germany
,
Björn Bergh
1  Department of Medical Information Systems, Heidelberg University Hospital, Heidelberg, Germany
› Author Affiliations
Funding This work has been funded by the German Federal Ministry of Education and Research under reference number 16KT1201K as part of the OR.NET project.
Further Information

Address for correspondence

Dipl.-Inform. Raluca Dees
Department of Medical Information Systems, Heidelberg University Hospital
Im Neuenheimer Feld 130.1, 69120 Heidelberg
Germany   

Publication History

14 February 2018

14 February 2018

Publication Date:
03 May 2018 (online)

 

Abstract

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 flagship 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 IT systems 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 concepts of the demo OR were developed. Furthermore, the concrete architecture was implemented and evaluated for its technical and clinical relevance. The main benefits of the project were the establishment of basic requisites for improving the efficiency within the OR, easier operation of medical devices as a result of harmonized human–machine interfaces, and providing additional data for improving healthcare.

Conclusion OR.NET concepts for a standard-based connection of the OR with hospital IT systems have proven to be promising. They can serve as a reference for further integration scenarios in other hospitals.


#

Background and Significance

Integrated operating rooms (ORs), when optimally designed, can be very effective in increasing quality, risk reduction, and surgery time reduction.[1] Integrated 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.[3]

Over 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.[4] The 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.[5]

In 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.[8] Other 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.[12] Pertaining 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-to-device 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-to-infrastructure 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.

Table 1

Requirements sorted by their clinical relevance[12]

Average rank

Requirements

13

1.1 Accessing patient data, findings, and documents

13

1.2 Visualization of device data

11

1.3 Transfer of alerts and warnings

11

1.4 Image and video transfer within the OR

11

3.1 Clinical documentation

11

3.2 Image documentation

10

1.5 Accessing images and videos from the OR network, coming from the hospital IT systems

10

2.1 Manual control

10

3.3 Video documentation

6

4.3 Protocol transfer

6

2.2 Automatic control

6

4.1 Data, image and video fusion

6

4.2 Workflow control

5

1.6 Telemedicine

5

2.3 Manual remote control

4

2.4 Remote maintenance


#

Materials and Methods

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).

  • Patient data (HL7 ADT—admission, discharge, transfer).

  • Surgical reports (HL7 MDM—medical document management).

The initiative “Integrating the Healthcare Enterprise” (IHE)[19] offers integration profiles for connecting medical devices to hospital IT systems. 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 IT systems. 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:

  • 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).

All three standards together are called IEEE 11073 SDC (Service-oriented Device Connectivity) family. During the OR.NET project, the synonym Open Surgical Communication Protocol (OSCP) was used.


#

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.[12] Therefore, 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 semi-standardized questionnaires. These questionnaires could capture how clinicians rate the fulfillment of the corresponding requirements and note the missing functionality. 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.

Zoom Image
Fig. 1 Generic architecture and process.

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.

Table 2

Medical devices integrated with hospital IT systems at Heidelberg University Hospital

Medical device

Model

Medical device vendor

3D C-arm

Vision RFD 3D

Ziehm Imaging GmbH

OR microscope

HS MIOS 5

MÖLLER-WEDEL GmbH & Co KG

Endoscopy tower

D-Light P (light source)

Endoflator 50 (insufflator)

Hamou Endomat (suction/irrigation pump)

Autocon II 400 (electrosurgical unit)

Unidrive S III (motor system)

Image I S (endoscopy camera)

KARL STORZ GmbH & Co. KG

Patient monitoring system

Infinity Delta

Drägerwerk AG & Co. KGaA

Anesthesia machine

Primus

Drägerwerk AG & Co. KGaA

Patient monitoring system

IntelliVue MX800

Philips GmbH Market DACH

Infusion pumps

Injectomat Agilia

Fresenius Kabi GmbH

Zoom Image
Fig. 2 Demo OR at Heidelberg University Hospital.

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.

Zoom Image
Fig. 3 Inbound interfaces of the concrete architecture and process.
Zoom Image
Fig. 4 HL7 outbound interfaces of the concrete architecture and process.
Zoom Image
Fig. 5 DICOM outbound interfaces of the concrete architecture and process.

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:

1. Transmitting patient and order information via IEEE 11073 SDC (OSCP). Medical devices supporting this communication stack (IEEE 11073 SDC) such as the OR microscope, patient monitoring system (Dräger), anesthesia machine (ventilation), and the endoscopy tower received patient and order information by means of the connector IS (using a push mechanism) and the context manager components. Connector IS has a 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.

HL7 outbound interfaces ([Fig. 4]).

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 SDC-compliant 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.

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

#
#
#

Evaluation Results

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.

Table 3

Test scenarios for the evaluation

Test no.

Test scenario

Post condition

1

For the patient Erwin Test, an order is created in i.s.h.med (diagnosis C20, requested surgery: laparoscopic rectal resection) and sent to the connector IS

Relevant information about the order must have arrived at connector IS

2

The order is transferred from connector IS to the SDC software connector of the electrosurgical unit (made visible via overlay software)

Relevant information about the order is visible on the overlay

3

The order is transferred from the connector IS to the microscope

Relevant information of the order is visible on the microscope display

4

Dynamically changing measurements (blood pressure, heart rate, and oxygen saturation) are recorded and displayed on the Dräger patient monitor and the overlay

The measured values of the Dräger patient monitor match the displayed values of the overlay

5

Ventilation of a medical doll under different ventilation settings and comparison of the measurements on the anesthesia device with the displayed values on the overlay

The displayed ventilation parameters on the anesthesia machine match the measured values displayed on the overlay

6

The settings of the electrosurgical unit are changed and this information is transferred to the overlay

The settings of the electrosurgical unit match the values displayed on the overlay

7

Measurement of dynamically changing values (blood pressure, heart rate, and oxygen saturation) of a medical doll and transmission of the measured values via the HL7 gateway to COPRA (comparison of the measured values on the Philips patient monitor with the measured values displayed in COPRA)

The measured values are transmitted successfully to COPRA

8

Measurement of the blood pressure at a test person and transmission to COPRA via the HL7 gateway (comparison of the measured values on the Philips monitor with the measured values displayed in COPRA)

The results of the blood pressure measurements match to the measured values displayed in COPRA

9

The settings of the infusion pumps (rate, bolus) are changed. This information is transmitted via the HL7 gateway to COPRA. Comparison of the settings with the values transmitted to and displayed within COPRA

The values of the infusion pumps are successfully updated in COPRA

10

The dynamically changing measured values of the Dräger patient monitor are sent to COPRA via the HL7 gateway

The values of the Dräger patient monitor match the values within COPRA

11

An image is recorded with the OR microscope and sent to JiveX

The image is available within JiveX with the correct patient context data

12

A video is recorded with the OR microscope and sent to JiveX

The video is available within JiveX with the correct patient data

13

An image is recorded with the endoscopy camera and sent to JiveX

The image is available within JiveX with the correct patient data

14

Transfer of an image stored on the C-arm to JiveX

The image is available within JiveX with the correct patient data

15

Remote control of the electrosurgical unit from the OR microscope

The control parameters are updated accordingly at the overlay

16

The session is terminated within the context manager component

The surgery order is no longer available on the overlay

17

The electrosurgical unit is remotely controlled from the microscope after completion of the session

The electrosurgical unit can no longer be remotely controlled from the microscope

18

An image is sent from JiveX to the GE-PACS

The image is available within the GE-PACS and is assigned to the correct patient

19

A video is sent from JiveX to the GE-PACS

The video is available within the GE-PACS and is assigned to the correct patient

20

A surgery report is created and sent to the archive

The surgery report is available within the archive

21

The network cable of the SDC connector has been unplugged

The measured values are still available

22

The network cable between the DOR component and connector IS has been unplugged

The messages are not lost

Abbreviations: DOR, Device Observation Reporter; OR, operating room; SDC, Service-oriented Device Connectivity.


Syntactical and semantical interoperability of ORM and ORU messages were tested manually (ORM message between orchestra and the HL7-Gateway and ORU HL7 messages 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.[27] To 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).

Table 4

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

Access to preoperative documents

3

3

Access from the central monitor

Access to preoperative images

3.5

4

Access from the central monitor or other devices

Appropriate visualization of data at the central monitor

2

5

Important information like alerts or workflow; quicker actualization rate of measurements

Transmission of videos

5

5

Access to surgery data via an external monitor by authorized users

4

5

Retrieval of special information by the user

Remote control of devices

4

5

Prohibition of unauthorized remote control; clarification of responsibility

Appropriate storage of patient data

5

5

Appropriate storage of data of surgical devices

4

5

Storage and retrieval of pictures captured during surgery

4

5

No integration in devices

Storage and retrieval of videos captured during surgery

4

5

Better usability; easier to sort

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%).

  • More data for research (0%).

  • 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-to-infrastructure communication.

The requirement for remote control of medical devices has less priority for operators and clinicians.[12] While 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-of-systems 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.


#
#

Conflict of Interest

None declared.

Acknowledgments

We thank the following OR.NET partners and other companies: Mednovo Medical Software Solutions, VISUS Technology Transfer GmbH, Möller-Wedel GmbH, Ziehm Imaging GmbH, RWTH Aachen, Philips GmbH, and Fresenius Kabi GmbH.

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 so-called 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.


Protection of Human and Animal Subjects

Neither human nor animal subjects were included in the project.



Address for correspondence

Dipl.-Inform. Raluca Dees
Department of Medical Information Systems, Heidelberg University Hospital
Im Neuenheimer Feld 130.1, 69120 Heidelberg
Germany   


Zoom Image
Fig. 1 Generic architecture and process.
Zoom Image
Fig. 2 Demo OR at Heidelberg University Hospital.
Zoom Image
Fig. 3 Inbound interfaces of the concrete architecture and process.
Zoom Image
Fig. 4 HL7 outbound interfaces of the concrete architecture and process.
Zoom Image
Fig. 5 DICOM outbound interfaces of the concrete architecture and process.
Zoom Image
Fig. 6 Data network concept for connecting the demo OR to Heidelberg University Hospital IT test systems.