Perioperative Technology

The perioperative clinical process has been supported by a narrowly defined niche design approach to software. Software is required that offers a new vision and more holistic design, provides integrated function and supports the inherent complexity of the perioperative environment, has a sophisticated deployment, and supports and integrates all relevant technologies. Such an undertaking would require an unprecedented depth of partnership for all parties involved in creating and supporting technology in this area.

The technology requirements for the perioperative environment must be supported from a holistic viewpoint. Each technology element must integrate with the larger set of technologies used in the OR and throughout the perioperative process, including all aspects of information technology and clinical equipment. To enable data sharing, all perioperative data and knowledge bases must share common metadata. They also must support all clinical and administrative data for perioperative care, from the initial identification of a surgical case, through surgery, recovery, and ongoing outcome analysis. Clinical vocabularies and other data descriptors must support the needs of all perioperative issues. Databases supporting this process must be modernized to include all types of data, images, text, knowledge, and equipment usage involved in the surgical case.

Workflow for clinicians must be made faster and easier, not slower and more complicated. Data should be entered once with real-time decision support and shared ubiquitously as needed. This must be enabled by high levels of surgical equipment and software application interoperability throughout the perioperative process. Data interoperability would dramatically reduce data redundancy and errors. All data generated by clinical equipment should flow into clinical databases without manual re-entry, thus increasing clinical acceptance and accuracy of data by reducing user workload and transcription errors.

An example of how perioperative requirements have not been fully addressed is the national focus on the much heralded software created to support computerized physician order entry (CPOE), which makes possible direct, online order entry of medications by physicians. CPOE software is highly focused on the inpatient care unit environment. As soon as a physician creates a clinical order, that order is sent directly to the pharmacy for pharmacist review; the drug order is filled; and then a nurse administers the drug, guided by online medication administration software. However, this CPOE paradigm does not come close to matching the needs of an anesthesiologist in an OR suite who typically performs all three functions: ordering, filling, and administration. Furthermore, typical CPOE software does not support the planning of and preparation for an OR case in terms of medication inventories, after-case documentation, and inventory replenishment.

Optimal software design must be able to support clinical tasks and simplify, rather than complicate, the process of clinical documentation. Technology must be used to promote and improve workflow and workplace ergonomics. It should not make tasks more difficult for surgical teams and clinicians, as is the case when technologies do not fit into an optimized care process design.

Need for a High Level of Technical Interoperability

Over time, two distinct types of health care technology have emerged in the perioperative environment, each having its own areas of specialization in technology applications. Health care information technology (HIT) refers to broadly functional software applications. By contrast, clinical information technology (CIT) describes clinical equipment, clinical imaging, and some types of instruments. These two types of technologies usually are created and supported by different vendors, typically using different standards, and are often focused on different outcomes. In many hospitals, it is common to find HIT and CIT utilizing different networks, or at least subnets, that are secured from each other. Technologies within the HIT or CIT categories often do not interoperate, or share relevant data; it is even more rare for technologies to interoperate between these two categories. See the Appendix for a glossary of abbreviations and key terms relevant to HIT.

Examples of HIT include software applications that support admitting, scheduling, clinical documentation, pharmacy, laboratory, and other departments. HIT is typically deployed to meet the needs of a broad process or a function. Interoperability has improved between software modules of this type. Data interface standards, such as Health Level 7 (HL7) are used to share patient level data. The growth of vendor-created integrated software suites has also improved the interoperability of data between specific software modules.

CIT includes picture archive and communications systems (PACS) and various clinical imaging technologies, robotic surgical systems, perfusion pumps, mechanical ventilators, infusion pumps, anesthesia delivery systems, automated medication cabinets, and others. Any and all of these technology resources might be critical in the performance of a single surgical procedure. CIT is focused on specific clinical tasks and can be highly sophisticated. These technologies are often regulated by the Food and Drug Administration (FDA) and, therefore, can be difficult and time-consuming to change quickly or interoperate with other technologies. Standards include the Digital Imaging and Communications in Medicine (DICOM) to exchange clinical images, and the ANSI/IEEE 1073 standard—the Medical Information Bus (MIB) that defines how to connect critical care bedside medical devices and HIT software applications. Future products need to break through this legacy of technologies and software that were designed as if they were the only element of technology used during a case. They need to create new levels of partnership to ensure that technology used in the perioperative environment fully interoperates with all other relevant technologies.

Perioperative Informatics

