A service for monitoring the quality of intraoperative cone beam CT images

Frank Heckel; Jan Schlamelcher; Hanna Rotermund; Max Rockstroh; Stephan Zidowitz; Thomas Neumuth

doi:10.1515/cdbme-2016-0161

Article Open Access

A service for monitoring the quality of intraoperative cone beam CT images

Frank Heckel , Jan Schlamelcher , Hanna Rotermund , Max Rockstroh , Stephan Zidowitz and Thomas Neumuth

Published/Copyright: September 30, 2016

Published by

Become an author with De Gruyter Brill

Author Information Explore this Subject

From the journal Current Directions in Biomedical Engineering Volume 2 Issue 1

Abstract

In recent years, operating rooms (ORs) have transformed into integrated operating rooms, where devices are able to communicate, exchange data, or even steer and control each other. However, image data processing is commonly done by dedicated workstations for specific clinical use-cases. In this paper, we propose a concept for a dynamic service component for image data processing on the example of automatic image quality assessment (AQUA) of intraoperative cone beam computed tomography (CBCT) images. The service is build using the Open Surgical Communication Protocol (OSCP) and the standard for Digital Imaging and Communications in Medicine (DICOM). We have validated the proposed concept in an integrated demonstrator OR.

Keywords: CBCT; DICOM; digital operating room; image quality assessment; MDPWS; SOA

1 Introduction

Three-dimensional medical images acquired by computed tomography (CT) and magnetic resonance imaging (MRI) play a central role in today’s medicine. They are used preoperatively for diagnosis and therapy planning in order to find the best treatment for the patient. Intraoperative imaging is used to guide the surgeon during the intervention, so he or she is able to apply the preoperative plan such that the patient gets the best possible outcome. A common intraoperative imaging modality is ultrasound. A 3D imaging modality that is becoming more and more popular is cone beam computed tomography (CBCT). CBCT is often acquired by a mobile “C-arm” and used in various clinical applications, such as spine surgery, dental surgery, and interventional radiology [1], [2], [3], [4]. One drawback of CBCT is the fact that the surgeon frequently has to leave the operating room (OR) during acquisition due to radiation exposure [5]. After inspection of the images, the surgeon decides whether their quality is sufficient. If not, the acquisition has to be repeated.

In recent years, operating rooms have transformed from a collection of independent medical devices into interconnected digital (“integrated”) operating rooms, where devices are able to communicate, exchange data, or even steer and control each other [6]. While large vendors, such as Karl Storz, provide proprietary solutions for integrated ORs (Karl Storz OR1^[1]), there are also attempts for standardization and open communication protocols. Examples include OpenIGTLink [7], TiCoLi [8], SCOT [9], smartOR [10], and the Open Surgical Communication Protocol (OSCP) [11]. For image data exchange, the standard for Digital Imaging and Communications in Medicine (DICOM) has been widely accepted and implemented [12].

Despite this trend to interconnected devices, image data processing is commonly done by dedicated workstations for specific clinical use-cases, such as navigation systems. In this paper, we propose a concept for a dynamic service component for image data processing on the example of automatic image quality assessment (AQUA) of intraoperative CBCT images. The service is build using OSCP and DICOM.

2 Material and methods

The devices involved in the implementation of the proposed concept are shown in Table 1. For OSCP we used version 0.96_06 of the C++ library OSCLib^[2] that has been developed by SurgiTAIX AG.

Table 1

Devices involved in the image quality analysis setting.

Component	Device
C-arm	Ziehm Vision RFD 3D^a
PACS	VISUS JiveX^b
DICOM gateway	Prototype by OFFIS e.V. [13]
AQUA service	Prototype by Fraunhofer MEVIS based on MeVisLab^c

^ahttp://www.ziehm.com/us/products/ziehm-vision-rfd-3d.

^bhttp://www.visus.com/en/jivex-products.html.

^chttp://www.mevislab.de.

2.1 The open surgical communication protocol

OSCP has been developed as part of the project OR.NET [11], whose goal was to create a service-oriented architecture (SOA) for the safe and secure dynamic (plug-and-play) interconnection of medical devices in the OR. OR.NET builds on the methods and information models defined in ISO/IEEE 11073 [14]. In contrast to the binary protocol specified in ISO/IEEE 11073, OR.NET defines the alternative communication protocol OSCP that is based on Medical Device Profile for Web Services (MDPWS). MDPWS is currently in the process of standardization.

Using OSCP, a medical device is represented by a description and a state, which are given in the Medical Device Information Base (MDIB). A device is accessed by retrieving its description, which models its values and available controls. For each value in the description, a corresponding value exists in the state, which can be retrieved or set by any other device. MDPWS also defines a discovery mechanism that uses multicast messages in order to find devices in a network. Finally, MDPWS offers events and alarms.

2.2 Automatic image quality assessment

