A Wireless, Handheld Decision Support System To Promote Smoking Cessation in Primary Care

Abstract

Tobacco use remains a relatively unaddressed cause of disease and death in the daily care of patients by physicians. To overcome the barriers that physicians face in addressing tobacco use and its treatment in the primary care setting, we have developed a clinical decision support system that is readily accessible through the use of familiar wireless handheld devices and supportive of treatment through the implementation of the Tobacco Use and Dependence Treatment Guideline recommendations. We adopted the Information Management Services model to ensure that the application would effectively implement the guideline. The techniques used here are readily adaptable to implementing a broad range of clinical guidelines.

Introduction

Tobacco use is the most avoidable cause of disease and death in the United States [1]. While it is well known that smoking cessation can dramatically reduce the risk of lung cancer and other diseases, physicians routinely fail to identify tobacco use in their patients and provide effective treatments that promote smoking cessation [2]. Typical barriers cited that prevent physicians from assessing and treating smokers are the inability to identify smokers easily, a lack of formal training in tobacco cessation interventions, time constraints, and identification and delivering of effective treatments [3].

Besides these inherent barriers to smoking cessation intervention, Cabana has shown that developers must also address barriers related to physicians’ knowledge, attitudes, and behavior [4]. In the case of smoking cessation, physicians generally have positive attitudes towards the benefits of smoking cessation, but familiarity with the guideline knowledge content remains an important barrier to overcome.

Two technologies that are both familiar to the physicians and useful for supporting the implementation of a guideline are web browsers and personal digital assistants (PDAs)[5]. By combining these two technologies, we have created a system that is both familiar to the physician and powerful enough to integrate the United States Public Health Service’s Tobacco Use and Dependence Treatment Guideline (TUDTG) into the clinical practice setting [3].

Information Management Services Analysis

To incorporate a guideline-based clinical decision support system (CDSS) into the clinical workflow, the information management services model identifies eight Information Management Services that an effective guideline implementation might address [6]. These include Recommendation, Presentation, Documentation, Registration, Communication, Explanation, Aggregation, and Calculation. From data collected in two previous surveys of physicians and administrators, Marcy showed that the first four services are typically designated as necessary services by prospective clinician-users of a decision support tool, while the last four are considered optional [7]. As will be shown, the CDSS described here addresses all eight of these services to varying degrees.

Materials and Methods

To incorporate the TUDTG in a nomadic, intuitive decision support tool, we began the knowledge acquisition process by marking up an electronic text version of the guideline using the GEM Cutter guideline markup tool. Applying the systematic approach to guideline implementation described in [8], we identified the decision variables and actions that comprise the guideline recommendations and refined their specifications. We next identified the metadata necessary to place the knowledge into a clinical context and to integrate the recommendations into clinical workflow.

In parallel with the process of knowledge extraction from the guideline, we began the localization process by gathering requirements and creating use cases. Identifying standard use cases helped us to choose appropriate hardware and to design the software that would form the basis of the system while also mapping out a data access and storage analysis strategy. We adopted an iterative development cycle, which greatly facilitated the adoption of modifications as they were introduced. Finally, we addressed the needs of deploying the application and the changes that it would require. Each of these steps will be discussed in greater detail below.

Requirements gathering and use case development

Based on the GEM markup results and initial meetings with stakeholders to determine local workflows, user roles and activities were identified and a core use case was mapped out. Further refinement of user views and a need for alternative flows were identified in local practices.

Initial analysis of the requirements suggested that communication between the nurse and physician actors could be carried out optimally over a wireless local area network (LAN) using messaging between the nurse and physician if both carried PDAs. A client-server architecture, as shown in Figure 1, was thus identified as the most suitable, since the server could act as a proxy for patient data retrieval and as a conduit between nurses and physicians. We planned a distributed architecture to handle multiple input and data access methods over the network.

Figure 1.

Flow of data through the CDSS.

One of the more important design characteristics of this application is the minimization of exposure of patient data. Only the data displayed on a single screen is available at any time. No data is cached by the browser nor stored on the PDA. Typical concerns regarding battery life, power loss, and theft are thus not issues that need to be addressed.

Hardware

PDA

For the PDA, primary considerations included ease-of-use, user-familiarity with the hardware, and wireless capability. We also considered battery life, unit size and weight, and screen characteristics (e.g., brightness, resolution, color display capabilities).

Finally, since the PDA market is constantly changing, price was considered an important element. Both tablet-based PCs and cellular telephone devices were considered but were rejected after further analysis. The tablet PC’s were expensive (more than $2000 each) and potentially fragile, while the cellular phones lacked adequate screen size for implementing the full guideline.