The unique requirements of surgical specialties and the perioperative care process have been dramatically undersupported in informatics research and field work. A critical foundation for improving the way technology and information support perioperative clinicians would be an improvement in perioperative focus in informatics, to help create the required focus and knowledge set needed to support perioperative care.³ Opportunities abound for informatics-based improvements in perioperative care. Additional perioperative work groups and industry partnerships need to be created. Various health care standards should be reviewed to ensure full support of perioperative requirements. Table 2 summarizes some of the proposed perioperative informatics focus areas and opportunities.

Table 2

Opportunities for informatics-based perioperative improvements.

The reality of surgical case prioritization and timing must be supported by a real-time, current-state schedule that changes dynamically and automatically as work load varies. Old time versions of schedules (paper or grease boards) should be replaced by electronic schedule display boards that can be viewed by all people in various roles. Examples of how surgery schedule access must be supported include:

• Large screen “tracker boards” in key locations.
• Secure Web pages.
• Handheld PDAs.
• Wireless voice over IP network (VoIP) communication devices.
• Pager units.

Only when a perioperative team truly converts to a single and shared digital surgery schedule will modern software be able to fully support the perioperative process. If paper versions of the schedule continue to be used (the paper schedule is always immediately out of date), or if elements of the perioperative team use their own “off schedule” versions of planned cases, it is a clear indication that either the software is not yet sophisticated enough to support clinicians’ needs, or the perioperative process is not yet fully converted to a digital shared format. Either way, what support software can achieve is limited.

Safety is increased by monitoring vital signs in the OR. Similarly, safety can be improved by monitoring the flow of patients and documentation through the perioperative process. Reporting and analysis can be improved if they are based on newly designed longitudinal perioperative databases. Current systems need to be redesigned to integrate data from multiple sources. This increases safety by eliminating transcription errors and duplication of effort.

It is critical to focus reporting and analysis with a process-based approach that analyzes key process steps, cycle time, backlogs, rework, and errors. If measures of quality, productivity, service, cost per unit of service, and patient/clinician satisfaction can be created along the entire perioperative process, historical mysteries about hard to solve problems can be illuminated and resolved. The goal is to utilize software to support the optimal perioperative process, and once sophisticated workflow-enabled software is deployed, to utilize real-time measurement to constantly track and improve how work is defined, how process steps are staffed, and how resources are utilized. Ongoing process course corrections or fine tuning should be encouraged and expected.

Newly discovered medical evidence can take years to become incorporated into general practice. However, new practice guidelines or measurements—such as perioperative beta-blockade, prophylactic antibiotic administration, and normothermia maintenance—can be incorporated into the online knowledge deployed with perioperative software. Software must be designed to assist clinicians in utilizing clinical guidelines and evidence-based “best practice.”

Expert systems and predictive alerting engines should be designed to assess data in real time for potential unsafe or error conditions before patients are harmed. Expert systems could also be used much more extensively to assess digital patient data and create evidence-based treatment suggestions at relevant points in the perioperative care process. Knowledge-aware software becomes a tool both to promote evidence-based practice and to report compliance with “best practice” and new research findings.

A key question for the designers of future perioperative systems is: Should perioperative surgical software applications be designed to be stand-alone (niche), or should they be designed to be part of larger application suites? The primary advantage for the niche design is a more specific focus on the needs of perioperative-based clinicians. However, these systems typically have not been designed to interoperate with other applications that are used within the perioperative process, or outside the process, to share relevant information. As clinical software uses more online clinical knowledge and software tools (e.g., inference engines) to manage that knowledge, it will become even harder to interoperate at the level required.

Larger clinical application suites often include perioperative applications, but these do not provide the depth of function or the usability needed in the perioperative environment. Thus, they have been poorly accepted to date. Given the inherent difficulty of achieving a high level of software interoperability, well-designed integrated “suites” of clinical applications might provide the best future foundation for delivering sophisticated clinical support function. However, they ultimately must be able to deliver the level of function needed by clinicians and staff in the perioperative care process that is so far available only from the niche applications.

RFID Technologies

To support the real-time surgery schedule and enable perioperative process-support software to be “aware” of the many key elements of surgical cases, the use of radio frequency identification (RFID) holds significant promise to bring dramatic improvements in sophistication to perioperative software.

