IHE統合プロファイル「可搬型医用画像」
IHE:PDI(Portable Data for Imaging）Integration Profile

本書はIHEが定める放射線部門（Radiology）のテクニカルフレームワークの内媒体
による画像を含む診療情報を交換するための統合プロファイルについて、“IHE
Technical Framework，Vol.I Integration Profilesの１，２，１５章およびVol.III
Transactions (Continued) Rev.8.0”から４章のPDIに関する部分を抜粋しまとめたものである。IHEテクニカルフレームワークの全体像が分かるように、Introduction
やProfilesなどの記述についてはそのまま残した。また、本書の出典元である上述のテクニカルフレームワークの記述部分が分かるように章、節などの番号はそのままの形で利用している。必要があればRadiology Domain IHE Technical Framework
を参照いただきたい。参照先は以下である。
http://www.ihe.net/Technical_Framework/index.cfm#radiology
Radiology Technical Framework
Revision 8.0
August 30, 2007
Copyright © 1998–2007: HIMSS/RSNA
Final Text Version

1 Introduction
Integrating the Healthcare Enterprise (IHE) is an initiative designed to stimulate theintegration of the information systems that support modern healthcare institutions. Its
fundamental objective is to ensure that in the care of patients all required information
for medical decisions is both correct and available to healthcare professionals. The IHE
initiative is both a process and a forum for encouraging integration efforts. It defines atechnical framework for the implementation of established messaging standards toachieve specific clinical goals. It includes a rigorous testing process for the
implementation of this framework. And it organizes educational sessions and exhibits
at major meetings of medical professionals to demonstrate the benefits of thisframework and encourage its adoption by industry and users.
The approach employed in the IHE initiative is not to define new integration standards,
but rather to support the use of existing standards initially DICOM and HL7, but
potentially others, as appropriate in their respective domains in an integrated manner,
defining configuration choices when necessary. When clarifications or extensions toexisting standards are necessary, IHE refers recommendations to the relevant standards
bodies.
This initiative has numerous sponsors and supporting organizations in different medical
specialty domains and geographical regions. In North America the primary sponsors
are the Healthcare Information and Management Systems Society (HIMSS) and theRadiological Society of North America (RSNA). The American College of Cardiology(ACC) and Laboratory Healthcare Partnership (LHCP) are currently supporting
exploratory IHE activities in their respective domains. IHE Europe (IHE-EUR) is
supported by a large coalition of organizations including the European Association ofRadiology (EAR) and European Congress of Radiologists (ECR), the Coordination
Committee of the Radiological and Electromedical Industries (COCIR), Deutsche
Röntgengesellschaft (DRG), the EuroPACS Association, Groupement pour laModernisation du Système d'Information Hospitalier (GMSIH), Société Francaise deRadiologie (SFR), and Società Italiana di Radiologia Medica (SIRM). In Japan IHE-J
is sponsored by the Ministry of Economy, Trade, and Industry (METI); the Ministry of
Health, Labor, and Welfare; and MEDIS-DC; cooperating organizations include theJapan Industries Association of Radiological Systems (JIRA), the Japan Association of
Healthcare Information Systems Industry (JAHIS), Japan Radiological Society (JRS),
Japan Society of Radiological Technology (JSRT), and the Japan Association of
Medical Informatics (JAMI). Other organizations representing healthcare professionals
are invited to join in the expansion of the IHE process across disciplinary andgeographic boundaries.

1.1 Overview of Technical Framework
This document, the IHE Technical Framework, defines specific implementations ofestablished standards to achieve integration goals that promote appropriate sharing of
medical information to support optimal patient care. It is expanded annually, after aperiod of public review, and maintained regularly through the identification andcorrection of errata. The current version, rev. 8.0, specifies the IHE transactions
defined and implemented as of April 2007. The latest version of the document isalways available via the Internet at www.ihe.net/Technical_Framework/.
The IHE Technical Framework identifies a subset of the functional components of thehealthcare enterprise, called IHE Actors, and specifies their interactions in terms of aset of coordinated, standards-based transactions. It describes this body of transactionsin progressively greater depth. The present volume provides a high-level view of IHE
functionality, showing the transactions organized into functional units called
Integration Profiles that highlight their capacity to address specific clinical needs. The
subsequent volumes, II and III, provide detailed technical descriptions of each IHE
transaction.
The other domains within the IHE initiative also produce Technical Frameworks within
their respective areas that together form the IHE Technical Framework. Currently, thefollowing IHE Technical Framework(s) are available:• IHE IT Infrastructure Technical Framework• IHE Radiology Technical Framework
Where applicable, references are made to other technical frameworks. For theconventions on referencing other frameworks, see Section 1.6.4 within this volume.

1.2 Overview of Volume I
The remainder of section 1 further describes the general nature, purpose and functionof the Technical Framework. Section 2 introduces the concept of IHE Integration
Profiles that make up the Technical Framework.
Section 3 and the subsequent sections of this volume provide detailed documentation
on each integration profile, including the clinical problem it is intended to address andthe IHE Actors and transactions it comprises.

The appendices following the main body of the document provide detailed discussionof specific issues related to the integration profiles and a glossary of terms andacronyms used.

1.3 Audience
The intended audience of this document is:• Technical staff of vendors participating in the IHE initiative• IT departments of healthcare institutions• Experts involved in standards development• Anyone interested in the technical aspects of integrating healthcare information
systems

1.4 Relationship to Standards
The IHE Technical Framework identifies functional components of a distributed
healthcare environment (referred to as IHE Actors), solely from the point of view of
their interactions in the healthcare enterprise. At its current level of development, it
defines a coordinated set of transactions based on the HL7 and DICOM standards. As
the scope of the IHE initiative expands, transactions based on other standards will be
included as required.
In some cases, IHE recommends selection of specific options supported by thesestandards; however, IHE does not introduce technical choices that contradict
conformance to these standards. If errors in or extensions to existing standards are
identified, IHE’s policy is to report them to the appropriate standards bodies forresolution within their conformance and standards evolution strategy.
IHE is therefore an implementation framework, not a standard. Referencing IHE as astandard is inappropriate. Conformance claims by product must still be made in directreference to specific standards. In addition, vendors who have implemented IHE
integration capabilities shall use an IHE Integration Statement to describe theconformance of their product to the specifications in the IHE Technical Framework.
The purpose of an IHE Integration Statement is to communicate to the users of thecorresponding product the IHE capabilities it has been designed to support. Vendors
publishing IHE Integration Statements accept full responsibility for their content. By
comparing the IHE Integration Statements from different implementations, a user
familiar with the IHE concepts of Actors and Integration Profiles should be able todetermine whether and to what extent communications might be supported between
products. See Appendix D for the format of such IHE Integration Statements. IHE
encourages implementers to ensure that products implemented in accordance with the
IHE Technical Framework also meet the full requirements of the standards underlying
IHE, allowing the products to interact, although possibly at a lower level of integration,with products that have been implemented in conformance with those standards, but
not in full accordance with the IHE Technical Framework.

1.5 Relationship to Real-world Architectures
The IHE Actors and transactions described in the IHE Technical Framework are
abstractions of the real-world healthcare information system environment. While someof the transactions are traditionally performed by specific product categories (e.g. HIS,Electronic Patient Record, RIS, PACS, Clinical Information Systems or imaging
modalities), the IHE Technical Framework intentionally avoids associating functions or
actors with such product categories. For each actor, the IHE Technical Framework
defines only those functions associated with integrating information systems. The IHE
definition of an actor should therefore not be taken as the complete definition of any
product that might implement it, nor should the framework itself be taken tocomprehensively describe the architecture of a healthcare information system.
The reason for defining actors and transactions is to provide a basis for defining theinteractions among functional components of the healthcare information system
environment. In situations where a single physical product implements multiple
functions, only the interfaces between the product and external functions in theenvironment are considered to be significant by the IHE initiative. Therefore, the IHE
initiative takes no position as to the relative merits of an integrated environment basedon a single, all-encompassing information system versus one based on multiple systems
that together achieve the same end. To illustrate most dramatically the possibilities of
the IHE Technical Framework, however, the IHE demonstrations emphasize theintegration of multiple vendors’ systems based on the IHE Technical Framework.

1.6 Conventions
This document has adopted the following conventions for representing the framework
concepts and specifying how the standards upon which the IHE Technical Framework
is based should be applied.

1.6.1 Actor and Transaction Diagrams and Tables
Each integration profile is a representation of a real-world capability that is supported
by a set of actors that interact through transactions. Actors are information systems orcomponents of information systems that produce, manage, or act on categories of
information required by operational activities in the enterprise. Transactions areinteractions between actors that transfer the required information throughstandards-based messages.
The tables of actors and transactions given in sections 3 - 14 indicate whichtransactions each actor in a given profile must support.
The convention used in these diagrams is that the arrow indicating the direction for thetransaction points from the initiator of the transaction to the destination.
In some cases, a profile is dependent on a pre-requisite profile in order to function
properly and be useful. For example, Presentation of Grouped Procedures depends on
both Scheduled Workflow and Consistent Presentation of Images being implemented
as pre-requisites. These dependencies can be found by locating the desired profile in
Table 2-1 and seeing which profiles are listed as required pre-requisites.
An actor must implement all required transactions in the pre-requisite profiles in
addition to those in the desired profile. In some cases, the pre-requisite is that the actor
selects any one of a given set of profiles to satisfy the pre-requisite. For example,
Post-processing depends on any one of the content profiles being supported.
1.6.2 Process Flow Diagrams
The descriptions of integration profiles that follow include Process Flow Diagrams that
illustrate how the profile functions as a sequence of transactions between relevant
actors.
These diagrams are intended to provide a “big picture” so the transactions can be seenin the context of the overall workflow. Certain transactions and activities not defined indetail by IHE are shown in these diagrams in italics to provide additional context on
where the relevant IHE transactions fit into the broader scheme of healthcare
information systems.
These diagrams are not intended to present the only possible scenario. Often other actor
groupings are possible, and complementary transactions from other profiles may beinterspersed. In some cases the sequence of transactions may be flexible. Where this isthe case there will generally be a note pointing out the possibility of variations.
The convention used in these diagrams is that the arrow on the line for the transaction
points from the initiator of the transaction to the destination.
1.6.3 Normative versus informative contents of the Technical Framework
Most parts of the Technical Framework describe required or optional characteristics ofIntegration Profiles, Actors and Transactions: these are normative. For a better
understanding of the text, there also exist illustrating parts in the Technical Frameworkthat are informative and non-normative.
According to IETF RFC 2119, certain words indicate whether a specific content of theTechnical Framework is normative: either required (e.g. “must”, “required”, “shall”) or
optional (e.g. “may”, “recommended”). Informative content does not contain these key
words.
1.6.4 Technical Framework Referencing
When references are made to a section within the same Technical Framework volume,
a section number is used by itself. When references are made to other volumes or to a
Technical Framework in another domain, the following format is used:<domain designator> TF-<volume number>: <section number>, where<domain designator> is a short designator for the IHE domain (ITI = IT Infrastructure,
RAD = Radiology)<volume number> is the applicable volume within the given Technical Framework(e.g., 1, 2, 3), and<section number> is the applicable section number.
For example: ITI TF-1: 3.1 refers to section 3.1 in volume 1 of the IHE IT
Infrastructure Technical Framework, RAD TF-3: 4.33 refers to section 4.33 in volume
3 of the IHE Radiology Technical Framework.
When references are made to specific transactions (transaction numbers) the following
format is used:<domain designator>-<transaction number>
For example RAD-4 refers to transaction number 4 (Procedure Scheduled) in theRadiology Technical Framework.

1.9 Copyright Permission
Health Level Seven, Inc., has granted permission to the IHE to reproduce tables fromthe HL7 standard. The HL7 tables in this document are copyrighted by Health Level
Seven, Inc. All rights reserved.
The National Electrical Manufacturers Association (NEMA) has granted permission to
the IHE to incorporate portions of the DICOM standard.
Material drawn from these documents is credited where used.

1.10 IHE Radiology Technical Framework Development andMaintenance Process
The Technical Framework is being continuously extended and maintained by the IHE
Technical Committee. The Development and Maintenance Process of the Framework
follows a number of principles to ensure stability of the specification both vendors andusers may rely upon in specifying, developing and acquiring IHE compatible products.
The process is intended to address the need for extensions, clarifications andcorrections while maintaining backward compatibility of framework definitions as tosupport implementations claiming conformance to any previously defined Integration
Profile and its Actors.
To maintain stability of the IHE Technical Framework, modifications occur in a
regular annual cycle (Figure 1.10-1) according to one of two controlled paths:
1. New Development – Extending the Existing Technical Framework
Each year, new functionality to be developed is identified by the IHE Planning
Committee. The Technical Committee performs the necessary analysis and design
work and generates new text for the Technical Framework.
Generally, new functionality is published in the form of a Supplement. The scope of a
Supplement is to make one of the following additions to the Technical Framework:• A new Integration Profile, usually including the introduction of new Actors andTransactions.
• New Actors in an existing Integration Profile: These may be either Actors
previously defined elsewhere in the Technical Framework, or new ones not yet
defined. Transactions identifying the new actors responsibilities in this profile
are identified or defined and may be designated as required or optional. To
avoid causing compatibility problems for systems that have alreadyimplemented that profile, no new required Transactions are added for existing
Actors in the profile.
• New Options in an existing Integration Profile: These usually add optional
Transactions for existing actors in the profiles, or add optional features within
existing Transactions.
• Major conceptual changes: They do not change the behavior of existing
Integration Profiles but may imply changes or additions to Actors orTransactions in the future. The publication process consists of certain phases
and is clearly indicated on each document.
First, the text is published for Public Comment (with a “PC” designation). During the
Public Comment period (typically 30 days), the text and a comment submission facility
are available on the IHE Website. Following this period, the Technical Committee will
review the comments.
Updated text of Supplements is then published for Trial Implementation (with a “TI”
designation), based on the modifications resulting from the comments received.
After trial implementations have been judged to have sufficiently exercised the newfunctionality (e.g. due to experience from the Connect-a-thon), and the text is
considered sufficiently stable, the new text will be published as Final Text (with a“FT” designation).
Final Text Supplements will be merged at the end of the annual development cyclewith the current version of the Technical Framework resulting in a new version of theTechnical Framework with an increased version number.
2. Maintenance of existing Technical Framework content
Despite the best efforts of the Technical Committee, a published current version of theTechnical Framework or Trial Implementation documents may contain text that isincorrect, incomplete or unclear. Such issues are handled as Change Proposals andcover:• Corrections: technical issues causing non-interoperability of implementations are
fixed without introducing changes in functionality of a stable Integration
Profile.
• Clarifications: text that can be misunderstood or is ambiguous is made easier tounderstand or disambiguated, without introducing any technical changes.
The publication process is the same for both Corrections and Clarifications, andaddresses both changes to Trial Implementations and changes to a current version of
the Technical Framework.
A Submitted Change Proposal results from issues raised by users, vendors orTechnical Committee members, e.g. from experiences with Trial Implementation or
Final Text Integration Profiles or at a Connectathon. The resulting Change Proposal
document should explicitly state:• the parts of the Technical Framework requested to be changed,• a problem description,• a rationale why the change is considered necessary,• and a solution or approach to the problem.
The Technical Committee regularly considers Change Proposals which are then either
accepted or rejected.
A Rejected Change Proposal is published with a rationale from the TechnicalCommittee explaining why the change is not appropriate. An Accepted Change
Proposal is assigned to a member of the Technical Committee as a work item forfurther investigation with the goal to produce adequate clarifications or corrections.
The resulting text will again be reviewed by the Technical Committee before being
approved.
Once approved, a Final Text Change Proposal is published by the TechnicalCommittee, and then is to be considered as effective. It will be merged into the next
version of the Technical Framework at the end of the annual development cycle.
Submitting a Change Proposal to a Final Text Change Proposal or a Final Text
Supplement is not possible.
The current version of the Technical Framework is considered the primary reference
document. Final Text Supplements and Final Text Change Proposals from the current
annual cycle complement this document. Past Final Text documents are retained toprovide convenient summaries of differences to prior versions of the Technical
Framework or Trial Implementation versions of Supplements.
During the annual development and maintenance cycle, it is recommended to use
Technical Framework documents for implementations as follows:• Product Implementations Products implemented based on Trial Implementation text
are expected to review the subsequent Final Text and update their products asnecessary. Further, it is expected that vendors will monitor Final Text Change

Proposals and make any corrections relevant to their product in a timely fashion.
• Connectathon Implementations Testing at the Connectathon will be based on thecurrent version of the Technical Framework for the appropriate IHE Domain, plus
any relevant Supplements for Trial Implementation and Final Text Change
Proposals.

Figure 1.10-1. The figure shows the process of developing and maintaining the Technical
Framework during an annual cycle. Dashed arrows indicate the assembly (merging) of text.

2 Integration Profiles
IHE Integration Profiles, depicted in Figure 2-1, offer a common language that
healthcare professionals and vendors may use in communicating requirements for the
integration of products. Integration Profiles describe real-world scenarios or specificsets of capabilities of integrated systems. An Integration Profile applies to a specified
set of actors and for each actor specifies the transactions necessary to support thosecapabilities.
Integration Profiles provide a convenient way for both users and vendors to reference a
subset of the functionality detailed in the IHE Technical Framework. They enable users
and vendors to be more specific than simply requesting or promising overall IHE
support, without laborious restatement of the details regarding IHE actors andtransactions defined by the IHE Technical Framework.
The Profiles can be considered in three classes: Content Profiles which address the
management of a particular type of content object; Workflow Profiles which address
the management of the workflow process by which content is created; andInfrastructure Profiles which address departmental issues. Figure 2-1 shows the current
set of IHE Integration Profiles organized around these classes.
The Content Profiles describe the creation, storage, management, retrieval and generaluse of a particular type of content object. Current Content Profiles include: Consistent
Presentation of Images, Key Image Notes, NM Image, Mammography Image,
Evidence Documents, and Simple Image and Numeric Reports. Additionally, thehandling of image content is described inside the Scheduled Workflow Profile. Content
Profiles are “workflow neutral”. The profile addresses how the object is created, stored,
queried and retrieved, but does not address the workflow management process.
The Workflow Profiles address managing workflow process, which typically involves
providing worklists, and reporting/monitoring the progress and completion ofworkitems. Within this context, one or more content objects are generally createdaccording to their content profile. Current Workflow Profiles include: Scheduled
Workflow (for acquisition), Post-Processing Workflow, Reporting Workflow,
Cross-enterprise Document Sharing for Imaging and Import Reconciliation Workflow.
Presentation of Grouped Procedures is an extension of Scheduled Workflow. Charge
Posting is an extension of all the Workflow Profiles.
The Infrastructure Profiles address general departmental issues like Radiology Audit
Trail Option and Access to Radiology Information.

Figure 2-1. IHE Integration Profiles

Dependencies among Integration Profiles
In general, IHE Integration Profiles do not operate independently. Objects that serve as
useful input to one profile may have been produced as a result of implementing anotherprofile.
Figure 2-1 (above) provides a graphical view of the dependencies between Integration
Profiles. The arrows in the diagram point from the dependent profile to the profile(s)on which it relies. In addition, dashed arrows indicate that the dependent profile
requires one or more of the profiles it has dashed arrows pointing to.
Table 2-1 defines the required dependencies between the Integration Profiles in atabular form.
In some cases a profile is strictly dependent on one or more profiles in order to function.
For example, Presentation of Grouped Procedures depends directly on the features of
Scheduled Workflow and Consistent Presentation of Images in order to function.
In other cases a profile is dependent on one of a class of profiles in order to be useful.

For example, Charge Posting depends on at least one of the workflow profiles(Scheduled Workflow, Post-Processing Workflow and/or Reporting Workflow) being
present in order for it to have something useful to post. Similarly, each workflow
profile is of little value unless at least one relevant content profile is also implemented.
Of course the more content profiles are supported, the more forms of input and output
can be managed by the workflow.
There are of course other useful synergies that occur when different combinations ofprofiles are implemented, but those are not described in the table below.
Table 2-1. Integration Profiles Dependencies

2.1 Integration Profiles Overview
In this document, each IHE Integration Profile is defined by:• The IHE Actors involved• The specific set of IHE Transactions required for each IHE Actor.
These requirements are presented in the form of a table of transactions required foreach actor supporting the Integration Profile. Actors supporting multiple Integration
Profiles are required to support all the required transactions of each Integration Profile
supported. When an Integration Profile depends upon another Integration Profile, alltransactions required for the dependent Integration Profile have been included in thetable.

As mentioned earlier, there is a class of Profiles that deal primarily with data content.
Most types of content belong to the family of Evidence Objects. Currently this means
Images, Presentation States, Key Image Notes and Evidence Documents. Evidence
Objects are generated as a result of performing procedure steps on systems in theradiology department. These objects are used by the Radiologist in the process ofcreating a Radiological Diagnostic Report and are managed inside the Radiology
Department. Evidence Documents represent the uninterpreted information that is
primarily managed and used inside Radiology, although distribution outside Radiology
is not precluded. In contrast, the diagnostic reports described in the Simple Image andNumeric Reports Profile represent the interpreted information which is the primary
output of the Radiology department and are available for wide distribution.
Note that IHE Integration Profiles are not statements of conformance to standards, and
IHE is not a certifying body. Users should continue to request that vendors provide
statements of their conformance to relevant standards, such as DICOM and HL7.
Standards conformance is a prerequisite for vendors adopting IHE Integration Profiles.
Also note that there are critical needs for any successful integration project that IHE
cannot address. Successfully integrating systems still requires a project plan thatminimizes disruptions and describes fail-safe strategies, specific and mutually
understood performance expectations, well-defined user interface requirements, clearly
identified systems limitations, detailed cost objectives, plans for maintenance andsupport, etc.
2.1.13 Portable Data for Imaging (PDI)The Portable Data for Imaging Integration Profile specifies actors and transactions thatallow users to distribute imaging related information on interchange media. The intent
of this profile is to provide reliable interchange of evidence objects and diagnostic
reports for import, display or print by a receiving actor. A single physical transportmeans is specified that supports the multiple usage scenarios described in this profile.
The CD format was chosen for supporting the described use cases.

2.2 Options to other Domains’ Profiles
2.3 Actor Descriptions
Actors are information systems or components of information systems that produce,
manage, or act on information associated with operational activities in the enterprise.
The following are the actors defined by IHE and referenced throughout the rest of thisdocument.
It is acknowledged that some of the terms used as modifiers for the actor names are notused consistently (e.g., Evidence Creator, Image Display). At this point, the benefit indoing extensive renaming to gain consistency is outweighed by the risk of introducing
significant confusion that would result from renaming many of the existing actors.
Therefore the actor names will remain as defined below.

2.3 Actor Descriptions
Actors are information systems or components of information systems that produce,
manage, or act on information associated with operational activities in the enterprise.
The following are the actors defined by IHE and referenced throughout the rest of thisdocument.
It is acknowledged that some of the terms used as modifiers for the actor names are notused consistently (e.g., Evidence Creator, Image Display). At this point, the benefit indoing extensive renaming to gain consistency is outweighed by the risk of introducing
significant confusion that would result from renaming many of the existing actors.
Therefore the actor names will remain as defined below.
Acquisition Modality – A system that acquires and creates medical images while apatient is present, e.g. a Computed Tomography scanner or Nuclear Medicine
camera. A modality may also create other evidence objects such as Grayscale
Softcopy Presentation States for the consistent viewing of images or Evidence
Documents containing measurements.
ADT Patient Registration – A system responsible for adding and/or updating patient
demographic and encounter information. In particular, it registers a new patient with
the Order Placer and Department System.
Charge Processor – Receives the posted charges and serves as a component of thefinancial system. Further definition of this actor is beyond current IHE scope.
Department System Scheduler/Order Filler – A department-based information
system (for instance, Radiology or Laboratory) that provides functions related to the
management of orders received from external systems or through the department
system’s user interface. Upon a defined workflow action, makes procedures
available for charge posting. The action/event that actually causes charges to post is
defined by the actor.
Display – Primary description for this actor can be found in ITI TF-1: Appendix A.
The required capabilities for its use within the Radiology Technical Framework add
the ability to view "web-viewable" diagnostic and therapeutic imaging information

on interchange media.
Document Consumer – The Document Consumer actor queries a Document Registry
actor for documents meeting certain criteria, and retrieves selected documents fromone or more Document Repository actors.
Document Registry – The Document Registry actor maintains meta-data about eachregistered document in a document entry. This includes a link to the Document
Repository where the actual document is stored. The Document Registry responds toqueries from Document Consumer actors about documents meeting specific criteria.
It also enforces some healthcare specific technical policies at the time of document
registration.
Document Repository – The Document Repository actor persistently storesdocuments. It assigns and maintains a unique identifier for each document, to allow
Document Consumers to retrieve them.
Enterprise Report Repository – A system that receives Structured Report Export
Transactions from the Report Manager and stores them.
Evidence Creator – A system that creates additional evidence objects such as images,presentation states, Key Image Notes, and/or Evidence Documents and transmits
them to an Image Archive. It also makes requests for storage commitment to the
Image Manager for the data previously transmitted. It may also retrieve worklist
entries for post-processing steps from the Post-Processing Manager and provide
notification of completion of the step, allowing the enterprise to track the status of
post-processing work.
External Report Repository Access – A system that performs retrieval of clinicalreports containing information generated outside the imaging department andpresented as DICOM Structured Reporting Objects.
Image Archive – A system that provides long term storage of evidence objects such asimages, presentation states, Key Image Notes and Evidence Documents.
Image Display – A part of a system that can access imaging evidence objects (images,
Presentation States, Key Image Notes, Evidence Documents) through network
query/retrieve or reading interchange media and allow the user to view these objects.
Image Manager – A system that provides functions related to safe storage andmanagement of evidence objects. It supplies availability information for thoseobjects to the Department System Scheduler.
Imaging Document Consumer – The Imaging Document Consumer actor parses animaging manifest document that is retrieved by the Document Consumer actor fromthe Document Repository actor, and retrieves DICOM SOP Instances referenced

within that manifest from the Imaging Document Source actor.
Imaging Document Source – The Imaging Document Source actor is the producer andpublisher of imaging documents. It is responsible for providing imaging documents
and meta-data to the Document Repository actor, which subsequently registers theimaging documents with the Document Registry actor. It also supports the retrieval
services for DICOM SOP Instances referenced in a published imaging manifest
document.
Importer – A system that imports evidence objects such as images, presentation states,
Key Image Notes or Evidence Documents from hardcopy or digital media.
Master Patient Index (MPI) – A system that maintains unique enterprise-wide
identifiers for patients. Note that this is not supported in the current scope of the IHE
Technical Framework
Order Placer – A hospital or enterprise-wide system that generates orders for various
departments and distributes those orders to the correct department.
Patient Demographics Supplier – A repository of patient information that can besearched on demographic related fields. This actor is defined in the ITI Technical
Framework.
Performed Procedure Step Manager – A system that re-distributes the Modality
Performed Procedure Step information from the Acquisition Modality or Evidence
Creator to the Department System Scheduler/Order Filler, Image Manager andReport Manager.
Portable Media Creator – This actor assembles the content of the media and writes itto the physical medium.
Portable Media Importer – This actor reads the DICOM information contained on the
media, and allows the user to select DICOM instances, reconcile key patient andstudy attributes, and store these instances. The actor grouped with the Media
Importer can then process the instances.
Post-Processing Manager – A system that provides functions related topost-processing worklist management. This involves the ability to schedule
post-processing worklist items (scheduled procedure steps), provide worklist items
to post-processing worklist clients, and update the status of scheduled and performed
procedure steps as received from post-processing worklist clients.
Print Composer – A system that generates DICOM print requests to the Print Server.
Print requests include presentation state information in the form of Presentation
Look-Up Tables (Presentation LUTs). It may also read the DICOM information
contained on interchange media.

Print Server – A system that accepts and processes DICOM print requests as a
DICOM Print SCP and performs image rendering on hardcopy media. The system
must support pixel rendering according to the DICOM Grayscale Standard Display
Function.
Report Creator – A system that generates and transmits draft (and optionally, final)
diagnostic reports, presenting them as DICOM Structured Reporting Objects. It may
also retrieve worklist entries for reporting steps from the Report Manager andprovide notification of completion of the step, allowing the enterprise to track thestatus of an awaited report.
Report Manager – A system that provides management and short-term storage of
DICOM Structured Report objects during the reporting process then distributes text
or structured reports to report repositories. It also manages the worklists and status ofreporting.
Report Reader – A part of a system that can access reports through network
query/retrieve or reading interchange media and allow the user to view reports
presented as DICOM Structured Reporting Objects.
Report Repository – A system that provides long-term storage of diagnostic reports
and their retrieval as DICOM Structured Reporting Objects.
The following table shows which actors are used in which Integration Profiles.
Table 2.3-1. Integration Profile Actors

2.4 Transaction Descriptions
Transactions are interactions between actors that transfer the required information
through standards-based messages. The following are the transactions defined by IHE
and referenced throughout the rest of this document.
1. Patient Registration – The ADT system registers and/or admits a patient andforwards the information to other information systems.
2. Placer Order Management – The Order Placer informs the Order Filler of theinitiation or cancellation of an order. The Placer/Filler Order Managementtransaction will sometimes be referred to as “-New” when a new order isbeing initiated, or as “-Cancel” when an existing order is canceled.
3. Filler Order Management – The Order Filler informs the Order Placer of theinitiation, cancellation, or change in the status of an order. The Placer/Filler
Order Management transaction will sometimes be referred to as “-New”
when a new order is being initiated, or as “-Cancel” when an existing order iscanceled.
4. Procedure Scheduled – Schedule information is sent from the Department
System Scheduler/Order Filler to the Image Manager and to the ReportManager.
5. Query Modality Worklist – In response to a query (with optional filtering) a
list of Scheduled Procedure Steps with selected demographic and orderinformation is returned.
6. Modality Procedure Step In Progress – An Acquisition Modality notifies the
Performed Procedure Step Manager of the start of a new Procedure Step andthe PPS Manager informs the Department System, Image Manager and theReport Manager.
7. Modality Procedure Step Completed – An Acquisition Modality notifies the
Performed Procedure Step Manager of the completion of a Procedure Step
and the PPS Manager informs the Department System, Image Manager andthe Report Manager.
8. Modality Images Stored – An Acquisition Modality sends acquired or
generated images to the Image Archive.
9. Modality Presentation State Stored – An Acquisition Modality requests that
the Image Archive store a Grayscale Softcopy Presentation State (GSPS) for
the acquired or generated images.
10. Storage Commitment – A requestor (Acquisition Modality or Evidence
Creator) requests that the Image Manager confirm ownership for the
specified DICOM objects (images, GSPS objects, Key Image Notes,
Evidence Documents or any combination thereof) that the requestor stored in
the Image Archive, thus allowing the sender to delete those objects now
owned by the Image Manager.
11. Images Availability Query – The Department System Scheduler/Order Filler
and Report Manager asks the Image Manager if a particular image or image
series is available.
12. Patient Update – The ADT Patient Registration System informs the Order
Placer and the Department System Scheduler/Order Filler of new information
for a particular patient. The Department System Scheduler may then further
inform the Image Manager and Report Manager.
13. Procedure Update – The Department System Scheduler/Order Filler sends the
Image Manager and Report Manager updated order or procedure information.
14. Query Images – An Image Display queries the Image Archive for a list of
entries representing images by patient, study, series, or instance.
15. Query Presentation States – An Image Display queries the Image Archive fora list of entries representing image Grayscale Softcopy Presentation States

(GSPS) by patient, study, series, or instance.
16. Retrieve Images – An Image Display or an Imaging Document Consumer
requests and retrieves a particular image or set of images from the Image
Archive or an Imaging Document Source, respectively.
17. Retrieve Presentation States – An Image Display or an Imaging Document
Consumer requests and retrieves the Grayscale Softcopy Presentation State(GSPS) information for a particular image or image set.
18. Creator Images Stored – An Evidence Creator sends new images to the Image
Archive.
19. Creator Presentation State Stored – An Evidence Creator requests that theImage Archive store the created Grayscale Softcopy Presentation Stateobjects.
20. Creator Procedure Step In Progress – An Evidence Creator notifies the
Performed Procedure Step Manager of the start of a new Procedure Step andthe PPS Manager informs the Department System and Image Manager.
21. Creator Procedure Step Completed – An Evidence Creator notifies the
Performed Procedure Step Manager of the completion of a Procedure Step
and the PPS Manager informs the Department System and Image Manager.
22. Intentionally unassigned
23. Print Request with Presentation LUT – A Print Composer sends a print
request to the Print Server specifying Presentation LUT information.
24. Report Submission – A Report Creator sends a draft or final diagnostic reportto the Report Manager.
25. Report Issuing – A Report Manager sends a draft or final diagnostic report to
the Report Repository.
26. Query Reports – A Report Reader provides a set of criteria to select the list of
entries representing diagnostic reports by patient, study, series, or instanceknown by the Report Repository or External Report Repository Access.
27. Retrieve Reports – A Report Reader or an Imaging Document Consumer
requests and retrieves a diagnostic report from the Report Repository,
External Report Repository Access or an Imaging Document Source.
28. Structured Report Export – A Report Manager composes an HL7 Resulttransaction by mapping from DICOM SR and transmits it to the Enterprise
Report Repository for storage.
29. Key Image Note Stored – An Acquisition Modality or an Evidence Creator
sends a Key Image Note to the Image Archive30. Query Key Image Notes – An Image Display queries the Image Archive for alist of entries representing Key Image Notes by patient, study, series, or
instance.
31. Retrieve Key Image Note – An Image Display or an Imaging Document
Consumer requests and retrieves a Key Image Note from the Image Archiveor an Imaging Document Source, respectively.
32. Authenticate Node [DEPRECATED] – This transaction is identical to, andhas been superseded by the Authenticate Node as part of the ITI Audit Trailand Node Authentication Profile (ITI TF-II 3.19).
33. Maintain Time [DEPRECATED] – This transaction identical to, and has beensuperseded by the Maintain Time as part of the ITI Consistent Time Profile(ITI TF-II 3.1).
34. Record Audit Event [DEPRECATED] – This transaction has beensuperseded by the Record Audit Event as part of the ITI Audit Trail andNode Authentication Profile (ITI TF-II 3.20).
35. Charge Posted - The Department System Scheduler/Order Filler sends
descriptions of potential procedure and material charges.
36. Account Management – The ADT Patient Registration Actor informs theCharge Processor about creation, modification and ending of the patient’s
account.
37. Query Post-Processing Worklist – Based on a query from a worklist client(Evidence Creator), a worklist is generated by the worklist manager(Post-Processing Manager) containing either Post-Processing or Computer
Aided Detection (CAD) workitems that satisfy the query. Workitems are
returned in the form of a list of General Purpose Scheduled Procedure Steps.
38. Workitem Claimed – A worklist client (Evidence Creator, Report Creator)
notifies the worklist provider (Post-Processing Manager, Report Manager)that it has claimed the workitem.
39. Workitem PPS In Progress – A worklist client (Evidence Creator, ReportCreator) notifies the worklist provider (Post-Processing Manager, ReportManager) that it has started work (i.e. created a General Purpose Performed
Procedure Step).
40. Workitem PPS Completed – A worklist client (Evidence Creator, ReportCreator) notifies the worklist provider (Post-Processing Manager, ReportManager) of the completion of a General Purpose Performed Procedure Step.
41. Workitem Completed – A worklist client (Evidence Creator, Report Creator)

notifies the worklist provider (Post-Processing Manager, Report Manager)that it has finished the workitem (i.e. completed a General Purpose Scheduled
Procedure Step).
42. Performed Work Status Update – The worklist provider informs otherinterested actors of the on-going status and completion of performed work.
43. Evidence Document Stored – A source actor of Evidence Documents(Acquisition Modality or Evidence Creator) sends recorded, measured orderived diagnostic evidence in the form of a DICOM Structured Report to the
Image Archive.
44. Query Evidence Documents – A user of Evidence Documents (Image Display,
Report Creator or Report Reader) queries the Image Archive for a list of
entries representing Evidence Documents.
45. Retrieve Evidence Documents – A user of Evidence Documents (Image
Display, Report Creator or Report Reader) or an Imaging Document
Consumer requests and retrieves an Evidence Document from the Image
Archive or an Imaging Document Source, respectively.
46. Query Reporting Worklist – Based on a query from a Report Creator worklist
client, a worklist is generated by the Report Manager containing reportingtask workitems that satisfy the query. Workitems are returned in the form of alist of General Purpose Scheduled Procedure Steps.
47. Distribute Imaging Information on Media – A source actor (Portable MediaCreator) writes image data, other evidence objects and reports onto a piece ofinterchange media. The media is physically transported to another actor(Portable Media Importer, Image Display, Report Reader, Display or Print
Composer) which then imports, displays or prints the evidence objects andreports. The media can also be provided to a patient or a referring physician
for web-based viewing.
48. Appointment Notification – The Department System Scheduler/Order Filler
sends the Order Placer actor the date and time of the appointment(s) related
to one or more Scheduled Procedure Step(s).
49. Instance Availability Notification – The Image Manager/Image Archive
notifies interested workflow actors (such as the Department System
Scheduler/Order Filler, Post-Processing Manager and Report Manager) about
the availability status of instances at specified storage locations.
50. Intentionally, temporarily Left Blank
51. Intentionally, temporarily Left Blank

52. Intentionally, temporarily Left Blank
53. Intentionally, temporarily Left Blank
54. Provide and Register Imaging Document Set - An Imaging Document
Source actor initiates the Provide and Register Imaging Document Set
transaction. For each document in the Submission Set, the Imaging
Document Source actor provides both the documents as an opaque octet
stream and the corresponding meta-data to the Document Repository. The
Document Repository is responsible to persistently store these documents,
and to register them in the Document Registry using the Register Documents
transaction by forwarding the document meta-data received from the Imaging
Document Source Actor. [RAD-54, derived from ITI-15].
55. WADO Retrieve – A WADO Retrieve transaction is issued by an Imaging
Document Consumer to an Imaging Document Source to retrieve DICOM
objects over HTTP/HTTPS protocol [RAD-55].
56. Intentionally, temporarily Left Blank
57. Intentionally, temporarily Left Blank
58. Intentionally, temporarily Left Blank
59. Import Procedure Step In Progress – The Performed Procedure Step
Manager receives progress notification of an importation Procedure Step andin turn notifies the Order Filler, Image Manager and the Report Manager.
60. Import Procedure Step Completed – The Performed Procedure Step Manager
receives completion notification of an importation Procedure Step and in turnnotifies the Order Filler, Image Manager and the Report Manager.
61. Imported Objects Stored – A system importing DICOM Objects or digitizedhardcopy sends imported DICOM Composite Objects to the Image Archive.
The following table shows which transactions are used in which Integration Profiles

Table 2.4-1. Integration Profile Transactions

2.5 Product Implementations
Developers have a number of options in implementing IHE actors and transactions in
product implementations. The decisions cover four levels of optionality:• For a system, select which actors it will incorporate. (Multiple actors per system is
acceptable).
• For each actor, select which Integration Profiles it will participate in.
• For each actor-profile, select which optional transactions will be implemented. All
required transactions must be implemented for the profile to be supported. (Refer tothe Integration Profile Tables in sections 3-14)

• Finally, for each transaction, select which optional features will be supported. (Referto the transaction descriptions in TF Volume II and Volume III)
Implementers should provide a statement describing which IHE Actors, IHE
Integration Profiles, optional transactions and optional features are incorporated in agiven product. The recommended form for such a statement is defined in Appendix D.
In general, a product implementation may incorporate any single actor or combinationof actors. However, in the cases specified below, the implementation of one actor
requires the implementation of one or more additional actors:• The Image Archive shall be grouped with the Image Manager, and the ImageManager shall be grouped with the Image Archive.
• The Image Manager participating in Scheduled Workflow or Reporting Workflow
Integration Profiles shall be grouped with a Performed Procedure Step Manager.
The grouped Performed Procedure Step Manager shall be capable of being disabled
via configuration.
• The Department System Scheduler/Order Filler participating in Scheduled Workflow
or Reporting Workflow shall be grouped with a Performed Procedure Step
Manager. The grouped Performed Procedure Step Manager shall be capable ofbeing disabled via configuration.
• The Print Composer shall be grouped with an Image Manager, an Acquisition
Modality, an Image Display or an Evidence Creator.
• The Evidence Creator participating in Post-Processing Workflow shall be groupedwith an Image Display.
• Any Actor participating in Basic Security Profile shall be grouped with the Secure
Node Actor• The Post-Processing Manager shall be grouped with either an Image Manager or a
Department System Scheduler.
• The Portable Media Importer shall be grouped with at least one of the following
actors in order to perform import of the supported evidence objects and/or
Diagnostic Reports:• Evidence Creator (Evidence Documents)• Acquisition Modality (Images, Key Image Notes, Evidence Documents)• Image Manager/Image Archive (Images, Presentation States, Key Image
Notes, Evidence Documents)

• Report Creator (Diagnostic Reports)• Report Manager (Diagnostic Reports)• Report Repository (Diagnostic Reports)• Importer• The Imaging Document Consumer shall be grouped with an ITI XDS Document
Consumer, thereby supporting the Document Consumer’s transactions for querying
an XDS Registry and Repository as defined in ITI XDS.
• The Importer Actor is generic in terms of not defining a specific transport mechanism
for the Evidence Objects it imports. It may be necessary for the Importer to begrouped with additional Actors to support specific transport mechanisms. For
example, to support import from PDI Media, the Importer Actor must be groupedwith the Portable Media Importer Actor.
When multiple actors are grouped in a single product implementation, all transactions
originating or terminating with each of the supported actors shall be supported (i.e., theIHE transactions shall be offered on an external product interface). The exceptions tothis rule are any transactions defined between actors in the required groupings defined
above.
For example, the Procedure Step In Progress/Completed transaction does not need tobe supported between the Performed Procedure Step Manager and the Image Manager
when these are grouped together in a single system. On the other hand, the Report
Submission Transaction must be supported even by an implementation that groups theReport Creator and the Report Manager.
When two or more actors are grouped together, internal communication between actors
is assumed to be sufficient to allow the necessary information flow to support theirfunctionality; for example, the Image Manager provides necessary information updates
to the Image Archive to support its Query/Retrieve functionality. The exact
mechanisms of such internal communication are outside the scope of the IHE
Technical Framework.
The following examples describe which actors typical systems might be expected tosupport. This is not intended to be a requirement, but rather to provide some examples
to aid understanding.
• A modality system, such as an MRI scanner and console or Ultrasound system mighttypically include an Acquisition Modality actor and a Print Composer actor.
• An imaging workstation, such as a post-processing workstation or advanced review
station might typically include an Image Display actor, an Evidence Creator actor

and a Print Composer actor.
• An HIS registration and order entry system might typically include the ADT Patient
Registration actor and an Order Placer actor.
• A departmental RIS system might typically include a Department System Scheduler
actor, an Order Filler actor, a Performed Procedure Step Manager actor, a ReportManager actor and a Report Reader actor.
• An Ultrasound system that generates echo report measurements would likely include
an Acquisition Modality actor that supports both the Scheduled Workflow Profiles
and the Evidence Documents Profile.
When an implementation has an actor supporting multiple integration profiles, the actor
is required to support logical cross-behaviors/ transactions. For example, if an
Evidence Creator supports the Post-Processing Workflow and Evidence Documents
Profiles, then the actor must generate PPS messages when creating evidence documents.
If an Image Display supports the Simple Image and Numeric Reports and Consistent
Presentation of Images Profiles, then the actor must make use of any GSPS referenced
by the Simple Image and Numeric Report when rendering the relevant images.

15 Portable Data for Imaging (PDI) Integration Profile
The Portable Data for Imaging Integration Profile specifies actors and transactions
that provide for the interchange of imaging-related information on interchange media.
The intent of this profile is to provide reliable interchange of image data and diagnostic
reports for import, display or print by a receiving actor.
This profile addresses identification of the media content’s source and the patient(where appropriate), reconciliation of data during import, and the structure of the media
contents.
The central elements of the profile are:• Reliable interchange of imaging-related information based on the DICOM
standard• A Web Content Option that provides guidelines for including web-viewable
content on media
The Web Content Option addresses the case of media containing both
DICOM-encoded objects and objects in XHTML or JPEG derived from these
DICOM-encoded objects.

15.1 Actors/ Transactions
Figure 15.1-1 diagrams the actors directly involved in this profile and the transactions
between actors.

Figure 15.1-1. Portable Data for Imaging Diagram

Table 15.1-1 lists the transactions for each actor directly involved in the Portable Datafor Imaging Profile. In order to claim support of this Integration Profile, animplementation shall perform the required transactions (labeled “R”). Transactions
labeled “O” are optional. A complete list of options defined by this Integration Profile
is listed in RAD TF-1: 15.2. Note that one of a number of actors must be grouped with
Portable Media Importer as described in RAD TF-1: 2.5.

Table 15.1-1. Portable Data for Imaging Integration Profile - Actors andTransactions

15.2 Portable Data for Imaging Integration Profile Options
Options that may be selected for this Integration Profile are listed in table 15.2-1 alongwith the Actors to which they apply. Dependencies between options when applicableare specified in notes.
Table 15.2-1: Portable Data for Imaging - Actors and Options

15.3 Portable Data for Imaging Process Flow
This section describes the typical process flow related to the use of Interchange Media.
The transaction covered is 47- Distribute Imaging Information on Media.
The following steps can be identified in this process flow:• The source actor (Portable Media Creator) writes a group of image dataset(s) and/or
the associated diagnostic report(s) onto a piece of interchange media. It is
presumed that the Portable Media Creator has access to the data from a grouped
actor, or another source outside the scope of IHE.
• The media is physically transported to a destination where the imaging-relatedinformation contained on the media will be used.
• The Portable Media Importer reads DICOM objects (images, presentation states, key
image notes, evidence documents and reports) on the media and imports them into
the local
information space. The Portable Media Importer reconciles the data as needed (e.g.,
to change the recorded Patient ID to the local Patient ID). If some classes of
DICOM objects are present on the media and cannot be imported, the Portable
Media Importer actor notifies the operator of the studies and series affected andmakes clear that they are not supported by the importing application.
• The Image Display, Report Reader, Display or Print Composer reads the objects it
supports and renders them depending on the receiver’s needs. If some objects are
not supported by the reading application it notifies the operator that those objects
are not supported.
The potential usage scenarios of the data are described in the use cases below.
15.3.1 Use Cases
This profile is not intended to provide an archival solution.
Use Case 1 - Patient/Referring Physician Viewing: Diagnostic and therapeutic
imaging data, such as images and reports, is received on media potentially serving
multiple use cases. The patient or the referring physician can view the data, either witha viewer application residing on the same media or using a web browser. This data is
not necessarily intended as a basis for diagnostic or therapeutic processes, and may justbe informative data. For security and privacy reasons, media given to a patient would
not contain data of other patients. Refer to section 15.5 for additional security
considerations.
Use Case 2 - Healthcare Enterprise Interchange: One or more patients’ data, such asimages, reports or complete studies, is received on media to enable a diagnostic ortherapeutic care process. Media data are imported at a different site, generally for the
purpose of a “second read import” or “reference import”.
• Second Read Import: Media data is imported to the Image Manager/Archive
to be read/over read. In order to avoid data conflicts, key patient/study
attributes may need to be reconciled with existing local data. Images andrelated presentation states can be sent to a Print Composer to be printed.
• Reference Import: Media data is imported to the Image Manager/Archiveand/or Report Repository to become part of the patient history. It may be
used as “relevant prior” data for future reads. In order to avoid data
conflicts, key patient/study attributes may need to be reconciled withexisting local data.
Use Case 3 - Operating Room Viewing: Media data is used to enable diagnostic ortherapeutic processes in environments without a reliable network connection. The
volume of data can be very large and may contain image data, post-processing results
and reports. In the operating room, the surgical staff receives the media and reads its
contents using advanced viewing capabilities, which may include manipulating orprocessing images.
15.3.2 Process Flow Description
The use cases can be specified in terms of three media-related activities:• Media Export• Media Viewing• Media ImportMedia Export (All Use Cases):
The Portable Media Creator assembles the media content (DICOM and web-viewable
content) and writes it to the physical medium.
The following sequence of activities will be performed during media creation:• Export of DICOM data (FSC activity)• Optionally, export of web-viewable data, which involves deriving easily accessible
informative data from the DICOM data (Web Content Option).
• Optionally, inclusion of additional content (e.g.: a DICOM Viewer or viewing
software components on the media to access DICOM data)B) Media Viewing:
B1) Web (Use Case 1) (care providers, other users and patients without DICOM
viewing equipment or software):Any web-viewable media content is received and displayed by a Display actor,
which exists as a generally available resource (i.e. web browser). Note that thePortable Media Creator cannot rely on the presence of web-viewable content on
all media since it will be included only on media created using the Web Content
Option).

