HealthManagement, Volume 15 - Issue 1, 2015

Interoperability Standards for Medical Device Integration in the OR

share Share

The Digital Operating Room

Advances in medical technology, specifically information technology (IT), in the last quarter of the 20th Century have produced extraordinary changes in the way medicine, and in particular surgery, is practised. These advances have not been without certain drawbacks and shortcomings, including escalating healthcare costs and the challenge of handling the complexity of these technologies.


It has been challenging to cost-justify many of the new technological and system advances, associated interventional procedures and the corresponding redesign of healthcare infrastructures, for example, for the Operating Room (OR). The development and dissemination of these technologies have become central issues in the debate over healthcare reform and healthcare finance.

Figure 1. DOR Maturity Levels

In particular, a number of major technical and organisational challenges are being faced in the attempt to improve the safety and effectiveness of connectivity/ interoperability for the diverse array of medical devices and information technology that proliferates in the OR environments today. These have been clearly identified in recent years, for example by J. M. goldman, MD, (Director, CIMIT Program on Interoperability, and Medical Device “Plug-and-Play” Interoperability Program), as challenges in their MD PnP Program (goldman 2007):


• Proprietary medical device systems; long capital equipment cycles (12 years!);

• Limited comprehensive, vetted user requirements (clinically/safety-based);

• Absence of proven standards matched to clinical requirements;

• Tendency to silo standards that would limit interoperability across continuum of care;

• Limited funding for development;

• Limited recognition of complexity of challenges in IT-BME convergence and lack of system; integrators to build the middleware;

• Legal (liability) concerns;

• Regulatory pathway questions.


In the current MD PnP Program (MD PnP Program 2014) it is interesting to note, that user requirements in the program are established by means of explicit clinical scenarios – i.e. workflow analysis of clinical scenarios at a level of detail needed to create the basis of interoperability solutions and to derive engineering requirements.


In the context of international approval procedures and, relating to the challenge of “Regulatory Pathway” transparency and reduced complexity, the MD PnP Program is leading a working group of companies, academics, and hospitals that are developing a prototype regulatory submission to help refine the FDA clearance process (see FDA workshop content (U.S. Food and Drug Administration; Continua Health Alliance; Center For Integration Of Medicine & Innovative Technology (CIMIT); Medical Device “Plug-and-Play” Interoperability Program (MD PnP) 2010)).


To move beyond conceptual demonstrations of new interventional systems and towards the systematic assessment and employment in interventional settings, an understanding of the expected maturity levels of the Digital Operating Room (DOR) at present and in the foreseeable future is helpful (Lemke and Berliner 2011).


Figure 1 provides an estimated timetable for the past, present and future developments of the DOR over a 25-year period including:

• its development up to the present time as well as its continued development and implementation

• the political, economic, and industrial issues that may be encountered (Lemke and Berliner 2011).


Four main areas of technology development for the DOR can be identified:

1. Devices, including signal detection and recording, robotics, guidance systems, simulation technologies, which allow precision in the delivery of personalised operative healthcare;

2. IT Infrastructure, including DICOM, IHE, EMR, Therapy Imaging and Model Management System (TIMMS) infrastructure for the storage, integration, processing and transmission of patient specific data;

3. Functionalities, including specific interventional processes, patientspecific modelling, optimisation of surgical workflow, TIMMS engines and;

4. Visualisation, including the processing, transmission, display and storage of radiographic images, video, and physiologic signals (e.g. a type of surgical PACS).


Each of these areas is following its own characteristic development, validation and approval cycle and methods. In (Lemke and Berliner 2011), five stages of maturity for the various technical areas have been identified in the development of the Digital Operating Room for the first quarter of the 21st century:


2005+: Maturity level 1

Characterised by the vendor-specific integration of technologies. The critical feature of this stage is considered to be the development of integrated device control. Additional technologies include high definition (HD) video and digital image acquisition and processing, boommounted devices, automatic reporting.


2010+: Maturity level 2

Characterised by perioperative processes optimisation. The two critical features of this stage are considered to be the development of preoperative image integration and navigated control. Additional technologies include basic DICOM in surgery, intraoperative image acquisition, modelling and simulation and intelligent cameras.


2015+: Maturity level 3

Characterised by intra operative process optimisation. The two critical features of this stage are considered to be the development of a workflow management (TIMMS) engine and full DICOM in surgery. Additional technologies include DOR process redesign with EMR and signal integration, basic IHE integration profiles for surgery, smart walls including n-dimensional visualisation, and basic model-guided intervention.


2020+: Maturity level 4

Characterised by vendor-independent integration of technologies. The critical features of this stage are considered to be the development of hospital/enterprise wide interoperability and patient specific models. Additional technologies include knowledge and decision management, clinical quantitative and statistical assessment, and IHE integration profiles for surgery, pathology and interventional procedures generally.


2025+: Maturity level 5

Characterised by intelligent infrastructure and processes. The critical feature of this stage is considered to be the development of surgical cockpit systems and Medical TIMMS architecture. Additional technologies include real-time access to peerto-peer surgical process repositories, intelligent real-time data mining, full voice/gesture control, real-time CAD integration, and intelligent (situation aware) robotic devices.


