| HOME | HELP | FEEDBACK | SUBSCRIPTIONS | ARCHIVE | SEARCH | TABLE OF CONTENTS |
|
|
|
|||||||
|
|||||||||
infoRAD |
1 From the Division of Medical and Biological Informatics, H0100, German Cancer Research Center, Im Neuenheimer Feld 280, D-69120 Heidelberg, Germany; and Steinbeis-Transferzentrum Medizinische Informatik, Heidelberg. Received May 30, 2003; revision requested August 4 and received August 20; accepted September 15. Address correspondence to R.H. (e-mail: r.hussein@dkfz-heidelberg.de).
 |
Abstract |
|---|
 Top Abstract IntroductionState of the ArtProblems and ChallengesMethodSoftware Development Tools and...ResultsDiscussionConclusionsReferences |
|---|
© RSNA, 2004
Index Terms: Computers • Digital imaging and communications in medicine (DICOM) • Information management • Picture archiving and communication system (PACS) • Radiology reporting systems
|
Introduction |
|---|
|
TopAbstractIntroductionState of the ArtProblems and ChallengesMethodSoftware Development Tools and...ResultsDiscussionConclusionsReferences |
|---|
The biggest problem in SR implementation is to consider the combination of these customization factors to provide the end users with an extremely user-friendly SR toolkit while handling the complicated DICOM SR objects transparently.
The main aim of the work described herein is to overcome these problems and challenges while implementing a generic SR toolkit for picture archiving and communication system (PACS) workstations. This aim has been achieved by first addressing the SR implementation challenges in general and for PACS workstations in particular. Then, the available SR implementations and publications are surveyed to recognize how the different implementations and proposed models tried to overcome these challenges. Finally, approaches to solving these problems in order to avoid the reported drawbacks are provided.
The developed SR toolkit was integrated to CHILI (3) as a PACS workstation example (4). The CHILI architecture, which is based on a software component architecture, offers an environment for PACS and teleradiology (5). The main objective of the CHILI system is to efficiently distribute medical images both in-house and to external medical partners through a scalable architecture on stationary and mobile devices (6). On the other hand, the CHILI design provides the required flexibility to make the product comply not only with the communication standards but also with the Integrating the Healthcare Enterprise (IHE) technical framework (7).
|
State of the Art |
|---|
|
TopAbstractIntroductionState of the ArtProblems and ChallengesMethodSoftware Development Tools and...ResultsDiscussionConclusionsReferences |
|---|
To encourage healthcare implementers to incorporate the DICOM SR concepts with reduced implementation challenges, some SR models that use different approaches are provided, such as the following:
1. An object-oriented model was produced to represent DICOM SR. An extensible markup language (XML) exchangeable representation of this model was derived by using World Wide Web Consortium (W3C) specifications (10). In addition, an XML schema was developed for representing DICOM SR as XML documents, as described in reference 11.
2. An SR object model that uses the W3C recommendation to provide an XML Document Object Model (DOM) was introduced by Clunie (12).
3. A complete DICOM toolkit including SR was provided by OFFIS, Oldenburg, Germany (13). The OFFIS DICOM Toolkit is a collection of libraries and applications implementing large parts of the DICOM standard by using the C and C++ programming languages.
In addition, the National Electrical Manufacturers Association (NEMA) organized the Implementer’s Workshop on DICOM Structured Reporting in 2001 (14). The main aims of this workshop were to present and discuss the SR implementation experiences and to emphasize the practical use of real-world tools and applications. However, no implementation was concerned with providing a general-purpose SR application for PACS workstations. Most of the workshop participants were vendors of medical devices who showed how the modalities generate the initial SR reports of measurements and calculations performed by the different modalities during examinations (eg, ultrasound obstetrics and echocardiology reports) (15,16). The other SR implementers focused only on certain specialties, mainly cardiology, such as providing a cardiology image reporting system (17), developing a program that reads the cardiology templates and combines them with the patient data before generating the SR files (18), and converting data from cardiology devices into DICOM SR (19).
At the technical level, XML parsers and extensible stylesheet language (XSL-T) tree transformation engines are proposed by Clunie to parse the SR trees (12). An alternative solution was provided by using a C++ class library as described by OFFIS (13). Most of the applications rendered SR documents in hypertext markup language (HTML) format.
During the past 2 years, different SR implementers also presented their products during the IHE annual live system-to-system testing event called the Connectathon (20).
|
Problems and Challenges |
|---|
|
TopAbstractIntroductionState of the ArtProblems and ChallengesMethodSoftware Development Tools and...ResultsDiscussionConclusionsReferences |
|---|
The following points summarize the obstacles in implementing DICOM SR for PACS workstations from the different perspectives:
1. DICOM standard aspects include the following: (a) the complex structure of SR documents, particularly the enhanced and comprehensive SR documents; (b) the wide allowed areas in customizing the SR presentation, the user interface, and the database structure; (c) making the SR toolkit compliant with standard SR templates addressed in the DICOM Content Mapping Resource (DCMR) (21); and (d) support of key image notes (22).
2. Software aspects include the following: (a) automatic encoding of free-text reports into DICOM SR files; and (b) providing the end users with an easy-to-use, customizable SR toolkit.
3. PACS aspects include the following: (a) supporting the private templates used in different clinics; (b) handling third-party DICOM SR documents and key image notes; and (c) providing a generic, general-purpose toolkit that covers the different clinical specialties.
|
Method |
|---|
|
TopAbstractIntroductionState of the ArtProblems and ChallengesMethodSoftware Development Tools and...ResultsDiscussionConclusionsReferences |
|---|
|
2. The end-user modules provide healthcare practitioners with a free-text SR editor and viewer similar to the routinely used editors. The HTML format is used to represent the content of clinical reports.
3. The internal modules encapsulate the construction and encoding of DICOM SR files as well as the DICOM SR services (ie, storage, query, and retrieval) from the end users.
The following sections describe the internal components of the different modules and how they collaborate to achieve the required functionalities.
Administrator Module
This module consists of the SR setup utility, by which the system administrator can create the different templates for any specialty. This can be achieved by providing an easy-to-use utility to create the clinical document template (in HTML format) and its associated SR tree (in a separate text file). The SR trees are presented in a format that has been proposed by Clunie (23). Finally, both the HTML templates and their associated SR trees are saved in a predefined directory.
End-User Modules
The end-user modules consist of the SR editor and SR viewer utilities, by which the end users can create, edit, and view the clinical documents. The input of the SR editor is either (a) the HTML document template created by the SR setup in the case of creating a new report or (b) the currently viewed HTML report in the SR viewer in the case of editing, completing, verifying, or revising a precreated report.
The SR viewer first loads the required DICOM SR files to be displayed through querying the DICOM SR archive. Then, it displays the retrieved reports in HTML format after their conversion by the SR manager. Finally, the SR viewer provides the PACS workstation with a list of the referenced images to be selected and displayed.
For each PACS viewer, a scenario is required to link the SR documents with the referenced images. The proposed scenario used in this work is as follows:
1. Rendering precreated SR documents: (a) The PACS workstation indicates that the current selected patient’s study contains SR documents by displaying a report icon with the thumbnail images. (b) When one clicks on the report icon, the SR viewer is activated and queries the SR files contained in the selected study. (c) The referenced images and predecessor documents are represented as HTML hyperlinks in the SR HTML documents. When one clicks on the hyperlinks of predecessor documents, the original documents are automatically displayed in the SR viewer. If one clicks on the hyperlinks of referenced images, the SR toolkit provides the PACS workstation with a list of unique identifiers (UIDs) for referenced images to be marked and displayed.
2. Creating a new SR document: (a) If the selected study does not contain any SR documents, a new SR document is created and automatically loaded in the SR editor for editing. This process is performed by clicking on the SR button that was added to the main toolbar of the integrated PACS workstation. (b) The PACS workstation provides a list of the UIDs for the currently selected images to the SR editor by triggering a created function called "Set Referenced Images," in which the UIDs list for the selected images is passed as a parameter. Hence, these images are automatically referenced in the currently edited report in the SR editor and appear as hyperlinks within the HTML text.
Internal Modules
The internal modules are grouped in the SR manager. The main function of the SR manager is to maintain the accuracy and consistency of the SR tree for future encoding, viewing, and editing by using the SR managerial aspects stated in the DICOM standard. Therefore, the required tasks of the SR manager are as follows: (a) to encode a proper DICOM SR document by parsing the HTML document (created in the SR editor) using the associated SR tree of this report template (created by the SR setup); (b) to convert DICOM SR files to HTML documents for rendering via the SR viewer; (c) to manage the DICOM SR services (ie, querying, retrieving, and storing) transparently; (d) to handle the key image notes (in this work, the contents of key image notes are encoded as SR objects by using the same DICOM SR structure); (e) to handle third-party SR documents and key image notes; and (f) to automatically handle the DICOM SR managerial aspects, such as UIDs for SR instances based on the used UIDs of the integrated PACS product, copies and versions of documents, completion and verifications of documents, and so on.
To achieve these goals, many editing validation functions were implemented in addition to three main functions for report saving, rendering, and parsing:
1. The report saving function mainly handles the SR service object pair (SOP) instance UIDs according to the DICOM SR rules for creating new SOP instances. The integrated PACS application creates the new SR series. Then, the SR manager generates the SR SOP instance UIDs by using the specified root for the PACS vendor.
2. The report rendering function is accessed in the background. The SR manager internally calls this function to convert the DICOM SR file to the HTML format on the fly before rendering via the SR viewer and the SR editor.
3. The report parsing function is accessed before the report encoding in the DICOM format. The HTML report is parsed according to its associated SR tree created by the setup module (Fig 2). The parser traverses the SR tree levels in the background and obtains the corresponding value of each node from the HTML document. In the case of free-text reports that contain multiple coded items within continuous text under a subtitle, the parsing process of strings will be bi-dimensional. This means that at each tree level and during the vertical parsing process, parsing will also be horizontally performed to obtain all the values of the multiple children at this level.
|
Coded Entries Table
Figure 3 shows the coded entries table, in which all concepts used in constructing the SR documents are stored. Coded entries are presented mainly by the triplet of code value, coding scheme designator, and code meaning. The coding scheme version is used when the coding scheme designator does not imply a version. The DICOM Content Mapping Resource (DCMR) defines lists of grouped codes, which are called context groups and convey the context in which the codes are used.
|
Radiologic Workstation
To introduce a pragmatic example, the SR toolkit was integrated into the CHILI PACS workstations. CHILI is a family of software components for PACS and teleradiology. Its reporting workstation, PACS viewers, and Web viewers have built-in teleradiology functionality to provide cooperative teleconferencing. A strong security concept, based on the European regulations for data security and protection, is the basis for the storage and distribution of medical images and cooperative work on these images (24).
|
Software Development Tools and Environment |
|---|
|
TopAbstractIntroductionState of the ArtProblems and ChallengesMethodSoftware Development Tools and...ResultsDiscussionConclusionsReferences |
|---|
Development Toolkit and Environment
The Linux operating system (SuSE version 7.2 with K Desktop Environment [KDE] version 2.0) is the main development environment (25,26). Qt (Unix/X11) version 3.0 is used as the development toolkit (27,28). Qt is a cross-platform and fully object-oriented C++ framework.
OFFIS DICOM Toolkit
The OFFIS DICOM Toolkit version 3.5.2, which supports SR, was integrated to provide SR tree construction and encoding (29). The OFFIS DICOM SR module provides an SR class library and command-line tools that read, write, create, and manipulate the SR objects of all SR classes. In addition, it converts SR to XML and displays SR as text or HTML. The OFFIS DICOM SR module uses HTML 3.2/4.0, cascading style sheets (CSS), and document type definition (DTD). It maps DICOM character sets to HTML 3.2/4.0 as far as possible. References within the SR document are mapped to hyperlinks.
Developed Modules
The different developed modules of the SR toolkit—namely, the administrator module (SR setup), end-user modules (SR editor and SR viewer), and internal modules (SR manager)—in general use the Qt generic C++ classes, as follows: (a) The user interface of the SR toolkit uses the Qt Menu bars, Tool bars, and Painter classes to provide the overall SR toolkit with a customizable user interface. (b) The SR setup, SR editor, and SR viewer are inherited from the Qt Text Edit to support both text and HTML formats. (c) The Qt Tab Widgets class was implemented as well to be able to display multiple reports simultaneously.
The OFFIS DICOM Toolkit was integrated into the SR manager (internal modules) to provide the SR toolkit with the SR encoding and DICOM services (eg, SR files query and retrieve). However, a new SR document class was inherited from the OFFIS SR Document class and implemented in the SR manager. In this way, the SR manager has its own functions required to integrate the SR toolkit with any PACS product. These functions are mainly as follows: (a) HTML rendering is the ability to fit the appearance of HTML reports with the end users’ requirements. (b) Verify Document by Date is the ability to construct DICOM SR files via parsing the displayed HTML report. (c) Set Study Instance UID, Set Series Instance UID, and Set SOP [service object pair] Instance UID represent the ability to be integrated into any PACS product. Finally, the SR toolkit plug-in was developed, in which all developed modules are embedded.
|
Results |
|---|
|
TopAbstractIntroductionState of the ArtProblems and ChallengesMethodSoftware Development Tools and...ResultsDiscussionConclusionsReferences |
|---|
SR Setup
The SR setup (administrator module) is used to create and edit the report templates, either the DICOM standard templates or private ones. The SR setup consists mainly of the template HTML editor (on the left side) and its associated SR tree text editor, which appears below the coded entries table (on the right side) (Fig 4). The coded entries table contains the required triplet encoding items (code value, coding scheme designator, and code meaning) for the used coded entries. This table is extensible to cover all coded entries used in any clinic template.
|
|
An additional toolbar was created to manage SR tree construction. It includes different combo boxes for the following: (a) SR information object definitions (IODs) (basic, enhanced, and comprehensive text SR); (b) value types of the content items; and (c) relationships. The SR toolbar also contains buttons for controlling the depth of the SR tree during tree construction and traversal.
To help the administrator in constructing the SR tree, the SR tree toolbar enables only the allowed value types and relationships of different content items according to the selected SR IOD. In addition, it guides the administrator at each tree level to recognize which entry is expected (ie, either a value type or a relationship) by enabling only the matched control of the required entry.
The administrator constructs the clinical template in the HTML editor by selecting the appropriate items from the coded entries table. The code meaning values, which represent the report titles or headings, are pasted automatically into the HTML editor by just double clicking on the code meaning. Concurrently, the associated SR tree is automatically created in the SR tree text editor. However, the SR tree can also be modified by hand, if required. Furthermore, the administrator adds hints to each created HTML template (Fig 4b). These hints guide the end users toward knowing the position of editable lines, the expected value to be entered, and so on.
For further parsing by the SR manager, some editing rules are followed during template creation, such as the following: (a) Report headings or categories (eg, titles, subheadings) must have bold formats; (b) the order of concept names must be preserved as they appear in the SR tree; and (c) the HTML template must be saved with the report title name. Finally, the HTML template and its associated SR tree are saved in a predefined directory.
SR Viewer
The SR viewer (end-user modules) renders the HTML presentation of precreated reports, which are located in the DICOM SR archive, in a successive-multiple-pages user interface (Fig 5). The user can select which report to render by clicking on its tab. Concurrently, the SR viewer provides the integrated PACS workstation with a list of the referenced images to be selected and displayed. The referenced images and the predecessor documents appear as hyperlinks in the HTML document.
|
In both cases, when the user clicks on the referenced image hyperlinks, the corresponding image thumbnails are automatically marked. Consequently, the referenced images are automatically displayed in the image workspace.
A similar approach is used to create a new SR document for the currently selected patient. In this case, the user clicks on the SR button, which is added to the application toolbar, to activate the SR editor with a new document. The report image hyperlinks automatically refer to the currently selected images.
SR Editor
The SR editor (end-user modules) provides the end users with an easy-to-use HTML editor for creating new reports, based on their corresponding templates created by the SR setup, in addition to the ability to revise the completed status reports or modify the contents of precreated documents.
The SR editor supports all SR information object definitions (IODs) (basic text, enhanced, and comprehensive SR) as well as private free-text reports. The SR editor consists of the report HTML editor (on the left side) and the coded entries table (on the right side) (Fig 6). The editing toolbar provides the end users with the editing functions (cut, copy, paste, undo, redo, save, and print).
|
SR Manager
The SR manager (internal modules) works as a broker between the various modules. Hence, it transparently converts between the different document formats required by each module, as follows: (a) creating DICOM SR files for storing, (b) using text SR trees and HTML templates for creating new reports, and (c) creating HTML reports for editing and rendering. Furthermore, the SR manager automatically applies the managerial rules of the DICOM SR standard as well as the DICOM query, retrieve, and store services. As a result, the SR manager performs all the heavy work of DICOM SR in the background without any user intervention.
To achieve this aim, the SR manager automatically follows these rules (Fig 7): (a) Only the partially completed status documents are editable. (b) The completed documents are displayed in the viewer as read-only documents and can only be revised. (c) The verification function is activated only after document completion. (d) The document can be multiply verified, and the current observer’s name is automatically added to the report observers’ list. (e) The predecessor documents appear as hyperlinks in the report header for automatic document tracking through the multiple report pages. (f) The templates combo box is activated only when a new report is being created. (g) The coded entries table is automatically loaded with only the matched codes used in the currently selected template. (h) The report content date and time are automatically managed. (i) The document titles and headings are not editable; in addition, the templates contain hints to guide the user during the entry process.
|
Handling Key Image Notes
The SR toolkit also supports key image notes according to the key object selection template addressed in the DICOM Content Mapping Resource (DCMR). This template was specified to mark the DICOM objects as of interest, rejected for quality reasons, or for teaching, conference, research, therapy, and so on.
Figure 8 shows an example of use of a key image note to mark the selected image(s) as rejected for quality reasons. By following the same methodology as the SR editor, the key image note header and the observation context are automatically filled in according to the current user information. Then, the user selects the reason from the coded entries table and it is automatically pasted into the document. The hyperlinks automatically refer to the currently selected image(s) in the PACS workstation. Finally, the user can optionally enter a description of the referenced images.
|
|
Discussion |
|---|
|
TopAbstractIntroductionState of the ArtProblems and ChallengesMethodSoftware Development Tools and...ResultsDiscussionConclusionsReferences |
|---|
The following points summarize the information gathered from the National Electrical Manufacturers Association (NEMA) SR Implementer’s Workshop (14): (a) Only a limited area of SR applications (mainly cardiology) was targeted. As a result, a generic SR toolkit that covers a large variety of applications (as required in PACS installations) was not provided. (b) No generic module was provided to handle any kind of SR templates, for example, to support both standard and private templates. (c) No intelligent module was provided to handle the coded entries of the SR tree in the background automatically and without any user intervention. (d) Most of the SR creation and editing modules were not user-friendly. For instance, the documents are edited via a treelike user interface. This method is not convenient for reports that contain large sections of free text. (e) There was inability to visualize or difficulty visualizing third-party reports of unknown structure.
The available publications on SR modeling indicate the following (10): The proposed SR object models mainly address healthcare departments that do not support the DICOM standard, that is, those outside the PACS environment. These models transcode DICOM SR into other representations, such as the Health Level Seven (HL7) clinical document architecture (CDA) based on XML (30) or Web-based technology using XML. In this way, SR documents can be easily distributed to all clinical departments.
From the different experiences gained from this survey on different SR applications and models, the drawbacks and challenges described have been solved in the developed SR toolkit by the following means:
1. Distributing the tedious SR work over various modules and different documents formats (Fig 1) not only separates the hard work from the end user but also guarantees the accuracy and consistency of the SR documents. At the implementation level, this has been achieved by the automatic filling in of the SR headers from the applications database, performing all transcoding processes between different document presentations and SR managerial specifications in the background, and implementing numerous validation functions to track SR tree construction. As a result, it has been feasible to provide a fully featured, user-friendly SR toolkit for PACS workstations.
2. Use of generic design approaches, for example, the coded entries table, facilitates handling the different types of DICOM SR documents and being compliant with any DICOM standard or private template.
3. Traditional DICOM binary encoding applications and toolkits are re-used in SR encoding. The OFFIS DICOM Toolkit was mainly chosen to be integrated into the CHILI application because both are written in the C++ programming language (27,29). In addition, the OFFIS DICOM Toolkit supports generic design approaches that can efficiently handle any SR document (13).
4. From the PACS workstation perspective, HTML has been used rather than XML to provide a more user-friendly SR presentation. This is because HTML provides explicit presentation of information, which is readable by a wide range of tools. By contrast, XML contains no explicit or implied presentation. Therefore, XML documents should be combined with some form of presentation tool in order to render them, for example, style sheets written in extensible stylesheet language (XSL) or cascading style sheets (CSS). In this case, the PACS workstation should understand how to render the SR documents into an appropriate form.
5. Developing the SR toolkit plug-in has provided a self-contained software component that easily integrates into the different PACS products. On the other hand, the SR toolkit uses the conventional menus, toolbars, and user interface colors for document handling. However, the toolkit user interface was created by using generic classes that facilitate customization of the user interface to the integrated PACS product (Fig 5).
6. Outside the DICOM-based domain of PACS, implementation of the DICOM SR standard is not recommended (10). This is because practically all of the end users of clinical reports are referring physicians who use HL7-based information systems. The optimal solution is to export the SR results to the HL7 domain by using the HL7 CDA (30), when it is finalized. In this case, it would be better to represent the different SR documents in XML.
|
Conclusions |
|---|
|
TopAbstractIntroductionState of the ArtProblems and ChallengesMethodSoftware Development Tools and...ResultsDiscussionConclusionsReferences |
|---|
Nevertheless, SR defers to the other industry standards in allowing wide areas of customization. Despite the fact that customization promotes innovation, there are many challenges to providing end users with an easy-to-use, free-text SR toolkit while transparently handling the sophisticated SR specifications. In the healthcare enterprises, one of the main challenges of SR is to truly interoperate the DICOM SR standard within the healthcare work flow, in different clinical scenarios, and with different information exchange formats such as HL7 version 3.0, which will be XML based. Consequently, the impact of SR is still unrecognizable until the DICOM SR standard is integrated into the hospital information system (HIS) in the healthcare enterprises.
The future direction of this work is to support delivery to the point of care whenever needed. This means delivery of DICOM SR to the PACS workstations and delivery of Web-based documents to the enterprise. The CDA standard will be capable of interfacing DICOM with HL7 information for enterprise implementation. In particular, CDA Level 3—though it is not yet finalized—maps the SR content to the HL7 Reference Information Model (RIM) components (30). Hence, the SR toolkit will use the CDA standard to provide the SR toolkit with the required XML-based open technologies for integrated implementations. In this way, vital information can be seamlessly transferred from system to system, within and across departments. Furthermore, this will decrease the barriers for applying Web-aware applications and technologies.
For the time being, the described SR toolkit is integrated with the CHILI PACS workstations. The benefits of sharing the clinical knowledge of the SR documents are to enhance understanding during consultations, to enable reusability of the clinical findings for training, and to facilitate evaluation of the overall performance. As a result, the healthcare enterprise increases the effectiveness and efficiency of the clinical work flow for better healthcare service.
|
Acknowledgments |
|---|
|
Footnotes |
|---|
See also the article by Hussein et al (pp 891–896) in this issue.
|
References |
|---|
|
TopAbstractIntroductionState of the ArtProblems and ChallengesMethodSoftware Development Tools and...ResultsDiscussionConclusionsReferences |
|---|
Related Article
This article has been cited by other articles:
|
|
 |
|
  C. W. Arnold, A. A. T. Bui, C. Morioka, S. El-Saden, and H. Kangarloo Informatics in Radiology: A Prototype Web-based Reporting System for Onsite-Offsite Clinician Communication RadioGraphics, July 1, 2007; 27(4): 1201 - 1211. [Abstract] [Full Text] [PDF]
|
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| HOME | HELP | FEEDBACK | SUBSCRIPTIONS | ARCHIVE | SEARCH | TABLE OF CONTENTS |
| RADIOGRAPHICS | RADIOLOGY | RSNA JOURNALS ONLINE |