B2) DICOM (Use Case 1 and 3) (users with DICOM viewing equipment orsoftware):
The DICOM portion of the media content is displayed using specialized
applications pre-existing in the reading environment or included on the media
itself. The variety of DICOM objects that an Image Display and/or Report Reader
actor can process is indicated by its support of the corresponding content profiles.
The Print Composer actor sends images from the media to a Print Server for
printing.
C) Media Import (Use Case 2):
The “Media Import” activity is accomplished by a Portable Media Importer and deals
exclusively with the DICOM portion of the media content. The Portable Media
Importer actor is grouped with one or more content actors (Evidence Creator, ReportCreator, etc.), depending on the type of media content to be imported. The grouped
actor provides storage capability for the media data accessed by the Portable Media
Importer.
The Portable Media Importer actor accesses all DICOM instances referenced by the
DICOMDIR file and enables the user to select a media patient dataset to be imported.
The Portable Media Importer obtains local data that is known to be accurate within theimporting institution/enterprise and reconciles “key attributes” of patient and study
information (when required). A method for performing these steps is documented in
the Import Reconciliation Workflow Profile (see Section 3.21). Refer to RAD TF-3:
4.47.4.1.3. for the list of “key attributes” and the related reconciliation actions to be
performed.
Note: The Portable Media Importer may for example be grouped with an Evidence Creator toallow the storage of its diagnostic and therapeutic imaging content to an Image Manager/Image
Archive, or grouped with a Report Creator to store reports an a Report Repository. This enables
use of the content for subsequent “relevant prior” data for future reads. A grouping with an
Acquisition Modality actor could also be used to allow subsequent “reads/over reads”. In thecase of a Portable Media Importer grouped with the Print Composer actor, the imported content(images and presentation states) can be sent to the Print Server to be printed.

