DOI: 10.1148/rg.274065124
RadioGraphics 2007;27:1201-1211
© RSNA, 2007
Informatics in Radiology
A Prototype Web-based Reporting System for Onsite-Offsite Clinician Communication1
Corey W. Arnold, MS,
Alex A. T. Bui, PhD,
Craig Morioka, PhD,
Suzie El-Saden, MD, and
Hooshang Kangarloo, MD
1 From the Medical Imaging Informatics Group (C.W.A., A.A.T.B., C.M., S.E., H.K.) and the Department of Information Studies (C.W.A.), University of California, Los Angeles, 924 Westwood Blvd, Suite 420, Los Angeles, CA 90024. Presented as an infoRAD exhibit at the 2003 RSNA Annual Meeting. Received June 27, 2006; revision requested August 18; final revision received January 25, 2007; accepted February 19. Supported in part by NIBIB grants PO1-EB00216 and RO1-EB002247, and by NLM Medical Informatics Training grant LM07356. All authors have no financial relationships to disclose.
Address correspondence to C.W.A. (e-mail: cwarnold{at}ucla.edu).
 |
Abstract
|
|---|
The communication of imaging findings to a referring physician is an important role of the radiologist. However, communication between onsite and offsite physicians is a time-consuming process that can obstruct work flow and frequently involves no exchange of visual information, which is especially problematic given the importance of radiologic images for diagnosis and treatment. A prototype World Wide Web–based image documentation and reporting system was developed for use in supporting a "communication loop" that is based on the concept of a classic "wet-read" system. The proposed system represents an attempt to address many of the problems seen in current communication work flows by implementing a well-documented and easily accessible communication loop that is adaptable to different types of imaging study evaluation. Images are displayed in a native (DICOM) Digital Imaging and Communications in Medicine format with a Java applet, which allows accurate presentation along with use of various image manipulation tools. The Web-based infrastructure consists of a server that stores imaging studies and reports, with Web browsers that download and install necessary client software on demand. Application logic consists of a set of PHP (hypertext preprocessor) modules that are accessible with an application programming interface. The system may be adapted to any clinician-specialist communication loop, and, because it integrates radiologic standards with Web-based technologies, can more effectively communicate and document imaging data.
© RSNA, 2007
|
Introduction
|
|---|
In the hospital environment, a physician in the emergency department may request an imaging study that is "wet-read" by an emergency radiologist, who then immediately communicates the results back to the physician (typically by phone). In contrast, less time-sensitive imaging (such as with outpatients) can be performed at satellite imaging centers, with several days required for the imaging to be scheduled and for the images to be read and returned to a referring physician. However, there also exists a set of conditions and scenarios in which a wet-read may not be required but in which an expedited and interactive documented review of an imaging study (facilitated by making the images and associated annotations available to offsite users) could be beneficial. For example, an outside primary care physician (PCP) may request an imaging study from a radiology service to quickly rule out one of several possible diagnoses and may want to view marked-up key images from the study to better understand the nature and severity of the underlying disease (eg, as part of educating him- or her self or the patient). Similarly, at many health care institutions, night call is performed by offsite radiologists who must wet-read emergency images and convey their findings, not only back to the referring health care provider, but also to the onsite radiologist, who will later perform a final reading to ensure a concordance of findings. In both situations, a seamless World Wide Web–based loop between an offsite clinician (eg, radiologist, PCP) and an onsite radiologist can provide improved communication of images and text without disturbing traditional work flow. Such a loop may be based on the classic paradigm of a wet-read, in which imaging information is shared at an expedited rate and specific questions posed by a clinician are answered through direct communication.
Because the prevalence of commercial picture archiving and communication systems (PACS) has increased, wet-reads are often performed using these systems. Although offsite image reporting has improved dramatically, there still exist systems that offer only limited support for viewing, manipulating, and annotating imaging data stored in an institutional PACS. In addition, the review of images and associated findings generated by onsite radiologists may be possible only for an immediate network of users with direct access to the image repository and any ancillary databases, thereby limiting the ability of a referring clinician from a different institution to review annotated images. Presently, telephones and fax machines are the standard communication media for sharing information between offsite and onsite clinicians (1,2). Studies of e-mail as a means of sharing information have demonstrated it to be an effective mode of communication, but an inflexible means of presenting complex media (3). Moreover, because of closed implementations and proprietary standards, many PACS lack the capacity for the rapid evolution and the integration of more advanced reporting tools that would allow improved sharing of imaging information between offsite and onsite clinicians. Perhaps more important, the lack of a standard and architecture for structuring the content of study requests, radiology reports, and the resultant images has prevented the creation of a generalized wet-read framework. Most wet-read solutions have yet to take advantage of a range of reporting tools and Web-based technologies to reach such potential.
In this article, we discuss and illustrate an open-source solution to support onsite-offsite clinician communication, leveraging Web-based techniques to create a feedback loop. This loop begins with an imaging referral and the capture of significant diagnostic questions, proceeds to image acquisition and the formulation of responses by the radiologist, and is closed by the dissemination of results to the referring physician. On the basis of a study by Muto et al (4), a Java-based applet was developed that supports several extensible modules: (a) the ability to export the results to standardized reports, which may be communicated between onsite and offsite clinicians; (b) the creation of structured data (eg, using Digital Imaging and Communications in Medicine [DICOM] standards) with secondary applications in teaching files or research; and (c) the mapping of findings and imaging terms to a controlled lexicon.
|
Background and Related Work
|
|---|
Onsite-offsite clinician communication plays an important role in the sharing of patient imaging data (5). Designing a system to take into account the environment of a clinician and his or her duty to facilitate communication helps ensure its acceptance. Thus, a Web-based system for wet-reads and image communication should be integrated into a PACS and make use of as many existing protocols and standards as possible to ensure widespread usability. Current PACS generally offer a Web-based view of radiologic images and reports (6–9); compared with the capabilities of the full-fledged PACS workstations in a hospital, however, such a Web-based view is typically limited in its review, reporting, and annotation capabilities.
Multiple areas of research and development can be drawn upon to elucidate issues relevant to this effort and are briefly described in the following paragraphs.
Structured Reporting and Presentation States
Radiologic findings may best be expressed through annotated images; text alone may not be sufficient to document information or interpretation. In such cases, the ability to denote and specify regions of interest with explicitly linked textual descriptions can allow the unambiguous presentation of important findings on the image. DICOM structured reporting (SR) classes and presentation states (PS) (10) can be used to store and transmit image-centered documents along with annotations and descriptive text. Work with templates and extensible markup language (XML) has made these standards easier to implement and has proved beneficial in outcomes analysis (11–19).
Radiologic Image Annotation
Annotating images in a standard manner with methodologies that allow context-sensitive presentation is a current research problem that is receiving significant attention. Goede et al (20) define an annotation and its purpose using requirements assessments from radiologists, ophthalmologists, neurobiologists, anatomists, and dermatologists as well as medical students. Zheng et al (16) developed a Web-based annotation system for digital mammograms using overlays and the Breast Imaging Reporting and Data System lexicon. However, although these studies demonstrate the usefulness of structured annotations and Web-based systems, neither deals specifically with the wet-read process.
Teaching Files
The requirements for electronic teaching files are very similar to those for Web-based wet-read systems (21,22). These two applications require comparable user interfaces that are designed to guide the user through image annotation and capture, and once the selected images have been annotated, they are transferred over a network to a server, which then distributes the images. Open-source and proprietary solutions have been developed that make use of controlled vocabularies for efficient and accurate case retrieval (23,24).
|
System Design
|
|---|
Between the hours of 5 PM and 8 AM, emergency radiology interpretations are performed at our institution by residents on call at offsite locations. After being notified of a case, the resident logs into the Web-based PACS view to perform the study interpretation. However, this view is read only and does not allow the resident to return any information to the PACS. Although this fact does not impede the resident’s notifying the referring emergency department physician of the wet-read results over the telephone, it does prevent the transfer of information to the onsite PACS from which the daytime radiologist will perform a final interpretation. As a workaround, residents currently must document a list of wet-reads performed in the course of an evening using a text editor and then e-mail the file to administrative personnel, who redistribute the list to onsite radiologists the next day. Unfortunately, this system is not easily integrated into a work flow because it requires a radiologist to interrupt his or her routine by accessing a separate system (eg, e-mail, hard copy) and, for each pending case, checking to see if a wet-read was performed the previous evening. An additional factor complicating this process is that the list of the previous night’s wet-reads may not be released until after a radiologist has already begun his or her interpretations. It is clear that the current system can result in discordant findings not being resolved in a timely manner if an onsite radiologist is unaware of a previous wet-read performed on the study that he or she is interpreting.
In a second scenario, radiology reports for patients referred to our imaging center are faxed to a PCP (or other referring physician) by administrative personnel. This process may not be completed until 1–4 days following imaging. Although this process is not inherently problematic, there is no transfer of the actual imaging information and associated annotations that formed the basis of the radiologist’s diagnosis. Although it is typically unnecessary for a PCP to review a patient’s imaging studies, cases can exist in which doing so is helpful in gaining a better understanding of a patient’s condition. Currently, the infrastructure at our institution does not allow this imaging information to be shared electronically with a PCP.
Limitations exist in today’s PACS-based image annotation systems, which are currently the primary means of communicating image-centered information. Technologies to improve this process do exist; however, they are not yet in place due to the nature of PACS development and the lack of a unifying standard. In an attempt to illustrate its potential clinical, research, and teaching benefits, a prototype system integrating current technologies and standards was developed that facilitates an onsite-offsite clinician "communication loop" in the context of an electronic wet-read.
Several design considerations drove the development of this system: (a) the need for image manipulation and reporting akin to the basic operations of a normal PACS workstation to accommodate offsite radiologists or users; (b) the need to disseminate results to physicians not necessarily within the same medical enterprise, thereby providing them with ready access to the system’s contents; and (c) the ability to extend or configure the system (eg, to add new annotation tools) using different modules. Satisfying the first requirement necessitates information transfer with the hospital PACS and display of the images in a native DICOM format, thereby allowing accurate presentation along with typical window width and level, scaling, rotation, and further image manipulation tools. The second requirement can be satisfied by using a Web-based infrastructure, consisting of a server that receives and stores DICOM images and associated data from a PACS, with Web browsers downloading and installing necessary client software on demand. This strategy helps overcome data-user locality issues and arguably outweighs the limitations of Web-based programming (as opposed to custom software applications). The third and final requirement can be satisfied by using modular application logic to guide the work flow, which was implemented with a set of PHP (hypertext preprocessor) modules and application programming interfaces.
The overall architecture consists of a base image viewer that is implemented as a secure Java applet and provides a general interface for reading and annotating images. This client-side applet is responsible for providing all user functionality except database queries and DICOM SR-PS creation, which are handled by server-side processes and the hospital PACS. The applet ensures that collected data are structured and allows the user to tag images and findings with selected American College of Radiology (ACR) codes. These codes are subsequently mapped to the Unified Medical Language System (UMLS) with use of a manually generated template. A process-information flow was first developed to show how medical image-centered information may be shared between onsite and offsite clinicians; Figure 1 illustrates the steps involved in the two scenarios for which the system is to be used. Modules were designed around these process flows. All data passed between the logical application modules are stored in a MySQL database. The details of each module are described in the following sections.
View larger version (33K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 1. Diagram illustrates a system developed for onsite-offsite clinician communication. The system allows communication between offsite PCPs and onsite radiologists, as well as between offsite radiologists performing wet-reads and onsite radiologists performing final interpretations.
|
|
Wet-Read Request Module
In our hypothetical scenarios, a wet-read request may be initiated by submitting a patient’s information to the request module. This request takes the place of phoning or paging the on-duty radiologist. Unlike a phone call, which allows two-way communication, the proposed system relies on the description provided by the referring clinician to inform the radiologist of the problem. However, if the description is thought to be inadequate, the radiologist may phone the referring physician for clarification. At present, user accounts are manually assigned to referring clinicians to ensure proper security and authentication in the system. The requesting physician accesses a Web page, logs in, and completes a form by providing the patient’s name, demographic information, and identification number (Fig 2). In addition, the request type, the chief complaint, and the reason for examination are recorded to aid the onsite radiologist. The request type is selected from a drop-down menu and is associated with a set of predefined questions (ie, a template) that are pertinent to the problem. For example, if the chief complaint is headache, the request for a brain magnetic resonance imaging study may invoke a template with questions regarding various rule in–rule out diagnoses (eg, presence of brain tumor, presence of infection). These template questions form the basis for the radiologist’s response and are termed pertinent positives and pertinent negatives. Additional questions can be posed by the referring physician in a Comments field. Presently, templates are designed by domain experts and stored in a database table and can be used in turn to guide the creation of DICOM SR documents. The PCP-entered data from the Web page form are submitted to the server using the hypertext transfer protocol (HTTP) request-response method and are received by a PHP script on the server that stores them in the request table. The request module is then signaled to begin querying for images.
Image Request Module
Once it has been invoked by the wet-read request module, a Java servlet will retrieve images from the hospital PACS to the wet-read server. With use of the DICOM protocols C-FIND and C-MOVE, an image study is queried for and retrieved based on the information contained in the original form (eg, the patient’s identification number). These standard protocols are used to transfer information between the PACS and other systems that implement the standard. A C-FIND query requests study information for specific patients, whereas a C-MOVE query transfers imaging studies and reports between systems. If the wet-read request arrives before the images have been uploaded to the PACS, the servlet will make queries at regular intervals until the images have been successfully downloaded. The module does not perform any prefetching of prior patient studies; if necessary, however, these studies may be viewed on the existing Web-based PACS.
Annotation Module
The annotation module supports two separate functions to facilitate the operational scenarios of the system: (a) providing an annotation interface for the offsite radiologist, and (b) accepting PS objects from the hospital PACS system and constructing reports for the referring PCP.
Annotation Interface.—
The annotation module serves as a mechanism for offsite radiologists to view, manipulate, and codify images in support of the wet-read interpretation and reporting process, with the onsite radiologist subsequently performing a final interpretation (eg, the next day). Pending wet-reads are pushed to a queue in the system and are viewed by the offsite radiologist. The radiologist then logs into the annotation interface, where the Java applet is downloaded from the wet-read server to the client and commences the transfer of images from the server to the local Web browser. Once an image is downloaded, the applet parses the DICOM header to select the initial display parameters (eg, image size, window width and level) for the user. At this point, the user may begin reading and annotating the series using the basic annotation tools (window width and level, zoom, line drawing, measuring, text overlays). As part of the reading process, the radiologist responds to the pertinent positives and pertinent negatives posited as part of the requesting doctor’s original inquiry, thereby answering questions relevant to the chief complaint; further comments can also be entered (Fig 3). All pertinent positive and pertinent negative template questions are in a discrete form so that the radiologist may respond by clicking on a checkbox or radio button. Although this constraint may limit the expressiveness of the report, it helps compile structured data that are easier to manage and analyze. However, a free-text comment box is also provided so that the radiologist may convey any additional observations as part of the initial interpretation. A list of ACR anatomy and pathology codes (Fig 3) are provided for the optional tagging of the images to support future applications of the data. After completing the process, the radiologist invokes the Save Series button; the annotation data and report information are then returned to the server through a uniform resource locator, where a PHP script parses the PS information and annotations and saves the data into the database.
View larger version (103K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 3. Screen used by the offsite radiologist to perform a wet-read. A study is annotated by scrolling through images, marking up selected images and typing in comments when appropriate. A indicates pertinent positive and pertinent negative questions, as well as a free-text comment box; B indicates selectable ACR anatomy and pathology codes, which may be selected to support future uses of the data; C indicates various image annotation, manipulation, and viewing tools; and D indicates the image window, which displays the current image in the series.
|
|
If there is more than one series in the study, the radiologist may continue the reading process. Once the study has been read in its entirety, the radiologist invokes the Submit Patient button, which updates the wet-read request status to "READ." A server-side script then creates a PS object for annotated images in the study and sends it to the hospital PACS to be saved for the onsite radiologist performing the final interpretation. This last step is performed for two reasons: (a) to ensure that the onsite radiologist is aware of the wet-read and will take appropriate action should discordant findings exist; and (b) to eliminate the need for the radiologist to access a separate log (eg, e-mail, hard copy) to check for wet-reads performed the previous evening, a significant impediment to work flow.
In this framework, the offsite radiologist is required to access the proposed system. The institution’s Web-based PACS may also be consulted if prior studies are available for comparison. Instead of using a phone, the referring physician uses an online interface to request a wet-read. The electronic request forms currently in place at our institution can be altered to reflect specific queries, thereby making additional credentialing unnecessary. The offsite radiologist calls findings in to the referring physician, with additional information being conveyed in the form of a textual and graphic synopsis of the salient findings. This information is also captured for the attending radiologist who will perform the final interpretation the next morning, so that any necessary changes in interpretation may be conveyed to the referring clinician as well as to the offsite resident radiology trainee.
Report Construction.—
After the interpretation of a study on the onsite PACS, the module automatically fetches the results. The radiologist is required only to mark up the images of interest, which will be captured and attached to the impressions section of the report, thereby requiring only minimal extra effort or divergence from the normal PACS readout. A server-side script accepts and reads this information, placing it into a database. The status of the PCP’s request is updated to "READ," indicating that the study is ready to view. After the status has been updated, the script generates an e-mail to the PCP to notify him or her of the completed wet-read. This level of notification is deemed acceptable because it is not relied upon to communicate emergency information. If emergency findings are discovered, the radiologist personally contacts (via e-mail) a physician responsible for the patient’s care. The e-mail contains no protected health information, but simply a brief message and a link to the Web-based wet-read report viewer, which requires a user to first log in. The e-mail notification and Web display of images and findings serve strictly as an added benefit for PCPs and do not replace the normal avenues of obtaining imaging reports. It is entirely up to a PCP as to whether he or she would like to make such a request and subsequently view the additional information provided by the Web view.
Presentation Module
Lastly, the presentation module makes use of a modified read-only version of the applet used by the annotation module, displaying the results of the radiologist’s read to the PCP. All PS variables, annotations, and the wet-read report are combined in an HTML page by means of additional parameters for the applet. Figure 4 shows the final generated view for an annotated image. The modified applet has much the same functionality as the annotation module applet, including window width and level settings and rotate-flip and zoom-pan functions. These functions allow the PCP to view the images as the radiologist intended, as well as to inspect the images independently. The interface is designed to quickly communicate the results of the study to the PCP by displaying the impressions section from the final report and the annotated images.
View larger version (94K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 4. Screen used to display imaging results to a PCP. Only the pertinent images are displayed, along with any associated comments. A indicates pertinent positive and pertinent negative findings and free-text comments; B indicates selected ACR anatomy and pathology codes; C indicates image manipulation and viewing tools, which are provided should the PCP wish to adjust the view to better understand the results; and D indicates the image window, which displays the current image in the series, along with annotations.
|
|
The presentation module also includes a feature that tracks when and by whom a report is viewed. With this feature, the radiologist is notified by e-mail that a report has been received by a clinician, thus completing the communication loop.
|
Discussion
|
|---|
Onsite-offsite clinician communication is an essential part of patient care in today’s medical environment, yet it is often overlooked as a tool for both understanding and documentation. An easily accessible combined imaging and textual synopsis of a study may greatly facilitate understanding and patient care for an offsite referring physician. Likewise, information generated by wet-reads performed by offsite residents and fellows must be effectively shared with onsite radiologists performing final interpretations to ensure that discordant findings are identified and resolved. Indeed, an ideal system should not only facilitate communication between clinicians, but could also serve as a repository of medical data and images, contextually complete and standardized to allow retrieval for teaching files, research, and other applications such as quality control tracking.
A Web-based image documentation and reporting system based on the concept behind traditional wet-read systems has been developed for use in supporting onsite-offsite clinician communication loops. The proposed system represents an attempt to address many of the issues in current wet-read systems by implementing a well-documented and easily accessible onsite-offsite communication loop adaptable to any type of read. The system provides export capabilities to standard formats and the ability to generate DICOM SR objects. Although our current PACS cannot accept outside DICOM SR objects, this feature was implemented for future applications and allows interoperability with any other system implementing the standard. The support of DICOM SR and the structured data format used by the system provide an interface for integration with an electronic medical record system. Instead of "burning in" annotations and PS information, resulting in multiple files for a single image, annotation data exist within separate files and may be overlaid on one image file, thereby reducing redundancy and minimizing storage requirements. Furthermore, because the application logic is independent from the data model, the interface is generalizable and can accommodate different types of imaging study requests or other image-related data. The system was built using open-source software and includes a Web-based interface that requires no additional installation of software on the user’s computer. The system has annotation and reporting capabilities that are currently unavailable in a Web-accessible form. These features may provide increased convenience and utility to users who currently rely on limited communication mechanisms as well as methods that poorly document information passed between onsite and offsite clinicians. The system is currently undergoing an initial evaluation by clinicians for deployment at a Veteran’s Administration hospital. Metrics for evaluation will include system use and access time information, technical aspects of system performance, and clinician satisfaction.
The generality of the system allows extensibility of core functionality. For example, the system allows the user to tag images with a standard lexicon, such as the ACR lexicon, which can in turn be used to support indexing and information retrieval applications. Because of the system’s modular architecture, lexicons can easily be modified or substituted (eg, UMLS, ACR, Rad-Lex) and different ontologies can be mapped together. Currently, these mappings are generated manually and are stored in a separate database. Methods of automatically suggesting codes and generating such mappings are being explored with use of statistical natural language processing techniques (25). Extensibility is also demonstrated in the image annotation module and the use of DICOM PS-SR components: Additional data generated with more advanced image manipulation or analysis tools can be stored as part of the reporting process.
Several opportunities exist to enhance this initial development.
Additional XML-based Representations and Protocols
The system would surely benefit from creating XML-based structured documents to represent the various wet-read classes. This capability would allow more efficient exchange of templates and would represent a step toward standardization. In addition, other data passing protocols, such as Web Access to DICOM Persistent Objects (10), Simple Object Access Protocol, or XML-RPC, should be implemented to simplify information transfer and the implementation of future revisions to the data model.
Teaching File Applications
The wet-read database also serves as an ideal basis for the development of secondary applications. For instance, the data collected during the wet-read process have significant educational potential and could be used to construct an online teaching file. Further work to (a) capture patient histories in conjunction with the information presently captured as part of the wet-read and (b) apply an annotation hierarchy to control the flow of information presentation (ie, the user is first presented with a textual description of the patient’s findings, and upon invoking a button, image annotations outlining the findings are displayed) are both necessary for this application. The file may be indexed according to patient demographic information as well as collected ACR codes and subsequently mapped UMLS codes.
Supporting Dialog between Clinicians and Radiologists
The system currently provides the referring physician with a static view of the wet-read report. Extending this view to support an (asynchronous) dialog between clinicians is an important area of future development (eg, this capability would allow a PCP to respond to the radiologist, requesting clarification of the wet-read or asking additional questions). This "continuous dialog" would in turn be captured and documented. This added functionality could also benefit secondary teaching file applications in that the case creators could dialog with students reviewing the cases. Such a feature would be more like e-mail than instant messaging, the main difference being that the conversation is captured within the Web-based system instead of a user’s e-mail application.
Closer Integration with PACS and Radiology Information Systems
Because of the proprietary nature of many hospital radiology information systems, a radiologist performing a final read must find and review a patient’s wet-read report on a separate system. It is anticipated that this limitation may cause some dissatisfaction among radiologists in a department-wide release, and therefore, methods for stronger integration are being developed. Closer integration may also aid in resolving differences in findings between the wet-read and final interpretation. Currently, the radiologist making the final read must contact the referring physician by telephone or e-mail to inform him or her of the discordant findings.
Natural Language Processing
To accommodate work flow, when an onsite radiologist interprets a study, he or she is not required to complete the report using the Web-based wet-read interface. Instead, the impressions section of the report stored on the PACS is parsed and used to create the view for the PCP by means of the presentation module. Although this accommodation limits the amount of structuring that is possible, we are refining natural language processing methods developed within our group (26) to automatically extract structured responses to the pertinent positive and negative questions from the free-text report.
|
Conclusions
|
|---|
The system described in this article has been discussed in the context of the wet-read concept. However, the system may be adapted to any clinician-specialist communication loop. By integrating radiologic standards (eg, DICOM, ACR, PACS) with Web-based technologies (eg, HTTP, PHP, MySQL), we have built a widely accessible application that can more effectively communicate and document imaging data.
|
TAKE-HOME POINTS
|
|---|
The lack of a standard and architecture for structuring the content of study requests, radiology reports, and the resultant images has prevented the creation of a generalized wet-read framework.
- The overall architecture consists of a base image viewer that is implemented as a secure Java applet and provides a general interface for reading and annotating images.
- The proposed system represents an attempt to address many of the issues in current wet-read systems by implementing a well-documented and easily accessible onsite-offsite communication loop adaptable to any type of read.
- The generality of the system allows extensibility of core functionality.
- By integrating radiologic standards (eg, DICOM, ACR, PACS) with web-based technologies (eg, HTTP, PHP, MySQL), we have built a widely accessible application that can more effectively communicate and document imaging data.
|
Footnotes
|
|---|
Abbreviations: ACR = American College of Radiology, DICOM = Digital Imaging and Communications in Medicine, HTTP = hypertext transfer protocol, PACS = picture archiving and communication system, PCP = primary care physician, PS = presentation state, SR = structured reporting, UMLS = Unified Medical Language System, XML = extensible markup language
|
References
|
|---|
- Blankenship JC, Menapace FJ, Fox LS, Frey CM. Telephone reporting of the results of cardiac procedures: feasibility and primary care physician preferences. Am J Med 1999;106:521–526.[CrossRef][Medline]
- Stille CJ, Primack WA, Savageau JA. Generalist-subspecialist communication for children with chronic conditions: a regional physician survey. Pediatrics 2003;112:1314–1320.[Abstract/Free Full Text]
- Liederman EM, Morefield CS. Web messaging: a new tool for patient-physician communication. J Am Med Inform Assoc 2003;10:260–270.[Abstract/Free Full Text]
- Muto K, Emoto Y, Katohji T, Nagoshima H, Iwata A, Koga S. PC-based Web-oriented DICOM server: the "DIY" DICOM server—cost-effective, high performance and easy to customize [abstr]. Radiology 2000;217(P):709.
- Kaplan B, Shaw NT. People, organizational, and social issues: evaluation as an exemplar. In: IMIA yearbook of medical informatics. Edmonton, Alberta, Canada: International Medical Informatics Association, 2002; 91–102.
- AGFA website. Available at: http://www.agfa.com/en/he/index.jsp. Accessed October 30, 2005.
- Siemens website. Available at: http://www.medical.siemens.com. Accessed October 30, 2005.
- Fuji website. Available at: http://www.fujimed.com. Accessed October 30, 2005.
- General Electric website. Available at: http://www.gehealthcare.com. Accessed October 30, 2005.
- National Electrical Manufacturers Association. Digital Imaging and Communications in Medicine (DICOM). Rosslyn, Va: National Electrical Manufacturers Association, 2006.
- Bidgood WD Jr. Clinical importance of the DICOM structured reporting standard. Int J Card Imaging 1998;14:307–315.[CrossRef][Medline]
- Zhao L, Lee KP, Hu J. Generating XML schemas for DICOM structured reporting templates. J Am Med Inform Assoc 2005;12:72–83.[Abstract/Free Full Text]
- Lee KP, Hu J. XML schema representation of DICOM structured reporting. J Am Med Inform Assoc 2003;10:213–223.[Abstract/Free Full Text]
- Hussein R, Engelmann U, Schroeter A, Meinzer HP. DICOM structured reporting: I. Overview and characteristics. RadioGraphics 2004;24:891–896.[Abstract/Free Full Text]
- Clunie DA. DICOM structured reporting. Bangor, Pa: PixelMed, 2000.
- Zheng Y, Wu M, Cole E, Pisano ED. Online annotation tool for digital mammography. Acad Radiol 2004;11:566–572.[CrossRef][Medline]
- Liberman L, Abramson AF, Squires FB, Glassman JR, Morris EA, Dershaw DD. The breast imaging reporting and data system: positive predictive value of mammographic features and final assessment categories. AJR Am J Roentgenol 1998; 171:35–40.[Abstract/Free Full Text]
- Geller BM, Barlow WE, Ballard-Barbash R, et al. Use of the American College of Radiology BI-RADS to report on the mammographic evaluation of women with signs and symptoms of breast disease. Radiology 2002;222:536–542.[Abstract/Free Full Text]
- Hussein R, Engelmann U, Schroeter A, Meinzer HP. DICOM structured reporting: II. Problems and challenges in implementation for PACS workstations. RadioGraphics 2004;24:897–909.[Abstract/Free Full Text]
- Goede PA, Lauman JR, Cochella C, Katzman GL, Morton DA, Albertine KH. A methodology and implementation for annotating digital images for context-appropriate use in an academic health care environment. J Am Med Inform Assoc 2004; 11:29–41.[Abstract/Free Full Text]
- Ernst RD, Baumgartner BR, Tamm EP, Torres WE. Development of a teaching file by using a DICOM database. RadioGraphics 2002;22:217–221.[Abstract/Free Full Text]
- Rosset A, Ratib O, Geissbuhler A, Vallee JP. Integration of a multimedia teaching and reference database in a PACS environment. RadioGraphics 2002;22:1567–1577.[Abstract/Free Full Text]
- Henderson B, Camorlinga S, DeGagne JC. A cost-effective web-based teaching file system. J Digit Imaging 2004;17:87–91.[CrossRef][Medline]
- Weinberger E, Jakobovits R, Halsted M. MyPACS.net: a Web-based teaching file authoring tool. AJR Am J Roentgenol 2002;179:579–582.[Abstract/Free Full Text]
- Bui AA, Taira RK, El-Saden S, Dordoni A, Aberle DR. Automated medical problem list generation: towards a patient timeline. San Francisco, Calif: Medinfo, 2004; 587–591.
- Taira RK, Soderland SG, Jakobovits RM. Automatic structuring of radiology free-text reports. RadioGraphics 2001;21:237–245.[Abstract/Free Full Text]
Top
Abstract
Introduction