A glimpse of what may be ahead in the OR and predicted in (Lemke and Berliner 2011) is provided by an interesting example of a surgical workflow management system, which includes a Surgical Procedure Manager (SPM), already in clinical use at the International Development Reference Centre (IRDC) in Leipzig (Strauß et al. 2013).


First experiences with this system show that this type of knowledge-based system in the OR can improve efficiency of the interventional processes. It may, however, induce the surgeon to rely excessively on the “intelligence” of the machine to provide the “right” information on patient and processes at the right place, at the right time and to the right person in the OR.


Trust in this form of “intelligence” and in the right record-keeping and subsequent management of interventional process information for patient outcome evaluation, are new dimensions of concern when machine intelligence moves into therapeutic activities within the context of a digital OR.


Important aspects of these dramatically evolving ICT based methodologies and tools are new requirements for:

1. DOR IT architectures providing the right basis for enabling a higher quality of therapeutic interventions by means of interoperability features, for example, real-time integration of information in patient related data structures and therapeutic processes through computer assisted workflow, knowledge and decision management (see also section 2 below).

2. Standards that take account of the specific requirements for surgical/ interventional workflows, devices and systems. Examples are DICOM in Surgery and IHE Surgery (see also section 3 below).

3. Methods and tools for supporting approval procedures on an international level, for example, device/ systems classification, clinical and non-clinical testing for safety, high confidence medical device software and systems through appropriate modelling and simulation, etc. (see also section 4 below).


2. DOR IT architectures for interoperability

Architectural features, for example, as part of an intelligent infrastructure of an OR have only recently become a focus in discussions relating to interventional settings (goldman 2007; Lemke and Vannier 2006). Such an IT reference architecture may be referred to as a Therapy Imaging and Model Management System (TIMMS) (Lemke and Vannier 2006).

A TIMMS-like architecture and its application for achieving image and model guided therapy has been the subject of discussions i n t he DICOM and I HE standard activities. An implementation of a prototype based on open standards of the modular TIMMS-like architecture is in progress at the Innovation Centre Computer Assisted Surgery (ICCAS) in Leipzig, germany. TIMMS is a comprehensive medical-surgical communication and assistance system (see Figure 3), which is composed of interconnected computer hardware and software components (such as engines, repositories and an IT infrastructure).


There are seven TIMMS engines, which may be defined as software modules which can be executed on an appropriate computing machine in order to provide interventional functionalities. These engines relate to imaging and biosensor data acquisition, modeling, simulation, workflow and knowledge and decision management, visualisation, intervention and validation. Some of these engines are already present and used in modern OR systems.


The Kernel for workflow and knowledge and decision management provides the strategic intelligence for therapeutic planning and workflow execution. Often this module (or parts thereof) is integrated into some of the other engines, as need may demand. This important computing kernel (or “brain”) of the system may use different forms of logic, different database structuring, agents and other forms of artificial intelligence, depending on the specific applications of the performed procedure.


In a full realisation, a TIMMS may provide the following features and functions throughout the course of a medical and surgical treatment:

1. Standardised interfaces for communication and mechatronics, thereby creating a unified environment for the input and output of data (including the representation of and display of information and images, as well as the electromechanical control of surgical and navigational devices);

2. Creation and maintenance of a patient-specific model (PSM), thereby providing a multi-scalar, comprehensive, precise, personalised representation of the patient;

3. Creation and maintenance of a system for process modelling (PM) of all aspects of the surgical workflow, to ensure efficiency, learning and safety throughout operative procedures;

4. Real-time knowledge management and decision support system thereby promoting optimised diagnostic, prognostic and therapeutic decisions throughout the treatment workflow;

5. Validation and approval procedures, thereby providing quality assurance, patient safety, system security and processing of medical evidence towards securing better patient outcome.


Features 1, 2, 3 and 4 are the prerequisite of an intelligent infrastructure of an OR. A full realisation of these functions is still a long way away. In practice, however, some small subsets of patient models, process models and/or real time knowledge management have been implemented and clinically tested. Feature 5 can begin to be properly addressed when features 1-4 have reached a tangible stage of implementation from which one can derive appropriate requirements for safety testing and feature/(usage) classification for devices and systems approval.


Feature 2 is subject to standard activities in working groups in DICOM and IHE in surgery. Feature 5 is of major concern in a number of regulation agencies such as FDA, PMDA, CEN and DIN. FDA and PMDA will be discussed further in section 4 below.


One of the architectures proposed in OR:NET (OR.NET 2014) is somewhat different in appearance with respect to the TIMMS architecture, but conceptually contains an equivalent base structure (see Figure 4).


3. DOR standards

Since 2003/2004 it was recognised (Lemke et al. 2005; CAR/CMI 2004), that the realisation of the “OR of the Future” or DOR, will be a comprehensive undertaking, requiring, among others, the development of standards for achieving interoperability of medical devices and systems in the OR. Since then, DICOM and IHE have been considered, in principle, as enablers for fulfilling these requirements.