‘Wet Reads’ in the Age of PACS: Technical and Workflow Considerations for a Preliminary Report System

Abstract

Communication between clinicians, technologists, and radi ologists has become more complex, with Picture Archiving and Communication Systems (PACS) now allowing the radiologist to be removed from the physical location of the patients and the site of imaging. With these changes, effective communication becomes an ongoing challenge. Efficient communication of study interpretations has also become a priority for radiologists as they struggle to maintain relevance and provide added value to patient care when clinicians have ready access to radiology images. The purpose of this paper is to share our experience in developing and implementing the Collaborative Notification System (CNS), a communication tool used to inform referring clinicians of urgent findings—a.k.a. “wet reads.” The system utilizes a system of web pages integrated into PACS for the sending and receiving of succinct messages to provide clinical information at the point of need. A second system of pager alerts provides notification of the need for such communication through a relatively unintrusive, one-way, acknowledged alert system. The CNS provides asynchronous, integrated communication for the reporting of urgent and emergent radiology findings in a complex, geographically distributed medical environment.

Background

Communication between clinicians, technologists, and radiologists has become more complex, with Picture Archiving and Communication Systems (PACS) now allowing the radiologist to be removed from the physical location of the patients and the site of imaging. As a clinician loses the ability to walk into a reading room with a question and a jacket of films, maintaining effective, efficient communication becomes an ongoing challenge. Efficient communication of study interpretations has also become a priority for radiologists as they struggle to maintain relevance and provide added value to patient care when clinicians have ready access to radiology images.

Communication in hospitals is biased toward synchronous methods—those requiring simultaneous availability—such as face-to-face or telephone discussions.¹ Inadequacy of these methods is heightened in an emergency setting, when rapid, efficient transfer of information is essential. Synchronous communication is not well documented and has poor fidelity, with messages changing meaning and potentially becoming “lost” in memory.² Moreover, synchronous communication is interrupt-driven by nature, interfering with normal workflows. Disruptions like this may actually impair cognitive processes and lead to increased medical errors.³ Synchronous communication does have the advantage of being reliable, with good feedback, clear confirmation of receipt of the message, and the possibility of two-way interaction, whereas asynchronous channels are capable of greater efficiency, but are not intrinsically two-way and may suffer from lack of confirmation that a message has been delivered. Thus, a traditional risk management system would be more supportive of the synchronous model.

Any solution to these problems would ideally use asynchronous communication methods, but with some of the robustness of synchronous channels. It would also have to be well documented, deliver messages at the point of need (“just-in-time”), and be integrated into existing systems. An effective solution should additionally take into account specific features of the local medical setting, including the issue of discordances between preliminary and final reports.

Various asynchronous methods have been employed in an effort to solve these communication gaps. Writing on carbon-copy paper or faxing requests and interpretations has been used to better distribute reports. Computer-based solutions have included attaching text or voice virtual “sticky notes” to patients’ studies in PACS or using voice recognition to decrease the lag time of transcription in delivering emergent reports. While these communication methods may represent significant improvements over traditional methods they still fail to fulfill the requirements for a robust, complete communication solution. Faxed reports, for example, require additional work on the part of clinicians, who have to check a machine and sort through a stack of paper to find the report of interest. Moreover, although there is confirmation that the message reached the receiving fax machine, there is no confirmation that the intended clinician read the report. Attached voice or text notes fail to provide a method for reconciliation of preliminary and final reports. Using voice recognition to completely dictate a study results in an inefficient workflow for the radiologist and long reports for ED clinicians to read.

We addressed these issues with the creation of a communication tool: the collaborative notification system (CNS). The purpose of this paper is to share our experience in developing and implementing a PACS-integrated tool for the efficient, robust, asynchronous communication of urgent findings to referring clinicians—a.k.a. “wet reads.”

Setting

Our university health center consists of 20 community, tertiary, and subspecialty hospitals, all covered during the day by on-site radiologists. Daytime images are directed to the appropriate subspecialty radiologists and there are no dedicated emergency department (ED) radiologists. Evening coverage consists of staff and resident radiologists at the main campus interpreting local ED images and “stat” teleradiology studies from six of the surrounding hospitals.

Because this research required no disclosure of patient medical data and no human subjects, it was exempt from institutional review board evaluation.

Collaborative Notification System