The basis of the AQUA framework are so called tests that calculate a certain property or feature of an image. For those tests we distinguish between atomic tests, which only require the input image, and complex tests, which require additional inputs. The additional inputs are computed by test preconditions. An example for a complex test is the signal-to-noise ratio that requires both a fore- and background mask as preconditions. Multiple tests and preconditions for a specific use-case can be combined in a test set. The tests are controlled by a management layer that sets up the execution environment, executes the tests with a problem-specific parametrization, and stores their results. The last step is the use-case specific interpretation of all test results (cf. Figure 1).

Figure 1

Basic architecture of the AQUA framework.

In the CBCT use-case we are testing four image quality characteristics: the resolution, the signal-to-noise ratio, a generic quality index that measures sharpness, and the amount of metal artifacts. The results are combined using a voting mechanism, for which we first define a set of possible options, represented by a value o ∈ [0, 1]. Each option o_i is rated based on the result of each test t_j with a vote v ∈ [0, 1], where v = 1 refers to “fully agree” and v = 0 to “fully disagree”. The best option r is given by

(1)r=arg maxi(minj (v⁢(oi,tj))).

In our use-case we defined the options o₁ = 0.0 as “bad”, o₂ = 0.7 as “acceptable”, and o₃ = 1.0 as “good”. The specific test results are mapped v̂ ∈ [0, 1] according to the empirically defined functions shown in Figure 2A. The voting v for each option o is computed according to the test-specific linear mapping of v̂ shown in Figure 2B. As the overall quality of the CBCT images is mainly influences by metal artifacts and the signal-to-noise ratio, the votes of those tests are more restrictive. For visualization of the test results, the user interface shown in Figure 3 is provided, where the overall rating of the image’s quality is summarized by an intuitive traffic sign pictogram.

Figure 2

Mapping functions for voting: (A) mapping of test-specific results to [0, 1], and (B) rating of a specific option o.

Figure 3

Graphical user interface of the AQUA component.

The design of the voting system also allows the deduction of the reason for bad image quality. Assuming that the options o_i are sorted by increasing quality, all tests t_j with v(o_i, t_j) < min_j(v(o_r, t_j)) and i > r prevent a better voting. The features that are measured by those tests can hence be assumed to cause the bad image quality.

2.3 Device communication

The communication between the devices is shown in Figure 4. The devices use the MDPWS discovery mechanism to find each other. The AQUA component provides two DICOM services: one that listens to Modality Performed Procedure Step (MPPS) messages and one that allows a Picture Archiving and Communication System (PACS) to send DICOM files. After sending the image data to the PACS, the C-arm sends an MPPS message to the AQUA service. This message contains, besides others, the unique Series Instance UID that allows the AQUA service to request the image data from the PACS using the standard DICOM Query/Retrieve service. All DICOM communication in done transparently through the DICOM gateway [13].

Figure 4

Communication of the devices in the CBCT setting.

The analysis is initiated as soon as the image data becomes available to the AQUA service. Finally, the results of the image quality analysis are send to other devices in the OR network using OSCP so they can be shown on a central or mobile display for example.

3 Results

We have validated our prototypical implementation of the described concept as part of a demonstrator operating room that has also been presented during this year’s conhIT conference. Besides the components shown in Table 1, this demo OR also integrated a lot of other medical devices using OSCP. In this setting, ionizing radiation was not allowed. Therefore, image acquisition and reconstruction was simulated by the C-arm. For image quality assessment, three exemplary 3D images of a head phantom were provided: one high-quality image, one reconstruction with suboptimal signal-to-noise ratio, and one image with severe metal artifacts. The AQUA service was able to distinguish between these exemplary images and it correctly returned the reason for bad image quality.

The overall time required by the whole processing pipeline (i.e. from sending the CBCT images to the PACS until the image quality analysis) was about one minute. The DICOM-based communication was reliable. At the time of evaluation, we had some significant delays during the discovery process, which took several minutes, and which did not always work robustly. As a workaround, we cached the devices that have been found. Since the gateway ignores inaccessible devices anyway, this does not affect the runtime behavior.

4 Discussion and conclusion

We have shown a concept for implementing a dynamic service component for image processing in an integrated OR using standardized and open protocols. The setting included hard- and software from different vendors and research institutes. We were able to successfully connect different devices using OSCP, notify an image processing component about intraoperatively acquired CBCT data in real time, and retrieve it from PACS using DICOM.

The proposed solutions enable an immediate and fully automatic 3D image processing pipeline within an integrated OR. Image processing services can run on any device that can be dynamically added and removed from the network in order to provide specific functionality. This is not limited to image analysis. For example, a service that automatically prepares a 3D reconstruction of an intraoperative 3D image could be implemented using the same concepts.

The image quality assessment service provides a monitoring component that is able to permanently review the quality and validity of intraoperatively acquired images in an integrated OR. Applications to this include for instance navigated interventions, where high accuracy is required that is often limited by image quality. Another use-case for an AQUA service is surgery documentation, where low-quality images could automatically be tagged or excluded for example.