Figure 15.3.2-1 shows an example flow of events covering the use cases described in
the previous sections.

Figure 15.3-2-1. Portable Data for Imaging Process Flow

15.4 Media Content
The requirements on media content are intended to promote the reliable transfer ofimaging data, including diagnostic reports, and to allow for the viewing of images andreports on general purpose computers.
The media content can be accessed via two "entry points" on the media: theDICOMDIR file for DICOM imaging information and optionally the INDEX.HTM filefor web-viewable content. Created media are required to contain DICOM data and may
optionally include web-viewable data derived from it. This web-viewable data, if
present, shall faithfully preserve the clinical intent of the original DICOM information.

15.4.1 DICOM Content
The DICOM data shall be created by using the DICOM General Purpose Media
Storage Application Profile. The DICOMDIR file shall reference all DICOM files
stored on the media.
DICOM files shall not be placed in the root directory, but no constraints are placed on
the name of directory that contains them.

15.4.2 Web Content Option
Portable Media Creators implementing the Web Content Option may also include
web-viewable data on the media.
The web-viewable data shall be derived from the DICOM information as XHTML files
and referenced JPEG images. The XHTML entry page (INDEX.HTM) shall allow
access to all of this data. This enables end-users to access relevant media content using
a generally available web browser. The INDEX.HTM file shall be placed in the root
directory.
Note that the web-viewable data specified in this integration profile reflects the full setof the exported DICOM data or a subset considered at the time of creation to faithfully
represent the patient's clinical condition. For example, if a DICOM Structured Reportreferences only Key Images and a larger DICOM dataset, the web-viewable data
derived from it may selectively include the report in XHTML format and only JPEG
images derived from the DICOM Key Images.

