The
full report of this Working Group appears below:
CHAPTER
3:
SYSTEMS INTEGRATION AND TECHNICAL STANDARDS
…THE REPORT OF WORKING GROUP 2
| PARTICIPANTS
Julian
Goldman, MD, Massachusetts General Hospital (Clinical
Leader)
Ramin Shahidi, PhD, Stanford University (Technical Leader)
Michael Brown, General Electric Global Research
Richard Bucholz, MD, St. Louis University
Laurence Clarke, PhD, National Cancer Institute
Jeff Collman, PhD, Georgetown University
Gilbert Devey, BS, Georgetown University
Tony Epifane, Karl Storz Endoscopy
Michael Evans, Stryker Endoscopy
Peter Kazanzides, PhD, Johns Hopkins University
Walter Lambiotte, Stryker Communications
Dave Lieberman, Olympus Surgical
William MacNeil, MS, Johns Hopkins University
Sohan Ranjan, MS, Georgetown University |
3.1 OVERVIEW: THE NEED FOR AN INTRAOPERATIVE AND INTEGRATED
SYSTEMS PLATFORM
There
are wide ranges of medical devices used in today’s operating
rooms (ORs). However, almost all of these devices operate independently
or are incapable of communicating with other devices or technologies.
Significant improvements in operating room efficiency and quality
might be achieved by the design and implementation of an intraoperative
and integrated systems platform.
A
standard interface for interoperability is needed for all technologies
used in the OR if simpler and seamless integration is to be
achieved. However, the integration should be driven not by what
components and technology matches are possible but by what makes
sense clinically. In terms of integrating surgical equipment,
what makes sense is taking a broader approach than just dealing
with surgical information. The approach must integrate and incorporate
the “physiological datastream”– that is, the
anesthesia record, medical administration, and other information
that is specific to the OR and patient activity.
This
Working Group devoted significant time to identifying the building
blocks that are needed to clinically and technically generate
system platforms for multipurpose OR suites. A platform comprising
clinically connected devices (operating via plug and play standardization)
was the end goal desired for the Operating Room of the Future
(ORF).
3.2 CLINICAL NEEDS: ISSUES IN DEVELOPING INTEGRATED
OPERATING ROOM SYSTEMS AND TECHNICAL STANDARDS
At
least two significant steps were identified as critical for
building new, more useable systems for the OR. These are:
1.
Defining information that is mandatory in the OR. Laying
the groundwork for building an integrated and standardized system
for the OR requires, first of all, determining what information
is needed for clinical decision-making. Clinical requirements
must be defined and articulated by surgeons and associated personnel
and then conveyed to engineers and industry developers. This
information will eventually need to be integrated into OR information
systems and made readily available to OR clinicians.
These
definitions of OR requirements must encompass not only the information
and tools that are required in the OR but must also include
and synthesize existing procedural protocols. There are currently
varying types of protocols used in the OR. Clinical requirements
(once identified) will define and generate the needed standards
that represent a single, global protocol. Achieving this global
protocol is the goal for attaining effective and measurable
work in the OR.
2.
Generating a systems platform for a multipurpose OR suite. A
building block approach to defining clinical requirements and
standards is needed from which to generate systems platforms
for a multipurpose OR suite. Four key areas that must be addressed
in standards development are as follows: imaging, visualization,
control of devices, and communications. In addition, the platforms
must facilitate reconfigurability that is needed for different
procedures and for accommodating different surgeons’ needs
and tastes.
The
building blocks of the OR informational system also have to
continually define engineering requirements and so enable the
system to meet platform standards for an application-specific,
protocol-based workflow. There have to be multi-level device
integration and high bandwidth data communications when required.
Too
much technology?
An
issue that arose during this Working Group’s discussion
was: Is there too much technology in today’s OR to allow
for clinical efficiencies? A need for surgical operation-specific
procedural maps was voiced, as was the need for technology (and
`modular technology, should needs change) that ought to be in
the OR on a given day for achieving clinical efficiency. Ideally,
each OR would be physically standardized to facilitate performing
particular procedures and be physically mapped according to
placement of tools and task-specific people.
Figure
3: Operating Room of the Future at Massachusetts General Hospital
(courtesy of the Center for Integration of Medicine and Innovative
Technology (CIMIT))
Planning for each procedure’s requirements (and following
specific, usual surgical routines) will indicate specific technology
platforms that are needed for some procedures, not always for
others. This standardized inventory is, as one group member
noted, an extremely critical foundation from which to begin
“before you start filling your room with standards of
seven other different technologies.” A goal may well be
a requirement to design multipurpose, easily reconfigurable
ORs. It was believed, however, that hospital administrators
and hospital efficiency experts would not support separate ORs
for each specialty. Standardization will occur only after the
room is defined by the procedures (whichever operation is taking
place).
Improved
use of technology and current OR clinical requirements demand
that planners:
3.3 TECHNICAL REQUIREMENTS: STANDARDS AND TOOLS FOR
IMPROVED OPERATING ROOM PROCESS INTEGRATION
The
technology for creating standards or standardized interfaces
among devices in today’s OR needs to be identified. These
systems must satisfy clinical requirements, and they must address
what clinicians say they need in the OR.
At
the outset, a plug and play system for developing this interface
appears to be key for communication and control between multiple
devices. Identifying requirements for this platform is essential.
Specifically, devices that need to work together have to be
identified as do their requirements for operation (e.g., in
terms of bandwidth, speed, and synchronization).
Each
device’s range of capabilities has to be included in this
configuration as well. Capabilities to transmit the status of
its completed tasks to a designated location or via a built-in,
real-time confirmation mechanism have to be included. Other
features of the platform include authorization mechanisms for
each device’s use, and configurations that allow for only
specified access to its capabilities by some designated users.
In
addition, devices of the same type must be assigned to a specific
class. The class must be understood as having specific capabilities
and standards. For instance, insuffulators as a class have many
capabilities, but some have all capabilities and others only
have a few of these. Surgeons in the OR need to know about the
particular capabilities of the insuffulator on hand so as to
plan their work accordingly.
Although
the need for building an improved platform is great and immediate,
this Working Group agreed on the need for performing “historical
due diligence” of device-related standards that have failed
to date. Investigating these standards and why they did not
succeed is a task that should be undertaken. The successes of
certain other standards, such as HL7, USB, and DICOM, also need
to be included in the ongoing research on workable system integration
and standards for the ORF.
3.4 RESEARCH PRIORITIES
At
least four research areas were identified as priorities by this
Working Group including: