XDS/XDS-I Affinity Domain Implementation Guide

DATE PRESENTED BY

XDS/XDS-I Affinity Domain Implementation Guide

Date: November 1, 2013

Version 1.0

Canada Health Infoway: XDS/XDS-I Implementation Guide of 95

Contents

Introduction .................................................................................................................................................. 6

1.1 Background ................................................................................................................................... 6

1.2 Reference Documents ................................................................................................................ 7

1.3 Abbreviations ................................................................................................................................ 7

2 Open Issues ........................................................................................................................................ 8

2.1 Open DI CDA Report Issues for Public Comment period: .................................................... 8

3 Considerations for Developing an XDS Affinity Domain .............................................................. 9

3.1 XDS Affinity Domain Definition .................................................................................................. 9

3.2 Privacy and Security Architecture ............................................................................................. 9

3.2.1 Identification & Authentication ............................................................................................ 9

3.2.2 Access Control ...................................................................................................................... 9

3.2.3 Identity Protection and Pseudonymisation ....................................................................... 9

3.2.4 Anonymization ..................................................................................................................... 10

3.2.5 Confidentiality ...................................................................................................................... 10

3.2.6 System and Data Integrity ................................................................................................. 10

3.2.7 Availability ............................................................................................................................ 10

3.2.8 Accountability ...................................................................................................................... 10

3.3 Organizational Rules ................................................................................................................. 10

3.3.1 Organizational Structure .................................................................................................... 10

3.3.2 Organizational Roles .......................................................................................................... 11

3.4 Membership Rules ..................................................................................................................... 11

3.4.1 Acceptance .......................................................................................................................... 11

3.4.2 Types of Membership ........................................................................................................ 11

3.4.3 Membership Policies .......................................................................................................... 11

3.5 Legal Considerations ................................................................................................................. 12

3.5.1 Legal Governance .............................................................................................................. 12

3.5.2 Government Regulations ................................................................................................... 12

3.5.3 Liability and Risk Allocation .............................................................................................. 12

3.5.4 Indemnification .................................................................................................................... 12

3.5.5 Intellectual Property Rights to Published Documents ................................................... 12


3.6 Plan for System Operation, Maintenance, and Innovation Transparency ........................ 12

3.6.1 Enforcement and Remedies ............................................................................................. 13

3.7 Operational Rules ...................................................................................................................... 13

3.7.1 Service Level Agreements ................................................................................................ 13

3.7.2 Governance ......................................................................................................................... 13

3.7.3 Policy Change Procedures................................................................................................ 13

3.7.4 Publication and Notification Policies ................................................................................ 14

3.7.5 Management When Systems are Unavailable ............................................................... 14

3.7.6 Configuration Management ............................................................................................... 14

3.7.7 Addition of New Components ........................................................................................... 14

3.7.8 Data Retention, Archive, and Backup ............................................................................. 15

3.7.9 Disaster Recovery .............................................................................................................. 15

4 Architecture ........................................................................................................................................ 16

4.1 XDS/XDS-I Infrastructure.......................................................................................................... 17

4.2 Connectivity to the XDS Affinity Domain from External Systems ....................................... 19

4.2.1 XDS Proxy Interface ........................................................................................................... 19

4.2.2 Direct DIR System Interface ............................................................................................. 19

4.2.3 DICOM Object Transport ................................................................................................... 21

4.2.4 CDA Diagnostic Report Transport ................................................................................... 22

4.3 Connectivity from the XDS Affinity Domain to External Systems ....................................... 23

5 Data Quality Management .............................................................................................................. 24

5.1 Image and Report Change Management ............................................................................... 24

5.1.1 Study Synchronization ....................................................................................................... 24

5.1.2 IHE Enterprise Profile Considerations ............................................................................. 24

5.1.3 IHE Profiles for Change Management ............................................................................ 25

5.1.4 Image and Report Change Management Use Cases ................................................... 25

5.2 Content Synchronization ........................................................................................................... 37

5.3 Other Synchronization Options Considered .......................................................................... 37

5.3.1 IHE Delayed Document Assembly ................................................................................... 37

5.3.2 IHE On-Demand Documents ............................................................................................ 38

5.3.3 Report Synchronization ..................................................................................................... 39

5.3.4 Metadata Subscription (DSUB) ........................................................................................ 39

5.4 Archiving and Publishing .......................................................................................................... 40


5.5 Timely Access to DI Results .................................................................................................... 40

5.6 Exam Delete vs. Exam Deprecate .......................................................................................... 41

5.7 Data Retention ............................................................................................................................ 42

5.8 Relationship between Accession#/SUID/Manifests.............................................................. 42

5.9 Minimum Supported SOP Classes .......................................................................................... 43

6 Foreign Exam Management (FEM) ............................................................................................... 45

6.1 Introduction ................................................................................................................................. 45

6.2 General System Design Considerations: ............................................................................... 45

6.3 Data Submission ........................................................................................................................ 46

6.4 Body Part Examined .................................................................................................................. 46

6.5 System-wide Design Image Object Move Priorities: ............................................................ 47

6.6 System-wide Design Report Format Priorities: ..................................................................... 47

6.7 IHE and FEM Actors .................................................................................................................. 48

6.8 Clinical Use Cases ..................................................................................................................... 48

6.8.1 Use Case 1: Basic – Pre-fetching for a New Radiology Order.................................... 49

6.8.2 Use Case 2: Adhoc or On-Demand Image Fetch from DIR to Local PACS ............. 51

6.8.3 Use Case 3: Pre-fetch of Relevant Priors from DIR into local PACS Initiated by Patient Visit (non-radiology workflow) ........................................................................................... 51

6.8.4 Use Case 4: Report-only Prior Retrieval ........................................................................ 51

6.8.5 Use Case 5: Report is Amended after Pre-fetch has Occurred to Local System .... 52

6.8.6 Use Case 6: Images are Added/changed after Pre-fetch has Occurred to Local System ............................................................................................................................................... 52

6.8.7 Use Case 7: STAT: Emergency Patient comes in and is Imaged at Local Site ....... 52

6.9 Exceptions/out of Scope for this Version: .............................................................................. 53

6.10 IHE Volume 2 Material – Transactions ............................................................................... 54

6.10.1 Pre-fetch Keys: ................................................................................................................ 54

6.10.2 HL7 v.2 ORM/OMI Order Schedule Message Specification: ................................... 56

6.10.3 HL7 v.2.x Patient Arrival Messages Specification: .................................................... 57

6.10.4 HL7 v.2.x ORU Results Message Specification: ........................................................ 58

6.10.5 CDA Report Format: ....................................................................................................... 59

6.10.6 FEM Attribute Tag Morphing: ........................................................................................ 59

6.10.7 Unified list of what must be configurable on FEM: .................................................... 61

6.10.8 Unified/summary list of audit logs: ............................................................................... 61

7 Diagnostic Imaging Report -CDA Definition ................................................................................. 62


7.1 DI Report Background ............................................................................................................... 62

7.1.1 HL7 CDA .............................................................................................................................. 63

7.1.2 IHE XDS/XDS-I ................................................................................................................... 63

7.1.3 Guideline Recommendations ............................................................................................ 63

7.2 Conformance Verbs, Cardinality, Constraints, Null Flavors, Notations, and Canadian Realm Data Types ................................................................................................................................ 63

7.3 Diagnostic Imaging (DI) Report Header ................................................................................. 63

7.3.1 ClinicalDocument/id ............................................................................................................ 66

7.3.2 ClinicalDocument/code ...................................................................................................... 66

7.3.3 ClinicalDocument/title ........................................................................................................ 67

7.3.4 ClinicalDocument/effectiveTime ....................................................................................... 67

7.3.5 inFulfillmentOf ..................................................................................................................... 68

7.3.6 documentationOf/ServiceEvent ........................................................................................ 68

7.4 Diagnostic Imaging (DI) Report Body ..................................................................................... 71

7.4.1 Discussion on Addendums, Document Deprecation, and Documents created in Error ................................................................................................................................ 71

7.4.2 DICOM Object Catalog Section ........................................................................................ 73

7.4.3 History .................................................................................................................................. 76

7.4.4 Current Procedure Descriptions ....................................................................................... 76

7.4.5 Indications for Procedure .................................................................................................. 76

7.4.6 Findings ................................................................................................................................ 77

7.4.7 Key Images .......................................................................................................................... 77

7.4.8 Complications ...................................................................................................................... 77

7.4.9 Impressions ......................................................................................................................... 77

7.4.10 Completion Status ........................................................................................................... 77

8 Metadata and Standard Terminology ............................................................................................ 78

9 Testing Strategy ................................................................................................................................ 93

10 Transition Strategy ........................................................................................................................... 93

10.1 Foreign Exam Management – DICOM Only Environment............................................... 93

10.1.1 Use Case 1: Basic – Pre-fetching for a new Radiology Order ................................ 93


Introduction

The XDS/XDS-I Affinity Domain Implementation Guide provides a pragmatic roadmap for the

planning and implementation of the XDS-I Affinity Domain solution interoperable with the

electronic health record (EHR). XDS (Cross-Enterprise Document Sharing) it will address the

challenges associated with organization of patient imaging records (e.g., patient-centric,

longitudinal) persisted as documents, sharing these documents across healthcare

organizations, and access to these documents from various applications regardless of where

these documents are stored.

1.1 Background

Canada Health Infoway’s initial investments in the DI (diagnostic imaging) program focused on

reducing film through the implementation of a PACS (picture archiving and communications

system) networks in the jurisdictions. Distribution of DI results to primary care physicians was

not an explicit objective of the program. As a result, the DI solutions deployed in the jurisdictions

provide access to a patient’s imaging record from imaging applications and viewers using

standards (DICOM) which are specific to the DI domain and not readily available to primary care

physicians.

One of the key goals of the Infoway DI Program is to provide access to imaging health records

to authorized care providers from anywhere and anytime regardless of where the images were

acquired and reports created. This includes access via EMR (electronic medical record)

applications in use at physician offices and clinics.

It is widely recognized that increased use of the patient records stored in the EHR repositories

will assist in the adoption of the EHR Infrastructure and realization of the relevant benefits. It will

also assist in the implementation and adoption of the EMR applications across Canada. Access

to imaging health records must be provided using standards-based protocols to facilitate EHR-

EMR interoperability. However, currently there are no standards-based protocols defined and

implemented to access imaging documents from the EMR applications.

As the jurisdictions move forward with their EMR programs the distribution of, and access to,

hospital reports, DI reports, including interpretations of diagnostic images is seen as a key

benefit of EHR-EMR interoperability to providers. DI reports fall into the wider universe of clinical

documents including discharge summaries, care summaries and referral notes, which follow

common workflow patterns when viewed from the perspective of a primary care provider.

Clinically relevant radiology imaging data is the key value proposition of this implementation

guide. This guide will assist in a full adoption of EHR/EMR solutions and realizing the benefits

of electronic health record provided that:


1. The content is implemented in the EMR systems approved for use in the respective

jurisdictions;

2. The content is implemented in the EHR/DI solutions so they are capable of processing

the DI documents initiated by the EMR applications;

3. Sharing of the DI documents adheres to the privacy legislation in the respective

jurisdictions and is aligned with the Infoway EHRS Blueprint and Privacy and Security

Architecture;

4. The EHR-EMR interactions are fully tested to ensure the quality of the information being

exchanged;

5. Sharing of DI documents is in accordance with the policy and governance model

established between the respective stakeholder groups e.g., Ministries of Health, Health

Authorities, professional organizations, and physicians.

A solution for such interoperability is, however, not a simple undertaking. Unstructured textual

data forms remains the predominate mechanism for information exchange among health care

providers, and a good majority of data needed by physicians and other health care providers to

make good clinical decisions is embedded in this free text. Efficient and effective interoperability

therefore begins by identifying the most relevant clinical data.

1.2 Reference Documents

The following Documents are referenced in the XDS Affinity Domain extensions or used as input in the creation of this document: Integrate Health Enterprise Radiology Technical Framework Version 11.

1.3 Abbreviations

• DIR: Diagnostic Imaging Repository • DI: Diagnostic Imaging • DICOM: Digital Imaging and Communications in Medicine • EHR: Electronic Health Record • EMR: Electronic Medical Record • HIE: Health Information Exchange • HL-7: Health Level Seven is a non-profit organization involved in the development of

international healthcare informatics interoperability standards."HL7" also refers to some of the specific standards created by the organization

• IHE: Integrating the Healthcare Enterprise • PACS: Picture archiving and communications system • PHI: Personal health information • PHR: Personal Health Record • TLS: Transparent layer security


2 Open Issues Do not remove section but remove issues listed here that are closed except for item #6

2.1 Open DI CDA Report Issues for Public Comment period:

1. IHE Radiology change proposal #248 is still open. This CP impacts Foreign Exam

Management Chapter 6 and XDS Meta Data Chapter 8. This has been specified from a

Canadian perspective however, it is still open internationally.


3 Considerations for Developing an XDS Affinity Domain

This section defines the organizational rules, roles and responsibilities, membership rules,

information governance, legal, legislative and professional considerations that are pertinent to

the Canadian XDS/XDS-I Affinity Domain deployment projects.

This section uses the ITI template for documenting implementation decisions, policies, and IHE

Profile refinements, for either an individual XDS Affinity Domain, or multiple XDS Affinity

Domains within a particular region.

3.1 XDS Affinity Domain Definition

The concept of an XDS Affinity Domain is defined in ITI TF-1:10, Appendix K. It is clear that

many regulatory/professional organizations will need to define policies regarding coded

terminology, privacy, document format and content, language support, etc. for an XDS Affinity

Domain.

When defining the policies and Profile refinements for an XDS Affinity Domain it is essential that

these do not contradict those mandated for all XDS Affinity Domains in Canada for which the

XDS Affinity Domain will exist. In addition, specifications for a particular XDS Affinity Domain

should not duplicate those defined in this document for the Pan-Canadian guidelines. Instead

the documentation for the regional XDS Affinity Domain should reference this and other

documents defining the national or regional policies.

3.2 Privacy and Security Architecture

3.2.1 Identification & Authentication

Considerations for identity and access management requirements for user account provisioning,

authentication and authorization services to ensure that only authenticated and authorized users

are allowed access to the assets of the XDS Affinity Domain.

3.2.2 Access Control

Considerations for access control requirements to ensure that the resources for data processing

can be accessed only by authorized entities in authorized ways. Including the management of

privileges and authorization. Reference the standards as described in ISO/IEC 2382-8:1998.

3.2.3 Identity Protection and Pseudonymisation

Considerations for identity protection services that will improve privacy protection by facilitating

the separate storage of personal information that uniquely identifies individuals (e.g. name,

address, health card number, etc.) from health information relating to their care and treatment;

As well as allowing approved researchers access to anonymized longitudinal data by providing

pseudonymously identified Personal Health Information (PHI).


3.2.4 Anonymization

Considerations for anonymization services that takes PHI representing an identifiable individual

and then removes all personal identifiers prior to aggregating the data into data sets of

completely anonymized data for use in research and statistical analysis.

3.2.5 Confidentiality

Considerations for encryption services that maintains data confidentiality and integrity using

cryptography technology. Communications confidentiality can be provided by Transport Layer

Security (TLS) to establish a secure, encrypted communications channel between information

sending and receiving servers residing in different physical security zones. Specifically,

communication between nodes can be established over a secure/encrypted communication link

using mutual-node authentication via the exchanging of X.509 certificates.

3.2.6 System and Data Integrity

As information is managed and retained in the XDS Affinity Domain, need to ensure that privacy

and PHI are protected, that data quality and integrity are kept sufficient to support intended

purposes of the data, that information management policies and practices are implemented

(among participants and with other initiatives); that patients, providers and users perceive a

consistent, coherent and well-managed experience, that there is adequate oversight,

accountability and transparency in information uses and disclosures, as they evolve over time.

3.2.7 Availability

Considerations for a solution that provides high availability throughout its components including:

redundant hardware, clustering, load balancing, RAID based disk configurations, primary site

and disaster recovery site.

3.2.8 Accountability

Considerations for accountability requirements to ensure the actions of an accessing entity may

be traced to that entity. Establishing agreements, harmonizing policies, and drafting terms of

reference are all tools that can be used to develop an accountability framework. Reference the

standards as described in ISO 7498-2:1989.

3.3 Organizational Rules

Considerations for a description of the organizational rules for the XDS Affinity Domain. It

should detail the administrative framework, functionalities, claims and objectives, the principles

involved, agreements, rights, duties, and penalties.

3.3.1 Organizational Structure

The organizational structure within a Canadian regional XDS Affinity domain are described here.

Considerations include, but are not limited to:


• Organization of the regional XDS Affinity domain governance (options to consider include: central point of authority, collaborative governance, distributed governance, etc.).

• The controllers, administrators, etc. of the XDS Affinity Domain. Their roles and responsibilities should be clearly defined, and contact information provided. It should be made clear who someone wishing to participate in the XDS Affinity Domain should have to contact in order to obtain information regarding participation in or access to the XDS Affinity Domain.

3.3.2 Organizational Roles

Considerations for the general roles of the organizations and individuals associated with the

implementation and maintenance of a regional XDS Affinity Domain. For example, specify the

roles played by the governmental agencies, corporate entities, organizations, individuals, etc.

associated with this XDS Affinity Domain.

3.4 Membership Rules

3.4.1 Acceptance

This section defines the types of organizations and individuals that can become members of the XDS Affinity Domain so that they will be permitted access to its components and data. Specify how they can apply for membership.

If there are any different rules for handling the membership of organizations and individuals whose physical location is considered part of another XDS Affinity Domain then define these here. For example, if the XDS Affinity Domain is defined for a specific geographic region, such as a Province or State, but an organization or individual located outside of this region wants to become a member. In addition, if there are any special rules for handling the membership of organizations and individuals who are already members of a different XDS Affinity Domain then define these here also.

3.4.2 Types of Membership

This section will specify whether or not there are different types of membership that define how published data can be accessed (e.g., read-only, publish-only, etc.). If there are then define what these membership types are, and the mechanisms used to enforce the rules for the defined types. Note that in addition to types of membership for individuals who are part of the XDS Affinity Domain, there may be the need to define types for those who would not normally be considered part of the Affinity Domain (e.g., for those who are external to the regional or organizational boundary of the XDS Affinity Domain but require or want access, possibly on a temporary basis, through a portal, etc.).