To make use of RFID and positioning technologies, a ubiquitous sensor environment or network must be deployed throughout the perioperative environment. In the past, this involved deployment of new and proprietary radio frequency sensors, but many products now support the more traditional 802.11 wireless networks that are already in use in many hospitals and clinics. With this system, important items that are “tagged” with RFID chips can be located and identified by the radio frequency network; the precise location can be noted, and in some cases, the movement (e.g., an object going into or leaving a surgical suite) can be recorded.

The RFID tags or chips can be “passive” with no power needed by the chip and provide simple identification. They also can be “active”—that is, driven by a power source and able to interact with the network to infer events, task completion, or relevant movement. Data about tag locations and movement are written in real time into a database, and unique visualization software is used to transform highly specific location data into a map or image that personnel can use to track key events or issues. For example, once the architectural layout of the surgical department is scanned into the visualization software, after a one-time special setup programming, the location of relevant tag-provided data becomes visible on a computer rendering of the department.

The possibilities of using RFID tags in the perioperative process are many and varied. For example, they would permit:

• Visualization of the exact location of a piece of surgical equipment or a case cart.
• Automation of time fields of patient entry into or exit from the OR.
• Notation of which clinicians are present in an OR suite during a surgical case.

RFID chips are not all the same; some are less sophisticated and provide only a rough location of a tagged object (e.g., accurate to within 15 feet). This low level and low cost degree of location precision is fine for some items, such as the location of a piece of equipment. However, more precision would be needed for certain other functions, such as surgical instrument management, a critical and very difficult task. Electronic tagging through barcoding or RFID tagging and tracking technologies could be designed to individually identify surgical instruments, which can then be tracked from operation to operation, making sure all the correct instruments are in the correct place at the correct time. Proper instrument quality assurance procedures could also be enabled through tracking the history of each surgical instrument. Items that need repair or are at the end of their useful life would be electronically flagged and could be taken out of circulation prior to delivery to an OR.

The promise of more sophisticated function using RFID networks and chips is called “co-location.” This capability depends on higher functioning, and higher cost, RFID chips that have the ability to note a much more exact geographic calculation of location to within 12 to 18 inches. Once a more precise location of two items can be calculated—for example, the RFID tag on a patient and a tag on a perfusion machine used on that patient during surgery—the two tagged items can be “co-located” and recorded in a database. In this scenario, if a patient and perfusion machine were within 3 feet of each other for more than 15 minutes, a software application would note the event and enter the serial number of that perfusion machine into the patient’s surgical case history. Should there ever be a recall or problem with that specific piece of surgical equipment, all patients on whom it was used could be quickly located in the database for any necessary followup.

In a similar manner, blood safety could be improved by tagging blood products, and “co-location” technology could be used to assess whether the blood product (e.g., blood type A+) matches the blood type of a patient (as recorded in the electronic medical record) who is located within a predefined distance of that blood product. If the blood product does not match the patient’s blood type, an alarm sounds. These are just a few of the possibilities of how tagging and “co-location” could be utilized to greatly enhance efficiency and patient safety.

Implementation

Adoption of HIT in the perioperative process has often been slow, expensive, and difficult. Integrating even well-designed and workflow-enabled software into the perioperative workflow is not easy. Clinicians have little tolerance for systems that do not work as claimed, even when the systems are clearly an improvement over the former noncomputerized versions. Because they are reluctant to change current work patterns, the value of new software and process changes must be clearly demonstrated and delivered to gain clinician acceptance. Workflow for clinicians must be made easier and faster, not more complicated and slower. It helps when key clinical and administrative leadership within the perioperative process champion the perioperative system. Second only to patient safety, the bottom line for clinicians is what the software can do to deliver improvements that would justify investments in new software and technologies—for example, streamlining workflow, increasing efficiency, supporting more cases, increasing revenue, and improving time management.

As in the successful adoption of any technology, especially in a clinical environment, providing resources for the training of all affected clinicians is critical. Successful training in the perioperative environment is especially challenging, since hours available for training for surgeons, anesthesiologists, nurses, and OR support staff are typically limited and costly. It is a challenge to provide technology training without negatively affecting the surgery schedule.

A larger OR suite might require several iterations of the same training session due to the large number and variety of shifts. To help with the training time burden, new systems must also be designed to be intuitive to those using the system so training can be minimized. Web-based training materials can provide a significant value, since they can be accessed by staff at home or at other locations.

An important design approach is to deliver training in smaller content increments that support interruptions while training materials are learned. Furthermore, smaller content increments can be revisited for “just-in-time” rereading when needed. Additional reference materials, designed for adults who might not be experts in clinical software usage, should be offered to perioperative staff.

