| HOME | HELP | FEEDBACK | SUBSCRIPTIONS | ARCHIVE | SEARCH | TABLE OF CONTENTS |
|
|
|
|||||||
|
|||||||||
Computers in Radiology |
1
Department of Radiological Sciences, UCLA Medical Center, 924 Westwood Blvd.,
Ste. 420, Los Angeles, CA 90024-1721.
2
Department of Computer Sciences, UCLA, 4732 Boelter Hall, Los Angeles, CA
90024-1721.
3
Present address: Department of Radiological Sciences, Childrens Hospital &
Medical Center, 4800 Sand Point Way N.E., M.S. Ch69, Seattle, WA
98105-0371.
Received August 24, 1999;
accepted after revision November 16, 1999.
Supported by National Institutes of Health grant NCI:2P01CA51198-06.
Abstract
 Top Abstract IntroductionSystem DesignResultsDiscussionConclusionReferences |
|---|
CONCLUSION. After implementation, the module was tested with 150 chest radiology reports by two radiologists and assessed for ease of use and accuracy. Overall, accuracy was close to 90% and user satisfaction was high. When radiology reports are structured as a part of routine clinical practice, it is possible to accomplish intelligent indexing and retrieval to facilitate teaching and research.
|
TopAbstractIntroductionSystem DesignResultsDiscussionConclusionReferences |
|---|
|
TopAbstractIntroductionSystem DesignResultsDiscussionConclusionReferences |
|---|
|
Speech Recognition Module
The speech recognition module (PowerScribe; Fonix, Salt Lake City, UT)
converts the speech input into text format. The inclusion of a speech
recognition module enables the entire process to be completed in a single
session. As previously mentioned, this task can also be accomplished by typing
the report.
This module is included to support the most familiar method of reporting used by radiologists (i.e., dictation). An initial training session is required to enable the speech recognition module to accurately interpret the radiologist's dictation. This training session is used to characterize the user's speech profile. If the profile closely matches one of the pre-defined profiles, the system can achieve a high accuracy with limited training. The user has the option to edit the output of the speech module using speech or keyboard commands. The text output of the speech module is written as a flat file to a directory. The module report manager polls this directory every 10 sec for the arrival of new reports. In addition to the dictated report, the text output of the speech module has a header that includes fields for patient demographics, radiology information system accession number, and radiologic procedure code. Under routine clinical operations, the text output of the speech module can be directly stored in a radiology information system database and accessible using the information in the header.
Natural Language Processing Module
The natural language processing module processes the findings section of
the radiology report [3]. It
does not process the entire report but addresses only specific concepts in a
specialized glossary. The glossary has two main sources: the Unified Medical
Language System [4] and a
thoracic radiology glossary compiled using thoracic imaging texts and
glossaries published by cardiopulmonary sub-specialty societies
[5]. Phrases or words with
similar meanings share a common base concept code. The details of this module,
which comprises four sub-components (lexical analyzer, finding analyzer,
reference resolver, and joiner), were described earlier
[3]. The output of the natural
language processing module is represented as either concepts or frames. Each
concept is based on a glossary entry that maps the word or phrase from the
free text to a structured representation. Frames group concepts together to
represent radiologic findings and their attributes. Frames can contain many
attributes to model the radiologic findings; further, an attribute can store
either a concept or a frame.
The output of this module for a given report is a list of the radiologic findings and related attributes (e.g., a mass may have attributes of location, size, and growth trend). Each data element is stored as an attribute—value pair in a hierarchy. The natural language processing module returns information regarding the findings, related attributes, concept identifiers in the corresponding glossaries, relative locations in the free text report, and presence or absence of findings. The output of the natural language processing module is accessed by the module through a Common Object Request Broker Architecture wrapper. The latter technology was chosen because it is currently recognized as the standard for heterogeneous computing and complements the Java platform by providing distributed objects framework services and by supporting interoperability with other languages. In the implementation described here, Common Object Request Broker Architecture allows data to be exchanged between software written in different languages (C, C++, and Java) and running on different platforms (Unix and NT; Server, Microsoft, Redmond, WA). The header associated with the free text report is appended to the structured report so that the free text and structured text are accessible with the same keywords. The natural language processing module was implemented in C and C++ on a Unix platform.
Visual Structured Relevant Report
This module has four main functions that also translate to four
subcomponents in the user interface: display of the free text in which the
findings of the natural language processing module are highlighted, visual
overview of the extracted relevant findings, tabular view of the relevant
findings, and editing capabilities for individual findings
(Fig. 2). The interface is
written in Java and is platform-independent.
|
Augmented free text.—The concept type and location specified in the output of the natural language processing module is used to highlight free text. A color scheme is used to distinguish the finding and the associated attributes. Findings that are absent are explicitly crossed out in the augmented text (Fig. 2).
Visual overview.—The extracted findings are mapped onto a schematic symbolic representation of the anatomic structure. This graphic display serves as a visual guide that shows the gross location of the findings identified by the natural language processing module. It provides fast navigation to indicate locations of findings rather than model all the details of the finding such as shape and size attributes; attribute details are shown in the tabular view.
Tabular view.—The tabular view shows each finding and all the associated attributes extracted by the natural language processing module. Selection of any row in the table automatically highlights the portion of the augmented free text from which it was derived. Each finding is also assigned a status: present or absent. The user has the option to change the status or delete, edit, or create a finding.
Editing or creating a finding.—The user can choose to edit a finding using a list of attributes and values (Fig. 3). Attribute value lists were extracted from the glossaries compiled for the natural language processing module and included only the concepts listed in the glossaries. Findings not extracted by the natural language processing module can also be created using a wizard interface and the editor panel (Fig. 4).
|
|
Implementation
The speech recognition module runs on a Windows NT Workstation (Microsoft).
The output of the speech recognizer is transferred over the network to a Sun
workstation (Sun Microsystems, Palo Alto. CA) for structuring using the
natural language processing module. A Common Object Request Broker
Architecture wrapper is used to access the natural language processing module.
The structured output is transferred back to the Microsoft Windows NT
Workstation for visualization and editing. Our system is currently implemented
as a standalone system; however, eventually, it will be integrated into
routine radiology practice in the department.
The cost of the system including software and hardware includes $2000 for the PC (Dell Computer, Round Rock, TX), $20,000 for the Sun Sparc2 server (Sun Microsystems), and $5948 for the PowerScribe speech recognition software. The implementation described here and the costs quoted above are valid for a standalone application. No cost is required for the natural language processing software, the Common Object Request Broker Architecture wrapper, or the interface for visualizing and editing because we developed these components.
Evaluation
One hundred fifty free text chest radiology reports were processed by two
radiologists. The performance of the natural language processing module was
evaluated for the findings in the 150 reports using two quantitative
indexes—recall and precision. In this article, recall is defined as the
ratio of correct findings identified by the algorithm to the total possible
findings (identified by the radiologists). Precision (or accuracy) is defined
as the ratio of correct findings to (correct findings + error) the findings of
the algorithm. The reference standard for this evaluation was the manual
extraction of findings and attributes by the two radiologists.
A qualitative initial assessment of the user interface for ease of use and visual information was obtained from a survey of five users (radiologists and scientists). Users evaluating the system were provided with a list of questions that was a modified and simplified version of an established user survey questionnaire for user-interface satisfaction [6]. Survey questions covered topics including ease of use, organization, content and clarity of the interface, learning curve, and willingness to use the module. All answers were graded on a scale from 1 to 10.
|
TopAbstractIntroductionSystem DesignResultsDiscussionConclusionReferences |
|---|
The qualitative evaluation of user responses showed satisfaction to be high. A detailed evaluation study involving more radiologists is currently under way. The visualization of the findings in an anatomic overview was helpful as a guide to the location of findings. Initial feedback suggested that users may require a finer granularity of the schematic than was available on our current design. Users preferred the flat interface design because it avoided navigation through multiple layers of graphic user interface windows. Editing features were intuitive and the wizard interface permitted easy creation of findings. For the evaluators, the major advantage of our system was the integration of speech, structuring, and editing, enabling the creation of structured reports in a single session.
|
TopAbstractIntroductionSystem DesignResultsDiscussionConclusionReferences |
|---|
We can also use improved natural language processing modules as they become available. The version of the natural language processing module used in this investigation has a recall and precision of 85% and 90%, respectively. Considerable progress has since been made to the natural language processing module that has raised the recall and precision of mass findings to 98% and 100%, respectively (Taira RK et al., presented at the American Medical Informatics Association fall symposium, Orlando, FL, 1999). These improvements would have a considerable impact on reducing the time required to create a structured report. The visualization and editing module is written in Java to support platform independence. The modular nature of the system permits us to incorporate other improved speech recognition modules as they become commercially available.
Currently, the prototype implementation is as a standalone system. However, it can be fully integrated into the radiology information system so that dictation, transcription, structuring, and editing could be performed from a workstation for routine radiology reporting. In the integrated version, both the free text and structured reports can be stored and accessed by common keywords in the header file. The module can be used to retrospectively structure legacy free text reports stored in radiology information system databases. These structured reports can then be optionally edited by radiologists. This option will provide a powerful method to index existing documents and provide retrieval access to information that was either nonretrievable or had to be manually extracted.
In addition to our current methodology of incorporating natural language processing techniques for the creation of structured radiology report data, efforts are also under way to investigate the direct entry of structured data [1, 2]. Initial usage of these systems has been limited to focused areas such as sonography, in which it was fairly successful [1, 2]. However, it remains to be seen whether this methodology will gain widespread acceptance because it deviates from the current practice of generating radiology reports such as dictation. Our approach allows physicians to dictate their free text report and obtain a graphic summarization of an automatically generated structured report. The preliminary results are positive, although natural language processing techniques are by no means a solved problem. Both methods, structuring using natural language processing methods and direct entry of structured data will have to be investigated in greater depth to determine the applicability and acceptability of these techniques.
|
TopAbstractIntroductionSystem DesignResultsDiscussionConclusionReferences |
|---|
|
TopAbstractIntroductionSystem DesignResultsDiscussionConclusionReferences |
|---|
CiteULike 
Complore 
Connotea 
Del.icio.us 
Digg 
Reddit 
Technorati What's this?
This article has been cited by other articles:
|
|
 |
|
  C.-S. Yam, N. Rofsky, J. Kruskal, and A. Sitek Development of a Radiology Report Monitoring System for Case Tracking Am. J. Roentgenol., January 1, 2005; 184(1): 343 - 346. [Abstract] [Full Text] [PDF]
|
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| HOME | HELP | FEEDBACK | SUBSCRIPTIONS | ARCHIVE | SEARCH | TABLE OF CONTENTS |