The remaining problems with the discovery process have already been reduced in the latest version of OSCLib (0.97_09) and can be expected to be completely solved in the future as the implementations of OSCP become final. As an extension of the proposed solution and in order to provide the results of the AQUA service to other DICOM devices, the test results as well as the ratings could be stored as DICOM Structured Reporting (SR) documents using the Key Object Selection document template^[3].

Author’s Statement

Research funding: This work was funded by the German Ministry of Education and Research (BMBF) as part of the project OR. NET (reference number: 16KT1232). Conflict of interest: Authors state no conflict of interest. Material and methods: Informed consent: Not applicable. Ethical approval: The conducted research is not related to either human or animals use.

References

[1] Rafferty MA, Siewerdsen JH, Chan Y, Daly MJ, Moseley DJ, Jaffray DA, et al. Intraoperative cone-beam CT for guidance of temporal bone surgery. Otolaryngol Head Neck Surg. 2006;134:801–8.10.1016/j.otohns.2005.12.007Search in Google Scholar PubMed

[2] Scarfe WC, Farman AG. What is cone-beam CT and how does it work? Dental Clinics of North America. 2008;52;707–30.10.1016/j.cden.2008.05.005Search in Google Scholar PubMed

[3] Wallace MJ, Kuo MD, Glaiberman C, Binkert CA, Orth RC, Soulez G, et al. Three-dimensional c-arm cone-beam CT: applications in the interventional suite. J Vasc Interv Radiol. 2009;20:S523–37.10.1016/j.jvir.2009.04.059Search in Google Scholar PubMed

[4] Schafer S, Nithiananthan S, Mirota DJ, Uneri A, Stayman JW, Zbijewski W, et al. Mobile c-arm cone-beam CT for guidance of spine surgery: image quality, radiation dose, and integration with interventional guidance. Med Phys. 2011;38:4563–74.10.1118/1.3597566Search in Google Scholar PubMed PubMed Central

[5] Nottmeier EW, Bowman C, Nelson KL. Surgeon radiation exposure in cone beam computed tomography-based, image-guided spinal surgery. Int J Med Robot. 2012;8:196–200.10.1002/rcs.450Search in Google Scholar PubMed

[6] Mildner A, Janß A, Dell’Anna-Pudlik J, Merz P, Leucker M, Radermacher K. Device- and service profiles for integrated or systems based on open standards. Curr Dir Biomed Eng. 2015;1:538–42.10.1515/cdbme-2015-0128Search in Google Scholar

[7] Tokuda J, Fischer GS, Papademetris X, Yaniv Z, Ibanez L, Cheng P, et al. Openigtlink: an open network protocol for image-guided therapy environment. Int J Med Robot. 2009;5:423–34.10.1002/rcs.274Search in Google Scholar PubMed PubMed Central

[8] Gessat M, Bohn S, Vorunganti A et al. “TiCoLi: an open software infrastructure for device integration in the digital OR. Int J Comput Assist Radiol Surg. 2011;1:284.Search in Google Scholar

[9] Iseki H, Muragaki Y. Sensor technology and the medical information guided operating theater (smart cyber operating theater: SCOT). Journal of the Institute of Electrical Engineers of Japan. 2012;132:409–12.10.1541/ieejjournal.132.409Search in Google Scholar

[10] Köny M, Benzko J, Czaplik M, et al. Distributed Networks: Intelligence, Security, and Applications. CRC Press; 2013, ch. The Smart Operating Room: smartOR. p. 291–315.10.1201/b15282-12Search in Google Scholar

[11] Kühn F, Leucker M. OR.NET: safe interconnection of medical devices. In International Symposium on Foundations of Health Information Engineering and Systems; 2014. p. 188–98.10.1007/978-3-642-53956-5_13Search in Google Scholar

[12] Mildenberger P, Eichelberg M, Martin E. Introduction to the DICOM standard. Eur Radiol. 2001;12:920–7.10.1007/s003300101100Search in Google Scholar PubMed

[13] Schlamelcher J, Onken M, Eichelberg M, Hein A. Dynamic DICOM configuration in a service-oriented medical device architecture. Conf Proc IEEE Eng Med Biol Soc. 2015;2015:1717–20.10.1109/EMBC.2015.7318708Search in Google Scholar PubMed

[14] Andersen B, Dehm J, Gessner C et al. Intraoperabilität von Geräten und Systemen in OP und Klinik, 2nd ed. VDE Verband der Elektrotechnik Elektronik Informationstechnik e.V., 2015.Search in Google Scholar

Published Online: 2016-9-30

Published in Print: 2016-9-1

This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License.

Articles in the same Issue

https://doi.org/10.1515/cdbme-2016-0161

Keywords for this article

CBCT; DICOM; digital operating room; image quality assessment; MDPWS; SOA

Creative Commons

BY-NC-ND 4.0