15.4.3 Other Content
Viewing applications (for example a DICOM Media Viewer) may optionally be
included on the media. Such viewers may have launch links included in the HTML.
Including such viewers on the media is discouraged due to security issues discussed in
the next section, as well as potential interoperability problems.
Additional data (e.g., a diagnostic report in non-DICOM format) may be also included
on the media. Since the format of any such data is not specified by this profile, suchdata shall be placed in a separate directory on the media. If such data is referenced in
the INDEX.HTM file, it shall be clearly indicated that this content was not generated inconformance with the IHE Radiology Technical Framework, and its reliable import has
not been addressed.

15.5 Security and Privacy Aspects
Portable Media Creator actors shall ensure that no malicious software (viruses, etc.) ispresent on created media.
The automatic launch of applications from media poses a risk that malicious software
could be started and it is recommended that media reading actors not allow automatic
launching. Portable Media Creators should therefore also avoid using automatic
launching. This includes not automatically launching a DICOM media viewer that may
be present on the media.
Furthermore, if a DICOM media viewer is present, security issues are minimized by:• working under normal (restricted) user privileges and not requiring the user towork with administrator or root privileges and• not needing software installed on the computer where the media is used.
Audit trails to track export/import/viewing activities are addressed in RAD TF-3:
4.34.1.1.1.15 and 4.34.1.1.1.H. Portable Media Creator and media reading actors thatclaim support of the Basic Security Integration Profile shall generate such audit trail
entries.
Encryption of data and other access controls to media content are not addressed in thisprofile. Media created using this profile should be considered to be unlocked
information (e.g., like paper records). Such media should be handled according toappropriate site policies (e.g., do not give a patient a disk containing data from other
patients, do not leave disks where they can be taken by unauthorized persons, etc.).
For many Use Cases it is not appropriate to place data from multiple patients on asingle media for Security and Privacy Reasons.