3.4.3 Membership Policies

This section will define any rules regarding management of members status. How does an individual or organization apply to no longer be a member? How is the list of members maintained and distributed? Is the list of members public? If not then what is the policy regarding requests for access to this list? Handling of membership in multiple XDS Affinity Domains.


3.5 Legal Considerations

3.5.1 Legal Governance

This section will define policies regarding the governance of legal issues related to users, publishers, IT staff, and vendors involved in the XDS Affinity Domain or within the regional XDS Affinity Domain for which these policies are defined.

3.5.2 Government Regulations

This section will reference government regulations that apply to implementation, use, or access to the XDS Affinity Domain.

3.5.3 Liability and Risk Allocation

In this section, any policies regarding liability issues and risk allocation for the XDS Affinity Domain will be described. Policies regarding the provision of liability insurance for those publishing documents to, or using documents from, the XDS Affinity Domain will be included as neccessary.

3.5.4 Indemnification

This section provides guidelines for how indemnification is dealt with in this XDS Affinity Domain implementation, such as:

• Indemnification of providers against lawsuits for data they publish that is misused by a user from a consuming system

• Mechanism to isolate financial responsibility to a particular provider when a patient sues another for misuse of his/her data

• Providers of data create indemnification agreements with all possible users of data • Recourse methods for providers to communicate problems with published data, rather

than the use of that data

3.5.5 Intellectual Property Rights to Published Documents

This section will define how intellectual property rights will be managed for documents published to the XDS Affinity Domain. For example, define whether property rights are maintained in any way once documents are published or if they are immediately waived.

3.6 Plan for System Operation, Maintenance, and Innovation Transparency

This section will document the manner in which accurate and timely disclosure of information will be provided by the various organizations that administer, organize, provide, and use the XDS Affinity Domain. This section will detail the procedures to follow in order to gain access to this information.

In this section guidelines will be provided regarding the types of information that organizations and individuals using the XDS Affinity Domain must be capable of providing should an audit of their participation or access be carried out.


3.6.1 Enforcement and Remedies

This section will document the responsible organizations for enforcing rules regarding payment, access rights, performance requirements, security, etc. associated with the regional XDS Affinity Domain. Clearly differentiate the areas of responsibility for the different organizations. If it is not clear who will ultimately be responsible for certain areas then also document this here.

3.7 Operational Rules

This section will describe the operational rules for the XDS Affinity Domain.

3.7.1 Service Level Agreements

This section will identify how Service Level Agreements will be created for the operational components of the XDS Affinity Domain.

3.7.2 Governance

This section will describe how the components of the XDS Affinity Domain are managed at an operational level. Develop a collaborative strategy for the implementation of a shared repository for digital images and reports in order to promote efficiency, generate value, reduce costs and improve IT service for the XDS Affinity Domain membership. Considerations to comment on include, but are not limited to:

• Overall operation management (coordination of efforts) • Sub-component division (if any) • Day-to-day operations management communication methods (meetings, summits,

forums, etc.) • Business (Enterprise) Governance processes and systems will ensure that member

interests are represented, and that value is maximized • IT governance processes should adhere to best practices and follow established

international models, where appropriate • Governance processes to ensure that resources are used appropriately • Governance processes to ensure that risk is managed appropriately • Governance processes to satisfy PHIPA fiduciary responsibilities • Governance model should have a clearly articulated decision framework that (1)

describes what to do; (2) tells how to do it; (3) assigns who should do it; and (4) details how it should be measured

• Governance bodies identified in the final model will be formally chartered so that roles and responsibilities are clear; and

• IT Governance that supports the technical architecture guiding principles

3.7.3 Policy Change Procedures

This section will define the procedures for managing proposed policy changes for the XDS Affinity Domain, the manner in which individuals and organizations can propose policy changes, and the manner in which such proposals are reviewed and by whom.


3.7.4 Publication and Notification Policies

This section will specify the mechanisms used for publishing the policies and the means used to notify members of any changes. For example:

• If the policies are posted to an internet site then specify the URL • If notifications are sent by e-mail then document this along with the mechanisms used for

managing the list of addressees

3.7.5 Management When Systems are Unavailable

This section will define policies for managing cases where various types of components of the XDS Affinity Domain are unavailable. For example, what type of workarounds should be used if the PIX Manager for this XDS Affinity Domain implementation is unavailable? Other considerations include, but are not limited to:

• Notification mechanisms for scheduled system downtime and maintenance • Notification mechanisms when a system or user of the XDS Affinity Domain detects that

one or more components are unavailable • Notification of causes and resolutions for unscheduled system downtimes • Detailed procedures for maintaining business continuity, recovery and disaster

management in the event of failure should be specified in a Business Continuity Plan and Disaster Recovery Management

3.7.6 Configuration Management

This section will specify how change management issues (such as hardware upgrades, software upgrades, configuration changes, etc) are to be managed. Explain what authorization is needed in order to make changes to a component of the XDS Affinity Domain that will affect other components (such as those that will cause component downtime, require configuration changes on other systems, or effect functionality). Define how configuration settings will be disseminated among systems in the XDS Affinity Domain. Define the rules for DNS management and system naming conventions. Make sure to mandate the use of appropriate host names and policies that will attempt to guarantee their continued use as hardware is upgraded and replaced over time. This is important because host names are used in the <location> part of Metadata URLs, and thus URLs can be broken if host names are not maintained over time.

3.7.7 Addition of New Components

This section will specify procedures for adding new components to the XDS Affinity Domain. Explain who is authorized to grant permission for new components to be added and how are they can be contacted. Define procedures for providing the necessary configuration and security information to the managers of components that will need to communicate with a new component.

Includes rules regarding the migration of data from one type of system to another, particularly when moving data from one XDS Repository to another. Rules for handling the case where an additional XDS Repository is added to an XDS Affinity Domain and a subset of the data in existing Repository(s) is to be migrated to the new system.


• Rules for migrating data if all the data in an XDS Repository is going to be migrated to a new system or another system that is already also acting as an XDS Repository for the Affinity Domain.

• Rules regarding the migration of content that is originally to be stored long term on local systems acting as XDS-I Sources to a centralized long term archive or vice versa. The rules must define how the XDS-I Repository Manifests will be.

3.7.8 Data Retention, Archive, and Backup

This section define policies regarding the responsibilities for data retention, archive, and backup for the various types of components of the XDS Affinity Domain. For example, specify how long access to documents published to an XDS Repository of the XDS Affinity Domain must be maintained, and how long their data integrity must be guaranteed. State the backup requirements for the Repository.

Specify the manner in which security audit logs, both electronic and non-electronic, will be retained and made available for compliance audits and legal review. Define the time period for which such audit logs must be maintained.

3.7.9 Disaster Recovery

This section defines disaster recovery practices for the various types of components of the XDS Affinity Domain. Included will be procedures to follow when disaster recovery is needed, and what notification must be provided in such cases. The types of procedures should include, but are not limited to:

• How to recover • What process/workflow to invoke • Where to recover • Expectations • Service Level Agreement (SLA) for recovery • Notifications/Communications • Business impact analysis • Emergency procedures for lack of access


4 Architecture

Within Canada there are healthcare facilities that already have RIS and PACS and are operating in a near filmless state. Trying to “glue” all of these systems together presents significant challenges:

• points of integration with the EHRs are many • locating data stored in multiple systems is a complex problem • achieving performance expectations is challenging

The Infoway DI vision is to leverage these existing RIS and PACS as operational solutions, but to consolidate the long term storage in a single infrastructure, namely the DI domain repository. In so doing:

• the integration with EHR components is consolidated • information access by EHR consumers is simplified • economies of scale can be leveraged to reduce costs

Recognizing the challenges in sharing DI information, the Infoway vision is to comply with the IHE XDS-I integration profile as the means to achieve seamless sharing. Whereas, implementation models for XDS-I have not been fully vetted, the expectation is to deploy the various XDS-I actors as follows:

• XDS-I Registry – The EHR Index serves as the XDS-I Registry actor. The EHR Index is, in practice, a super set of the XDS Registry in that it supports a variety of data categories over and beyond clinical documents e.g. event notifications, dynamic workflow artifacts, etc.

• XDS-I Document Repository – The DIR serves as the Document Repository actor • XDS-I Document Source – The DIR serves as the Document Source actor for DICOM

objects since the DIR is the long term storage solution for all DI information. Hence, a local PACS or modality are NOT considered Document Source actors as they do not hold responsibility for long term storage of the DI information. Systems that generate DI reports, such as Radiology Information Systems (RIS) and Transcription Systems, should serve as Document Source actors. They submit the report documents to the DIR acting as a Document Repository.

• XDS-I Document Consumer - The local PACS serve as Document Consumer actors in that they query and retrieve DI information, from the EHR Index (XDS-I registry) and DIR (XDS-I repository/document source), on behalf of PACS viewing clients. The local PACS viewing clients may also be Document Consumer actors to allow direct access to the EHR Index and DIR (without having to interact with the local PACS infrastructure). The local RIS serve as Document Consumer actors in that EHR consumers may well use RIS clients as a viewing tool for DI reports. EHR viewers serve as Document Consumer actors.

The diagram below depicts the XDS-I actor roles in a jurisdiction that has existing RIS and PACS deployed.


Figure 1: DIR and the Implementation of XDS-I Actors

4.1 XDS/XDS-I Infrastructure

The XDS/XDS-I Infrastructure is a regional archive for images and reports. An Imaging Source is an entity or facility which provides images and reports to the XDS/XDS-I Infrastructure. The XDS/XDS-I Infrastructure supports the following IHE XDS/XDS-I Profile Actors for receiving images and reports:

• XDS-I Imaging Document Source • XDS-I Imaging Document Consumer • XDS/XDS-I Document Repository • XDS/XDS-I Document Registry • PIX Manager/PDQ Source • ATNA Secure Node/Audit Record Repository • Consistent Time, Time Client


Additionally, the solution may contain the following components:

• XDS Proxy Device • Identity & Access Management • User Registry • DI Terminology Registry • Image Archive


4.2 Connectivity to the XDS Affinity Domain from External Systems

The IHE XDS-I profile does not specify how Images are transferred to an Imaging Document Source. The XDS-I Implementation Guide provides guidance to how images and reports should be communicated between the source system at the clinical facility (i.e., PACS or RIS) and the DIRs XDS infrastructure.

In Canada, there are two methods for a clinical facility to provide images and related information to a DIR’s Imaging Document Source:

• XDS Proxy Interface • Direct DIR System Interface

4.2.1 XDS Proxy Interface

An XDS Proxy Interface is a solution which collects the DICOM Images, Reports and associated Metadata on behalf of the source system at the clinical facility for submission to the jurisdiction’s DIR. The XDS Proxy Interface will then provide conformant metadata prior to sending the DICOM Images and CDA Reports to the DIR.

4.2.2 Direct DIR System Interface

A clinical facility within a regional jurisdiction acquires and sends DICOM Images and reports directly to a jurisdiction’s DIR. The source system at the clinical facility is responsible for sending valid DICOM Images to the DIR with sufficient information to support the creation of the Image Manifest and the associated metadata. The source system at the clinical facility will create the Image Manifest and metadata within the DIR’s XDS Repository. The source system at the clinical facility sends CDA Reports and are expected to include the metadata that would correspond to the associated DICOM Objects for the study.


4.2.3 DICOM Object Transport

A facility providing DICOM Objects to a DIR are recommended to follow the reccomendations for the Image Manifest, XDS-I metadata and the assigning authority identification.

4.2.3.1 DICOM Send (without associated XDS Metadata attached)

DICOM Objects acquired at a local clinical facility are reccomended to be validated of their content prior to sending to a DIR via a DICOM C-STORE.

When transferring DICOM Objects without associated XDS Metadata attached, the DIR is reliant on the DICOM Object attributes and the MPPS attributes for populating the metadata.

The DICOM MPPS message is reccommended to conform with the IHE Radiology Transactions for Scheduled workflow:

[RAD-6] Modality PS in Pogress

[RAD-7] Modality PS Completed

[RAD-20] Creator PS In-Progress

[RAD-21] Creator PS Completed

A performed procedure step may include multiple modalities(PET, CT, PR, SR, etc) which would nessessitate multiple MPPS N-CREATE sends with the DICOM Objects. It is reccommended that if multiple MPPS N-CREATE transactions are performed for a single Performed Procedure Step, then a single MPPS N-SET is used to complete the transfer. Each MPPS will transaction will contain a manifest of 0-N acquired or created DICOM Objects. The accumulated set of MPPS DICOM Instances in each of the MPPS tractions for the Performed Procedure Step will be used by the XDS-I Image Document Source for the Image Manifest.

A DIR may use the DICOM Object attributes and the associated MPPS content to create the XDS-I Metatdata for the Image Manifest as identified in Section 8.0 Metatdata and Standard Terminology.

4.2.3.2 XDR-I Sharing of DICOM SOP Instances Option (with associated XDS-I Metadata attached)

DICOM Objects acquired at a local clinical facility are reccomended to be validated of their content prior to sending to a DIR.

When an Image Document Source uses the XDR-I Sharing of DICOM SOP Instances Option (with the associated XDS-I Metadata attached), it is reccommended to conform to Section 8.0 Metadata and Standard Terminology for the specific metatadata.

A DIR may use the XDR-I metadata to create the XDS-I metadata and the Image Manifest.

4.2.3.3 Institution and Assigning Authority Identification

It is necessary for DICOM Objects acquired at a local clinical facility to be uniquely identified with regards to the originating institution and the local assigning authorites for it’s clinical content. To ensure this uniqueness, it is reccomended that all DICOM Objects and the associated MPPS adhere to the reccommendations identifeid in the IHE Technical framework TI


Supplement, “Multiple Image Manager/Archive (MIMA)”, Appendix J.2.2: Configurable Mapping to Default Assigning Authorities and Institution Name.

4.2.4 CDA Diagnostic Report Transport

4.2.4.1 XDS-I CDA Report, Transport

A facility providing a CDA Diagnostic Report is reccomended to use XDS-I for CDA Reports directly to a DIR providing the following reccomendations are followed: The clinical facility may send the CDA Diagnostic Report directly to the DIR with an XDS provide and register transaction following the XDS metadata recommendations in Section 8.0 Metadata and Standard Terminology. The sending clinical facility is recommended to include a fully qualified Accession Number referencing the associated study and acquired images. In the situation where an XDS Proxy Interface is implemented the clinical facility may send HL7 messages (ORU) to the XDS Proxy Interface which will transform the HL7 message content into the XDS provide and register transaction with the required XDS metadata.

4.2.4.2 XDR-I CDA Report and DICOM Objects, Transport

IHE ITI has a transport protocol called XDR which serves well for non-imaging payloads. It is compatible with the Security and Privacy protocols developed by the IHE ITI domain. The XDS-I protocol breaks the content profile into 2 components. The first component is designed essentially as a notification from where to pull the content. Usage of the XDR transport protocol should not require this notification/pull architecture, but just the push model. It should remove the requirement for a source to be a cross enterprise source of Images.

The value for this capability would allow for a less sophisticated system to be a source of images. An XDR-I image source could be as low cost as a workstation. Additional value could be to use the XDR-I web-services as an XDS-I proxy with a regional XDS-I source. Currently, when an XDS-I Image Document Source provides & register images on behalf of a local facility, there is no mechanism to provide feedback to the originating source. This would allow for an XDS-I Image document source to use the response of the XDR transport services to provide success or failure status back to the originating source of the images

A facility providing both the CDA Report and the DICOM Objects may use XDR-I for providing both the CDA Report and DICOM Objects in the same submission Set.

The associated metadata for the submission set is required to conform to the XDS metadata described in section 8.0 Metadata and Standard Terminology.


4.3 Connectivity from the XDS Affinity Domain to External Systems

Figure 2: Cross-Enterprise Imaging Diagram

The IHE XDS-I profile specifies a common registry indexing image manifests and CDA-formated reports with associated metadata for query descoveries. The general use cases include:

• Ad hoc query for patient imaging records by a clinician • Coarse grained automated pre-fetch of relevant priors • Retrieval of Images and report for a referral

XDS-I specifies the ITI Transaction, ITI-18 Registry Stored Query to locate the relevant documents based on the general use cases identified. The stored query will use metadata constraints, based on the XDS registry metadata as described in section 8.0 Metadata and Standard Terminology.

Using the Registry Stored Query response, the identified Image Manifests and CDA Reports may be retrieved from the DIR XDS Repository using the ITI-43 Retrieve Document Set transaction.

The retrieved image manifests contain the list of image objects and specific information on how and where to retrieve the images. Depending on the retrieing system’s capabiities, images may be retrieved using a number of alternatives:

• DICOM WADO Retrieve based on the IHE RAD-55 WADO transaction • DICOM WADO-WS Retrieve (synchronous) based on the IHE RAD-69 transaction • DICOM WADO-WS Retrieve (asynchronous) based on the IHE RAD-69 (XDS

asynchronous option) transaction • DICOM C-MOVE based on the IHE RAD-16 transaction


It should be noted that the DICOM WADO-WS Retrieve (asynchronous) provides the capability to specify a separate reviewing address for images to be retrieved. WADO-WS interface allows more than 1 image to be retrieved at a time (unlike the straight WADO interface which only supports single image retrieval).

5 Data Quality Management

5.1 Image and Report Change Management

5.1.1 Study Synchronization

The results of Study Synchronization actions needs to be better understood. Source organizations that publish DI results, DIR policies and regulatory requirements need to be recognized in order to ensure data integrity, audit capability and potential recovery or roll-back processes are not compromised.

Some of the items to consider are:

• Maintaining a history or versioning of data and changes during the life of that study if the data will not be re-used outside of the system. If the data will be re-used outside of the system the versioning must be unique to avoid ambiguous interpretation in data.

• Audit trail of changes and ability to view previous versions of the study at different points in time

• Audit log messages for study updates, changes, replacements and deprecations are sent to the ATNA repository

