- Email: [email protected]
DICOM Structured Reporting—a prototype implementation
International Congress Series 1230 (2001) 795 – 800
DICOM Structured Reporting—a prototype implementation J. Riesmeiera,*, M. Eichelberga, K. Kleberb, H. Oosterwijkc, S. von Gehlena, D.H.W. Gro¨nemeyerb, P. Jenscha,d a
b
Kuratorium OFFIS e.V., Escherweg 2, 26121 Oldenburg, Germany Institute for MicroTherapy, Department of Radiology and MicroTherapy, University Witten/Herdecke, Universita¨tsstr. 142, 44799 Bochum, Germany c OTech, Inc., 2001 East Oakshores Drive, Crossroads, TX 76227, USA d Carl von Ossietzky Universita¨t Oldenburg, Postfach 2503, 26111 Oldenburg, Germany
Abstract About 1 year ago, Digital Imaging and Communications in Medicine (DICOM) Structured Reporting (SR) has been released as an official extension of the DICOM standard. Structured Reporting introduces a new concept for structuring and encoding medical reports in a standardised manner. Since this approach is quite different from any other extension that has been added to the DICOM standard in the past, it is not surprising that there is no ‘‘real’’ application available up to now. However, we have developed a DICOM SR editor and viewer, and demonstrated this prototype at RSNA infoRAD 2000 and ECR 2001 together with two of DICOM’s new security extensions: secure network transmission and digital signatures. D 2001 Elsevier Science B.V. All rights reserved. Keywords: DICOM; Structured Reporting; Medical report; Security
1. Introduction Since the initial release in 1993, the Digital Imaging and Communications in Medicine (DICOM) standard [1] has not only quite successfully penetrated the PACS domain. At the same time, the standard has significantly broadened its scope from a mere radiology image
*
Corresponding author. Tel.: +49-441-972-2142; fax: +49-441-972-2102. E-mail address: [email protected] (J. Riesmeier).
0531-5131/01/$ – see front matter D 2001 Elsevier Science B.V. All rights reserved. PII: S 0 5 3 1 - 5 1 3 1 ( 0 1 ) 0 0 1 3 7 - 6
796
J. Riesmeier et al. / International Congress Series 1230 (2001) 795–800
interchange protocol to a ubiquitous medical imaging standard that covers a multitude of services (e.g. printing, media storage, workflow support or the recent security extensions) and medical fields (e.g. cardiology, radiotherapy, ophthalmology). With the release of DICOM Structured Reporting (SR) as an official extension of the standard, DICOM now enters a completely new domain that is only indirectly related to medical imaging. The development of DICOM SR has taken significantly longer than initially expected due to differing ideas on what Structured Reporting should be and what it should not. The final version of the DICOM Structured Reporting specification (Suppl. 23) has been approved in April 2000. In principle, DICOM SR is a general model allowing to encode medical reports in a structured manner in DICOM’s tag-based format. Therefore, the existing DICOM infrastructure (network services, PACS, etc.) can be used to archive and communicate structured reports with only relatively small changes to existing systems. In addition to the header information that is also used for DICOM images, the actual content of a structured report is represented by a document tree; in fact, it is a directed acyclic graph (DAG). Each content item (node) of the tree contains some piece of information (e.g. a text paragraph or a reference to an image). A set of well-defined relationships describes how ‘‘parent’’ and ‘‘child’’ content items in the hierarchical document structure are related to each other. Fig. 1 shows an example of a simple SR document tree consisting of a root container object, a set of text objects and a reference to an image. The concept (semantics) of most content items in the SR document tree is described by a machine-readable code (e.g. SNOMED or ICD 10) and, therefore, enables computer-supported automatic evaluation and processing. Fig. 2 shows a rendering of the report, together with the referenced key image, in which the headlines of the document sections have been derived automatically from the machine-readable codes attached to each text object in the SR document tree. Fig. 2 also shows the two document status flags that each SR document carries; the ‘‘completion flag’’ indicates whether a document is partial or complete, and the ‘‘verification flag’’ indicates whether or not the document has already been verified and approved. The DICOM standard does not precisely define the meaning of these two flags. The interpretation we have chosen is once a report is marked as ‘‘complete’’, its content cannot be changed anymore; it can only be amended by revised versions of the document which are stored separately. We allow only completed documents to be verified, and the process of verification is also
Fig. 1. Simple SR document tree.
J. Riesmeier et al. / International Congress Series 1230 (2001) 795–800
797
Fig. 2. Screenshot of DICOM SR prototype implementation.
the point in time where the verifying observer can optionally add a digital signature to the report.
2. Material and methods An Open Source implementation of a DICOM SR editor and viewer was developed for the purpose of demonstration at RSNA infoRAD 2000. The implementation called ‘‘DICOMscope’’ combines a DICOM image viewer with Structured Reporting facilities and also supports the recent DICOM security enhancements. We developed two separate layers for this purpose: a C++ class library that extends the well-known OFFIS DICOM toolkit ‘‘DCMTK’’ and allows to read, write and manipulate SR documents, and a Java graphical user interface with an SR viewer and editor. Both parts, Java and C++, are linked via the Java Native Interface (JNI). This combination enables portability on different platforms (the application supports Windows NT and Linux as well as Solaris) without any performance penalty for computationally intensive operations. The software is available as Open Source Freeware [2,3]. Our basic concept was to implement the entire SR model under a technical viewpoint rather than concentrating on a particular clinical application. Therefore, our software allows to read and display (render) all SR document classes as well as to create, modify and write such documents and to perform the document management functions provided
798
J. Riesmeier et al. / International Congress Series 1230 (2001) 795–800
Fig. 3. SR editor—tree view of SR document and selection of editor components.
by SR (revise, verify, etc.) The ‘‘technical approach’’ also shows on the user interface that the viewer presents the rendered report as a single HTML document with hyperlinks (e.g. to images) and that the editor maps the hierarchical structure of the document tree directly to the screen, allowing to modify the contents on item level. Fig. 3 shows on the left-hand side an example of a complex SR document tree in the editor. The right-hand side of the figure shows the editor components for containers, text objects and image references, respectively. While this editor is able to handle all structurally valid SR documents independent of document type, it is clear that the user interface is not well-suited to any clinical application.
3. Results Our software demonstrates that it is indeed possible to implement DICOM SR with justifiable effort. According to our experience, this requires a complete understanding of SR and its underlying concepts, though. One should realise that SR is not only ‘‘just another modality’’ like the new image formats that are introduced to DICOM quite frequently. In our opinion, the very general structure of DICOM SR is currently also the main issue that remains to be solved in practice. No medical user would probably be willing to use a software which requires him to enter the different pieces of a report in a hierarchical tree item structure, as our prototype does. Intuitive user interfaces, however, are likely to be
J. Riesmeier et al. / International Congress Series 1230 (2001) 795–800
799
tailored towards particular clinical applications, which also means that they will not handle the generic SR model at its full breadth, but only a well-defined subset of SR suitable for that particular clinical scenario. For this reason, DICOM introduces the concept of ‘‘SR Templates’’, pre-defined documents structures and code dictionaries for particular clinical applications. Both templates and codes for particular medical fields are currently under development and some of them will probably be integrated into our software in the future. A very simple template called ‘‘Key Object Selection’’, allowing to mark relevant images in a study, has also been proposed as a separate SR document class recently [4]. Another example is the ‘‘Mammography CAD’’ report template, which allows to encode the results of mammography CAD system in a standardised manner.
4. Discussion For a particular medical field of application, the requirements for implementing the SR model would be lower than with our general approach since it should be sufficient to support only a fixed number of templates and codes. Although the user interface can be represented by a static input mask in this case, a significant effort still needs to be invested in the intuitive handling of SR reports. However, only a cross-vendor agreement on suitable SR templates will make structured reports fully interchangeable between different implementations. SR seems to open another new field for future standardisation in DICOM. DICOM is not the only standard introducing structured medical reports. HL7 has also started a similar approach with the ‘‘HL7 Clinical Document Architecture’’ (CDA) [5] based on XML. HL7 CDA can be understood more or less as a competitor of DICOM SR. It will be interesting to see whether both standards will converge in the future as some people expect. It is also not yet clear whether or not ‘‘semantically loss –less’’ conversions between both formats will be possible. The current ‘‘CDA Level One’’ specification does only support very basic layout formats (like HTML) rather than real structuring elements (like XML).
5. Conclusion DICOM Structured Reporting is a general-purpose framework for reporting purposes that needs to be filed in order to become usable for daily practice. Templates and codes are currently being developed and selected by the DICOM committee [6]. Vendors of medical equipment have already started implementing SR for the IHE (Integrating the Healthcare Enterprise) demonstration [7] at RSNA 2000 and HIMSS 2001. However, most early SR implementations are rather rudimentary, and it will definitely take a while until commercial SR applications fulfilling the users’ needs are available. With the introduction of medical reports to the DICOM world, other new extensions of the standard also become more important, especially those dealing with security. We have already demonstrated the secure transmission of DICOM data at RSNA infoRAD 2000 and an implementation of digital signatures in DICOM at ECR 2001.
800
J. Riesmeier et al. / International Congress Series 1230 (2001) 795–800
References [1] NEMA Standards Publication PS 3.x, Digital Imaging and Communications in Medicine (DICOM), National Electrical Manufacturers Association, 2101 L Street, N.W., Washington, DC 20037, 1992 – 2000. [2] OFFIS DICOM Project, http://www.offis.de/projekte/dicom/. [3] Institute for MicroTherapy, http://www.microtherapy.de/go/dicomscope/. [4] DICOM Standards Committee, Working Group 6: Digital Imaging and Communications in Medicine (DICOM), Supplement 59: Key Object Selection Document SOP Class, Letter Ballot, January 2001. [5] Health Level 7: Clinical Document Architecture Framework, Version 1.0 Draft 08/2000. [6] DICOM Standards Committee, Working Group 6 Base Standard: Digital Imaging and Communications in Medicine (DICOM), Supplement 53: DICOM Content Mapping Resource (DCMR), Letter Ballot, January 2001. [7] Integrating the Healthcare Enterprise, http://www.rsna.org/IHE/.
DICOM Structured Reporting—a prototype implementation J. Riesmeiera,*, M. Eichelberga, K. Kleberb, H. Oosterwijkc, S. von Gehlena, D.H.W. Gro¨nemeyerb, P. Jenscha,d a
b
Kuratorium OFFIS e.V., Escherweg 2, 26121 Oldenburg, Germany Institute for MicroTherapy, Department of Radiology and MicroTherapy, University Witten/Herdecke, Universita¨tsstr. 142, 44799 Bochum, Germany c OTech, Inc., 2001 East Oakshores Drive, Crossroads, TX 76227, USA d Carl von Ossietzky Universita¨t Oldenburg, Postfach 2503, 26111 Oldenburg, Germany
Abstract About 1 year ago, Digital Imaging and Communications in Medicine (DICOM) Structured Reporting (SR) has been released as an official extension of the DICOM standard. Structured Reporting introduces a new concept for structuring and encoding medical reports in a standardised manner. Since this approach is quite different from any other extension that has been added to the DICOM standard in the past, it is not surprising that there is no ‘‘real’’ application available up to now. However, we have developed a DICOM SR editor and viewer, and demonstrated this prototype at RSNA infoRAD 2000 and ECR 2001 together with two of DICOM’s new security extensions: secure network transmission and digital signatures. D 2001 Elsevier Science B.V. All rights reserved. Keywords: DICOM; Structured Reporting; Medical report; Security
1. Introduction Since the initial release in 1993, the Digital Imaging and Communications in Medicine (DICOM) standard [1] has not only quite successfully penetrated the PACS domain. At the same time, the standard has significantly broadened its scope from a mere radiology image
*
Corresponding author. Tel.: +49-441-972-2142; fax: +49-441-972-2102. E-mail address: [email protected] (J. Riesmeier).
0531-5131/01/$ – see front matter D 2001 Elsevier Science B.V. All rights reserved. PII: S 0 5 3 1 - 5 1 3 1 ( 0 1 ) 0 0 1 3 7 - 6
796
J. Riesmeier et al. / International Congress Series 1230 (2001) 795–800
interchange protocol to a ubiquitous medical imaging standard that covers a multitude of services (e.g. printing, media storage, workflow support or the recent security extensions) and medical fields (e.g. cardiology, radiotherapy, ophthalmology). With the release of DICOM Structured Reporting (SR) as an official extension of the standard, DICOM now enters a completely new domain that is only indirectly related to medical imaging. The development of DICOM SR has taken significantly longer than initially expected due to differing ideas on what Structured Reporting should be and what it should not. The final version of the DICOM Structured Reporting specification (Suppl. 23) has been approved in April 2000. In principle, DICOM SR is a general model allowing to encode medical reports in a structured manner in DICOM’s tag-based format. Therefore, the existing DICOM infrastructure (network services, PACS, etc.) can be used to archive and communicate structured reports with only relatively small changes to existing systems. In addition to the header information that is also used for DICOM images, the actual content of a structured report is represented by a document tree; in fact, it is a directed acyclic graph (DAG). Each content item (node) of the tree contains some piece of information (e.g. a text paragraph or a reference to an image). A set of well-defined relationships describes how ‘‘parent’’ and ‘‘child’’ content items in the hierarchical document structure are related to each other. Fig. 1 shows an example of a simple SR document tree consisting of a root container object, a set of text objects and a reference to an image. The concept (semantics) of most content items in the SR document tree is described by a machine-readable code (e.g. SNOMED or ICD 10) and, therefore, enables computer-supported automatic evaluation and processing. Fig. 2 shows a rendering of the report, together with the referenced key image, in which the headlines of the document sections have been derived automatically from the machine-readable codes attached to each text object in the SR document tree. Fig. 2 also shows the two document status flags that each SR document carries; the ‘‘completion flag’’ indicates whether a document is partial or complete, and the ‘‘verification flag’’ indicates whether or not the document has already been verified and approved. The DICOM standard does not precisely define the meaning of these two flags. The interpretation we have chosen is once a report is marked as ‘‘complete’’, its content cannot be changed anymore; it can only be amended by revised versions of the document which are stored separately. We allow only completed documents to be verified, and the process of verification is also
Fig. 1. Simple SR document tree.
J. Riesmeier et al. / International Congress Series 1230 (2001) 795–800
797
Fig. 2. Screenshot of DICOM SR prototype implementation.
the point in time where the verifying observer can optionally add a digital signature to the report.
2. Material and methods An Open Source implementation of a DICOM SR editor and viewer was developed for the purpose of demonstration at RSNA infoRAD 2000. The implementation called ‘‘DICOMscope’’ combines a DICOM image viewer with Structured Reporting facilities and also supports the recent DICOM security enhancements. We developed two separate layers for this purpose: a C++ class library that extends the well-known OFFIS DICOM toolkit ‘‘DCMTK’’ and allows to read, write and manipulate SR documents, and a Java graphical user interface with an SR viewer and editor. Both parts, Java and C++, are linked via the Java Native Interface (JNI). This combination enables portability on different platforms (the application supports Windows NT and Linux as well as Solaris) without any performance penalty for computationally intensive operations. The software is available as Open Source Freeware [2,3]. Our basic concept was to implement the entire SR model under a technical viewpoint rather than concentrating on a particular clinical application. Therefore, our software allows to read and display (render) all SR document classes as well as to create, modify and write such documents and to perform the document management functions provided
798
J. Riesmeier et al. / International Congress Series 1230 (2001) 795–800
Fig. 3. SR editor—tree view of SR document and selection of editor components.
by SR (revise, verify, etc.) The ‘‘technical approach’’ also shows on the user interface that the viewer presents the rendered report as a single HTML document with hyperlinks (e.g. to images) and that the editor maps the hierarchical structure of the document tree directly to the screen, allowing to modify the contents on item level. Fig. 3 shows on the left-hand side an example of a complex SR document tree in the editor. The right-hand side of the figure shows the editor components for containers, text objects and image references, respectively. While this editor is able to handle all structurally valid SR documents independent of document type, it is clear that the user interface is not well-suited to any clinical application.
3. Results Our software demonstrates that it is indeed possible to implement DICOM SR with justifiable effort. According to our experience, this requires a complete understanding of SR and its underlying concepts, though. One should realise that SR is not only ‘‘just another modality’’ like the new image formats that are introduced to DICOM quite frequently. In our opinion, the very general structure of DICOM SR is currently also the main issue that remains to be solved in practice. No medical user would probably be willing to use a software which requires him to enter the different pieces of a report in a hierarchical tree item structure, as our prototype does. Intuitive user interfaces, however, are likely to be
J. Riesmeier et al. / International Congress Series 1230 (2001) 795–800
799
tailored towards particular clinical applications, which also means that they will not handle the generic SR model at its full breadth, but only a well-defined subset of SR suitable for that particular clinical scenario. For this reason, DICOM introduces the concept of ‘‘SR Templates’’, pre-defined documents structures and code dictionaries for particular clinical applications. Both templates and codes for particular medical fields are currently under development and some of them will probably be integrated into our software in the future. A very simple template called ‘‘Key Object Selection’’, allowing to mark relevant images in a study, has also been proposed as a separate SR document class recently [4]. Another example is the ‘‘Mammography CAD’’ report template, which allows to encode the results of mammography CAD system in a standardised manner.
4. Discussion For a particular medical field of application, the requirements for implementing the SR model would be lower than with our general approach since it should be sufficient to support only a fixed number of templates and codes. Although the user interface can be represented by a static input mask in this case, a significant effort still needs to be invested in the intuitive handling of SR reports. However, only a cross-vendor agreement on suitable SR templates will make structured reports fully interchangeable between different implementations. SR seems to open another new field for future standardisation in DICOM. DICOM is not the only standard introducing structured medical reports. HL7 has also started a similar approach with the ‘‘HL7 Clinical Document Architecture’’ (CDA) [5] based on XML. HL7 CDA can be understood more or less as a competitor of DICOM SR. It will be interesting to see whether both standards will converge in the future as some people expect. It is also not yet clear whether or not ‘‘semantically loss –less’’ conversions between both formats will be possible. The current ‘‘CDA Level One’’ specification does only support very basic layout formats (like HTML) rather than real structuring elements (like XML).
5. Conclusion DICOM Structured Reporting is a general-purpose framework for reporting purposes that needs to be filed in order to become usable for daily practice. Templates and codes are currently being developed and selected by the DICOM committee [6]. Vendors of medical equipment have already started implementing SR for the IHE (Integrating the Healthcare Enterprise) demonstration [7] at RSNA 2000 and HIMSS 2001. However, most early SR implementations are rather rudimentary, and it will definitely take a while until commercial SR applications fulfilling the users’ needs are available. With the introduction of medical reports to the DICOM world, other new extensions of the standard also become more important, especially those dealing with security. We have already demonstrated the secure transmission of DICOM data at RSNA infoRAD 2000 and an implementation of digital signatures in DICOM at ECR 2001.
800
J. Riesmeier et al. / International Congress Series 1230 (2001) 795–800
References [1] NEMA Standards Publication PS 3.x, Digital Imaging and Communications in Medicine (DICOM), National Electrical Manufacturers Association, 2101 L Street, N.W., Washington, DC 20037, 1992 – 2000. [2] OFFIS DICOM Project, http://www.offis.de/projekte/dicom/. [3] Institute for MicroTherapy, http://www.microtherapy.de/go/dicomscope/. [4] DICOM Standards Committee, Working Group 6: Digital Imaging and Communications in Medicine (DICOM), Supplement 59: Key Object Selection Document SOP Class, Letter Ballot, January 2001. [5] Health Level 7: Clinical Document Architecture Framework, Version 1.0 Draft 08/2000. [6] DICOM Standards Committee, Working Group 6 Base Standard: Digital Imaging and Communications in Medicine (DICOM), Supplement 53: DICOM Content Mapping Resource (DCMR), Letter Ballot, January 2001. [7] Integrating the Healthcare Enterprise, http://www.rsna.org/IHE/.