The CNS was created in 1998, and since that time, it has undergone extensive revision and optimization. CNS consists of two main components: a computerized preliminary report application and a pager notification system. The preliminary report application consists of a PACS-integrated, web-based application that opens automatically for appropriate studies, allowing clinicians and radiologists to input interpretations into a text box. This preliminary report remains associated with the patient’s images.

The second component, the pager notification system, informs the radiologist of the availability of an urgent study to be read as well as conveys otherwise unavailable clinical history from the outlying hospitals. Pager notifications are also used to inform ED physicians of significant discordances between preliminary reports and final interpretations.

Technical Considerations

CNS was written as a web-based application for seamless integration with our web-based PACS (Stentor, Brisbane, CA, USA). We used a Windows-based platform and a combination of client- and server-side scripting languages (Table 1).

Table 1.

Hardware and Software Specifications for the Collaborative Notification System

PACS: Stentor 3.3

Platform:

Operating System: Microsoft Windows 2000

Web server: Internet Microsoft Information Server (IIS)

Database management system: Microsoft SQL Server

Scripting:

Hypertext markup Language (HTML)

Microsoft active server pages (ASP)

JavaScript

These series of hosted pages are primarily ASP, which is a Microsoft technology that supports dynamic content for web pages. The ASP pages in this application were written using Jscript (Microsoft Corporation, Redmond, WA, USA), a variation of the JavaScript language. ASP is a server-side technology, as most browsers do not understand the ASP environment. The web server recognizes the ASP script file by its extension (.asp) and the script is then processed by the server. This processing results in the creation of a standard HTML file, which is then sent to the browser for rendering, with the original ASP code never actually seen by the web browser. One of the many strengths of ASP is the ability to interact with the server file system to manipulate remote files and folders as well as communicate with local or remote databases using Active Data Objects Database (ADODB). ADODB is an implementation of ActiveX™ Data Objects optimized for use with Microsoft Object Linking and Embedding Database (OLE DB) providers, including the Microsoft Open Database Connectivity (ODBC) Provider for OLE DB.

Stentor PACS ships with an advanced programming application program interface (API), allowing deep, seamless integration with the graphical user interface (GUI). The API provides the functionality to add a right-click menu item to the context menu of a displayed image. When a right-click is captured, all of the context information is provided in an extensible markup language (XML) structure, which is then passed by hypertext transfer protocol (HTTP) to the preliminary notes application that is loaded in a new web window. The XML includes the identifiers used by the PACS to uniquely identify the patient and the exam. These identifiers are used as the primary keys in the supporting database.

Client-side JavaScript is used to perform many of the functional workflow enhancements. JavaScript is a cross-platform, object-oriented scripting language. Client-side JavaScript supplies objects to control a browser and its document object model (DOM). Client-side scripting allows an application to form input and page navigation, control page layout, respond to user events such as mouse clicks, and maintain application workflow through redirection, disabling controls, and reloading pages. Using a client-side scripting solution also increases the application’s performance, as there is no post back to the server. This eases network traffic, and also takes advantage of the processing power of each work station’s PC, which is usually underutilized at this point in the workflow, as there is no interaction with the PACS system.

The paging component uses the text paging web client provided by Arch Wireless (USA Mobility, Alexandria, VA, USA), accessed by means of a right-click option within the PACS. Text pagers are nearly universally used by physicians at our institution and have the advantage of supporting mobility, as some radiologists have overnight duties that require moving between different areas of the hospital.

Workflow Considerations

The use of the system begins immediately after completion of the case by the technologist. When checking that the case was properly received from the modality into the PACS, the technologist can choose to initiate a page to the on-call radiologist via a right-click option (Fig. 1). A paging form then comes up, prepopulated with the patient’s identifying information (Fig. 2). Submission of this form sends a text message to the on-call radiologist, which includes a label (“trauma” or “teleradiology”), the name and medical record number of the patient, a call-back number telephone number, and the clinical history—either as provided on the study request or as obtained by the technologist from the patient. The technologist can also add any pertinent notes.

Fig 1.

Technologist’s PACS view. Interface used by radiology technologists to confirm receipt of a study into PACS. The upper frame is used to filter cases, which are then displayed in the right frame. A page to the radiologist on call can be initiated by means of a right click on an image.

Fig 2.