• Source/creator image life cycle management (do the source systems permanently delete patient records after a period of time)

• Data retention policies differ from province to province • Notification of study changes to DSUB subscribers

5.1.2 IHE Enterprise Profile Considerations

Where possible, existing IHE mechanisms from the following IHE profiles are reccommended for use with the obective to minimize the need for changes/corrections to study content prior to export:

• Scheduled Workflow (SWF) • SWF Instance Availability Option • Patient Information Reconciliation (PIR)

• Patient Information Cross-Reference (PIX)

• Patient Demographics Query (PDQ)

• Key Image Notes (KIN)

• Consistent Presentation of Images (CPI)

For images, the Instance Availability option is recomended in the workflow, if the service is triggered by the data quality step of image verification.

For reports, the reporting physician verifies the report, confirming the content accuracy.


5.1.3 IHE Profiles for Change Management

In the cases where changes/corrections to an exported study are needed, it is recommended to adopt a standard mechanism for changes/corrections of an exported study as specified in the IHE Image Object Change Management (IOCM) profile; grouped with XDS change management options. The XDS change management options are:

• XDS Document Replacement Option for the XDS Document Source, XDS Document Repository, XDS Imaging Document Source and XDS Imaging Document Repository

• XDS Document Metadata Update Option for the XDS Document Registry and XDS Document Consumer

5.1.4 Image and Report Change Management Use Cases

The following use cases are specified for implementing IOCM and XDS Options for Change Management profiles:

Append:

• An existing image set with additional set of image instances

• An existing report with an addendum

Replace:

• An existing image set with a new set of image instances

• An existing report with a new report

Delete:

• An existing image set and all references

• An existing report and all references

Split:

• An existing image set into 2 (or more) separate image sets

Merge:

• Existing 2 (or more) image sets into 1 (single) image set


5.1.4.1 Append: An Existing Image Set with Additional Set of Image Instances

This section describes the case where a submitted image set needs to be appended with additional images. It is reccommended to use the following Profile Actor Options:

Clinical Image Provider: • XDR-I: Image Document Source: Sharing of DICOM SOP Instance Option or DICOM

Send SCU (ref sec 4.2.3.1)

Diagnostic Imaging Repository: • XDR-I: Image Document Recipient: Sharing of DICOM SOP Instance Option and • DICOM Send SCP (ref sec 4.2.3.1) • XDS-I: Image Document Source: Set of DICOM Instances Option • XDS: Document Source: Document Replacement Option • XDS: Repository: None • XDS: Registry: Refence ID Option

It is reccomended that the following actors are grouped • XDS-I Image Doc Source • Image Document Recipient

XDR-I Image Document Source

Or

DICOM SEND SCU

XDS-I.b Image Doc Source

XDR-I Image Document Recipient

DICOM SEND SCP

XDS Repository

Shares an

append Image

Set to an

existing Image

Set

DICOM SEND or

XDR-I, Sharing DICOM SOP

Instance [ITI-41]

Shares

Image Set

Add additional Images

to existing image set

previously submitted

Provide & Reg Img Doc Set

– MTOM/XOP [RAD-68]

XDS Registry

Register Document Set

[ITI-42]



(Replace existing manifest

with new manifest to include

additional Image Instances)


[ITI-42]

Replace

manifest

DICOM C-STORE or

XDR-I, DICOM SOP Instance

[ITI-41]

Stores Images, Creates

Image manifest and

Metadata image set

Figure 3 - Image Manifest Append of Exported Study

The Image Source sends a newly created Image Set using the DICOM SEND or XDR-I Sharing of DICOM SOP Instance [ITI-41] to the Image Document Recipient using the constraints described in Section 4.2.3.

The Image Document Recipient, grouped with the XDS-I Imaging Document Source, creates the Image Manifest and derives the associated XDS-I metadata as described in Section 4.2.3.


The XDS-I Imaging Document Source sends the Image Manifest to the XDS Repository via the [RAD-68] transaction. The XDS Repository then registers the manifest to the XDS Registry [ITI-42].

The Image Document Source should maintain the submitted UUID of the Image Manifest with the fully qualified Accession Number for the study (see section 4.2.3.3) used in the transaction.

Later, the Imaging Source sends an ‘append’ of the existing Image Set using DICOM SEND or XDR-I, Sharing of DICOM SOP Instances [ITI-41] to the Image Document Recipient using the constraints described in Section 4.2.3.

The Image Document Recipient determines that the Shared DICOM SOP Instances are an ‘append’ to an existing Image Set based on the identical use of the identical fully qualified Accession Number (see section 4.2.3.3). The Image Document Recipient stores the appended image set.

The XDS-I Image Document Source submits the new Image Manifest as a replacement to the existing Image manifest, containing references to the previously submitted image set plus the appended images using the REPLACE transform described in the RAD-68 and referencing the ITI-41transaction

The XDS Repository then registers the manifest as a replacement, using the REPLACE transform, with the XDS Registry (ITI-42).

5.1.4.2 Append: An Existing Report with an Addendum

This section describes the case where a submitted report needs to be appended. It is reccommended to use the following Profile Actor Options:

Radiology Service Provider: • XDS-I: Image Document Source: CDA Imaging Report with Structured Headings

Diagnostic Imaging Repository:

• XDS: Repository: None • XDS: Registry: Reference ID Option

Note that the Association relationship in the submission is “replace”. The objective for using replace is to maintain a single document for the report.



Ğ CDA Report

XDS Repository

A report addendum

is created,

Sends Addendum

with APPEND

transform to DIr

Pro vide & Reg Img Doc Set

Ğ MTOM/XOP [RAD -68]

XDS Registry


[ITI -42]



(Append existing report with

addendum )


[ITI -42]

Append

Report

Images read,

sends Report

to DIr

Figure 4 - Append Existing Report

The Radiology Service provider, acting as an XDS-I Imaging Document Source, sends a Radiology Report to the DIR XDS Repository [RAD-68]. The Image Document Source should maintain the submitted UUID of the Report with the fully qualified Accession Number for the study used in the transaction.

The XDS Repository registers the manifest to the XDS Registry [ITI-42].

Later, the Radiology Service provider creates a report addendum for submission to an existing and previously submitted Report. Prior to submission, the original report and the addendum are combined to create a new report.

The Radiology Service provider, acting as an XDS-I Imaging Document Source, sends to the XDS repository the combined report addendum plus original report, with the REPLACE relationship to the existing report.

The XDS Repository registers the combined report as a document replacement, with the XDS Registry (ITI-42).


5.1.4.3 Replace/Modify: An Existing Image Set with a New Set of Image Instances

This section describes the case where a submitted image set needs to be replaced or modifed with additional images. It is reccommended to use the following Profile Actor Options:

Clinical Image Provider: • IOCM: Change Requestor • XDR-I: Image Document Source: Sharing of DICOM SOP Instance Option or • DICOM Send SCU (ref sec 4.2.3.1)

Diagnostic Imaging Repository: • IOCM Image Manager/Image Archive • XDR-I: Image Document Recipient: Sharing of DICOM SOP Instance Option and • DICOM Send SCP (ref sec 4.2.3.1) • XDS-I: Image Document Source: Set of DICOM Instances Option • XDS: Document Source: Document Replacement Option • XDS: Repository: None • XDS: Registry: Refence ID Option

It is reccomended that the following actors are grouped: • XDS-I Image Doc Source grouped with XDR-I Image Document Recipient • XDS-I Image Doc Source grouped with IOCM Image Manager/Image Archive

Figure 5 - Replace/Modify Existing Image Set


Images may be replaced or Modified for several clinical reasons as described in IOCM. The IOCM use cases are extensible to managing images across the enterprise using XDS-I.




Later, the Imaging Source corrects the Image Set and sends a Rejection Note with Replacement Instances to the IOCM Image Manager / Archive using RAD-66, RAD-74 (with either DICOM SEND or XDR-I).

The IOCM Image Manager/Archive, hides the incorrect images as called out in the Rejection Note (RAD-66). Grouped with an XDS-I Imaging Document Source, it replaces the original submitted manifest that references the incorrect images by submitting a new replacement manifest which includes original images not rejected and the KOS Rejection Note

Once the IOCM Image Manager/Archive receives the corrected images in the Replacement Instances Stored (RAD-74) tranaction, grouped with the XDS-I Imaging Document Source, it replaces the previously submitted manifest by submitting a new replacement manifest that includes references to the replacement instances existing images not rteplaced and the KOS Rejection note. .

5.1.4.4 Replace/Modify: An Existing Report with a New Report

This section describes the case where a submitted report needs to be replaced. It is recommended to use the following Profile Actor Options:


Diagnostic Imaging Repository: • XDS: Repository: None • XDS: Registry: Reference ID Option

Note that the workflow is identical to the “Append” for an existing Report.



Ğ CDA Text Wrapped

XDS Repository

An existing report

is modified or a

new replacement

report is created

Sends New or

Modified Report

with a REPLACE

transform to DIr

Pro vide & Reg Img Doc Set


XDS Registry


[ITI -42]



(Replace existing report with

mod ified or new )


[ITI -42]

Replace

Report

Images read,

sends Report

to DIr

Figure 6 – Replace/Modify Existing Report



Later, the Radiology Service provider creates a new report for submission as a replacement to an existing and previously submitted Report.

The Radiology Service provider, acting as an XDS-I Imaging Document Source, sends to the XDS repository the new report, with the REPLACE relationship to the existing report.

The XDS Repository registers the combined report as a document replacement, with the XDS Registry (ITI-42).


5.1.4.5 Delete: An Existing Image Set and all References (soft delete with no replacement)

This section describes the case where a submitted image set needs to be become unavailable (soft Delete). It is reccommended to use the following Profile Actor Options:



It is reccomended that the following actors are grouped: • XDS-I Image Doc Source grouped with XDR-I Image Document Recipient • XDS-I Image Doc Source grouped with IOCM Image Manager/Image Archive

Register Document Set [ITI-42]

Register Document Set [ITI-42] Provide & Reg Img Doc Set


Hides existing Images of

previously submitted Image Set

Image Source /

Change Requester

Image Manager /

Image Archive /


XDS Repository

Provide

additional

Image set

instances to

DIr

DICOM SEND or

XDR-I, DICOM SOP Instance

[ITI-41]

Provide

Images to

DIr



XDS Registry

Rejection Note Stored [RAD-66]

Using

DICOM SEND or XDR-I

Replace existing manifest with

new manifest, removing

incorrect images, adding the

Rejection Note

Replace

manifest

Stores Images, Creates Image

Manifest and Metadata for

Image submission

Figure 7 - Delete Existing Image Instances

Images may be soft deleted for several clinical reasons as described in IOCM. The IOCM use cases are extensible to managing images across the enterprise using XDS-I.





Later, the Imaging Source corrects the Image Set and sends a Rejection Note with No Replacement Instances to the IOCM Image Manager / Archive using RAD-66, (with either DICOM SEND or XDR-I).

The IOCM Image Manager/Archive, hides the soft deleted images as called out in the Rejection Note (RAD-66). Grouped with an XDS-I Imaging Document Source, it replaces the original submitted manifest that references the soft deleted images by submitting a new replacement manifest the KOS Rejection Note.

5.1.4.6 Delete: An Existing Report and all References (no replacement)

This section describes the case where a submitted report needs to be replaced. It is reccommended to use the following Profile Actor Options:


• XDS Document Administrator: Update Metadata

Diagnostic Imaging Repository: • XDS: Repository: None

• XDS: Registry: Reference ID Option

It is recommended that the following actors are grouped • XDS-I/XDS Image Doc Source grouped with XDS Document Administrator


Figure 8 – Soft Delete (deprecate) Existing Report



Later, the Radiology Service provider soft deletes a report by sending to the XDS repository the new report, with the Update Document Set (ITI-57) to change the document status of the existing report from approved to deprecated.

5.1.4.7 Split: An Existing Image Set into 2 (or more) Separate Image Sets

This section describes the case where a submitted image set needs to be split. It is recommended to use the following Profile Actor Options:

Clinical Image Provider: • IOCM: Change Requestor • XDR-I: Image Document Source: Sharing of DICOM SOP Instance Option or • DICOM Storage SCU (ref sec 4.2.3.1)

Diagnostic Imaging Repository • IOCM Image Manager/Image Archive • XDR-I: Image Document Recipient: Sharing of DICOM SOP Instance Option and • DICOM Storage SCP (ref sec 4.2.3.1) • XDS-I: Image Document Source: Set of DICOM Instances Option • XDS: Document Source: Document Replacement Option • XDS: Repository: None • XDS: Registry: Refence ID Option


It is recommended that the following actors are grouped

XDS-I Image Doc Source grouped with XDR-I Image Document Recipient

XDS-I Image Doc Source grouped with IOCM Image Manager/Image Archive

Figure 9 – Split an Existing Image Set

5.1.4.8 Merge: Existing 2 (or more) Image Sets into 1 (single) Image Set

This section describes the case where a submitted image set needs to be merged. It is recommended to use the following Profile Actor Options:



It is recommended that the following actors are grouped: • XDS-I Image Doc Source grouped with XDR-I Image Document Recipient • XDS-I Image Doc Source grouped with IOCM Image Manager/Image Archive


Figure 10 - Merge Two Existing Image Sets

Images may be merged from two exams to a single existing exam for several clinical reasons as described in IOCM. The IOCM use cases are extensible to managing images across the enterprise using XDS-I.

The Image Source sends two newly created Image Sets using the DICOM SEND or XDR-I Sharing of DICOM SOP Instance [ITI-41] to the Image Document Recipient using the constraints described in Section 4.2.3.

The XDS-I Imaging Document Source sends the Image Manifest to the XDS Repository via the [RAD-68] transaction for each of these Submission Sets. The XDS Repository then registers the manifest to the XDS Registry [ITI-42].

The Image Document Source should maintain the submitted UUID of the Image Manifest with the two unique and fully qualified Accession Numbers for the studies (see section 4.2.3.3) used in the transaction.


Later, the Imaging Source needs to merge the two studies into a single study. For the study to be merged a Rejection Note with No Replacement Instances is sent to the IOCM Image Manager / Archive using RAD-66, (with either DICOM SEND or XDR-I).

The IOCM Image Manager/Archive, hides the soft deleted images as called out in the Rejection Note (RAD-66). Grouped with an XDS-I Imaging Document Source, it replaces the original submitted manifest that references the soft deleted images by submitting a new replacement manifest the KOS Rejection Note.

The Imaging Source sends an ‘append’ of the existing Image Set using DICOM SEND or XDR-I, Sharing of DICOM SOP Instances [ITI-41] to the Image Document Recipient using the constraints described in Section 4.2.3.

The Image Document Recipient determines that the Shared DICOM SOP Instances are an ‘append’ to an existing Image Set based on the identical use of the identical fully qualified Accession Number (see section 4.2.3.3). The Image Document Recipient stores the appended image set.

The XDS-I Image Document Source submits the new Image Manifest as a replacement to the existing Image manifest, containing references to the previously submitted image set plus the appended images using the REPLACE transform described in the RAD-68 and referencing the ITI-41transaction

The XDS Repository then registers the manifest as a replacement, using the REPLACE transform, with the XDS Registry (ITI-42).

5.2 Content Synchronization

Once a report or image is consumed by a local system, the system consuming the foreign exams will need to purge both the images and reports at a specified time. This is reviewed in the Foreign Exam Management section.

5.3 Other Synchronization Options Considered

The prevous section describes the current status of content synchronization, where the following section describes potential future directions.

5.3.1 IHE Delayed Document Assembly

XDS is designed with the expectation that the document is entirely created prior to registering the metadata with the Document Registry. The use of Delayed Document Assembly allows source systems to register the existence of stable document content, but defer actually assembling the document content only if and when it is retrieved. This deferral of the creation of the document content is preferred in an application architecture where a great deal of content is available for sharing but saved as a set of distinct elementary records in a clinical database and not as documents. To convert all this content to documents is considered a waste of resources for any document which is never requested. Thus, only content that is specifically requested is formed into a document.


5.3.2 IHE On-Demand Documents

The use of On-Demand Documents supports registration of the availability of content dynamically assembled in a document; content that is expected to change over time, and in response to a retrieve request returns the most current content available to the responder. The use of On-Demand Documents is intended for an application architecture where the supplier of data wishes to provide, through a single request mechanism, the most current content available at the time of the request. The dynamic nature of the shared data means this environment is more complicated to support but allows easy access to, for instance, summary data for a specific patient. However, it does not provide for robust source attestation of the overall document content because the content is selected through automation rather than overseen and attested in whole by a clinician. Delayed Document Assembly is distinct from On-Demand Documents in that Delayed Document Assembly is consistent with the current assumptions of XDS, namely that Document Entries in the Document Registry reflect Documents that are static, clinician attested documents and the content of the document is identified prior to registration of the Document Entry. On-Demand Documents allows the content of the document to be identified at the time of receipt of the retrieval request. Delayed Document Assembly has been designed to be as transparent as possible to Document Consumer Actors. Document Consumers Actors may easily support Stable Documents whose assembly has been delayed just as if they were a regular Stable Document since the only constraint on Document Consumers brought by this Delayed Document Assembly option is to support responses to queries with the presence of Stable Document Entries that have zero size and hash values.

In the Infoway architecture, the DIR is the Imaging Document Source that is responsible for creating the manifest for each study and registering it to the Document Registry, that means the study has to be already stored from the local PACS to the DIR , which has already introduced the main issue of study synchronization. The use of Delay Document Assembly allows the Registry to be aware of the manifest and at the same time let the Imaging Document Source to delay the actual creation of the specific manifest. The net benefit is save some processing time in the DIR and save some storage in the Document Repository for manifests that are never requested. This implies that this benefit can only be realized in case most of the time, studies are NOT accessed via XDS-I. In other words, in most circumstances, the local query/retrieve to the DIR will get what you need. The need for cross DIR access is minimal. However, use of Delay Document Assembly does NOT eliminate the need for XDS-I manifest synchronization in case the study is modified because the manifest identity has already been assigned and registered, just simply not assembled. The use of On-Demand Documents eliminates the need for manifest synchronization because the latest state of the requested study will be captured as a new manifest on demand upon request. On the other hand, it is more complex to use On-Demand Documents than Delayed Document Assembly.


