Today, in accordance with the theme of this session, I want to discuss DICOM Structured Reporting, its role in the Cardiology Electronic Patient Record, and its status in the effort to support the practicing clinician. <>
So what is DICOM Structured Reporting? Or, as it is commonly called, &quot;SR.&quot; <> First, it is a means for encoding structured clinical documents. Think of a structured document as one in which all information is organized under headings and subheadings in a hierarchical tree. And although there are several technical mechanisms that could be used, we are using the well-established DICOM object encoding syntax. <> Second, SR leverages the open DICOM object management infrastructure for exchanging documents between systems. This includes sending objects by network or on disk, query and retrieve from an archive, and other network services such as security. <> Third, DICOM SR provides unambiguous documentation of meaning through a robust set of data types, as well as the ability to provide linkages or relationships between sections of a document. <> Fourth, SR is tailored to needs of the image-intensive clinical environment, with careful attention paid to the need to document the clinical context of observations, as well as being able to link to information contained in DICOM image and waveform objects. <>
Just a few comments on what DICOM SR is not. <> It is not just final clinical reports. Indeed, SR can be used for any structured data to be exchanged between systems, including things like hemodynamic measurements, quantitative analysis results, sonographer notes, et cetera. <> DICOM SR is also not structured data entry, by which I mean the common technique of using pull-down menus to support report creation. And although structured data entry is a valuable means of creating structured report content in certain circumstances, DICOM does not standardize such applications or data entry techniques. <>
Where can cardiology use SR? <> Obviously, the first use case is for clinical reports. In fact, as soon as the DICOM standard for Xray angiography interchange was completed, DICOM Working Group 1 turned to the issue of how to send the clinical report along with the pretty pictures. <> Following close behind is the need to send the analyses that support the findings of the clinical report, such as the hemodynamic measurements, <> as well as the other supporting documentation of a procedure, such as a cath procedure log to provide context for the images and waveforms. <> Another important use is to be able to send case data to a clinical database, whether that is a local cardiology information system supporting direct patient care, or a national or international registry for outcomes analysis. Let's look at an example of how some of these use cases work out in the cath lab. <>
[view this slide in presentation mode with transitions] As the case begins, we begin collecting information in the procedure log. <> When we acquire a run, that event will be logged with a pointer to the image object. <> Similarly, when we record a hemo waveform, that event will be logged with a pointer to that object. <> We continue with the case, acquiring more images, <> perhaps perform an intevention <> and record post intervention images <> and hemodynamics. At some point we will <> create a hemodynamics report with references to the two original waveforms, and <> perhaps creating a derived waveform to illustrate a finding. <> And the hemo report when complete will be referenced from the procedure log. <> Now we prepare the clinical cath report. <> As supporting information for the narrative description of the procedure we include a reference to the log. <> The summary hemodynamic findings in the report have a reference to the hemo report if more detail is desired, <> and significant pre- <> and post-intervention images are referenced. We see in this example that all the information for the case, even though captured in separate information objects, possibly stored on separate servers, is all hyper-linked by the DICOM SR objects into a virtual unified electronic patient record. In fact, <>
Structured Reporting is the glue that makes possible construction of an electronic patient record for cardiology. <> Obviously, this vision is not quite here yet. What is the status of DICOM SR?
As anyone who has worked in this area will testify, standardizing structured reporting is hard , both technically and politically. Indeed, formal work on DICOM SR began in 1994, although the idea has been around long before that. And any presentation on SR must include a tribute to Dean Bidgood, who through sheer tenacity in the face of seemingly insurmountable challenges made it a reality. Last December, Dean was awarded the first DICOM Lifetime Achievement Award for this work. SR was adopted into the DICOM standard in April 2000. It defined a general format for Structured Report objects based on the standard DICOM composite object model; that is, it includes a standard header with patient, study, and series descriptors. The hierarchical tree of document content items is encoded in a set of nested sequences. One of the major features is that concepts are represented by coded vocabulary terms; the standard allows the use of non-DICOM lexicons and coding systems, such as Reed codes, SNOMED codes for anatomy, ICD-9 or 10 diagnosis or procedure codes, or the ECG lead IDs defined in the CEN SCP-ECG standard. Supplement 23 also defined three general classes of SR documents - clinical reports with just plain text in a hierarchical outline structure, reports with both numeric and coded content in addition to the plain text, and reports with the full range of data types and inter-item references. All in all, the DICOM SR standard provides an extremely flexible format for document encoding; and that is a problem. <>
DICOM SR in its raw form is too flexible to provide good interoperation between systems. A document creator can put anything in a document, in any structure he wants to use. The system that wants to read such a document, however, must be able to handle anything that is thrown its way. The remedy for this situation is to use standardized document patterns that constrain the structure and content of SR objects, and improve the ability of receiver to meaningfully use the information. <>
DICOM solves this problem through the features of Supplement 53 adopted this past spring. It allows the specification of document structural patterns in templates, and context-sensitive constraints on allowed terms through what are known as &quot;context groups&quot;. This supplement further defines a basic set of templates for clinical context and a basic diagnostic imaging clinical report. <>
So theoretically, DICOM SR is ready to be implemented for use in cardiology. <> Except for a few pragmatic issues. <>
First, many of the use cases for cardiology are not well covered by the “clinical report” model, which was the initial focus of DICOM SR. In particular, although a procedure log has many similarities to a classical report, its fundamental time-oriented nature poses some issues. Measurements, especially when not verified, as for example a sonographer's preliminary echo data sheet, should possibly be managed in a class separate from the physician's final reports. <> Second, there are usually many ways to encode the same information. This is the problem addressed by SR templates and context groups, and a consistent approach needs to be established for good cross-vendor interoperability. <> Further, as I mentioned before, standardized structured reporting is technically challenging, and intimidating to the novice. And we are all novices in this new area. Each specialty needs a well-defined, tractable subset of SR to reduce the learning curve for those first application developers. <> What is still needed for practical implementation are cardiology-specific templates and terminology support by a broad consensus of the community. <>
As I mentioned, soon after the finalization of the XA DICOM Standard in 1996, Working Group 1 began discussions on report interchange. That effort is now finally coming to its first stage of fruition with Supplement 66, which includes templates for the five categories of cath lab related reports shown here. Working Group 12 simultaneously has been developing the SR template for the echo report, as well as other ultrasound reports such as OB/GYN and vascular. Both of these documents have been delayed as the base DICOM SR standard was hashed out through the standardization process, but now the way is clear for them to be released for formal public coment this autumn, and if all goes well, for final standard balloting in the spring.
To give you some idea of the decisions that need to be made in designing templates, let's look first at the Procedure log. <> The first decision was to make the log document a very flat structure - essentially a single layer of time stamped entries, thus emulating a classic hard copy log. <> Next we decided that the entries must be encoded in the document object in strictly time-ordered sequence, thus making presentation simpler. <> We had an issue with how to link entries together, for instance, to identify that a particular device was used for a particular sub-procedure. Here we decided to not use the SR relationship construct, but rather to allow the identification of a procedure step or action by a label, and apply that label to associated log entries of any type. <> These differences from the typical use of SR for clinical reports, as well as its use solely within the cardiology department, argued for assigning the Procedure Log a separate SOP Class. <> We also want multiple devices participating in the cath procedure to be able to contribute to the log, for example, the X-ray system should be able to create a log entry when it acquires an image run. We therefore defined a new Application Event Logging Service Class to enable distributed construction of the procedure log. <>
We had similar decisions to make on the Hemodynamics Report. <> We decided on a SOP Class to handle all cath lab measurement reports, since their domain of interchange, that is, the systems that need to handle them, will be basically the same for all types of measurements. <> In contrast to the procedure log, the hemo report is defined with a rather deep hierarchical structure. <> This structure allows the use of vocabulary which is post-coordinated, that is, built up from terms representing atomic concepts. Let's look at the report structure to see what that means. <>
The hemo report is first organized into containers by procedural phase, such as baseline, or post-intervention. The phase can have additional descriptors of the patient state in a subsidiary container. Each phase is further subdivided into classes of measurements, which are each qualified by a particular anatomic location where the measurements were taken. Finally within each of these containers we have the specific measurements. So, for instance, this diastolic pressure is qualified by the structure to indicate it is the baseline - left femoral artery - diastolic pressure. There are several obvious alternative ways to encode this same information, which is why having a consensus template is so very important.
DICOM Structured Reporting Current Status and Clinical Importance ...
DICOM Structured Reporting Current Status and Role in the Electronic Patient Record Harry Solomon Co-chair, DICOM WG1 - Cardiovascular Information
What is DICOM Structured Reporting? <ul><li>A means of encoding structured information … </li></ul><ul><ul><ul><li>hierarchical tree of content items, using DICOM object syntax </li></ul></ul></ul><ul><li>For vendor-independent exchange between systems … </li></ul><ul><ul><ul><li>leveraging the DICOM object management infrastructure </li></ul></ul></ul><ul><li>Providing unambiguous documentation of meaning … </li></ul><ul><ul><ul><li>text, categorical codes, numeric measurements, inter-item relationships </li></ul></ul></ul><ul><li>For the image-intensive clinical environment </li></ul><ul><ul><ul><li>careful attention to clinical observation context </li></ul></ul></ul><ul><ul><ul><li>robust references to DICOM images, waveforms </li></ul></ul></ul>
Structured Reporting is Not... <ul><li>DICOM SR is not just “reports” </li></ul><ul><ul><li>any structured data exchanged between systems </li></ul></ul><ul><ul><li>measurements, analyses, sonographer notes ... </li></ul></ul><ul><li>DICOM SR is not Structured Data Entry </li></ul><ul><ul><li>Hierarchical pull-down menus to support report creation is often denoted “structured reporting” </li></ul></ul><ul><ul><li>DICOM does not standardize applications or data entry techniques </li></ul></ul><ul><ul><li>Structured data entry is a valuable means of creating SR content in certain circumstances </li></ul></ul>
Where Can Cardiology Use SR? <ul><li>Clinical Reports (cath, echo, nuc, etc.) </li></ul><ul><ul><li>to go along with our pretty DICOM pictures </li></ul></ul><ul><li>Analyses of raw image and waveform data </li></ul><ul><ul><li>backing up the Clinical Report </li></ul></ul><ul><li>Documentation of the procedure </li></ul><ul><ul><li>provide context for the raw data and analyses </li></ul></ul><ul><li>Input to a clinical database </li></ul><ul><ul><li>for patient care over time, or outcomes analysis </li></ul></ul>
Cath Lab Example Hemo Report Baseline Ref waveform Measurements … Post-intervention Ref waveform Measurements … Derived measurements Ref waveform Procedure Log 11:10 Patient prepped Cath Lab Report Patient 67 yr old male, history of … Ref prior ECG report Procedure Ref Log Narrative ... Findings Hemodynamic Ref HD Report Narrative ... Angiographic 70% stenosis ... Ref image Intervention Stent placed in LAD … Ref image Complications Summary Procedure Log 11:10 Patient prepped 11:19 Percutaneous entry 11:23 XA image acquired Procedure Log 11:10 Patient prepped 11:19 Percutaneous entry 11:23 XA image acquired 11:27 HD waveform acquired Procedure Log 11:10 Patient prepped 11:19 Percutaneous entry 11:23 XA image acquired 11:27 HD waveform acquired 11:30 XA image acquired Procedure Log 11:10 Patient prepped 11:19 Percutaneous entry 11:23 XA image acquired 11:27 HD waveform acquired 11:30 XA image acquired 11:47 PTCA 11:59 XA image acquired Procedure Log 11:10 Patient prepped 11:19 Percutaneous entry 11:23 XA image acquired 11:27 HD waveform acquired 11:30 XA image acquired 11:47 PTCA 11:59 XA image acquired 12:02 HD waveform acquired Procedure Log 11:10 Patient prepped 11:19 Percutaneous entry 11:23 XA image acquired 11:27 HD waveform acquired 11:30 XA image acquired 11:47 PTCA 11:59 XA image acquired 12:02 HD waveform acquired 12:21 Pt released to holding 12:24 HD Report
Structured Reporting is the glue that makes possible construction of an electronic patient record for cardiology
DICOM SR Status <ul><li>Work began in 1994 </li></ul><ul><ul><li>Championed by Dr. Dean Bidgood </li></ul></ul><ul><li>Supplement 23: Structured Reporting - April 2000 </li></ul><ul><ul><li>Defined general format for SR objects </li></ul></ul><ul><ul><ul><li>DICOM header, hierarchical tree of content items </li></ul></ul></ul><ul><ul><ul><li>Concepts represented by coded terminology using external (non-DICOM) lexicons [e.g., Reed codes, SNOMED anatomy, ICD-9/10 diagnosis or procedure codes, SCP-ECG lead IDs] </li></ul></ul></ul><ul><ul><li>Defined general classes of clinical reports </li></ul></ul><ul><ul><li>Extremely flexible </li></ul></ul>
The Problem of Flexibility <ul><li>A document creator can put in anything in any structure </li></ul><ul><li>A document reader must handle every possible document </li></ul><ul><li>Need to constrain the SR content to enable meaningful receiving applications </li></ul><ul><ul><li>Structure </li></ul></ul><ul><ul><li>Content </li></ul></ul>
DICOM SR Status <ul><li>Supplement 53: Content Mapping Resource - May 2001 </li></ul><ul><ul><li>Defined general structure for templates : document patterns </li></ul></ul><ul><ul><li>Mechanism for terminology context groups : constrained vocabulary subsets </li></ul></ul><ul><ul><li>Fundamental templates for documenting clinical context and for basic reports </li></ul></ul><ul><ul><li>DICOM lexicon for vocabulary not externally available </li></ul></ul>
So Theoretically ... <ul><li>DICOM Structured Reporting is ready to be implemented for cardiology! </li></ul><ul><li>But Pragmatically … </li></ul>
Issues for Cardiology SR <ul><li>Uses not well covered by “clinical report” model </li></ul><ul><ul><li>Procedure logs, preliminary measurement reports </li></ul></ul><ul><li>Many ways to encode the same information </li></ul><ul><ul><li>Need consistent approach for interoperability </li></ul></ul><ul><li>Need tailored subset of SR for developers </li></ul><ul><ul><li>Reduce the learning curve </li></ul></ul>Need Cardiology-specific SR Templates and consensus Terminology
Cardiology SR Efforts <ul><li>Supplement 66: Cath Lab SR (WG1) </li></ul><ul><ul><li>Procedure Log </li></ul></ul><ul><ul><li>Hemodynamics Report </li></ul></ul><ul><ul><li>ECG Report </li></ul></ul><ul><ul><li>Quantitative Analysis Report </li></ul></ul><ul><ul><li>Cath Lab Report </li></ul></ul><ul><li>Supplement 26: Ultrasound SR (WG12) </li></ul><ul><ul><li>Echocardiography Report </li></ul></ul><ul><li>Both to be released for Public Comment this autumn </li></ul>
Procedure Log Issues <ul><li>Structure - flat </li></ul><ul><li>Ordering - strictly time sequential </li></ul><ul><li>Linkage of events - associative Procedure Step / Action ID </li></ul><ul><li>SOP Class - distinct from reports </li></ul><ul><li>Remote entries - new Application Event Logging Service Class </li></ul>
Hemodynamic Report Issues <ul><li>SOP Class - Cath Lab Measurements (together with QCA, QVA, IVUS measurements, etc.) </li></ul><ul><ul><li>Distinction from report titles </li></ul></ul><ul><li>Structure - deep hierarchy </li></ul><ul><li>Terminology - post-coordinated, context from hierarchy </li></ul>
Hemo Report Structure Hemo Report CONTAINER Baseline Phase CONTAINER Post-Contrast Phase CONTAINER Arterial Measurements CONTAINER Ventricular Measurements CONTAINER Gradient Measurements CONTAINER Anatomic Location = L Fem Art Patient State CONTAINER Patient State CONTAINER Systolic Pres Diastolic Pres Mean Pres Arterial Measurements CONTAINER Anatomic Location = Aorta Systolic Pres Diastolic Pres Mean Pres Post-Intervention Phase CONTAINER
Find out more <ul><li>http://www.pixelmed.com/srbook.html </li></ul><ul><ul><li>David Clunie’s excellent introduction to DICOM SR </li></ul></ul><ul><li>ftp://medical.nema.org/medical/dicom/supps </li></ul><ul><ul><li>text of draft supplements </li></ul></ul><ul><li>http://www.dicomwg12.org/structured_reporting </li></ul><ul><ul><li>echocardiography SR </li></ul></ul><ul><li>subscribe to WG1 email list </li></ul><ul><ul><li>send request to firstname.lastname@example.org </li></ul></ul>
Thank you Questions? mailto://email@example.com
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.