4 IHE Transactions
This section continues the definition of each IHE transaction in detail, specifying thestandards used, the information transferred, and the conditions under which thetransaction is required or optional. See Volume II, section 4 of the IHE Technical
Framework for description of Transactions RAD-1 through RAD-31.

4.47 Distribute Imaging Information on MediaThis section corresponds to Transaction RAD-47 of the IHE Technical Framework.
Transaction RAD-47 is used by the Portable Media Creator and by media reading
actors (Portable Media Importer, Image Display, Report Reader, Display and Print
Composer).
4.47.1 Scope
In the Distribute Imaging Information on Media transaction the Portable Media Creator
sends information to media reading actors by means of Interchange Media where it
stores the information.
4.47.2 Use Case Roles

Actor: Portable Media Creator
Role: Assemble the media content and store it on the media to be distributed.
Actor: Portable Media Importer
Role: Read the DICOM content of distributed media in order to access information
stored in the DICOMDIR file and its referenced instances (DICOM FSR) and perform
import of media data.
Actor: Image Display
Role: Read the DICOM content of distributed media in order to access information
stored in the DICOMDIR file (DICOM FSR) and display its referenced evidence
objects.
Actor: Report Reader
Role: Read the DICOM content of distributed media in order to access information
stored in the DICOMDIR file (DICOM FSR) and read its referenced diagnostic reports.
Actor: Print Composer