5.3.3 Report Synchronization

Similar to the challenges faced in Study Synchronization, we have challenges with report synchronization after reports have been exported and pushed into local RIS or PACS as part of the Foreign Exam Management (FEM) process or ad-hoc query/retrieve. This introduces an additional challenge for foreign reports in PACS, because PACS has ability to delete images, but reports are persisted in the RIS and/or PACS database. Local RIS have implemented solutions to publish addendums when report corrections are made. When publishing report corrections/addendums to the DIR, there are typically 2 ways:

1. The previous report is deprecated and replaced with a new report which contains the corrections as an addendum (recommended approach);

2. The addendum report containing the corrections is published as a linked document to the original report.

During FEM a copy of the report can be pushed to local the RIS and/or PACS. In a specific scenario, when a report is published for the wrong patient the standard process is to deprecate the original report, and replace with a new report that states “…previous report was deleted due to wrong patient…” Challenges arise when the incorrect report was processed by FEM and now persists in the foreign RIS and/or PACS. In the Infoway architecture, the local RIS (or HIS) is the Document Source that is responsible for creating the report for each study and registering it to the Document Registry. The use of Delayed Document Assembly allows the Registry to be aware of the report and at the same time let the Document Source to delay the actual creation of the specific report. The net benefit is save some processing time in the DIR and save some storage in the Document Repository for reports that are never requested. However, use of Delayed Document Assembly does NOT eliminate the need for XDS-I report synchronization in case the report is modified because the report object identity has already been assigned and registered, just simply not assembled.

The use of On-Demand Documents eliminates the need for report synchronization because the latest state of the requested report will be captured as a new report on demand upon request. On the other hand, it is more complex to use On-Demand Documents than Delayed Document Assembly. In the near term, it is incumbent upon the healthcare provide to assure that they have the most recent version of data (e.g., query for new documents every time). In the long term, report sync will be addressed.

5.3.4 Metadata Subscription (DSUB)

While the foreign exam content is maintained in a local system, the information must be synchronized with the originating source. The IHE Document Metadata Subscription (DSUB) profile is recommended. A local system is recommended to subscribe for any updates while the foreign content is consumed. When updates are made available, the local content should be replaced.


5.4 Archiving and Publishing

The following scenarios exist for archiving and publishing to the DIR: Case 1: Study exists in the local PACS STS (Short Term Storage) and in the DIR

• DIR is acting as the Long Term Archive (LTA). The local PACS are the Image Manager, but do not have an Image Archive. Image Archive is the DIR.

• Scenario 1: Study exists in the local PACS (STS) and in the DIR • Scenario 2: Study exists only in the DIR and a database entry (pointer) exists in

the local PACS (study has been purged from STS) Case 2: Study exists in the local PACS STS and in the local LTA. A copy of the study is

sent to the DIR • DIR is not the Long Term Archive (LTA). The local PACS is the Image Manager,

and the Image Archive. • Scenario 1: Study exists in STS, LTA and DIR • Scenario 2: Study exists in LTA and DIR

Case 3: Study exists in the local PACS STS and a copy of the study is sent to the DIR via DICOM send outside of the normal participating PACS archive process

• DIR may or may not be the Long Term Archive (LTA) • Study will likely be resent under the normal participating PACS archive process at

a later time – patient demographics or study information may have changed • Scenario 1: Study exists in STS, may or may not exist in a local LTA and exists in

DIR • Scenario 2: Study exists in STS and DIR

In addition to the above scenarios, when implementing Foreign Exam Management (FEM), the same study can also exist in a foreign PACS. We need to recognize there are various scenarios for archiving and publishing studies. Participating organizations should leverage the DIR as their LTA in order to reduce storage and operating costs associated with maintaining separate archives.

5.5 Timely Access to DI Results

There are various factors that can influence the decision on when to send DI results for publication, for example:

• Turnaround time for reporting on studies • Study splits and merges • Quality Control

The study-publishing event varies across organizations and PACS vendors:

• Sending copies of studies using 3rd party tools • Sending copies of studies based on internal trigger events, study status or on a batch

cycle • Natively archiving studies to the DIR as a DICOM LTA

The study-publishing event is dependent on the PACS vendor and the organization’s workflow.


A major consideration for the “trigger event” to publish studies has been the ability for study changes/corrections in local PACS to be propagated to the DIR. Often times there is considerable manual intervention required of the PACS Administrators to make study corrections in the local PACS, and also in the DIR. The result unfortunately, is a decision to delay the publishing of studies thus ensuring there is less of a chance for a published study requiring manual changes/corrections. Some sites publish studies as soon as they are acquired, other sites publish upon study verification, while others have chosen to publish once a report is available or the study is complete. If the vision for the DIR is to contribute to the electronic health record (EHR) to provide emergency care then patient’s images must be available for sharing on a timely basis. As part of normal workflow, it is highly recommended to publish when the report is available and finalized. As part of emergent situation, the images should be available within the DIR as soon as possible without a report. Image Manager has the responsibility for Disaster Recovery / Business Continuity Processes (DR/BCP) from the time of study acquisition until the study is archived. The DIR ’s also play a role in the DR/BCP for Image Manager; the recovery is handled through SLAs with the local PACS Vendor. The timing of when to publish studies to the DIR should not be dictated by DR/BCP considerations, these are local Image Manger considerations.

5.6 Exam Delete vs. Exam Deprecate

This section is to clarify and describe the differences between the terms ‘delete’ and ‘deprecate’ since these terms often cause confusion. Delete is the process to remove data from the DIR so it is no longer available. Audit trail would exist to detail the process and the prior existence of the data that was deleted. Deprecate means the previously published document is no longer active and will no longer be returned in query requests by default. Whether or not there is a replacement document is optional. Audit trail would exist to detail the process and the prior existence of the data that was deprecated. There is no standard mechanism to support versioning of DICOM objects. Additionally, there are no defined semantics if the PACS receive the same object (e.g., same SOP Instance UID) at a later time with different values. XDS does support versioning of data. DIR solutions can implement a Point in Time Architecture (PTA) which provides support for two related but different concepts:

• History – all information, both current and historical, that as of this moment, is believed to be true

• Audit Trail – all information believed to be true at some previous point in time The core concept in PTA is no information is ever physically deleted or updated. Purging data once it has exceeded its useful lifetime is handled under the Data Retention work item. PTA is a


product architecture decision, not a solution implementation decision. In other words, if the product architecture does not support such concept, it can be very difficult to implement as a solution. DIR solutions should support both Exam Delete and Exam Deprecate. Point in Time Architecture (PTA) provides a foundation that can help address both requirements.

5.7 Data Retention

Data retention rules can vary depending on the encounter: Clinical, Research, Clinical Trials. Within the DIR, data retention rules for archiving do not have to be the same as data retention rules for publishing. Data is saved (“retained”) in local systems (e.g., PACS) primarily for performance reasons. Due to the large datasets associated with Diagnostic Imaging, data is often cached in Short Term Storage (STS), to facilitate speed of retrieval and ease of access to the studies. Most PACS vendors have implemented a tiered storage model where data is moved from the cache (STS) to the archive (LTA) over time as the data ages. Foreign Exam Management (FEM) can bring studies acquired outside the organization into the local system to be used for comparative analysis. Data retention rules specific to FEM studies must also be developed and implemented. Where the DIR is also acting as the LTA for Image Manager then the data retention rules must be aligned across both Image Manager and DIR. The creation of a comprehensive audit trail is not a legitimate reason to keep data in perpetuity. Ontario Hospital Association (OHA) provides records retention policies and guidelines. Very few, if any, EHR-based systems have implemented processes to purge data based on data retention requirements. Without having built-in technical mechanisms to selectively purge data the costs involved to purge data using manual processes is prohibitive. Data retention policies and guidelines need to be developed at the national level to ensure consistency across the various clinical domains: Diagnostic Imaging, Laboratory, Pharmacy, etc.

5.8 Relationship between Accession#/SUID/Manifests

1 SUID may be referenced by 2 or more manifests • 1 manifest for all the SOPs in the study • 1 manifest for the SOPs identified in the Key Object Selection (KOS)

Study Split usually means two studies were incorrectly merged together; therefore Study Split is the mechanism to take the two studies apart again. The split out study is supposed to be different, and will have two separate Study Instance UIDs. The IOCM profile supports this use case (e.g., Incorrect Worklist Selection). A study split will result in 2 or more manifests:


• SUID#1 --> + SUID#1 + SUID#2 • 1 manifest for the original SOPs remaining in the study after the split • 1 manifest for the SOPs split out into the new study

Study Merge usually means two related studies (e.g., two separate procedure steps) are combined into one. One study is acquired using an Incorrect Worklist Selection. The study is corrected and merged to an existing study. IOCM profile supports this use case the same way as a Study Split. Depending on the local PACS Vendor the study merge event can be handled differently. Some PACS Vendors preserve the original SUID. Other PACS Vendors assign new SUID for the merged SOPs:

• SUID#1 + SUID#2 --> SUID#1 • SUID#1 + SUID#2 --> SUID#2 • SUID#1 + SUID#2 --> SUID#3

The manifest on its own does not provide enough information to uniquely distinguish the manifest. Document metadata used to register the document in the XDS Registry must provide the details to identify the contents of the document.

5.9 Minimum Supported SOP Classes

There are many different SOP classes produced by the variety of modalities and PACS: • Standard SOP Class • Standard Extended SOP Class • Specialized SOP Class • Private SOP Class

Additional details on the various SOP classes can be found at: ftp://medical.nema.org/medical/dicom DICOM Conformance Statements from each system will provide details for support of storage and display of the various SOP classes. Support for storage and display of SOP classes varies widely across Vendor systems. Conformance Statements are critical to interoperability because they provide important information for implementers and system integrators in order to determine whether or not applications do interoperate. When issues occur, Conformance Statements provide a source of information to potentially resolve any problems.

ftp://medical.nema.org/medical/dicom


Canada Health Infoway has developed Diagnostic Imaging (DI) Standards to allow authorized health care providers to electronically collect, store, manage, distribute and view patient radiology and images entirely in digital format. DI Standards are the building blocks that facilitate sharing of DI Information and make the information an integral part of longitudinal patient records regardless of where the images or reports are required or created. The IHE Basic Image Review profile requires the system to show the first frame of any image (based on the stated list of SOP classes). It is recommended that all image viewers, as a minimum, support the IHE Basic Image Review Profile. The required supported SOP classes specified by the IHE Basic Image Review Profile are presented in the table below. SOP Classes for Basic Image Review Profile

In addition, the following SOP classes should be supported as a minimum:

SOP Class UID SOP Class Name

1.2.840.10008.5.1.4.1.1.11.1 Grayscale Softcopy Presentation State Storage

1.2.840.10008.5.1.4.1.1.88.59 Key Object Selection Document Storage

1.2.840.10008.5.1.4.1.1.88.11 Basic Text SR Storage

1.2.840.10008.5.1.4.1.1.88.22 Enhanced SR Storage

1.2.840.10008.5.1.4.1.1.88.33 Comprehensive SR Storage

With DICOM, unsupported SOP Classes are not transferred to the system because they are not accepted during association negotiation.


6 Foreign Exam Management (FEM)

6.1 Introduction

From the IHE Radiology Import Reconciliation Workflow (IRWF) the definition of “foreign exam” is: “The current Import Reconciliation Workflow Profile does not cover many of the use cases or feature functionality desired by customers when handling foreign studies. By foreign study, we mean an imaging exam that was ordered, acquired, and reported on at some site external to the one where the study is currently being imported. Such foreign studies could be imported via removable media or through network interchange.” (IHE IRWF Supplement for Trial

Implementation)

6.2 General System Design Considerations:

The Foreign Exam Management design presented here uses the “do not check if foreign reports and images have been sent recently, just automatically resend” philosophy. The reason for this is that managing the state of these images and reports locally (Have all or some been deleted locally? Was the report amended elsewhere? Were additional images or mark-ups created?) is too difficult to manage and control, so the design direction is to just overwrite the data. This may result in sending the identical data multiple times, potentially wasting bandwidth, but ensures that the most recent data is available.

1. Patient Discovery: For FEM to work properly, it is imperative that patient identity resolution is maintained in a timely fashion such that patient linkage sets are as complete as possible.

2. Data Submission Consistency: For FEM to work properly, it is required that the images and reports have sufficient data included in the headers and meta-data for pre-fetching to work correctly. Images must be submitted consistent with the 8.0 Metadata and Standard Terminolgy section. Reports must be submitted to the DIR in CDA format with the header specification as defined in Section 7.0 “Diagnostic Imaging Report –CDA Definition” and ensure that the CDA header is mapped properly to the XDS meta data as described in Section 8.0 “Metadata and Standard terminology”. It should be noted that there may be a “proxy server” or “edge device” which converts the local report format to CDA and/or creates an XDS wrapper prior to submission to the DIR.

3. Images additions/changes/mark-ups: Additional images or annotations may be created as part of a post-processing step. This is often done prior to report generation, however. Waiting until the report is final may mitigate this issue. Consider other local workflows where this may not be the case, however. Once images have been sent to the DIR, any additional mark-up or post-generated images should immediately be sent to the DIR after image creation to make the additional data as broadly available as possible.

4. Amendment of a report: It is possible for a report to be amended after it is marked as final (completed/verified). It is possible that the pre-amended report was downloaded elsewhere between the time that it was marked final and the time that it was amended. Amended reports should be propogated to the DIR as soon as possible to minimize the time the stale data is present. Amended reports should contain the entire report text, not just the “delta” changes, and should be noted as “Amended”.

http://www.ihe.net/Technical_Framework/upload/IHE_RAD_Suppl_IRWF-b_Rev1-1_TI_2012_06_15.pdf

http://www.ihe.net/Technical_Framework/upload/IHE_RAD_Suppl_IRWF-b_Rev1-1_TI_2012_06_15.pdf


5. Viewing versus storing of reports: Image sets are very large and typically are required to be transferred in advance. Reports, however, may be viewed real-time on demand. Report viewing on demand mitigates the issues involve with storing reports locally including report amendments and purging of report objects. For remote systems which do store reports, remote users work processes should include downloading foreign information only immediately before they intend to use to minimize the time window of stale data being present on the DIR.

6. Foreign exam retention policy: It is recommended that local systems purge foreign studies from local systems within 7 days, but that parameter should be configurable. Foreign studies should not be re-archived long term. If a system localizes a foreign exam (e.g., updates to local patient id and procedure codes), the Study Instance UIDs and SOP Instance UIDs should not be changed, and the study should not be re-archived to the XDS Repository (DIR).

7. Notes regarding timing of messages: In the real world some orders are created days, weeks, or several months (e.g., oncology follow-up) in advance. Some DSS/OF systems can either send an HL7 Patient Arrived (ADT^A10- inpatient; ADT^A04- outpatient) message, hold an HL7 Order (ORM) message until the date of the new study, or send an HL7 order ORM with the status set to arrived (ORC5 = “a” arrived). However, some systems can only send Order messages at the time the order is created. See “Note 1” in the Basic Use case transaction diagram. All of these situations need to be considered.

6.3 Data Submission

For Foreign Exam Management to be able to work properly, data must be submitted properly. It is expected that all radiology reports be submitted to the XDS Repository as CDA documents with the meta data as described in Section 7.0 Diagnostic Imaging Report –CDA Definition with the XDS meta mapped properly Section 8.0 Metadata and Standard terminology.

6.4 Body Part Examined

The concept of “Body Part Examined” is also worth discussion. “Body Part Examined” can be very detailed (also referred to as “refined body parts”)- the DICOM standard lists hundreds of refined body parts in CID4. It would require a good deal of logic to be able to link related refined body parts which have different codes. To mitigate this problem, the concept of a “Coarse Body Part” has been introduced for XDS metadata mapping, specifically for the purpose of being able to determine if body parts (studies) may be relevant. (Also see IHE Radiology Change Proposal (CP) 248 for XDS for more information.)

This XDS Implementation Guide specifies the coarse body parts in Section 8.0 Metadata and Standard terminology. The intent is that the Coarse Body Part code will be a Pan-Canadian code for the long-term goal of cross DIR information sharing.

It is important to note the conversions of code mappings when a report or image is created:

1. Local procedure codes are used when orders are generated and in the requested procedures codes of DICOM objects.

2. Local procedure codes are also stored in the CDA report header and DICOM image objects


3. Local procedure codes are converted to Affinity domain-wide procedure codes (e.g., SNOMED CT).

4. When a CDA report is wrapped in XDS meta data or when an XDS image manifest is created, the local codes should be converted to Affinity domain-wide procedure codes. The Affinity domain-wide procedure codes should be stored in the XDS meta data, but the local procedures code may also be.

5. Affinity domain-wide procedure codes and/or anatomical body parts are converted (mapped) to Coarse Body Part codes. The Coarse Body Part code is stored in the XDS metadata of the images and report.

As described in the Use Cases below, code mapping may also be required on the Image and/or Document Consumer (upon receiving the information).

