Download radiologist-clinician.v1.0 - Dicom

Collaboration between the Referring Clinician and the Radiologist
Emmanuel Cordonnier, ETIAM
V1.0
April 3, 2004
Introduction
This notes intends to propose some evolutions of the DICOM Standards in order to enhance
the collaboration between the referring clinician and the radiologist.
Focussed on the most current case where a diagnosis service is demanded by a clinician (GP,
PCP, specialist in hospital or ambulatory medicine), to be performed by a radiologist, it has to
be extended in a second time to covers the cases of therapy service (interventional radiology)
in the one hand, and when the "image based" act is performed by a other specialist (e.g.
cardiologist, gynecologist, surgeon, ophthalmologist, pathologist…).
Because the note is in its preliminary draft version, it is largely incomplete and richer on the
question side than on the solution one.
Context
The 10/20 first years of DICOM/ACR-NEMA have been concentrated on solving the
communication and digital imaging issues inside the radiology "world", or more generally
saying inside the "speciality imaging world". Even in permanent evolution (standards are
"living bodies"), it can be said however that DICOM is a significantly mature standard on the
radiologist point of view.
This opens possibility to apply efforts now to enhance the standards from the "partner" point
of view (some would say "client", others would say – or think - "user") in a longer perspective
than a "one shot" collaboration (e.g. in some situations where the radiologist is not
responsible of archiving the images, the patient, referred by the clinician will provide to the
radiologist the previous examination data which can be required for a good quality diagnosis).
The two other conditions which motivate focussing on the relation between referring clinician
and radiologist are the following:
 gradually the referring clinician is more and more able to manage digital data (know
using the same computers than the radiologist – less powerful but fully compatible;
more frequently equipped with dedicated information systems), and
 the communication channels between both are more and more available, powerful and
cheap (LAN, Internet including security, CD/DVD carried by the patient).
Workflow
As the Departmental Workflow IHE White Paper (IHE_TF_White_Paper_Dept_Workflow_v1.0_PC.pdf )
is describing in its Chapter 6 (Departmental Workflow - External View),
"an Imaging or Radiology Department provides a number of services to the enterprise or practice it
supports.
These services fall into two types of services:
 Diagnostic Services
 Imaging Information Access Services (Reports & Images)
In addition, a Radiology Department may need, from the enterprise, a number of services to support
its operation such as the Admission, Discharge, Transfer (ADT) Services that provide patient
identification and demographics.
The Diagnostic Services provide a diagnostic report from the Radiology Department to the Enterprise,
most often in response to an Order issued by the Enterprise.
582723227
Clinician-Radiologist Collaboration
1
The Imaging Information Access Services provide, to care areas, access to reports and associated
images for their operation. For example, neurosurgery or oncology needs to retrieve images for their
therapy planning activities.
The Admission, Discharge, Transfer (ADT) Services notify the Radiology Department of all patients
registered, their identifiers and associated demographic information. This will avoid re-entering this
information for patients that are examined by the Radiology Department as well as improving the
accuracy, reliability and timeliness of the demographic information as it passes through the
department."
The Diagnostic service workflow can be summarized by its inputs:
 The patient
 The order (including identification of the patient as well as medical precision on the
demand – organ, pathology suspected…)
 Optionally the complementary information, necessary or at least useful for the diagnosis
And its outputs:
 The patient (best case ;-)
 The report containing (or referencing) the most significant images
 Optionally the examination data (mainly original images)
The fact that the patient is considered as a part of the workflow is absolutely not a artifacts:
 The patient shall be present for the first step of the diagnosis act (examination) is
performed, generally not for the second step (interpretation and reporting). That is not
exactly the case for the other "image based" acts (surgery or pathology specialties). So
the first step shall be synchronized with the physical presence of the patient.
 The patient can be considered as a "communication channel", at least for the inputs and
for conveying the images (the report is often after she/he has left the radiology
department/office). The actual boom of the distribution of images on CD is highlighting
this assessment.
 The patient is more and more often the decision maker for choosing the professional the
