ACC, HIMSS and RSNA
Integrating the Healthcare Enterprise
IHE Radiology Technical Framework
Supplement 2004-2005
Cross-enterprise Document Sharing for
Imaging (XDS-I)
Rev. 1.0
Draft for Public Comment
Comments due July 12, 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 https://www.doczj.com/doc/ea6027012.html, or https://www.doczj.com/doc/ea6027012.html,/IHE.
__________________________________________________________________________
1
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 submitted for Public Comment between June 15, 2005 and July 12, 2005.
Comments shall be submitted before July 12, 2005 to:
https://www.doczj.com/doc/ea6027012.html, under the “IHE” forum
Select the Radiology Supplements for Public Review sub-forum.
The IHE Radiology Technical Committee will address these comments and publish the Trial Implementation version in August 2005.
__________________________________________________________________________
2
Date: June 14, 2005
Authors: Radiology Technical Committee
These ”boxed” instructions for the author to indicate to the Volume Editor how to integrate the relevant section(s) into the overall Technical Framework
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, surgeon, 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. 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. Proposed Solution
The Cross-Enterprise Document Sharing 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
__________________________________________________________________________
3
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 “for display” form to minimize the needs for receivers to
“process” the report content and associated risk of misrepresentation.
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 teleradiology, 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. XDS Integration Profile builds upon and depends on parts of the IT-I Integration Profiles, such as Patient ID Cross-Referencing (PIX) and Audit Trail and Node Authentication (ATNA). Patient uniform identification, security and privacy capabilities are necessary to properly manage access to shared imaging information. However they are not specified as part of this profile as an implementation can group actor(s) of this Integration Profile with actors in other IHE Integration Profiles, to address these issues.
Open Issues and Questions
1. We solicit feedback from the IT-I Technical Committee members on the “XDS Content
Profile” appendix.
2. As specified in the present document, the Document Consumer can use either WADO or
DICOM C-Move/C-store services as the mechanism to retrieve DICOM instances that
__________________________________________________________________________
4
are referenced within the shared manifest document. The Image Manager/ Image Archive is currently required to support both mechanisms. The Radiology Technical Committee
solicits feedback on this approach
3. The EventCodes metadata attribute is valued with one or more codes. DICOM context
ID 4 and 29 are selected for the possible Code Values of Modality and Body Part. We
solicit public feedback on this choice.
4. The FormatCode metadata attribute: Needs standard codes to designate TEXT, PDF, or
combination. “PDF/IHE 1.x” where 1.x indicates the PDF version of the document, could be used for PDF and “TEXT/IHE” for text documents. We think that IT Infrastructure
Technical Committee should define these codes.
5. Need to coordinate references to XUA. Where should this profile reference XUA?
6. The Technical Committee believes that DICOM SR objects can be shared as a DICOM
instances as part of an extensive DICOM set without including the Report Repository as an Actor in this profile. We solicit public feedback on this choice.
Closed Issues
1. We need to give an example of query as an informative text in an appendix. IT-I will
provide such example in the XDS Profile
2. Add an appendix on WADO security. ATNA has what is needed for http
3. Add a volume-one informative appendix on the XDS-I security environment as it
involves the direct communication between the Document Consumer and the IM/IA that holds the images. Appendix has been added in volume one in XDS-I. This appendix may be moved from the radiology TF to the ITI TF in the future.
4. “Title” attribute in the metadata is optional. We discussed if this should be required and
have decided to keep it optional.
5. What is the mime type of a multipart report document? It is “multipart/related”. We have
discarded “multipart/report” as this mime type is about status reports. We have discarded “multipart/mixed” as this mime type seems to imply an order of the parts matters.
6. We decided that body part modifier is not to be included in the event code list as this
level of details is not needed in the metadata.
7. The order of the event code list is not important/
8. Sharing of non-DICOM images – specify the rules for applying presentation states to
shared non-DICOM images. We have decided to recommend it. The discussion on this
should go in the provide & register transaction
9. The document Source should replace or deprecate the published manifest whenever the
referenced instances are changed or deleted. It should also replace any published
Document whenever the diagnostic content is changed due to any patient reconciliation.
__________________________________________________________________________
5
These are the main rationales behind requiring the grouping of the Document Source and the IM/IA.
10. There is no defined option for the Document Consumer as options are at the transaction
level and the user can refer to the DICOM conformance statement to identify the
implemented transactions
11. Three options are defined for the Document Source. The user can thus refer to the IHE
integration statement to identify the document types that the Document Source is capable of sharing
12. In order to enable the Document Consumer to retrieve DICOM instances, do we create a
Generic Retrieve transaction or do we group Document consumer with image display or report reader.
a. We require the Document Consumer to support at least one of the IHE retrieve
transactions.
13. Configuration issues with DICOM retrieval (on both doc consumer & source) –
specifically mapping AE Titles to IP address/ ports
a. We have decided not to mandate a specific solution such as manual configuration
or DICOM configuration management
14. We have decided to include only one metadata table to describe the attributes of the
various document types.
15. Do we have to mention Cardiology?
a. No, but state that that we have not addressed cardiology because the cardiology
technical committee intends to address this topic in the near future
16. FormatCode: Need a code to say DICOM Manifest
a. Use the Key Object Selection SOP Class UID as the formatCode of the manifest
b. State that the format code of a DICOM object is its SOP class UID.
17. What value to put in the LegalAuthenticator
a. DICOM verifying Observer when available
b. LegalAuthenticator is a multi-valued attribute. Therefore is can hold several
verifying observers.
18. Do we still need the section that compares PDF and text that was an appendix in the
white paper?
a. There is no value added to include this section in the final version, as we usually
do not publish rationale. Rewrite the entire text and present it as suggestions about
when to encode PDF, text or both. Anything useful in the rationale about why we
have decided to keep both format
__________________________________________________________________________
6
19. Is there an issue with the document type containing modality & body part for manifests?
a. Not believed to be an issue at this time.
20. Can we add DICOM transactions to the Registry?
a. No. This desire is mitigated by use of brokering technologies grouped with
existing Radiology actors to provide the XDS-specific transactions (to repository
or registry)
21. How are diagnostic reports shared?
a. This profile describes distribution of text & PDF reports. It allows any DICOM
object to be shared (via manifest). DICOM SR reports can be shared like any
other DICOM object. Transform of DICOM SR to text or PDF is not specified.
b. This answer no longer holds since we have not considered SR in this version
22. How is coded data shared (e.g., evidence documents)?
a. This profile allows any DICOM object to be shared (via manifest). DICOM SR
evidence documents can be shared like any other DICOM object. Inclusion of
DICOM SR into text or PDF report is not specified.
23. Radiology repositories (e.g., IM/IA, Report Repositories) would allow “affinity domain-
wide” requests for information from document consumers.
24. Do we mandate text and PDF documents that are derived from SR to reference to the
complete published set that contains the SR instance?
a. No, unless SR is sole object in the set. Also will be very difficult to determine the
exact nature of the transform. In general referencing the manifest should imply
referencing of the complete contents of the manifest.
25. What about PDF and text OIDs, do we mandate a DICOM instance style OID?
a. No, OID rules defined by XDS.
26. Do we discard the CDA/Style Sheet solution?
a. Yes – discarded for now, may be considered in the future. Coded data will be
necessary but is not currently widely implemented and overheard to encode/decode is
a barrier to entry.
27. Is there any constraint on the manifest to reference images from the same study? Do we
constrain the publication for a single study so we use the study instance UID as the
document OID
a. Currently this is a constraint, though in practice it’s expected that most manifests
will reference images within a single study. In the near future DICOM is expected to
provide an update to the Key Object Selection Template, which may in the future
remove this limitation. At that time the manifest should use that template.
__________________________________________________________________________
7
28. Do we require that the Key Object Selection Document Instance be signed and referenced
objects digest included
a. No. A trusted relationship is assumed between IM/IA & Doc Source actors.
29. parentDocumentRelationship. Do we require XDSI document source to have the
capability to do a document replacement? Is it an option or required capability
a. We have to define the circumstances when a replacement is necessary
b. It is required that the Document Source replaces the shared document when
necessary.
c. The cases when a Document Source is required to replace the manifest are:
i. The availability status change (we need to investigate whether this status
is encoded within the manifest)
ii. Any change that results in a sop instance UID change of referenced
instances
iii. Addition or deletion of a reference from within the manifest
iv. When any value of the required query keys has changed (review the list of the required query key to decide on the rule to specify)
We have closed this issue, as it is discusses in the PIR section
30. PIR must be factored-in to any Imaging Information Sharing profile developed.
Considerations:
a. Reconciliation beginning in the Affinity domain to individual enterprise(s)
b. Reconciliation beginning in the Individual enterprise(s) to Affinity Domain
c. ITI solution may require adaptation based on differences between Imaging
Information Sharing and XDS (e.g., images stored outside repository and manifest
pointing to those images)
d. We have analyzed PIR and will submit our analysis to ITI technical committee Profile Abstract
This Supplement introduces a new IHE Integration Profile that facilitates the sharing of Imaging Information across health enterprises. Imaging Information includes extensive sets of DICOM instances, diagnostic reports provided in a “for display” form and a selection of diagnostically significant images associated with the report content.
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 Electronic Health Record.
__________________________________________________________________________
8
__________________________________________________________________________
9Volume 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 extensive sets of DICOM
instances, imaging reports in a “for display” format, as well as significant images in non-
DICOM format.
Cross-enterprise Document Sharing for Imaging Integration Profile
Dependencies 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
… … …
… Cross-Enterprise Document Sharing for Imaging IT Infrastructure Cross-Enterprise Document Sharing (XDS) Document Source, Document Consumer, Document Registry, Document Repository actors are required to support XDS
Documents, 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)
The Cross-enterprise Document Sharing for Imaging 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. It 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 “for display” form to minimize the needs for receivers to “process” the report content, and a selection of diagnostically significant images associated with the report content.
As there are multiple types of information that can be shared, actors participating in this profile are required to exchange at least one information type.
Add the following to 2.2 Actor Descriptions
2.3 Actor Descriptions
Document Source - The Document Source actor is the producer and publisher of documents.
It is responsible for putting documents into a Document Repository actor. It also
supplies meta-data to the Document Repository Actor for subsequent registration of
the documents with the Document Registry actor.
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.
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
__________________________________________________________________________
10
__________________________________________________________________________
11Table 2.2-1. Integration Profile Actors
Integration
Profile
Actor SWF PIR PWF RWF CHG CPI PGP KIN ED SINR PDI ARI SEC XDS-I
Acq. Modality
X X X X X X X ADT Patient Reg.
X X X X Audit Record Rep
X Charge Processor
X X DSS/OF X X X X X X X Enterprise Rep.
Repository
X X Evidence Creator
X X X X X X X Ext. Rep. Access
X X X Image Archive
X X X X X X X X X X X Image Display
X X X X X X X X Image Manager
X X X X X X X X X X X Order Placer X X X Post-Processing
Manager
X X X PPS Manager
X X X X X X Print Composer
X X X Print Server X X
__________________________________________________________________________
12Integration
Profile Actor SWF PIR PWF RWF CHG CPI PGP KIN ED SINR PDI ARI SEC XDS-I
Report Creator
X X X X Report Manager
X X X X X Report Reader
X X X X X Report Repository
X X X X Removable Media
Creator
X X Removable Media
Importer
X X Secure Node X Time Server X Document Source
X Document Consumer
X Document Repository
X Document Registry
X Patient Identity
Source
X 2.3 Transaction Descriptions
Add the following to 2.3Transaction description
Y1. Provide and Register Document Set - A Document Source actor initiates the Provide
and Register Document Set transaction. For each document in the submitted set, the
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 Document Source Actor. [RAD-Y1, derived from ITI-15].
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-18. 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-18].
Y6. WADO Retrieve – A WADO Retrieve transaction is issued by a Document Consumer to an Image Manager / Image Archive to retrieve DICOM objects over HTTP/HTTPS
protocol.
Update the Integration Profile Transactions table as follows
__________________________________________________________________________
13
__________________________________________________________________________
14Table 2.3-1. Integration Profile Transactions
Integration Profile
Transaction
SWF PIR PWF RWF CHG CPI PGP KIN ED SINR PDI ARI SEC XD S-I Patient Registration
[1]
X X Placer Order [2]
X Filler Order [3]
X Procedure Scheduled
[4]
X X Query Modality
Worklist [5]
X X Modality Procedure
Step In Progress [6]
X X X Modality Procedure
Step Completed [7]
X X X X X Modality Images
Stored [8]
X X X Modality Presentation
State Stored [9]
X X Storage Commitment
[10]
X X X X X Images Availability
Query [11]
X X X X Patient Update [12]
X X X Procedure Update [13]
X X X Query Images [14]
X X X X X Query Presentation
States [15]
X X Retrieve Images [16]
X X X X X X X X Retrieve Presentation
States [17]
X X X Creator Images Stored
[18]
X X X Creator Presentation
State Stored [19]
X Creator Procedure
Step In Progress [20]
X X Creator Procedure
Step Complete [21] X X
__________________________________________________________________________
15Integration Profile
Transaction
SWF PIR PWF RWF CHG CPI PGP KIN ED SINR PDI ARI SEC XD S-I Print Request with
Presentation LUT
[23]
X Report Submission
[24]
X Report Issuing [25]
X Query Reports [26]
X X X Retrieve Reports [27]
X X X Structured Report
Export [28]
X Key Image Note
Stored [29]
X Query Key Image
Notes [30]
X X Retrieve Key Image
Notes [31]
X X X Authenticate Node
[32]
X Maintain Time [33]
X Record Audit Event
[34]
X Charge Posted [35]
X Account Management
[36]
X Query Post-
Processing Worklist
[37]
X Workitem Claimed
[38]
X X Workitem Completed
[39]
X X Workitem PPS In-
Progress [40]
X X Workitem PPS
Completed [41]
X X Performed Work
Status Update [42]
X X X X Evidence Documents
Stored [43]
X Query Evidence
Documents [44] X X
__________________________________________________________________________
16Integration Profile
Transaction SWF PIR PWF RWF CHG CPI PGP KIN ED SINR PDI ARI SEC XD S-I Retrieve Evidence
Documents [45]
X X X Query Reporting
Worklist [46]
X X Distribute Media [Y]
X Provide and Register
Document Set [RAD-
Y1]
X Register Document
Set [ITI-14]
X Query Registry [ITI-
16]
X Retrieve Document
[ITI-17]
X Patient Identity Feed
[ITI-18]
X WADO Retrieve
[RAD-Y6] X
2.4 Product Implementations
Add the following grouping descriptions to the end of section 2.4
In order to implement the sharing of an extensive set of DICOM instances, the Document Source shall be grouped with an Image Manager/Image Archive.
In addition, the Document Source can optionally be grouped with a Document Repository. This eliminates the need for providing the image set manifest as a separate transaction to the Document Repository.
In order to publish a report that references selected images, a Document Source shall be grouped with an Image Manager/Image Archive.
In order to publish a report that references selected images from previously published extensive DICOM set, a Document Source can be grouped with a Document Consumer. The consumer gets the references to images from a previously published manifest, creates the report, includes the references to selected images and publishes the report.
Add the following sections (X, X.1,) at the end of volume 1, before Appendix A.
X. Cross-enterprise Document Sharing for Imaging Integration Profile The Cross-enterprise Document Sharing for Imaging (XDS-I) Integration Profile specifies actors and transactions that provide for the sharing across health enterprises of Imaging Information. The Cross-Enterprise Document Sharing Profile in the IHE IT Infrastructure Domain is used and adapted to meet the imaging information sharing use cases. New document types and actor capabilities are defined based on the standard artifacts of Radiology. The information to be shared includes one or more of the following:
? 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 “for display” form to minimize the needs for receivers to “process”
the report content and associated risk of misrepresentation.
? A selection of diagnostically significant images associated with the report content.
X.1 Actors/ Transactions
Figure X.1-1 shows the actors directly involved in this profile and the transactions between actors.
__________________________________________________________________________
17
Figure X.1-1. Cross-enterprise Document Sharing for Imaging Diagram
Table X.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: X.2. Note that a number of actors must be grouped with Document Source as described in RAD TF-1: 2.4.
__________________________________________________________________________
18
__________________________________________________________________________
19Table X.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 Retrieve Document [ITI-17] R
ITI TF-2:3.17 Retrieve Images [RAD-16] O (note2)
4.16 Retrieve Presentation States [RAD-17] O (note2)
4.17 Retrieve Key Image Note [RAD-31], O (note2)
4.31 Retrieve Evidence Documents [RAD-45] O (note2)
4.45 Document Consumer WADO Retrieve [RAD-Y6]
O (note2) 4.Y6 Document Source
Provide and Register Document Set [RAD-Y1] R 4.Y1 Provide and Register Document Set
[RAD-Y1]
R 4.Y1 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-18]
R ITI TF-2:3.18 Patient Identity Source
Patient Identity Feed [ITI-18] R ITI TF-2:3.18 WADO Retrieve [RAD-Y6] R 4.Y6
Retrieve Images [RAD-16] R 4.16
Retrieve Presentation States [RAD-17] R 4.17
Retrieve Key Image Note [RAD-31], R 4.31
Image Manager/ Image Archive Retrieve Evidence Documents
[RAD-45]
R 4.45 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.
Note 2 : At least one of the optional retrieve transactions is required to be supported . Refer to RAD TF-2: Appendix Y.5.1 for
additional requirements on the Document Consumer.