AJR 2005; 184:343-346
© American Roentgen Ray Society
Development of a Radiology Report Monitoring System for Case Tracking
Chun-Shan Yam1,
Neil Rofsky1,
Jonathan Kruskal1 and
Arkadiusz Sitek1
1 All authors: Department of Radiology, Beth Israel Deaconess Medical Center and
Harvard Medical School, WCC, 1 Deaconess Rd., Rm. 306, Boston, MA 02215.
Received October 31, 2003;
accepted after revision April 3, 2004.
Address correspondence to C-S Yam
(csyam{at}caregroup.harvard.edu).
Abstract
OBJECTIVE. The objective was to develop an automated system to
monitor and collect radiology reports for case-tracking purposes.
CONCLUSION. The system we developed allows users to automate the
case-tracking process for either clinical follow-up or teaching purposes. With
this system, radiologists can initiate the tracking of a case by dictating a
keyword into the report. Any existing and future reports associated with the
same patient will be collected automatically. The schematic that we developed
is based on the Health Level Seven (HL7) standard, which is
platform-independent. In our implementation, we used an IBM-compatible
computer and commercially available software. Users can monitor the
case-tracking progress from Web browsers.
Introduction
Keeping track of radiology cases for either clinical or teaching purposes
is a time-consuming task for radiologists. During normal case readouts, the
radiologist must remember the patient's name or identification number (ID) or
make a brief note for tracking. For that, the most practical solution is to
use a notepad. Often, one can find bundles of little papers in the pockets of
the radiologists' lab coats. This written information is the first step of the
case-tracking process. In fact, the process has not really started yet. First
of all, he or she still must transfer this written information from paper into
a computer spreadsheet program such as Excel or Access (Microsoft). More
detailed clinical information from the radiology report must also be entered
into the spreadsheet. When follow-up studies occur for the same patient, the
radiologist must repeat this process. Although there is nothing wrong with
using a little piece of paper to remember cases, losing them may trigger
Health Insurance Portability and Accountability Act (HIPAA) issues
[1]. We identified the need to
develop an automated system to remember, collect, and organize tracking cases.
The advantage of using an automated system is that it streamlines clinical
workflow, lessens HIPAA concerns, and eliminates human errors in writing and
typing.
Research studies have been performed to develop gateways to the reporting
system
[2–5].
The general scope of these studies was to enhance clinical workflow or perform
data mining. In this article, we describe a simple automated system for
tracking cases by monitoring and collecting radiology reports using a
platform-independent approach. The fundamental concept of our system is
adherence to the Health Level Seven (HL7) standard. HL7 is one of several
American National Standards Institute-accredited standards, which provides
specifications and protocols for health care domains. The major domain of the
HL7 is clinical and administrative data.
HL7 Standard
Equivalent to the DICOM protocol, which is a standard being used in medical
image transfer, HL7 is becoming the standard in medical information
communications in today's hospital information system (HIS) and radiology
information system (RIS). In HL7 communications, data flow of radiology
reports between client and server can be described as a five-step process: a
transmission control protocol using Internet protocol (TCP/IP) connection is
established between client and server applications, an initial message is sent
from client to server for verification, verification is returned from server
to client, report data are transmitted from client to server, and the server
acknowledges the data arrival. After all the data transmissions are finished,
the TCP/IP connection can be closed by the client application. However, in
actual practice (production mode), the connection is usually kept open all the
time. Detailed information on current HL7 developments, vendor conformance
statements, and software resources is available at the official HL7 Web site
[6].
On the basis of this standard, we implemented an HL7 receiving system to
collect radiology reports in real time. With the ability to access the report
stream, we could extract the desired reports effortlessly and flawlessly.
System Design
Process Flow
Figure 1 shows the process
flow of our system. Live radiology reports are sent from the HIS data center
to our system, using HL7 protocol. The report is then processed by a data
parser that determines if it should be extracted for case tracking. The
extracted reports are then stored in the reviewing radiologist's personal
folder. Users can access their own tracking cases via a secured intranet Web
browser or network-shared connections. Each component of the system is
detailed in the following paragraphs.
View larger version (13K):
[in this window]
[in a new window]
[as a PowerPoint slide]
|
Fig. 1. —Flow process of automated case-tracking system. When new
report is dictated into hospital information system (HIS), copy of this report
is sent to Health Level Seven (HL7) receiver module of our system. Data parser
module determines if report should be extracted on basis of keyword field
content and patient's identification number. Extracted reports are stored in
individual radiologist's personal folder in Excel or Access (Microsoft)
format. Data access is restricted to authenticated users in intranet.
|
|
HL7 Receiver
Because the report transfer is based on the HL7 standard, the only software
requirement on our system is the ability to receive HL7 reports. In our
implementation, we used the commercial software LinkTool (LINK Medical
Computing), which costs $850, as the HL7 receiver. The software runs on an
IBM-compatible host system with a Windows 2000 OS (Microsoft). The setup of
the HL7 receiver is simple. One needs to provide the IP address and the port
number. A similar setup is required on the HIS at the data center to send us
the reports. The fact that the setup in HL7 is similar to that of DICOM is
because both these sytems are based on TCP/IP communications. As mentioned
previously, the TCP/IP is platform-independent. Other systems that can perform
TCP/IP communications, such as Mac OS, Linux, and Unix, can also be used as
the host system in receiving radiology reports. Many software resources and
development toolkits are available on the Internet
[7–9].
The HL7 receiver is operating 12 hr a day from 6:00 am to 6:00 pm. Reports
created during odd hours are carried over to the next day's transactions.
Under routine clinical operation, radiology reports that arrive in the
hospital HIS system, either by voice dictation or terminal data entry, are
copied to our HL7 interface program in real time
(Fig. 1). Each report arriving
in our system is stored in the local hard drive as a text file. Each file
contains three separate sections: HL7 header message, report content, and HL7
footer message. Figure 2 is a
screen capture of a typical HL7 message showing the format of these three
sections. The header at the beginning of each file contains the initial
transaction messages. The footer at the end of each file contains special
characters that are used as a closure statement to the initial messages.
Special characters used when developing a message are as follows: Segment
Terminator, Field Separator, Component Separator, Subcomponent Separator,
Repetition Separator, and Escape Character. More detailed information on the
format of the HL7 message is available at the official HL7 Web site
[6].
View larger version (41K):
[in this window]
[in a new window]
[as a PowerPoint slide]
|
Fig. 2. —Screen capture of typical Health Level Seven (HL7) message
for dictated radiology report. Each report message contains three separate
sections: HL7 header message, report content, and HL7 footer message. Because
this is standard format for every report message, one can easily extract
desired patient and study information from header. Again, report content is
extracted by scrubbing header and footer messages.
|
|
Data Parser
Because of the adherence of the unique format used in the HL7 message, we
can easily decode the information contained in the header: software version,
hardware unit, destination name, study description, patient name, ID,
referring physician, reviewing physician, accession number, date of service,
time of study, and so forth. In our implementation, we developed a simple data
parser using Visual Basic (Windows Scripting Language, Microsoft) to extract
the desired reports. As shown in the logic diagram in
Figure 1, two criteria are
checked. The first criterion is to see if the keyword field contains any
information. If the keyword field is not blank, as in the example shown in
Figure 2, the data parser will
extract the patient's ID value and enter it as a tracking case. The second
criterion is to match the patient's ID and extract the report into the
tracking system. In our implementation, when a patient case is tracked, all
the existing reports and any future reports for the same patient will be
automatically collected. Thus, the radiologist will have a complete collection
of all the studies performed on the same patient.
Again, the ability to extract desired reports is due to the HL7 standard,
rather than to the choice of visual basic script or Windows platform. Any
system that can perform text search, such as Mac OS, Linux, and Unix, can be
programmed to perform the keyword and patient ID search. By the same token,
using the keyword field to identify the patient case for tracking is an
arbitrary choice in our implementation. For example, one can program the data
parser to filter information from other parts of the report (e.g., history or
impressions) as well. The reason for using the keyword field as a trigger is
to facilitate categorization. As the example shows in
Figure 2, the radiologist
entered a brief note, PERIPHERAL ANGIO, in the keyword field. This helps in
organizing all cases that are related to that category.
Report Storage
When a report has been identified for tracking, the data parser will
extract the following parameters from the report: referring physician's name,
radiologist's name, patient's name, patient's ID, date of study, examination
type, accession number, and keyword. All reports are stored in the reviewing
radiologist's personal folder. Figure
3 is a screen capture of the folder structure of a typical
radiologist.
View larger version (40K):
[in this window]
[in a new window]
[as a PowerPoint slide]
|
Fig. 3. —Screen capture of folder content in one radiologist's
personal folder. All collected reports are stored under individual
radiologist's personal folder for easy viewing. For each tracking case,
individual radiology report is labeled with patient's name, date of study,
imaging technique, and accession number. For illustration purposes, patients'
and radiologists' names are anonymous.
|
|
Data Access
To facilitate data analysis and patient searching, we also store the
reports in both Excel and Access format for users to download to their
desktops. Figure 4 is a screen
capture of the design view of the main table of the Access database. Users can
access their own data via common Web browsers or by using network shared
access for both Macintosh and IBM. However, access is restricted to
authenticated users and for intranet only.
View larger version (35K):
[in this window]
[in a new window]
[as a PowerPoint slide]
|
Fig. 4. —Screen capture of design view of main table of Access
(Microsoft) database. All text parameters stored in this table are extracted
from radiology reports. Actual content of radiology report is stored in memo
field called "Radiology_Report."
|
|
Performance
We started using this system to collect RIS reports in August 2002. To
date, our automated case-tracking system has been running for 26 months. The
host PC runs 24 hr a day 7 days a week, and the interface program runs from
6:00 am to 6:00 pm. A total of five shutdowns occurred during this primary
period. Two shutdowns were required because of network errors at the data
center during equipment upgrades. Three shutdowns were required for Microsoft
security patch installations. The total downtime was 20 hr. However, with the
built-in backup utility in the HIS data center, all queued reports were
retransferred and no report was lost. A total of more than 1,300,000 reports
(both preliminary and final) were received. In an initial test by two
radiologists, the number of new tracking cases collected using the keyword
search was 82 per month. Although this is a small fraction of the total
reports received, the system does provide the automated function as
planned.
We use this system in our department to support both teaching and clinical
applications. For teaching files, all the tracked reports are transferred to
our departmental teaching file server. Teaching cases are then created using
the report information. For clinical applications, in one example, we use this
system to collect potential interventional radiology consulting cases and to
notify the on-call radiologists via e-mail.
Discussion
We developed an automated system to monitor and collect radiology reports
for tracking, teaching, and patient cases. With this system, radiologists can
collect radiology reports for their tracking cases in an on-thefly manner
while dictating. In our implementation, we used an IBM-compatible system and
commercial software to receive reports from the HIS. The method we developed
adheres to the HL7 standard. Any system that can perform TCP/IP
communications, such as Mac OS, Linux, and Unix, can use our method to collect
and monitor radiology reports. Many commercial HL7 products for different
computer platforms are available on the Internet
[7,
8,
10].
The infrastructure of this system was designed by a committee of 10
members, seven from the radiology department and three from the hospital HIS
system, with the aim of developing a system to provide the radiology
department with an easy and flexible way of accessing radiology reports.
Although this system was initially developed for tracking teaching cases,
we could append other research activities and daily radiology practices to
this system because of its simple logic and flexibility for creating custom
functions. Furthermore, because this system contains all the RIS reports (both
preliminary and final), we are extending it for data mining and quality
assurance.
References
- Joint Healthcare Information Technology Alliance (HIPAA).
Conference proceedings: charting a course—HIPAA implementation. In:
HIPAA: The facts you need for compliance. Chicago, IL:
Joint Healthcare Information Technology Alliance,2000
- Weltin G, Swett H. A computer utility for automated retrieval of
radiology reports. AJR 1996;166
: 1031-1033[Abstract/Free Full Text]
- Hripcsak G, Austin JHM, Alderson PO, Friedman C. Use of natural
language processing to translate clinical information from a database of
889,921 chest radiographic reports. Radiology2002; 224:157
-163[Abstract/Free Full Text]
- Sinha U, Dai B, Johnson D, et al. Interactive software for
generation and visualization of structured findings in radiology reports.
AJR 2000;175:609
-612[Abstract/Free Full Text]
- Bui ATT, Taira RK, Dionisio JDN, Aberle DR, ElSaden S, Kangarloo H.
Evidence-based radiology: requirement for electronic access. Acad
Radiol 2002;9:662
-669[Medline]
- Health Level Seven Web site. Available at:
www.hl7.org.
Accessed October 6, 2004
- Link Medical Computing Web site. Available at:
www.linkmed.com.
Accessed October 6, 2004
- Interfaceware Web site. Available at:
www.interfaceware.com.
Accessed October 6, 2004
- HL7 Resource Library Web site. Available at:
www.hl7.org/library.
Accessed October 6, 2004
- Swearingen Software Web site. Available at:
www.swearingensoftware.com.
Accessed October 6, 2004
CiteULike 
Complore 
Connotea 
Del.icio.us 
Digg 
Reddit 
Technorati What's this?
Top
Abstract
Introduction