Based on the above constraints and after we reviewed the PDA literature and market, we chose the Palm Tungsten C (palmOne, Milpitas, CA) running the Palm operating system. We found the Tungsten C to be a mature product with a large the number of available applications specifically written for physicians, thus suggesting that it would be familiar already to many physicians who use a PDA. The Tungsten C supports wireless technology (including Bluetooth and 802.11b Wi-Fi), has ample memory (64 MB), long battery life (~8 hours), and a large (320 X 320 pixels) color screen to make the application appealing to the end user. Data entry can be performed using a stylus or integrated keyboard. In addition, the PDA was priced at less than $400.

A web-based user interface was selected as the best means to provide the necessary data to both the nurse and the physician. We determined that Web Browser 2.0—the standard version of the web browser provided with the Tungsten C—was adequate for handling user input and data access methods. This version of the browser supports many web standards, including CSS 1.0 and 2.0, SSL 3.0, JavaScript 1.3, and HTML 4.01, although not all aspects of these standards are completely supported.

Server and Network

The server selected was a Dell PowerEdge 400SC (Dell, Austin, TX) with a Pentium 4 (2.26GHz) CPU and 500MB RAM, on which the Fedora version of RedHat Linux 9.0 [http://fedora.redhat.com] was downloaded and installed. A Linksys 2.4 GHz Wireless-B Router (Linksys, Irvine, CA) was selected to handle the Wi-Fi network traffic. The 802.11b specification that this router supports was considered to be adequate for anticipated security concerns and data transfer rates of this application.

Printer

An HP 5850 wireless, network printer (Hewlett Packard, Palo Alto, CA) was selected. Wireless communication with the printer would provide added flexibility in positioning the printer in the office setting.

Application Software

The software architecture is based on the Model-View-Controller (MVC) design pattern [9]. Since this is primarily a web application, the Spring 1.1 Application Framework [http://www.springframework.org] was selected because it provides a web application context that is flexible, easy to reconfigure, and allows the application to integrate seamlessly with existing web technologies, such as logging and remote database access. The web application runs inside the Apache Tomcat 5.018 [http://jakarta.apache.org/tomcat/] servlet container.

Controller

For the controller, the Spring Framework [http://www.springframework.org] allows a web application to be written using plain Java objects without the need for writing custom, web-specific servlets. Thus the controller code can be reused if a different View is selected, such as a desktop application. It accomplishes this by implementing the Inversion of Control design pattern, which specifies object relations within a configuration file.

View

The JSP 2.0 expression language (Sun Microsystems, Santa Clara CA) was utilized for the View to help decrease user-interface development time. In addition, JSP provides direct methods for data access and storage, XML parsing, and accessing user session data.

Model (Data Storage and Access)

MySQL 3.23.58 [http://web.mysql.com/] database server was installed on the Linux server and set up to access and store patient data, tobacco consultation data, and drug interaction data. Queries were created dynamically using SQL to provide drug recommendations based on patient state (e.g., history of heart disease, seizures, current pregnancy) and guideline recommendations. Recommendations were divided into four groups: Recommended, Caution, Extreme Caution, and Contraindicated.

Drug data from the TUDTG were converted to XML documents and validated against a schema that we developed. These XML documents were added to a running version of the Open Source eXist XML database project [http://exist-db.org/]. This XML database has an easy to use web interface and is simple to setup. Queries to extract the drug data from the database were written using XPath expressions and performed upon selection of a drug info button on the PDA screen.

Development

A critical component in developing the software was identifying the decision logic that was defined by the guideline recommendations. We found that guideline markup and extraction of decision variables and actions was a very useful approach [10]. We created a table in the MySQL database that included information about clinical conditions that influence the choice of smoking cessation modalities, along with pharmacologic interventions and level of indication/ contraindication. Result sets from SQL queries were displayed using a color-coded background (green = Recommended; yellow = Caution; orange = Extreme Caution; red = Contraindicated) (see Figure 2). In addition, the software provided an option to view expanded information for each drug choice.

Figure 2.

PDA display of drug contraindication levels

Deployment

Although originally planned for deployment to a Linux server, we determined that an Apple PowerBook would be preferable, because of its small size and ease of use. Because the application had been written in Java utilizing Open Source technologies, we were able to port the application easily to the Apple platform. In fact, the application server can also run on a server running Windows. Thus, because of the nature of the selected software components, we should be able to provide future enhancements to the system with minimal concern for OS-related issues. The major maintenance problem relates to printing, which relies on both the hardware chosen and the OS, since each OS handles printer control uniquely.

Workflow

Nurse

As specified in the requirements gathering phase, the use of the application begins with the CDSS providing a list of patients who are scheduled for a visit on a given day (Registration). The patient data is retrieved from a database table that contains the schedule information for those patients appointed for an office visit. Also displayed are some key elements of the schedule record, such as age, sex, town of residence, and insurance type, which help to further identify the patient and condition the logic. For example, insurance type helps to determine eligibility for prescription coverage and pregnancy and lactation are relevant considerations only for females.

Once a patient is selected, the nurse proceeds to collect and record vital signs (Documentation). Although the Tungsten C has a built-in keyboard, a number pad was added to the screen to facilitate numeric data entry. As part of the localization process, a pain assessment screen was added, which displays buttons for entering pain intensity values as the fifth vital sign.

Next, tobacco use is assessed by recording whether the patient smokes every day, some days, or not at all. Classification of a patient as a non-smoker, recent quitter, or a smoker moves a patient to a particular, guideline-defined pathway (Recommendation). If the patient is a smoker, prompts appear on the nurse’s PDA to document how many packs per day are smoked and whether the patient smokes within 30 minutes after awakening. Finally, the patient’s vital signs and smoking status are transmitted wirelessly to the physician (Communication).

Physician

The entry screen for the physician displays the patient’s name, vital signs, smoking status, and pain status information. The physician is then given the option of whether to proceed with the smoking cessation evaluation at this time or to print out a handout that encourages smoking cessation and includes basic counseling information.

If the physician opts to proceed with the smoking cessation counseling in accordance with the guideline, the physician is presented with an Advise and Assess screen. As suggested in the TUDTG, the Advise screen reminds the physician to provide a clear, strong, and personalized message that tobacco use is detrimental to the patient’s health. (Recommendation). If the patient expresses willingness to make a quit attempt and is willing to use medications, a clinical conditions history screen is displayed. Once the relevant history is recorded, the appropriate pharmacologic options are displayed and the clinician is offered an opportunity to make a selection. Next, a counseling options screen is displayed. In Vermont, programs exist to provide counseling either via a telephone “quit line” or in person via Community Cessation Services. To help the physician determine the most convenient counseling location for a given patient, an image map of Vermont is provided with Counselor information displayed upon selection.

Finally, a summary of the encounter is transmitted wirelessly to the printer for the physician’s records. The patient is provided with a customized report in letter format that includes complete counselor and drug information and a record of the encounter is stored in the database (Aggregation).

Discussion

We have successfully integrated the recommendations from the Tobacco Use and Dependence Treatment Guideline into a clinical decision support system suitable for the physician office setting. The wireless, PDA- and browser-based system provides (a) guidance in pharmacotherapy selection based on the patient’s medical history, (b) personalized counseling information, and (c) complete summaries of the encounter for both the patient and the physician.

The CDSS is delivered on a device increasingly familiar to physicians, the Palm PDA [5], thus making use of a familiar technology, which should lead to wider acceptance and greater adoption. Minor modifications could also make this application suitable for other web-enabled devices.

Preliminary usage testing has been generally very positive. The web architecture has been demonstrated to be capable of running with little modification in diverse server environments, including Windows, Mac OS, and Linux.

Assuring security represents the next area of development for the CDSS. The standard Palm comes with built-in Wi-Fi capable of operating within the 802.11b network specification. Although we use 104 bit key Wired Equivalent Privacy (WEP) encryption, for all wireless transmissions, there are known security flaws with this technology. [http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html] Since the Palm Web Browser 2.0 supports secure socket layer (SSL) transactions, we plan to encrypt patient data transactions in real world clinical settings. Further, Internet Protocol (IP) verification will be implemented, since each Palm can be assigned its own static IP address. We can also take advantage of the logging capabilities of the client-server architecture to monitor traffic and usage carefully. Finally, the security features of the Spring Framework can be utilized to authenticate users and control access.

The printing capabilities of the application are heavily affected by the operating system running on the application server and the available printer drivers. For the Mac OS, we were able to send html files directly to the printer for printing reports and encounter summary letters for the patient. For Linux, the HTML must be converted to PDF before sending to the printer. This conversion causes slight variations in the output formats, which limits its cross platform portability.

In order to ensure that this system provides effective clinical decision support to physicians and improve heath care, an iterative testing and development cycle is planned. The initial testing phase will be conducted in a simulated clinical setting with individual physicians to improve the system’s usability and reliability, to assess the value of provided information, and determine whether the application adheres to the guideline. The final phase of testing will be conducted in three clinics, to assess physician and patient experiences and opinions.

Conclusion

We have completed a successful deployment of the Tobacco Use and Dependence Treatment Guideline in a clinical decision support system. Our approach was based on modeling the guideline with use of the GEM model and object oriented programming techniques to develop the system. We have also incorporated all eight of the information management services that an effective CDSS should include. Since the implementation process described here is easily reproducible, this approach should be readily applicable to implementing a wide range of guidelines with varying complexity. Future work will build on this phase of the project by incorporating user feedback obtained through user testing and incorporating real-time and near real-time data into the system.