Role: Read the DICOM content of distributed media in order to access information
stored in the DICOMDIR file (DICOM FSR) and send print data (images) to the Print
Server.
Actor: Display (from ITI TF)
Role: Read the web-viewable content of distributed media in order to accessinformation stored in the INDEX.HTM file and display its referenced data (XHTML
files and JPEG images).
4.47.3 Referenced Standard
DICOM 2007 PS 3.10: Media Storage and File Format for Data Interchange
DICOM 2007 PS 3.11: Media Storage Application Profiles
DICOM 2007 PS 3.12: Media Formats and Physical Media for Data Interchange
DICOM Supplement 80 (final text): DVD Media Application Profiles
XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition). A
Reformulation of HTML 4 in XML 1.0. W3C Recommendation 26 January 2000,
revised 1 August 2002. http://www.w3.org/TR/xhtml1.
XHTML™ Basic. W3C Recommendation 19 December 2000.
http://www.w3.org/TR/xhtm-basic.

4.47.4 Interaction Diagram

4.47.4.1 Distribute Imaging Information on MediaThis transaction consists of the interchange of information on media by way of thephysical transport of the created media from the Portable Media Creator to a
media-reading actor.
4.47.4.1.1 Trigger Events
The user at the Portable Media Creator wishes to transport information by the creationand transport of interchange media. The Portable Media Creator assembles theInterchange Media content and stores it on the media.
4.47.4.1.2 Message Semantics
The message semantics of this transaction are described in terms of content
specifications for the media.
The Portable Media Creator shall be able to include all DICOM objects supported by
the IHE actors with which it is grouped. If not grouped with any IHE actors, it shall beable to include all DICOM Storage objects listed in its DICOM Conformance
Statement.
4.47.4.1.2.1 Media Filesystem and File Naming Restrictions
Since the DICOM content on the media is required to conform to the DICOM standard,some of the requirements specified in PS 3.10, 3.11 and 3.12 are reiterated here for
emphasis:• Strict ISO 9660 Level 1 compliance• No packet writing• File and folder names referenced by the DICOMDIR file restricted to 8 characters,