Technologist’s paging form. The form is prepopulated with patient information. The technologist can add patient history or study notes into the text box. Pressing “submit” will send a page to the on-call radiologist.

Other institutions have chosen to automate this process for all Emergency Department cases and have had positive results.^4,5 Because of the high volume of ED cases at our institution, however, we decided to reserve pages for a subset of ED cases that are particularly urgent or have a high possibility of going unnoticed and unread by the radiologist, namely trauma cases, cases marked “stat” by the ordering clinician, or teleradiology cases.

At a self-determined convenient point in the workflow, the radiologist can access the case for interpretation. Cases that originate in the ED or are paged to the radiologist automatically have the preliminary report application window open. Preliminary notes are not automatically opened for other types of cases, but can be initiated by the radiologist or other clinician by means of a right-click. Local ED studies are viewed using the usual PACS worklist. Teleradiology studies are accessed with the enterprise web viewer through a custom-built interface, showing only those studies that have been marked as teleradiology cases (Fig. 3). The system regularly queries the database and removes from the worklist any study that has a preliminary note submitted.

Fig 3.

Teleradiology worklist. The upper frame displays the urgent studies requested from outlying hospitals. The lower frame displays the study, with the preliminary note window automatically opened. A study will be removed from the worklist when a preliminary report is submitted.

The preliminary note application itself consists of two text boxes within a single window (Fig. 4a): the left side contains text entered by anyone who can access the study, whereas the right side is reserved for the dictating radiologist. Both sides are visible to any user who accesses the study. If the clinical staff (e.g., ED physician) reviews the study before the radiology resident or on-call radiologist, they can leave an initial impression, allowing the radiologist to later determine if the final interpretation is the same as the one that was clinically acted upon.

Fig 4.

Preliminary note window. (a) The window consists of two text boxes, with the right side reserved for the dictating radiologist and the left side available for input from other personnel (radiology residents, clinicians, nurses, others). (b) There is a pull-down menu for frequently used terms. (c) Once submitted, the preliminary report displays a time stamp and a clickable author username, which reveals the author’s full name, department, and pager number.

Additional features of the preliminary note box are a drop-down list for commonly typed statements (Fig. 4b) and a clickable time and name stamp for anyone who submits a preliminary or final report (Fig. 4c). Clicking on the name stamp gives the name, position, and pager number of the submitter. Once a preliminary report is entered, the clinician’s worklist displays a “+/−” symbol next to that case to indicate that a preliminary report is available (Fig. 5). The preliminary report automatically opens when the clinician opens the case (Fig. 6).

Fig 5.

Clinician’s worklist. The clinician can search for radiology images on specific patients. A “+/−” icon in front of the patient’s study name indicates that a preliminary report has been submitted.

Fig 6.

Clinician’s view. When a clinician opens a case with a submitted preliminary report, the preliminary window is automatically displayed. The radiologist’s view has a similar appearance. Addendums to the preliminary report can be added by any member of the medical team.

Final interpretation of the study usually takes place the next morning. Cases with a preliminary note attached are automatically sorted to the top of the worklist and labeled with a red bar and a “+/-” sign (Fig. 7). Again, the preliminary note will be opened automatically when the case is opened, in a view similar to that seen in Figure 6. Staff radiologists can “agree” with the preliminary interpretation with a button, but are prompted for a “judgment” if they enter their own text (Fig. 8a). Discordances are divided into “agree,” “mild discordance,” or “significant discordance,” and definitions of these levels are provided on the screen. Significant discordances come with a second choice of whether or not to activate the ED alert and an option to send an e-mail notification (Fig. 8b). The creator of the preliminary note always receives an e-mail notification of significant discordances.

Fig 7.

Close-up of radiologist’s worklist. Emergency studies are automatically sorted to the top of the list and are labeled with a red bar. A “+/−” icon indicates that there is a preliminary report, but no final report. An “ED” indicates that there is no preliminary or final report.

Fig 8.

Significant discordance dialog boxes. When a radiologist types into the final dictation text box, he or she is (a) prompted to “judge” the preliminary report. (b) A significant discordance results in the alert dialog box, with options to alert the ED and/or send an e-mail. The preliminary author automatically receives an e-mail alert. (c) The window displays the preliminary report, final report, and judgment.

