IHE Radiology Technical Framework Supplement 2005 · PDF fileIHE Radiology Technical Framework Supplement 2005-2006 ... partially supported, while still others may require future IHE
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
ACC, HIMSS and RSNA Integrating the Healthcare Enterprise
5
10
15
IHE Radiology Technical Framework
Supplement 2005-2006
Cross-enterprise Document Sharing for Imaging (XDS-I)
Trial Implementation Version Publication date: August 15, 2005
Foreword Integrating the Healthcare Enterprise (IHE) is an initiative designed to stimulate the integration 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 a technical framework for the implementation of established messaging standards to achieve 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 this framework 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, HL7, DICOM, IETF, and others, as appropriate in their respective domains in an integrated manner, defining configuration choices when necessary. IHE maintain formal relationships with several standards bodies including HL7, DICOM and refers recommendations to them when clarifications or extensions to existing standards are necessary.
This initiative has numerous sponsors and supporting organizations in different medical specialty domains and geographical regions. In North America the primary sponsors are the American College of Cardiology (ACC), the Healthcare Information and Management Systems Society (HIMSS) and the Radiological Society of North America (RSNA). IHE Canada has also been formed. IHE Europe (IHE-EUR) is supported by a large coalition of organizations including the European Association of Radiology (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 la Modernisation du Système d'Information Hospitalier (GMSIH), Société Francaise de Radiologie (SFR), Società Italiana di Radiologia Medica (SIRM), the European Institute for health Records (EuroRec), and the European Society of Cardiology (ESC). 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 the Japan 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.
The IHE Technical Frameworks for the various domains (IT Infrastructure, Cardiology, Laboratory, Radiology, etc.) defines specific implementations of established standards to achieve integration goals that promote appropriate sharing of medical information to support optimal patient care. It is expanded annually, after a period of public review, and maintained regularly
through the identification and correction of errata. The current version for these Technical Frameworks may be found at www.ihe.net or http://www.himss.org/IHE.
60
65
The IHE Technical Framework identifies a subset of the functional components of the healthcare enterprise, called IHE Actors, and specifies their interactions in terms of a set of coordinated, standards-based transactions. It describes this body of transactions in progressively greater depth. The volume I 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 provide detailed technical descriptions of each IHE transaction.
This supplement to the Radiology Technical Framework is issued for Trial Implementation through March 2006, per the schedule announced in February 2005.
Comments and change proposals arising from Trial Implementation may be 70 submitted to:
http://forums.rsna.org under the “IHE” forum Select the Radiology Supplements for Public Review sub-forum.
75 The IHE Radiology Technical Committee will address these comments resulting from
implementation, connect-a-thon testing, and demonstrations. Final text is expected to be published in May 2006.
These ”boxed” instructions for the author to indicate to the Volume Editor how to integrate the relevant section(s) into the overall Technical Framework 80
85
90
95
100
105
110
1 Introduction
Background Documents and data representing a patient’s medical record are generated and archived on a variety of systems over the course of diagnosis and treatment.
Many imaging and clinical activities would benefit from a coordinated method for “sharing”, locating and accessing relevant imaging related documents. Images, diagnostics reports, and evidence documents derived from the processing of images represent important components of a patient’s medical record. However, they are managed and archived on a variety of imaging information systems such as RIS and PACS over the course of diagnosis and treatment. For the same patient some of this imaging information is produced in departments associated with one or more in-patient facilities (where the patient may have been hospitalized), as well as independent imaging centers. A number of healthcare delivery professionals (e.g., referring physicians, radiologists, surgeons, oncologists, etc.) would benefit from a coordinated method for locating and accessing relevant imaging information. The creation and subsequent usage of these documents may span several care delivery organizations and may be performed separately over different time periods.
IHE IT Infrastructure has released the Cross-Enterprise Document Sharing (XDS) profile. It provides an integration solution to the problem of general-purpose document sharing in a broad healthcare environment.
This profile specifies sharing of imaging “documents” such as radiology images and reports; it presents a solution for sharing imaging documents based on XDS. XDS-I extends XDS by sharing, locating and accessing DICOM instances from its original local sources, e.g. for radiologists or oncologists. Even though this profile may be useful for sharing cardiology documents, cardiology specific use cases have not been addressed as the cardiology technical committee intends to address this topic in the near future.
Since the XDS for Imaging Profile relies so heavily on the IT Infrastructure XDS Profile including the use of terms defined in XDS (e.g., affinity domain, submission set, etc.) the reader of XDS-I is expected to have read and understand the XDS Profile (See ITI TF-1: 10).
Proposed Solution The Cross-Enterprise Document Sharing (XDS) Profile in the IHE IT Infrastructure Domain is used and adapted to meet the imaging information sharing use cases. New XDS document types and actor capabilities are defined based on the standard artifacts of Radiology. The XDS design
principle that one single registry is a single query/ access point and holds the indexing data about all documents that are available from multiple repositories in the Affinity Domain, is the key point here.
The information to be shared includes one or more of the following:
1. Imaging studies that include images acquired on a broad range of different modalities, as well as evidence documents (e.g. post-processing measurements/analysis outcome), and presentation states.
2. Diagnostic reports resulting from the interpretation of one or more related imaging studies provided in a ready-for-display form.
3. A selection of diagnostically significant images associated with the report content.
Scope of Supplement This profile considers “imaging information sharing” in the sense of making imaging work products available to be shared by other authorized members of an affinity domain. This is intended to exclude (for now) the handshaking, notifications and immediate availability of intermediate work products necessary to co-ordinate workflows between the imaging departments of different enterprises (e.g. federated PACS/RIS where the acquisition and reading is distributed among independent enterprises, regional archiving serving multiple PACS, home on-call tele-radiology, etc.). IHE Radiology may address such workflows in the future.
Connecting the sharing of imaging information across enterprises with intra-enterprise workflows seems to be an important issue, but one that is related more to the intra-enterprise IHE Integration Profiles (e.g. Scheduled Workflow, Reporting Workflow) than to the data transfer necessary for sharing information across enterprises.
A number of conventions, such as the use of coded concepts in the XDS Registry, can be established as policies by an Affinity Domain or by Regional IHE Extensions. XDS sharing concepts such as Submission Sets and folders should be used as basic tools for organization.
Both the XDS and XDS for Imaging Integration Profiles are not intended to address all cross-enterprise EHR communication needs. Some scenarios may require the use of other IHE Integration profiles, such as Patient Identifier Cross-Referencing (PIX), Audit Trail and Node Authentication (ATNA), Enterprise User Authentication (EUA), Cross-enterprise User Authentication (XUA) and Retrieve Information for Display (RID). Other scenarios may be only partially supported, while still others may require future IHE Integration profiles, which will be defined by IHE as soon as the necessary base standards are available. Specifically:
1. The operation of any XDS-I Clinical Affinity Domain will require that a proper security model be put in place. It is expected that a range of security models should be possible. Although the XDS-I Integration Profile is not intended to include nor require any specific security model, it is expected that XDS-I implementers will group XDS-I Actors with actors from the IHE Audit Trail and Node Authentication and will need an
Access Control capability that operates in such a cross-enterprise environment. New IHE Integration Profiles have been identified as candidates (e.g. Public Key Infrastructure, Access Control, etc.). There is a discussion of XDS-I security considerations in RAD TF-1: Appendix X2.
2. The establishment of independent but consistently XDS-based Affinity Domains will call for their federation, as patients expect their records to follow them as they move from region to region, or country to country. IHE foresees a need for transferring information from one Clinical Affinity Domain to another, or to allow access from one Affinity Domain to documents managed in other Affinity Domains. XDS/ XDS-I has been designed with this extension in mind. An XDS/ XDS-I Domains Federation Integration Profile that complements XDS may be anticipated in the future.
3. XDS and XDS-I do not address transactions for the management or configuration of a clinical affinity domain. For example, the configuration of network addresses or the definition of what type of clinical information is to be shared is specifically left up to the policies established by the clinical affinity domain.
4. XDS and XDS-I do not specifically address the patient information reconciliation process necessary between the Clinical Affinity Domain and any other local patient identity domains that Document Sources and Document Consumers may be members of. For a discussion of some of these issues see RAD TF-1: Appendix X1.
Profile Abstract This Supplement introduces a new IHE Integration Profile known as the Cross-enterprise Document Sharing for Imaging (XDS-I) Profile that facilitates the sharing of Imaging Information across health enterprises. Imaging Information includes sets of DICOM instances, diagnostic reports provided in a ready-for-display form and a selection of diagnostically significant images associated with the report content.
In this context, sharing means making imaging information available in accessible repositories and registering them in a central registry. A registry query provides consumers with the details necessary to retrieve relevant data.
This Integration Profile provides specifications for managing the sharing of imaging information that healthcare enterprises (anywhere from a private physician to a clinic to an acute care in-patient facility) have decided to share in an Affinity Domain. This defines the imaging component of a shared longitudinal Electronic Health Record.
Since the XDS for Imaging Profile relies so heavily on the IT Infrastructure XDS Profile including the use of terms defined in XDS (e.g., affinity domain, submission set, etc.) the reader of XDS-I is expected to have read and understand the XDS Profile (See ITI TF-1: 10).
185 Volume I – Integration Profiles Changes to Sections 1 – 1.X
1.7 History of Annual Changes Add the following item to the bullet list in volume 1, section 1.7
• Added the Cross-enterprise Document Sharing for Imaging (XDS-I) Profile that specifies actors and transactions allowing users to share across enterprises sets of DICOM instances, imaging reports in a “ready-for-display” format, as well as significant images in non-DICOM format.
190
Cross-enterprise Document Sharing for Imaging Integration Profile Dependencies
195
200
Add the following row to the Profile Dependency table in volume 1, section 2.x
Table 2-1 defines the required dependencies between the Integration Profiles in a tabular form.
Table 2-1 Cross-enterprise Document Sharing for Imaging Integration Profiles Dependencies
Integration Profile Depends on Dependency type Comments
… … … …
XDS for Imaging
IT Infrastructure XDS
Document Consumer, Document Registry, Document Repository actors are required to support XDS
Document content types and metadata are specialized.
Integration Profiles Overview Add the following to 2.1 Integration Profiles overview
2.1.X Cross-enterprise Document Sharing for Imaging (XDS-I)
205
210
The Cross-enterprise Document Sharing for Imaging (XDS-I) Integration Profile specifies actors and transactions that allow users to share imaging information across enterprises. This profile depends on the IHE IT-Infrastructure Cross-Enterprise Document Sharing (XDS) profile. XDS for Imaging (XDS-I) defines the information to be shared such as sets of DICOM instances (including images, evidence documents, and presentation states), diagnostic imaging reports provided in a ready-for-display.
Since the XDS for Imaging Profile relies so heavily on the IT Infrastructure XDS Profile including the use of terms defined in XDS (e.g., affinity domain, submission set, etc.) the reader of XDS-I is expected to have read and understand the XDS Profile (See ITI TF-1: 10).
Add the following to 2.2 Actor Descriptions
2.2 Actor Descriptions 215
220
225
230
Imaging Document Source - The Imaging Document Source actor is the producer and publisher of imaging documents. It is responsible for providing imaging documents and meta-data to the Document Repository actor, which subsequently registers the imaging documents with the Document Registry actor. It also supports the retrieval services for DICOM SOP Instances referenced in a published imaging manifest document.
Document Consumer - The Document Consumer actor queries a Document Registry actor for documents meeting certain criteria, and retrieves selected documents from one or more Document Repository actors.
Imaging Document Consumer - The Imaging Document Consumer actor parses an imaging manifest document that is retrieved by the Document Consumer actor from the Document Repository actor, and retrieves DICOM SOP Instances referenced within that manifest from the Imaging Document Source actor.
Document Registry - The Document Registry actor maintains meta-data about each registered document in a document entry. This includes a link to the Document Repository where the actual document is stored. The Document Registry responds to queries 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 stores documents. It assigns and maintains a unique identifier for each document, to allow Document Consumers to retrieve them.
Patient Identity Source - The Patient Identity Source actor assigns a unique identifier to each instance of a patient as well as maintains a collection of identity traits.
Update the Integration Profile Actors table2.2-1 as follows Table 2.2-1. Integration Profile Actors
Integration Profile Actor
SWF PIR PWF RWF CHG CPI PGP KIN ED SINR PDI ARI SEC XDS-I
Integration SWF PIR PWF RWF CHG CPI PGP KIN ED SINR PDI ARI SEC XDS-Profile IActor
Patient Identity Source
X
2.3 Transaction Descriptions
Add the following to 2.3Transaction description
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].
245
250
255
260
265
270
ITI-14. Register Document Set - A Document Repository Actor initiates the Register Document Set transaction. This transaction allows a Document Repository Actor to register one or more documents with a Document Registry, by supplying meta-data about each document to be registered. This document meta-data will be used to create an XDS Document Entry in the registry. The Document Registry actor ensures that document meta-data is valid before allowing documents to be accessed through a query. If one or more documents fail the meta-data validation, the Register Document Set transaction fails as a whole.
To support composite documents, an XDS Document may be a multipart document. The Document Repository must handle multi-part data sets as an “opaque entity”. The Document Repository does not need to analyze or process its multi-part structure nor the content of any parts in the context of the XDS Integration Profile [ITI-14].
ITI-16.Query Registry – The Query Registry transaction is issued by the Document Consumer Actor on behalf of a care provider (EHR-CR) to a Document Registry. The Document Registry Actor searches the registry to locate documents that meet the criteria specified in the query request. It will return a list of document entries that contain metadata found to meet the specified criteria including the locations and identifier of each corresponding document in one or more Document Repositories [ITI-16].
ITI-17. Retrieve Document – A Document Consumer Actor initiates the Retrieve Document transaction. The Document Repository will return the document that was specified by the Document Consumer. To support composite documents, an XDS Document may be a
multipart document. In this case, the Document Consumer must take appropriate actions to make the multipart content accessible to the user [ITI-17].
ITI-8. Patient Identity Feed – This is IHE ITI Transaction 8, defined as part of the Patient Identifier Cross-referencing Integration Profile. It conveys the patient identifier and corroborating demographic data, captured when a patient’s identity is established, modified or merged or in cases where the key corroborating demographic data has been modified. Its purpose in the XDS Integration Profile is to populate the registry with patient identifiers that have been registered in the affinity domain [ITI-8].
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].
Update the following existing transactions descriptions. 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
290
27. Retrieve Reports – A Report Reader or an Imaging Document Consumer requests and retrieves a diagnostic report from the Report Repository or External Report Repository Access or an Imaging Document Source. 295
31. Retrieve Key Image Note – An Image Display or an Imaging Document Consumer requests and retrieves a Key Image Note from the Image Archive or an Imaging Document Source, respectively.
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
300 or an Imaging Document Source,
respectively.
Update the Integration Profile Transactions table as follows
305 Table 2.3-1. Integration Profile Transactions
Integration Profile Transaction
SWF PIR PWF RWF CHG CPI PGP KIN ED SINR PDI ARI SEC XDS-I
Integration Profile SWF PIR PWF RWF CHG CPI PGP KIN ED SINR PDI ARI SEC XDTransaction S-IQuery Reports [26] X X X Retrieve Reports [27] X X X XStructured Report Export [28]
Integration Profile SWF PIR PWF RWF CHG CPI PGP KIN ED SINR PDI ARI SEC XDTransaction S-IProvide and Register Imaging Document Set [RAD-54]
X
Register Document Set [ITI-14]
X
Query Registry [ITI-16]
X
Retrieve Document [ITI-17]
X
Patient Identity Feed [ITI-8]
X
WADO Retrieve [RAD-55]
X
2.4 Product Implementations Add the following grouping descriptions to the end of section 2.4
310 The Imaging Document Consumer shall be grouped with a Document Consumer.
Add the following sections (18, 18.1,) at the end of volume 1, before Appendix A.
18. Cross-enterprise Document Sharing for Imaging Integration Profile The Cross-Enterprise Document Sharing (XDS) Profile in the IHE IT Infrastructure Domain provides a solution for sharing (publishing, finding and retrieving) documents across a group of affiliated enterprises. The XDS for Imaging (XDS-I) Profile, defined here, extends and specializes XDS to support imaging “documents”, specifically including the following:
315
320
325
• Imaging studies that include images acquired on a broad range of different modalities, as well as evidence documents (e.g. post-processing measurements/analysis outcome), and presentation states.
• Diagnostic reports resulting from the interpretation of one or more related imaging studies provided in a ready-for-display form
• A selection of diagnostically significant images associated with the report content.
These document types along with the actor capabilities required to share them are defined by this profile.
The XDS for Imaging Profile relies so heavily on the IT Infrastructure XDS Profile including the use of terms defined in XDS (e.g., affinity domain, submission set, etc.) the reader of XDS-I is expected to have read and understand the XDS Profile (See ITI TF-1: 10).
Both the XDS and XDS for Imaging Integration Profiles are not intended to address all cross-enterprise EHR communication needs. Many scenarios may require the use of other IHE Integration profiles, such as Patient Identifier Cross-Referencing (PIX), Audit Trail and Node Authentication (ATNA), Enterprise User Authentication (EUA), Cross-enterprise User Authentication (XUA) and Retrieve Information for Display (RID). Other scenarios may be only partially supported, while still others may require future IHE Integration profiles, which will be defined by IHE as soon as the necessary base standards are available. Specifically:
1. The operation of any XDS-I Clinical Affinity Domain will require that a proper security model be put in place. It is expected that a range of security models should be possible. Although the XDS-I Integration Profile is not intended to include nor require any specific security model, it is expected that XDS-I implementers will group XDS-I Actors with actors from the IHE Audit Trail and Node Authentication and will need an Access Control capability that operates in such a cross-enterprise environment. New IHE Integration Profiles have been identified as candidates (e.g. Public Key Infrastructure, Access Control, etc.). There is a discussion of XDS-I security considerations in RAD TF-1: Appendix X2.
2. The establishment of independent but consistently XDS-based Affinity Domains will call for their federation, as patients expect their records to follow them as they move from region to region, or country to country. IHE foresees a need for transferring information from one Clinical Affinity Domain to another, or to allow access from one Affinity Domain to documents managed in other Affinity Domains. XDS/ XDS-I has been designed with this extension in mind. An XDS/ XDS-I Domains Federation Integration Profile that complements XDS may be anticipated in the future.
3. XDS and XDS-I do not address transactions for the management or configuration of a clinical affinity domain. For example, the configuration of network addresses or the definition of what type of clinical information is to be shared is specifically left up to the policies established by the clinical affinity domain.
4. XDS and XDS-I do not specifically address the patient information reconciliation process necessary between the Clinical Affinity Domain and any other local patient identity domains that Document Sources and Document Consumers may be members of. For a discussion of some of these issues see RAD TF-1: Appendix X1.
18.1 Actors/ Transactions Figure 18.1-1 shows the actors directly involved in this profile and the transactions between actors.
Figure 18.1-1. Cross-enterprise Document Sharing for Imaging Diagram
365
370
Table 18.1-1 lists the transactions for each actor directly involved in the Cross-enterprise Document Sharing for Imaging Profile. In order to claim support of this Integration Profile, an implementation 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: 18.2. Note that a number of actors must be grouped with Imaging Document Source as described in RAD TF-1: 2.4.
Table 18.1-1 Cross-enterprise Document Sharing for Imaging Integration Profile - Actors and Transactions
Actors Transactions Optionality Section in Vol. 2
Query Registry [ITI-16] R ITI TF-2:3.16
Document Consumer
Retrieve Document [ITI-17] R ITI TF-2:3.17
Retrieve Images [RAD-16] O (note2) 4.16
Retrieve Presentation States [RAD-17]
O 4.17
Retrieve Reports [RAD-27] O (note2) 4.27
Retrieve Key Image Note [RAD-31], O 4.31
Retrieve Evidence Documents [RAD-45]
O (note2) 4.45
Imaging Document Consumer
WADO Retrieve [RAD-55] O (note2) 4.55
Provide and Register Imaging Document Set [RAD-54]
R (note 3) 4.54
Retrieve Images [RAD-16] R 4.16
Retrieve Presentation States [RAD-17]
R 4.17
Retrieve Reports [RAD-27] R 4.27
Retrieve Key Image Note [RAD-31], R 4.31
Retrieve Evidence Documents [RAD-45]
R 4.45
Imaging Document Source
WADO Retrieve [RAD-55] R 4.55
Provide and Register Imaging Document Set [RAD-54]
R 4.54
Register Document Set [ITI-14] R (note1) ITI TF-2:3.14
Document Repository
Retrieve Document [ITI-17] R ITI TF-2:3.17
Register Document Set [ITI-14] R (note1) ITI TF-2:3.14
Query Registry [ITI-16] R ITI TF-2:3.16
Document Registry
Patient Identity Feed [ITI-8] R ITI TF-2:3.8
Patient Identity Source Patient Identity Feed [ITI-8] R ITI TF-2:3.8
Note1: The Register Transaction is not required in implementations where the Document Registry Actor is grouped with the Document Repository Actor. However, it is strongly recommended that these transactions be supported to allow for future configuration with multiple Repositories. 375
Note 2: At least one of the optional retrieve transactions is required to be supported. Refer to section 18.4 for additional requirements on the Imaging Document Consumer.
Note 3: Support of at least one of the four document types described by the options in section 18.2 is required..
18.2 Integration Profile Options Options that may be selected for this Integration Profile are listed in table 18.2-1 along with the Actors to which they apply. Dependencies between options when applicable are specified in notes.
Table 18.2-1 Cross-enterprise Document Sharing for Imaging - Actors and Options Actor Options Vol &
Section Set of DICOM Instances
(Note 1) RAD TF-1: 18.2.1
PDF Report (Note 1) RAD TF-1: 18.2.2
Text Report (Note 1) RAD TF-1: 18.2.3
Imaging Document Source
Multipart Text/PDF Report (Note 1)
RAD TF-1: 18.2.4
Document Repository No options defined -
Document Registry No options defined -
Document Consumer No options defined -
Imaging Document Consumer No options defined -
Patient Identity Source No options defined -
Note 1: At least one of these four options is required.
18.2.1 Set of DICOM Instances Option 385
390
395
This option requires the Imaging Document Source to provide and register a DICOM manifest that references DICOM instances. These DICOM instances are made available to be retrieved from the Imaging Document Source, as specified in the manifest. The Imaging Document Source is required to ensure that the referenced images from within a published manifest are available to be retrieved. For details of the transaction affected by this option, refer to RAD TF-2: 4.54.4.1.2.2.
18.2.2 PDF Report Option This option requires Imaging Document Source to provide and register an Imaging Report in a PDF format. The published report may contain embedded images or pre-computed links that reference images in a non-DICOM format. The Imaging Document Source is required to ensure that image references are valid links. For details of the transaction affected by this option, refer to RAD TF-2: 4.54.4.1.2.3
18.2.3 Text Report Option This option requires Imaging Document Source to provide and register an Imaging Report in a Text format. For details of the transaction affected by this option, refer to RAD TF-2: 4.54.4.1.2.3.
18.2.4 Multipart Text/PDF Report Option This option requires Imaging Document Source to provide and register an Imaging Report in Text and in PDF format as multipart of one document. For details of the transaction affected by this option, refer to RAD TF-2: 4.54.4.1.2.3. Text documents may serve as subsets or a specific summary of other document formats (e.g, transaction RAD-28 Structured Report Export) therefore it may be beneficial to provide both text and PDF documents in certain scenarios.
18.3 Image Information Sharing Process Flow The sharing of imaging related information among different health professionals and facilities, even across administrative and geographic boundaries can lead to a large variety of information flows. Typical imaging information sets used in healthcare settings are well known, but the challenge is to distill the “exchange” scenarios to drive the sharing of imaging information across enterprises distributed over a community, region or nation.
18.3.1 Overview of Imaging Information Sharing Use Cases
The following use case scenarios express the core imaging information sharing common to most clinical settings. They cover:
1. Routine imaging referral. The referring physician in his office requests that a patient have an examination done at an imaging facility. The physician expects to have electronic access to the imaging report and to the images if needed after the examination has been performed on his patient. This use case is further analyzed in this profile.
2. Course of Treatment Consult. An emergency physician orders an imaging examination for a patient at his hospital. After reviewing the preliminary report the ER physician decides to consult a surgical specialist at the regional hospital for advice on a course of action. For this, the surgical specialist accesses the images and preliminary report and reviews them in order to propose, on the phone, a course of action for the patient. This use case is further analyzed in this profile.
3. Clinical Consult. A general practitioner performs a routine imaging referral, reviews the shared imaging report and chooses to send the patient for evaluation by a specialist (e.g. an oncologist). The specialist needs access to the imaging report and full image set produced at the imaging facility where the patient had been sent by his general practitioner to perform the examination. This use case is further analyzed in this profile.
4. General imaging record access. A patient relocates or decides to change her physician. The new physician needs to retrieve relevant information from the patient record, review its content, including recent labs and imaging studies. A similar situation occurs when a patient is admitted for an emergency and timely access to the patient’s past information is required, including prior imaging studies. This use case is further analyzed in this profile.
This profile describes the information sharing transactions for care-delivering systems to publish patient’s imaging diagnostic documents (EHR-CR) for sharing across enterprises as longitudinal patient care records (HER-LR). The policies or administrative details regarding the sharing of imaging information are for the most part not explicitly discussed so as not to obscure clinical needs. Administrative variations between countries and regions are expected, and can be added or modified without losing the clinical information-sharing context.
Since the focus is on the sharing and access to patients imaging records rather than the entire workflow in which such information sharing takes place, other activities are described as though they are being done by telephone, paper mail, fax, etc. In an integrated electronic environment these other activities may be more automated, but those details are separate from the records access/sharing and are to be addressed by separate Integration Profiles.
18.3.2 Assumptions
The imaging information needs to be shared between multiple care delivery organizations (information sources and consumers), each (typically) with its own RIS and PACS. The point of service (“POS”) for physicians may be supported by a variety of systems: hospital EMR, physician practice system, PACS viewers, EHR web application, etc.
The concept of sharing information across enterprises that have agreed to join in such a health information network is based on basic design principles that can be summarized in the following points:
1. A group of healthcare enterprises have agreed to work together using a common set of policies and to share a common infrastructure of repositories and a registry for an affinity domain.
2. Information sources (e.g. EHR, lab system, PACS) select the “documents” they wish to share.
3. Documents may include any information in an agreed format (e.g. a PDF document, a DICOM manifest, etc.). Documents are stored in multiple document repositories.
4. Shared documents are registered with a central service called a document registry that tracks only indexing information and the location from which documents may be retrieved.
5. Information consumers may query this well-defined unique/singular indexing service (document registry) to find the document index information for any patient and the location from which documents may be retrieved (document repositories).
6. Information sources remain the owner of the documents shared in repositories and, thereby, remain responsible for replacing or deprecating its documents if necessary.
In each one of the use cases, it is assumed that the people and the information systems that participate in a single “Affinity Domain” have agreed upon mechanisms to address:
• Governance: operational structure, data stewardship, etc. • Privacy: consent management and data masking controls • Security: Authorization and authentication, network security, audit trails, etc. • Normalized patient ID schemes: MPI (Master Patient Index), unique information IDs,
etc. • Coded Vocabularies used for registry information
18.3.3 Use cases
18.3.3.1 Routine Imaging Referral Use Case
This scenario describes imaging information sharing in a typical patient referral and reporting use case where:
• An examination is performed upon the request of a referring physician: • The referring physician accesses the regional health information network and reviews
the report along with the key images and may optionally access the full image set that made the study.
This scenario is characterized by all the information being provided for sharing at one time, as a single logical unit, when the imaging study is completed by the radiology enterprise (i.e., a single “document submission set”).
18.3.3.1.1 Process Flow
Figure 18.3.3-1 highlights the people and systems participating in this regional health information network, including:
• Physician Office: A referring physician working out of a private office with a physician practice system for access to information
• RIS/PACS Enterprise A: A radiology enterprise with modality equipment and a RIS/PACS to manage report and imaging information: Radiology Enterprise A
• RIS/PACS Enterprise B: Another radiology enterprise with a RIS/PACS to manage report and imaging information: Radiology Enterprise B
• Document Registry: A document registry that serves as the information index for the regional health information network
In the process flow description, steps that pertain to information sharing are shown in bold (and numbered). In contrast, the steps that do not pertain to the focus of information sharing are shown in italic (and not numbered). These steps are expressed to ensure a more complete context.
Figure 18.3.3-2 shows the transaction diagram for this process flow.
Exam is ordered The Referring Physician orders the examination and the patient goes to the Imaging Department: Radiology Enterprise A.
This is well-understood workflow that may be executed using any combination of paper, faxes, telephone, and electronic communications. It may or may not be addressed using the IHE Scheduled Workflow Integration Profile.
Although this step is part of the use case, it is peripheral to the specific steps for sharing of imaging of information.
Step 1: Obtain Relevant Prior Imaging Information • The PACS at Radiology Enterprise A, where the acquisition and reporting is
performed, does a query of the Document Registry to identify relevant prior images and reports. It should be noted that the determination of what is relevant is the responsibility of the consumer and not the registry.
• The PACS at Radiology Enterprise A retrieves prior imaging information from a repository in another radiology enterprise within the regional health network: Radiology Enterprise B, in preparation for study acquisition and subsequent reporting
Physician Office Radiology Enterprise A Affinity Domain
Figure 18.3.3-1 Data Flow within the Regional Health Network for a Routine Imaging Referral
Exam is Acquired and Reported Images are sent from the modality to the PACS. This is well-understood workflow described in IHE SWF.
The study is reported. This is well understood workflow that is managed by systems within Radiology Enterprise A
Step 2: Share Imaging Information within the Regional Health Network (Affinity Domain) • The PACS at Radiology Enterprise A, serving as a “Imaging Document Source”,
provides imaging information to the document repository, which register the document in the registry, for sharing, including: o Acquired DICOM study o Final report
Step 3: Obtain and Display Study Results • A physician practice system in the Physician’s office, serving as a document
consumer, queries the Document Registry in the regional health network. This query may be triggered by the patient’s next appointment, a call from the patient to the physician’s secretary, an electronic notification that the examination’s result is available (using the IHE ITI Notification for Document Availability profile), etc.
• The physician practice system presents a list of imaging information available for the patient
• The referring physician selects the study results and relevant prior studies and reports • The physician practice system in the Physicians office, serving as an Imaging
Document Consumer, retrieves the selected documents from the RIS/PACS Document Repositories in the regional health network and displays them to the referring physician.
Referring Physician reviews the results The Referring Physician reviews the results of the examination: the report and images from the RIS/PACS in Radiology Enterprise A, and the results of prior examinations: reports and images from the RIS/PACS in Radiology Enterprise B
This scenario is a variation on the routine imaging referral use case in that an addendum is generated after completion of the final report. As such, this scenario is characterized by information being provided for sharing at two separate times while ensuring that the initial information is supplemented by the addendum report.
The use of addendum reports is commonly encountered in a course of treatment consultation where:
575
580
585
590
595
600
• An ER physician orders an exam, and the study is acquired in the affiliated radiology department.
• A department radiologist creates and shares a report as well as identifies key images and annotations.
• A remotely located surgical specialist, at the request of the ER physician, reviews the report along with key images and the full study, and provides a consult to the ER physician (this use case does not constrain the method for communicating the results of the consult, e.g. phone, fax, etc).
• The radiologist identifies additional information and completes an addendum to the initial report.
Note that the scenario where the radiologist seeks an opinion from a more senior radiologist is similar to this use case.
18.3.3.2.1 Process Flow
The process flow description and steps are as for the routine imaging referral, but with the following variations (shown in bold):
Exam is ordered
Step 1: Obtain Relevant Prior Imaging Information
Exam Acquisition and Reporting
Step 2: Share Imaging Information within the Regional Health Network (Affinity Domain) • The PACS at Enterprise A, serving as a “Imaging Document Source”, provides
imaging information to the document repository, which register the document in the registry, for sharing, including: o Acquired DICOM study o Report o Key images along with annotations
Step 4: Share Addendum to Report within the Regional Health Network (Affinity Domain) • Sometime later on, the radiologist creates an addendum to the initial report. This
addendum is transcribed into the RIS at Enterprise A and signed off by the radiologist. This addendum must now supplement the initial report.
• The RIS at Enterprise A performs a document query of the document registry for the first submission set
• The RIS at Enterprise A, serving as a “Imaging Document Source”, provides the addendum for sharing to the document registry including the content of the first submission set and declaring the new document as an addendum to the initial report
Figure 18.3.3-3 shows the transaction diagram for this process flow.
Orthopaedic Centre(Document Consumer)
Rad. Enterprise A(Document Repository) Document RegistryRad. Enterprise A
(Document Consumer)Rad. Enterprise A: PACS
(Document Source)Rad. Enterprise A: RIS
(Document Source)
Step 1 - Query or relevant prior exams
Step 1 - Retrieve relevant prior images and reports
Step 2 - Share images and Initial Report(Submission Set 1) Step 2 - Register images and report
Step 3 - Query forexam
Step 3 - Retrieve images and report for new exam
Step 4 - ShareAddendum
(Submission Set 2)
Step 4 - Register Addendum
Step 4 - Query for new exam (associated submission set)
Rad. Enterprise B(Document Repository)
615 Figure 18.3.3-3 Process Flow – Course of Treatment Consult Use Case
18.3.3.3 Clinical Consult Use Case
This scenario is an extension of the routine imaging referral use case in that a consult report is generated based from the original imaging exam and radiologist report. As such, this scenario is characterized by information being provided for sharing at two separate times by two separate 620 source systems.
The reports shared in this use case are based on the same initial imaging exam. However the reports are generated by different people and registered by different systems.
The generation of consult reports is commonly encountered in cancer treatment. As such, the following clinical consult use case is used to describe the scenario:
• A general practitioner performs a routine imaging referral (as per Use Case 1). • In reviewing the imaging exam report from the radiologist, the practitioner chooses to
send the patient to an oncologist for a consultation. • The oncologist, located at a Cancer Center, reviews the report along with key images,
the full study, and past imaging information records for the patient • The oncologist generates an additional report that is made available to the general
practitioner • The general practitioner reviews the oncologists report and takes appropriate
treatment action
18.3.3.3.1 Process Flow
Figure 18.3.3-4 highlights the people and systems participating in this regional health information network. These are the same as for the routine imaging referral but with one additional participant:
• Physician Office • RIS/PACS Enterprise A • RIS/PACS Enterprise B • Document Registry • Oncologist: An oncologist working out of a cancer center: Cancer Center. This center
has an Electronic Health Record (EHR) application that serves as the POS application for reviewing imaging information within the regional health network. The EHR application has DICOM Viewing capabilities
Figure 18.3.3-4 Data Flow within the Regional Health Network for a Clinical Consult
The process flow description and steps are as for the routine imaging referral, but with certain variations. The variations that pertain to information sharing are shown in bold (and numbered). In contrast, the variations that do not pertain to the focus of information sharing are shown in italic (and not numbered).
Exam is ordered
Step 1: Obtain Relevant Prior Imaging Information
Exam Acquisition and Reporting
Step 2: Share Imaging Information within the Regional Health Network (Affinity Domain)
Step 3: Obtain and Display Study Results (General Practitioner) • This is identical to Step 3 in the routine imaging referral use case • Based on the radiology report, the general practitioner determines that a consult with
an oncologist is required
IHE Technical Framework Supplement - Cross-enterprise Document Sharing for Imaging Profile ______________________________________________________________________________
Step 4: Obtain and Display Study Results (Oncologist) • The EHR application in the oncologist’s office, serving as a document consumer,
queries the document registry in the regional health network. This query is triggered by a consult request from the general practitioner via paper, fax, phone, and/or electronic notification. The EHR application presents a list of imaging information available for the patient, including the most recent exam completed at Radiology Enterprise A
• The oncologist selects the exam reported by the radiologist as well as a number of relevant prior exams
• The EHR application in the oncologist’s office, serving as an Imaging Document Consumer, retrieves the documents selected from the RIS/PACS document repositories in the regional health network and displays them to the oncologist
• The oncologist reviews the images using image manipulation tools such as window level, zoom, pan, invert, measurement, etc. The oncologist may also apply 3D rendering such as multi-planar reformatting
Oncologist Generates Consult Report • The oncologist reviews the results of the examination along with prior exams • The oncologist generates a consult report
Step 5: Share Consult Report within the Regional Health Network (Affinity Domain) • The EHR application in the oncologist’s office, serving as a “Imaging Document
Source”, provides the consult report to the document registry for sharing. This has reference to the original imaging exam, which was used during the consult.
Figure 18.3.3-5 shows the transaction diagram for this process flow.
Rad. Enterprise A(Document Repository) Document RegistryRad. Enterprise A
(Document Consumer)Rad. Enterprise A
(Document Source)Cancer Centre
(Document Source)
Step 1 - Query for relevant priors
Step 1 - Retrieve relevant prior images and reports
Step 2 - ShareImages andFInal Report
Step 2 - Register images and report
Step 3 - Queryfor new exam
Step 3 - Retrieve new exam
Step 5 - Share Consult Report
Step 5 - Register consult report
Step 5 - Querynew exam
(associatedsubmission set)
Rad. Enterprise B(Document Repository)
GP Office(Document Consumer)
Step 4 - Query for new exam andrelevant priors
Step 4 - Retrieve new exam & relevantpriors
Figure 18.3.3-5 Process Flow – Clinical Consult Use Case
18.3.4 Queries
695
700
705
As presented in the use cases, human or machine users may query the Registry in order to retrieve documents in a subsequent step, based on the query result. The type of query attributes my vary between users or query scenarios, depending on the intent of the query. For instance, human users often wish to query specifically, restricting the search by several query attributes and values.
The following query attributes are relevant (but not exhaustive): • Patient Identity – The patient is expected to be identified by Patient ID • Exam Identity – The physician is looking for a specific exam. The attributes used to
identify the exam may include one or more of the following:
o Date
o Modality
o Body part/anatomical region
o Document type – images, diagnosis, progress report, preliminary report, etc.
o Author – in the case of reports, the physician may well identify the report by its author i.e. the radiologist and / or specialist
The metadata in the query response needs to be sufficient to allow the system consumer to parse the response and identify relevant priors. Relevant metadata includes (but is not limited to):
• Exam date • Modality • Body part/anatomical region • Procedure code
18.4 Consumer Processing
18.4.1 Consumer Processing – Set of DICOM Instances When the Imaging Document Consumer retrieves a manifest from the Document Repository, it is expected to decode the Key Object Selection Document Instance in order to find the references to DICOM objects. The Imaging Document Consumer is also expected to retrieve the referenced DICOM objects using DICOM retrieve or WADO. It should not make any assumptions about whether one or more studies are referenced within the Key Object Selection Document.
18.5 Patient Information Reconciliation These considerations can be found in appendix X1.
18.6 Security considerations These considerations can be found in appendix X2.
Add the following appendices (X1 and X2) after the last appendix, but before the glossary in Volume 1
Appendix X1: Patient Information Reconciliation (INFORMATIVE) Patient Information Reconciliation (PIR) workflow within a local domain is well understood and addressed within the IHE PIR Integration Profile. However, within an XDS affinity domain, there is the added complexity of managing patient information within the XDS Registry and synchronizing data between the document sources, repository and registry.
735
740
745
750
755
760
The XDS Profile does not address the challenges of PIR. The reason for this is scope management (at the time of writing the initial XDS Profile) as well as a lack of content profiles to stress the PIR issue. It is the intent of the ITI Technical Committee to address the issue of PIR within XDS in due course.
Given that PIR will be addressed within the XDS Profile, this Appendix is considered informative and serves to demonstrate that imaging informatin content does not introduce any new or imaging information content specific PIR issues.
X1.1 Context and Assumptions
X1.1.1 XDS Affinity Domain Assumptions • The Document Registry assumes that all documents have a normalized patient ID
pertaining to the XDS Affinity Domain. Therefore:
o The XDS Affinity Domain must have a Patient Identification Domain in order to realize normalized patient IDs.
o The XDS Affinity Domain must have a Patient Identity Source Actor
o To simplify description in this section, the nomenclature for the XDS Affinity Domain will be “XAD”.
• A Document Source is responsible for obtaining the XAD patient ID for registering the document within the registry. The XAD patient ID that is obtained is only used for this purpose and is not used to update any patient ID’s within the document. Patient ID’s within the document shall remain unchanged by the registration process
• A Document Consumer is expected to query the Document Registry using the XAD patient ID
• The Registry can only accept a document if the document has a valid XAD patient ID • The Registry must check to see if the XAD patient ID is valid. This can be done in
o Query the XAD Patient Identity Source to see if the XAD patient ID exists – not supported at this time
o Maintain all XAD patient IDs in the registry irrespective of whether there are documents for that patient i.e. keep in synch with the XAD Patient Identity Source –
765 this is the expected model
• The Registry cannot accept a document with an OID that is already registered
o If a document is submitted that has the OID of a document already registered, the Registry will reject the submission
o If a document is re-submitted and, thereby, is identical to a document already submitted, the Registry will reject the submission
770
775
780
785
790
X1.1.2 Meta-Data in the Registry • The XAD patient ID is the only piece of metadata that can be reliably used to query
for a patient • The Registry maintains supporting patient information such as Name, Sex, DoB, etc.
but is NOT obligated to ensure the referential integrity of this data. Therefore:
o This information is NOT used for query matching (but is only used for audits and potential verification of Document Consumers)
o There is no requirement for the XDS Document Registry to verify that the meta-data in the Registry corresponds to the patient information in the document itself
• The Registry does track the local domain source patient ID, but this is not used for query matching
X1.1.3 Patient Identity Management in the XDS Registry • The Registry keeps a list of known XAD patient IDs • The Registry associates documents with the patient IDs • The Registry receives patient “merge” notifications from the XAD Patient Identity
Source • The Registry is responsible for updating XAD patient IDs associated with documents • The Registry does not update metadata nor document content • If the clinical content of a document has changed, the Document Source is
responsible for updating the Repository and Registry
X1.1.4 Expected Implementation Models for Patient Identity Management
In a cross enterprise scenario, we assume that there are multiple patient identity domains
• Local patient identity domains that support one or more enterprises. These pertain to Document Sources and Document Consumers
• Affinity Domain patient identity domain
Each patient identity domain has a Patient Identity Source. In the case of local domains, this is likely to be an ADT system. For the Affinity Domain, this is yet another patient registry.
A participating enterprise may deploy a Patient Identifier Cross-Referencing (PIX) Manager to cross-map Patient ID in the local domain to Patient ID in XAD domain. In such cases, the Cross Reference Manager will interact with the Affinity Domain Patient Identity Source.
Document sources and consumers are required to obtain a normalized XAD patient ID. The mechanism for achieving this is dependent on the implementation of patient identity feeds and patient identity cross reference manages within the Affinity Domain. For example, where local domains have Patient Identity X-ref managers, the document sources and consumers obtain the normalized XAD patient ID from the Affinity Domain patient identity source via the X-ref managers. The document sources and consumers can also obtain the XAD patient ID using other methods such as IHE PDQ or non- IHE approaches.
This is shown in Figure X1.1-1
For the sake of discussion, no assumptions are made on how document sources and consumers interact with the XAD patient identity domain – it could be directly or through a local domain X-ref manager.
Figure X1.1-1 – Patient Identity Management using PIX Cross Referencing
X1.2 Patient Information Reconciliation (PIR) in an Affinity Domain PIR workflow within a local domain is well understood and addressed within the IHE PIR Integration Profile. However, within an XDS affinity domain, there is the added complexity of managing patient information within the XDS Registry and synchronizing data between the document sources, repository and registry.
X1.2.1 Patient Merge within XAD Patient Identity Domain • XAD patient identity domain merges two patients • Document sources are unaware of the merge transaction within XAD patient identity
• XDS Registry receives a merge notification from the XAD patient identity source and applies merge logic to the registry
• Document consumers have continued access to documents pertaining to the patient since consumers are expected to obtain the XAD patient ID for the patient at the time of querying the Registry
• Document sources are unaware of the merge transaction that occurred in the XDS registry and do not need to be made aware of this merge. The reasons for this are: o Consumers have continued access to the document o The document source must query for the XAD patient ID before attempting to
interact with the repository and registry. As such, the document source will have an updated XAD patient ID at the time of interacting with the registry.
o When a document source wishes to submit a change to the document:
o The document source must query for the XAD patient ID before registering the new document
o The document source must register the new document with a request to deprecate the old document. From the document source’s perspective, the old document is still associated with the original XAD patient ID. By virtue of obtaining a new XAD patient ID for the patient, the document source must assume that a patient merge has taken place and use the new XAD patient ID to deprecate the old document
The process flow is described in more detail as follows:
Scenario: • Key identifier for a patient within the XAD patient identity domain changes, such as
health number • The XAD patient identity source merges two patients
Process Steps: 1. The XAD patient identity source sends a “merge” notification to the XDS Registry
2. XDS Registry applies merge logic to the patients within the merge notification • The metadata in the registry will be accurate with the exception of the source patient
ID
X1.2.2 Local Domain Patient Update - XAD Domain Patient ID does not change • Demographics for the patient change
• Local domain patient ID does NOT change • XAD patient ID does NOT change
In this scenario: • XDS Registry does nothing since the XAD patient ID has not changed • If a document source changes the patient demographics content of a document and a
new document is created then this document should be registered with the XDS repository/registry as a replacement to the old document
The process flow is described in more detail as follows:
Scenario: • Patient first name is corrected from “Jamie” to “James” in the local domain patient
identity source
Process Steps:
1. Update information flows from the local domain patient identity source (i.e. ADT) to the document source: image manager/archive.
• Document source updates its database to correct demographics • Either: Document source does not change the document
o The Document Source does not update the repository/registry. In this scenario, the patient demographics: Name, Dob, Sex, etc.; in the Document Source do not match those in the XDS Registry. This is acceptable in the XDS framework
• Or: Document source changes the document
o The Document Source updates the repository/registry with an addendum
2. The Registry takes no action as the XAD patient ID has not changed
X1.2.3 Local Domain Patient Update - XAD Domain Patient Merge • Demographics for the patient change • Local domain patient ID does NOT change • XAD patient ID does change and triggers a merge within XAD domain • Document sources are unaware of the merge transaction within XAD patient identity
XAD-Pa” – patient “Alfonso” was already registered within the XAD domain with patient ID XAD-Pa
Process Steps: • See “X1.2.1 Patient Merge within XAD Patient Identity Domain”
X1.2.4 Local Domain Patient Merge – XAD Domain Patient ID does not change • Demographics for the patient changes • Local domain patient identity source merges patient A with patient B • XAD patient ID for patient A and patient B are the same
In this scenario: • XDS Registry does nothing since the XAD patient ID for patient A and patient B is
the same • Document sources apply merge logic to the documents within their database i.e.
documents are now associated with a new local domain patient ID • Document sources must now query XAD patient identity source1 to obtain the XAD
patient ID for the merged patient • The XAD patient ID is the same as already associated with the document:
o If the document source does not change the document content, the document source does not need to interact with XDS Repository/Registry – status quo
1 How the document source queries the XAD patient identity source is not prescribed as this may be directly or via a local domain x-ref manager
o If the document source changes the patient demographics content of a document and a new document is created, then this document should be registered with the XDS repository/registry as a replacement to the existing document.
The process flow is described in more detail as follows:
Scenario: • Patient last name is corrected from “Smythe” to “Smyth” • ADT already has an entry for “Smyth” • “Smythe” with local domain patient ID D-123 is merged with Smyth with local
domain patient ID D-456 • XAD Patient Identity Source already recognized “Smythe: D-123” and “Smyth: D-
456” as the same patient and, therefore, assigned each with the same XAD patient ID: XAD-Px
Process Steps: 1. Update information flows from the local domain patient identity source (i.e. ADT) to the
document source: image manager/archive. • Document source applies merge logic to the database: documents for the merged
patient are associated with the new patient ID
2. Document source queries the XAD patient identity domain to determine whether the XAD patient ID has changed for the merged documents. In this case the XAD patient ID does not change
3. Document source updates the demographics of the document • Either: Document source makes no changes to the document – demographics are in
the database
o The Document Source need not update the repository/registry. In this scenario, the patient demographics in the Document Source do not match those in the XDS Registry. This is acceptable in the XDS framework
• Or: Document source changes the document
o The Document Source updates the repository/registry with an addendum
4. The Registry takes no action as the XAD patient ID has not changed
X1.2.5 Local Domain Patient Merge – XAD Domain Patient Merge • Demographics for the patient changes • Local domain patient identity source merges patient A with patient B
• XAD patient IDs for patient A and patient B are different • Patient A is merged with patient B in the XAD domain patient identity source
There are three situations that can occur:
1. XDS Registry merge prior to Document Source merge • XDS Registry receives a merge notification from the XAD patient identity source and
applies merge logic to the registry • Document sources are unaware of the merge transaction that occurred in the XDS
registry and do not need to know about this transaction (see X1.2.1) • Document consumers have continued access to documents pertaining to the patient
since consumers are expected to obtain the XAD patient ID for the patient at the time of querying the Registry
• Document sources apply merge logic to the documents within their database i.e. documents are now associated with a new local domain patient ID
• Document sources must now query XAD patient identity source to obtain the XAD patient ID for the merged patient
• The XAD patient ID for the documents has changed:
o The document source changes the XAD patient ID associated with the documents – it can assume that the Registry has made this change as well
o If the document source does not change the document content, the document source does not need to interact with XDS Repository/Registry – status quo
o If the document source changes the patient demographics content of a document and a new document is created then this document should be registered with the XDS repository/registry – the existing document is deprecated.
2. Document Source merge prior to XDS Registry merge • Document sources apply merge logic to the documents within their database i.e.
documents are now associated with a new local domain patient ID • Document sources must now query XAD patient identity source to obtain the XAD
patient ID for the merged patient • The XAD patient ID is the same as already associated with the document:
o If the document source does not change the document content, the document source does not need to interact with XDS Repository/Registry – status quo
o If the document source changes the patient demographics content of a document and a new document is created, then this document should be registered with the XDS repository/registry as a replacement to the old document
• XDS Registry receives a merge notification from the XAD patient identity source and applies merge logic to the registry
• Document sources are unaware of the merge transaction that occurred in the XDS registry and do not need to know about this transaction
• Document consumers have continued access to documents pertaining to the patient since consumers are expected to obtain the XAD patient ID for the patient at the time of querying the Registry
3. Document Source merge at same time as XDS Registry merge • Document sources apply merge logic to the documents within their database i.e.
documents are now associated with a new local domain patient ID • Document sources must now query XAD patient identity source2 to obtain the XAD
patient ID for the merged patient
o The XAD patient ID is the same as already associated with the document • XDS Registry receives a merge notification from the XAD patient identity source and
applies merge logic to the registry • Document source chooses to change the patient demographics content of a document
and a new document is created. This document is registered with the XDS repository/registry:
o The XAD patient ID for this document has now been merged in the XDS Registry and, therefore, is no longer valid
o The Registry will reject the document registration transaction as the XAD patient ID used in the transaction is no longer valid.
o Document sources must now query XAD patient identity source to obtain the XAD patient ID for the merged patient and re-register the document with the XDS repository/registry
Scenario: • Patient last name is corrected from “Smythe” to “Smyth” • ADT already has an entry for “Smyth”
2 How the document source queries the XAD patient identity source is not prescribed as this may be directly or via a local domain x-ref manager
Appendix X2: Security considerations for XDS-I (informative)
This IHE profile does not specify all the details of the security environment for exchanging radiology information. The IHE includes several security profiles that apply to the XDS/ XDS-I use. The use of these security profiles in the first trial implementation for XDS-I will likely be optional. The security profiles make assumptions about the overall security environment and are configurable to adapt to different security requirements.
Figure X2-1 shows typical transactions for XDS-I. Each transaction goes through security and privacy controls. This figure illustrates use of firewall access points and TLS controls for all XDS-I participants, including the Imaging Document Source. The firewalls may have simple easy to implement rules or more complex rules depending upon local policies. The flows shown in figure X2-1 are described in more detail below:
Flow #1. The Store Images, etc. transactions:
a) Internal firewall rules I:
- Simple rules: “outgoing HTTP is OK”
- Complex rules: examine source IP, destination IP, HTTP headers to decide whether to permit the connection.
b) TLS within each actor:
- IM/IA: Is this really the authorized Image Document Source that was requested?
- Repository: Is this really an authorized IM/IA?
c) Once the TLS connection is established there is further processing, generation of audit records, etc.
Flow #2. The Provide and Register Imaging Document Set transaction:
a) does not cross a firewall
b, c) TLS, authorization, auditing as above.
Flow #3. The Register transaction
a) External firewall rules II:
- Simple: Outgoing HTTP is OK
- Complex: examine source IP, destination IP, HTTP headers to decide whether to permit the connection.
- Complex: very tricky given many different uses for HTTP incoming by different web applications.
b, c) TLS, authorization, auditing as above.
Flow #5, Retrieve Images, etc. transactions:
a) External firewall access rules III:
- Simple: Incoming DICOM is only permitted from authorized affinity domain IP blocks.
- Complex: Examine the DICOM retrieve connection initiator and the targeting acceptor IP addresses, and permit only connections between a priori authorized pairs of initiator and acceptor.
b, c) TLS, authorization, auditing as above.
This example shows access for both HTTP and DICOM traffic. It is easier to get multi-layer protection for the DICOM traffic because it is easily differentiated from the many diverse uses of HTTP for web applications and services. Then the TLS security, actor authorization rules, and auditing are applied to all traffic regardless of type.
Figure X2-1 Security Environment IHE assumes that there will be some form of external control point. This usually involves technologies like VPNs, firewalls, routers, etc. IHE does not specify what is necessary here, and the IHE profiles will operate and provide a good level of security even when the external control point is missing.
The purpose of having an external control point is:
• To control the low level network access between the Internet and the Imaging Document Source and Document Repository. The precision of this control is up to the sites involved. One common configuration is to merely restrict the list of IP Ports that are permitted access. This simplifies the security requirements on the server.
• Log and monitor all traffic for indications of hostile or abusive activity. This is usually a combination of logging and intrusion detection (IDS) activity that is oriented towards the overall IT organization requirements.
This kind of protection is useful and complements the encryption and access controls defined as part of IHE’s Audit Trail and Node Authentication (ATNA) Profile and its Radiology Option.
The internal network is probably divided into two or more zones that are isolated by internal control points. These internal control points are similar to the external control point, but usually are much more permissive in terms of the traffic that they allow. They exist both to detect problems and to provide a means of rapidly isolating portions of the network in the event of a security breach.
The Imaging Document Source is assumed to be located in the zone labeled the “Affinity Domain Zone”. This might also be part of a general DMZ (De-Militarized Zone) for the organization or it might be a special zone reserved exclusively for Affinity Domain activities. There are cost and functionality tradeoffs involved in making that decision and the IHE profiles support both approaches.
IHE will specify the minimum-security requirements for the Imaging Document Source. It will be expected to comply with the IHE ITI ATNA (Audit Trail and Node Authentication) Integration Profile. There may be multiple Imaging Document Sources in the Affinity Domain Zone and they will all be expected to comply with the ATNA profile. This profile mandates:
• All connections that might transfer protected health information (PHI) must utilize TLS configured to:
o Authenticate both machines involved
o Ensure that all traffic is encrypted, either directly by TLS or by means of equivalent protection such as VPN.
• Enforce access control to the system
• Provide a detailed security audit trail for all PHI related activity and information transfers
The TLS protocol is also widely known as HTTPS. The ATNA profile mandates this protection for any DICOM, HL7, HTTP or other protocols.
There may be special auditing requirements for an XDS-I actor. For example, in the US there are HIPAA requirements for disclosure logs. Only the sites themselves can determine what belongs in a disclosure log. The ATNA logs were not directly intended for this purpose.
The Imaging Document Source may be a system that is complete with its own image archive, or it may be a proxy machine that relays information to another machine, perhaps located in a private zone. This is considered an internal design issue by IHE. The IHE XDS-I profile specifies that the Imaging Document Source must support the XDS-I transactions, and does not specify the internal design.
There are several important design considerations for securing XDS-I networks that must be made by the affinity domain and its members. These are:
1. What kind of external control points are used. IHE recommends that they be present, but does not profile them.
2. How to subdivide the enterprise network and whether to establish a dedicated Affinity Domain Zone. There is an advantage to creating a Affinity Domain Zone with just a few servers located in it:
a. The log analysis is easier
b. The certificate and TLS management for node authentication is easier
c. The preparation of disclosure logs and the equivalent is easier.
d. The internal control point reduces the risks from a breach of the Affinity Domain Zone.
3. Whether User Authentication is needed. IHE provides both the Enterprise User Authentication (EUA) and Cross Enterprise User Authentication (XUA) profiles. Use of user authentication permits additional information to be captured in the audit logs (e.g., the identity of the user) and permits additional access control in some situations. The issues that the affinity domain and sites must address are:
a. What to do about automated processes, such as pre-fetch and email. These can be identified using node authentication via TLS as specified in ATNA, by using simple identity assertions.
b. How to handle delegation. Often it is clerks, nurses, etc. that are actually operating the computer to obtain the records for a patient, and it is someone else that will actually be examining the records. So the user authentication might not provide any further useful information.
The IHE profiles do not determine these choices. Some reasonable selections include:
1. Not using user authentication. The ATNA ensures that the enterprise and the machine are authenticated. These machines are already authenticated and trusted to protect PHI information. It may be impractical to track and coordinate the personnel activities across all the different organizations.
2. Though not specifically designed for this purpose, it is also possible that the XDS-I profile is being used internally within a centrally controlled large organization, where the Kerberos based identity management of EUA is available. EUA can be used in such an intra-enterprise environment. EUA supports simple identity assertions. These are based on trusting the authenticated node to provide the correct identity of its user.
3. The use of XUA is optional. Where a human user is involved, XUA can be employed for cross-enterprise user identity assertion. If only machines are involved, the node authentication provided by ATNA should be sufficient. The use of XUA requires that the affinity domain establish the authentication policies,
procedures, and have a supporting infrastructure of servers, etc. (This infrastructure may be provided by the local government or might need to be provided by the affinity domain.). Note: In order to use the IHE XUA Integration Profile, the underlying application protocol must be able to carry a user identity assertion in its payload. While such a mechanism has been established in HL7 and HTTP/S, the mechanism to provide this for DICOM messages is still under development. Thus, XUA profile cannot (yet) be employed when retrieving DICOM SOP Instances referenced in the manifest document.
The affinity domain and individual site policies will determine the choices made. There are IHE profiles defined to address these alternatives.
GLOSSARY Add the following to glossary entries to the Glossary in Volume one
Affinity Domain Refer to the IHE ITI Technical Framework Glossary.
Care Delivery Organization/Enterprise
An organization that provides medical services at one or more physical locations
XDS Document Refer to the IHE ITI Technical Framework Glossary
Point of Service (POS) Application
An application used by physicians to access patient information and perform work. Examples of a POS include EMR, EHR, physician practice system, PACS, etc.
Regional Health Information Network
An implementation of an affinity domain serving a number of care delivery organizations in a region.
Submission Set Refer to the IHE ITI Technical Framework Glossary
URI Unique Resource Identifier
DMZ De-Militarized Zone. A computer or small sub-network that sits between a trusted internal network, such as a corporate private LAN, and an un-trusted external network, such as the public Internet. Typically, the DMZ contains devices accessible to Internet traffic, such as Web (HTTP) servers, FTP servers, SMTP (e-mail) servers and DNS servers.
Manifest Document A Manifest Document is an instance of DICOM Key Object Selection SOP Class, which describes and collects a set of DICOM SOP Instances that are intended for sharing.
This section corresponds to Transaction RAD-16 of the IHE Technical Framework. Transaction RAD-16 is used by an Image Display actor to request and retrieve images from an Image Archive and the Imaging Document Consumer to request and retrieve documents from an Imaging Document Source actor. the Image Archive, and Image Display actors.
4.16.1 Scope 1200
After the Image Display or Imaging Document Consumer request for image retrieval, the requested DICOM Images are transferred from the Image Archive to the Image Display or from the Imaging Document Source to the Imaging Document Consumer for viewing.
4.16.2 Use Case Roles
Retrieve Images
Image Display
Image Archive
Imaging Document
Source
Imaging Document Consumer
1205 Actor: Image Archive:
Role: Sends requested images to the Image Display Actor.
Actor: Imaging Document Source:
Role: Sends requested images to the Imaging Document Consumer Actor.
Actor: Image Display 1210
Role: Receives requested images from the Image Archive Actor.
Actor: Imaging Document Consumer
Role: Receives requested images from the Imaging Document Source Actor.
The Retrieve (Study Root – MOVE and optionally Patient Root – MOVE) SOP Classes shall be supported. The DICOM Image Storage SOP Classes will be supported by the Image Archive or 1220 Imaging Document Source as an SCU. Refer to DICOM 2003 PS 3.4, Annex C, for detailed descriptive semantics.
In the case of retrieving images in a Cross-Enterprise, imaging document sharing (XDS-I) network environment, a configuration of mapping the AE Titles to DICOM AE Network Addresses (IP Address and Port number) is needed to be exchanged between the Imaging 1225
Document Source and the Imaging Document Consumer. Appendix Y describes in details the AE Title mapping to the DICOM AE Network Addresses.
4.16.4.1.1 Trigger Events
Images are selected for viewing at the Image Display or Imaging Document Consumer.
1230
1235
4.16.4.1.2 Message Semantics
The message semantics are defined by the DICOM Query/Retrieve SOP Classes and the DICOM Image Storage SOP Classes.
A C-MOVE Request from the DICOM Study Root Query/Retrieve Information Model – MOVE SOP Class or the DICOM Patient Root Query/Retrieve Information Model – MOVE SOP Class shall be sent from the Image Display to the Image Archive or from the Imaging Document Consumer to the Imaging Document Source.
4.16.4.1.3 Expected Actions
The Image Archive or Imaging Document Source receives the C-MOVE request, establishes a DICOM association with the Image Display
1240 or Imaging Document Consumer, respectively,
and uses the appropriate DICOM Image Storage SOP Classes to transfer the requested images. The Image Display or Imaging Document Consumer is expected to support at least one of the SOP Classes specified in table 4.8-1. It is assumed that support of retrieval for a SOP Class also means support for display. 1245
4.16.4.1.3.1 NM Image Profile
Image Manager/Image Archive, Imaging Document Source, Image Displays and Imaging Document Consumer actors that claim support of the NM Image Profile shall support all the SOP Classes specified in Table 4.8-3 in section 4.8.
1250
4.16.4.2 View Images
This transaction relates to the “View Images” event of the above interaction diagram.
4.16.4.2.1 Trigger Events
The Image Display or Imaging Document Consumer is requested to be capable to display the images. 1255
This is a local invocation of functions at the Image Display or Imaging Document Consumer.
4.16.4.2.2.1 Display of Digital X-Ray, Mammo and Intra-Oral Images
For the “For Presentation” variant of the Digital X-Ray Image, the Digital Mammography Image, and the Digital Intra-oral X-Ray Image, the Image Display or Imaging Document 1260 Consumer actor shall have both the capability to apply the transformations specified by the VOI LUT Sequence (0028,3010) and the capability to apply the transformations specified by the Window Width (0028,1051)/Window Center (0028,1050) attributes in the DX Image Module (although not simultaneously).
The Image Display or Imaging Document Consumer actor must also support pixel rendering according to the Grayscale Standard Display Function (GSDF) defined in DICOM 2003 PS 3.14, because the output values of these images are always P-Values.
1265
If the DICOM image is referenced by other DICOM composite objects, such as Grayscale Softcopy Presentation States, it is optional for the Image Display or Imaging Document Consumer to actually retrieve and display/apply these objects. 1270
4.16.4.2.2.2 Display of Localizer Lines
Image Display or Imaging Document Consumer actors that want to show the localizer lines, if visible, will be able to calculate the position of these lines of intersection based on the information recorded in the images by the Acquisition Modality actor (See 4.8.4.1.2.1).
1275
Section 4.16.4.2.2.3 remains unchanged.
4.16.4.2.3 Expected Actions
The Image Display or Imaging Document Consumer presents to the user a DICOM Image. 1280
The Image Display or Imaging Document Consumer may receive patient data inconsistent with those received from a previously issued query or retrieve operation. For example, in the event that a patient has been renamed, the Image Display or Imaging Document Consumer will receive images with the same Study Instance UID, Series Instance UID and SOP Instance UIDs, but with a different patient name. The Image Display or Imaging Document Consumer shall use the just queried information or the most recently received instances to ensure that the most recent patient data from the Image Manger/Archive
The Image Display or Imaging Document Consumer shall be able to display the Series Description for each series displayed.
1290
Update the following existing transaction 17
4.17 Retrieve Presentation States This section corresponds to Transaction RAD-17 of the IHE Technical Framework. Transaction RAD-17 is used by the Image Display or Imaging Document Consumer to request and retrieve Presenttaion State from the Image Archive or Imaging Document Source actor. 1295 Image Archive and Image Display actors.
4.17.1 Scope
This section describes the sequence of messages required for the Image Display or Imaging Document Consumer to retrieve Grayscale Softcopy Presentation State Instances from the Image Archive
1300 or Imaging Document Source. The Image Display or Imaging Document
Consumer will query and then retrieve Presentation State objects. The transformations will be applied by the Image Display or Imaging Document Consumer to the image data to assure the image display is consistent with the device that originally created and stored the Presentation State. The Image Display or Imaging Document Consumer will be required to support all transformations defined in DICOM 2003 PS 3.4: Grayscale Softcopy Presentation State Storage. In addition, multiple Presentation States may exist that reference the same image data.
1305
4.17.2 Use Case Roles
Retrieve Presentation
States
Image Display
Image Archive
Imaging Document
Source
Imaging Document Consumer
Actor: Image Display 1310
1315
Role: Retrieve Grayscale Softcopy Presentation State objects together with the referenced image data and apply the transformations specified by the Presentation State. This actor must support pixel rendering according to the Grayscale Standard Display Function (GSDF) defined in DICOM 2003 PS 3.14. This device will implement the Query/Retrieve SOP Classes in the role of an SCU.
Role: Retrieve Grayscale Softcopy Presentation State objects together with the referenced image data and apply the transformations specified by the Presentation State. This actor must support pixel rendering according to the Grayscale Standard Display Function (GSDF) defined in DICOM 2003 PS 3.14. This device will implement the Query/Retrieve SOP Classes in the role 1320 of an SCU.
Actor: Image Archive
Role: Respond to retrieve requests from the Image Display for Grayscale Softcopy Presentation States objects. Transmit requested Grayscale Softcopy Presentation State object(s) to the Image Display. This device will implement the Query/Retrieve SOP Classes in the role of an SCP. 1325
Actor: Imaging Document Source
Role: Respond to retrieve requests from the Imaging Document Consumer for Grayscale Softcopy Presentation States objects. Transmit requested Grayscale Softcopy Presentation State object(s) to the Imaging Document Consumer. This device will implement the Query/Retrieve SOP Classes in the role of an SCP. 1330
4.17.4.1 Retrieve Grayscale Softcopy Presentation State
This transaction refers to the “C-MOVE” and “C-STORE” messages between the Image Display and Image Archive or Imaging Document Consumer and Imaging Document Source actor in the above interaction diagram. The Retrieve (Study Root – MOVE and optionally Patient Root – MOVE) SOP Classes are supported. Refer to the DICOM 2003 PS 3.4 for detailed descriptive semantics.
1340
In the case of retrieving Grayscale Softcopy Presentation State in a Cross-Enterprise, imaging document sharing (XDS-I) network environment, a configuration of mapping the AE Titles to DICOM AE Network Addresses (IP Address and Port number) is needed to be exchanged between the Imaging Document Source and the Imaging Document Consumer. 1345 Appendix Y describes in details the AE Title mapping to the DICOM AE Network Addresses.
4.17.4.1.1 Trigger Events
The Image Display or Imaging Document Consumer selects specific Grayscale Softcopy Presentation State objects to retrieve from the Image Archive.
The message semantics are defined in the DICOM Query/Retrieve Service Class section of the DICOM 2003 PS 3.4: Query/Retrieve Service Class. It is the responsibility of the Image Manager or Imaging Document Source to assure that the patient and procedure information is current in the images and Softcopy Presentation State objects when they are retrieved from the Image Archive
1355
or Imaging Document Source.
4.17.4.1.3 Expected Actions
The Image Archive or Imaging Document Source receives the C-MOVE request, establishes a DICOM association with the Image Display or Imaging Document Consumer actor, 1360 respectively, and uses the DICOM Grayscale Softcopy Presentation State Storage SOP Class to transfer the requested Presentation State objects.
4.17.4.2 View Presentation States
1365 This transaction relates to the “View Presentation States” event in the above interaction diagram. Presentation States cannot be viewed separately, but must be applied to an image. Refer to sec. 4.16 for a description of the transaction used to retrieve images to which Presentation States may be applied.
4.17.4.2.1 Trigger Events
The Image Display or Imaging Document Consumer receives Presentation State instances from the Image Archive
1370 or Imaging Document Source actor, respectively.
4.17.4.2.2 Invocation Semantics
This is a local invocation of functions resident within the Image Display or Imaging Document Consumer. The method used by the Image Display or Imaging Document Consumer to present images for viewing by the user after the Presentation State transformations have been applied is outside the scope of the IHE Technical Framework.
1375
4.17.4.2.3 Expected Actions
The Image Display or Imaging Document Consumer applies the transferred Grayscale Softcopy Presentation State to image data and renders it for viewing. The Image Display or Imaging Document Consumer may receive patient data inconsistent with those received from a previously issued query or retrieve operation. For example, in the event that a patient has been renamed, the Image Display
1380
or Imaging Document Consumer will receive Softcopy Presentation State objects with the same Study Instance UID, Series Instance UID and SOP Instance UIDs, but with a different patient name. The Image Display or Imaging Document
Consumer shall use the most recently queried information or the most recently received instances to ensure that the most recent patient data from the Image Manger/Archive
1385 or Imaging
Document Source actor is displayed.
Update the following existing transaction 27
4.27 Retrieve Reports 1390
This section corresponds to Transaction RAD-27 of the IHE Technical Framework. Transaction RAD-27 is used by the Report Manager, Report Repository, Imaging Document Source, Report Reader, Imaging Document Reader, and External Report Repository Access actors.
4.27.1 Scope
In the Retrieve Reports Transaction, the requested DICOM Structured Reports are transferred from the Report Man
1395 ager, Report Repository, Imaging Document Source or External Report
Repository Access to the Report Reader or Imaging Document Reader for viewing.
4.27.2 Use Case Roles
R etrieve Reports
Report Reader
R eport R epository
External R eport R epository
A ccess
Report M anager
Im aging D ocum ent
Source
Im aging D ocum ent C onsum er
1400 Actor: Report Repository
Role: Sends requested DICOM Structured Reports to Report Reader.
Actor: Imaging Document Source
Role: Sends requested DICOM Structured Reports to the Imaging Document Consumer Actor.
Actor: External Report Repository Access 1405
Role: Sends requested DICOM Structured Reports to Report Reader. Such a system may be required to convert reports of different formats (HL7) into DICOM Structured Reports (see appendix C).
This transaction relates to the retrieve section of the above interaction diagram. The Retrieve (Study Root – MOVE and optionally Patient Root – MOVE) SOP Classes shall be supported. The Report Reader and Imaging Document Consumer as an SCP shall support the DICOM Basic Text SR Storage SOP Class and optionally the DICOM Enhanced SR Storage SOP Class. The Report Manager
1430
, Imaging Document Source and the Report Repository as an SCU shall support both the DICOM Basic Text SR Storage SOP Class and the DICOM Enhanced SR Storage SOP Class. The External Report Repository Access as an SCU shall support the DICOM Basic Text SR Storage SOP Class and optionally the DICOM Enhanced SR Storage SOP Class. Refer to DICOM PS 3.4, Annex C, for detailed descriptive semantics.
The user at the Report Reader or Imaging Document Consumer selects specific reports to view. 1440
1445
4.27.4.1.2 Message Semantics
The DICOM Query/Retrieve SOP Classes and the DICOM Structured Report Storage SOP Classes define the message semantics.
A C-MOVE Request from the DICOM Study Root Query/Retrieve Information Model – MOVE SOP Class or the DICOM Patient Root Query/Retrieve Information Model – MOVE SOP Class shall be sent from the Report Reader to the Report Manager, Report Repository or External Report Repository Access, or from the Imaging Document Consumer to the Imaging Document Source.
4.27.4.1.3 Expected Actions
The Report Manager, Report Repository, Imaging Document Source or External Report Repository Access receives the C-MOVE request, establishes a DICOM association with the Report Reader
1450
or Imaging Document Consumer and uses the appropriate DICOM Structured Report Storage SOP Classes (Basic Text SR Storage SOP Class and/or Enhanced SR Storage SOP Class) to transfer the requested reports.
1455
1460
Report Repository responds to the queries with the information from the DICOM instances it received from the Report Manager. Typically, Report Manager will apply information updates to the instances of reports it holds and re-issue the reports to the Report Repository. To properly update the content of instances that are no longer present on the Report Manager, the update shall be performed by retrieval and re-submission of the report through the Report Manager. It may also be done by grouping the Report Repository and Report Manager.
4.27.4.2 View Reports
This transaction relates to the “View Reports” event of the above interaction diagram.
4.27.4.2.1 Trigger Events
The Report Reader or Imaging Document Consumer receives reports from the Report Repository, Imaging Document Source or External Report Repository Access. 1465
4.27.4.2.2 Invocation Semantics
This is a local invocation of functions at the Report Reader or Imaging Document Consumer, and the method used by the Report Reader or Imaging Document Consumer to interpret and display the report data in a meaningful way is outside the scope of the IHE Technical Framework. At a minimum the Report Reader or Imaging Document Consumer shall be able 1470
to correctly display reports defined in RAD TF-1: 9.4. The Report Reader or Imaging Document Consumer shall be able to display reports based on the Simple Image Report (RAD TF-1: 9.4.1). If the Report Reader or Imaging Document Consumer supports the Enhanced SR Information Object Definition then it shall also support display of Simple Image and Numeric Reports (RAD TF-1: 9.4.2). Even though the IHE Technical Framework sets boundaries on the complexity of SR objects, the Report Reader
1475 or Imaging Document Consumer must still be
able to receive, store and view any Basic Text SR object and optionally any Enhanced SR object in order to conform to the DICOM Standard. An implementation may not be able to render, in a meaningful way, reports more complex than those specified in RAD TF-1: 9.4.
If a DICOM Structured Report references other DICOM composite objects, such as images, and softcopy presentation states, it is optional for the Report Reader
1480 or Imaging Document
Consumer to actually retrieve and display/apply these objects, but the Report Reader or Imaging Document Consumer must convey to the user that such references exist in the report.
4.27.4.2.2.1 Retrieve AE Title
1485 If the Report Reader is grouped with an Image Display and capable of retrieving objects referenced in a DICOM Structured Report then the Report Reader shall retrieve these objects from the device matching the appropriate Retrieve AE Title attribute (0008,0054) included in the DICOM Structured Report. If the Retrieve AE Title attribute is not specified or configured, then the Report Reader may use some other configurable Retrieve AE Title.
In the case of retrieving reports in a Cross-Enterprise, imaging document sharing (XDS-I) 1490 network environment, a configuration of mapping the AE Titles to DICOM AE Network Addresses (IP Address and Port number) is needed to be exchanged between the Imaging Document Source and the Imaging Document Consumer. Appendix Y describes in details the AE Title mapping to the DICOM AE Network Addresses.
4.27.4.2.3 Expected Actions 1495
The Report Reader or Imaging Document Consumer presents to the user a DICOM Structured Report.
Update the following existing transaction 31
4.31 Retrieve Key Image Notes 1500
This section corresponds to Transaction RAD-31 of the IHE Technical Framework. Transaction RAD-31 is used by the Image Display and Image Archive actors.
In the Retrieve Key Image Notes Transaction, the requested DICOM Key Image Notes are transferred from the Image Manager or Imaging Document Source to the Image Display or 1505 Imaging Document Consumer for viewing along with the images flagged by the Key Image Note.
4.31.2 Use Case Roles
Retrieve Key Image Notes
Image Display
Image Archive Imaging Document
Source
Imaging Document Consumer
1510
Actor: Image Archive:
Role: Sends requested Key Image Notes to the Image Display Actor.
Actor: Imaging Document Source
Role: Sends requested Key Image Notes to the Imaging Document Consumer Actor.
Actor: Image Display 1515
Role: Receives requested Key Image Notes from the Image Archive Actor.
Actor: Imaging Document Consumer
Role: Receives requested Key Images Notes from the Imaging Document Source Actor.
The Retrieve (Study Root – MOVE and optionally Patient Root – MOVE) SOP Classes will be supported. The Image Archive and Imaging Document Source as an SCU shall support DICOM Image Storage SOP Classes. Refer to DICOM 2003 PS 3.4, Annex C, for detailed descriptive semantics.
4.31.4.1.1 Trigger Events 1530
The Image Display or Imaging Document Consumer selects specific Key Image Note objects to retrieve from the Image Archive or Imaging Document Source.
The message semantics are defined in the DICOM Query/Retrieve Service Class section of the DICOM 2003 PS 3.4: Query/Retrieve Service Class. It is the responsibility of the Image Manager to assure that the patient and procedure information is current in the images and Key Image Note objects when they are retrieved from the Image Archive. It is the responsibility of the Imaging Document Source to assure that the patient and procedure information is current in the Key Image Note objects when they are retrieved from this Actor.
4.31.4.1.3 Expected Actions 1540
The Image Archive or Imaging Document Source receives the C-MOVE request, establishes a DICOM association with the Image Display or Imaging Document Consumer, and uses the DICOM Key Image Note Storage SOP Class to transfer the requested Key Image Note objects.
4.31.4.2 Render Key Image Notes
1545 This transaction relates to the “Render Key Image Notes” event of the above interaction diagram. Key Image Notes cannot be rendered separately, but must be applied to images. Refer to sec. 4.16 for a description of the transaction used to retrieve images to which Key Image Notes may be applied.
The Image Display or Imaging Document Consumer is not required to, but may choose to, support retrieval and display of images from other studies than the one to which the Key Image Note belongs
1550
4.31.4.2.1 Trigger Events
The Image Display or Imaging Document Consumer receives Key Image Note instances from the Image Archive or Imaging Document Source.
4.31.4.2.2 Invocation Semantics 1555
This is a local invocation of functions resident within the Image Display or Imaging Document Consumer. The method used by the Image Display or Imaging Document Consumer to present images for viewing by the user flagged by the Key Image Notes is outside the scope of the IHE Technical Framework.
4.31.4.2.2.1 Retrieve AE Title 1560
1565
If the Image Display is capable of retrieving objects referenced in a DICOM Key Image Note then it shall retrieve these objects from the device matching the appropriate Retrieve AE Title attribute (0008,0054) included in the DICOM Key Image Note. If the Retrieve AE Title attribute is not specified or configured, then the Image Display shall use some other configurable Retrieve AE Title.
In the case of retrieving DICOM Key Image Notes in a Cross-Enterprise, imaging document sharing (XDS-I) network environment, a configuration of mapping the AE Titles to DICOM AE Network Addresses (IP Address and Port number) is needed to be exchanged between the Imaging Document Source and the Imaging Document Consumer. Appendix Y describes in details the AE Title mapping to the DICOM AE Network 1570 Addresses.
4.31.4.2.3 Expected Actions
The Image Display or Imaging Document Consumer flags the images and renders the Key Image Note.
Note: It is recommended to use the just retrieved instance of the Key Image Note to ensure that the most recent patient data be displayed to reflect possible patient merge and patient update in the Image Manager/Image Archive
1575
or Imaging Document Source. This patient data may be inconsistent with patient data contained in a previously retrieved copy of the same Key Image Note instance.
1580
Volume 3 begins here.
Update the following existing transaction 45
4.45 Retrieve Evidence Documents This section corresponds to Transaction RAD-45 of the IHE Technical Framework. Transaction RAD-45 is used by the Image Archive, Image Display, Imaging Document Source and 1585 Imaging Document Consumer.
4.45.1 Scope
In the Retrieve Evidence Documents Transaction, the requested DICOM Evidence Documents are transferred from the Imaging Archive to the Image Display, or from the Imaging Document Source to the Imaging Document Consumer. 1590
The Retrieve (Study Root – MOVE and optionally Patient Root - MOVE) SOP Classes shall be supported. The Image Archive as an SCU shall support DICOM Storage SOP Classes that may be used as Evidence Documents. The Imaging Document Source as an SCU shall support 1610 DICOM Storage SOP Classes that may be used as Evidence Documents it published for sharing. Refer to DICOM 2003 PS 3.4, Annex C, for detailed descriptive semantics (see vol. III, table 4.38-1).
In the case of retrieving Evidence Documents in a Cross-Enterprise, imaging document sharing (XDS-I) network environment, a configuration of mapping the AE Titles to 1615 DICOM AE Network Addresses (IP Address and Port number) is needed to be exchanged between the Imaging Document Source and the Imaging Document Consumer. Appendix Y describes in details the AE Title mapping to the DICOM AE Network Addresses.
4.45.4.1.1 Trigger Events
The Image Display or the Imaging Document Consumer selects specific Evidence Document objects to retrieve from the Image Archive
1620 or the Imaging Document Source.
4.45.4.1.2 Message Semantics
The message semantics are defined in the DICOM Query/Retrieve Service Class section of the DICOM 2000 PS 3.4: Query/Retrieve Service Class. It is the responsibility of the Image Manager or Imaging Document Source to assure that the patient and procedure information is current in the Evidence Document objects when they are retrieved from the Image Archive
The Image Archive or the Imaging Document Source receives the C-MOVE request, establishes a DICOM association with the Image Display or the Imaging Document 1630 Consumer, and uses the DICOM C-STORE command to transfer the requested Evidence Document objects.
Since the Image Display or the Imaging Document Consumer can select compatible documents based on the Template IDs returned in the query, the Image Display or the Imaging Document Consumer is required not to return an error to the Image Archive or the Imaging 1635 Document Source due to the retrieved document content. The retrieved results may simply be discarded instead.
4.45.4.2 Render Evidence Documents
This transaction relates to the “Render Evidence Documents” event of the above interaction diagram. 1640
4.45.4.2.1 Trigger Events
The Image Display or the Imaging Document Consumer receives Evidence Document instances from the Image Archive or the Imaging Document Source.
4.45.4.2.2 Invocation Semantics
This is a local invocation of functions resident within the Image Display or the Imaging 1645 Document Consumer. Evidence Documents shall be displayed to the user of the Image Display or Imaging Document Consumer. The method used by the Image Display or the Imaging Document Consumer to present Evidence Documents for viewing by the user is outside the scope of the IHE Technical Framework. For example, in the case when an Image Display or an Imaging Document Consumer is grouped with an Evidence Creator, the Evidence Document may be rendered as input for further processing by the Evidence Creator.
1650
4.45.4.2.3 Expected Actions
The Image Display or the Imaging Document Consumer renders the Evidence Documents retrieved. If the Image Display or the Imaging Document Consumer is unable to handle parts of the document, it may inform the user and offer the choice of doing a “low-grade” rendering or ignoring the data.
1655
Evidence Documents may contain references to other types of evidence objects. The Image Display or the Imaging Document Consumer shall always be able to render (or “low-grade” render) referenced Evidence Documents or to invoke other rendering display functionality.
If the Image Display also supports the Consistent Presentation of Images Profile, it is also required to apply any presentation states referenced in the Evidence Document for application to the relevant images.
If the Image Display also supports the Key Image Notes Profile, it is also required to render any Key Image Notes referenced in the Evidence Document.
Note: It is recommended to use the just retrieved instance of the Evidence Document to ensure that the most recent patient data be displayed to reflect possible patient merge and patient update in the Image Manager/Image Archive or the Imaging Document Source. This patient data may be inconsistent with patient data contained in a previously retrieved copy of the same Evidence Document instance.
Add the following new transactions RAD-54 and RAD-55, as well as Appendix Y: Configuration for Accessing DICOM and WADO Retrieve Services
4.54 Provide and Register Imaging Document Set 1675
1680
1685
1690
This section corresponds to Transaction RAD-54 of the IHE Technical Framework. Provide and Register Imaging Document Set is used by the Imaging Document Source to provide a set of imaging documents to the Document Repository, and to request that the repository store these documents and then register them with the Document Registry. This transaction is derived from the Transaction ITI-15 of the IHE IT Infrastructure Technical Framework. It adds new document content types as well as additional semantics and constraints on the metadata defined in Transaction ITI-15.
4.54.1 Scope
The Provide and Register Imaging Document Set transaction passes a Submission Request from an Imaging Document Source to a Document Repository.
A Provider and Register Document Set transaction carries: • Metadata describing
zero or more new documents Submission Set definition along with the linkage to new documents and references to
existing documents Zero or more XDS Folder definitions along with linkage to new or existing documents.
Role: Creates (text and/or PDF) report and/or DICOM KOS Manifest documents, and submits the document(s) with associated metadata to a Document Repository.
Actor: Document Repository
Role: receives documents and associated metadata and: • Stores the documents • Enhances submitted metadata with repository information to enable later retrieval of
documents • Forwards the enhanced metadata to the Document Registry.
An Imaging Document Source sends documents and associated metadata to a Document Repository. This message corresponds to an ebRS SubmitObjectsRequest with associated documents, and is specified in Transaction ITI-15 of the IHE IT Infrastructure Technical Framework, Volume 2.
1720
1725
1730
4.54.4.1.1 Trigger Events The Imaging Document Source Actor, based on a human decision or the application of a certain rule of automatic operation, wants to submit
• A set of one or more new imaging documents for sharing, or • A set of one or more updated imaging documents which reflect the content correction /
change of previously submitted documents.
4.54.4.1.2 Message Semantics
This transaction extends the message semantics of the ITI-15 Provide and Register Document Set by specifying additional document content types, to allow the sharing of the following types of documents:
To support these content types, additional requirements and constraints on the XDS document metadata are specified. The Imaging Document Source is required to include appropriate metadata for the shared documents.
XDS-I Provide and Register Imaging Document Set message semantics are specified in the following subsections:
1. Sharing of Persistent DICOM Instances via a Manifest document
2. Sharing of radiology diagnostic report in PDF or Text formats
3. XDS-I document metadata specification
4. Use of XDS Submission Set concept in sharing of radiology imaging information.
4.54.4.1.2.1 Sharing of Set of DICOM Instances
The Imaging Document Source creates a manifest that describes and collects references to DICOM SOP instances that are intended for sharing. The manifest, a Key Object Selection (KOS) Document Instance, is the actual document provided to the Document Repository and registered at the Document Registry.
As specified in IHE ITI XDS Integration Profile, the structure of the message between the Imaging Document Source and the Document Repository is a MIME “multipart/related” message. The KOS Document Instance to be stored is attached as a part having a MIME type of “application/dicom”. The registration transaction to the Registry must contain an indication of the MIME type (e.g., “application/dicom”).
The referenced DICOM instances are made available to be retrieved from the Imaging Document Source. The Imaging Document Source is required to ensure that the referenced DICOM SOP Instances from within a published manifest are available to be retrieved.
The Imaging Document Source is responsible for replacing a previously submitted manifest document when a change occurs to the manifest content (e.g., Change of the DICOM SOP instances referenced within the manifest).
4.54.4.1.2.1.1 Manifest KOS Document
The Imaging Document Source is required to include the references of the DICOM SOP Instances for sharing in Current Requested Procedure Evidence Sequence (0040,A375) of the KOS Manifest Document.
In addition, the Imaging Document Source shall support a number of attributes in (0040,A375), which are represented in the SOP Instance Reference Macro, as described in the following table
Table 4.54-1. Attributes of SOP Instance Reference Macro in KOS Manifest Document Attribute Name Tag Imaging Document Source
Study Instance UID (0020,000D) R Referenced Series Sequence (0008,1115) R > Series Instance UID (0020,000E) R > Retrieve AE Title (0008,0054) R+ > Stoarge Media File-Set ID (0088,0130) O > Storage Media File-Set UID (0088,0140) O > Referenced SOP Sequene (0008,1199) R >> Referenced SOP Class UID (0008,1150) R >> Referenced SOP Instance UID (0008,1155) R
Some of these requirements build on attributes which are Type 2 or Type 3 in DICOM (such attributes are indicated with R+). 1770
1775
1780
1785
4.54.4.1.2.2 Sharing of Report
Since text reports address many of the weaknesses of PDF reports and vice versa, it is required that the Imaging Document Source shall support shared reports in at least one of the following 3 different formats:
• Text,
• PDF, or
• A single multipart MIME document with corresponding Text and PDF parts.
It is likely that in a given Affinity Domain only a subset of these formats will be used based on Affinity Domain policy.
To maximize interoperability of the chosen formats, the following restrictions shall be required:
• For PDF documents:
Baseline PDF version shall be PDF 1.3 (see IANA registry for details about PDF MIME type, such as version). PDF versions below 1.3 shall be supported.
PDF text encryption feature shall be disabled.
The Affinity Domain will specify restrictions on text fonts and languages used in the PDF documents.
A report (no matter what document format is chosen) can be shared with or without image reference(s).
If a shared report includes image reference(s), it can embed selected images in its PDF format or it can include fully resolved hyperlinks that point to the selected images; these hyperlinks can be interactively clickable (e.g. PDF) or can be processed or copied (e.g. text).
The Imaging Document Source that provides and registers the shared report is responsible for formatting the hyperlink to reference relevant images. The referenced images within a shared imaging report are meant to be accessed without the need for specialized (e.g., DICOM) viewing applications.
The hyperlink that reference the selected image shall be formatted as a DICOM WADO URI.
The Imaging Document Source is required to ensure that image references are valid links.
Even though significant images can be shared as non-DICOM format (embedded picture in PDF report or hyperlinks in PDF or Text report), it is required that sharing of a large set of DICOM images be achieved by sharing a set of DICOM SOP instances by providing and registering a manifest document. This is to avoid registration of a large number of individual documents in the XDS Document Registry.
4.54.4.1.2.3 Metadata
The Register Document Set message shall include the metadata attributes that will be forwarded by the XDS Document Repository Actor to the Registry Actor using the Register Document Set Transaction (ITI-14).
The Imaging Document Source supplies all necessary registry object attributes of an XDSDocumentEntry with the exception of the following attributes:
XDSDocument.URI
XDSDocument.hash
XDSDocument.size
This is the legend for the metadata tables that follow: • Optional - required status of the XDS attribute, one of R, R2, or O (optional). • Constrained – does this Content Profile further constrain this attribute. • Source Type – one of the following values:
Source Type
Description
SA Source document Attribute – value is copied directly from source
document. The Source/Value column identifies where in the source document this attribute comes from. Specify the location in XPath when possible.
SAT Source document Attribute with Transformation – value is copied from source document and transformed. The Source/Value column identifies where in the source document this attribute comes from. Specify the location in XPath when possible. Extended Discussion column must be ‘yes’ and the transform must be defined in the extended discussion
FM Fixed (constant) by Mapping - for all source documents. Source/Value column contains the value to be used in all documents.
FAD Fixed by Affinity Domain – value configured into Affinity Domain, all documents will use this value.
CAD Coded in Affinity Domain – a list of acceptable codes are to be configured into Affinity Domain. The value for this attribute shall be taken from this list.
CADT Coded in Affinity Domain with Transform - a list of acceptable codes are to be configured into Affinity Domain. The value for this attribute shall be taken from this list.
n/a Not Applicable – may be used with an optionality R2 or O attribute to indicate it is not to be used.
DS Document Source – value comes from the Document Source actor. Use Source/Value column or Extended Discussion to give details.
O Other – Extended Discussion must be ‘yes’ and details given in an Extended Discussion.
Cg Computed by Repository Cp Computed by Registry
4.54.4.1.2.3.1 Metadata Attributes of Author Information and Document Creation Time
In XDS, a registered document directly contains the clinical information of interest for sharing. Therefore, its metadata for registration can be populated directly from the document content. For example, a discharge letter is submitted to the Document Repository, so its author and creation information is populated into the XDS Document metadata.
1825
1830
In XDS-I, the Manifest document submitted to the Document Repository usually does not directly constitute clinical information of interest for sharing, but rather is a set of references to such clinical information. Thus, the metadata of the Manifest document should be related to the
referenced source content or its creation process, to reflect the clinical nature of the shared information. This affects the metadata attributes including authorSpecialty, authorInstitution, authorPerson, authorRole, creationTime, title.
If the manifest references source data from multiple authors, then one primary author, source data creation time and document title need to be chosen. Note that this metadata needs to be populated from this part of the source data that represents the main content for sharing most closely, in order to best support a user query to the Registry for finding this data. For example, a manifest referencing a current report, a current study as well as a prior report and study, will register metadata populated from the current report (which is the clinical content of interest for sharing).
In case where data to be shared is transformed from its original format (e.g. DICOM) to another format (e.g. PDF) in advance to sending it to the Repository, the metadata of such newly generated shared information must be populated from the original source data (e.g. DICOM data)
In summary, XDS-I metadata always reflects the main clinical content of a shared document, which may be described directly in the document, or in the source data referenced within the document, or in the source data from which the document is transformed.
4.54.4.1.2.3.2 XDSDocumentEntry Metadata
XDSDocumentEntry
Attribute
Optional Constrained
Extended Discussion
Source Type
Source/ Value
authorSpecialty R2 DS This attribute value shall be populated by the source actor from local configuration available to its software application. Usually, this value is not taken directly from a DICOM information object.
authorInstitution R2 DS This attribute value shall be populated by the source actor from local configuration available to its software application. Usually, this value is not taken directly from a DICOM information object.
authorPerson R2 DS
This attribute value represents the person or the machine who authored the document, and shall be populated by the Imaging Document Source from information about the user who authored the clinical content that is intended for sharing in the document (either the person who is logged in or the software application).
Note: this attribute does not necessarily represent the person who digitally signed
authorRole R CAD This Attribute value shall be populated by the Imaging Document Source from a list of codes designated by the Affinity Domain, to describe the clinical role of the author.
authorRoleDisplayName
R CAD The name of the authorRole code to be displayed.
classCode R CAD This attribute value shall be populated by the Imaging Document Source from a list of codes designated by the affinity domain.
It is a coarse classification of the documents such as Result.
classCodeDisplayName
R CAD The name of the class code to be displayed.
confidentialityCode R CAD This attribute value shall be populated by the source system from a list of codes designated by the affinity domain.
creationTime R SA This attribute value shall be populated by the source actor to record the date and time at which the clinical content conveyed in the shared document is created.
If the published document is a DICOM object or is transformed from a DICOM information object, this attribute value should be taken from the tags Instance Creation Date (0008,0012) and Instance Creation Time (0008,0013) of the DICOM object.
eventCodeList O
R2 SA This attribute shall be populated by the Imaging Document Source from code(s) in DCMR Context Group CID 29 for Acquisition Modality and from code(s) in DCMR Context Group CID 4 for Anatomic Region
This attribute can contain multiple codes and there is not any specific ordering assumed in these codes.
For DCMR Context Groups, see DICOM PS 3.16-2004.The presence of this attribute is strongly recommended.
eventCodeDisplay R R2 SA This attribute contains the Code Meaning
text(s) of the code(s) for Acquisition Modality and for Anatomic Region valued in eventCodeList, from DCMR Context Group CID 29 and from DCMR Context Group CID 4, respectively.
Note that the ordering of the Code Meaning texts populated in this attribute shall be sorted in the same order of the corresponding codes in eventCodeList.
For DCMR Context Groups, see DICOM PS 3.16-2004.
formatCode R FM This attribute shall be populated by the Imaging Document Source from one of the following values:
“1.2.840.10008.5.1.4.1.1.88.59” (DICOM KOS SOP Class UID) as the Format Code Value and “1.2.840.10008.2.6.1” (DICOM UID Registry UID) as the Format Coding Scheme OID for a DICOM Manifest document.
“TEXT” for a TEXT report document
“PDF” for a PDF report document
“PDF/TEXT” for a PDF and Text Multipart document.
healthcareFacility TypeCode
R
CAD This attribute shall be populated by the source from a configured list that is defined by the affinity domain
healthcareFacility TypeCodeDisplay Name
R CAD The display name of the healthcare facility.
languageCode R CAD This attribute shall be populated by the source by taking a value from the language tags specified in RFC 3066
Example: “en-us” for English in the United States.
legalAuthenticator O If information about the legal authenticator is unknown, no value shall be filled in this attribute.
Otherwise, this attribute can be populated by the Imaging Document Source to
indicate the legal authenticator of the shared document.
mimeType R FM This attribute shall be populated by the Imaging Document Source from one of the following values:
“application/dicom” for a DICOM Manifest document
“text/plain” for a TEXT report.
“application/pdf” for a PDF report
“multipart/related” and parts shall be “text/plain” and :application/pdf” for a multipart report
parentDocument Relationship
R (when applicable)
DS
This attribute value shall be populated by the source actor by taking one of the three values defined in the IHE ITI XDS Integration Profile to describe the relationship of this document and previously published document(s), if the current document updates, amends or deprecates those documents.
parentDocumentId R (when parent Document Relationship is present)
DS
If the parentDocumentRelationship is present, this attribute shall contain the OID of the parent Document
patientId R DS This attribute shall contain the Patient ID of the patient, who is the subject of the document, and shall be populated by the Imaging Document Source.
The Assigning Authority of this Patient ID shall be the Affinity Domain.
practiceSettingCode R
FAD This attribute shall be populated by the Imaging Document Source by taking a fixed code defined by the affinity domain to designate “Radiology”
practiceSettingCode DisplayName
R FAD The display name of the practice setting code.
serviceStartTime R2 DS This attribute shall be populated by the Imaging Document Source for a date and time that indicates the imaging service start time.
As an example, the Imaging Document Source could take the value of Study Date (0008,0020) and Study Time (0008,0030) from the associated DICOM study
serviceStopTime R2 N/a
sourcePatientId R SA This attribute shall represent the Patient ID of the patient, issued from a local domain used in the Imaging Document Source, who is the subject of the document, and shall be populated by the Imaging Document Source
The Assigning Authority of Patient ID shall represent the local patient identification domain.
sourcePatientInfo R DS This attribute shall represent the Patient demographics information used in the Imaging Document Source actor system to identify the patient.
This attribute allows multiple values for different pieces of patient demographics, see metadata specification of the IHE ITI XDS Integration Profile.
As an example, this information can be transformed from DICOM Patient’s Name (0010,0010), Patient’s Birth Date (0010,0030), and Patient’s Sex (0010,0040).
title O DS This attribute can be populated by the Imaging Document Source application for the text title of the document.
Example: CT of the head
typeCode R
SA This attribute shall be populated by the source actor from a coding system of the Requested Procedure Code of the Requested Procedure, to which the document is associated.
The coding system of the Radiology Imaging Requested Procedure Code will be designated by the affinity domain and shared by all Imaging Document Sources in the affinity domain.
R SA This attribute shall be filled by the source actor using the code meaning text of the corresponding Requested Procedure Code valued in typeCode.
uniqueId R SA This attribute shall contain the Document unique ID generated by the source actor. It shall be an ISO OID.
For a DICOM Manifest document, this attribute value shall be the same as the SOP Instance UID of the corresponding DICOM KOS object.
entryUUID R Cg This attribute shall be computed and populated by the Document Registry.
Size R Cp This attribute shall be computed and populated by the Document Repository.
Hash R Cp This attribute shall be computed and populated by the Document Repository.
availablityStatus R Cg This attribute shall be computed and populated by the Document Registry.
4.54.4.1.2.3.3 XDSSubmissionSet Metadata 1850
XDSSubmissionSet
attribute
Optional Constrained Extended Discussion
Source Type
Source/ Value
authorDepartment R2 DS This attribute shall be populated by the source actor from local configuration available to its software application.
authorInstitution R2 DS This attribute shall be populated by the source actor from local configuration available to its software application.
authorPerson O DS This attribute can be populated by the source based on the information about the person who is logged in the software application and who is taken the decision to publish the Submission Set.
comments R2 DS This attribute shall contain free text entered by a human user or generated by the source actor to describe this Submission Set.
contentTypeCode R CAD This attribute shall be populated by the source from a configured list of codes defined by the affinity domain
contentTypeCode DisplayName
R CAD The display name of the Type Code.
patientId R CAD This attribute shall contain the Patient ID of the patient, who is the subject of the Submission Set, and shall be populated by the Imaging Document Source.
The Assigning Authority of this Patient ID shall be the Affinity Domain.
sourceId R DS This attribute shall be populated by the source actor from local configuration available to its software application
submissionTime R DS This attribute shall be populated by the source actor to record the date and time, at which the Submission Set is sent to the Document Repository
uniqueId R DS This attribute shall contain UID of the Submission Set generated by the source actor
4.54.4.1.2.3.4 Transformation of DICOM VR to XDS Document Metadata Data Types
1855
1860
A number of XDS document metadata attributes use HL7 data types for value representation. Some of the metadata attributes may be transformed from data elements of the corresponding DICOM SOP Instance. In this section, transformations of DICOM VR (Value Representation) to the HL7 data types used in XDS metadata are described.
Note that term HL7 Data Type in the following transformations refers to their specified usage in XDS document metadata as defined in IHE ITI XDS Integration Profile.
4.54.4.1.2.3.4.1 CX – Extended Composite ID
The following table describes the transformation of data element of DICOM VR to CX data type as specified in IHE XDS Integration Profile:
CX Data Component
Component Name DICOM VR Comment
1 ID Number LO This attribute represent the value of
Patient ID issued by an Assiging Authority as indicated in component 3. In DICOM, it is data element (0010,0020).
3.2 Assigning Authority – Universal ID
Assigning Authority information is not required in DICOM instance. The Imaging Document Source must use its local configuration to populate this subcomponent, to inidcate the Patient ID Domain, from which the Patient ID value in component 1 has been issued. This must be an ISO OID
3.3 Assigning Authority – Universal ID Type
This must be “ISO”
5 Identifier Type Patient ID Type information is not required in DICOM instance. The Imaging Document Source can use its local configuration to populate this component, to inidcate the type of the Patient ID value in component 1.
HL7 CX data components not listed in the table are not used in XDS document metadata and shall be left empty. 1865
1870
4.54.4.1.2.3.4.2 DTM – Date / Time
HL7 DTM Data Type can be represented in the following regular expression:
YYYY[MM[DD[HH[MM[SS]]]]]
This can be transformed from DICOM elements of VR DA (format: YYYYMMDD) and TM (format: HHMMSS.fraction).
4.54.4.1.2.3.4.3 XCN – Extended Composite ID Number and Name for Person
The following table describes the transformation of DICOM VR to XCN data type as specified in IHE XDS Integration Profile:
XCN Data Component
Component Name DICOM Data Element
Comment
1 ID Number This attribute component is not required in DICOM. Imaging Document Source must use its local configuration or personnel direcotory service to populate this component. Is this the patient ID for a patient or the performer id , this is not clear
2 Family Name 1st Component of PN
A data element of VR PN, like (0010,0010) for Patient Name.
4 Second or Further Given Names or Initials Thereof
3rd Component of PN
5 Suffix 5th Component of PN
6 Prefix 4th Component of PN
7 Degree This attribute component is not required in DICOM.
HL7 XCN data components not listed in the table are not used in XDS document metadata and shall be left empty. 1875
4.54.4.1.2.3.4.4 XON – Extended Composite Name and Identification Number for Organization
The following table describes the transformation of DICOM VR to XON data type as specified in IHE XDS Integration Profile:
XON Data Component
Component Name DICOM Data Element
Comment
1 Organization Name LO A data element of VR LO, like (0008,0080) for institution name.
1880
1885
1890
HL7 XON data components not listed in the table are not used in XDS document metadata and shall be left empty.
4.54.4.1.2.4 Use of XDS Submission Set
4.54.4.1.2.4.1 Linking Report to Set of DICOM Instances
Figure 4.45.4 -1 shows examples of three Submission Sets: • Submission Set 1 includes a report and a Manifest that are stored in the Document
Repository. The manifest references DICOM instances that are archived in the IM/IA. • Submission Set 2 includes one single manifest. • Submission Set 3 includes a report and references the manifest from Submission Set 2 since
it was generated by interpreting the images referenced by that manifest. Submission Set 3 also references the report and the manifest form Submission Set 1 since that report and images that are referenced by that manifest were used for the interpretation.
Figure 4.45.4 -1 Imaging Information Sharing Submission Set
4.45.4.1.2.2.2 Linking Report to prior report 1895
1900
1905
1910
The Report Submission Set can reference the manifest for a set of prior images published if the prior images were used in creating the interpretation. Likewise the report submission set can reference a report from a previous submission.
4.54.4.1.3 Expected Actions
The Document Repository Actor will receive this message. Each document within the message will be stored into the repository. A detected failure will result in an error result message being returned to the Imaging Document Source Actor thus terminating this transaction.
If there is no error detected, as each document is stored into the repository, one URI must be created for the document, to reference it via an HTTP service.
The Document Repository Actor will complete the received document metadata, to prepare these for document registration, as specified in transaction ITI-15. The Document URI created above, will be added in the metadata for each document deposited in the repository via an ebRIM object ExtrinsicObject (see IHE ITI XDS Integration Profile). The Document Repository Actor must also add the attributes discussed in Section 4.54.4.1.2.1, to the metadata.
4.55 WADO Retrieve This section corresponds to Transaction RAD-55 of the IHE Technical Framework. Transaction RAD-55 is used by the Imaging Document Consumer and the Image Manager/ Image Archive actors.
4.55.1 Scope
The WADO Retrieve transaction enables an Imaging Document Consumer to access DICOM SOP Instances with a web-based service through HTTP/HTTPS protocol.
4.55.2 Use Case Roles
WADO Retrieve
Imaging Document Consumer
Imaging Document Source
Actor: Imaging Document Consumer
Role: Issues an HTTP Get Request to access a DICOM instance. 1925
1930
Actor: Imaging Document Source
Role: Receives an HTTP Get Request for accessing a DICOM instance and generates the HTTP response with the appropriate content.
4.55.3 Referenced Standard
DICOM 2004 PS 3.18: Web Access to DICOM Persistent Objects (WADO)
The Imaging Document Consumer issues an HTTP Get to request a specific DICOM instance from the Imaging Document Source. The Imaging Document Source receives the request, generates the response with the appropriate content and sends an HTTP Response to the Imaging Document Consumer.
1935
1940
1945
4.55.4.1.1 Trigger Events
The Imaging Document Consumer wishes to retrieve a DICOM instance that is referenced within a DICOM Manifest.
4.55.4.1.2 Message Semantics
The message semantics are defined by the DICOM Web Access to DICOM Persistent Objects (WADO), PS 3.18.
The WADO Retrieve transaction is performed by the Imaging Document Consumer to send a HTTP Request-URI to the web server of the Imaging Document Source. The Imaging Document Consumer generates the HTTP Request-URI to retrieve a DICOM instance. The DICOM instance shall be specified with its Study Instance UID, Series Instance UID, and SOP Instance UID in the HTTP Request-URI. The Imaging Document Consumer must obtain the host information (e.g., web server location, and script language) of the web server to perform this
1950 transaction. The Imaging Document Consumer can map the Retrieve AE Title of the SOP Instance to the web server host information based on its local configuration (see Appendix Y).
In addition, the Imaging Document Consumer shall support the following fields in the HTTP request:
Table 4.55-1. WADO HTTP Request Fields HTTP Field REQ Description Values Accept R This field is used to specify MIME
types which are acceptable for the response
At least one of the following values: application/dicom image/jpeg application/text application/html */*
Other values may be included as well
Accept-Language
O This field specifies the language of the object to be retrieved.
Any valid value according to RFC2616
1955
1960
The Imaging Document Source shall list all media types it supports in the Accept field of the HTTP request, and shall use WADO HTTP parameter contentType to request the desired media type of the object to be retrieved in the HTTP response (see Table 4.55-2).
The Imaging Document Source and the Imaging Document Consumer are required to support a number of parameters in the WADO HTTP Request-URI, as described in the following table.
Table 4.55-2. WADO HTTP Request Parameters
Requirement Parameter Name Parameter Description Imaging
Document Source
Imaging Document Consumer
Note
requestType Type of the HTTP request performed. It must be “WADO”
R R
studyUID Unique identifier of the study R R seriesUID Unique identifier of the series R R objectUID Unique identifier of the object R R contentType MIME type of the pesponse R+ R+ IHE-1
IHE-2 charset Charset of the response O O anonymize Anonymize object O O annotation Annotation of the object O O IHE-3
rows Number of pixel rows O O IHE-3 columns Number of pixel columns O O IHE-3 region Region of image O O IHE-3 windowCenter Window center of the image O O IHE-3 windowWidth Window width of the image O O IHE-3 frameNumber Frame number of the single frame
in a multi-frame image O O IHE-3
imageQuality Image quality factor O O IHE-3 presentationUID Unique identifier of the
presentation object O O IHE-3
presentationSeriesUID Uniquer identifier of the series containing the presentation object
O O IHE-3
transferSyntax Transfer syntax UID used with DICOM image object returned in the response
O O IHE-3
IHE-1: The Imaging Document Consumer must use the value “application/dicom” to retrieve a DICOM SOP Instance in the DICOM Part 10 File Format. This allows the Imaging Document Consumer to receive a SOP Instance in the native DICOM format for full data manipulation. 1965
1970
1975
1980
The Imaging Document Consumer can also use the value “application/jpeg” to retrieve an image encoded in JPEG baseline format if it is a single frame DICOM image object or a single frame image encoded in a multi-frame DICOM image object.
The Imaging Document Consumer can also use the values “application/text” or “application/html” to retrieve a DICOM SR object represented in the text or html format.
The Imaging Document Consumer can also use other values for this parameter as specified in DICOM PS 3.18, if they are supported by the Imaging Document Source.
This parameter is optional in DICOM PS 3.18. Because the default format of the DICOM persistent object returned in the HTTP Get response in the absence of a value in this parameter varies depending on the SOP Class of the retrieved object, this profile requires that the parameter is supported, to improve interoperability.
IHE-2: This parameter must be compatible to the value(s) that the Imaging Document Consumer placed in the Accept field of the HTTP Request-URI.
IHE-3: The parameter applies only to a DICOM SOP Instance if it is an image object.
This example uses reponse MIME type application/dicom to request the DICOM SOP Instance returned in the native DICOM Part 10 file format.
4.55.4.1.3 Expected Actions
Upon reception of the WADO HTTP Request, the Imaging Document Source shall parse the request and if there are no errors, shall construct an HTTP Get Response with the requested DICOM instance content and return the response as specified by the DICOM WADO standard, with HTTP response code 200 (OK).
The Imaging Document Source shall return HTTP response code 406 (Not Acceptable), if it cannot serve the requested response MIME type(s) in parameter contentType and/or Accept Field.
The Imaging Document Source shall return HTTP response code 404 (Not Found) if it cannot locate the requested DICOM SOP Instance or cannot recognize the UID values specified in the received HTTP Request-URI.
The Imaging Document Source shall return HTTP response code 400 (Bad Request) if any required HTTP field or required WADO HTTP parameters are missing in the received HTTP Request-URI, or any other syntactic error is detected in the HTTP Request-URI (e.g., media type in contentType parameter conflicts with media types in Accept field).
4.55.4.1.4 Audit Trial Trigger Events
IHE specifies a number of events that shall be reportable by means of the IHE Audit Trail (ITI TF-II 3.20). IHE Radiology Audit Trial Option further defines a subset of these events, which are particularly applicable to the radiology transactions.
Table 4.55-3 lists all the radiology audit trial trigger events applied to transaction RAD-55. The last column specifies whether the sender or receiver side of the transaction is required to audit the event.
Appendix Y. Configuration for Accessing DICOM and WADO Retrieve Services
Y.1 Mapping DICOM AE Title to DICOM AE Network Address When an Imaging Document Consumer wants to retrieve DICOM instances that are referenced within a shared manifest Document using DICOM C-Move/C-Store, the following configuration is necessary.
The Key Object Selection Document Instance includes an AE Title but does not include any IP address or any port number. As AE Title alone is not sufficient to retrieve DICOM objects, the Imaging Document Consumer needs to get the IP address and the port number of the Imaging Document Source from its local configuration file.
Similarly, the Imaging Document Source needs to know the AE Title, the IP address and the port number of the Imaging Document Consumer in order to store the DICOM objects. The Imaging Document Source needs to get the IP address, the AE Title, the port number of the Imaging Document Consumer from its local configuration file.
In this profile, it is assumed that mapping of AE Titles of Imaging Document Source and Imaging Document Source to their network presentation addresses (IP and port) is supported by exchanging configuration files of the related actors, under the guidance of affinity domain policies and processes. The method of configuration file exchange is out of the scope of this profile. In the future, DICOM Supplement 67 (Configuration Management) and its proper extension in cross-enterprise use can be employed to automate this mapping. This may be a future Integration Profile candidate of IHE IT Infrastructure.
As IP addresses and port numbers need to be resolved from AE titles, a special attention is required to ensure that AE titles of actors that are involved in this profile are uniquely allocated in an affinity domain.
Y.2 Mapping DICOM AE Title to WADO Service Network Address In order for an Imaging Document Consumer to retrieve DICOM instances referenced within a shared Manifest Document using WADO Access transaction (RAD-55), it needs to build a WADO HTTP Request-URI for the SOP instance. Though SOP instance identification information is fully specified in the Manifest, the Imaging Document Consumer needs an auxiliary method to map the Retrieve AE Title specified for a referenced SOP Instance in the Manifest to the server network address, which supports the WADO retrieve service.
The Imaging Document Consumer needs to maintain a mapping configuration of the server network addresses of all Imaging Document Source in the Affinity Domain, and their Retrieve AE Titles. Using this mapping, the Retrieve AE Title of a referenced SOP instance in the
Manifest can be translated to WADO service server address, which is then used to build the WADO HTTP Request-URI together with SOP instance identification information, and optionally other standard WADO HTTP parameters.
To achieve an unambiguous, automated mapping of Retrieve AE Title and WADO access service server network address, some policy needs to be in place to ensure unique Retrieve AE Titles of Imaging Document Source in the entire Affinity Domain.