Web Services for DICOM
Version 0.0 Dave Harvey 8th July 2008
This is a discussion document to prompt thoughts about the content aspects of
the new services. It is deliberately neutral about the transport arrangements
(since this is not my area of expertise) – it simply assumes that a suitable
mechanism exists to accept a complex request and return multiple discrete result
items.
1. WADO (WADO 2?)
The new service should continue to support all the parameters defined by
WADO, including the options to return either native DICOM objects or a prerendered object (JPEG, PDF etc.) These are summarised as below:
requestType
contentType
studyUID
seriesUID
objectUID
charset
anonymize
annotation
Rows / columns
region
windowCenter/ windowWidth
imageQuality
presentationUID
presentationSeriesUID
transferSyntax
frameNumber
1.1.
Allowed for?
Both
Both
Both
Both
Both
Both
DICOM
Rendered
Rendered
Rendered
Rendered
Both
Rendered
Rendered
DICOM
Rendered
Mandatory in request?
Y
Y
Y
Y
Y
Proposed Enhancements:
Series/Study retrieval in a single request
A simple version would simply require that the objectUID and seriesUID would
become optional, allowing use of studyUID, studyUID + seriesUID or studyUID +
seriesUID + objectUID. However in order to clarify the intent, and to ease
validation, it is suggested that an explicit “level” parameter should be added, with
values corresponding to the DICOM levels – i.e. “STUDY”, “SERIES” or “IMAGE”
(or “INSTANCE” depending on how closely we wish to align with DICOM!)
This would be very straightforward for retrieval of DICOM instances (contentType
= application/dicom) as they would have all their original attributes, but it raises
several issues if rendered copies are retrieved. These issues are as follows:
Relationship between objects
The relationship between multiple objects (e.g. sort/display order) would
be unclear. Three different solutions to this problem could be:
a) Disallow multiple rendered images (not attractive, since it defeats
part of the intent of this work)
b) Define a “sortOrder” parameter requiring sorting by position, image
number etc. The weakness of this is that there would still be no
obvious breaks between series within a study and positional
information would still be missing (though it could possibly be
included via the annotation parameter)
c) Mandate that basic “ordering” information (slice location, image
number etc.) should be returned alongside each rendered image. If
the transport can handle multiple objects, then it should be able to
handle a suitable small XML object (or similar) to hold this
information for each image. It is open to debate how many of the
DICOM attributes should be included in this object.
Presentation state information
Another issue for multiple rendered objects is the presentation state
information, which may or may not apply to a whole series/study, making
the existing presentationUID & presentationSeriesUID inadequate. There
are multiple possible solutions:
a) Disallow the presentation state definition for levels other than
IMAGE/INSTANCE
b) Only allow if one object can be used for the whole retrieval block (a
presentation can and commonly does contain such information, but
there are limitations for some attributes which restrict the
usefulness of this option)
c) Only allow via use of the KON/SR option define below.
Rendered type (contentType)
If a study contains multiple series with different object types (images,
reports, etc.), then the current “contentType” would need to be modified to
allow different types for different classes of object – perhaps via a
mapping list (including perhaps a “don’t send” mapping for objects not
required by the client)
An open issue is whether the request should allow multiple distinct
objects/series/studies to be retrieved in the same request (e.g. 2 out of 5 series
in a study, without pulling the whole study)
Frame Ranges & “Cine”
A new supplement is currently passing through the DICOM approvals process to
allow selection of individual frames or frame ranges from multi-frame images and
it would be sensible to provide similar capabilities in this service via a matching
set of attributes, allowing selection by:
a) list of frames
b) calculated ranges (for a to b step c)
c) Approximate time (for MPEG etc.)
It would also be useful to provide a better mechanism for the provision of multiframe images in rendered form (existing WADO specifies support for multi-frame
GIF, due to lack of anything better at the time!)
KOS/SR Based
The question above relating to presentation states (and also frame selection)
could be greatly simplified if we include a specific mechanism to relate
presentation states and frame numbers to a selection of images. Such a
mechanism does exist in DICOM – the “Current Requested Procedure
Evidence Sequence” in Structured reports and KOS objects. Specifying the
images to retrieve this way (to come back as either DICOM objects or rendered)
gives a lot of flexibility, contributes significantly to likely use cases (such as XDSI) and should be relatively easy to specify and implement. An open question is
whether the SR/KOS would be expected to reside on the server (specified by its
UIDs) or whether the transport mechanisms would allow the KOS (typically a few
kBytes) to be included in the retrieval request.
2. QIDO – Querying
There is a strong argument for mapping the query as closely as possible to the
DICOM query mechanisms, bearing in mind that patient demographics should
not be required in an EHR environment. The mechanisms used could then map
directly to a DICOM C-FIND, with parameters in an XML “query” matching those
used in a DICOM identifier, and similarly structured responses. As in DICOM,
there would need to be a queryLevel parameter (STUDY/SERIES/IMAGE) with
other fields depending on that. Here are suggested fields for those levels:
2.1.
STUDY
This table is based on the Patient Root Study Level table from DICOM Part 4,
with Patient ID and Patient Name added. An alternative would be to use the
Study Root Study Level table, which include more patient attributes, but do we
wish to include those?
Description
DICOM Tag
Patient ID
(0010,0010)
Suggested
Web Service
requirement
Y
Patient Name
(0010,0020)
Y
Study Date
(0008,0020)
R
Y
Study Time
(0008,0030)
R
Y
Accession Number
(0008,0050)
R
Y (1)
Study ID
(0020,0010)
R
Y
Study Instance UID
(0020,000D)
U
Y
Modalities in Study
(0008,0061)
O
Y(2)
SOP Classes in Study
(0008,0062)
O
Y
Referring Physician’s Name
(0008,0090)
O
Y
Study Description
(0008,1030)
O
Y
Procedure Code Sequence
(0008,1032)
O
>Code Value
(0008,0100)
O
>Coding Scheme Designator
(0008,0102)
O
>Coding Scheme Version
(0008,0103)
O
>Code Meaning
(0008,0104)
O
Name of Physician(s) Reading Study
(0008,1060)
O
Admitting Diagnoses Description
(0008,1080)
O
Referenced Study Sequence
(0008,1110)
O
>Referenced SOP Class UID
(0008,1150)
O
>Referenced SOP Instance UID
(0008,1155)
O
Issuer of Patient ID
(0010,0021)
O
Patient’s Age
(0010,1010)
O
Patient’s Size
(0010,1020)
O
Patient’s Weight
(0010,1030)
O
Occupation
(0010,2180)
O
Additional Patient History
(0010,21B0)
O
Other Study Numbers
(0020,1070)
O
Number of Study Related Series
(0020,1206)
O
Y
Number of Study Related Instances
(0020,1208)
O
Y
All other Attributes at Study Level
DICOM
Type
O
Y
Notes:
1) For the benefit of those from other fields, it is worth pointing out that
Accession Number (though often abused!) is NOT a unique field,
especially in a cross-PACS/cross-RIS environment. It is only a short
human-readable proxy for the order filler/placer number and as such can
be used as a query field, but not a unique key.
2) In DICOM modality is a SERIES level attribute, so this field is vital for
doing top level searches by modality – e.g. find me all studies containing
CT for this patient.
2.2.
SERIES
This table is based on the Patient Root Series Level table from DICOM Part 4,
with Series Description Added.
Description
Tag
Type
Modality
(0008,0060)
R
Suggested
Web Service
requirement
Y
Series Number
(0020,0011)
R
Y
Series Instance UID
(0020,000E)
U
Y
Number of Series Related
Instances
(0020,1209)
O
Y
Series Description
(0008,103E)
All Other Attributes at Series Level
2.3.
Y
O
IMAGE/INSTANCE
This table is based on the Patient Root Instance Level table from DICOM Part 4.
Description
Tag
Type
Instance Number
(0020,0013)
R
Suggested
Web Service
requirement
Y
SOP Instance UID
(0008,0018)
U
Y
SOP Class UID
(0008,0016)
O
Y
Alternate Representation
Sequence
(0008,3001)
O
>Series Instance UID
(0020,000E)
O
>SOP Class UID
(0008,1150)
O
>SOP Instance UID
(0008,1155)
O
>Purpose of Reference Code
Sequence
(0040,A170)
O
>>Code Value
(0008,0100)
O
>>Coding Scheme Designator
(0008,0102)
O
>>Coding Scheme Version
(0008,0103)
O
>>Code Meaning
(0008,0104)
O
Related General SOP Class UID
(0008,001A)
O
Concept Name Code Sequence
(0040,A043)
O
>Code Value
(0008,0100)
O
>Coding Scheme Designator
(0008,0102)
O
>Coding Scheme Version
(0008,0103)
O
>Code Meaning
(0008,0104)
O
Content Template Sequence
(0040,A504)
O
>Template Identifier
(0040,DB00)
O
>Mapping Resource
(0008,0105)
O
All Other Attributes at composite
object instance Level
O
3. NADO
A fundamental decision for NADO is whether it should attempt to convey the
details of the objects available (e.g. a list of SOP instances) or merely to
convey a basic notification that something has changed, leaving the client to
query for information of interest. This service could rapidly get very
complicated if allowed to get complex, so here (as a starting point only) is a
suggestion on how it could operate in a simple manner.
1) It would operate only at the study level, informing the client that
something has changed in a particular study’s content.
2) The client would “subscribe” by sending a request modelled on the QIDO
Study level query above – perhaps specifying a Referring Physician’s
Name as a key, other another filter of its choosing, requesting that it be
notified about additions to any studies which “match” that query.
3) The notification sent would only say that something had been added and
was now available. It would not imply any “closure” or “completeness” of
the study.
4) There probably should be a mechanism to allow the server to delay
sending a notification for a while to avoid sending multiple messages (in
practice, this would normally allow just one notification per study, whilst
not precluding another message if/when later additions such as reformats,
presentation states etc. are added)