The ED alert can take different forms: it can be an alarm at a central, constantly manned work station or page sent to an assigned pager, depending on the choice of the individual ED. In either case, the discordance alarm must be acknowledged at a work station by opening the case in question before it can be silenced. The “final” side of the preliminary report window will display the final text and the judgment of the case (Fig. 8c).

Data Mining

The database of preliminary and final reports combined with the record of PACS login information creates a digital record that can be leveraged for various administrative, quality assurance (QA), educational, and research uses. A database search tool (Fig. 9) can be used to generate a summary of statistics (Fig. 10) or of cases (Fig. 11). Statistics reports are generated on a regular schedule, detailing such information as the total number of preliminary notes, percentage of preliminary notes without final author input, percentage and types of discordances, and other metrics important for administration of the digital radiology department. The summary can prompt further investigation of anomalies so that steps can be taken to correct any systematic problems in a timely fashion. Summaries of discordant cases linked to PACS are generated for “Morbidity and Mortality” QA conferences or can be used for personal QA by radiologists.

Fig 9.

Preliminary report query tool.

Fig 10.

Preliminary report query statistics output. Various metrics useful for the administration of the digital department can be generated at regular intervals to assess the departmental status.

Fig 11.

Preliminary report case list output. The cases are linked to PACS so they can be displayed for QA conferences and follow-up.

Discussion

The CNS is an asynchronous communication tool designed to support reporting of urgent and emergent radiology findings in a complex, geographically distributed medical environment. The system utilizes a system of web pages integrated into PACS for the sending and receiving of succinct messages to provide clinical information at the point of need. The system of pager alerts provides notification of the need for such communication through a relatively unintrusive, one-way, acknowledged alert system. The acknowledgement is either explicit—by means of pressing an “acknowledgement” button on a work station when the ED is informed of a significant discordance, or implicit—in the form of the preliminary note generated by a radiologist. Together, the two parts provide an efficient communication system for the interpretation of urgent radiology studies in a complex medical center. The application’s integration with PACS allows for improved documentation and a seamless fusion with the existing clinical workflow.

The CNS represents an improvement on previous communication systems by providing:

• Asynchronous, acknowledged, two-way communication

• High signal-to-noise ratio “just in time” messages

• Support for different working styles, including mobility

• Improved documentation

• Integration into existing systems

• A database record of communication

Some of the advantages of the CNS are uniquely tailored to our large-volume academic environment. Institutions that rely on full-time ED coverage from dedicated ED radiologists, for example, may have less need for discordance adjudication or off-site coverage. Nevertheless, the improved communication and efficiency that is available from an asynchronous communication model can provide benefits in any radiology environment.

In an academic environment, the CNS can reveal patterns of discordances, illuminating potential gaps in resident education. Links to the cases in PACS provide a means for creating a digital teaching file of missed cases, which can be presented during resident conferences. Data on the frequency, types, and nature of discordances or lack thereof can be combined with information on individual readers and clinicians to support various research endeavors.

Because the CNS requires only minor computer resources for database storage and retrieval, it can be housed on existing departmental servers, which prevented high deployment costs. The software development itself represented a substantial commitment of resources within our research laboratory. Although most institutions would not be able to devote programmer time to this type of effort, our model may be useful to provide guidance to vendors who wish to emulate this functionality, or to other institutions with moderate development resources.

One potential drawback of the CNS is the requirement that the radiologist rendering the final interpretation provide adjudication of the preliminary report. This represents an additional workflow step, compared to the traditional approach of “doing nothing” when the preliminary and final interpretations are in agreement. We have found anecdotally that the attending radiologists in our system recognize the substantial benefits of completing the communication loop, and appreciate the reduction in synchronous commnication (i.e., interrupting phone calls) when the preliminary report is formally confirmed. Thus, compliance with adjudication has been excellent. It is worthwhile to note that the CNS allows the interpreting radiologist to confirm the preliminary report with a single button press, because that action is considered the default action.

Conclusion

The CNS represents the result our efforts to solve the problem of how to facilitate effective, efficient communication for urgent or emergent studies in a modern radiology setting. Many of the critical aspects of this system were not present at its inception, but instead represent the result of 6 years of trial-and-error, experimentation, and ongoing development. We hope that others can benefit from our experience and use this description as a foundation for their own optimized solutions.