The most important time to support perioperative staff is when new software is deployed. A large number of extra clinical, technology support, and vendor staff should be available to help if any problems or questions arise during implementation. This period during which extra support is required could last for weeks or months after new software is deployed, and the cost of providing this critical higher level of support is not trivial.

Implementation does not end with the installation of the hardware and software. A significant part of the original technology investment must be allocated each year to support ongoing software and technology needs. It is common for clinical software to have one or two major new versions released each year. These new versions should be approached as smaller scale deployments, not as consuming as the original software deployment, but not trivial either, and resources must be allocated. It is important for the software used in the perioperative environment to be kept as current as possible. It is not advisable to fall too far behind the current software release, as bugs and other problems with the current version will not be fixed, and new functions will not be available if the software is not kept current.

Installing computer workstations in the perioperative environment also is not a trivial task. Due to the space limitations of most OR suites, system designers need to be creative about using mounting hardware that provides access to the computer workstation when it is in use and also takes minimal space when the workstation is not in use. Like all equipment in the perioperative environment, such equipment has special requirements, such as the need for thorough cleaning and electrical safety. New microcomputers and communication devices are now available with cases made from materials with embedded antimicrobial agents that provide protection against a broad spectrum of bacteria, mold, and fungi. Technology products should be at least semi-waterproof and have the ability to be wiped clean for disinfection. Examples include the Vocera^® wireless communications badge with embedded BioCote^® silver-based antimicrobial agent (Vocera Communications, Inc., San Jose, CA), and the Motion C5 tablet computer from Motion Computing, which can be washed using many chemical disinfectants (Motion Computing, Inc., Austin, TX).

As with all patient care environments, ethical and legal issues demand that privacy rights be respected. Thus, the placement of computer hardware in publicly accessible areas must be limited to systems for which access can be controlled or which display data only in a format that is consistent with privacy rules, such HIPAA regulations. Special care should be taken to locate all computer/equipment view screens in a way to prevent patient-identified information from being accessed by nonauthorized people. This includes the installation of large computer monitors used to support patient tracking information—tracker boards—similar to those in airports that display flight information. Tracker boards can still be utilized and can be very valuable, but data on them should be displayed to support privacy standards. For example, the software can be made to display the patient’s initials instead of their full name.

Focus on Technology Use in Health Care: Inclusion of Perioperative Requirements

Government agencies, health care systems, and professional organizations have now realized the importance of creating sophisticated HIT systems. Incentives are being planned in terms of reimbursement increases and other incentives for implementing HIT systems.⁴ The Office of the National Coordinator for Health Information Technology (ONCHIT) was created on executive order of President George W. Bush. The national coordinator of Health IT, who reports to the Secretary of Health and Human Services (HHS), has focused on implementing the president’s vision for widespread adoption of interoperable electronic health records (EHRs) within 10 years. Toward this goal, major efforts have been undertaken to support patient data sharing, improve health care IT standards, and foster improvements in health care software to meet clinicians’ needs.

Significant resources are now being allocated for the development of sophisticated regional and national capabilities to share clinical information at the community level. In October 2005, HHS awarded three contracts totaling $17.5 million to public-private groups that will accelerate the adoption of HIT and the secure portability of health information across the United States.⁵ HHS and ONCHIT have also supported the relatively new Certification Commission for Healthcare Information Technology (CCHIT) with a $7.5 million contract awarded in October 2005. It is critical that the data and clinical requirements of the perioperative care process be included in this vision and in the infrastructure that is now being created.

CCHIT has taken an approach similar to the Underwriters Laboratories (UL), where products are put through rigorous testing and have to prove they function and that they comply with relevant standards. CCHIT has created standards for ambulatory and inpatient EHRs and is now working on standards for networks that share clinical data. For the first time, health care software vendors must actually prove they comply with industry standards and deliver specific items in the areas of function, interoperability, and security. Many vendors have now put their products through the CCHIT testing process and have earned the right to use the CCHIT symbol on their products, verifying that the products deliver mandated levels of function.

CCHIT is now beginning to focus on more specific areas of IT health care support, including child health, cardiovascular medicine, and the emergency department. The effort to create standards and testing scripts for more specialized areas starts with the creation of an expert panel and formulation of goals and standards. Given the unique issues facing perioperative and surgical medicine, an important step would be to create a CCHIT work group in this area.