5
Digital Imaging and Communications in Medicine (DICOM)
Supplement 93: Instance Availability Notification
10
15
VERSION: Final Text, June 15, 200420
Prepared by:
DICOM Standards Committee, Working Group 6
1300 N. 17
th
Street, Suite 1847
Rosslyn, Virginia 22209 USA
25
This is a draft document. Do not circulate, quote, or reproduce it except with the approval of
NEMA
Please send comments to Howard Clark, NEMA (
)
Supplement 93: Instance Availability Notification
Page 2
Table of Contents
Foreword ...........................................................................................................................................330
Introduction........................................................................................................................................4
I.1 SCOPE AND FIELD OF APPLICATION..............................................................................4
I.1.1 Limitations Of Current Standard...................................................................................4
I.1.2 Assumptions..............................................................................................................4
I.2 USE CASES ....................................................................................................................535
I.2.1 Radiology Modality Workflow Management Use Case....................................................5
I.2.2 Studies resulting from Unscheduled or Misidentified Radiology Acquisitions Use
Case 5
I.2.3 Studies resulting from External Acquisitions.................................................................6
I.2.4 Pre-fetching, Archival or Transfer of Studies Use Cases ................................................740
I.2.5 Instance Availability Notification Destinations and Failure Modes ....................................7
I.2.7 Other Uses.................................................................................................................7
Changes to NEMA Standards Publication PS 3.3-2003.........................................................................8
B.XX INSTANCE AVAILABILITY NOTIFICATION INFORMATION OBJECT DEFINITION .................9
B.XX.1 IOD Description ..........................................................................................................945
B.XX.2 IOD Modules ..............................................................................................................9
C.4.XX Instance Availability Notification Module........................................................................9
Changes to NEMA Standards Publication PS 3.4-2003.......................................................................12
Annex X INSTANCE AVAILABILITY NOTIFICATION SERVICE CLASS (Normative) ..........................13
X.1 OVERVIEW....................................................................................................................1350
X.1.1 Scope......................................................................................................................13
X.2 CONFORMANCE OVERVIEW.........................................................................................13
X.3 INSTANCE AVAILABILITY NOTIFICATION SOP CLASS ...................................................14
X.3.1 DIMSE Service Group ...............................................................................................14
X.3.2 Operations...............................................................................................................1455
X.3.3 Instance Availability Notification SOP Class UID...........................................................16
X.3.4 Conformance Requirements .....................................................................................16
Changes to NEMA Standards Publication PS 3.6-2003.......................................................................17
Changes to NEMA Standards Publication PS 3.16-2003.....................................................................19
CID 9231 General Purpose Workitem Definition...................................................................2060
Supplement 93: Instance Availability Notification
Page 3
Foreword
This supplement to the DICOM standard introduces a Service Class to provide availability
notification about composite instances.
This document is a Supplement to the DICOM Standard. It is an extension to the following parts of65
the published DICOM Standard:
PS 3.3 - Information Object Definitions
PS 3.4 - Service Class Definitions
PS 3.6 - Data Dictionary
PS 3.16 - Content Mapping Resource70
Supplement 93: Instance Availability Notification
Page 4
Introduction - will not appear in final standard
Introduction
I.1 SCOPE AND FIELD OF APPLICATION75
The proposed Instance Availability Notification Service Class proposed in this supplement
addresses the need in an integrated workflow environment to track availability of images (and
other evidence) for post-processing and diagnostic interpretation workflows.
In an integrated environment, workflow-management systems need to know when images and
other evidence are available as a result of acquisitions or other steps, (e.g., have been80
successfully transferred from the acquisition devices to the storage systems).
Knowledge of “availability” is required before subsequent steps (that need to be completed to
fulfill a requested procedure) can be scheduled or performed. The knowledge of instance
availability is required to properly govern the formation of worklists for subsequent workflow steps.
The scope of instances about which availability information is required is not restricted to just85
images; knowledge about availability of other evidence, such as Presentation States, Structured
Reports, and Key Object Selection Documents, which may be produced in the course of an
imaging procedure, is also required.
Knowledge of image availability is not limited to instances that first enter the system after
acquisition (generation). It continues to be important for images that remain in the system, or90
those that have been removed from it, or those that return to it through pre-fetching.
I.1.1 Limitations Of Current Standard
Currently, the only way for the workflow-management systems to determine the image availability
is by performing a query (C-FIND) of the archive. This “polling” approach is unwieldy, particularly
when instances are not immediately available on an archive even though a PPS has been flagged95
as completed. Decisions as to when, and how frequently, to query, are difficult to make. Frequent
queries add an unnecessary burden to the archive.
Basic Study Content Notification is not appropriate because the normative semantics do not
match the proposed use-cases.
I.1.2 Assumptions100
It is assumed by this service that identification of what instances are available by UIDs at the
Instance, Series, Procedure Step and Study level is sufficient. Contextual information (such as
which Study Instance UID is associated with which patient or request) is outside the scope of this
service; it is expected that such information will be conveyed to the workflow-manager, for
example, by PPS services.105
Even in the case where an acquisition device does not directly support MPPS, other devices and
services are expected to convey contextual information to the workflow manager (such as creation
of a PPS by some other proxy device or internally in the archive or PACS).
The intent is to avoid overloading the semantics of the Instance Availability Notification with
anything other than availability notification, and particularly to avoid semantics related to study or110
procedure step change management or completeness notification.
Supplement 93: Instance Availability Notification
Page 5
I.2 USE CASES
The use cases for instance availability notification are based on the radiological digital imaging,
however, they may be extended to other environments, such as cardiology, radiotherapy,
ophthalmology, etc.115
It is common in today’s radiology department to have studies planned and tracked by the workflow
management systems (e.g. RIS or PACS), and to be concerned with the issues such as staff load,
productivity, efficiency, equipment utilization, report turn-around time, proper identification of
procedures performed. The list of use cases identified below is not intended to identify all cases
where this instance availability notification may be used, nor to recommend any one of them. The120
Instance Availability Notification SOP Class will facilitate the support of each one of these use
cases, although a number of other existing supporting services may also needed.
I.2.1 Radiology Modality Workflow Management Use Case
In this use case, the RIS closely monitors and actively manages the workload of interpreting
radiologists by building lists of procedures to be interpreted. Content of such lists change125
dynamically based on such factors as average radiologist load, subspecialty, radiologist availability,
and others.
The following is a typical sequence of events:
• Images and other DICOM instances are acquired or created on the modality.
• If so equipped, the modality uses MPPS to provide information to the RIS or the PACS130
(or both) about the results of the acquisition.
• When instances arrive at the PACS location from which they might be accessed for
interpretation purposes, the PACS notifies the RIS about the availability of the instances.
• If MPPS information is available to the PACS, the notification may be issued when all
instances comprising a single MPPS have arrived and are available at the PACS.135
• If association of the instances with an MPPS is not possible, the timing of notification
of those instances that are available is at the discretion of the PACS.
• The RIS uses the MPPS information received, and the availability status and location of
instances, to build a worklist of requested procedures to be interpreted and generates
General Purpose Scheduled Procedure Steps (including the references of instances140
included in the availability notification). The RIS should not depend on the timing and
sequencing of the IAN and PPS notifications, which are not specified.
I.2.2 Studies resulting from Unscheduled or Misidentified Radiology
Acquisitions Use Case
Instances are acquired by the modality when the information about the patient identity is not145
available and/or the examination performed is not yet being tracked by the RIS or PACS.
Such a situation may occur when patient is a trauma victim, or when the modality is not capable of
obtaining proper identification through the Modality Worklist Service; in either case identification
has to be entered manually by the modality operator.
To properly include such an examination into the departmental workflow, a RIS may need to track150
the existence of instances and associate them with corresponding patient and procedure
identifiers.
Supplement 93: Instance Availability Notification
Page 6
The following is a typical sequence of events:
• Images and other DICOM instances are acquired or created on the modality.
• If so equipped, the modality uses MPPS to provide information to the RIS or the PACS155
(or both) about the results of the acquisition.
• When instances arrive at the PACS location from which they might be accessed for
interpretation purposes, the PACS notifies the RIS about the availability of the instances.
• If MPPS information is available to the PACS, the notification may be issued when all
instances comprising a single MPPS have arrived and are available at the PACS.160
• If association of the instances with an MPPS is not possible, the timing of notification
of those instances that are available is at the discretion of the PACS.
• The RIS has received procedure information (including patient and study information) via
an MPPS, whether it be from the modality or the PACS. This allows the RIS to recognize
that the study has been misidentified. The RIS should not depend on the timing and165
sequencing of the IAN and PPS notifications, which are not specified.
• The RIS performs resolution of the exception, either by an automated procedure or by
manual intervention.
• The RIS uses MPPS information, availability status and location of instances to build a
worklist of requested procedures to be interpreted and generates General Purpose170
Scheduled Procedure Steps (including the references of instances included in the
availability notification).
I.2.3 Studies resulting from External Acquisitions
Images are initially acquired outside of the institution where they are to be used, and thus contain
patient and study identification that are unknown to the local RIS and PACS. To include these175
images into the workflow (for example, for comparison purposes), they need to be associated with
a locally identified patient.
The following is a typical sequence of events:
• Images and other DICOM instances are imported locally (e.g., from interchange media)
and assigned local patient identifiers. How such local patient information is obtained is180
outside the scope of this service.
• The imported instances are transmitted to PACS, after having been coerced to include
the local patient identifiers replacing the external patient identifiers, both to avoid
identifier collision and to use a single identifier for all of that patient’s studies.
• When the imported set of instances are available on the PACS from which they might be185
accessed for interpretation purposes, the PACS notifies the RIS about the availability of
the instances and communicates the key attributes of the study as recorded in the
instances, using a GP-PPS or MPPS. The RIS should not depend on the timing and
sequencing of the IAN and PPS notifications, which are not specified.
• The RIS uses MPPS information, availability status and location of instances to build a190
worklist of requested procedures to be interpreted and generates General Purpose
Scheduled Procedure Steps (including the references of instances included in the
availability notification).
Supplement 93: Instance Availability Notification
Page 7
I.2.4 Pre-fetching, Archival or Transfer of Studies Use Cases
A number of PACS do not keep all instances on-line (i.e. immediately available for retrieval) or at195
the same location. A PACS may change the storage level or archive location over time. A RIS or
another PACS may need to track availability of instances in these configurations.
The following is the sequence of events:
• Images and other DICOM instances are available on a PACS on-line. The PACS decides
to move a set of instances to near-line or off-line storage or to another location. The200
instances are no longer available at the original storage level or location, hence
notifications of “non-availability”, or availability at a new location, are sent.
• At a later time, some of these instances are brought back on-line because a new
requested procedure has been scheduled for that patient. The PACS would issue
instance availability notifications stating the location where these instances are now205
available.
The triggers initiating the instance movements are beyond the scope of this SOP Class.
I.2.5 Instance Availability Notification Destinations and Failure Modes
In all these use cases, the Instance Availability Notification SOP Class SCU needs to be
configured (manually or through the configuration management service) with the AE Title of the210
SCP(s) to be notified. There is no intent to provide for registration of interest by an SCP in all
notifications, or a subset of notifications related to specific Studies or PPS.
The retry policies and behavior in cases where notification may have been lost (such as
because an SCP was unavailable for a period of time) are also beyond the scope of this
Service Class. It is expected that an SCP “waiting” for a notification that never comes, or was215
lost, will perform a query after an appropriate interval.
I.2.7 Other Uses
Instance Availability Notification could also be used on workstation, quality control stations or post-
processing systems. One can envision double-read scenarios where a second interpretation
workstation retrieves a reading worklist from the RIS and as such it knows that the images can be220
accessed on the other workstation that has issued the notification.
Supplement 93: Instance Availability Notification
Page 8
225
Changes to NEMA Standards Publication PS 3.3-2003230
Digital Imaging and Communications in Medicine (DICOM)
Part 3: Information Object Definitions
Supplement 93: Instance Availability Notification
Page 9
Item #1 Add to Part 3, Section B (Normalized IODs) the following IOD:
235
B.XX INSTANCE AVAILABILITY NOTIFICATION INFORMATION OBJECT
DEFINITION
B.XX.1 IOD Description
An "Instance Availability Notification Information Object Definition" is a summary of the information that
describes the availability of a set of Composite Instances.240
B.XX.2 IOD Modules
Table B.XX.2-1 lists the modules, which make up the Instance Availability Notification IOD.
Table B.XX.2-1
INSTANCE AVAILABILITY NOTIFICATION IOD MODULES
Module
Reference
Module Description
SOP Common
C.12.1
Contains SOP common information
Instance Availability Notification
C.4.XX
References the related SOPs and IEs.
245
Item #2 Add to Part 3, Section C.4 (Study Modules) the following Module:
C.4.XX Instance Availability Notification Module
Table C.4.XX-1 specifies the Attributes used to describe which Instances are available and their
relationships.250
Table C.4.XX-1
INSTANCE AVAILABILITY NOTIFICATION MODULE ATTRIBUTES
Attribute Name
Tag
Attribute Description
Referenced Performed
Procedure Step Sequence
(0008,1111)
Uniquely identifies the Performed Procedure Step
SOP Instance to which this availability notification
instance is related, if any. The Sequence shall have
zero or one Item.
Notes: 1. This may refer to a different PPS than that
encoded in the composite instances
themselves.
2. It is typically used for notification about
instances created as a consequence of some
scheduled activity.
>Referenced SOP Class UID
(0008,1150)
Uniquely identifies the referenced SOP Class of the
Performed Procedure Step.
>Referenced SOP Instance
UID
(0008,1155)
Uniquely identifies the referenced SOP Instance of
the Performed Procedure Step.
>Performed Workitem Code
Sequence
(0040,4019)
A sequence that conveys the (single) type of
procedure performed.
Supplement 93: Instance Availability Notification
Page 10
Only a single Item shall be permitted in this
sequence.
>>Include Code Sequence Macro Table 8.8-1
Baseline Context ID is CID 9231.
Study Instance UID
(0020,000D)
Unique identifier for the Study of which all the
Instances referenced in this notification are part.
Referenced Series Sequence
(0008,1115)
Sequence of Items where each Item includes
references to Instances within the same Series. One
or more Items shall be included in this Sequence.
>Series Instance UID
(0020,000E)
Unique identifier of the Series of which all the
Instances referenced in this Item are part.
>Referenced SOP Sequence
(0008,1199)
Sequence of Items where each Item includes a
reference to a single Instance within this Series. One
or more Items shall be included in this Sequence.
>>Referenced SOP Class UID
(0008,1150)
Uniquely identifies the referenced SOP Class.
>>Reference SOP Instance
UID
(0008,1155)
Uniquely identifies the referenced SOP Instance.
>>Instance Availability
(0008,0056)
The availability of the referenced Instance.
See Section C.4.XX.1.1
>>Retrieve AE Title
(0008,0054)
Title of the DICOM Application Entity from which the
referenced Instance may or may not be retrievable,
i.e. the scope for which Instance Availability
(0008,0056) applies. See Section C.4.XX.1.1.
>>Storage Media File-Set ID
(0088,0130)
The user or implementation specific human readable
identifier that identifies the offline storage media on
which the instance resides.
>>Storage Media File-Set UID
(0088,0140)
Uniquely identifies the offline storage media on which
the instance resides.
C.4.XX.1 Instance Availability Notification Module Attribute Definitions
C.4.XX.1.1 Instance Availability255
The Enumerated Values for Instance Availability (0008,0056) are:
— “ONLINE” means the instances are immediately available from the Retrieve AE Title
(0008,0054), and if a C-MOVE were to be requested, it would succeed in a
reasonably short time
— “NEARLINE” means the instances need to be retrieved from relatively slow media such260
as optical disk or tape, and if a C-MOVE were to be requested from the Retrieve AE
Title (0008,0054), it would succeed, but may take a considerable time
— “OFFLINE” means that a manual intervention is needed before the instances may be
retrieved, and if a C-MOVE were to be requested from the Retrieve AE Title
(0008,0054), it would fail (e.g., by timeout) without such manual intervention.265
— “UNAVAILABLE” means the instances cannot be retrieved from the Retrieve AE Title
(0008,0054), and if a C-MOVE were to be requested, it would fail. Note that SOP
Instances that are unavailable from this AE may be available from other AEs, or may
have an alternate representation that is available from this AE.
Supplement 93: Instance Availability Notification
Page 11
270
Supplement 93: Instance Availability Notification
Page 12
275
Changes to NEMA Standards Publication PS 3.4-2003
Digital Imaging and Communications in Medicine (DICOM)
Part 4: Service Class Definitions280
Supplement 93: Instance Availability Notification
Page 13
Item #3 Add new Annex X Instance Availability Notification Service:
Annex X INSTANCE AVAILABILITY NOTIFICATION SERVICE
CLASS
(Normative)
X.1 OVERVIEW285
X.1.1 Scope
The Instance Availability Notification Service Class defines an application-level class-of-service
that allows one DICOM AE to notify another DICOM AE of the presence and availability of SOP
instances that may be retrieved. The AE from which such SOP Instances can later be retrieved
may or may not be the SCU performing the notification.290
Note: An example of usage of this Service Class is for the receiver of the instances to provide
notification of their arrival and availability for subsequent workflow steps to a different entity,
such as a separate workflow manager.
The SCU implementation defines the conditions under which it provides the notification. Certain295
SCUs may provide notification for arbitrary sets of SOP Instances, while other SCUs may provide
notification when they determine that the instances associated with a Procedure Step or a
Requested Procedure are available. The SCU is required to document in its Conformance
Statement the nature of its notification decisions (e.g., frequency of notifications, retrieve
capabilities and latency, etc.).300
Once the SCU has provided notification about availability of the SOP Instances, the SCP may use
that information in directing further workflow, such as in populating the Input Information
Sequence and Relevant Information Sequence when forming General Purpose Scheduled
Procedure Step. These types of policies are outside the scope of this Standard, however, the
SCP is required to document these policies in its Conformance Statement.305
The SCU of this Service Class is not required to assure that the study, procedure step or any
workflow-related entity is “complete”; indeed no semantics other than the concept of “availability”
is expressed or implied by the use of this service.
Notes: 1. The Performed Workitem Code Sequence (0040,4019) attribute of a referenced GP-PPS
instance may provide the specific description of the work item that triggered the Instance310
Availability Notification.
2. The Instance Availability Notification is typically a service of the composite instance Storage
SCP, since that application is responsible for making the instances available. The Instance
Availability Notification allows that application to report the specific Retrieve AE Title, which
may differ from the Storage Service AE Title, and which may vary with different instance SOP315
Classes, or may vary over time.
X.2 CONFORMANCE OVERVIEW
The Instance Availability Notification Service Class consists of a single SOP Class: the Instance
Availability Notification SOP Class. 320
Supplement 93: Instance Availability Notification
Page 14
The SOP Class specifies Attributes, operations, and behavior applicable to the SOP Class. The
conformance requirements shall be specified in terms of the Service Class Provider (SCP) and the
Service Class User (SCU).
The Instance Availability Notification Service Class uses the Instance Availability Notification IOD as
defined in PS 3.3 and the N-CREATE DIMSE Service specified in PS 3.7.325
X.3 INSTANCE AVAILABILITY NOTIFICATION SOP CLASS
X.3.1 DIMSE Service Group
The DIMSE Services shown in Table X.3.1-1 are applicable to the Instance Availability Notification IOD
under the Instance Availability Notification SOP Class.
Table X.3.1-1330
DIMSE SERVICE GROUP
DIMSE Service Element
Usage SCU/SCP
N-CREATE
M/M
The DIMSE Services and Protocols are specified in PS 3.7.
Note: Though the terminology “notification” is used for this Service Class, the notification is in fact
performed through Operations rather than Notifications.335
X.3.2 Operations
The Application Entity that claims conformance to this SOP Class as an SCU shall be permitted to
invoke the following operations and the Application Entity that claims conformance as an SCP shall
be capable of providing the following operations.340
X.3.2.1 N-CREATE Instance Availability Notification SOP Instance
This operation allows an SCU to create an instance of the Instance Availability Notification SOP Class
and to provide availability information about Instances that are under the control of the SCU. This
operation shall be invoked through the DIMSE N-CREATE Service.
X.3.2.1.1 Attributes345
The Attribute list of the N-CREATE is defined as shown in Table X.3.2-1.
Table X.3.2-1
INSTANCE AVAILABILITY NOTIFICATION SOP CLASS N-CREATE ATTRIBUTES
Attribute Name
Tag
Req. Type
N-CREATE
(SCU/SCP)
Specific Character Set
(0008,0005)
1C/1C
(Required if an
extended or
replacement
character set is used)
All other Attributes of SOP Common Module
3/3
Referenced Performed Procedure Step
Sequence
(0008,1111)
2/2
Supplement 93: Instance Availability Notification
Page 15
>Referenced SOP Class UID
(0008,1150)
1/1
>Referenced SOP Instance UID
(0008,1155)
1/1
>Performed Workitem Code Sequence
(0040,4019)
2/2
>>Code Value
(0008,0100)
1/1
>>Coding Scheme Designator
(0008,0102)
1/1
>>Code Meaning
(0008,0104)
1/1
>>All other Attributes from Performed Workitem Code
Sequence
3/3
Study Instance UID
(0020,000D)
1/1
Referenced Series Sequence
(0008,1115)
1/1
>Series Instance UID
(0020,000E)
1/1
>Referenced SOP Sequence
(0008,1199)
1/1
>>Referenced SOP Class UID
(0008,1150)
1/1
>>Reference SOP Instance UID
(0008,1155)
1/1
>>Instance Availability
(0008,0056)
1/1
>>Retrieve AE Title
(0008,0054)
1/1
>>Storage Media File-Set ID
(0088,0130)
3/3
>>Storage Media File-Set UID
(0088,0140)
3/3
X.3.2.1.2 Service Class User350
The SCU shall specify in the N-CREATE request primitive the SOP Class and SOP Instance UIDs
of the Instance Availability Notification SOP Instance which is created and for which Attribute
Values are to be provided.
The SCU shall provide Attribute values for the Instance Availability Notification SOP Class
Attributes as specified in Table X.3.2-1.355
The use of additional optional Attributes by the SCU is forbidden.
Note: The reason for forbidding optional attributes is to prevent the use of Standard Extended SOP
Classes that might add contextual information such as patient and procedure identifiers.
The encoding rules for Instance Availability Notification Attributes are specified in the N-CREATE360
request primitive specification in PS 3.7.
There are no requirements on when N-CREATE requests are required to be performed.
In particular, there are no requirements that notification about the availability of the first instance of
a Performed Procedure Step or Study be provided upon its reception, nor that availability
notification be provided when an entire set of instances comprising a completed Performed365
Procedure Step or Study are available, though these are typical and common scenarios.
Supplement 93: Instance Availability Notification
Page 16
X.3.2.1.3 Service Class Provider
The SCP shall return, via the N-CREATE response primitive, the N-CREATE Response Status
Code applicable to the associated request.
X.3.2.1.4 Status Codes370
There are no specific status codes. See PS 3.7 for response status codes.
X.3.3 Instance Availability Notification SOP Class UID
The Instance Availability Notification SOP Class shall be uniquely identified by the Instance
Availability Notification SOP Class UID, which shall have the value "1.2.840.10008.5.1.4.33".
X.3.4 Conformance Requirements375
Implementations shall include within their Conformance Statement information as described
below.
An implementation may conform to this SOP Class as an SCU or as an SCP. The Conformance
Statement shall be in the format defined in Annex A of PS 3.2.
X.3.4.1 SCU Conformance380
An implementation that is conformant to this SOP Class as an SCU shall meet conformance
requirements for the operations that it invokes.
X.3.4.1.1 Operations
Any Attributes for which Attribute Values may be provided (using the N-CREATE) by the SCU
shall be enumerated in the SCU Conformance Statement. The SCU Conformance Statement385
shall be formatted as defined in Annex A of PS 3.2.
An implementation that conforms to this SOP Class as an SCU shall specify under which
conditions during the performance of real-world activities it will create the SOP Class Instance.
The SCU Conformance Statement shall specify what is meant by each reported value of
Instance Availability (0008,0056).390
The SCU Conformance Statement shall describe the relationship between the Instance
Availability Notification and the Performed Procedure Step SOP Classes, if the latter are
supported.
X.3.4.2 SCP Conformance
An implementation that is conformant to this SOP Class as an SCP shall meet conformance395
requirements for the operations that it performs.
X.3.4.2.1 Operations
The SCP Conformance Statement shall be formatted as defined in Annex A of PS 3.2.
The SCP Conformance Statement shall provide information on the behavior of the SCP (in terms
of real world activities) for each reported value of Instance Availability (0008,0056).400
The SCP Conformance Statement shall describe the behavioral relationship between the
Instance Availability Notification and the Performed Procedure Step SOP Classes, if the latter
are supported.
Supplement 93: Instance Availability Notification
Page 17
405
410
Changes to NEMA Standards Publication PS 3.6-2003
Digital Imaging and Communications in Medicine (DICOM)
Part 6: Data Dictionary
Supplement 93: Instance Availability Notification
Page 18
Item #5 Add the following UID to Part 6 Annex A:415
UID Value
UID Name
UID Type
Part
1.2.840.10008.5.1.4.33
Instance Availability
Notification SOP Class
SOP Class
Part 4
Supplement 93: Instance Availability Notification
Page 19
420
425
Changes to NEMA Standards Publication PS 3.16-2003
Digital Imaging and Communications in Medicine (DICOM)
Part 16: Content Mapping Resource
Supplement 93: Instance Availability Notification
Page 20
430
Item #6 Add the following term to the Context Group 9231 in Part 16 Annex B:
CID 9231 General Purpose Workitem Definition
Context ID 9231
General Purpose Workitem Definition435
Type: Extensible Version: 20040615
Coding
Scheme
Designator
(0008,0102)
Code Value
(0008,0100)
Code Meaning
(0008,0104)
DCM
110001
Image Processing
DCM
110002
Quality Control
DCM
110003
Computer Aided Diagnosis
DCM
110004
Computer Aided Detection
DCM
110005
Interpretation
DCM
110006
Transcription
DCM
110007
Report Verification
DCM
110008
Print
DCM
110009
No subsequent Workitems
DCM
110013
Media Import
Item #7 Add the following Definitions to Part 16 Annex D:440
110013
Media Import
The procedure to read DICOM
instances from DICOM interchange
media, coerce identifying
attributes into the local namespace
if necessary, and make the
instances available.