See the IHE Radiology White Paper – Code Mapping between Radiology Profiles for additional discussions on the usefulness of code mappings between systems. (http://www.ihe.net/Technical_Framework/index.cfm#radiology)

6.5 System-wide Design Image Object Move Priorities:

These image object move priorities refer to foreign images being stored into the local PACS system.

If all image objects are stored/archived in DICOM format, there are several possible transport mechanisms for the stored image objects which may especially affect system performance and side-by-side comparison abilities.

1. DICOM C-Store - IHE RAD-8 (IODs), RAD-17 (presentation states), RAD-27 (SRs), RAD-31 (KINs), RAD-45 (EDs)

2. DICOM WADO-WS, IHE [RAD-69] (XDS asynchronous option)

6.6 System-wide Design Report Format Priorities:

These report format priorities refer to foreign reports being stored from the DIR back into the local DSS/OF information system or Report Manager (RM).

Going forward, it is the goal that all reports will be stored in CDA format. However, they can be converted to several different formats. It is not prevalent today that reports are generated or stored in CDA, but rather will be a migration strategy.

Report formats have been less consistent over time and continue to evolve rapidly. Report formats can range from raw text, to DICOM SRs, to pdfs, to CDA documents.

Although a CDA radiology report template has not yet been defined by IHE, a CDA report format is defined as part of this implementation guide in Section 7.0 “Diagnostic Imaging Report –CDA Definition.”

Given the rapid evolution of report structures, it is imprudent to specify a single report format, so instead, a list of report format options is given in descending order of preference. All of the report conversions are only possible from CDA format. (For example, it is not possible to


convert from a DICOM Secondary Capture (SC) to any other format). The order of preference is:

1. Clinical Document Architecture (CDA) is the future direction and consistent with the IHE XDS models and transport profiles as specified in section 4.0 “Architecture”.

2. Text based HL7 v2.3 ORU is very prevalent and has been used for many years to exchange radiology reports, but even within the ORU message, there may be many variations. In an attempt to standardize ORU messges, the FEM defines the more specific ORU format from the IHE Simple Image and Numeric Report (SINR) Profile. It should be noted that the receiving system sometimes defines the HL7 ORU format, however.

3. DICOM SR – encapsulating a radiology report (not measurements) IHE RAD- 24: Report Submission

4. Almost any PACS system can display a DICOM Secondary Capture (SC) image. It is a very simplistic visual representation of pixel data, is not structured data, and cannot be searched on individual data fields. For some systems, this is the best method of display. The DICOM SC object is defined in the DICOM standard: DICOM Supplement 57 Revised Secondary Capture (SC) object definition, 2001. (ftp://medical.nema.org/medical/dicom/final/sup57_ft.pdf)

It should also be noted that IHE Cardiology recommends the use of HL7 V2.5 MDM messages for Diagnostic Imaging Report format. An HL7 v2.5 MDM message is similar to an HL7 v2.3 ORU message, but an MDM message is designed to transport an encapsulated document while an ORU message is specified as an embedded text document. The MDM message may be considered for use in future revisions of this Implementation Guide.

6.7 IHE and FEM Actors

IHE defines “actors” which perform specific roles or functions and does not specify which system (e.g., a PACS or a RIS) fulfills the various roles. FEM reuses several of the actors defined by the IHE Radiology Scheduled Workflow, Cross Enterprise Document Sharing for Images (XDS-I), ITI Cross Enterprise Document Sharing (XDS), and Patient Identity Cross Reference (PIX) profiles which are defined in the IHE Technical Frameworks at www.ihe.net.

FEM, however, adds a new actor called the “Foreign Exam Manager”. The Foreign Exam Manager, based on incoming patient schedules or patient arrivals, moves image and document objects across institutions or departments to where they may be needed for review.

The actors are shown in the Use Cases described in the following sections.

6.8 Clinical Use Cases

To best address real clinical issues, use cases are described to illustrate the problem that is being solved. First, an abbreviated version of the clinical use case is described and then a more detailed process flow is given.

There are two architecture representations: the eventual goal/future direction of the IHE XDS/XDS-I based transactions and the still existing DICOM-only transactions. Although there

ftp://medical.nema.org/medical/dicom/final/sup57_ft.pdf

http://www.ihe.net/


will be many DICOM/XDS hybrid situations along the migration path, they will all be specific to a DIR and we did not try to represent them here.

6.8.1 Use Case 1: Basic – Pre-fetching for a New Radiology Order

A patient is scheduled for a radiology study at local Hospital A. A search is made for other related image sets or reports throughout the affinity domain (DIR) and that information is automatically brought, in a useful manner (i.e., may require tag/data morphing), to the local hospital for review. This retrieved information is not archived again locally, but rather eventually migrates off the local system.

Flow:

1. A registered patient is determined to have a need for a radiology study at Hospital A. 2. When the order is created and scheduled at the Department System Scheduled/Order

Filler (DSS/OF), the order is sent from the DSS/OF to the Image Manager (if applicable) and the Foreign Exam Manager (FEM) using the local Hospital A patient id, issuer of assession number, and accession number.

3. The FEM triggers the pre-fetch from a patient arrived (ADT^A10; ADT^A04) message or an order updated (ORM ORC5 = a” arrived) message. –OR- The FEM “holds” the scheduled order until a configurable amount of time prior to the study date.

4. The FEM checks the affinity domain for other patient ids for this patient, and, for those alternate patient ids, checks for additional studies in other locations.

5. If other health information is found, it is checked to be relevant (pre-fetch keys). 6. If reports are found to be relevant, the prior reports are retrieved, if necessary (cannot

just be “viewed on demand”). Based on “destination information” configured for each site, the report format may need to be converted and report tags may need to be morphed, if possible. The report may be sent to the DSS/OF, the Report Manager (RM), both, or neither.

7. If images are found to be relevant, the prior images are retrieved. Based on “destination information” configured for each site, image tags may need to be morphed, and the images are sent (DICOM C-Store) to the IM.

8. After the configured elapsed time, the DSS/OF, RM, and IM migrate the foreign exam from the local storage (deletes reports and image objects).

Note that the exact sequence of steps in the diagrams below is not required (e.g., images could be retrieved before reports.)


Figure 11 - XDS Use Case 1

Note 1: A new patient order message (new ORM), a patient arriving (ADT^A10) message or an updated order (ORM with ORC5 = “a” for arrival) can trigger the pre-fetch scenario demonstrated above. The new ORM messages may be more prevalent, but the significant disadvantage is that new order ORM messages are often sent out when the scheduling occurs. A radiology order may be scheduled days, weeks, or even many months in advance (oncology follow-up, for example). In this case, the FEM actor is required to have a database to maintain scheduled events which will significantly add to the cost and maintenance of such a system. If a patient arriving message is employed or if the ORM can be withheld until the date of the order, the FEM actor may be a transaction-based system which would reduce maintenance.

Note 2: It should be possible to use the “Issuer of Accession Number” sequence to ensure that no Accession Number collisions occur. “Issuer of Accession Number” is not typically displayed on a user interface, however.

Note 3: DICOM Modality Performed Procedure Step (MPPS) and Storage Commit (SC) are also recommended to be used to verify the successful transmission of the image set. The DICOM C-Store Success code also signifies completion, but may be less reliable.


6.8.2 Use Case 2: Adhoc or On-Demand Image Fetch from DIR to Local PACS

Note that the Patient ID will be different in separate hospital/clinic domains.

Ad hoc or “select from a list” queries require a user interface. That is, a patient-based query is made from Hospital A (as an XDS-I Image Document Consumer or Image Manager) to the XDS Registry (or possibly DIR in a DICOM-only environment) to get a list of all information that may be relevant to this patient. A user interface is required to make a selection from the list. This user interface integration is outside the scope of FEM although the tag morphing discussion will apply to import the images and reports.

If it is preferable to retrieve prior information for a patient visit (probably for performance reasons) rather than waiting to select from a list manually, the “basic use case” is applicable, although it may be more likely that a patient arriving (ADT^A10; ADT^A04) message is available than an ORM. In either case, the rest of the transactions are the same.

6.8.3 Use Case 3: Pre-fetch of Relevant Priors from DIR into local PACS Initiated by Patient Visit (non-radiology workflow)

There are other clinical areas such as oncology or neurology which need to view imaging studies and reports from across the affinity domain. For example, a follow-up, second opinion, consult, or treatment, visit may benefit from automatic pre-fetching based on scheduling or arriving message from a non-radiology scheduling system.

A new radiology order is not created (no new ORM trigger message), however, a patient arriving message may be triggered. In this case, the “Basic Use Case” is still applicable, but the trigger event will more likely be an ADT message. This message is most likely coming from a different scheduling system other than the radiology DSS/OF, but should have the same format. A Scheduled Visit (S12) message may also be an effective trigger for the FEM.

Furthermore, the pre-fetch criteria based on the originating system may be used differently. For example, a neurologist may not care what the modality type is (modality = “all”), but “Coarse Body Part” may only be neuro related. Oncologists may want to see all available information. It is critical to be able to “cast a wide net” for other clinical areas, which could perhaps be optimized and refined in the future.

It is assumed in this use case that the clinician (e.g., neurologist or oncologist) has access to be able to review the images on the local PACS system. Conversely, a separate destination device could be set for these images and reports based on the originating system of the trigger message.

6.8.4 Use Case 4: Report-only Prior Retrieval

There may be cases where physicians, e.g, referring physicians, only want to see prior reports and not necessarily sift through thousands of CT images.

From a system architecture perspective, it is preferable to have a viewer to view the report(s), which can typically be retrieved in a very short amount of time (as opposed to very large image sets). An ad hoc (on demand) query based on local patient id would be sufficient to deliver the list of available reports.


However, there may be systems or occasions where the report viewer from the XDS Repository (DIR) is not possible or optimal.

In this case there should be a mechanism to pre-fetch reports only for local temporary storage. The trigger events will most likely be a patient arriving ADT message or a scheduled visit (S12) message from a non-radiology scheduling system. The Report Manager receiving the report will most likely be different from the Report Manager system in radiology (a separate destination with different tag morphing requirements). Note that this scenario brings up issues with report amendments/synchronization and report migration.

Finally, an oncologist or other specialist may want to review a complete case prior to the patient’s arrival. A trigger event would need to be established to enable this scenario.

6.8.5 Use Case 5: Report is Amended after Pre-fetch has Occurred to Local System

There is a race condition which does exist where a report could be amended after it has been pre-fetched to a different institution and stored locally there.

For reports which are stored as DICOM SR or SC, these race conditions could be mitigated by implementing IOCM (see section 5 of this document) or by designing the system as described in the System Design Consideration section (see section 6.2 of this document).

6.8.6 Use Case 6: Images are Added/changed after Pre-fetch has Occurred to Local System

There is a race condition which does exist where additional images could be created or annotated after the study has been pre-fetched to a different institution. The amount of time for these race conditions need to be mitigated by implementing IOCM or by designing the system as described in the System Design Consideration section (see section 6.2 of this document).

6.8.7 Use Case 7: STAT: Emergency Patient comes in and is Imaged at Local Site

There are two separate cases within the STAT case: unidentified patient and known patient.

In either case, the patient is flighted/ambulanced to a tertiary care or other site. Today, a CD or DVD is usually generated and taped to the gurney or the patient folder prior to departure.

Today, the tertiary site is often called with the notification that a patient transfer is being inititated. Upon arrival at the tertiary care center, the patient is typically registered with their own information or under a temporary patient ID. An order is created. The images on the CD or DVD are imported, which can take 20 minutes or more. The report may or may not be on the CD/DVD and often cannot be imported. The DICOM attributes are often not morphed properly or must be manually entered/matched.

After the episode, if the patient was registered under a temporary patient ID, the patient IDs must be updated at both sites to local identifiers.

There are several potential changes to this scenario which should be discussed for each DIR:

1. Images could be manually sent (DICOM C-Store) directly to the receiving site. Reports may or may not be able to be manually sent or faxed.


2. Images could be sent to the XDS Image Source (DIR) as soon as possible. The report could be pushed to the XDS Repository (DIR) (manual intervention probably required) prior to the report even being finalized. By mutual agreement in advance and mutually defined processes, the tertiary site could be called (phone) and the patient pre-registered. A new order (ORM) or patient arriving ADT message could trigger automated pre-fetching from the FEM. In this case, the DICOM attributes in the images would be morphed correctly. The report attributes would be morphed correctly and the report reformatted, if necessary. This latter case would have the added value that true relevant priors would also be automatically pre-fetched for identified patients.

6.9 Exceptions/out of Scope for this Version:

1. Patient Matching Algorithms: In either the XDS Patient Identifier Cross-reference Manager (PIX Manager) actor or in the DICOM model where the Foreign Exam Manager (FEM) actor, the algorithm used to match patient identifiers is out of scope of this Implementation Guide and will, in fact, probably vary from DIR to DIR.

2. Local retention of foreign exams: There should be a testable configuration parameter for each PACS system which determines how long a local PACS system should retain a foreign exam prior to migrating it from the local system. It is recommended that this length be set to 7 days, however, it will most likely vary by individual workflows from DIR to DIR (varies site to site).

3. Local management of foreign imaging exams: It is strongly recommended that local systems migrate (delete) foreign images after a period of time, but how the systems implement and manage that is not defined. For example, some PACS systems have a separate AE title that foreign exams are sent to or the PACS may check for pre-fixed accession numbers, and these exams are not archived long term. Some PACS systems use the IHE Import Reconciliation Workflow (IRWF) flags to determine whether or not to archived long term. (Specifically see IHE RAD Supplement IRWF: Table 4.5-4: Import Instruction Codes, where the “Archive Instruction Code” can be set to “Coding Scheme: IHERADTF; Code Value: IRWF012; Code Meaning: Do not archive”.) Any of these implementations are fine as long as they serve the intended purpose that exams are not re-archived long term. This implementation will also vary from system to system.

4. Local management of foreign reports: In general, image sets are required to be transferred in advance due to the data size and transfer times. It is possible, however, for reports to be viewed “real time” rather than downloaded and stored. However, if the report is downloaded and stored locally, the Report systems should behave similarly for purging foreign documents. In the event that local reports cannot be purged in a reporting system, consider sending a “This report may be stale.” as the content of an addendum report message. Sometime after the report was sent. For example, when images are purged and an audit log is created, the FEM could send another/separate ORU to systems that received the report indicating that the report may be stale. Users should then use the DIR viewer to view most recent report if they get a “stale report message”.

5. Limitation on Proxy Servers: It is assumed that the final destination is known for both the receipt of the images and reports (that is, Image Manager and Report Manager). It is possible that there is a proxy server routing images and reports. If this latter situation


exists, it may not be possible to morph the tags appropriately based on final destination information.

6.10 IHE Volume 2 Material – Transactions

This section contains the detailed technical information typically found in Volume 2 of IHE Technical Framework documents.

6.10.1 Pre-fetch Keys:

In general, the approach should be a “broad” pre-fetch. There is a general concern that if pre-fetch rules are too stringent, that appropriate studies will be inadvertantly missed. It is better to given the radiologist the final determination about whether or not something is appropriate, rather than attempting to become too granular.

The XDS-I metadata attributes are defined in the XDS-I IHE profile Table 4.68.4.1.2.3-1: XDS-I-specific Metadata Requirements. (http://www.ihe.net/Technical_Framework/upload/IHE_RAD_TF_Vol3.pdf)

The DICOM attributes listed below are defined in NEMA DICOM Part 16: Content Mapping Resource, 2003. (http://medical.nema.org/dicom/2003/03_16pu.pdf)

“Rank” is also a FEM system configuration parameter (configurable by receiving site) which defines the last number of “n” studies which should be retrieved in order of study date (most recent “n” studies).

“Laterality” was considered for a pre-fetch key, however, laterality can be pre-coordinated in some coding schemes (e.g., RadLex) or post-coordinated in a separate value in other coding schemes (e.g., SNOMED CT). Also, “Laterality” is a series level attribute. For these reasons, laterality will not be considered as a pre-fetch key. For sites with coding schemes which separate laterality, a FEM actor implementation should consider implementing laterality as an optional and configurable pre-fetch key.

“Practice Setting Code” (“Radiology”) was considered for a pre-fetch key, but was dismissed because, for example, CT Angiography and Nuclear Medicine could be considered part of radiology or cardiology and it was determined that would be better to not miss any possible studies. Note: if in a real-world deployment the retrieve needs to be further constrained, consider verifying “practiceSettingCode” set to either “Radiology” or “Cardiology”.

It should be possible to do a search on modality equals “all”, possibly by just not checking the modality values.

The FEM manager should consider a “reality check” during system configuration to verify that if not many of the other parameters are being verified, the “rank” value should be restricted to a ensure that only a reasonable number of studies will be pre-fetched and not place an unreasonable burden on server resources (e.g., bandwidth usage, etc.).

http://www.ihe.net/Technical_Framework/upload/IHE_RAD_TF_Vol3.pdf

http://medical.nema.org/dicom/2003/03_16pu.pdf


Common Data Element Name

XDS Environment DICOM Environment

XDS-I

Meta

Data

Value DICOM Attribute Number

DICOM Attribute Name

Rank Not applicable Configurable parameter to determine number of studies to pre-fetch. This value should be defaulted to “2 studies”.

Not applicable

Configurable parameter to determine number of studies to pre-fetch. This value should be defaulted to “2 studies”.

Modality eventCodeList 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. See DICOM 2011 PS 3.16 for DICOM Context Group definitions. This attribute (modality is a series level code, e.g., PET, CT in one study) can contain multiple codes and there is not any specific ordering assumed in these codes. Note that this can be a multiple valued item.

CID 29

(0008,0060)

Acquisition Modality (DICOM defined code set)


Common Data Element Name

XDS Environment DICOM Environment

XDS-I Meta Data Value DICOM Attribute Number

DICOM Attribute Name

Study Date

serviceStartTime 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.

DCM 111060

(0008,0020)

Study Date

(DICOM defined format)

Anatomic Region Code

eventCodeList DIRs shall use the “Coarse” list of anatomic body parts defined in the XDS Metadata section of this implementation guide. See “Coarse Body Part discussion” in the preceding sections.

It will be up to the submitting device to correctly map the fine anatomic body part to the coarse body part list.

Note that this can be a multiple valued item.

CID 4

(0008,0104) SQ

Anatomic Region

There are several hundred codes defined in DICOM CID 4, although “Anatomic Region” may also be a free-format text field on the modality as well as a drop-down box of codes.

In the DICOM-only environment (see section 10 of this document) it will be a requirement of the FEM to map inbound request to a more general (coarse) body part.

6.10.2 HL7 v.2 ORM/OMI Order Schedule Message Specification:

The message to schedule a procedure shall be used directly from the IHE Radiology Technical Framework “Procedure Scheduled RAD-4” Message (HL7 ORM or OMI message per the exact format specified in the IHE Technical Framework 2011. (http://www.ihe.net/Technical_Framework/upload/IHE_RAD_TF_Vol2.pdf)

http://www.ihe.net/Technical_Framework/upload/IHE_RAD_TF_Vol2.pdf


Also, for reference, there is an automated order creation mechanism defined in the IHE Radiology Import Reconciliation Workflow (IRWF) profile in section IHE RAD TF-1: 21.2.3 Automated Order Placement and Scheduling Option

6.10.3 HL7 v.2.x Patient Arrival Messages Specification:

There are two types of arrival messages, inpatient (ADTÂ10) and outpatient (ADTÂ04).

This specification is for the HL7 ADTÂ10 (inpatient) message which could be sent from the DSS/OF actor to the FEM, IM, or RM actors to indicate patient arrival. Specifically, IHE IT Infrastructure IHE ITI-2b:3.31.7.28 Patient Arriving – Tracking – ADTÂ10ÂDT_A09.

The IHE IT Infrastructure transactions defines an ADT message to monitor movement of a patient. Parts of this transaction are highlighted here:

MSH-9 is valued ADTÂ10ÂDT_A09.

6.10.3.1 Message Static Definition

Static definition of message ADTÂ10ÂDT_A09

Segment Meaning Usage Card. HL7 chapter

MSH Message Header R [1..1] 2

SFT Software Segment O [0..*] 2

EVN Event Type R [1..1] 2

PID Patient Identification R [1..1] 3

PD1 Additional Demographics O [0..1] 3

PV1 Patient Visit R [1..1] 3

PV2 Patient Visit – Additional Info O [0..1] 3

DB1 Disability Information O [0..*] 3

OBX Observation/Result O [0..*] 7

DG1 Diagnosis Information X [0..0] 6

This specification is for the HL7 ADTÂ04 (outpatient) message which could be sent from the DSS/OF actor to the FEM, IM, or RM actors to indicate patient arrival. Specifically, IHE IT Infrastructure IHE ITI-2b:

The IHE IT Infrastructure transactions defines an ADT message to monitor movement of a outpatient. Parts of this transaction are highlighted here.

This specification is for the HL7 ADTÂ04 (inpatient) message which could be sent from the DSS/OF actor to the FEM, IM, or RM actors to indicate patient arrival. Specifically, IHE IT Infrastructure IHE ITI-2b:3.31.7.3 Register a Patient – ADTÂ04ÂDT_A01.

Parts of this transaction are highlighted here, see the reference above for the full definition:

MSH-9 is valued ADTÂ04ÂDT_A01.


Static definition of message ADT^A04^ADT_A01

Segment Meaning Usage Card. HL7 chapter

MSH Message Header R [1..1] 2

SFT Software Segment O [0..*] 2

EVN Event Type R [1..1] 2

PID Patient Identification R [1..1] 3

PD1 Additional Demographics O [0..1] 3

ROL Role O [0..*] 15

NK1 Next of Kin / Associated Parties O [0..*] 3

PV1 Patient Visit R [1..1] 3

PV2 Patient Visit – Additional Info O [0..1] 3


DB1 Disability Information O [0..*] 3

OBX Observation/Result O [0..*] 7

AL1 Allergy Information O [0..*] 3

DG1 Diagnosis Information O [0..*] 6

DRG Diagnosis Related Group O [0..1] 6

--- --- PROCEDURE begin O [0..*]

PR1 Procedures R [1..1] 6


--- --- PROCEDURE end

GT1 Guarantor O [0..*] 6

--- --- INSURANCE begin O [0..*]

IN1 Insurance R [1..1] 6

IN2 Insurance Additional Info. O [0..1] 6

IN3 Insurance Additional Info - Cert. O [0..1] 6


--- --- INSURANCE end

ACC Accident Information O [0..1] 6

UB1 Universal Bill Information O [0..1] 6

UB2 Universal Bill 92 Information O [0..1] 6

PDA Patient Death and Autopsy O [0..1] 3

Specifically, the Patient Visit segment contains the visit status. Almost all of the optional segments defined in this IHE transaction are not relevant to FEM.

6.10.4 HL7 v.2.x ORU Results Message Specification:

This specification is for the HL7 ORU message sent from the FEM actor to the DSS/OF, IM, or RM actors.


Results (ORU) integration is often a significant effort due the extensive variations possible in ORU messages. To minimize costs and standardize on a specific ORU implementation, the following message format is adopted from IHE.

The IHE Radiology Simple Image and Numeric Report (SINR) Profile defines an ORU report message sent from a Report Manager (RM) to an Enterprise Report Repository (ERR) actor in IHE RAD-TF2:4-28 (RAD-28). Parts of this transaction are highlighted here:

ORU Structured Report Export Chapter in HL7 2.3.1

MSH Message Header 2

PID Patient Identification 3

[PV1] Patient Visit 3 (see note)

OBR Order detail 7

{OBX} Observation Results 7

Note: PV1 is required if use of PV1-19 Visit Number is required per the applicable regional or national appendices to the IHE Technical Framework (See RAD TF-4)

In the PID segment, the Patient ID, PID-3 shall be morphed to be the local PID, including Assigner.

There are several possible variations within the report text: 1. Text only solution: Multiple OBX segments shall be sent limited to 80 characters each to

assist with formatting on the local system. 2. Embedded HTML solution: Multiple OBX segments shall be sent limited to 80 characters

each. However, HTML structures may be included in the text to assist with rendering on the local system.

Also, note from the Foreign Exam Management (FEM) System Design Considerations section (6.2) that an amended report should contain the entire report text, not just the “delta” changes.

6.10.5 CDA Report Format:

The report format for a CDA report is defined in section 7.0 Diagnostioc Imaging Report – CDA Definition.

6.10.6 FEM Attribute Tag Morphing:

As part of the IHE Import Reconciliation Workflow (IRWF) Automated Import Option (http://www.ihe.net/Technical_Framework/upload/IHE_RAD_Suppl_IRWF-b_Rev1-1_TI_2012_06_15.pdf ), a very extensive table has been generated to discuss how to handle most identifying attributes in a DICOM header. This table is contained in the IRWF Supplement as IHE Radiology TF-2: A.5: Imported Object Integration – Critical Attributes.

The table below summarizes key attributes from that table. There are certain instances where data must be morphed from the foreign system to work properly on the local system. The table below lists all of the data elements which may be morphed by the Foreign Exam Manager in image objects or reports:


FEM Attribute Tag Morphing Requirements and Recommendations

# HL7 ORU element

DICOM Attribute Name/Number

Morphing/ Coersion Description

Required (R) or Optional (O) (as determined by importing enterprise per IRWF)

PID-5 Patient Name (0010, 0010)

Copy requesting (Hosp A) name is recommended in IRWF

O

PID-7 Patient Date of Birth (0010, 0030)

Copy requesting (Hosp A) DOB is recommended in IRWF

O

PID-8 Patient Sex (0010, 0040)

Copy requesting (Hosp A) sex is recommended in IRWF

O

PID-3 Patient ID (0010, 0020)

Convert to local PID R

PID-3^^^ Other Patient ID(2) (0010, 1000)

Merge Foreign (original) PID R

OBR-4 PERFORMED (0008,1032) and REQUESTED (0032,1064) Procedure Code Sequences

Convert to local PACS procedure code so that PACS hanging protocols will work (where import list should be 8-20 codes max)

R

Accession Number (0008, 0050)

Pre-pend two letters from originating site or use “Issuer of Accession Number” to avoid collisions. OR, set to zero length. Ensure <= 16 characters DICOM limit.

O

Note that IHE Radiology Import Reconcilliation Workflow (IRWF) gives significant guidance on additional elements, but the attributes listed in the table above were deemed important enough to call out here.

The following shall not be morphed by the FEM actor: • Study Instance UID (0020, 000D)

IRWF does allow Study Instance UID to be changed but only in the case where a system is known to be violating UID rules. IHE RAD TF-2: Note: IHE-A.5-2.6 gives additional guidance on how and when a Study Instance UID can and should be altered.


6.10.7 Unified list of what must be configurable on FEM:

The following, at a minimum, shall be configurable on the FEM:

1. Rank – per receiving site and per report or per image failure. Retrieve the last “n” studies as determined by study date. Should be variable by image studies and reports and be configurable per site.

2. Re-try – per receiving site and per report or per image failure. Re-tries should be initiated if a move (C-Move) of an image or the sending of a report fails. It should be possible to set the number of retries to zero also.

3. Report Destination(s) per Site – where should the report be sent (usually DSS/OF, IM, both, or neither) for each site.

4. Report Format- identify the receiving report format type per report destination. 5. Originating Site – optional: 2 letters to prepend to Accession Number to identify

originating site. 6. Requested/Performed procedure codes – subset to make hanging protocols work. Per

site.

6.10.8 Unified/summary list of audit logs:

The IHE transactions specify when audit logs should be created as well as the content of the audit log message. Other audit logs should be considered however. For example, an IM could create an audit log when images are deleted locally. The FEM should create an audit log identifying which tags are morphed in objects. Various triggers should be discussed and identified within a DIR.


7 Diagnostic Imaging Report -CDA Definition

This section is intended to provide the content for the Diagnostic Imaging (DI) Report Section for

the Canada Health Infoway XDS Implementation Guide as prepared by SCWG 10. The base

definition (the Header) of this DI Report is defined by Canada Health Infoway SCWG 2, and is

referenced below.

The Section is divided in four subsections: Background, General Recommendations, DI Report

Header and DI Report Body.

The focus of this section of the XDS Implementation Guide focuses on the DI Report format and

content and does not specify the transport. It is assumed that IHE XDS/XDS-I/XDR-I profiles are

used to transport DI Reports. Please refer to the IHE ITI and IHE Radiology Technical

Framework and related integration profiles, as well as the other sections in this XDS

Implementation Guide for guidance on transport of data.

In addition, it is expected that the transfers of care will occur in an environment where the

physician offices and hospitals have a coordinated infrastructure that serves the information

sharing needs of this community of care. Several mechanisms are supported by IHE profiles:

• A registry/repository-based infrastructure is defined by the IHE Cross Enterprise Document Sharing (XDS) and other IHE Integration Profiles such as Patient Identification Cross-Referencing (PIX) and Notification of Availability of Documents (NAV). An image source for imaging study exchange is defined by Cross Enterprise Document Sharing for Imaging (XDS-I) as an Image Document Source.

• A media-based infrastructure is defined by the IHE Portable Data for Imaging (PDI) profile.

• A reliable messaging-based infrastructure is defined by the IHE Cross Enterprise Document Reliable Interchange for Images (XDR-I) profile.

• All of these infrastructures support security and privacy through the use of the Consistent Time (CT) and Audit Trail and Node Authentication (ATNA) profiles.

• For more details on these profiles, see the IHE IT Infrastructure Technical Framework and the IHE Radiology Technical Framework.

7.1 DI Report Background

Defining structured DI Reports are a multi year effort. In this version of the XDS Implementation

Guide our focus is on defining the Header and Body of the CDA formatted DI Report and identify

any potential gaps and alignment issues with IHE Rad/ITI profiles. In future years templating of

the DI report, further refinements and use of terminology/lexicon standards will be introduced.


7.1.1 HL7 CDA

SCWG 10 made the decision to base the DI Report content format on HL7 CDA Release 2. This

leverages the content format used by other domains and the work done by SCWG 2 and uses

the pan-Canadian CDA Header as the format for all clinical documents. Significant work has

also been done by IHE on Content Profiles, most notably, IHE Patient Care Coordination (PCC),

Laboratory and Cardiology.

7.1.2 IHE XDS/XDS-I

CDA is a defined format in XDS. In XDS-I/XDR-I CDA is used to wrap any data, including a

report (plain text) but not as CDA content (structured). The XDS Implementation Guide adopts

the XDS-I CDA Structured Report with Structured Headings Option for the Imaging Document

Source.

7.1.3 Guideline Recommendations • The DI Report SHALL be based on the HL7 Clinical Document Architecture (CDA)

Release 2 format specification. • The DI Report SHALL be based on the Canadian Clinical Document Architecture

Guidance Paper, Version 2 (final), April 2013. • The Header of the DI Report SHALL be based on the Canada Health Infoway “CDA

Header Implementation Guide”; version is 1.0 (Final). • The DI Report CDA Header and Body SHALL leverage the Implementation Guide for

CDA Release 2: Imaging Integration - Basic Imaging Reports in CDA and DICOM Diagnostic Imaging Reports (DIR), Release 1.0, March 2009.

The following sections describe the specific elements of the Header and Body as they pertain to

the DI Report.

7.2 Conformance Verbs, Cardinality, Constraints, Null Flavors, Notations, and Canadian Realm Data Types

Conformance verbs, cardinality, constraints, null flavors, notations, and Canadian Realm Data

Types are all inherited directly from the Canada Health Infoway “CDA Header Implementation

Guide” referenced above, sections 1.11 and 2.3.

7.3 Diagnostic Imaging (DI) Report Header

The Header of the DI Report SHALL be based on the Canada Health Infoway “CDA Header

Implementation Guide”; version is 1.0. This section will either clarify or specify specific Header

elements and their content as they pertain to the DI Report. The optionality, cardinality and

vocabulary constraints for elements inherited directly from the CDA Header Implementation

Guide are not repeated here to avoid synchronization issues.


Diagnostic Imaging Report Header

Template Name Canada Health Infoway Diagnostic Imaging Report Header

Template ID 2.16.840.1.113883.2.20.4.1

Parent Template 2.16.840.1.113883.2.20.4

Header Element N/A

General Description A Diagnostic Imaging report specification of the pan-Canadian healthcare report.

Opt and Card

Description Template Specification

Document Vocabulary Constraint

Clinical Document Header/ realmCode

CHI: CDA Hdr IG:

Section 2

Clinical Document/typeId CHI: CDA Hdr IG:

Section 2

ClinicalDocument/templateId CHI: CDA Hdr IG:

Section 2

ClinicalDocument/classCode CHI: CDA Hdr IG:

Section 2

ClinicalDocument/moodCode CHI: CDA Hdr IG:

Section 2

R[1..1] ClinicalDocument/id 7.3.1 OID format, not UUID; 64 char limit

R[1..1] ClinicalDocument/code 7.3.2 Code value "Diagnostic Imaging Report"

R[1..1] ClinicalDocument/title 7.3.3

R[1..1] ClinicalDocument/effectiveTime 7.3.4

ClinicalDocument/confidentialityCode CHI: CDA Hdr IG:

Section 2

ClinicalDocument/languageCode CHI: CDA Hdr IG:

Section 2

ClinicalDocument/setId CHI: CDA Hdr IG:

Section 2

ClinicalDocument/versionNumber CHI: CDA Hdr IG:

Section 2


Opt and Card



RecordTarget (Patient) CHI: CDA Hdr IG: Section 2

Author CHI: CDA Hdr IG: Section 2

DataEnterer CHI: CDA Hdr IG: Section 2

Informant CHI: CDA Hdr IG: Section 2

Custodian CHI: CDA Hdr IG: Section 2

InformationRecipient CHI: CDA Hdr IG: Section 2

LegalAuthenticator CHI: CDA Hdr IG: Section 2

Authenticator CHI: CDA Hdr IG: Section 2

Participant (Support) CHI: CDA Hdr IG: Section 2

O[0..n] InFulfillmentOf priorityCode scheme: 1.2.208.177.1.0.1.4

7.3.5

O[0..n] DocumentationOf/serviceEvent

Physician Reading Study Performer: 2.16.840.1.113883.10.20.6.2.1

Anatomic Region/Body Part Affected:

1.2.208.177.1.0.3.4

Modality:

1.2.208.177.1.0.3.3

7.3.6

Authorization/consent CHI: CDA Hdr IG: Section 2

ComponentOf CHI: CDA Hdr IG: Section 2


7.3.1 ClinicalDocument/id

The id element is an instance identifier data type (see HL7 Version 3 Abstract Data Types). For

compatibility with DICOM-SR, this specification constrains the root attribute to an OID, and

UUIDs are prohibited. Since every UUID has an OID representation (see ITU-T X.667), this

constraint should not pose an exceptional burden on implementers. If an extension is present,

the root uniquely identifies the scope of the extension. The root and extension attributes

uniquely identify the document.

OIDs are limited by this specification to no more than 64 characters in length for compatibility

with other standards and IGs.

The ClinicalDocument/id element SHALL be present. The ClinicalDocument/id/@root attribute

SHALL be a syntactically correct OID, and SHALL NOT be a UUID.

OIDs SHALL be represented in dotted decimal notation, where each decimal number is either 0

or starts with a nonzero digit. More formally, an OID SHALL be in the form ([0-2])(.([1-9][0-

9]*|0))+

When a DICOM SR report is transformed to a CDA Diagnostic Imaging Report, a new

ClinicalDocument/id is created by the transforming application, and DICOM Attribute (0008,

0018) SOP Instance UID of the original document is used as a reference to the parent

document.

OIDs SHALL be no more than 64 characters in length.

7.3.1.1 ClinicalDocument/id example

<id extension='999021' root='2.16.840.1.113883.19'/>

7.3.2 ClinicalDocument/code

The code element SHALL contain exactly one [1..1] code.

The code element SHALL comply with the following value set assertion, effective 2013-04-01:

the set of codes in the expansion of value set CDAHeaderDocumentType

2.16.840.1.113883.2.20.3.206 STATIC and SHALL NOT contain nullFlavor.

Please note that the pan-Canadian value set is to be defined still. Until this is a defined and a suitable displayName for the DI Report is named the ClinicalDocument/code SHALL be based on LOINC Table 4: LOINC® Document Type Codes 2.16.840.1.113883.6.1 LOINC DYNAMIC and SHALL be 18748-4 "Diagnostic Imaging Report" 2.16.840.1.113883.6.1 LOINC STATIC.


Please note that we using the long name “Diagnostic Imaging Report” and not “Diagnostic Imaging Study”. This name is consistent with the Implementation Guide for CDA Release 2: Imaging Integration - Basic Imaging Reports in CDA and DICOM Diagnostic Imaging Reports (DIR). The use of the word “Study” leads to confusion as in radiology this is commonly understood to be the images itself. We want to refer the report instead. The report is in most cases linked to an imaging study that contains the images.

7.3.2.1 ClinicalDocument/code example

<code code="18748-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"

displayName="Diagnostic Imaging Report"/>

7.3.3 ClinicalDocument/title

The title element SHALL contain exactly one [1..1] title and SHALL NOT contain nullFlavor.

Note that the title does not need to be the same as the display name provided with the document type code. If there is no title in a transformed DICOM SR report, then it is suggested to use the LOINC® display name to populate this required field or alternative as defined by the pan-Canadian ClinicalReportObservationType.

7.3.3.1 ClinicalDocument/title example

<title>Diagnostic Imaging Report</title>

7.3.4 ClinicalDocument/effectiveTime

ClinicalDocument/effectiveTime represents the document creation time, when the document first

came into being. It is the creation timestamp of the DI report document, not of the imaging

procedure. The effectiveTime shall be precise at least to the day, and should be precise to the

minute.

When the CDA document is a transformation from an original document in some other format,

the ClinicalDocument/effectiveTime is the time the original document is created, not the current

time.

The effectiveTime element SHALL contain exactly one [1..1] effectiveTime and SHALL NOT

contain nullFlavor

a. The content of effectiveTime SHALL be conformant to Canadian realm Date and Time

Data Type (See Data and Time Data Types section of the Canadian CDA Implementation

Guide).

7.3.4.1 ClinicalDocument/effectiveTime example

<effectiveTime value="20080519171504+0500"/>


7.3.5 inFulfillmentOf

One or more inFullfillmentOf elements SHOULD be present. They represent the Placer Order

that was fulfilled by the imaging procedure(s) covered by this report document.

7.3.5.1 inFullfillmentOf/order/ids

To capture both the referral id and the examination id associated with the order two

inFullfillmentOf/order/ids SHALL be used. Examination id is mapped to the DICOM Accession

Number from the imaging data and the OID should be used to distinguish the two. The referral

id is typically assigned by an electronic medical record system.

7.3.5.2 Priority Code

The priority of the referral SHOULD be optionally communicated within the priorityCode

element.

7.3.5.3 inFulfillmentOf Example

<inFulfillmentOf>

<order>

<! Accession number = root="2.16.840.1.113883.19.4.27" >

<id extension="10523475" root="2.16.840.1.113883.19.4.27"/>


<priorityCode code=”N” codeSystem=”1.2.208.177.1.0.1.4” displayName=”Normal”/>

</order>

</inFulfillmentOf>

7.3.6 documentationOf/ServiceEvent

A serviceEvent represents the main act, such as a radiology study, being documented. Each

documentationOf/ServiceEvent indicates an imaging procedure that the provider describes and

interprets in the content of the Diagnostic Imaging Report. The main activity being described by

this document is the interpretation of the imaging procedure. This is shown by setting the value

of the @classCode attribute of the serviceEvent element to ACT, and the start date and time is

provided in the effectiveTime element. Within each documentationOf element, there is one

serviceEvent element. This event is the unit imaging procedure corresponding to a billable item.

The type of imaging procedure may be further described in the serviceEvent/code element.

7.3.6.1 documentationOf/serviceEvent/code

The documentationOf/serviceEvent/code element SHOULD contain the examination codes of

the imaging procedure documented. In the case of a diagnostic imaging report based on a

DICOM imaging study, the examination code may be present in the Performed Procedure Code

Sequence (0040, A372).


This element may be multi-valued and should contain the local procedure code and a name for

the local procedure coding scheme name. As a multi-valued field, it may also contain the

normalized SNOMED CT code, if known, at the creation time of the document.

7.3.6.2 documentationOf/serviceEvent/id

The documentationOf/serviceEvent/id element SHALL contain the Study Instance UID (DICOM

attribute 0020,000D) of the imaging procedure documented, if known.

7.3.6.3 documentationOf/serviceEvent/effectiveTime

The documentationOf/serviceEvent/effectiveTime element SHOULD contain the examination

date and time of the imaging procedure being documented, if known, and may be mapped from

DICOM attribute Study Date (0008,0020) and Study Time (0008,0030).

If the imaging procedure crosses a date boundary or spans multiple days (e.g., a NM time-

elapsed study), the initial start time of the first component of the imaging procedure should be

used as the serviceEvent/effectiveTime value.

7.3.6.4 documentationOf/serviceEvent/ Performer

A documentationOf/serviceEvent SHOULD contain at least one Physician Reading Study

Performer (templateId 2.16.840.1.113883.10.20.6.2.1) listing the persons performing the

procedure(s) being reported, if known. This is sometimes referred to as “Interpreting

Radiologist.”

The Physician Reading Study Performer entry SHALL be using templateid

2.16.840.1.113883.10.20.6.2.1. The Physician Reading Study Performer SHALL be

represented with a performer element where typeCode is PRF.

The specific type of performer MAY be described in performer/assignedEntity/code.

A assignedEntity/code element SHALL be present and SHALL contain a valid DICOM personal

identification code sequence (codeSystem is 1.2.840.10008.2.16.4) or an appropriate national

health care provider coding system (e.g., SNOMED CT in Canada).

Every assignedEntity element SHALL have at least one assignedPerson or

representedOrganization.

7.3.6.5 DocumentationOf ACT Example

<documentationOf>

<serviceEvent classCode="ACT">

<id root="1.2.840.113619.2.62.994044785528.114289542805"/>






<effectiveTime value="20060823222400"/>

<!—Interpreting Radiologist/Performer -- >

<performer typeCode="PRF">

<templateId root="2.16.840.1.113883.10.20.6.2.1"/>

<assignedEntity>

<id extension="121008" root="2.16.840.1.113883.19.5"/>

<code code="1234" codeSystem= “2.16.840.1.113883.6.96” codeSystemName=”SNOMED

CT” displayName="Diagnostic Radiology"/>

<addr nullFlavor="NI"/>

<telecom nullFlavor="NI"/>

<assignedPerson>

<name>

<given>Christine</given>

<family>Cure</family>

<suffix>MD</suffix>

</name>

</assignedPerson>

</assignedEntity>

</performer>

</serviceEvent>

</documentationOf>

7.3.6.6 documentationOf Anatomic Region

Additional sections of the documentationOf SHOULD be used to describe the detailed

anatomical region / body part affected by the examination templateId

root="1.2.208.177.1.0.3.4"). Anatomic Region is defined in DICOM CID4 and is DICOM Attribute

sequence (0008,0104). (Note: This element should contain the detailed anatomic region as

opposed to the coarse anatomic region.)

7.3.6.7 documentationOf Anatomic Region Example

<documentationOf>

<templateId root="1.2.208.177.1.0.3.4"/> <serviceEvent>

<code code="T-AB000" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DICOM"

displayName="Ear"/>

</serviceEvent>

</documentationOf>


7.3.6.8 Documentation of Modality

Additional sections of documentationOf SHOULD be used to describe the clinical modality (e.g.,

CT, MR, CR, US, etc.) used in the examination (templateId root="1.2.208.177.1.0.3.3").

Modality is defined in DICOM CID29 “Acquisition Modality”. This element is commonly found in

DICOM Attribute (0008,0060). (Note: DICOM Modality Attribute (0008,0060) may also contain

non-clinical modality values such as “SR”, “MX”, etc.).

7.3.6.9 documentationOf Modality Example

<documentationOf>

<templateId root="1.2.208.177.1.0.3.3"/>

<serviceEvent>

<code code="DX" codeSystem="1.2.840.10008.2.16.4" displayName="Digital

Radiography"/>

</serviceEvent>

</documentationOf>

7.4 Diagnostic Imaging (DI) Report Body

In a CDA-document the body makes up the human-readable text of the document. All sections

of the body are coded with LOINC-codes derived from the CDA release 2 for imaging set of

sections codes.

7.4.1 Discussion on Addendums, Document Deprecation, and Documents created in Error

Addendums (as a differential document) shall not be used in the creation of CDA documents.

Rather a new instance of a CDA report will be created with the complete report content including

the addendum. The previous CDA DI Report document prior to the addendum will be

deprecated.

The “Addendum” section of the Consolidated CDA Header SHALL NOT be used.

There are also instances in the real-world where reports are created in error and, for example,

assigned to the incorrect local Patient ID. In this case, the incorrect DI report should be

deprecated and a new DI report created which succinctly states “The previous report was

deprecated because….” For example, “The previous report was deprecated because the

incorrect Patient ID was assigned.” Please also see section 5.1.4.6.

We further recommend that any change to a document constitute a new document and follows

the XDS deprecation workflow as outlined in this implementation guide.


Table 7-2 Diagnostic Imaging Report Body

Template Name Canada Health Infoway Diagnostic Imaging Report Body

Template ID <oid> none currently defined

Parent Template N/A

Header Element N/A

General Description A Diagnostic Imaging report body specification of the pan-Canadian healthcare report.

Opt and Card



C(R[1..1] if DICOM)

DICOM Object Catalog

7.4.2 DICOM Code 121181

O[0..1] History 7.4.3

DICOM Code 12160

LOINC Code 11329-0 History general Narrative – Reported

O[0..1] Current Procedure Description

7.4.4

DICOM Code 121064

LOINC Code 55111-9 Current imaging procedure descriptions

Document


Opt and Card



O[0..1] Indications for Procedure (Reason for Study)

7.4.5

DICOM Code 121109

LOINC Code 18785-6 Radiology Reason for study (narrative)

R[1..1] Findings (Report Text) 7.4.6

DICOM Code 121070

LOINC Code 18782-3 Radiology Study observation (narrative)

O[0..1] Key Images 7.4.7

DICOM Code 121180

LOINC Code 55113-5 Key images Document Radiology

O[0..1]

Complications 7.4.8

DICOM 121113

LOINC Code 55109-3 Complications Document

O[0..1] Impressions 7.4.9

DICOM 121072

LOINC 19005-8 Radiology Imaging study (narrative)

O[0..1] Report status 7.4.10 HL7 Table 0123

Preliminary, Final, Correction

A Diagnostic Imaging Report SHALL have a structuredBody element. The content of this element makes up the human-readable text of the document. The order of the sections in the DI Report SHALL be the same as in the imaging set of sections. To be human-readable all sections SHALL contain a title and a text section. The exception is DICOM Object Catalog as this option section is not intended to be human-readable. Note that the “Impressions” section shall be used rather than “Conclusions” or “Summary” sections.

7.4.2 DICOM Object Catalog Section

The DI Report SHALL have a DICOM Object Catalog section, if it exists. It is at the discretion of

the reporting application to include the level of detail on the imaging study. For example it

makes little sense to include all SOP instances for a large CT study. Including WADO

references is always preferred (e.g. for Key Images).

7.4.2.1 Study

One or more entry elements SHALL be present, each containing a Study Act (templateId

2.16.840.1.113883.10.20.6.2.6).

<code code="113014" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="DICOM Study"/> The study can also have an effectiveTime using the element effectiveTime@value noting the

time the study took place.

7.4.2.2 Series

Each Study Act in turn contains Series associated with it (code="113015")

<code code="113015" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM"

displayName="DICOM Series">

7.4.2.3 Modality

On the series level the code for the modality used is described within the codeSystem

1.2.840.10008.2.16.4, DCM.

<value code="DX" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM"

displayName="Digital Radiography">

7.4.2.4 SOP Instance

Each series SHALL contain one or more SOP Instances.

7.4.2.5 Example <section classCode="DOCSECT" moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.6.1.1"/>


displayName="DICOM Object Catalog"/>

<entry>



<act classCode="ACT" moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.6.2.6"/>

<id root="1.2.840.113619.2.62.994044785528.114289542805"/>


displayName="Study"/>

<entryRelationship typeCode="COMP"> <act classCode="ACT" moodCode="EVN">

<id root="1.2.840.113619.2.62.994044785528.20060823223142485051"/>


displayName="Series">

<qualifier>

<name code="121139" codeSystem="1.2.840.10008.2.16.4"

codeSystemName="DCM" displayName="Modality">

</name>

<value code="CR" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM"

displayName="Computed Radiography">

</value>

</qualifier>

</code>





<entryRelationship typeCode="COMP">

<observation classCode="DGIMG" moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.6.2.8"/>

<id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.3"/>

<code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1"

codeSystemName="DCMUID" displayName="Computed Radiography Image Storage">

</code>

<text mediaType="application/dicom">

<reference

value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619

.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.200

60823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.2006082

32232322.3&contentType=application/dicom"/>

 </text>

</observation>

</entryRelationship>

<entryRelationship typeCode="COMP">

<observation classCode="DGIMG" moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.6.2.8"/>

<id root="1.2.840.113619.2.62.994044785528.20060823.200608232231422.3"/>

<code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1"

codeSystemName="DCMUID" displayName="Computed Radiography Image Storage">

</code>

<text mediaType="application/dicom">

<reference

value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.6

2.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.200608

23223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.2006082322

31422.3&contentType=application/dicom"/>



</text>


</observation>


</act>


</act>

</entry>

</section>

7.4.3 History

The History section SHOULD describe all aspects of medical history of the patient pertinent to the current procedure,

7.4.4 Current Procedure Descriptions

The Current Procedure Descriptions section SHOULD be represented by local procedure code

descriptions.

7.4.5 Indications for Procedure

The Indication for Procedure SHOULD be used to describe the reason of the study.


7.4.6 Findings

The Findings being reported make up the main narrative body of the report.

The DI Report SHALL have a Findings section and the templateId for the Findings section

SHALL be 2.16.840.1.113883.10.20.6.1.2.

If no finding is present in the report from Document Source the text section SHALL read ”No

findings reported”.

7.4.6.1 Example

<section>

<templateId root="2.16.840.1.113883.10.20.6.1.2"/>


displayName="Findings"/>

<title>Findings</title>

<text>The cardiomediastinum is within normal limits. The trachea is midline. The

previously described opacity at the medial right lung base has cleared. There are no new

infiltrates. There is a new round density at the left hilus, superiorly (diameter about

45mm). A CT scan is recommended for further evaluation. The pleural spaces are clear.

The visualized musculoskeletal structures and the upper abdomen are stable and

unremarkable.</text>

</section>

7.4.7 Key Images

The Key Images section SHOULD list of references to images considered significant. Using

WADO references is preferred.

7.4.8 Complications

The Complications section SHOULD contain information on additional medical problems that

develop following a procedure, diagnostic test or study, treatment, or illness.

7.4.9 Impressions

The Impressions section SHOULD be used to list conclusions and or a summary.

7.4.10 Completion Status

The Completion Status section SHOULD be used to indicate the report status of the DI Report.

The report status SHOULD be communicated with a value based on the HL7 Result Status (HL7

Table 0123) as: P=Preliminary, F=Final or C=Correction to Result.


8 Metadata and Standard Terminology

This section describes the metadata and terminology concepts along with the standards and

validation methods to ensure interoperability with Imaging Documents.

Image Documents: There are two types:

1. Manifest: Encompasses a collection of clinical images 2. Report: Interpretation of a collection of clinical images

The key enabler of the Imaging Information Exchange with the XDS-I architecture is the use of

metadata. Metadata are data that provides information about one or more aspects of the

Imaging documents. IHE defines and specifies a collection of metadata to aid its identity,

discovery, routing, security, provenance, privacy, authenticity and electronic pre-processing.

• Submission sets: collection of imaging documents to reflect a given moment. This moment includes the interpretation of images and other evidence for a diagnostic imaging report.

• Associations: supports the association relationship between documents. The associations supported are: append, replace, transform, transform with replace, and signs. Append, replace, and transform associations support lifecycle events, where a document is associated with documents which are created as part of lifecycle events related to the original document.

External Resources:

IHE XDS Metadata Content Specifications

ebXML Registry Information Model

Optionality definition:

R – Required RC – Required if condition met R2 – Required if known O - Optional

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Vol3.pdf

https://www.oasis-open.org/committees/regrep/documents/2.0/specs/ebrim.pdf

XDS-I metadata Manifest Report Option

-ality DICOM Imaging Content

XDSDocumentEntry

Author

Author-Institution (hospital/clinic where the author is employed)

Institution Name (XON) At a minimum, XON Component 1 (Organization Name) shall be present.

Institution Name (XON) At a minimum, XON Component 1 (Organization Name) shall be present.

R2/R2

Institution Name (0008,0080)

Note: The Author-Institution sub-attribute of Author follows the HL7 v2.5 Extended Organization Name (XON) data type as restricted by the IHE XDS Profile. Here is an excerpt from IHT ITI TF-3 pertaining to the use of this data type in the XDS profile: “ This type provides the name and identification of an organization. This specification restricts the coding to the following fields:

XON.1 – Organization Name – this field is required

XON.6.2 – Assigning Authority Universal Id – this field is required if XON.10 is valued and not an OID

XON.6.3 – Assigning Authority Universal Id Type – this field is required if XON.10 is valued and not an OID and shall have the value

“ISO”

XON.10 – Organization Identifier – this field is optional

No other fields shall be specified. The XON data type in XDS Metadata results in a valid encoding of an HL7 V2.5 XON encoding, with the exception of length limitations. Component length restrictions are unobserved; however, the total length including delimiters shall not exceed the limit of the ebXML Slot Value. It is common for organizations to be uniquely identified by an OID. In such cases, the Organization Identifier (component 10) may contain the organization’s OID. If the Organization Identifier is not an OID, the metadata use assumes that it has been assigned so that the




XDSDocumentEntry

composite ID created by combining components 6 and 10 is a unique identifier for the organization. The XDS affinity domain must ensure that this assumption is correct, through appropriate policies for assigning authorities. Examples: Some Hospital Some Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45 Some Hospital^^^^^&1.2.3.4.5.6.7.8.9.1789&ISO^^^^45 ” An affinity domain must ensure that all its institutions can be uniquely identified using the XON-based scheme described above.

Author-Person Is used to include authors as well as parties who had indirect contribution to or are interested in the document (e.g., Referring Physician, Ordering Physician)

Operator Name (XCN) [ Referring Physician ] At a minimum, the XCN Components 2 and 3 (Family and Given Name) shall be populated.

Radiologist Name (XCN) [ Referring Physician ] At a minimum, the XCN Components 2 and 3 (Family and Given Name) shall be populated.

R2/R2

Modality Operator (0008,1070)

Performing Physician (0008,1050)

Physician Approving Interpretation (4008,0114)

Note: The Author-Person sub-attribute of Author follows the HL7 v2.5 Extended Person Name (XCN) data type as restricted by the IHE XDS Profile. Here is an excerpt from IHT ITI TF-3 pertaining to the use of this data type in the XDS profile: “ This data type contains, amongst others, Identifier, Last Name, First Name, Second and Further Given Names, Suffix, Prefix, Assigning Authority. All of the HL7 v2.5 fields may be specified as optional components with the following restrictions:

Either name or an identifier shall be present. Inclusion of other components is optional provided the slot value length restrictions

imposed by ebXML3.0, 256 bytes, is not exceeded.

If component 1 (ID Number) is specified, component 9 (Assigning Authority) shall be present if available.

The XDS XCN Component 9 is subject to the same the restrictions as defined for the XDS CX data type component 4. Thus: the




XDSDocumentEntry

first subcomponent shall be empty, the second subcomponent must be an ISO OID (e.g., 1.2.840.113619.6.197), and the third

subcomponent shall read ‘ISO’.

Any empty component shall be treated by the Document Registry as not specified. This is in compliance with HL7 v2.5.

Trailing delimiters are recommended to be trimmed off. Document Registries shall ignore trailing delimiters. This is in compliance

with HL7 v2.5.

An example of person name with ID number using this data type is as follows: 11375^Welby^Marcus^J^Jr.^ MD^Dr^^^&1.2.840.113619.6.197&ISO “ When XDS is used in the Imaging setting, the XDS-I profile further restricts the above Author-Person attribute format to only utilize the first 7 XCN components (see RAD TF-3, 4.68.4.1.2.3.3.3), e.g.: 11375^Welby^Marcus^J^Jr.^ MD^Dr Thus, only the following XCN Data Components shall be used in the XDS-I setting: 1 – Id Number, 2 – Family Name, 3 – Given Name, 4 – Second Name(s), 5 – Suffix, 6 – Prefix, 7 – Degree An affinity domain must ensure that all its possible document authors can be uniquely identified using the XCN-based scheme described above.




XDSDocumentEntry

Author-Role

Supported values: “Technologist” (default) “Radiologist” “Cardiologist”

Supported values: “Radiologist” (default) “Cardiologist”

R2/R2 Modality Operator (0008,1070)

Performing Physician (0008,1050)

Physician Approving Interpretation

(4008,0114)

Note: The Role is a standardized term expressed as a text string and enforced by the XDS Registry. Roles associated with indirect authors – i.e., additional individuals who somehow contributed to the generated manifest or report – may be present as well. The set of roles supported for these indirect authors is as follows: “Orderer” “Referrer” “Admitter” “Attender” The use of indirect authors as well as potential extensions to the set of roles listed above is an implementation decision that needs to consider requirements of a specific project and/or affinity domain.

Author-Specialty

Supported values: “Imaging”

Supported values: “Imaging”

R2/R2

Note: Specialty is a standardized term expressed as a text string and enforced by the XDS Registry.

Author-Telecommunications

Email/Phone# (XON)

Email/Phone# (XON)

O/O




XDSDocumentEntry

Represents the telecommunications address (e.g., email) of the document author, intended to assist with automated routing of other messages intended for the document author.

Only XTN.3 (type of telecommunication address) and XTN.4 (the telecommunication address) shall be used, as per XDS.

Only XTN.3 and XTN.4 shall be used, as per XDS.

Sample value:

^^Internet^[email protected]

Availability Status

As per XDS As per XDS R/R

Class Code (Used to convey the high-level type - not the low level format - of the published document )

Code: 18726-0 Code System: 2.16.840.1.113883.6.1 (LOINC) Display Name: Radiology Studies

Code: 18748-4 Code System: 2.16.840.1.113883.6.1 (LOINC) Display Name: Diagnostic Imaging Report

R/R

Note: The LOINC code 18748-4 for the CDA Radiology Report comes from the pan-Canadian value set and is in line with the recommendations of SCWG2. This code would typically be present also inside the XML element ClinicalDocument/code of the CDA document encapsulating the report. Note that the code value explicitly stipulated in the XDS-I profile (IHE-RAD TF-3, Section 4.68.4.1.2.3.5.1.1) uses a different code, 11528-7, one that has been deprecated in LOINC.

mailto:%5E%5EInternet%[email protected]




XDSDocumentEntry

classCodeDisplayName

The name to be displayed

for communicating to a

human the meaning of the

classCode.

Radiology Studies Diagnostic Imaging Report R/R

Comments

As per Affinity Domain As per Affinity Domain O/O

Confidentiality Codes (Used to convey the level of confidentiality associated with the manifest or report)

Supported codes are: Normal (default) Restricted Very Restricted

Supported codes are: Normal (default) Restricted Very Restricted

R/R Confidentiality Code (0040,1008)

Note: Confidentiality Codes shall be based on the pan-Canadian value set BasicConfidentialityKind as defined by the coding scheme “2.16.840.1.113883.5.25”. The specific codes are: value=N, codingScheme=2.16.840.1.113883.5.25, displayName=Normal value=R, codingScheme=2.16.840.1.113883.5.25, displayName=Restricted value=V, codingScheme=2.16.840.1.113883.5.25, displayName=Very Restricted

Creation Time Creation time of the manifest This time corresponds to when the manifest was created (and not to when the imaging event took

Creation time of the report This time corresponds to when the radiology report was created (and not to when the imaging event took

R/R Instance Creation Date (0008,0012)

Instance Creation Time (0008,0013)




XDSDocumentEntry

place conveyed by Service Start Time)

place conveyed by Service Start Time)

entryUUID As per XDS As per XDS R/R

Event Codes (Used to convey the acquisition modality used and body parts imaged).

Modality codes (may be multiple) are based on DICOM codes for Acquisition Modality. The coding scheme is DCM. The supported set of code values corresponds to the acquisition modalities listed in DICOM PS 3.16, DCMR Context Group CID 29. Body Part codes (may be multiple) will use the Pan-Canadian SNOMED CT-based terminology for anatomic regions. Both coarse and exact body parts (e.g., abdomen and spleen, respectively) may be present. At a minimum, the coarse body part shall be present to facilitate prefetching of priors.

Modality and Body Part similar to Manifest

R/R Modality (0008,0060) Constrained usage for metadata by the acquisition modalities listed in DICOM PS 3.16, DCMR Context Group CID 29.

Body Part Examined (0018,0015) or

Anatomic Region Sequence

(0008,2218), if available




XDSDocumentEntry

The set of supported coarse body parts includes: 1. Abdomen (SCTID 113345001) 2. Cardiovascular (SCTID 113257007) 3. Chest (SCTID 51185008) 4. Cervical Spine (SCTID 122494005) 5. Lower Extremity (SCTID 61685007) 6. Upper Extremity (SCTID 53120007) 7. Head (SCTID 69536005) 8. Lumbar Spine (SCTID 122496007) 9. Neck (SCTID 45048000) 10. Pelvis (SCTID 12921003) 11. Thoracic Spine (SCTID 122495006) 12. Spine (SCTID 280717001) 13. Breast (SCTID 76752008) 14. Anatomical structure (SCTID 91723000) - used for entire body

eventCodeListDisplayName Display names of the

modality and body part

codes.

Display names of the

modality and body part

codes.

R/R Modality (0008,0060)

Body Part Examined (0018,0015)

mapped to CID 4 or Anatomic

Region Sequence (0008,2218)

using CID 4

Accession Number(s)

Fully qualified Accession Number(s) associated with the published imaging manifest. May contain multiple values. Each value shall be encoded as

The XDS document metadata slot referenceIDList shall be used for conveying fully-qualified accession numbers in the following format:

Same as manifest. R/R Accession Number (0008,0050)

Issuer of Accession Number

Sequence (0008,0051)

If issuer is not present in the

DICOM dataset, its value shall be




XDSDocumentEntry

specified by the IHE ITI Change proposal CP-ITI-659.

number^^^issuer^urn:ihe:iti:xds:2013:accession

populated based on configuration.

Format Code (used to identify the low-level format /encoding of the imaging manifest and report)

Code: 1.2.840.10008.5.1.4.1.1.88.59 (DICOM KOS SOP Class UID) Coding Scheme: 1.2.840.10008.2.6.1 (DICOM UID Registry UID Coding Scheme) As per XDS-I, the code corresponds to the DICOM KOS SOP Class UID.

Code: urn:ihe:rad:CDA:ImagingReportStructuredHeadings2013 Coding Scheme: 1.3.6.1.4.1.19376.1.2.3 (XDS Coding Scheme) PDF report format (urn.ihe.rad.PDF) shall not be used as CDA is the preferred encapsulation mechanism for reports.

R/R

formatCodeDisplayName DICOM manifest CDA

Hash As per XDS As per XDS R/R

Healthcare Facility Type Code (used to represent the type of organizational setting where the clinical encounter/ service occurred)

Supported codes: HOSP (for imaging

performed at a hospital) – hospital setting

Supported codes: HOSP

R/R




XDSDocumentEntry

OF – Outpatient facility (for

imaging performed outside hospital) – non hospital setting

OF – Outpatient facility

Note: The pan-Canadian value set ServiceDeliveryLocationRoleType with coding scheme “Service Delivery Location” (2.16.840.1.113883.5.111) shall be used to convey the concept of Healthcare Facility Type. The specific codes are: value=HOSP, codingScheme=2.16.840.1.113883.5.111, displayName=Hospital value=OF, codingScheme=2.16.840.1.113883.5.111, displayName=Outpatient facility

healthcareFacility

TypeCodeDisplay Name

Hospital, Outpatient facility Hospital, Outpatient facility R/R

Home Community Id

As per XDS, XCA As per XDS, XCA R/R

Language Code

Supported values: “eng-CA” “fra-CA”

Supported values: “eng-CA” “fra-CA”

R/R

Legal Authenticator

As per XDS As per XDS O/O

Mime Type

“application/dicom” “text/xml” R/R

Patient Id





XDSDocumentEntry

Practice Setting Code (used to convey the clinical specialty where the act that resulted in the document was performed)

Supported codes: RADDX – radiology setting CVDX – cardiology setting BREAST – breast setting

Supported codes: RADDX – radiology setting CDVX – radiology setting BREAST – breast setting

R/R

Note: The pan-Canadian value set ServiceDeliveryLocationRoleType with coding scheme “Service Delivery Location” (2.16.840.1.113883.5.111) shall be used to convey the concept of Practice Setting. The specific codes are: value= RADDX, codingScheme=2.16.840.1.113883.5.111, displayName= Radiology diagnostics or therapeutics unit value= CVDX, codingScheme=2.16.840.1.113883.5.111, displayName= Cardiovascular diagnostics or therapeutics unit value=BREAST, codingScheme=2.16.840.1.113883.5.111, displayName=Breast clinic

practiceSettingCodeDisplay

Name

Radiology diagnostics or

therapeutics unit

Cardiovascular diagnostics

or therapeutics unit

Breast clinic

Radiology diagnostics or

therapeutics unit

Cardiovascular diagnostics

or therapeutics unit

Breast clinic

R/R

Repository Unique Id


Service Start Time Study Date and Time for the study (same as in the DICOM datasets)

Study Date and Time for the study (same as in the DICOM datasets) If Study Date and Time is

R/R Study Date (0008,0020) Study Time (0008,0030)




XDSDocumentEntry

unknown to the report submitter, then use Procedure Date/Time.

Service Stop Time

Not enforced Not enforced O/O

Size


Source Patient Id Patient identifier in the local RIS/PACS

Patient identifier in the local RIS/PACS

R/R Patient ID (0010,0020)

Issuer of Patient ID(0010,0021)

Source Patient Info Patient demographics from the local RIS/PACS

Patient demographics from the local RIS/PACS

O/O From Patient Demographic Module

Patient’s Name (0010,0010),

Patient’s Birth Date (0010,0030)

Patient’s Sex (0010,0040).

Patient’s Primary Language Code

Sequence (0010,0101)

Patient’s Address (0010,1040)

Patient’s Telephone Numbers

(0010,2154)

Ethnic Group (0010,2160)

Patient's Religious Preference

(0010,21F0)

Note: Typically the source demographics include the following information: the patient first and last name, sex and birth date (PID-5, PID-8, PID-7).




XDSDocumentEntry

Title

Represents the title of the

document. Clinical

documents often do not

have a title, and are

collectively referred to by the

display name of the

classCode

Display name of the

Procedure Code

associated with the

imaging exam (see Type

Code’s display name)

Display name of the

Procedure Code associated

with the imaging exam (see

Type Code’s display name)

O/O

Type Code (used to identify the type of imaging procedure associated with the published manifest and report, e.g., Chest 2 view) An affinity domain shall define a set of procedure codes to be consistently applied to imaging studies that are shared.

Procedure Code Only one code allowed Note: the implication of the above is that a group case will require multiple manifests.

Procedure Code Only one code allowed

R/R Performed Procedure Code

Sequence (0040,A372)

When performed procedure code is

not available, Requested Procedure

Code (0032,1064) may be used

instead.

typeCodeDisplay Name Display name of the

procedure

Display name of the

procedure

R/R Performed Procedure Code

Sequence (0040,A372)

UniqueId SOP Instance UID of the KOS Object

Report identifier; same as the identifier in the CDA R2 header of the report document

R/R SOP Instance UID (0008,0018)




XDSDocumentEntry

URI As per XDS As per XDS O/O

XDS-I metadata Manifest Report Option-

ality DICOM Imaging Content

Private slot

Study Instance UID(s) Encoded in the slot: urn:chi:scwg10:studyInstanceUIDList

Study Instance UIDs of DICOM studies referenced in the manifest May contain multiple values.

O/O

Study Instance UIDs (0020, 000D)

Source procedure code(s) encoded in the slot: urn:chi:scwg10:sourceProcedureCodeList

Source procedure code(s) associated with the imaging exam. The encoding of the procedure code shall be: code^displayName^codingScheme when display name is present, or: code^^codingScheme when display name is not present

Same as manifest. O/O Performed Procedure Code Sequence (0040,A372) When performed procedure code is not available, Requested Procedure may be used instead – see Requested Procedure Code Sequence (0032,1064).


9 Testing Strategy

The proposed Testing strategy is to test the underlying profiles at the IHE Connectathon.

Systems which complete the testing will be elligible for SCWG-10 Use Case testing at a time

following the connectathon.

10 Transition Strategy

This section describes strategy and considerations for the transition path from the current state

to target state: the DIR Affinity Domain implemented and interoperable with the local imaging

systems.

10.1 Foreign Exam Management – DICOM Only Environment

In general, the long term plan for pan-Canadian architecture is in the direction of the IHE Cross Enterprise Document Sharing (XDS/XDS-I) architecture. In the near-term, however, there are many systems which are in a DICOM-only environment. In an attempt to unify the existing systems as much as possible, DICOM-only system architectures are represented in this section, but with the expectation that these systems will migrate towards an XDS architecture and the DICOM-only models shown here will eventually become unnecessary. It should also be noted that not all features can be replicated in a DICOM-only environment (which is why IHE XDS was created).

The set of transaction sequences is a DICOM/HL7 only based environment. It is intended to represent some of the existing installed-base systems. These transactions are meant to illustrate a guideline of best practices and variations will need to be created to match existing system behaviour and capabilities. It should also be noted that some use cases can not be modeled in a DICOM-only environment.

10.1.1 Use Case 1: Basic – Pre-fetching for a new Radiology Order

A patient is scheduled for a radiology study at local Hospital A. A search is made for other related image sets or reports throughout the affinity domain (DIR) and that information is automatically brought, in a useful manner (i.e., may require tag/data morphing), to the local hospital for review. This retrieved information is not archived again locally, but rather eventually migrates off the local system.

Flow:

1. A registered patient is determined to have a need for a radiology study at Hospital A. 2. When the order is created and scheduled at the Department System Scheduled/Order

Filler (DSS/OF), the order is sent from the DSS/OF to the Image Manager (if applicable) and the Foreign Exam Manager (FEM) using the local Hospital A patient id, issuer of assession number, and accession number.


3. The FEM triggers the pre-fetch from a patient arrived (ADT^A10; ADT^A04) message or an order updated (ORM ORC5 = a” arrived) message. –OR- The FEM “holds” the scheduled order until a configurable amount of time prior to the study date.

4. The FEM checks the DIR for other patient IDs for this patient, and, for those alternate patient IDs, checks for additional studies in other locations.

5. If other health information is found, it is checked to be relevant (pre-fetch keys). 6. If reports are found to be relevant, the prior reports are retrieved, if necessary (cannot

just be “viewed on demand”). Based on “destination information” configured for each site, the report format may need to be converted and report tags may need to be morphed, if possible. The report may be sent to the DSS/OF, the Report Manager (RM), both, or neither.

7. If images are found to be relevant, the prior images are retrieved. Based on “destination information” configured for each site, image tags may need to be morphed, and the images are sent (DICOM C-Store) to the IM.

8. After the configured elapsed time, the DSS/OF, RM, and IM migrate the foreign exam from the local storage (deletes reports and image objects).

Note that the exact sequence of steps in the diagrams below is not required (e.g., images could be retrieved before reports.)


Figure: 12 - Use Case 1 Basic DICOM transaction sequences

Note 1: A new patient order message (new ORM), a patient arriving (ADT^A10) message or an updated order (ORM with ORC5 = “a” for arrival) can trigger the pre-fetch scenario demonstrated above. The new ORM messages may be more prevalent, but the significant disadvantage is that new order ORM messages are often sent out when the scheduling occurs. A radiology order may be scheduled days, weeks, or even many months in advance (oncology follow-up, for example). In this case, the FEM actor is required to have a database to maintain scheduled events which will significantly add to the cost and maintenance of such a system. If a patient arriving message is employed or if the ORM can be withheld until the date of the order, the FEM actor may be a transaction-based system which would reduce maintenance. Note 2: Although it is not commonly sent currently, it may also be possible to use the “Issuer of Accession Number” sequence to ensure that no Accession Number collisions occur. “Issuer of Accession Number” is not typically displayed on a user interface, however. Note 3: DICOM Modality Performed Procedure Step (MPPS) and Storage Commit (SC) are also recommended to be used to verify the successful transmission of the image set. The DICOM C-Store Success code also signifies completion, but may be less reliable.

XDS/XDS-I Affinity Domain Implementation Guide

Documents

Transcript of XDS/XDS-I Affinity Domain Implementation Guide