perform the acts as well as defining the access rights on her/his personal healthcare
information, as it is increasingly stated officially in many countries. In many cases the
patient has the possibility to choose the radiologist (very often only "theoretical" but
applicable however), even if a clinician (GP, PCP…) must be seen before to see the
radiologist. So the clinician is generally not knowing which radiologist will perform the
diagnosis. For the relation between the radiologist and the clinician it is generally the
opposite, well described in the expression "referring clinician".
A complementary aspect of the radiology specialty specificity has be taken into account. The
diagnosis service is always a "secondary stream", and the "main stream" is managed by the
clinician. But the rear case in which the radiology department/office is totally depending of an
unique clinical organization (e.g. cancer center), it is generally "serving" different "peer"
organization, each one having its own constraints, practice and "descriptive" data (e.g.
Domain ID). So radiologists have to be able to manage "multi-partner" context, depending of
the referring clinician, who is not necessarily in the same organization.
Actual limitation of DICOM
DICOM is not in charge of analyzing use case workflow (covered by IHE). However it shall
enable the workflow that happens in the real world to be run. The description of the workflow
specificity above is revealing some weak or totally missing points in DICOM detailed below,
for defining potential new work items to be discussed in the WG10.
582723227
Clinician-Radiologist Collaboration
2
Order / prescription
The ordering process and associated messages are been clearly "managed" by HL7, as the
IHE Radiology SWF Integration Profile is stating. However the specific radiology
information that are described by the referring clinician for "driving" the diagnosis service
have to be taken into account at least for the interpretation and sometimes for the acquisition
itself. The work done in Japan around the JJ17xx directives has opened new perspective in
this direction. If it is considered that the interpretation / reporting is performed by the
radiologist on the DICOM equipment, this "ordering medical information" has to be managed
by DICOM standards. CPOE ("electronic connected prescription") are now emerging, and it
can be thought to a "DICOM SP" (DICOM Structured Prescription"), which can be directly
derived from the DICOM SR, which has to contain also this prescription into its initial
section. Contrary of the DICOM SR, a mapping from HL7 has to be defined even in the first
definition of the new IOD (if it is a pertinent idea only).
Report
DICOM SR is the best way for managing reporting information and process inside radiology.
From an external point of view its statute is quite "balanced" between a "classical medical
report" (well covered by CDA, especially release two), and an "extension of the imaging
objects". In any case, if the paper aims to be replaced by electronic communication, the
"stable presentation" possibility has to be managed. Presently there is neither "presentation
state" for SR, nor clear mapping to CDA (which has no clear presentation state but it shall be
solved by HL7 body).
On the communication side, there is not really a "push" message that enables the radiologist
to send the report to the clinician. A better combination of DICOM Store and Instance
Availability Notification (sup. XXX) can help. See further developments on the next chapter.
Significant images
The clinician is asking mainly for a report but needs very often to see the significant images,
not necessary to re-interpret them, but to better understand the diagnosis and potentially
prepare the following steps. DICOM has all the necessary objects covering this significant
images issue (SR, KIN, GSPS…). However the lack of use of such possibilities by the
products is certainly revealing some limitation inside the standard, at least on the "explanation
side". Number of images within an examination are increasing rapidly, as well as the number
of examination a radiologist is interpreting per day, making the selection a big challenge for
the collaboration between clinician (who does not want to waste time in searching the
significant images in a set of thousands) and the radiologist (who wants to avoid a boring
complicated and time consuming "selection of images"). Because films are now more and
more replacing by CD for communication the images to the patient, the significant images are
however printed on paper to complete the report (paper version). The is an "implied" selection
of images. There is no way into DICOM to make this relation (Print and KOS).
The CD general profile fits well the transmission of such information on a media, but it could
be "refined" but complementary information making possible an easier exploitation of the
information by the recipient. Probably this work is done within IHE (Media Distribution
Profile – which is actually in the "renaming" process).
For network communication, if the significant images are to be sent in a "one shot" operation
to the referring physician, there is no way to sent this "package" to him. The KOS are
certainly the best object to start with but the referring physician has then to retrieve individual
objects. Exploiting DICOM MIME type imbedded into an e-mail is another solution, but it is
probably necessary to used also this kind of "push" channel to send also reference to objects,
582723227
Clinician-Radiologist Collaboration
3
either by sending KOS in DICOM MIME, or by sending parameters enabling the referring
physician to retrieve the object through WADO.
Access to images and reports
Nobody knows how far WADO "clients" will be implemented in the information systems
used by referring clinicians, but the success of the IHE RID profile seams to anticipate some
future for WADO, which enables the client to retrieve DICOM objects both in DICOM and
non-DICOM (jpeg, mpeg for images, html, pdf or xml for documents).
Because DICOM viewers are more and more largely available, also through CD containing
images, manipulate DICOM objects is accessible to referring clinician. But DICOM protocol,
implying negotiation, preliminary configuration (host, IE Title), and IP fixed address (more or
less but it is still an issue) seam to be non a realistic way for accessing the images from non
imaging equipment.
Extension of the WADO have to be done, on different axes:
 "Set of objects" retrieval (example a series or a KOS referring a list of images);
 "Left part" of the URI (using Namespaces for solving the problem "transposition" of the
references between different contexts);
 Refining the access to only a part of the DICOM object, either a set of Tags for
example, or a part of the image or the sequence (beyond the single frame number).
And more a mechanism for Querying the DICOM objects using web technologies has to be
developed, probably in conjunction with use of such mechanisms outside of the medical
imaging (HL7…).
These works on the "access to images and reports" item, the evolution of the "terminal" need
to be taken into account, including PDA and other mobile equipment.
Multi-domain patient identification
Because radiologists are collaborating with different referring clinicians who can belong to
different organizations ("enterprises"), it is necessary they help their partners to maintain a
continuity of the medical data by at least supporting (not to say managing) patient Ids from in
different domains. The CPxx has addressed partially this point by adding a complementary
field to the PatientID one, but further analysis is probably necessary to see how far the
existence of multi-domain communication can impact DICOM (in relation with the IHE ITI
PIX Profile for example).
This multi-domain issue is of course true for the output of the radiology service (reports,
images communicated to the referring clinician) but also far complementary information
coming to the radiologist for enhancing the report (lab results, previous radiology exams…),
including the import of previous examinations stored on CD.
Collaboration on DICOM objects
Probably in a second step when DICOM objects are used by clinicians, it must be thought to
the interactive collaboration (CSCW) between a radiologist and a clinician who calls and ask
for further "explanation" on images, with interactive display / layout and overlays. The work
done on hang up protocol can be probably a good basis for such work but the goal here is not
to optimize the reporting workflow but the enable an interactivity between professionals.
________________________
582723227
Clinician-Radiologist Collaboration
4