gms | German Medical Science

In today’s operating theatre there exists no communication platform which allows unified data exchange among surgical assist systems (SAS), e.g. imaging, navigation or mechatronic devices [Ref. 1], [Ref. 2], [Ref. 3]. This lack of a standard communication platform makes integration difficult, which prevents interoperability and flexibility when trying to connect and use several devices simultaneously. Smooth, flexible and vendor-independent interoperation of different SAS is a fundamental requisite for the Operating Room of the future. Many SAS have good functionality as stand-alone facilities, but fail when working together with other devices.

The lack of interoperability and flexibility has important negative effects on the working conditions within the operating room. For example, each of the stand-alone devices will usually try to supply all information to the surgeon. This creates very poor human-machine interfaces, where information tends to be redundant and forces the surgeon to continuously change the focus of attention to look for the relevant data required at each step of the procedure. Further, many tasks cannot be done according to the user’s needs or wishes. The user is forced to be satisfied with less than optimal solutions, even when technically the problem could be better solved. Interconnection may improve the range of technical possibilities and allow more flexible user interaction.

A clear example of this problem is to be found in the mechatronic assistance systems. These are usually systems conceived to perform a particular active task and are mostly self-contained and closed. They provide all information perceived to be relevant to the task at hand and are usually difficult to connect to other clinical systems.

One of the main research objectives within the Innovation Center Computer Assisted Surgery (ICCAS) is the integration of surgical assist systems in the operating theatre and the development of a Surgical Picture Acquisition and Communication System (S-PACS). The basis for this is the development of a common standard such as DICOM in surgery. The S-PACS architecture should be based on well defined standards and definitions for communication and interoperability in order to allow flexible and vendor-independent operation of devices within the OR. The development of a prototype S-PACS will conform to the common systems engineering cycle with the following main steps: (a) concept, (b) specification, (c) modular and detail design, (d) implementation, (e) testing, (f) application and (g) maintenance.

The conceptual phase is underway at ICCAS and some interesting results have been already obtained. As it has been previously noted [Ref. 4] for a project of this kind to be successful, it is very important to have user involvement, support of the management and a clear statement of the requirements. In order to meet these conditions, the concept design has been driven by a series of interdisciplinary workshops. Clinical users and engineers together have employed the Quality Deployment Function (QFD) tool to draft the user requirements.

Quality function deployment (QFD) is a structured and quantitative method to identify customer needs under the umbrella of constancy of purpose. It can play an important role in systems engineering for implementations that are cross-functional and complex [Ref. 5]. QFD starts with a brainstorming of the user requirements within the scope of the problem. These are then structured in a tree and each node in the tree is assigned with an importance rating (IR) as agreed by the group of users. Later in the process, the user requirements (quality) are combined with engineering attributes (function) in a matrix. This matrix allows an efficient implementation (prototyping) to be performed according to the user’s needs, because the engineering attributes are mapped to the user requirements.

A second step after the specification of the user requirements is the identification of the system functionalities. In the case of mechatronic assist systems, in order to organise their functionalities we have grouped them first according to their automation degree. We have based our categories on the work by Parasuraman et al. [Ref. 6]. They define several levels of automation depending on the degree of involvement of human and system during planning and the clinical procedure. Thus an automation degree of one means that all activity is carried out by the human, while the system is totally inactive. On the other hand, the highest automation degree would mean a system which can plan and perform the operation autonomously, while the human wouldn’t have any influence at all. Intermediate levels show a growing involvement of the system and a decreasing one of the human.

As it has been previously reported [Ref. 7], the joint work of clinical users and engineers has already produced a first description of the S-PACS system components. Table 1 [Tab. 1] shows the first level of this structure.

Using the concept of automation degrees, the system components identified within the mechatronic assist systems were found to show automation degrees between three and six. Table 2 [Tab. 2] gives the characteristics of these levels of automation in terms of human and system involvement. Also, examples for each category are given. Typical systems with a degree of automation three are the common navigation platforms. They can be used to assist during preoperative planning and offer passive assistance in the form of pose information during the surgical procedure. The surgeon performs the planning with the system’s help and during operation must actively take note of the new data available. Systems in level four are basically analogous but will offer active assistance by calling the human’s attention to predetermined events, e.g. use alarms to warn of some danger. Still, the human decides how to react to such an event. Typical examples are navigation systems with alarms or telemanipulator slave arms where the passive assistance in the form of tremor filtering, motion scaling, etc.

A crucial difference in the systems with a degree of automation five is their ability to automatically take active action in some specific parts of the operation. Thus based on the current situation and possibly depending on a set of predefined circumstances, the system may be able to change its own state. This will probably be coupled with some appropriate notification to the human. When using this type of systems, the human is passive during small parts of the operation, when the system takes control. Examples of such systems are needle positioning robots and tracked instruments with automatic functionality. Among the latter, the FESS Control system [Ref. 8] is able to turn on and off a milling instrument based on navigation data and a preoperatively defined workspace. Finally, systems with a level of automation six are able to automatically perform the surgical procedure with the human assuming a control function. However, these systems, usually robots, offer only assistance during planning.

We present the results of the first steps in the conceptual design towards integrating mechatronic systems into an open Surgical PACS architecture. The components functionalities must be further refined and organised to allow for an efficient and hierarchical implementation of the required capabilities. In order to effectively drive this efforts, at ICCAS and in cooperation with other partners we are currently developing prototypes of S-PACS compliant mechatronic systems.