uppercase letters, digits and underscore only, with no extension
Specifically, it is not permitted to name DICOM files based on their SOP Instance UID,
since that would exceed the 8 character limit and use the illegal period character, and it
is not permitted to add a “.dcm” extension or similar. Filenames should not be in lower
case, nor have lower case equivalent file names encoded as Joliet or Rockridge
extensions to the ISO 9660 filesystem.
Refer to Appendix E of this supplement for a reference to common implementation
misinterpretations and/or errors that are detrimental to interoperability.
Non-DICOM data is restricted to ISO 9660 Level 1 compliance, but without the
restrictions on file extensions and characters imposed by DICOM; i.e. a 3 character
extension is permitted.
4.47.4.1.2.2 Content Organization Overview
The following diagram illustrates the content organization principles (see Appendix F
for examples):Figure 4.47.4.1.2.2-1. Media Content Organization

Description of the content to be contained in the media file system:
4.47.4.1.2.2.1 DICOM Content
The DICOMDIR file shall be located in the root directory and shall reference all
DICOM instances contained in the media.
The DICOM instance files shall not be in the root directory or in the IHE_PDI
sub-directory, instead they shall reside in a sub-directory whose name is not otherwise
constrained.
It is recommended, though not required, to include the README.TXT file described
below, even if the Web Content Option is not supported.
4.47.4.1.2.2.2 Web Content Option
Portable Media Creators implementing the Web Content option shall meet thefollowing requirements:• INDEX.HTM file located in the root directory, which shall portray the exactcontent of the interchange media. The file shall present:• An informative header containing:• Identification of the institution that created the interchange media• Optionally, a disclaimer statement about privacy/security from theinstitution that created the interchange media• a link to an entry point for accessing the web content of the IHE_PDI
directory• a link to the README.TXT file
• a link to additional non-constrained data (if it exists) - See 4.47.4.1.2.2.3• a manifest which lists the data that can be imported by a Portable Media
Importer Actor. (i.e., all DICOM content on the media)• a manifest which lists any patient-related data contained on the CD thatcannot be imported (i.e., additional non-constrained content that doesn’t
have an importable DICOM equivalent on the media).
• a link to a launch point for a DICOM viewer, if present on the interchange
media
Note: The file INDEX.HTM is required to present the content defined above to the user. This does not
imply that the information must necessarily be contained in INDEX.HTM. Instead, INDEX.HTM mightalso open a frame set consisting of additional XHTML files that in total contains the information
specified above.

• README.TXT file located in the root directory, that shall contain:• Contact information regarding the Institution that created the media.
• Information regarding the Application that created the media.
• Name of the product application and software version• Contact information of the vendor of the application that created themedia• General information about the overall organization of the interchange media.
This is not intended to be specific to the content stored on this instance ofinterchange media, which if necessary should be placed in the INDEX.HTM
file.
• Information regarding the Media Viewer application (if a Media Viewer iscontained)• Operating system(s) supported• Name of the product application and software version• Contact information of vendor that provided the Media Viewer

application• Disclaimer statement about the intended usage of the application• List of minimum requirements• Additional information regarding the usage of the application
Note that generally the README.TXT file is independent of the clinical content of the media, i.e. thesame README.TXT may be included on all media created by that application at that institution.
It is recommended that information is included in the README.TXT file about web browsers (including
version number) that are known to be capable of displaying the web content as intended.

• IHE_PDI directory located in the root directory of the interchange media whichshall contain:• Web-viewable objects in XHTML, JPEG, PNG and/or GIF derived from the
DICOM encoded objects or used for web page navigation.
• The web content shall faithfully represent the patient's clinical condition.
• It is not allowed to place any other data in the IHE_PDI directory.
• It is allowed to have sub-directories within the IHE_PDI directory
Note that these are IHE requirements (not DICOM requirements) that are intended to facilitate theoverall organization of the media and make easier the access to the INDEX.HTM file, especially for
non-expert users like patients and referring physicians.
Note: There is a recognized need for cine/video data, however a standardized method (format) has
not yet been identified for endorsement by IHE and inclusion in this transaction.

4.47.4.1.2.2.3 Optional Content
It is permitted to place other optional data on the media outside the IHE_PDI directory,
but any additional content shall take into account all constraints listed above.
Furthermore any additional directory cannot begin with “IHE”.
Additional files (files other than mandatory files) in the root directory are not expressly
prohibited however their inclusion is discouraged.
Note that it cannot be assumed that any automatically launching application will run on
the receiving device.
4.47.4.1.2.2.3.1 DICOM Media Viewer
If a DICOM media viewer is present on the media, it is recommended that:• the media viewer be capable of correctly rendering all DICOM objects stored
on the medium.
• a user manual in PDF format be included on the medium, in the root
directory.
• a short manual in hardcopy be provided within the CD jewel case.
4.47.4.1.2.2.4 Media Identification
The Portable Media Creator actor shall support a user in adding human-readable
identification information on the outside of the physical medium. The method of media
marking is outside the scope of this integration profile.
It is recommended that the Patient Name, patient ID, birthdate, media creation date, thestudy dates for the studies on the medium and the name of the originating institution bemarked on the medium. It is also recommended that the type of content (“DICOM
ONLY” or “DICOM PLUS WEB”) be marked on the medium.
4.47.4.1.2.3 Content Organization Detail4.47.4.1.2.3.1 DICOM Content
The DICOM portion of the media content is defined by the current DICOM standard. It
is required that created file-sets be correctly formatted in order to grant maximum
interoperability.
All DICOM data shall be referenced by the DICOMDIR file.
In order to assure interoperable use of the created media, a “widely-used” general
purpose DICOM Media Application Profile is required. The Portable Media Creator,
Portable Media Importer, Image Display, Report Reader and Print Composer shall use
the STD-GEN-CD Media Storage Application Profile to interchange DICOM
information on interchange media.
The Portable Media Creator is not required to be able to create media containing datafrom multiple patients. However, all media reading actors shall be able to import media
containing multiple patients’ data.
While the Portable Media Creator is not required to correct DICOM SOP instancesfrom a source that incorrectly encodes the DICOM data, it is expected that the DICOMMedia Creator will store the DICOM files in Explicit VR Little Endian. The
DICOMDIR, whose content is entirely the responsibility of the Portable Media Creator,
shall be correctly encoded regardless of the correctness of any referenced SOP
Instances.
The Portable Media Creator may be requested to include DICOM SOP Instances that

do not contain sufficient information to encode mandatory DICOMDIR information.
For example, Patient ID and Study ID are Type 2 and may be zero length in image SOPInstances, but are Type 1 in the Patient and Study Directory Records. The Portable
Media Creator is required to synthesize appropriate values for all such mandatory
attributes. No specific guidance is given as to from whence appropriate values should
be obtained or what default values are appropriate, except that different patients,
studies, and series must remain distinct (e.g., two different Studies with differing Study
Instance UIDs shall not be assigned the same synthesized Study ID).
4.47.4.1.2.3.1.1 DICOM Instances Content
There are no additional requirements specified here on the Attributes contained within
DICOM Instances on the media.
If the Portable Media Creator Actor is grouped with an Acquisition Modality (or other)
Actor within the Scheduled Workflow Integration Profile, then the attributes may
effectively be constrained beyond the normative requirements of the DICOM standard.
For example certain attribute values in the Modality Worklist query shall be included.
However, since such grouping is not required under this profile, actors receiving
created media such as the Portable Media Importer, Image Display, Report Reader and
Print Composer may not assume that the DICOM Instance Attributes are constrained
beyond the definitions of the IODs in the DICOM Standard.
The instances on the Interchange Media generated by a Portable Media Creator shall all
be DICOM Composite IODs. Therefore the Interchange Media shall not containinstances from the following SOP Classes:• Detached Patient Management SOP Class• Detached Study Management SOP Class• Detached Visit Management SOP Class• Study Component Management SOP Class• Modality Performed Procedure Step SOP Class• Detached Result Management SOP Class• Detached Interpretation Management SOP Class• Stored Print Storage SOP Class
4.47.4.1.2.3.1.2 DICOMDIR Directory Content
There are no additional DICOMDIR keys required beyond those required by the
DICOM STD-GEN-CD specification.

No private elements shall be included in the standard directory records and no private
directory records shall be present.
The following types of Directory shall not be used in the Basic Directory object(DICOMDIR File):• VISIT,• RESULTS,• INTERPRETATION,• STUDY COMPONENT,• STORED PRINT• TOPIC• PRIVATEThe PATIENT, STUDY, SERIES Directory Records shall follow the following rules:• Only one Directory Record per Patient ID shall be present in the DICOMDIR.
• Only one STUDY Directory Record per Study Instance UID shall be present in
the DICOMDIR; this implies that a study belongs to a single patient.
Only one SERIES Directory Record per Series Instance UID shall be present in the
DICOMDIR; this implies that a series belongs to a single study.
• Only one composite instance level Directory Record shall be present per SOP
Instance UID; this implies that an instance belongs to only a single series.
• Only one HL7 STRUC DOC Directory Record shall be present per SOP Instance
UID; this implies that an instance belongs to only a single Patient.
• Only one HANGING PROTOCOL Directory Record shall be present per SOP
Instance UID
Users should review the supported Media Storage SOP Classes in the Conformance
Statements of media creators and readers to ensure interoperability in the interchangeof media objects.
4.47.4.1.2.3.1.3 DICOM Report Content
It is highly recommended to place diagnostic reports on the media.
The Portable Media Creator actor, if grouped with a Report Creator actor, shall support
the ability to create a diagnostic imaging report. A Basic Text DICOM SR, according

