1. Harry Solomon Co-chair, DICOM WG1 - Cardiovascular Information
DICOM Structured Reporting Current Status and Role in the Electronic Patient Record
Harry Solomon
Co-chair, DICOM WG1 - Cardiovascular Information
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. <>
Solomon, DICOM SR European Society of Cardiology 2 September 2001

2. What is DICOM Structured Reporting?
A means of encoding structured information …
hierarchical tree of content items, using DICOM object syntax
For vendor-independent exchange between systems …
leveraging the DICOM object management infrastructure
Providing unambiguous documentation of meaning …
text, categorical codes, numeric measurements, inter-item relationships
For the image-intensive clinical environment
careful attention to clinical observation context
robust references to DICOM images, waveforms
So what is DICOM Structured Reporting? Or, as it is commonly called, "SR." <> 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. <>
Solomon, DICOM SR European Society of Cardiology 2 September 2001

3. Structured Reporting is Not...
DICOM SR is not just “reports”
any structured data exchanged between systems
measurements, analyses, sonographer notes ...
DICOM SR is not Structured Data Entry
Hierarchical pull-down menus to support report creation is often denoted “structured reporting”
DICOM does not standardize applications or data entry techniques
Structured data entry is a valuable means of creating SR content in certain circumstances
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. <>
Solomon, DICOM SR European Society of Cardiology 2 September 2001

4. Where Can Cardiology Use SR?
Clinical Reports (cath, echo, nuc, etc.)
to go along with our pretty DICOM pictures
Analyses of raw image and waveform data
backing up the Clinical Report
Documentation of the procedure
provide context for the raw data and analyses
Input to a clinical database
for patient care over time, or outcomes analysis
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. <>
Solomon, DICOM SR European Society of Cardiology 2 September 2001

5. Cath Lab Example Procedure Log Procedure Log 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
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
Procedure Log
11:10 Patient prepped
11:19 Percutaneous entry
11:23 XA image acquired
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
Angiographic
70% stenosis ...
Ref image
Intervention
Stent placed in LAD …
Complications
Summary
[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, <>
Hemo Report
Baseline
Ref waveform
Measurements …
Post-intervention
Derived measurements

6. Structured Reporting is the glue that makes possible construction of an electronic patient record for cardiology
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?
Solomon, DICOM SR European Society of Cardiology 2 September 2001

7. DICOM SR Status Work began in 1994
Championed by Dr. Dean Bidgood
Supplement 23: Structured Reporting - April 2000
Defined general format for SR objects
DICOM header, hierarchical tree of content items
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]
Defined general classes of clinical reports
Extremely flexible
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 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. <>
Solomon, DICOM SR European Society of Cardiology 2 September 2001

8. The Problem of Flexibility
A document creator can put in anything in any structure
A document reader must handle every possible document
Need to constrain the SR content to enable meaningful receiving applications
Structure
Content
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. <>
Solomon, DICOM SR European Society of Cardiology 2 September 2001

9. DICOM SR Status Supplement 53: Content Mapping Resource - May 2001
Defined general structure for templates: document patterns
Mechanism for terminology context groups: constrained vocabulary subsets
Fundamental templates for documenting clinical context and for basic reports
DICOM lexicon for vocabulary not externally available
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 "context groups". This supplement further defines a basic set of templates for clinical context and a basic diagnostic imaging clinical report. <>
Solomon, DICOM SR European Society of Cardiology 2 September 2001

10. So Theoretically ... But Pragmatically …
DICOM Structured Reporting is ready to be implemented for cardiology!
But Pragmatically …
So theoretically, DICOM SR is ready to be implemented for use in cardiology. <> Except for a few pragmatic issues. <>
Solomon, DICOM SR European Society of Cardiology 2 September 2001

11. Issues for Cardiology SR
Uses not well covered by “clinical report” model
Procedure logs, preliminary measurement reports
Many ways to encode the same information
Need consistent approach for interoperability
Need tailored subset of SR for developers
Reduce the learning curve
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. <>
Need Cardiology-specific SR Templates and consensus Terminology
Solomon, DICOM SR European Society of Cardiology 2 September 2001

12. Cardiology SR Efforts Supplement 66: Cath Lab SR (WG1)
Procedure Log
Hemodynamics Report
ECG Report
Quantitative Analysis Report
Cath Lab Report
Supplement 26: Ultrasound SR (WG12)
Echocardiography Report
Both to be released for Public Comment this autumn
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.
Solomon, DICOM SR European Society of Cardiology 2 September 2001

13. Procedure Log Issues Structure - flat
Ordering - strictly time sequential
Linkage of events - associative Procedure Step / Action ID
SOP Class - distinct from reports
Remote entries - new Application Event Logging Service Class
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. <>
Solomon, DICOM SR European Society of Cardiology 2 September 2001

14. Hemodynamic Report Issues
SOP Class - Cath Lab Measurements (together with QCA, QVA, IVUS measurements, etc.)
Distinction from report titles
Structure - deep hierarchy
Terminology - post-coordinated, context from hierarchy
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. <>
Solomon, DICOM SR European Society of Cardiology 2 September 2001

15. Hemo Report Structure
Hemo Report
CONTAINER
Baseline Phase
Post-Contrast Phase
Arterial Measurements
Ventricular Measurements
Gradient Measurements
Anatomic
Location =
L Fem Art
Patient State
Systolic Pres
Diastolic Pres
Mean Pres
Aorta
Post-Intervention Phase
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.

16. Find out more http://www.pixelmed.com/srbook.html
David Clunie’s excellent introduction to DICOM SR
ftp://medical.nema.org/medical/dicom/supps
text of draft supplements
echocardiography SR
subscribe to WG1 list
send request to
Solomon, DICOM SR European Society of Cardiology 2 September 2001

17. Questions? mailto://harry.solomon@med.ge.com
Thank you
Questions?
Solomon, DICOM SR European Society of Cardiology 2 September 2001