to a proper subset of the Simple Image Report Pattern as defined by the SINR
Integration profile, can be created and this kind of diagnostic report can be imported bya Portable Media Importer.
Additional optional diagnostic reports in non-DICOM formats (such as HL7 CDA) are
not defined by this transaction and may be placed on the media without the need tocreate DICOM SRs, but they will be non-importable data.
Note: This requirement may be met with other DICOM SR SOP Classes that are used for diagnostic ortherapeutic reports. For the most basic radiology report, a simple pattern with one or more sections
including a paragraph of text meets this requirement. Image references do not have to be included,
but may be if so desired.

4.47.4.1.2.3.2 Web Content Option
Portable Media Creators claiming the Web Content option shall meet the following
requirements:
End-users should be able to access information at a minimum using a web browser toview content on media. In order to grant maximum interoperability using the stored
XHTML files, they shall be formatted according to the XHTML Basic and W3C
HTML Compatibility Guidelines provided in Appendix C of the W3C XHTML 1.0
Recommendation.
The web-viewable data that is generated by Portable Media Creators claiming the Web
Content option shall:• contain the web representation of a subset of the media’s DICOM information,using only XHTML files, JPEG referenced images, and PNG and/or GIF files
used for navigation,• contain hyperlinks within XHTML files which contain only lowercase letters topromote interoperability across O/S Platforms,• reside in the IHE_PDI, while the corresponding DICOM data from which it isderived is located in a different sub-directory (see 4.47.4.1.2.2.1), and• be completely referenced in the INDEX.HTM file
The web-viewable data included shall be a set or subset that was considered at the timeof creation to faithfully represent the patient's clinical condition.
If the Portable Media Creator supports Presentation States, it shall have the capability
to apply them to the relevant images when including web-viewable content. The user of
the application may choose not to make use of this capability.

The constraints placed by DICOM on the ISO 9660 file system are not required forweb-viewable content, i.e. a 3-character extension is permitted.
To ensure interoperability, JPEG means a file with a JFIF header and encoded using
the sequential Huffman DCT 8bit per component process (baseline), and theprogressive variant thereof.
To ensure interoperability the use of XHTML shall be limited to static and restricted
forms of dynamic web content. At this time Dynamic Web Content such as DHTML,
Cascading Style Sheets and most Scripting Languages are explicitly prohibited as no
single established Standard exists to ensure interoperability between web browsers.
The use of JavaScript is explicitly permitted, recognizing that there may be issues withdifferent browsers. Portable Media Creators should make every effort to use portable
constructs or use JavaScript that works with or adapts to all known portable browsers ;further, the failure of JavaScripts should not make the resulting web pages unusable.
Additional optional web-viewable content not derived from DICOM objects may be
stored on the media, but not in the IHE_PDI directory.
4.47.4.1.3 Expected Actions
The receiving/reading actors read the patient’s data from the media and act upon it as
specified below. The receiving actor shall document which DICOM objects it supports
in its Conformance Statement. If a SOP Class on the media is not supported, the actor
shall present the user with a summary of the data that could not be acted upon,
containing the Patient Name(s) and ID(s), Study ID(s), Study Date(s), Study and Series
Description(s) and Modality as obtained (if present) from the DICOMDIR file.
The automatic launching of applications is not expressly prohibited on media
interchanged within this profile; its use is discouraged, however.
To facilitate avoidance of malicious software, receiving actors (Portable Media
Importer, Image Display, Report Reader, Print composer and Display) are not required
to launch automatically running applications present on media.
4.47.4.1.3.2 Image Display
The Image Display reads the DICOM image data from the media and provides the user
with the ability to view all studies (that it supports) contained on the media. GSPS
objects and Key Image Notes are read from the media and applied if the Consistent
Presentation of Images and the Key Image Notes IHE Integration Profiles aresupported. The Image Display actor may optionally be grouped with other actors whichview other evidence objects.

4.47.4.1.3.3 Report Reader
The Report Reader reads the DICOM SR Reports from the media and may process
them (based on the SR object classes it supports). At a minimum, it provides the user
with the ability to view all reports per the DICOM SR SCP requirements.
4.47.4.1.3.4 Portable Media Importer
The Portable Media Importer reads DICOM data from the media. Together with theactor with which it is grouped (see vol. 1), it shall be able to perform key attributereconciliation. Reconciliation may not be required in all cases (e.g., within the same
importing institution/enterprise). Refer to Table 4.47.4-1 for key attributes to bereconciled. Import Reconciliation Workflow provides a workflow to reconcile key
attributes (See Section RAD-TF 1:3.59). Note that the Referenced Study Sequence andRequested Attributes Sequence are removed for consistency with behavior of theunscheduled cases in SWF and PIR.
The grouped actors provide the capability of storing the supported DICOM objects to
an Image Manager/ Image Archive (for image objects like Images, Presentation States,
Key Image Notes, Evidence Documents), or to a Report Repository (for Diagnostic
Reports).
Table 4.47.4-1 Media instances - Key attributes to be reconciled

Note 1: The manner in which the Portable Media Importer receives the ADT value is beyond the scopeof this profile.
Note 2: Handling of Coded information is beyond the scope of this Integration Profile.

4.47.4.1.3.5 Print Composer
The Print Composer reads the DICOM image data from the media and provides ameans to print it.
4.47.4.1.3.6 Display
The Display actor (defined in the IT Infrastructure TF) reads the web-viewable
information from the media and displays it. Note that the web-viewable content will
only be present if the Portable Media Creator involved supports the Web Content
Option.

Appendix E: DICOM Media Interchange – Critical DICOM
Compatibility Tips
This appendix presents a number of compatibility issues that result from not following
the DICOM Media Interchange standard (PS 3.10, PS 3.11 and PS 3.12). This appendix
is simply intended to be a reminder for the most common DICOM issues that haveresulted in the past in incompatibilities between file set creators and readers.
This list shall not be interpreted, as being the only DICOM requirements that
implementers should pay attention to. DICOM has proven to be a very effective andthorough specification that implementers of this IHE profile shall be familiar with.
1. The CD Media shall be formatted according to ISO 9660 Level 1. (Extensions
such as Joliet or Rock Ridge are not forbidden by DICOM and hence are
permitted by the PDI profile., nor a A UDF file system are is not allowed
unless an ISO 9660 Level 1 Filesystem is also present). Such extensions may
be necessary to encode non-DICOM content on the media, such as long
filenames for viewing software. Such extensions may result in ISO 9660
Level 1 uppercase filenames being presented to application software as
lowercase or mixed case depending on the operating system’s mountbehavior; accordingly, all Portable Media Displays and Portable Media
Importers shall be case insensitive in this respect.
2. The DICOMDIR file shall be at the root directory of the Interchange Media
3. All DICOM file names (DICOM files as well as non-DICOM Files) shall contain
only uppercase letters, numeric digits and the underscore character, and. tThe
file name size without extensions shall not exceed 8 characters.
4. All Directory names in DICOM paths shall contain only uppercase characters,
numeric digits and the underscore character. Directory names shall notcontain extensions.
5. Non-DICOM files shall notmay have extensions with more than 3 characters(ISO 9660 Level 1).
6. DICOM files shall have no extension.
7. DICOM files shall have an ISO 9660 version of 1, which may be displayed bysome operating systems as a ".;1" at the end. However, the ".;1" should not be
included in the name of the file itself.
8. The version number of the file name shall not be included in the reference data
element in the DICOMDIR.
9. Only 8 levels of Directories are allowed, including the root directory (i.e. theremay be up to 7 levels of sub-directories below the root).
10. Objects in DICOM files shall be stored in Explicit VR Little Endian (notImplicit)
11. DICOM File Meta-Information shall be in Explicit VR Little Endian (notImplicit)
12. File Meta Information Version (0002,0001) shall contain a two byte OB value
consisting of a 0x00 byte, followed by 0x01 byte, and not the value 0x0001
encoded as a little endian 16 bit short value, which would be the other way
around.
13. The file meta information shall include the Media Storage SOP Class UID(0002,0002) data element, and its value shall be equal to the SOP Class UID
data element in the data set.
14. The file meta information shall include the Media Storage SOP Instance UID(0002,0003) data element, and its value shall be equal to the SOP Instance
UID data element in the data set.
15. No private elements shall be included in the file meta information.
16. The file meta information header shall contain an attribute (0002,0000) Group
Length with a correct value as specified in DICOM PS 3.10.
17. The physical format of the DICOM CD-R discs shall comply with theapplication definitions within ISO/IEC 10149 Part II as specified in PS3.12.
This allows discs to be written with• Mode 1 sectors or• Mode 2, Form 1 sectors with CD-ROM-XA File Number = 0, Channel Number= 0 and Coding Information Byte = 0.

Appendix F: Example Created Media Instance Content
Example F-1. Media containing a DICOM CT imaging study, a DICOM
Presentation States and a DICOM Structured Report. The creator supports
the Web Content Option and includes web-viewable data derived from DICOM
data on the media. Also a DICOM Viewer is included on the media.

Example F-2. Media containing a DICOM US imaging study and a DICOM SR
diagnostic report. The creator does not support the Web Content Option but
chose to optionally include the README.TXT file. No web-viewable data
derived from DICOM data is included on the media.