ACC, HIMSS and RSNA
Integrating the Healthcare EnterpriseIHE Cardiology Technical Framework
Year 2: 2005-2006
Volume I
Integration Profiles
Revision 2.1

Final Text Version
Publication Date: June 9, 2006

Copyright © 2004-2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Contents
1 Introduction.............................................................................................................................. 6
1.1 Overview of Technical Framework.................................................................................. 6
1.2 Overview of Volume I...................................................................................................... 6
1.3 Audience........................................................................................................................... 7
1.4 Relationship to Standards ................................................................................................. 7
1.5 Relationship to Real-world Architectures ........................................................................ 7
1.6 Conventions...................................................................................................................... 8
1.6.1 Actor and Transaction Diagrams and Tables.......................................................... 8
1.6.2 Process Flow Diagrams........................................................................................... 8
1.6.3 Normative versus informative contents of the Technical Framework.................... 9
1.6.4 Technical Framework Referencing......................................................................... 9
1.6.5 Transaction Referencing ......................................................................................... 9
1.7 IHE Cardiology Current Year Scope.............................................................................. 10
1.8 Comments....................................................................................................................... 10
1.9 Copyright Permission ..................................................................................................... 11
1.10 IHE Technical Framework Development and Maintenance Process ............................. 11
1.10.1 New Development – Extending the Existing Technical Framework.................... 121.10.2 Maintenance of existing Technical Framework content....................................... 13
1.10.3 Use of Technical Framework................................................................................ 14
2 Integration Profiles ................................................................................................................ 15
2.1 Dependencies between Integration Profiles ................................................................... 15
2.2 Integration Profiles Overview ........................................................................................ 17
2.2.1 Cardiac Catheterization Workflow (CATH)......................................................... 17
2.2.2 Echocardiography Workflow (ECHO) ................................................................. 18
2.2.3 Retrieve ECG for Display (ECG) ......................................................................... 18
2.2.4 Displayable Reports (DRPT) ................................................................................ 18
2.2.5 Evidence Documents (ED) ................................................................................... 18
2.3 Actor Descriptions.......................................................................................................... 19
2.4 Transaction Descriptions ................................................................................................ 20
2.5 Product Implementations................................................................................................ 23
3 Cardiac Catheterization Workflow (CATH) ......................................................................... 25
3.1 Actors/Transactions ........................................................................................................ 26
3.2 Cath Workflow Integration Profile Options ................................................................... 28
3.3 Cath Scheduled Process Flow ........................................................................................ 28
3.4 Cath Workflow Use Cases.............................................................................................. 32
3.4.1 Case C1: Patient Registered at ADT and Procedure Ordered at the Order Placer 34
3.4.2 Case C2: Patient Registered at ADT and Procedure Ordered at DSS/OF ............ 36
3.4.3 Case C3: Patient Registered at ADT and Procedure Not Ordered........................ 37
3.4.4 Case C4: Patient Registered at DSS/OF and Procedure Ordered ......................... 39
3.4.5 Case C5: Patient Not Registered........................................................................... 40
3.4.6 Case C6: Patient Updated During Procedure........................................................ 43__________________________________________________________________________
1
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
3.4.7 Case C7: Change Rooms During Procedure......................................................... 44
3.4.8 Case C8: Cancel Procedure................................................................................... 46
3.4.9 Case C9: Post-procedure evidence creation.......................................................... 47
3.4.10 Case C10: EP Ablation / Implantation Lab.......................................................... 49
4 Echocardiography Workflow (ECHO) .................................................................................. 51
4.1 Actors/Transactions ........................................................................................................ 52
4.2 Echocardiography Workflow Integration Profile Options ............................................. 54
4.3 Echocardiography Workflow Process Flow ................................................................... 54
4.3.1 Case E1: Patient Registered at ADT and Procedure Ordered............................... 56
4.3.2 Case E2: Intermittently Connected Modality ...................................................... 58
4.3.3 Case E3: Intermittently Connected Modality with Ad Hoc Procedure, Patient
Registered, Scheduled Procedure.......................................................................... 59
4.3.4 Case E4: Intermittently Connected Modality with Ad Hoc Procedure, Patient
Registered, Unscheduled Procedure ..................................................................... 61
4.3.5 Case E5: Intermittently Connected Modality with Ad Hoc Procedure, Patient
Unregistered, Unscheduled Procedure.................................................................. 62
4.3.6 Case E6: Stress Echo Staged Protocol ................................................................. 64
4.3.7 Case E7: Echo measurement evidence creation.................................................... 65
5 Retrieve ECG for Display (ECG) .......................................................................................... 68
5.1 Actors/Transactions ........................................................................................................ 68
5.2 ECG Integration Profile Options .................................................................................... 69
5.3 ECG Integration Profile Process Flow ........................................................................... 69
5.3.1 Case D1: Simple Display ...................................................................................... 69
5.3.2 Case D2: Advanced Display ................................................................................. 71
6 Displayable Reports (DRPT)................................................................................................ 73
7 Evidence Documents (ED) .................................................................................................... 74
7.1 Actors/Transactions ........................................................................................................ 74
7.2 Evidence Documents Profile – Cardiology Options ...................................................... 75
7.3 Evidence Documents Process Flow................................................................................ 75
Appendix A:
The Cardiac Catheterization Procedure in Perspective ............................... 76
Appendix B:
Challenges of Workflow Management in Cardiac Catheterization ............ 77
B.1 Clinical Context: Diagnostic and Interventional Procedures ......................................... 77
B.2 Organizing the Workflow: Requested Procedures and Procedure Steps........................ 77
B.2.1 Orders.................................................................................................................... 78
B.2.2 Requested Procedures ........................................................................................... 78
B.2.3 Scheduled and Performed Procedure Steps .......................................................... 78
B.2.4 Clinical Protocols and Procedure Step Protocols.................................................. 79
B.3 Multi-Modality and Ad Hoc Scheduling ........................................................................ 80
B.3.1 Unscheduled Case................................................................................................. 81
B.4 Modality Procedure Step Complete/Discontinue ........................................................... 82
B.5 Start and End Procedures................................................................................................ 82
B.6 Grouped Procedures ....................................................................................................... 83
B.6.1 What are Grouped Procedures? ............................................................................ 83__________________________________________________________________________
2
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
B.6.2 Why Grouped Case is a Problem with Multimodality Studies ............................. 84
B.7 The Approach Adopted by IHE Cardiology................................................................... 84
Appendix C:
IHE Integration Statements ......................................................................... 86
C.1 Structure and Content of an IHE Integration Statement................................................. 86
C.2 Format of an IHE Integration Statement ........................................................................ 87
Appendix D:
GLOSSARY................................................................................................ 89
Appendix E:
Security Environment Considerations......................................................... 92
Appendix F:
Displayable Report Distribution Using the DRPT, RID and XDS Profiles 94
Appendix G:
Displayable Report Signing ........................................................................ 94
Appendix H:
Cardiology Summary of Relevant Profiles from Other Domains ............... 95
H.1 Consistent Time (CT) ..................................................................................................... 95
H.1.1 CT Actors.............................................................................................................. 95
H.1.2 CT Transactions .................................................................................................... 96
H.1.3 Cardiology Use Cases ........................................................................................... 96
H.2 Scheduled Workflow (SWF) and Patient Information Reconciliation (PIR)................. 96
H.2.1 Cardiology Use Case for SWF and PIR................................................................ 96
H.3 Retrieve Information for Display (RID)......................................................................... 97
H.3.1 RID Process Flow ................................................................................................. 97
H.3.2 Cardiology Use Cases ........................................................................................... 97
H.4 Cross-Enterprise Document Sharing (XDS) .................................................................. 98
H.4.1 XDS Process Flow ................................................................................................ 99
H.4.2 Cardiology Use Cases ......................................................................................... 100
H.4.3 XDS Content Profiles ......................................................................................... 101
H.4.3.1 XDS-MS Medical Summary............................................................................... 101
H.4.3.2 XDS-I Imaging.................................................................................................... 101__________________________________________________________________________
3
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Foreword
Integrating the Healthcare Enterprise (IHE) is an initiative designed to stimulate the integration of
the information systems that support modern healthcare institutions. Its fundamental objective isto ensure that in the care of patients all required information for medical decisions is both correct
and available to healthcare professionals. The IHE initiative is both a process and a forum forencouraging integration efforts. It defines a technical framework for the implementation of
established messaging standards to achieve specific clinical goals. It includes a rigorous testingprocess for the implementation of this framework. And it organizes educational sessions andexhibits at major meetings of medical professionals to demonstrate the benefits of this frameworkand encourage its adoption by industry and users.
The approach employed in the IHE initiative is not to define new integration standards, but rather
to support the use of existing standards, HL7, DICOM, IETF, and others, as appropriate in theirrespective domains in an integrated manner, defining configuration choices when necessary.
When clarifications or extensions to existing standards are necessary, IHE refers
recommendations to the relevant standards bodies.
This initiative has numerous sponsors and supporting organizations in different medical specialty
domains and geographical regions. In North America the primary sponsors are the American
College of Cardiology (ACC), the Healthcare Information and Management Systems Society(HIMSS) and the Radiological Society of North America (RSNA). IHE Canada has also been
formed. IHE Europe (IHE-EUR) is supported by a large coalition of organizations including theEuropean Society of Cardiology (ESC), European Association of Radiology (EAR) and European
Congress of Radiologists (ECR), the Coordination Committee of the Radiological andElectromedical Industries (COCIR), Deutsche Röntgengesellschaft (DRG), the EuroPACS
Association, Groupement pour la Modernisation du Système d'Information Hospitalier (GMSIH),
Société Française de Radiologie (SFR), and Società Italiana di Radiologia Medica (SIRM). In
Japan IHE-J is sponsored by the Ministry of Economy, Trade, and Industry (METI); the Ministryof Health, Labor, and Welfare; and MEDIS-DC; cooperating organizations include the Japan
Industries Association of Radiological Systems (JIRA), the Japan Association of Healthcare
Information Systems Industry (JAHIS), Radiological Society (JRS), Japan Society ofRadiological Technology (JSRT), and the Japan Association of Medical Informatics (JAMI).
Other organizations representing healthcare professionals are invited to join in the expansion of
the IHE process across disciplinary and geographic boundaries.
The IHE Technical Frameworks for the various domains (IT Infrastructure, Cardiology,
Laboratory, Radiology, etc.) define specific implementations of established standards to achieve
integration goals that promote appropriate sharing of medical information to support optimal
patient care. They are expanded annually, after a period of public review, and maintained
regularly through the identification and correction of errors. The current version for theseTechnical Frameworks may be found at www.ihe.net .
__________________________________________________________________________
4
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________The IHE Technical Frameworks identify a subset of the functional components of the healthcare
enterprise, called IHE Actors, and specify their interactions in terms of a set of coordinated,
standards-based transactions. They describe this body of transactions in progressively greater
depth. This volume I provides a high-level view of IHE functionality, showing the transactionsorganized into functional units called Integration Profiles that highlight their capacity to address
specific clinical needs. The subsequent volumes provide detailed technical descriptions of each
IHE transaction.

__________________________________________________________________________
5
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

1 Introduction
1.1 Overview of Technical Framework
This document, the IHE Cardiology Technical Framework (IHE CARD-TF), defines specificimplementations of established standards to achieve integration goals for cardiology. Suchintegration promotes appropriate sharing of medical information to support optimal patient care.
The CARD-TF is expanded annually, after a period of public review, and maintained regularly
through the identification and correction of errors. The latest version of the document is always
available via the Internet at www.ihe.net .
The CARD-TF identifies a subset of the functional components of the healthcare enterprise,called IHE actors, and specifies their interactions in terms of a set of coordinated, standards-basedtransactions. It describes this body of transactions in progressively greater depth. The present
Volume I provides a high-level view of IHE functionality, showing the transactions organized
into functional units called Integration Profiles that highlight their capacity to address specificclinical needs. Volume II provides detailed technical descriptions of each cardiology-specific IHE
transaction.
The CARD-TF is part of a related set of IHE Technical Frameworks, comprised of the following
domain-specific documents:• IHE Cardiology Technical Framework• IHE IT Infrastructure Technical Framework• IHE Radiology Technical Framework• IHE Laboratory Technical Framework• IHE Patient Care Coordination Technical Framework
The IHE Cardiology Integration Profiles rely heavily on, and reference, the transactions definedin those other IHE Technical Framework documents. For the conventions on referencing otherframeworks, see Section 1.6.4 within this volume.

1.2 Overview of Volume I
The remainder of section 1 further describes the general nature, purpose and function of theTechnical Framework. Section 2 introduces the concept of IHE Integration Profiles that make up
the Technical Framework.
Section 3 and the subsequent sections of this volume provide detailed documentation on eachIntegration Profile, including the clinical problem it is intended to address and the IHE Actors andTransactions it comprises.
The appendices following the main body of the document provide detailed discussion of specificissues related to the Integration Profiles and a glossary of terms and acronyms used.
__________________________________________________________________________
6
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

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

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

1.5 Relationship to Real-world Architectures
The IHE Actors and transactions described in the IHE Technical Framework are abstractions of
the real-world healthcare information system environment. While some of the transactions are
traditionally performed by specific product categories (e.g. HIS, Electronic Patient Record, RIS,
PACS, Clinical Information Systems or imaging modalities), the IHE Technical Framework__________________________________________________________________________
7
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
intentionally avoids associating functions or actors with such product categories. For each actor,
the IHE Technical Framework defines only those functions associated with integrating
information systems. The IHE definition of an actor should therefore not be taken as the complete
definition of any product that might implement it, nor should the framework itself be taken tocomprehensively describe the architecture of a healthcare information system.
The reason for defining actors and transactions is to provide a basis for defining the interactions
among functional components of the healthcare information system environment. In situations
where a single physical product implements multiple functions, only the interfaces between the
product and external functions in the environment are considered to be significant by the IHE
initiative. Therefore, the IHE initiative takes no position as to the relative merits of an integrated
environment based on a single, all-encompassing information system versus one based on
multiple systems that together achieve the same end. To illustrate most dramatically thepossibilities of the IHE Technical Framework, however, the IHE demonstrations emphasize theintegration of multiple vendors’ systems based on the IHE Technical Framework.

1.6 Conventions
This document has adopted the following conventions for representing the framework concepts
and specifying how the standards upon which the IHE Technical Framework is based should beapplied.
1.6.1 Actor and Transaction Diagrams and Tables
Each integration profile is a representation of a real-world capability that is supported by a set ofactors that interact through transactions. Actors are information systems or components of
information systems that produce, manage, or act on categories of information required byoperational activities in the enterprise. Transactions are interactions between actors that transfer
the required information through standards-based messages.
The tables of Actors and Transactions given in sections 3 – 5 indicate which Transactions each
Actor in a given profile must support.
In some cases, a profile is dependent on a pre-requisite profile in order to function properly andbe useful. For example, Cath Workflow depends on the Consistent Time Profile (from the IHE IT
Infrastructure framework) being implemented as a pre-requisite. These dependencies can befound by locating the desired profile in Table 2-1 and seeing which profiles are listed as required
pre-requisites. An Actor must implement all required transactions in the pre-requisite profiles in
addition to those in the desired profile.
1.6.2 Process Flow Diagrams
The descriptions of Integration Profiles that follow include Process Flow Diagrams that illustrate
how the profile functions as a sequence of transactions between relevant actors.

__________________________________________________________________________
8
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
These diagrams are intended to provide a “big picture” so the transactions can be seen in thecontext of the overall workflow. Certain transactions and activities not defined in detail by IHE
are shown in these diagrams in italics to provide additional context on where the relevant IHE
transactions fit into the broader scheme of healthcare information systems.
These diagrams are not intended to present the only possible scenario. Often other actor
groupings are possible, and complementary transactions from other profiles may be interspersed.
In some cases the sequence of transactions may be flexible. Where this is the case there will
generally be a note pointing out the possibility of variations.
The convention used in these diagrams is that the arrow on the line for the transaction points fromthe initiator of the transaction to the destination.
1.6.3 Normative versus informative contents of the Technical Framework
Most parts of the Technical Framework describe required or optional characteristics of Integration
Profiles, Actors and Transactions: these are normative. For a better understanding of the text,
there also exist illustrating parts in the Technical Framework that are informative and nonnormative.
According to IETF RFC 2119, certain words indicate whether a specific content of the Technical
Framework is normative: either required (e.g. “must”, “required”, “shall”) or optional (e.g.
“may”, “recommended”). Informative content does not contain these key words.
1.6.4 Technical Framework Referencing
When references are made to a section within the same Technical Framework volume, a section
number is used by itself. When references are made to other volumes or to a Technical
Framework in another domain, the following format is used:<domain designator> TF-<volume number>: <section number>, where<domain designator> is a short designator for the IHE domain (ITI = IT Infrastructure, RAD =Radiology, CARD = Cardiology, LAB = Laboratory)<volume number> is the applicable volume within the given Technical Framework (e.g., 1, 2, 3),
and<section number> is the applicable section number.
For example: ITI TF-1: 3.1 refers to section 3.1 in volume 1 of the IHE IT Infrastructure
Technical Framework, RAD TF-3: 4.33 refers to section 4.33 in volume 3 of the IHE Radiology
Technical Framework.
1.6.5 Transaction Referencing
When references are made to a Transaction, the following format is used:<domain designator>-<transaction number>, where__________________________________________________________________________
9
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________<domain designator> is a short designator for the IHE domain (ITI = IT Infrastructure, RAD =Radiology, CARD = Cardiology, LAB = Laboratory)<transaction number> is the applicable transaction number as specified in the Technical
Framework for that domain.
Transactions may also be referenced by name, but only after that transaction name has been
identified with its domain and transaction number within that section of the document.

1.7 IHE Cardiology Current Year Scope
This document defines the final scope of Year 2 of the IHE Cardiology initiative. It was the basis
for the testing and exhibition process associated with the ACC, ASE, ESC and HIMSS 2006
annual meetings. The current IHE Cardiology Technical Framework addresses the following
primary features:• The Cardiac Catheterization Workflow Integration Profile describes mechanisms to manage
and distribute the workflow within the cardiology department catheterization labs across theseveral types of equipment in a synchronized manner, including production of procedure logs
and measurements such as quantitative coronography or ventriculography.
• The Echocardiography Workflow Integration Profile describes mechanisms to manage anddistribute the workflow within the cardiology department echocardiography function,
including stress echo and measurements.
• The Retrieve ECG for Display Integration Profile describes interoperable ways for ECG
waveforms and analyses to be retrieved and presented by display systems both inside andoutside the cardiology department.
• The Evidence Documents Integration Profile, included by reference to its definition in theRadiology Technical Framework with further cardiology-specific options, describes
management of observations, measurements, and peri-procedural results (i.e., evidence
documents).

1.8 Comments
The ACC welcomes comments on this document and the IHE initiative. They should be directedto the discussion server at http://forums.rsna.org/ or to:Katherine Doermann
American College of Cardiology
9111 Old Georgetown Rd
Bethesda, Md 20814-1699
Email: IHE@acc.org__________________________________________________________________________
10
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

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

1.10 IHE Technical Framework Development and Maintenance
Process
The Technical Framework is continuously extended and maintained by the IHE Cardiology
Technical Committee, in cooperation with the other domain-specific Technical Committees. The
Development and Maintenance Process of the Framework follows a number of principles toensure stability of the specification both vendors and users may rely upon in specifying,developing and acquiring IHE compatible products.
The process is intended to address the need for extensions, clarifications and corrections while
maintaining backward compatibility of framework definitions as to support implementations
claiming conformance to any previously defined Integration Profile and its Actors.
To maintain stability of the IHE Technical Framework, modifications occur in a regular annual
cycle (Figure 1.10-1) according to one of two controlled paths: new development, andmaintenance.

__________________________________________________________________________
11
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________New
Development

Publish for
Public Comment

Publish for
Trial Implementation

Publish as
Final Text

Publishnext version
Existing Technical
Framework fromprevious annual cycle

Propose & Draft
New Supplement

Supplement
PC

Final Text
Supplement

Supplement
TI

Public Comments
considered& Supplement updated
Issues raised inprevious version ofTechnical Framework

Change Proposal
submitted& accepted

Change Proposal
submitted& accepted

Final Text
ChangeProposal

Final Text
ChangeProposalTechnical
Framework(next version)

Continue as requiredin the next annual cycle

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

1.10.1 New Development – Extending the Existing Technical Framework
Each year, new functionality to be developed is identified by the IHE Cardiology Planning
Committee. The Technical Committee performs the necessary analysis and design work andgenerates new text for the Technical Framework.
Generally, new functionality is published in the form of a Supplement. The scope of a
Supplement is to make one of the following additions to the Technical Framework:• A new Integration Profile, usually including the introduction of new Actors and Transactions.
• New Actors in an existing Integration Profile: These may be either Actors previously definedelsewhere in the Technical Framework, or new ones not yet defined. Transactions identifying
the new actors responsibilities in this profile are identified or defined and may be designatedas required or optional. To avoid causing compatibility problems for systems that havealready implemented that profile, no new required Transactions are added for existing Actors
in the profile.
• New Options in an existing Integration Profile: These usually add optional Transactions forexisting actors in the profiles, or add optional features within existing Transactions.
• Major conceptual changes: They do not change the behavior of existing Integration Profiles
but may imply changes or additions to Actors or Transactions in the future.
__________________________________________________________________________
12
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________The publication process consists of certain phases and is clearly indicated on each document.
First, the text is published for Public Comment (with a “PC” designation). During the Public
Comment period (typically 30 days), the text and a comment submission facility are available on
the IHE Website. Following this period, the Technical Committee will review the comments.
Updated text of Supplements is then published for Trial Implementation (with a “TI”
designation), based on the modifications resulting from the comments received.
IHE provides a process for vendors to test their implementation of the Trial Implementation
specifications of IHE Actors and Integration Profiles. The IHE testing process, culminating in a
multi-party interactive testing event called the Connect-a-thon, provides vendors with valuable
feedback and provides a baseline indication of the conformance of their implementations. It also
serves as a validation of the technical approach of the Trial Implementation specifications.
After trial implementations have been judged to have sufficiently exercised the new functionality(e.g., due to experience from the Connect-a-thon), and the text is considered sufficiently stable,
the new text will be published as Final Text (with a “FT” designation).
Final Text Supplements will be merged at the end of the annual development cycle with thecurrent version of the Technical Framework resulting in a new version of the Technical
Framework with an increased version number.
1.10.2 Maintenance of existing Technical Framework content
Despite the best efforts of the Technical Committee, a published current version of the Technical
Framework or Trial Implementation documents may contain text that is incorrect, incomplete or
unclear. Such issues are handled as Change Proposals and cover:• Corrections: technical issues causing non-interoperability of implementations are fixed
without introducing changes in functionality of a stable Integration Profile.
• Clarifications: text that can be misunderstood or is ambiguous is made easier to understand or
disambiguated, without introducing any technical changes.
The publication process is the same for both Corrections and Clarifications, and addresses bothchanges to Trial Implementations and changes to a current version of the Technical Framework.
A Submitted Change Proposal results from issues raised by users, vendors or TechnicalCommittee members, e.g. from experiences with Trial Implementation or Final Text Integration
Profiles or at a Connect-a-thon. The resulting Change Proposal document should explicitly state:• the parts of the Technical Framework requested to be changed,• a problem description,• a rationale why the change is considered necessary,• and a solution or approach to the problem.
The Technical Committee regularly considers Change Proposals which are then either accepted or
rejected.
__________________________________________________________________________
13
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________A Rejected Change Proposal is published with a rationale from the Technical Committee
explaining why the change is not appropriate.
An Accepted Change Proposal is assigned to a member of the Technical Committee as a work
item for further investigation with the goal to produce adequate clarifications or corrections. The
resulting text will again be reviewed by the Technical Committee before being approved.
Once approved, a Final Text Change Proposal is published by the Technical Committee, andthen is to be considered as effective. It will be merged into the next version of the Technical
Framework at the end of the annual development cycle. Submitting a Change Proposal to a Final
Text Change Proposal or a Final Text Supplement is not possible.
1.10.3 Use of Technical Framework
The current version of the Technical Framework is considered the primary reference document.
Final Text Supplements and Final Text Change Proposals from the current annual cycle
complement this document. Past Final Text documents are retained to provide convenientsummaries of differences to prior versions of the Technical Framework or Trial Implementation
versions of Supplements.
During the annual development and maintenance cycle, it is recommended to use Technical
Framework documents for implementations as follows:• Product Implementations
Products implemented based on Trial Implementation text are expected to review thesubsequent Final Text and update their products as necessary. Further, it is expected thatvendors will monitor Final Text Change Proposals and make any corrections relevant to theirproduct in a timely fashion.
• Connect-a-thon Implementations
Testing at the Connect-a-thon will be based on the current version of the Technical
Framework for the appropriate IHE Domain, plus any relevant Supplements for Trial
Implementation and Final Text Change Proposals.

__________________________________________________________________________
14
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

2 Integration Profiles
IHE Cardiology Integration Profiles, depicted in Figure 2-1, offer a common language that
healthcare professionals and vendors may use in communicating requirements for the integrationof products. Integration Profiles describe real-world scenarios or specific sets of capabilities ofintegrated systems. An Integration Profile applies to a specified set of actors and for each actor
specifies the transactions necessary to support those capabilities.
Integration Profiles provide a convenient way for both users and vendors to reference a subset ofthe functionality detailed in the IHE Technical Framework. They enable users and vendors to be
more specific than simply requesting or promising overall IHE support, without laborious
restatement of the details regarding IHE actors and transactions defined by the IHE Technical
Framework.

2.1 Dependencies between Integration Profiles
In general, IHE Integration Profiles do not operate independently. Objects that serve as useful
input to one profile may have been produced as a result of implementing another profile.
Figure 2-1 provides a graphical view of the dependencies between Integration Profiles. The
arrows in the diagram point from the dependent profile to the profile(s) on which it relies. The
solid arrow indicates an implementation dependency – the actors of the dependent profile must
implement the supporting profile. The open arrows indicate a definitional dependency – thetransactions of the dependent profile are based on the transactions of the supporting profile; this isfor information purposes only, since the supporting profile is not itself used, only some subset ofit.
Note especially that the supporting profiles come from other IHE domains.

__________________________________________________________________________
15
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Cath Workflow

Echo Workflow

Retrieve ECG
for Display

Manage multi modality
synchronized procedurefrom admission to lab discharge
including unidentified patientsManage echocardiography
workflow, including stressDistribute ECGs, including
waveforms, measurements,
and interpretation, forenterprise-wide display

Evidence
Documents

Consistent TimeCreate, store, manage,
retrieve & use objects torecord study evidence(IHE Radiology)

Synchronized clocks on all
equipment(IHE IT Infrastructure)

Scheduled Workflow
Admit, order, schedule, worklist, status;
create, manage, store, display images(IHE Radiology)

Retrieve Infofor Display

Distribute documents forenterprise-wide display(IHE IT Infrastructure)

Patient Info
Reconciliation

Unidentified patients, update andmerge demographics(IHE Radiology)

Cross-Enterprise
Document Sharing

Distribute documents
across enterprise boundaries(IHE IT Infrastructure)

Figure 2-1. IHE Cardiology Integration Profiles and Dependencies

Table 2-1 defines the required dependencies between the Integration Profiles in a tabular form.
There are of course other useful synergies that occur when different combinations of profiles are
implemented, but those are not described in the table below. For instance, actors of the various
Cardiology profiles may implement profiles of the IT Infrastructure domain for user or node
authentication, audit trails, patient identifier cross-referencing, etc.
Table 2-1. Cardiology Integration Profiles Dependencies
Integration Profile
Cath Workflow

Depends on

Dependency TypeITI-TF Consistent TimeThe DSS/Order Filler andall Acquisition Modality
actors are required to begrouped with Time Client
actor

RAD-TF Scheduled Workflow

Comments

Definitional

RAD-TF Patient Information
Reconciliation
Echo Workflow

RAD-TF Scheduled Workflow

Definitional

RAD-TF Patient Information
Reconciliation
Retrieve ECG for Display

ITI-TF Retrieve Info for Display

Definitional

Vendor products support an Integration Profile by implementing the appropriate actortransactions as outlined in the Integration Profile in sections 3 through 5. A product may
implement more than one actor and more than one Integration Profile.
__________________________________________________________________________
16
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
An actor must implement all required transactions in the pre-requisite profiles in addition to thosein the desired profile.
Actors (see section 2.2) are information systems or components of information systems that
produce, manage, or act on information associated with operational activities in the enterprise.
Transactions (see section 2.3) are interactions between actors that transfer the required
information through standards-based messages.

2.2 Integration Profiles Overview
In this document, each IHE Integration Profile is defined by:• The IHE Actors involved• The specific set of IHE Transactions required for each IHE Actor.
These requirements are presented in the form of a table of transactions required for each actor
supporting the Integration Profile. Actors supporting multiple Integration Profiles are required tosupport all the required transactions of each Integration Profile supported. When an Integration
Profile depends upon another Integration Profile, all transactions required for the dependent
Integration Profile have been included in the table.
Note that IHE Integration Profiles are not statements of conformance to standards, and IHE is nota certifying body. Users should continue to request that vendors provide statements of theirconformance to relevant standards, such as DICOM and HL7. Standards conformance is aprerequisite for vendors adopting IHE Integration Profiles.
Also note that there are critical needs for any successful integration project that IHE cannot
address. Successfully integrating systems still requires a project plan that minimizes disruptions
and describes fail-safe strategies, specific and mutually understood performance expectations,well-defined user interface requirements, clearly identified systems limitations, detailed cost
objectives, plans for maintenance and support, etc.
2.2.1 Cardiac Catheterization Workflow (CATH)
Cardiac Catheterization is complex, especially from a workflow perspective. Evidence-gathering
activities may begin before an order is placed; in fact, orders are often not created for a cardiac
catheterization procedure due to its frequent emergency nature. There may be a variety ofimaging, measurement, and reporting systems that need to coordinate to use the same patient
identifier, and to assure that the evidence produced is all associated with the same procedure.
Further, the procedure itself may include both diagnostic and interventional or therapeutic
aspects, and may extend over a long time period (several hours).
The Cardiac Catheterization Workflow Integration Profile establishes the continuity and integrityof basic patient data in the context of the cardiac catheterization procedure. This profile deals
specifically with consistent handling of patient identifiers and demographic data, including that of__________________________________________________________________________
17
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
emergency patient presentation where the actual patient identity may not be established until after
the beginning of the procedure, or even a significant time after the completion of the procedure. It
also specifies the scheduling and coordination of procedure data across a variety of imaging,measurement, and analysis systems, and its reliable storage in an archive from where it isavailable to support subsequent workflow steps, such as reporting. It also provides central
coordination of the completion status of steps of a potentially multi-phase (diagnostic andinterventional) procedure.
2.2.2 Echocardiography Workflow (ECHO)The Echocardiography Workflow Integration Profile describes the workflow associated withdigital echocardiography, specifically that of transthoracic echo (TTE), transesophageal echo(TEE), and stress echo. As does the Cath Workflow Integration Profile, this profile deals withpatient identifiers, orders, scheduling, status reporting, multi-stage exams (especially stress echo),and data storage. It also specifically addresses the issues of acquisition modality devices that are
only intermittently connected to the network, such as portable echo machines, and addresses
echo-specific data requirements.
Intravascular ultrasound (IVUS) and intracardiac echocardiography (ICE) are used in cardiac
catheterization procedures, and are supported as modalities in the Cath Workflow, and not in the
Echo Workflow.
2.2.3 Retrieve ECG for Display (ECG)
The Retrieve ECG for Display Integration Profile specifies a mechanism for broad accessthroughout the enterprise to electrocardiogram (ECG) documents for review purposes. The ECG
documents may include “diagnostic quality” waveforms, measurements and interpretations. This
Integration Profile allows the display of this information without requiring specialized cardiology
software or workstations, but with general purpose computer applications such as a Web browser.
This Integration Profile is intended primarily for retrieving resting 12-lead ECGs, but may also
retrieve ECG waveforms gathered during stress, Holter, and other diagnostic tests. This
Integration Profile only addresses ECGs that are already stored in an information system. It does
not address the process of ordering, acquiring, storing, or interpreting the ECGs.
2.2.4 Displayable Reports (DRPT)
This section reserved.
2.2.5 Evidence Documents (ED)The Evidence Documents Profile defines ways for data recorded in the course of carrying out aprocedure step, such as observations, measurements, and results (i.e., evidence documents), to be
output by devices, such as acquisition systems and other workstations; to be stored and managed
by archival systems; and to be retrieved and presented or used by display and reporting systems.
__________________________________________________________________________
18
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
This allows detailed non-image information, such as measurements, CAD results, procedure logs,
etc. to be made available as input to the process of generating a clinical Report, either as
additional evidence for the reporting physician, or in some cases for selected items in the
Evidence Document to be included in the report.

2.3 Actor Descriptions
Actors are information systems or components of information systems that produce, manage, or
act on information associated with operational activities in the enterprise. The following are theactors defined by IHE and referenced throughout the rest of this document, as well as in otherdomain Technical Framework documents.
It is acknowledged that some of the terms used as modifiers for the actor names are not usedconsistently (e.g., Image Manager, which also manages non-image objects). At this point, thebenefit in doing extensive renaming to gain consistency is outweighed by the risk of introducing
significant confusion that would result from renaming many of the existing actors that are sharedacross multiple domains. Therefore the actor names will remain as defined below.
Acquisition Modality – A system that acquires and creates medical images or waveforms
while a patient is present, e.g., an X-ray angiography or hemodynamic measurement
system. A modality may also create other evidence objects such as Structured Report
Documents containing measurements.
ADT – A system responsible for adding and/or updating patient demographic and encounter
information (Admission/Discharge/Transfer). In particular, it registers a new patientwith the Order Placer and Department System.
Department System Scheduler/Order Filler – A department-based (for instance,
Cardiology or Radiology) information system that provides functions related to the
management of orders received from external systems or through the department
system’s user interface.
Evidence Creator – A system that creates additional evidence objects such as derived images
or measurements (Evidence Documents), and transmits them to an Image Archive.
Image Archive – A system that provides long term storage of evidence objects such asimages, presentation states, Key Image Notes and Evidence Documents.
Image Display – A system that offers browsing of patients’ studies. In addition, it may
support the retrieval and display of selected evidence objects including sets of images,presentation states, Key Image Notes, and/or Evidence Documents.
Image Manager – A system that provides functions related to safe storage and managementof evidence objects. It supplies availability information for those objects to the
Department System Scheduler.
Order Placer – A hospital or enterprise-wide system that generates orders for various
departments and distributes those orders to the correct department.
__________________________________________________________________________
19
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Performed Procedure Step Manager – A system that re-distributes the Modality Performed
Procedure Step information from the Acquisition Modality to the Department System
Scheduler/Order Filler and Image Manager.
Report Creator – A system that generates and transmits clinical reports.
Time Client – A system unit that synchronizes its time of day clock to the correct time
provided by a time server
Display – A system that can request and display preformatted (“presentation-ready”) datausing Web technologies.
Information Source – A system that responds to requests for patient-related data by encoding
it in a presentation-ready format using Web technologies.
The following table shows which actors are used in which Integration Profiles.
Table 2.3-1. Integration Profile Actors
Integration Profile

CATH

ECHO

ECG

ED

Acquisition Modality

X

X

ADT Patient Registration

X

X

Department System Scheduler/Order Filler

X

X

Evidence Creator

X

X

X

Image Archive

X

X

X

Image Display

X

X

X

Image Manager

X

X

X

Order Placer

X

X

Performed Procedure Step Manager

X

X

Actor
X

Report Creator
Time ClientX(note 1)

Display

X

Information Source

X

Notes: 1. The Time Client actor is not formally part of the Cath Workflow Profile, but it must begrouped with certain actors in that Profile.
2. The Information Source actor is not formally part of the Displayable Reports Profile,
but must be grouped with the Report Repository actor in that Profile.

2.4 Transaction Descriptions
Transactions are interactions between actors that transfer the required information throughstandards-based messages. The following are the transactions defined by IHE and referenced
throughout the rest of this document. Those transactions specified in other domain Technical
Framework documents are identified with the domain identifier and transaction number.
__________________________________________________________________________
20
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Patient Registration – The ADT system registers and/or admits a patient and forwards theinformation to other information systems. [RAD-1]
Placer Order Management – The Order Placer informs the Order Filler of the initiation orcancellation of an order. The Placer/Filler Order Management transaction will
sometimes be referred to as “-New” when a new order is being initiated, or as “Cancel” when an existing order is canceled. [RAD-2]
Filler Order Management – The Order Filler informs the Order Placer of the initiation,
cancellation, or change in the status of an order. The Placer/Filler Order Managementtransaction will sometimes be referred to as “-New” when a new order is being
initiated, or as “-Cancel” when an existing order is canceled. [RAD-3]
Procedure Scheduled – Schedule information is sent from the Department System
Scheduler/Order Filler to the Image Manager. [RAD-4]
Query Modality Worklist – Based on a query entered at the Acquisition Modality, amodality worklist is generated listing all the items that satisfy the query. This list of
Scheduled Procedure Steps with selected demographic information is returned to theAcquisition Modality [RAD-5].
Modality Procedure Step In Progress – An Acquisition Modality notifies the Performed
Procedure Step Manager of the start of a new Procedure Step and the PPS Manager
informs the Department System Scheduler/Order Filler and Image Manager. [CARD1, derived from RAD-6]
Modality Procedure Step Completed – An Acquisition Modality notifies the Performed
Procedure Step Manager of the completion of a Procedure Step and the PPS Manager
informs the Department System Scheduler/Order Filler and Image Manager. [RAD-7]
Modality Images/Evidence Stored – An Acquisition Modality sends acquired or generated
images, waveforms, or other evidence documents to the Image Archive. [CARD-2,
derived from RAD-8 and RAD-43]
Storage Commitment – A requestor (Acquisition Modality) requests that the Image Manager
confirm ownership for the specified DICOM objects (images, waveforms, evidence
documents, or any combination thereof) that the requestor stored in the Image
Archive, thus allowing the sender to delete those objects now owned by the ImageManager. [CARD-3, derived from RAD-10]
Patient Update – The ADT Patient Registration System informs the Order Placer and theDepartment System Scheduler/Order Filler of new information for a particular patient.
The Department System Scheduler may then further inform the Image Manager.
[RAD-12]
Procedure Update – The Department System Scheduler/Order Filler sends the ImageManager updated order or procedure information. [RAD-13]__________________________________________________________________________
21
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Query Images – An Image Display queries the Image Archive for a list of entries
representing images by patient, study, series, or instance. [RAD-14]
Query Evidence Documents – A user of Evidence Documents queries the Image Archive fora list of entries representing Evidence Documents. [RAD-44]
Retrieve Images/Evidence – An Image Display requests and retrieves a particular image or
set of images or other evidence from the Image Archive. [CARD-4, derived from
RAD-16 and RAD-44]
Instance Availability Notification – The Image Manager/Image Archive notifies interested
workflow actors (such as the Department System Scheduler/Order Filler and ReportManager) about the availability status of instances at specified storage locations.
[RAD-49]
Maintain Time – Synchronize the local time with the time maintained by the Time Server.
[ITI-1]Retrieve Specific Info for Display – A Display queries an Information Source for a specific
type information by patient and time period. [ITI-11]
Retrieve ECG List – A Display queries an Information Source for a list of entries
representing ECG documents by patient and time period. [CARD-5, derived from ITI11]
Retrieve ECG Document for Display – A Display queries an Information Source for a
specific ECG document by document ID. [CARD-6, derived from ITI-12]
The following table shows which transactions are used in which Integration Profiles.
Table 2.4-1. Integration Profile Transactions
Integration Profile

CATH ECHO ECGEDTransaction
Patient Registration [RAD-1]

X

X

Placer Order Management [RAD-2]

X

X

Filler Order Management [RAD-3]

X

X

Procedure Scheduled [RAD-4]

X

X

Query Modality Worklist [RAD-5]

X

X

Modality Procedure Step In Progress [CARD-1]

X

X

Modality Procedure Step Completed [RAD-7]

X

X

Modality Images/Evidence Stored [CARD-2]

X

X

X

Storage Commitment [CARD-3]

X

X

X

Patient Update [RAD-12]

X

X

Procedure Update [RAD-13]

X

X

Query Images [RAD-14]

X

X__________________________________________________________________________
22
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Integration Profile

CATH ECHO ECGEDTransaction
Query Evidence Documents [RAD-44]

X

Retrieve Images/Evidence [CARD-4]

X

X

Instance Availability Notification [RAD-49]

X

X

Maintain Time [ITI-1](note 1)Retrieve Specific Info for Display [ITI-11]

X

Retrieve ECG List [CARD-5]

X

Retrieve ECG Document for Display [CARD-6]

X

Notes: 1. The Maintain Time transaction is not formally part of the Cath Workflow Profile, but it
is required for the Time Client actor grouped with certain actors in that Profile.

2.5 Product Implementations
Developers have a number of options in implementing IHE actors and transactions in productimplementations. The decisions cover four levels of optionality:• For a system, select which actors it will incorporate. (Multiple actors per system is
acceptable).
• For each actor, select which Integration Profiles it will participate in.
• For each actor-profile, select which optional transactions will be implemented. All required
transactions must be implemented for the profile to be supported. (Refer to the Integration
Profile Tables in sections 3-5)
• Finally, for each transaction, select which optional features will be supported. (Refer to thetransaction descriptions in CARD-TF Volume II, or the appropriate domain TF)
Implementers should provide a statement describing which IHE Actors, IHE Integration Profiles,
optional transactions and optional features are incorporated in a given product. The recommended
form for such a statement is defined in Appendix C.
In general, a product implementation may incorporate any single actor or combination of actors.
However, in the cases specified below, the implementation of one actor requires theimplementation of one or more additional actors:• The Image Archive shall be grouped with the Image Manager, and the Image Manager shallbe grouped with the Image Archive.
• The Image Manager participating in Cath Workflow or Echo Workflow Integration Profiles
shall be grouped with a Performed Procedure Step Manager. The grouped Performed
Procedure Step Manager shall be capable of being disabled via configuration.
• The Department System Scheduler/Order Filler participating in Cath Workflow or Echo
Workflow shall be grouped with a Performed Procedure Step Manager. The grouped
Performed Procedure Step Manager shall be capable of being disabled via configuration.
__________________________________________________________________________
23
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________•The DSS/Order Filler and Modality Acquisition Actors participating in Cath Workflow
Integration Profile shall be grouped with the Time Client Actor of the Consistent Time Profile

When multiple actors are grouped in a single product implementation, all transactions originatingor terminating with each of the supported actors shall be supported (i.e., the IHE transactions shallbe offered on an external product interface). The exceptions to this rule are any transactions
defined between actors in the required groupings defined above.
For example, the Procedure Step In Progress/Completed transaction does not need to be supported
between the Performed Procedure Step Manager and the Image Manager when these are grouped
together in a single system.
When two or more actors are grouped together, internal communication between actors is
assumed to be sufficient to allow the necessary information flow to support their functionality; forexample, the Image Manager provides necessary information updates to the Image Archive tosupport its Query/Retrieve functionality. The exact mechanisms of such internal communication
are outside the scope of the IHE Technical Framework.

__________________________________________________________________________
24
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

3 Cardiac Catheterization Workflow (CATH)
The Cardiac Catheterization Workflow Integration Profile establishes the continuity and integrityof basic patient data in the context of the cardiac catheterization procedure. This profile deals
specifically with consistent handling of patient identifiers and demographic data, including that ofemergency patient presentation where the actual patient identity may not be established until after
the beginning of the procedure, or even a significant time after the completion of the procedure. It
also specifies the scheduling and coordination of procedure data across a variety of imaging,measurement, and analysis systems, and its reliable storage in an archive from where it isavailable to support subsequent workflow steps, such as reporting. It also provides central
coordination of the completion status of steps of a potentially multi-phase (diagnostic andinterventional) procedure.
This profile has much in common with the IHE Radiology Scheduled Workflow, Patient
Information Reconciliation, and Evidence Document Integration Profiles, but deals more
explicitly with the multi-modality coordination, and with cath-specific data requirements. See
Rad TF-1: 3.4 for the integrated workflow data model adopted by the IHE Technical Frameworkfor HL7 messages and DICOM information objects. This data model offers three major levels ofcontrol for workflow:• Order: A request for a Departmental Service• Requested Procedure: Unit of work resulting in one or more reports, with associatedcodified, billable acts.
• Scheduled and Performed Procedure Step: the smallest unit of work in theworkflow that is scheduled (work to do) or performed (work done).
A clear understanding of the workflow data model is essential to interpreting the Cath Workflow
Integration Profile. Additional information may be found in Appendix B.
Although the major cases for cath workflow are described in the following subsections, it isbeneficial to also see the corresponding workflows in radiology. Rad TF-1: 3.3 has a descriptionof the “normal” scheduled workflow when all three levels of control in the data model are fully
utilized for known patients, and Rad TF-1: 4.3 and 4.4 describes workflows when the patient is
unknown and/or the ordering and scheduling process is short-circuited (e.g., in the emergencycase). Even in this latter case, all three levels of control are present and used, although not to theirfull extent.

__________________________________________________________________________
25
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

3.1 Actors/Transactions
Figure 3.1-1 diagrams the actors involved with this profile and the transactions between actors.

ADT

Pt. Registration [RAD-1] ↓Patient Update [RAD-12] ↓DSS/ Order Filler↓ Pt. Registration [RAD-1]↓ Patient Update [RAD-12]← Placer Order Management [RAD-2]→ Filler Order Management [RAD-3]

Time Client↑ Modality PS in Progress [CARD-1]↑ Modality PS Completed [RAD-7]↓ Procedure Scheduled [RAD-4]↓ Patient Update [RAD-12]↓ Procedure Updated [RAD-13]↑ Instance Availability Notification [RAD-49]
Evidence
Creator← Modality PS in Progress [CARD-1]← Modality PS Completed [RAD-7]
Storage ↓Commitment[CARD-3]

Performed
Procedure
Step Manager

Order Placer

Image Display↓ Modality Image/EvidenceStored [CARD-2]

Image
Manager↓ Query Images [RAD-14]↓ Retrieve Images/Evidence [CARD-4]

Image
Archive→ Modality PS in Progress [CARD-1]→ Modality PS Completed [RAD-7]
StorageCommitment ↑[CARD-3]↑Modality Image/EvidenceStored [CARD-2]← Modality PS in Progress [CARD-1]← Modality PS Completed [RAD-7]← Query Modality Worklist [RAD-5]

Acquisition
Modality
Time Client

Figure 3.1-1. Cath Workflow Diagram

Note that this diagram maintains the actor and transaction names specified in the Radiology
Technical Framework (RAD-TF) for consistency of definitions.
Table 3.1-1 lists the transactions for each actor directly involved in the Cath Workflow
Integration Profile. In order to claim support of this Integration Profile, an implementation must
perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A
complete list of options defined by this Integration Profile that implementations may choose tosupport is listed in Section 3.2.

__________________________________________________________________________
26
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Table 3.1-1. Cath Workflow - Actors and Transactions
Optionality

Section

ADT Patient
Registration

ActorsPatient Registration [RAD-1]

R

RAD-TF 2: 4.1

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Order Placer

Patient Registration [RAD-1]

R

RAD-TF 2: 4.1

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Placer Order Management [RAD-2]

R

RAD-TF 2: 4.2

Filler Order Management [RAD-3]

R

RAD-TF 2: 4.3

Patient Registration [RAD-1]

R

RAD-TF 2: 4.1

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Placer Order Management [RAD-2]

R

RAD-TF 2: 4.2

Filler Order Management [RAD-3]

R

RAD-TF 2: 4.3

Procedure Scheduled [RAD-4]

R

RAD-TF 2: 4.4

Query Modality Worklist [RAD-5]

R

RAD-TF 2: 4.5

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Procedure Updated [RAD-13]

R

RAD-TF 2: 4.13

Instance Availability Notification [RAD-49]

O

RAD-TF 3: 4.49

Query Modality Worklist [RAD-5]

R

RAD-TF 2: 4.5

Department System
Scheduler/
Order Filler

Acquisition
Modality

Image Manager/
Image Archive

Transactions

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Modality Images/Evidence Stored [CARD-2]

R

CARD-TF 2: 4.2

Storage Commitment [CARD-3]

R

CARD-TF 2: 4.3

Procedure Scheduled [RAD-4]

R

RAD-TF 2: 4.4

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Modality Images/Evidence Stored [CARD-2]

R

CARD-TF 2: 4.2

Storage Commitment [CARD-3]

R

CARD-TF 2: 4.3

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Procedure Updated [RAD-13]

R

RAD-TF 2: 4.13

Query Images [RAD-14]

R

RAD-TF 2: 4.14

Retrieve Images/Evidence [CARD-4]

R

CARD-TF 2: 4.4

Instance Availability Notification [RAD-49]

O

RAD-TF 3: 4.49

Performed
Procedure Step
Manager

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Image Display

Query Images [RAD-14]

R

RAD-TF 2: 4.14

Retrieve Images/Evidence [CARD-4]

R

CARD-TF 2: 4.4

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Evidence Creator__________________________________________________________________________
27
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Actors

Optionality

Section

Modality Images/Evidence Stored [CARD-2]

TransactionsR

CARD-TF 2: 4.2

Storage Commitment [CARD-3]

R

CARD-TF 2: 4.3

Refer to Table 2-1 for other profiles that may be pre-requisites for this profile.

3.2 Cath Workflow Integration Profile Options
Many Actors have Options defined in order to accommodate variations in use across domains orimplementations. Options that may be selected for this Integration Profile are listed in the table
3.2-1 along with the Actors to which they apply. Certain of these Options are required for
implementation by actors in this Profile (although they may be truly optional in other Profiles).
Table 3.2-1: Cath Workflow - Actors and Options
Actor

Option Name

Optionality

Vol & Section

ADT Patient Registration

No options defined--

Order Placer

No options defined--

Department System Scheduler/Order
FillerMulti-modality Procedure Update

R

CARD-TF 2: 4.1

PPS Exception Management

O

RAD-TF 2: 4.7

Availability of PPS-Referenced InstancesO

RAD-TF 3: 4.49

Patient Based Worklist QueryO

RAD-TF 2: 4.5

Acquisition Modality

Broad Worklist Query

R (see note)

RAD-TF 2: 4.5

PPS Exception Management

O

RAD-TF 2: 4.7

PPS Exception Management

O

RAD-TF 2: 4.7

Intermittently Connected Modality

R

CARD-TF 2: 4.3

Cardiac CathR

CARD-TF 2: 4.2

Availability of PPS-Referenced InstancesO

RAD-TF 3: 4.49

Image Display

No options defined--

Performed Procedure Step Manager

No options defined--

Evidence Creator

No options defined--

Image Manager/ Image Archive

Note:

The Broad Worklist Query option is required to support Case C7, and facilitates effective
workflow in the multimodality environment.

The Acquisition Modality and Image Manager/ Image Archive will likely support a variety of
DICOM SOP Classes. It is expected that this level of optionality will be documented by areference in the IHE Integration Statement (see Appendix C).

3.3 Cath Scheduled Process Flow
Each process flow is introduced with an overview of the end-user issue addressed (“ClinicalContext”) and the approach taken in the Technical Framework (“IHE Context”).
__________________________________________________________________________
28
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Clinical context: This reflects the situation where a patient is admitted to the facility, and a cathprocedure is ordered and scheduled, similar to a radiology procedure. The main difference is thatcath is inherently multi modality so there needs to be a way for all of the participating modalities
to coordinate and to share patient and procedure information. Note that while Scheduled
Workflow is the normal or expected situation in radiology, it is currently the exception in Cardiac
Catheterization. The procedure traditionally is rarely ordered, as it is typically preceded by a
Cardiology Consultation that simply arranges for the procedure to be done. See also Appendix A
which discusses the cath procedure and its relationship to the overall episode of care.
IHE Context: This section describes the “normal” scheduled workflow when all three levels ofcontrol (order, requested procedure, and scheduled/performed procedure steps) in the IHE data
model are fully utilized to request a procedure for known patients. In fact, orders are often notcreated for a cardiac catheterization procedure due to its frequent emergency nature, but thisprocess flow provides the basis for understanding the specific use cases described in section 3.4.
In fact, this workflow, plus a patient information reconciliation step, constitutes case C1 in section
3.4
For comparison with radiology, see RAD-TF 1:3.3. To facilitate such comparison for thosereaders familiar with RAD-TF, the differences between the radiology Process Flow Diagrams andthose in cardiology are shown in green in the figures. Note that the Order Change Flow (RAD-TF
1:3.3.3) and the Exception Management Workflow (RAD-TF 1:3.3.4) may be used as elaborated
there, and are not further described in the Cardiology Technical Framework. The functionality of
those data flows is specified within the specific transactions invoked by the CARD-TF.

__________________________________________________________________________
29
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Order
PlacerADT

Department System
Scheduler/ Order Filler

Image
Manager

Acquisition
Modality

Register/
Admit
Patient
Patient
Registration [RAD-1]

Create Order
Placer Order Mgmt New [RAD-2]
Schedule
Procedure
Procedure
Scheduled [RAD-4]
Start
Procedure
Query Modality Worklist [RAD-5]
SelectPatient

Figure 3.3-1. Scheduled Workflow: Administrative Process Flow

The following should be noted in relation to the Administrative process flow:• Patient Registration: The Patient Registration data is broadcast to several systems, including
the Order Placer and the Department System Scheduler/Order Filler (DSS/OF).
• Create Order: The Order Placer is the repository for all patient orders.
• Schedule Procedure: The DSS/OF associates the order with one or more Requested
Procedures that have to be performed to satisfy the order. Each Requested Procedure
prescribes a number of actions that have to be performed by Acquisition Modalities. Actions
are specified in Scheduled Procedure Steps (SPS) based on timing and sequencing, and on
modality. Scheduled Procedure Steps are scheduled, i.e., assigned a time slot and performing
resource (modality), and are made available for Modality Worklist Query.
• Start Procedure: The DSS/OF may have an optional function to start the Cath Procedure,
typically to allow the collection of patient data specifically tied to the procedure but outside
the scope of any particular modality. This may result, for instance, in the “Arrived” status
being set in the associated SPSs. The purpose of this action is to start a procedure from a nonmodality actor.
• Query Modality Worklist: The Modality Worklist (MWL) query may be broad (get a list ofscheduled procedures from which one will be selected), or patient-specific (provided with__________________________________________________________________________
30
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
sufficient query keys to get back the scheduled procedure for a single patient). The latter casemay be facilitated by entering the Patient ID from a bar-coded wristband into the MWL query(as an institution’s cath lab standard operating procedure).
• Select Patient: In the event of a single SPS in the MWL response, a modality may optimize
the Select Patient function to select that SPS without further explicit user action.
See Appendix B for further description.

Order
Placer

Department System
Scheduler/ Order
FillerImage
Manager/
Image Archive/
PPS Manager

Modality Procedure
Step In Progress[CARD-1]

Acquisition
Modality n

Acquisition
Modality

Modality Procedure
Step In Progress[CARD-1]

UpdateSchedule

Filler Order
Mgmt - Status
Update [RAD-3]

Query Modality Worklist [RAD-5]
Modality Procedure
Step In Progress[CARD-1]

SelectPatient

Modality Procedure
Step In Progress[CARD-1]
Modality Images/
Evidence Stored[CARD-2]

Perform
Acquisition

Modality Images/Evidence Stored[CARD-2]

Perform
Acquisition

Modality Procedure
Modality Procedure
Step Completed
Step Completed [RAD-7][RAD-7]Filler Order
Mgmt - Status
Update [RAD-3]

End
Procedure

StorageCommitment[CARD-3]

Figure 3.3-2. Scheduled Workflow: Procedure Performance Process Flow

The following should be noted in relation to the Procedure Performance process flow:• Modality Procedure Step In Progress and Update Schedule: Initial Procedure scheduling may
be vague (i.e., not exactly specify a time or cath lab), or the procedure may be performed in alab room different from the one in which it was scheduled. If the DSS/OF has not started theprocedure, upon receipt of first MPPS In Progress for the Cath Lab, which includes the patient
ID/name and the modality Station AE Title (which allows it to be linked to a specific cathlab), the DSS/OF updates the Scheduled Procedure Steps for all the modalities in that same__________________________________________________________________________
31
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

•

•

•

•

•

cath lab to reflect the current active case (i.e., that first MPPS serves as “current patient / lab
selection”).
Query Modality Worklist: MWL queries from modalities in that cath lab subsequent to theUpdate Schedule process may be able to use a broad query with sufficient request keys thatwould return in the MWL response only a single SPS for the current patient, allowing
optimization of modality start-up.
Perform Acquisition: Each Modality may produce a variety of images and other evidence(waveforms, analysis reports, etc.) that are stored to the Image Manager/Archive. The ImageManager/Archive must support all the object types (beyond just images) as specified by the
Cardiac Cath Option (see CARD-TF-2: 4.2.1).
Modality Procedure Step Complete and End Procedure: Modality Procedure Step Complete
also includes Modality Procedure Step Discontinued. The simple transmission of a Complete
or Discontinued does not indicate that a modality is then available, due to multi-stepprocedures (diagnostic/interventional) and multi-modality cross-dependencies in a procedureroom. It is a function of the DSS/OF (outside the scope of this document) to determine whento end the procedure, and declare the modality resources in the room are available for anotherprocedure.
Storage Commitment: The Image Manager/Archive accepts responsibility for stored images
and evidence, allowing the modality to delete the data from its local storage. The ImageManager/Archive shall support mobile devices, such as intravascular ultrasound (IVUS) andintracardiac echocardiography (ICE), that may be intermittently connected to the network andtemporarily unable to receive Storage Commitment messages.
Filler Order Management - Status Update: Status Update transactions may be sent to theOrder Placer at several points in the workflow, although only the update after the first
Modality Procedure Step In Progress and the last Modality Procedure Step Complete areshown.

3.4 Cath Workflow Use Cases
This section describes the specific use cases and process flows defined for the Cath Workflow
Profile.
Clinical Context: Currently, the most common scenario for the performance of a cardiac
catheterization is that a consulting cardiologist recommends that the patient undergo acatheterization, and makes the arrangements by phone for the procedure. This is a simple
logistical arrangement with the cath lab that rarely involves a formal electronic schedulingactivity (this function is served instead by the ubiquitous “whiteboard”). At this point, one ofthree paths may be used: the procedure is ordered at the Order Placer system, the procedure isordered at the departmental system, or the procedure begins without an order in the cath lab.
Note that in operations typical of current practice in the cath lab, there is little (if any) interaction
between the department information systems and a hospital Order Placer system. One of thegoals of IHE is to facilitate better integration between those two worlds, and enable the Order__________________________________________________________________________
32
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Placer system to provide a uniform system of order management for the departments. The
clinical context of the Cath Workflow Profile encourages the evolution from current practice to amore highly integrated enterprise workflow.
IHE Context: Many of the use cases include the set of transactions necessary for post-hoc
updating of patient information. In the Radiology Technical Framework, this is specified in a
separate Patient Information Reconciliation Profile, but because the cath workflow needs to deal
with this in a large percentage of cases, patient updating has been included in the basic Cath
Workflow Profile. However, the specific data flows for such reconciliation are indicated in theProcess Flow Diagrams in blue.
The use cases parallel those defined in the Radiology Patient Information Reconciliation Profile(RAD-TF 1:4.4). To facilitate comparison for those readers familiar with RAD-TF, thedifferences between the radiology Process Flow Diagrams and those in cardiology are shown ingreen in the figures of the following subsections.
There are six specific Use Cases defined for Cath Workflow, C1 through C6, whose variations
occur based on whether or not and where a patient is registered, as well as whether or not andwhere an order is placed. These variations are listed in Table 3.4-1. Cath use cases C1 throughC6 correspond closely to RAD-TF Patient Information Reconciliation use cases 1 through 6.
Additional use cases, C7: Change Rooms During Procedure, C8: Cancel Procedure, and C9:
Post-Procedure Evidence Creation, are not shown in the Table.
Table 3.4-1. Cath Workflow Cases
Order Placed atOrder Placer

Order Placed atOrder Filler

Order Not Placed

Patient Registered at ADT

Case C1

Case C2

Case C3

Patient Registered in the
Department (see note)

Not Applicable the Order Placer
requires the patientregistration fromthe ADT system

Case C4

Case C5

Case C6

Case C6

Case C6

Order
Placement
Patient
Registration

Patient Updated

Note:

Patient is registered in the department either in the DSS/OF system, or manually (temporary
ID assigned on paper and manually entered into the modality).

__________________________________________________________________________
33
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Note: The transactions for Modality Image/Evidence Stored and Storage Commitment are notshown in the following subsections, and select Order Status Update transactions are notshown, as they do not impact the process control workflow. Also only selectedtransactions for “Modality N” (i.e., representing multiple additional modalities in the lab)
are shown to indicate the multi-modality nature of the Process Flow.
Also note that the Performed Procedure Step Manager as shown on the Process Flow
diagrams is presumed to be grouped with the Image Manager for the purpose ofpresentation. In actual implementations it may be grouped with the Department System
Scheduler/Order Filler with corresponding changes in the flow of PPS related transactions
between the Image Manager and Department System Scheduler/Order Filler.
3.4.1 Case C1: Patient Registered at ADT and Procedure Ordered at the Order
PlacerClinical Context: This corresponds to the more traditional Radiology Structured Workflow,where an order is placed in the hospital ordering system for the Cardiac Catheterization. It also
accounts for the special situation where an emergency identifier has been created for the patient(so that the patient is registered in the ADT and has been assigned a unique identifier). Since theorder is placed before the procedure begins, common identifiers can be used to enable thecoordinated presentation and electronic distribution of all of the information related to the cardiac
cath.
IHE Context: This case includes the full scheduled workflow when all three levels of control(order, requested procedure, and scheduled/performed procedure steps) in the IHE data model are
fully utilized to request a procedure (see section 3.3).
The patient may be registered at the ADT system as a known patient with complete
demographics, or with incomplete demographics, including the case of a totally unidentified
patient for whom only a Patient ID and a temporary name are assigned. To the subsequentsystems in the Cath Workflow, it is irrelevant to procedure performance whether or not thecomplete demographics are known. This case thus includes both identified and unidentified
patients, registered at the ADT system, for whom Orders are created at the Order Placer, andwhose procedures are scheduled at the Department System Scheduler/Order Filler (DSS/OF).
For unidentified patients the ADT system is a single point of patient reconciliation in theenterprise. When the real patient identity is known, the ADT is responsible for reconciliation of
its own records, as well as informing the Order Placer and DSS/OF about corresponding changes.
The ADT sends a Patient Update message to both the Order Placer and DSS/OF. The DSS/OF
sends the Patient Update message to the Image Manager.

__________________________________________________________________________
34
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Department System
Scheduler/
Order Filler

Order
PlacerADT

ImageManager/
PPS Manager

Acquisition
Modality

Acquisition
Modality n

Register J.Doe
Patient
Registration [RAD-1]
Placer OrderManagement–
New [RAD-2]
Schedule
Procedure
Procedure
Scheduled [RAD-4]
Start
Procedure

Query Modality Worklist [RAD-5]
Modality Procedure
Step In Progress[CARD-1]

Modality Procedure
Step In Progress[CARD-1]

Perform
Acquisition

UpdateSchedule
Query Modality Worklist [RAD-5]
Patient Reconciliation
J.Doe ->
J.SmithFiller Order
Mgmt - Status
Update [RAD-3]

Patient Update/
Merge [RAD-12]

Modality Procedure
Step Completed[RAD-7]

Perform
Acquisition

Modality Procedure
Step Completed[RAD-7]

Patient Update/
Merge [RAD-12]

Figure 3.4-1. Patient Registered at ADT and Ordered at the Order Placer – Case C1

Significant Transactions (see also Section 3.3):•

To reconcile the patient information, the ADT may register a new patient and merge thetemporary patient with the correct patient, and send both Patient Registration [RAD-1] andPatient Update [RAD-12] (Merge) transactions to the Order Placer and DSS/OF.

•

If a permanent Patient ID was assigned, then the ADT may only send a Patient Update[RAD-12] transaction with proper information.

Note that if the Order has been placed, but not scheduled, there will be no response to theModality Worklist query. In that case, the system will treat this as Case C3 (Patient Registered at
ADT and Procedure Not Ordered), and the original Order will need to be canceled by a manual
process.

__________________________________________________________________________
35
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
3.4.2 Case C2: Patient Registered at ADT and Procedure Ordered at DSS/OF
Clinical Context: This scenario is closely akin to Case C1, however, an order is not placed in the
traditional hospital ordering system, but rather, the procedure information is entered at the
Departmental System, which then submits the information to the hospital ordering system. This
workflow is typical of many institutions, and alleviates the need to have an Order Placer system(HIS) terminal in the department or cath lab.
IHE Context: This case is based on case C1. However, in this situation the order for a procedure
for a registered patient is generated by the Department System Scheduler/Order Filler andsubmitted to the Order Placer. Procedures are scheduled normally and acquisition systems use
Modality Worklist.
If the patient information requires subsequent reconciliation, the ADT sends the Patient Update
messages to both the Order Placer and Department System Scheduler/Order Filler. The
Department System Scheduler/Order Filler sends the Patient Update message to the ImageManager as in case C1.
Department System
Scheduler/
Order Filler

Order
PlacerADT

ImageManager/
PPS Manager

Acquisition
Modality

Acquisition
Modality n

Register J.Doe
Patient
Registration [RAD-1]

Filler OrderManagement New [RAD-3]
Start
Procedure

Schedule
Procedure
Procedure
Scheduled [RAD-4]
Query Modality Worklist [RAD-5]
Modality Procedure
Step In Progress[CARD-1]

UpdateSchedule

Patient Reconciliation
J.Doe ->
J.SmithFiller Order
Mgmt - Status
Update [RAD-3]

Patient Update/
Merge [RAD-12]

Modality Procedure
Step In Progress[CARD-1]
Query Modality Worklist [RAD-5]

Modality Procedure
Step Completed[RAD-7]

Modality Procedure
Step Completed[RAD-7]

Perform
Acquisition

Perform
Acquisition

Patient Update/
Merge [RAD-12]

Figure 3.4-2. Patient Registered at ADT and Ordered at DSS/OF – Case C2__________________________________________________________________________
36
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Significant Transactions:•

A Filler Order Management (New Order) transaction [RAD-3] is sent from Department
System Scheduler/Order Filler to the Order Placer.

3.4.3 Case C3: Patient Registered at ADT and Procedure Not Ordered
Clinical Context: This scenario is similar to case C2, but the procedure information is notentered at the departmental system (e.g., due to time constraints). One of the participating
modalities will therefore need to initiate the process of creating the common procedure identifiers.
The identifiers are created at the departmental system based on an action taken by the firstmodality to start the procedure (typically the hemodynamics system); they are then available forsubsequent modalities to share. The amount of detail in the procedure information will be limited
to what is provided by the first modality, e.g., if it does not provide a coded procedure type, it will
necessarily appear as a “generic cath procedure”. It is desirable whenever possible to use case C1
or case C2 process flows.
IHE Context: As in cases C1 and C2, this uses a permanent Patient ID generated by the ADT fora registered patient (identified, or unidentified). However, no order entry or scheduling takes
place before an Acquisition Modality begins performing the procedure. The permanent Patient ID
is entered at the Acquisition Modality (typically, from a patient wristband; a barcode reader may
minimize the occurrence of data entry errors).
This case differs from the corresponding Radiology use case. Because the cath procedure isinherently multi-modality, it is essential for all devices to use a common set of identifiers for thepatient and study. Therefore, upon receiving the first Modality Procedure Step In Progress, the
DSS/OF will automatically create a Requested Procedure for the cath exam, and its associated
Scheduled Procedure Steps for all modalities in the same cath lab (room), utilizing the Study UID
provided by the first Modality Procedure Step In Progress. The other modalities in that lab canthen obtain coordinated identifiers using the Query Modality Worklist transaction.
See Appendix B for further details.
When the Requested Procedure is automatically created, the DSS/OF generates and submits anorder to the Order Placer, as in case C2, using a generic cardiac cath procedure code, and thensends a Procedure Scheduled to the Image Manager.
Notes: 1. The difference from the Radiology TF is that the DSS/OF creation of a Requested
Procedure occurs upon the MPPS In Progress (N-CREATE) message, not the MPPS
Completed message; this allows multi-modality synchronization to the same Requested
Procedure.
2. Also, the DSS/OF does not wait for the Order Placer to return a response with an Order
Placer Number before creating the Requested Procedure, as this may delay expeditious
creation of SPSs to enable time-critical multi-modality start-up in the cath lab.

If the patient information requires subsequent reconciliation, the ADT sends the Patient Update
messages to both the Order Placer and Department System Scheduler/Order Filler. The__________________________________________________________________________
37
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Department System Scheduler/Order Filler sends the Patient Update message to the ImageManager as in case C1.
Department System
Scheduler/
Order Filler

Order
PlacerADT

ImageManager/
PPS Manager

Acquisition
Modality

Acquisition
Modality n

Register J.Doe
Patient
Registration [RAD-1]
Modality Procedure
Step In Progress[CARD-1]
Filler OrderManagement New [RAD-3]
Filler Order
Mgmt - Status
Update [RAD-3]

Modality Procedure
Step In Progress[CARD-1]

Auto-create
Procedure

Perform
Acquisition

Procedure
Scheduled [RAD-4]

Query Modality Worklist [RAD-5]
Patient Reconciliation
J.Doe ->
J.SmithFiller Order
Mgmt - Status
Update [RAD-3]

Patient Update/
Merge [RAD-12]

Modality Procedure
Step Completed[RAD-7]

Modality Procedure
Step Completed[RAD-7]

Perform
Acquisition

Patient Update/
Merge [RAD-12]

Figure 3.4-3. Patient Registered at ADT and Procedure Not Ordered – Case C3

Significant Transactions:• From the first acquisition modality’s perspective, the difference between this and cases C1and C2 is that the MWL query (not shown) will not return a response for the current
patient. An unscheduled Performed Procedure Step will need to be created.
•

On receiving a Modality Procedure Step In-progress [CARD-1], the Department System
Scheduler/Order Filler recognizes it as an unscheduled case, but can match the Patient ID
to ADT information previously received.

•

Using the information from the MPPS transaction, which includes the patient ID and themodality station AE Title, the DSS/OF creates a new Requested Procedure, and also
creates Scheduled Procedure Steps for all the modalities in that same cath lab to reflect thecurrent active case. Note that since the patient is registered, the DSS/OF will havereceived the demographics associated with the patient ID.

•

The Department System Scheduler/Order Filler sends a Filler Order Management (New
Order) transaction [RAD-3] to the Order Placer, then a Filler Order Management (Status
Update) indicating the in-progress state, and sends a Procedure Scheduled transaction[RAD-4] to the Image Manager.

__________________________________________________________________________
38
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________•

Subsequent Modality Worklist queries [RAD-5] from equipment in this cath lab will
receive the appropriate scheduled procedure steps including the necessary patient/study
identifiers.

3.4.4 Case C4: Patient Registered at DSS/OF and Procedure Ordered
Clinical Context: This is a variation of Case C2 where the order is being placed in thedepartment. This accommodates the emergency case when there is not enough time to register thepatient in the hospital system, or the event that the ADT system is unavailable (e.g., after hours).
In this scenario, however, the patient identifier is not available from the hospital ADT. A
temporary patient identifier is created at the department level, and the procedure information canbe entered. The Order Placer system cannot be notified yet (while the patient ID is still
temporary). At some later time, the registration will occur at the ADT system, at which time thereconciliation with the temporary patient ID can happen (manually at the department system).
The Order Placer system can then also be notified.
IHE Context: In this case, no valid Patient ID is available to the Department System
Scheduler/Order Filler from the ADT system. The DSS/OF assigns a temporary Patient ID and atemporary name and schedules the required procedure. The scheduled procedure with thetemporary Patient ID is conveyed to the Image Manager.
Note:

The Department System Scheduler/Order Filler must ensure that the assigned temporary
Patient ID is unique within its scope.

However, unlike case C2, the DSS/OF does not send the Filler Order Management (New Order)transaction to the Order Placer when the Requested Procedure is created, since the temporary
Patient ID is out of the ADT domain scope of the Order Placer. Similarly, a Filler OrderManagement - Status Update transaction is not sent based on the first MPPS In Progress.
Procedure performance at the modalities proceeds as normal based on Modality Worklist.
When patient information becomes known, the ADT system sends new patient information toboth the Order Placer and the Department System Scheduler/Order Filler. The Department
System Scheduler/Order Filler (typically using a manual process) reconciles received patient
information with that associated with the temporary Patient ID and merges the permanent patient
record with its own temporary one and sends a Patient Update transaction to the Image Manager.
At the same time, the Department System Scheduler/Order Filler generates and submits an orderto the Order Placer using the permanent Patient ID, notifies the Order Placer that the order iscompleted, and updates the Image Manager with the Order Placer Number for the order.

__________________________________________________________________________
39
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Department System
Scheduler/
Order Filler

Order
PlacerADT

ImageManager/
PPS Manager

Acquisition
Modality

Acquisition
Modality n

Assign J.Doe
Temp Patient ID
Schedule
Procedure
Procedure
Scheduled [RAD-4]

Query Modality Worklist [RAD-5]
Modality Procedure
Step In Progress[CARD-1]

Perform
Acquisition

Modality Procedure
Step In Progress[CARD-1]

UpdateSchedule
Query Modality Worklist [RAD-5]
Modality Procedure
Step Completed[RAD-7]

Register
J.SmithModality Procedure
Step Completed[RAD-7]

Perform
Acquisition

Patient
Reconciliation

Patient
Registration [RAD-1]

J.Doe -> J.Smith
Filler OrderManagement New [RAD-3]
Filler Order
Mgmt - Status
Update [RAD-3]

Patient Update/
Merge [RAD-12]
Procedure
Update [RAD-13]

Figure 3.4-4. Patient Registered at DSS/OF and Procedure Ordered – Case C4

Significant Transactions:•Patient information is reconciled internally by the Department System Scheduler/Order
Filler using the Patient Registration from ADT.

•The Department System Scheduler/Order Filler sends the Patient Update [RAD-12], andProcedure Update [RAD-13] transactions to the Image Manager.

•

The Department System Scheduler/Order Filler sends the Filler Order Management (New
Order and Status Update) transactions [RAD-3] to the Order Placer.

3.4.5 Case C5: Patient Not Registered
Clinical Context: This is a combination of Cases C3 and C4 (above). In this case, the patient has
not been registered in the ADT system and there is no order placed ahead of time in either theOrder Placer system or the departmental system. This can occur in an emergency situation where
there is either no patient information available or there is not enough time available to create it. It__________________________________________________________________________
40
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
might also occur in the less emergent setting where the ADT or other key component of the HIS
is unavailable. All of the activities of Cases C3 and C4 need to take place. A temporary patient
ID assigned by the department is entered at the first modality to start the procedure; that modality
forwards the patient and procedure information to the departmental system for sharing with theother modalities. This procedure information cannot be sent yet to the Order Placer system.
When a valid identifier is available from the ADT, the departmental system can complete theprocess of reconciling the patient IDs and notifying the Order Placer system.
IHE Context: In this case, no valid Patient ID is available to the Department System
Scheduler/Order Filler from the ADT system, and no ordering or scheduling is done before theprocedure is performed. A temporary ID and name are entered at the Modality (not from a patient
wristband, since that would be a valid ADT system Patient ID, and is covered in case C3). The
Patient ID and name are selected according to the locally defined rules; for example, selectedfrom the predefined pool of “Patient ID–patient name” pairs. The rules for selecting temporary
Patient ID shall guarantee its uniqueness within the scope of Department System Scheduler/Order
Filler.
As in case C3, it is essential for all devices to use a common set of identifiers for the patient andstudy. Therefore, upon receiving the first Modality Procedure Step In Progress, the DSS/OF willautomatically create a Requested Procedure for the cath exam, and its associated Scheduled
Procedure Steps for all modalities in the same cath lab (room), utilizing the Study UID provided
by the first Modality Procedure Step In Progress. The other modalities in that lab can then obtaincoordinated identifiers using the Query Modality Worklist transaction.
Note:

See note on time delay between the Modality Procedure Step In Progress transaction from thefirst modality, and the availability of SPSs in the Modality Worklist in Appendix B.

The DSS/OF sends a Procedure Scheduled message to the Image Manager. However, as in caseC4, the DSS/OF does not send the Filler Order Management (New Order) transaction to the Order
Placer when the Requested Procedure is created, since the temporary Patient ID is out of the ADT
domain scope of the Order Placer.
Note:

The difference from the Radiology TF is that the DSS/OF creation of a Requested Procedure
occurs automatically upon receipt of the MPPS In Progress (N-CREATE) message, not after
manual reconciliation following the MPPS Completed message; this allows multi-modality
synchronization to the same Requested Procedure. Since the Requested Procedure and(temporary) Patient identifiers are known, the Image Manager can be notified of a Procedure
Scheduled.

When patient information becomes known, the ADT system sends new patient information toboth the Order Placer and the Department System Scheduler/Order Filler. As in case C4, theDepartment System Scheduler/Order Filler (typically using a manual process) reconciles received
patient information with that associated with the temporary Patient ID and merges the permanentpatient record with its own temporary one and sends a Patient Update transaction to the ImageManager. At the same time, the Department System Scheduler/Order Filler generates and submits
an order to the Order Placer using the permanent Patient ID, notifies the Order Placer that theorder is completed, and updates the Image Manager with the Order Placer Number for the order.
__________________________________________________________________________
41
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

ADT

Department System
Scheduler/
Order Filler

Order
PlacerImage
Manager/
PPS Manager

Modality Procedure
Step In Progress[CARD-1]
Auto-create
Procedure

Acquisition
Modality

Modality Procedure
Step In Progress[CARD-1]

Acquisition
Modality nEnter J.Doe
Temp Patient ID
Perform
Acquisition

Procedure
Scheduled [RAD-4]

Query Modality Worklist [RAD-5]
Modality Procedure
Step Completed[RAD-7]

Register J.Smith
Patient
Registration [RAD-1]
Filler OrderManagement New [RAD-3]

Modality Procedure
Step Completed[RAD-7]

Perform
Acquisition

Patient
Reconciliation
J.Doe -> J.Smith
Patient Update/
Merge [RAD-12]
Procedure
Update [RAD-13]

Filler Order
Mgmt - Status
Update [RAD-3]

Figure 3.4-5. Patient Not Registered – Case C5

Significant Transactions:• From the first acquisition modality’s perspective, the difference between this and case C3
is that the MWL query (not shown) will not return a response for the current patient, andthere is no ADT system-issued Patient ID. An unscheduled Performed Procedure Step willneed to be created with a locally created Patient ID.
• On receiving a Modality Procedure Step In-Progress [CARD-1] transaction, theDepartment System Scheduler/Order Filler recognizes it as an unscheduled case, and incontrast to case C3, cannot match the Patient ID to ADT information previously received.
• Using the information from the MPPS transaction, which includes the temporary patient
ID and the modality station name, the DSS/Order Filler creates a new Requested
Procedure, and also creates Scheduled Procedure Steps for all the modalities in that same
cath lab to reflect the current active case. It sends a Procedure Scheduled [RAD-4] to the
Image Manager.
• Patient information is reconciled internally by the Department System Scheduler/Order
Filler using the Patient Registration from the ADT.
• The Department System Scheduler/Order Filler sends a Patient Update/Merge transaction[RAD-12] to the Image Manager.
__________________________________________________________________________
42
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________••The Department System Scheduler/Order Filler sends Filler Order Management (New
Order and Status Update) transactions [RAD-3] to the Order Placer.
Using the information from the placed order, the Department System Scheduler/Order
Filler sends a Procedure Update [RAD-13] transaction to the Image Manager containing
the new official Order Placer number.

3.4.6 Case C6: Patient Updated During Procedure
Clinical Context: An unidentified patient may be registered at the ADT system and brought into
the cath lab with temporary patient demographics. While the procedure is in progress, the ADT
system is able to obtain the correct patient demographics, and sends an update message. In thissituation, some of the information may be obtained with the original (temporary) patient
demographics, and some with the revised demographics. This case identifies how reconciliation
occurs.
IHE Context: Updates may need to occur after the initial Patient Registration and Order
Placement has occurred. The Modality may have requested information from the Department
System Scheduler before the update has occurred and continue to send the images with theoriginal Patient Registration and Order information. The Image Manager will need to update thepatient information in items stored in the Image Archive, as well as items that it may continue toreceive from the modalities.

__________________________________________________________________________
43
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Order
PlacerADT

Department System
Scheduler/ Order Filler

Image Manager/
Image Archive
PPS Manager

Acquisition
Modality n

Acquisition
Modality

Query Modality Worklist [RAD-5]
Modality Procedure
Step In Progress[CARD-1]
ModifyPatient
Patient Update
Merge [RAD-12]

Patient Update/
Merge [RAD-12]

Update Patientin Procedureand Steps

Modality Procedure
Step In Progress[CARD-1]
Modality Images/
Evidence Stored[CARD-2]

Perform
Acquisition

Update Patientin stored
objects
Query Modality Worklist [RAD-5]

Modality Procedure
Step In Progress[CARD-1]

Modality Procedure
Step In Progress [CARD-1]
New Patient Data
Modality Images/ Evidence Stored[CARD-2] New Patient Data
Modality Images/
Evidence Stored[CARD-2] Original
Patient Data

Perform
Acquisition

Perform
Acquisition

Update Patientin stored
objects

Figure 3.4-6. Patient Updated during procedure – Case C6

Significant Transactions:• The Modality may continue to send information using the original patient informationeven after the patient update has occurred.
• The Image Manager must continue to reconcile Patient Information even after the Patient
Update transaction has been completed.
Only partial transactions are shown. Other transactions are performed according to the otherprofile use case requirements.
3.4.7 Case C7: Change Rooms During Procedure
Clinical Context: It is not uncommon in the cath environment that it becomes necessary tochange the room in which the procedure is taking place. This may happen when a diagnostic caseturns into an interventional case, and the patient is moved to a room that is better suited to__________________________________________________________________________
44
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
performing interventions. It may also be required when there is an equipment failure in the
middle of a procedure, and the patient must be moved to a working room to complete the study.
Note:

There is a part of the clinical workflow where a patient is moved from the procedure room toa “holding area”, but information (typically vital signs and cardiac rhythms) is still being
monitored and recorded. This is outside the scope of the current IHE Cardiology Technical
Framework.

IHE Context: This case describes the process flow for halting a procedure in one room, with one
set of modality equipment, and resuming it in another room with different equipment. For
continuity of clinical data, it is critical that this be treated as a single Requested Procedure, i.e., ituses the same Study Instance UID.
The basic process is that each modality in the first room will issue a Modality Procedure Step
Completed or Discontinued. The DSS/OF through its scheduling functionality can reassign the
Requested Procedure to a new room, which will create Scheduled Procedure Steps for themodalities in the new room; those modalities can then restart the procedure using the Modality
Worklist information. In the event that the DSS/OF does not reschedule the Requested Procedure
to the new location, the modalities in the new room need to issue a broad Modality Worklist
query (not constrained to its own AE Title) to obtain the Scheduled Procedure Step for theoriginal room; they can then append a Modality Performed Procedure Step to that Scheduled Step.
Note that the absence of Modality Procedure Step Completed or Discontinued does not impact theability to continue in a new room. The Modality Procedure Step Completed or Discontinued fromthe modalities in the first room may be sent at any time, but are required from each modality tocomplete its Modality Procedure Step in Progress.
Note that there is no comparable case covered in the Radiology Technical Framework.

__________________________________________________________________________
45
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Department System
Scheduler/
Order Filler

Image
Manager/
PPS Manager

Acquisition
Modality
Room 1

Acquisition
Modality n
Room 1

Acquisition
Modality
Room 2Acquisition
Modality n
Room 2

Query Modality Worklist [RAD-5]
Modality Procedure
Step In Progress [CARD-1]

Modality Procedure
Step In Progress [CARD-1]

Perform
Acquisition

UpdateSchedule
Query Modality Worklist [RAD-5]

Reassign
Procedure

Modality Procedure
Step In Progress [CARD-1]

Modality Procedure
Step In Progress [CARD-1]

Modality Procedure
Step Discontinued [RAD-7]

Modality Procedure
Step Discontinued [RAD-7]

Perform
Acquisition

Query Modality Worklist [RAD-5]
Modality Procedure
Step In Progress [CARD-1]

Modality Procedure
Step In Progress [CARD-1]

Modality Procedure
Step In Progress [CARD-1]

Modality Procedure
Step In Progress [CARD-1]

Perform
Acquisition

Query Modality Worklist [RAD-5]
Perform
Acquisition

Figure 3.4-7. Change Rooms During Procedure – Case C7

Only partial transactions are shown. Other transactions are performed according to the otherprofile use case requirements, in particular, Modality Images/Evidence Stored and Storage
Commitment.
3.4.8 Case C8: Cancel Procedure
Clinical Context: When a cath procedure is cancelled, it is important for the information systems
to keep track of the cancellation to be able to respond to queries that the cath lab personnel willcontinue to receive regarding that patient.
IHE Context: This case describes the process flow for canceling a cath procedure prior to its
start. The procedure is ordered either by the Order Placer system, or by the DSS/OF, as shown in
Figure 3.4-8. The DSS/OF assigns the Requested Procedure ID and Study Instance UID,
schedules the procedure, and notifies the Image Manger.
If the procedure is cancelled in the department, the DSS/OF notifies the Order Placer system andthe Image Manger. All three systems - DSS/OF, Order Placer, and Image Manger – may maintain
information about the cancelled Order and Requested Procedure for an implementation- or
institutionally-determined length of time.
__________________________________________________________________________
46
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Order
PlacerADT

Department System
Scheduler/ Order Filler

Image
Manager

Register/
Admit
Patient
Patient
Registration [RAD-1]

Create Order
One or theothermethods ofcreating anorder isused

Placer Order Mgmt New [RAD-2]
Filler OrderManagement New [RAD-3]

Schedule
Procedure
Procedure
Scheduled [RAD-4]

Filler OrderManagement Cancel [RAD-3]

Cancel
Procedure
Procedure
Updated [RAD-13]

Figure 3.4-8. Cancel Procedure – Case C8

3.4.9 Case C9: Post-procedure evidence creation
Clinical Context: After a cath procedure is performed, the imaging and other procedure data isoften analyzed using specialized software. This analysis provides quantitative measurements ofthe coronary arteries and/or ventricles, coronary tree and intervention documentation, andpotentially additional derived images highlighting the findings. This does not include the use of acore lab for clinical trial or outcomes analysis, where the evidence produced is not returned to theclinical environment.
IHE Context: This case describes the process flow for post-procedure analysis of the cathimaging data (angiographic or ultrasound). The analysis is performed at a station that groups the
Image Display and Evidence Creator actors, as shown in Figure 3.4-9. The analysis station (Image
Display actor) retrieves the images to be analyzed from the Image Manger/Image Archive. The
actors participate in both the Cath Profile and the Evidence Documents Profile.
When the analysis is performed, the station (Evidence Creator actor) notifies the Image
Manger/Image Archive and the Department System Scheduler/Order Filler of the activity throughthe Modality Performed Procedure Step In Progress and Complete transactions. The Evidence
Creator stores any measurements or derived images to the Image Manager/Image Archive, andcommits them using the Storage Commitment transaction.
__________________________________________________________________________
47
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Another Image Display actor may query the Image Manager for evidence documents. For
documents stored as DICOM SR objects, the Query Evidence transaction allows the Image
Display to request, and the Image Manager to provide, the document titles, status, and otherattributes. The Image Display may retrieve and display the evidence documents.
Department System
Scheduler/
Order Filler

Image
Manager/
PPS Manager

Image Display/
Evidence Creator

Image Display

Query Images[RAD-14]Retrieve Images/Evidence[CARD-4]
Modality Procedure
Step In Progress[CARD-1]

Modality Procedure
Step In Progress[CARD-1]
Modality Images/
Evidence Stored[CARD-2]

Perform
Analysis

Storage Commitment[CARD-3]
Modality Procedure
Step Completed[RAD-7]

Modality Procedure
Step Completed[RAD-7]
Query Images [RAD-14]
Query Evidence [RAD-44]
Retrieve Images/Evidence [CARD-4]

Figure 3.4-9. Post-procedure evidence creation – Case C9

Notes: 1. While the Evidence Creator may not be a modality, it can still use the MPPS transactions
indicating an appended procedure step for the modality of the images. The Evidence Creator
may use the referenced Scheduled Procedure Step information in the analyzed images as thereferenced SPS for the evidence documents created. This keeps the workflow consistent withthe case of analysis performed on the original acquisition modality.
2. This profile does not specify the workflow transaction or trigger that causes the analysis
station to perform its work. The workflow may be managed using the Post-Processing
Workflow (PWF) Profile (see RAD-TF 1:12). The IHE Cardiology Technical Committee has__________________________________________________________________________
48
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
not evaluated the appropriateness of the PWF Profile for the Cardiology domain, but this may
be the subject of a future recommendation.
3. Support for the Query Evidence transaction is part of the Evidence Documents Profile. If
either actor does not support it, the Image Display will only be able to present to the user a listof SR Documents differentiated by document instance number and date/time as provided in
the Query Images transaction. In this event, the Image Display may achieve the same effectas the Query Evidence transaction by retrieving all the SR documents and extracting fromthem the relevant attributes for display in the query user interface.

3.4.10 Case C10: EP Ablation / Implantation Lab
Clinical Context: The Cardiac Cath workflow is also applicable to the multi-modality
electrophysiology laboratory. Programmers for implantable devices and device-generated data
will be addressed in a separate profile.
In electrophysiology laboratory ablation procedures, specialized catheters are placed into the heart
to identify and eliminate sources for arrhythmia. The EP lab is also used to implant and adjust
cardiac rhythm control devices (pacemakers, cardioverter-defibrillators, and cardiac
resynchronization therapy devices).
The EP lab is a multi-modality mix of many types of equipment from many different
manufacturers; as many as eight systems from different manufacturers may typically participate ina procedure. In current practice, these systems are unconnected islands, each managing its pieceof the patient clinical record. Integration of this data would result in increases in efficiency and areduction of medical errors.
Increases in efficiency are especially critical due to the rapidly increasing demand for EP
procedures and devices, and the limited availability of trained clinical professionals in the field.
For an ablation procedure, the patient is brought to the electrophysiology laboratory and thepatient’s demographic data is separately entered into the EP recording system, the fluoroscopy
system, the intracardiac echocardiographic system, and any specialized mapping systems that will
be required for the procedure. Data from the medical record such as allergies and laboratory
values are frequently reentered into the procedural record to document that the information has
been “reviewed.”
A wide array of specialized equipment is used during an ablation procedure; data is acquired fromeach of these systems independently without any time synchronization, and any documentation ofsimultaneous acquisition of information from various pieces of equipment must be enteredmanually in the procedural record. During the procedure, review of data must be evaluated oneach individual piece of equipment. For example, if an important event occurred at time X:XX,
data from the recording equipment, imaging equipment, and mapping equipment must be queued
for display separately to X:XX and reviewed sequentially. Finally, raw data from each system isstored in a variety of formats (optical disc, hard drive, tape) and stored near the electrophysiology
laboratory. However, a summary of discrete data from the procedure (usually paper) is kept in a
separate document in the hospital and is often not part of the medical record.
__________________________________________________________________________
49
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
To summarize, for the simplest electrophysiologic/ablation studies, current hospital information
systems will typically generate a paper copy of the dictated report, a paper copy of important
hemodynamic or electrophysiologic data, an optical disc of electrophysiologic data, a disc offluoroscopic data, and a disc of echocardiographic imaging data.
IHE Context: For the initial implementation of the EP workflow, the CATH profile includes thisspecial use case to address the workflow in the EP Lab. Given the similarities between the CATH
and EP workflows, the process flow diagrams for use cases C1-C9 defined for CATH are also
applicable to EP. The emergency use cases C3 and C5 however, are highly unusual in the EP
workflow.
The following systems are typical Acquisition Modality Actors for this use case:•EP recording system•

EP logging system•

Mapping system•

X-ray angiography/fluoroscopy•

Intracardiac echo•

There are other modalities that may be involved during the EP procedure that will beequally applicable to this workflow.

It should be noted that the EP lab acquisition devices are managed by separate Scheduled
Procedure Steps within the process flows described in cases C1-C9. These SPSs provide patient
demographics and eliminate multiple entry of patient data. All acquired data is consistently timestamped (in accordance with the Consistent Time profile) and stored in the Image Manager/Image
Archive for review on multi-modality Image Display actors. A procedure log containing asummary of events and key measurements may be included in the study data set.

__________________________________________________________________________
50
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

4 Echocardiography Workflow (ECHO)The Echocardiography Workflow Integration Profile describes the workflow associated withdigital echocardiography, specifically that of transthoracic echo (TTE), transesophageal echo(TEE), and stress echo. As does the Cath Workflow Integration Profile, this profile deals withpatient identifiers, orders, scheduling, status reporting, multi-stage exams (especially stress echo),and data storage. It also specifically addresses the issues of acquisition modality devices that are
only intermittently connected to the network, such as portable echo machines, and addresses
echo-specific data requirements.
The Echo workflow is focused on the imaging acquisition process, and image-based
measurements made either on the modality or on an independent workstation. Items not included
would be nursing notes, drug administration documentation, etc. The TEE, TTE, and stress echo
workflows are treated identically for the purposes of workflow control.
Intravascular ultrasound (IVUS) and intracardiac echocardiography (ICE) are used in cardiac
catheterization procedures, and are supported as modalities in the Cath Workflow, and not in the
Echo Workflow.
Note that there is no DICOM standard for 4-D ultrasound, so that is not addressed in this profile.
This profile has much in common with the IHE Radiology Scheduled Workflow, Patient
Information Reconciliation, and Evidence Documents Integration Profiles. See Rad TF-1: 3.4 forthe integrated workflow data model adopted by the IHE Technical Framework for HL7 messages
and DICOM information objects. This data model offers three major levels of control for
workflow:• Order: A request for a Departmental Service• Requested Procedure: Unit of work resulting in one or more reports with associatedcodified, billable acts.
• Scheduled and Performed Procedure Step: the smallest unit of work in theworkflow that is scheduled (work to do) or performed (work done).
A clear understanding of the workflow data model is essential to interpreting the Echo Workflow
Integration Profile.

__________________________________________________________________________
51
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

4.1 Actors/Transactions
Figure 4.1-1 diagrams the actors involved with this profile and the transactions between actors.

ADT

Pt. Registration [RAD-1] ↓Patient Update [RAD-12] ↓DSS/ Order Filler↓ Pt. Registration [RAD-1]↓ Patient Update [RAD-12]← Placer Order Management [RAD-2]→ Filler Order Management [RAD-3]↑ Modality PS in Progress [CARD-1]↑ Modality PS Completed [RAD-7]

Order Placer↓ Procedure Scheduled [RAD-4]↓ Patient Update [RAD-12]↓ Procedure Updated [RAD-13]↑ Instance Availability Notification [RAD-49]
Evidence
Creator← Modality PS in Progress [CARD-1]← Modality PS Completed [RAD-7]
Storage ↓Commitment[CARD-3]

Performed
Procedure
Step Manager

Image Display↓ Modality Image/EvidenceStored [CARD-2]

Image
Manager↓ Query Images [RAD-14]↓ Retrieve Images/Evidence [CARD-4]

Image
Archive→ Modality PS in Progress [CARD-1]→ Modality PS Completed [RAD-7]
StorageCommitment ↑[CARD-3]↑Modality Image/EvidenceStored [CARD-2]← Modality PS in Progress [CARD-1]← Modality PS Completed [RAD-7]
Acquisition
Modality← Query Modality Worklist [RAD-5]

Figure 4.1-1. Echocardiography Workflow Diagram

Table 4.1-1 lists the transactions for each actor directly involved in the Echocardiography
Workflow Integration Profile. In order to claim support of this Integration Profile, animplementation must perform the required transactions (labeled “R”). Transactions labeled “O”
are optional. A complete list of options defined by this Integration Profile that implementations
may choose to support is listed in Section 4.2.
Table 4.1-1. Echocardiography Workflow - Actors and Transactions
ActorsTransactions

Optionality

SectionR

RAD-TF 2: 4.1

ADT Patient
Registration

Patient Registration [RAD-1]
Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Order Placer

Patient Registration [RAD-1]

R

RAD-TF 2: 4.1

Patient Update [RAD-12]

R

RAD-TF 2: 4.12__________________________________________________________________________
52
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
ActorsDepartment System
Scheduler/
Order Filler

Acquisition
Modality

Image Manager/
Image Archive

Optionality

SectionPlacer Order Management [RAD-2]

Transactions

R

RAD-TF 2: 4.2

Filler Order Management [RAD-3]

R

RAD-TF 2: 4.3

Patient Registration [RAD-1]

R

RAD-TF 2: 4.1

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Placer Order Management [RAD-2]

R

RAD-TF 2: 4.2

Filler Order Management [RAD-3]

R

RAD-TF 2: 4.3

Procedure Scheduled [RAD-4]

R

RAD-TF 2: 4.4

Query Modality Worklist [RAD-5]

R

RAD-TF 2: 4.5

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Procedure Updated [RAD-13]

R

RAD-TF 2: 4.13

Instance Availability Notification [RAD-49]

O

RAD-TF 3: 4.49

Query Modality Worklist [RAD-5]

R

RAD-TF 2: 4.5

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Modality Images/Evidence Stored [CARD-2]

R

CARD-TF 2: 4.2

Storage Commitment [CARD-3]

R

CARD-TF 2: 4.3

Procedure Scheduled [RAD-4]

R

RAD-TF 2: 4.4

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Modality Images/Evidence Stored [CARD-2]

R

CARD-TF 2: 4.2

Storage Commitment [CARD-3]

R

CARD-TF 2: 4.3

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Procedure Updated [RAD-13]

R

RAD-TF 2: 4.13

Query Images [RAD-14]

R

RAD-TF 2: 4.14

Retrieve Images/Evidence [CARD-4]

R

CARD-TF 2: 4.4

Instance Availability Notification [RAD-49]

O

RAD-TF 3: 4.49

Performed
Procedure Step
Manager

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Image Display

Query Images [RAD-14]

R

RAD-TF 2: 4.14

Retrieve Images/Evidence [CARD-4]

R

CARD-TF 2: 4.4

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Modality Images/Evidence Stored [CARD-2]

R

CARD-TF 2: 4.2

Storage Commitment [CARD-3]

R

CARD-TF 2: 4.3

Evidence Creator

Refer to Table 2-1 for other profiles that may be pre-requisites for this profile.

__________________________________________________________________________
53
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

4.2 Echocardiography Workflow Integration Profile Options
Many Actors have Options defined in order to accommodate variations in use across domains orimplementations. Options that may be selected for this Integration Profile are listed in the table
4.2-1 along with the Actors to which they apply. Certain of these Options are required for
implementation by actors in this Profile (although they may be truly optional in other Profiles).
Table 4.2-1: Echocardiography Workflow - Actors and Options
Actor
ADT Patient Registration

Option Name
No options defined

Optionality

Vol & Section--

Order Placer

No options defined--

Department System
Scheduler/Order Filler

PPS Exception Management

O

RAD-TF 2: 4.7

Availability of PPS-Referenced InstancesO

RAD-TF 3: 4.49

Acquisition Modality

Patient Based Worklist QueryO

RAD-TF 2: 4.5

Broad Worklist QueryR

RAD-TF 2: 4.5

Stress EchoO

CARD-TF 2: 4.2

PPS Exception Management

O

RAD-TF 2: 4.7

PPS Exception Management

O

RAD-TF 2: 4.7

Echocardiography

R

CARD-TF 2: 4.2

Intermittently Connected Modality

R

CARD-TF 2: 4.3

Availability of PPS-Referenced InstancesO

RAD-TF 3: 4.49

Image Display

Stress EchoR

CARD-TF 2: 4.4

Performed Procedure Step
Manager

No options defined--

Evidence Creator

No options defined--

Image Manager/ Image
Archive

The Acquisition Modality and Image Manager/ Image Archive will likely support a variety of
DICOM SOP Classes. It is expected that this level of optionality will be documented by areference in the IHE Integration Statement (see Appendix C).

4.3 Echocardiography Workflow Process Flow
The process and information flow for echocardiography procedures generally follows the same
flow as the Cath Workflow Profile (see sections 3.3 and 3.4). The special use cases for the Echo
Workflow Profile are described here.
Clinical Context: Three variations of echocardiography are considered in this version of the IHE
Cardiology Technical Framework:
1.
Transthoracic Echocardiography (TTE): In the United States, TTE images are usuallyacquired by sonographers and reviewed off-line by cardiologists (this model varies in other__________________________________________________________________________
54
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
countries). The studies may be performed on patients who are brought to the Echocardiography
Department, or on patients in their hospital beds using a mobile ultrasound machine (cart).
Studies are frequently requested (verbally) but not electronically ordered by the time thesonographer gets to the bedside. Procedures on unregistered patients may be required inemergency situations.
2.
Transesophageal Echocardiography (TEE): Cardiologists perform transesophageal
echoes (TEE), as it involves sedating the patient and passing the echo probe down the esophagus.
It is less likely that the procedure would be performed on an emergency basis on unregisteredpatients, but this may occur. Resource management is more extensive than a simple imaging
study, and includes staff, room, and equipment. Evidence gathered during a TEE includes
information about the procedure, and not just the echocardiographic images.
3.
Stress Echocardiography (“Stress Echo”): This study is performed to observe the effectof stress (exercise or pharmacologic challenge) on the performance of the heart muscle. The
studies are generally scheduled, and unlikely to be performed on an emergency basis. The
evidence gathered for stress echocardiograms includes information about the stress used on thepatient (exercise or pharmacologic), and information about the patient’s response to the stress(blood pressure, heart rate, symptoms, ECG changes, etc.). Like TEE, resource management ismore extensive than for simple imaging.
In all of these scenarios, the carts (especially the mobile ones) may be disconnected from the
network for significant periods of time.
There are six specific Use Cases defined for Echo Workflow. The variations occur based onwhether or not and where a patient is registered, as well as whether or not and where an order isplaced. These variations are listed in Table 4.3-1. The last use case, E6: Stress Echo, is notshown in the Table.
Table 4.3-1. Echo Workflow Cases
Order
Placement

Order Placed
and Scheduled

Order Placed
and Scheduled, butschedule notobtained byModality

Order Not Placed,
Not Scheduled

Case E3 (mobile)

Case E4 (mobile)

Not Applicable - theOrder Placer/Order
Filler requires patientregistration

Not Applicable - theOrder Placer/Order
Filler requires patientregistration

Case E5 (mobile)

Case E1

Case E1

Case E1

Patient
Registration(see note)

Patient Registered at
ADT

Case E1

Patient Unregistered

Case E2 (mobile)

Patient Updated

Note:

Order Placement may be done in the Order Placer System or the DSS/Order Filler (using theOrder Filler Management transaction)__________________________________________________________________________
55
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
4.3.1 Case E1: Patient Registered at ADT and Procedure Ordered
Clinical Context: This corresponds to the more traditional Radiology Scheduled Workflow,where an order is placed in the Order Placer system or in the department system for a given echo
procedure. It also accounts for the special situation where an emergency identifier has beencreated for the patient (so that the patient is registered in the ADT and has been assigned a unique
identifier).
IHE Context: This case includes the full scheduled workflow when all three levels of control(order, requested procedure, and scheduled/performed procedure steps) in the IHE data model are
fully utilized to request a procedure (see section 3.3).
The patient may be registered at the ADT system as a known patient with complete
demographics, or with incomplete demographics, including the case of a totally unidentified
patient for whom only a Patient ID and a temporary name are assigned. To the subsequentsystems in the Echo Workflow, it is irrelevant to procedure performance whether or not thecomplete demographics are known. This case thus includes both identified and unidentified
patients, registered at the ADT system, for whom Orders are created at the Order Placer or
Department System Scheduler/Order Filler, and whose procedures are scheduled at the DSS/OF.
The Scheduled Procedure Steps are obtained by the modality through Query Modality Worklist,
the acquisition is performed and statused through Modality Performed Procedure Step.
For unidentified patients the ADT system is a single point of patient reconciliation in theenterprise. When the real patient identity is known, the ADT is responsible for reconciliation of
its own records, as well as informing the Order Placer and DSS/OF about corresponding changes.
The ADT sends a Patient Update message to both the Order Placer and DSS/OF. The DSS/OF
sends the Patient Update message to the Image Manager.

__________________________________________________________________________
56
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Department System
Scheduler/
Order Filler

Order
PlacerADT

ImageManager/
PPS Manager

Acquisition
Modality

Register J.Doe
Patient
Registration [RAD-1]

One or theother methodsof creating anorder is used

Placer OrderManagement–
New [RAD-2]
Filler OrderManagement New [RAD-3]

Schedule
Procedure
Procedure
Scheduled [RAD-4]
Query Modality Worklist [RAD-5]

Filler Order
Mgmt - Status
Update [RAD-3]

Patient Reconciliation
J.Doe ->
J.SmithFiller Order
Mgmt - Status
Update [RAD-3]

Patient Update/
Merge [RAD-12]

Modality Procedure
Step In Progress[CARD-1]

Modality Procedure
Step Completed[RAD-7]

Modality Procedure
Step In Progress[CARD-1]

Perform
Acquisition

Modality Procedure
Step Completed[RAD-7]

Patient Update/
Merge [RAD-12]

Figure 4.3-1. Patient Registered at ADT and Procedure Ordered – Cases E1/E2

Significant Transactions:• Patient Registration: The Patient Registration data is broadcast to several systems, including
the Order Placer and the Department System Scheduler/Order Filler (DSS/OF).
• Create Order: The Order Placer is the enterprise repository for all patient orders.
• Schedule Procedure: The DSS/OF associates the order with one or more Requested
Procedures that have to be performed to satisfy the order. Each Requested Procedure
prescribes a number of actions that have to be performed by Acquisition Modalities. Actions
are specified in Scheduled Procedure Steps (SPS) based on timing and sequencing, and on
modality. Scheduled Procedure Steps are scheduled, i.e., assigned a time slot and performing
resource (modality), and are made available for Modality Worklist Query.

__________________________________________________________________________
57
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
•
•
•
•
•
•

Query Modality Worklist: The Modality Worklist (MWL) query may be broad (get a list ofscheduled procedures from which one will be selected), or patient-specific (provided with
sufficient query keys to get back the scheduled procedure for a single patient).
Perform Acquisition: The Modality may produce a variety of images and other evidence(analysis reports, etc.) that are stored to the Image Manager/Archive. The ImageManager/Archive must support all these object types beyond just images.
Modality Procedure Step Complete: Modality Procedure Step Complete also includes
Modality Procedure Step Discontinued.
Storage Commitment: The Image Manager/Archive accepts responsibility for stored images
and evidence, allowing the modality to delete the data from its local storage.
Filler Order Management - Status Update: Status Update transactions may be sent to theOrder Placer at several points in the workflow, specifically after the first Modality Procedure
Step in Progress, and after completion of the procedure (e.g., when the report is signed).
Patient Reconciliation: To reconcile the patient information for an unidentified patient, theADT may register a new patient and merge the temporary patient with the correct patient, andsend both Patient Registration [RAD-1] and Patient Update/Merge [RAD-12] transactions to
the Order Placer and DSS/OF. If a permanent Patient ID was initially assigned, then the ADT
may only send a Patient Update [RAD-12] transaction with proper information.

4.3.2 Case E2: Intermittently Connected Modality
Clinical Context: This use case covers a mobile workflow, typical of TTE and TEE, in which
the acquisition modality is only intermittently connected to the network, and hence to the otheractors in the workflow. Connectivity will typically be established at the beginning and end of ashift. For the purpose of this use case, the period of non-connectivity bounded by periods ofconnectivity constitutes a “shift”, regardless of the elapsed time period (several minutes, several
hours, or several days). “Intermittently connected” also covers the case of a modality being turned
off.
IHE Context: The Process Flow Diagram for this case is identical to Case E1, although thetiming of the transactions may be significantly different. At the beginning of a shift, the Query
Modality Worklist transaction will retrieve the list of procedure steps scheduled for the shift.
Once retrieved, the sonographer will take the modality mobile and perform the procedure steps
listed in the worklist.
When disconnected from the network, the Modality Procedure Step In Progress and Modality
Procedure Step Completed transactions cannot be sent. At the end of the shift when the machineis connected back to the network, the modality will send the MPPS messages for the activity ofthe shift. Similarly, the modality will send the Modality Images/Evidence Stored transactions forthe acquisitions of the shift, and the Storage Commitment request transactions for thoseacquisitions. The delay in sending these transactions is consistent with the normal operations of
the DSS/Order Filler and Image Manager/Archive under the IHE scheduled workflow profiles.
__________________________________________________________________________
58
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
During the time that the modality is mobile, the Image Manager will not be able to send Storage
Commitment response (N-Event Report) messages. An Intermittently Connected Modality option
is specified for the Image Manager, under which the Image Manager must queue N-Event Reportmessages if the modality is not connected. The modality opening an Association (message
channel) to the Image Manager shall serve as a trigger for the Image Manager to open a separate
Association to the Modality to send the queued N-Event Report messages. This option is required
for the Echo Workflow Profile.
See Figure 4.3-1 for the Process Flow Diagram.
Significant Transactions:••Though the Modality Procedure Step In Progress [CARD-1] will be sent, it is likely to besent immediately preceding the Modality Procedure Step Complete [RAD-7]
The Image Manager/Archive must support intermittently connected devices that may be
temporarily unable to receive Storage Commitment [CARD-3] messages.

4.3.3 Case E3: Intermittently Connected Modality with Ad Hoc Procedure, Patient
Registered, Scheduled Procedure
Clinical Context: This use case describes the situation in which the Modality is mobile (notconnected to the network), and during that mobile shift the sonographer has received notice toperform a procedure that was unscheduled at the time the worklist for the shift was downloaded(at the beginning of the shift). However, the procedure has been scheduled, but the modality
cannot query for that information since it is not connected to the network.
IHE Context: The Order may be created either at the Order Placer system, or at the DSS/OF, andis scheduled. Even though the procedure has been scheduled by the DSS/OF and is available for
the Query Modality Worklist transaction, the modality cannot perform this transaction because it
is not currently connected to the network (mobile). Because of this, the perspective of themodality is that the procedure is unscheduled. Therefore, the Patient ID and other demographics
must be manually entered at the modality. The modality must also create a Study Instance UID
for that study.
Due to the inability to obtain a worklist, when the modality reconnects to the network it sends an
MPPS In Progress message [CARD-1] without the Requested Procedure or Scheduled Procedure
Step information. This indicates to the DSS/OF that it is an unscheduled procedure. This willcause the DSS/OF to raise an exception for reconciliation (see RAD-TF 2:4.6.4.1.3). The
Patient/Order reconciliation includes obtaining the full patient demographics for the Patient ID
specified in the MPPS In Progress message. Procedure Reconciliation also includes matching the
Performed Procedure with an Order and Requested Procedure that is known to the DSS/OF. It is
likely that this will be a manual process.
The DSS/OF then sends a Status Update [RAD-3] indicating in-progress to the Order Placer.
__________________________________________________________________________
59
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Upon matching the Performed Procedure with the original Requested Procedure, the DSS/OF willcancel the original Procedure using the Procedure Update/Cancelled [RAD-13] with a status of"cancelled" to the Image Manager, and generate a new Procedure Scheduled [RAD-4] containing
the Study Instance UID from the MPPS In Progress message, and a Patient Update [RAD-12]
with the full patient demographics. The Image Manager/Archive uses the information from thePatient Update transaction to update the demographics in the objects that it has, or will receive,from the acquisition modality.
Eventually (e.g., after completion of the report), the DSS/OF sends a Status Update [RAD-3]
indicating completion to the Order Placer.
Department System
Scheduler/
Order Filler

Order
PlacerADT

ImageManager/
PPS Manager

Acquisition
Modality

Register J.Doe
Patient
Registration [RAD-1]

One or theother methodsof creating anorder is used

Placer OrderManagement–
New [RAD-2]
Filler OrderManagement New [RAD-3]

Schedule
Procedure
Procedure
Scheduled [RAD-4]
Modality Procedure
Step In Progress[CARD-1]
Modality Procedure
Step Completed[RAD-7]Filler Order
Mgmt - Status
Update [RAD-3]

Filler Order
Mgmt - Status
Update [RAD-3]

Perform
Acquisition
Modality Procedure
Step In Progress[CARD-1]
Modality Procedure
Step Completed[RAD-7]

Patient/Order
Reconciliation
Procedure Update Cancel [RAD-13]
Procedure
Scheduled [RAD-4]
Patient Update/
Merge [RAD-12]

Update Patientin stored
objects

Figure 4.3-2. Intermittently Connected Modality with Ad Hoc Procedure, Patient
Registered, Scheduled Procedure – Case E3__________________________________________________________________________
60
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Significant Transactions:− Procedure Update - Cancel [RAD-13] must be used to cancel the Procedure Scheduled
sent to the Image Manager, and a new Procedure Scheduled [RAD-4] sent with the Study
Instance UID used by the modality (see RAD-TF-2:4.13, table 4.13-2).
Only partial transactions are shown. Other transactions are performed according to the otherprofile use case requirements.
4.3.4 Case E4: Intermittently Connected Modality with Ad Hoc Procedure, Patient
Registered, Unscheduled Procedure
Clinical Context: This use case describes the situation in which the Modality is mobile (notconnected to the network), and during that mobile shift the sonographer has received notice toperform an emergent echo procedure for a patient that has been registered. This is not uncommon
in the emergency department.
IHE Context: This case is identical to other unscheduled procedure cases, e.g., in the radiology
Patient Information Reconciliation Profile.
As in Case E3, the Patient ID and other demographics must be manually entered at the modality.
The modality must also create a Study Instance UID for that study. When the modality reconnects
to the network, it sends an MPPS In Progress message [CARD-1] without the Requested
Procedure or Scheduled Procedure information. This indicates to the DSS/OF that it is anunscheduled procedure. This will cause the DSS/OF to raise an exception for reconciliation.
The Patient reconciliation includes correcting the patient demographics for the Patient ID
specified in the MPPS In Progress message. It is likely that this will be a semi-automatedprocess, since the Patient ID matches a registered patient. The DSS/OF then creates a New Orderfor the performed procedure, and sends it to the Order Placer, as well as a Status Update
indicating in-progress [RAD-3].
The DSS/OF will generate a Procedure Scheduled [RAD-4] containing the Study Instance UID
from the MPPS In Progress message, and a Patient Update [RAD-12] with the full patient
demographics. The Image Manager uses the information from the Patient Update transaction to
update the demographics in the objects that it has, or will receive, from the acquisition modality.

__________________________________________________________________________
61
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

ADT

Department System
Scheduler/
Order Filler

Order
PlacerImage
Manager/
PPS Manager

Acquisition
Modality

Register J.Doe
Perform
Acquisition

Patient
Registration [RAD-1]

Modality Procedure
Step In Progress[CARD-1]
Modality Procedure
Step Completed[RAD-7]Filler OrderManagement New [RAD-3]
Filler Order
Mgmt - Status
Update [RAD-3]

Patient
Reconciliation/
Order Creation

Procedure
Scheduled [RAD-4]
Patient Update/
Merge [RAD-12]

Filler Order
Mgmt - Status
Update [RAD-3]

Modality Procedure
Step In Progress[CARD-1]
Modality Procedure
Step Completed[RAD-7]

Update Patientin stored
objects

Figure 4.3-3. Intermittently Connected Modality with Ad Hoc Procedure, Patient
Registered, Unscheduled Procedure – Case E4

4.3.5 Case E5: Intermittently Connected Modality with Ad Hoc Procedure, Patient
Unregistered, Unscheduled Procedure
Clinical Context: This use case describes the situation in which the Modality is mobile (notconnected to the network), and the procedure is unscheduled and the patient is unidentified. This
scenario, though less common, is similar to case E4 with the exception that the patient isunregistered.
IHE Context: This case is identical to other unscheduled procedure cases, e.g., in the radiology
Patient Information Reconciliation Profile.
A temporary ID and name are entered at the Modality (not from a patient wristband, since thatwould be a valid ADT system Patient ID, and is covered in case E4). The Patient ID and nameare selected according to the locally defined rules; for example, selected from the predefined pool__________________________________________________________________________
62
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________of “Patient ID–patient name” pairs. The rules for selecting temporary Patient ID shall guarantee
its uniqueness within the scope of Department System Scheduler/Order Filler.
The modality must also create a Study Instance UID for that study. When the modality reconnects
to the network, it sends an MPPS In Progress message [CARD-1] without the Requested
Procedure or Scheduled Procedure information. This indicates to the DSS/OF that it is anunscheduled procedure. This will cause the DSS/OF to raise an exception for reconciliation.
When the patient is registered, the DSS/OF reconciles the patient registration with the local
identifiers, and sends a Patient Update to the Image Manager. The Image Manager uses theinformation from the Patient Update transaction to update the demographics in the objects that it
has, or will receive, from the acquisition modality.
The DSS/OF then creates a new order for the performed procedure, and sends it to the Order
Placer. The DSS/OF will then generate a Procedure Scheduled [RAD-4] containing the Study
Instance UID from the MPPS In Progress message. The Image Manager uses the informationfrom the Procedure Scheduled transaction to update the Order and Procedure information in theobjects.

ADT

Department System
Scheduler/
Order Filler

Order
PlacerImage
Manager/
PPS Manager

Acquisition
ModalityEnter J.Doe
Temp Patient ID

Modality Procedure
Step In Progress[CARD-1]
Modality Procedure
Step Completed[RAD-7]

Register J.Smith
Patient
Registration [RAD-1]
Filler OrderManagement New [RAD-3]

Filler Order
Mgmt - Status
Update [RAD-3]

Modality Procedure
Step In Progress[CARD-1]
Modality Procedure
Step Completed[RAD-7]

Perform
Acquisition

Patient
Reconciliation
J.Doe -> J.Smith
Patient Update/
Merge [RAD-12]
Procedure
Scheduled [RAD-4]
Update Patientin stored
objects

Figure 4.3-4. Intermittently Connected Modality with Ad Hoc Procedure, Patient
Unregistered, Unscheduled Procedure – Case E5__________________________________________________________________________
63
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

4.3.6 Case E6: Stress Echo Staged Protocol
Clinical Context: A “Staged Protocol Exam” acquires images in two or more distinct timeintervals called “Stages” with a consistent set of images called “Views” acquired during eachStage of the exam. A View is of a particular cross section of the anatomy acquired with a specificultrasound transducer position and orientation. During the acquisition of a Staged Protocol Exam,the modality may also acquire non-Protocol images at one or more Protocol Stages.
A common real-world example of an ultrasound Staged Protocol exam is a cardiac stress-echo
ultrasound exam. Images are acquired in distinct time intervals (Stages) of different levels ofstress and Views. Typically, stress is induced by means of patient exercise or medication.
Typical Stages for such an exam are baseline, mid-stress, peak-stress, and recovery. During thebaseline Stage the patient is at rest, prior to inducing stress through medication or exercise. At
mid-stress Stage the heart is under a moderate level of stress. During peak-stress Stage thepatient’s heart experiences maximum stress appropriate for the patient’s condition. Finally, during
the recovery Stage, the heart recovers because the source of stress is absent.
A typical stress exam goes through progressive stages until a clinical end-point is reached, such as
achieving a pre-determined heart rate or emergence of symptoms preventing the patient fromcontinuing (arrhythmia, hypotension, angina, fatigue, etc.). A procedure may be complete, eventhough fewer than the full number of planned stages have been acquired.
At each Stage an equivalent set of Views is acquired. Examples of typical Views are parasternal
long axis and parasternal short axis. Examination of wall motion between the corresponding
Views of different Stages may reveal ischemia of one or more regions (“segments”) of the
myocardium. These views need to be displayed in a clinically relevant manner, grouping selected
images by View and Stage.
IHE Context: This workflow is the same as in Cases E1 (for a network connected modality) or
E2 (for an intermittently connected modality).
The type of stress protocol is specified to the Acquisition Modality through the Scheduled
Protocol Code Sequence or the Scheduled Procedure Step Description of the Modality Worklist.
The Scheduled Protocol Code Sequence may use the codes specified in CARD-TF 2: 4.2.3, Table
4.2-3.
Within the “perform acquisition” activity, there are several stages, but these are typicallyconsidered part of the same Procedure Step (see figure 4.3-5). The final MPPS shall indicate
status Complete for all cases that reach a clinical end-point. A status of Discontinued may be used
for a technical failure that prevents reaching a clinical end-point.

__________________________________________________________________________
64
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Department System
Scheduler/
Order Filler

Image Manager/
Image Archive/
PPS Manager

Acquisition
Modality

Query Modality Worklist [RAD-5]

Modality Performed Step In
Progress [CARD-1]

Modality Performed Step
Completed/Discontinued[RAD-7]

Modality Performed Step In
Progress [CARD-1]

Modality Images/EvidenceStored [CARD-2]

AcquireStage
View

Modality Images/EvidenceStored [CARD-2]

Acquirenext
view

Modality Images/EvidenceStored [CARD-2]

Acquirenext
view

Modality Performed Step
Completed/Discontinued[RAD-7]

Figure 4.3-5. Stress Echo Staged Protocol – Case E6

4.3.7 Case E7: Echo measurement evidence creation
Clinical Context: During the echo procedure some measurements and analysis may be
performed on the acquiring ultrasound system. These measurements (e.g., systolic and diastolic
left ventricular diameters) and preliminary analysis (e.g., Regional Wall Motion Score) would betransferred with the images to the Image Manager. After the procedure is completed, theechocardiographer reviews the images along with the measurements and preliminary analysis
offline (not on the ultrasound system, but on a separate workstation), and uses this information tocreate the final report. During this report creation, the echocardiographer may disagree with somemeasurement or may wish to create additional measurements for the final report. This revised setof measurements is saved with the study data.
IHE Context: This case describes the process flow for echocardiography measurement
generation. Figure 4.3-6 shows the process mapped to IHE actors and transactions. This process
flow is similar to the CATH Profile Case C9. The actors participate in both the Echo Profile andthe Evidence Documents Profile.

__________________________________________________________________________
65
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________The process begins with images and preliminary measurements (evidence documents) being
acquired on the ultrasound system during the procedure. These images and measurements aresent to the Image Manager using the transaction Modality Images/Evidence Stored [CARD-2].
The measurements are stored as DICOM Structured Report objects.
After the procedure, the user at the reporting workstation (Image Display actor) queries andretrieves the images and preliminary measurements, which were stored from the acquisition
modality, for verification and possible update. For the documents stored as DICOM SR objects,
the Query Evidence transaction provides the Image Display actor with the ability to request the
document titles, status, and other attributes.
The reporting workstation (as an Evidence Creator actor) notifies the Image Manager/Image
Archive and the Department System Scheduler/Order Filler of its activity through the Modality
Performed Procedure Step “In Progress” and “Complete” transactions. The Evidence Creator
may create measurements, analysis, and derived images that are stored to the ImageManager/Image Archive, and commits them using the Storage Commitment transaction. If thereporting workstation creates revisions of the preliminary measurements, those are stored in a
new (different) DICOM SR object; the preliminary measurements object is referenced from thenew object.
Department System
Scheduler/
Order Filler

Image
Manager/
PPS Manager
Modality Images/
Evidence Stored[CARD-2]

Modality Procedure
Step Completed[RAD-7]

Modality Procedure
Step In Progress[CARD-1]

Image Display/
Evidence Creator

Acquisition
Modality

Image Display

Perform
Acquisition &Measurements

Modality Procedure
Step Completed[RAD-7]
Query Images [RAD-14]
Query Evidence [RAD-44]
Retrieve Images/Evidence [CARD-4]
Modality Procedure
Step In Progress [CARD-1]
Modality Images/ Evidence Stored [CARD-2]

Perform/Update
Measurements& Analysis

Storage Commitment [CARD-3]
Modality Procedure
Step Completed[RAD-7]

Modality Procedure
Step Completed [RAD-7]
Query Images [RAD-14]
Query Evidence [RAD-44]
Retrieve Images/Evidence [CARD-4]

Figure 4.3-6 Echo Measurement Evidence Creation– Case E7__________________________________________________________________________
66
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Notes: 1. While the Evidence Creator may not be a modality, it can still use the MPPS transactions
indicating an appended procedure step for the modality of the images. The Evidence Creator
may use the referenced Scheduled Procedure Step information in the analyzed images as thereferenced SPS for the evidence documents created. This keeps the workflow consistent withthe case of analysis performed on the original acquisition modality.
2. This profile does not specify the workflow transaction or trigger that causes the reporting
station to perform its work.
3. A reporting station that includes the Evidence Creator may also include grouped actors ofother Profiles, in particular the Report Creator actor of the SINR or DRPT Profiles.
4. Support for the Query Evidence transaction is part of the Evidence Documents Profile. If
either actor does not support it, the Image Display will only be able to present to the user a listof SR Documents differentiated only by document instance number and date/time as provided
in the Query Images transaction. In this event, the Image Display may achieve the same
effect as the Query Evidence transaction by retrieving all the SR documents and extractingfrom them the relevant attributes for display in the query user interface.

__________________________________________________________________________
67
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

5 Retrieve ECG for Display (ECG)
ECG documents, including waveforms, measurements, and interpretations, are often created andmanaged on ECG management systems to which cardiographs are connected. Broad access to the
ECG documents throughout the enterprise as well as outside the enterprise is facilitated by thisIntegration Profile.
The primary use case involves a Cardiologist interpreting a 12 lead ECG on an ECG management
system. The resulting report needs to be accessible not only within the Cardiology Department(e.g. in preparing a later Cath) and by clinicians such as those from the ICU, but also by referring
physicians or other cardiologists following the patients. The intended use is essentially to review
the report as well as the ECG waveforms at resolution comparable to that used for diagnosis.
This Integration Profile allows the display of this information without requiring specialized
cardiology software or workstations by using general purpose computer applications. Once
displayed, the system where this ECG document is displayed may simply discard the information.
It is not the role of the displaying system to manage or archive this information. If it is later
needed, it can be requested again using the same “reference” and it will be displayed again in thesame way as the first time. The primary goal is to offer a faithful representation of the waveforms
at “diagnostic quality”, including the measurements and interpretation.
This Integration Profile is intended primarily for retrieving resting 12-lead ECGs, but may also
retrieve ECG waveforms gathered during stress, Holter, and other diagnostic tests. This
Integration Profile only addresses ECGs that are already stored in an information system. It does
not address the process of ordering, acquiring, storing, or interpreting the ECGs. It also is notintended for highly dynamic information such as that used for patient monitoring.
Discussion of the combined use of this Profile with the ITI-TF Enterprise User Authentication
and Patient Identifier Cross-Reference Profiles can be found in ITI-TF-1: Appendix E.

5.1 Actors/Transactions
Figure 5.1-1 shows the actors directly involved in the ECG Integration Profile and the relevanttransactions between them.

Retrieve Specific Info for Display [ITI-11]
Retrieve ECG List [Card-5]

Information
SourceDisplay
Retrieve ECG Document for Display [Card-6]

Figure 5.1-1. Retrieve ECG for Display Actor Diagram__________________________________________________________________________
68
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Table 5.1-1 lists the transactions for each actor directly involved in the ECG Profile. In order toclaim support of this Integration Profile, an implementation must perform the required
transactions (labeled “R”). Transactions labeled “O” are optional.
Table 5.1-1 Retrieve ECG for Display Integration Profile - Actors and Transactions
Actors
Display

Information Source

Transactions

Optionality

Section in Vol. 2

Retrieve Specific Info for Display [ITI-11]

O

ITI-TF 2: 4.11

Retrieve ECG List [CARD-5]

O

CARD-TF 2: 4.5

Retrieve ECG Document for Display [CARD-6]

R

CARD-TF 2: 4.6

Retrieve Specific Info for Display [ITI-11]

R

ITI-TF 2: 4.11

Retrieve ECG List [CARD-5]

R

CARD-TF 2: 4.5

Retrieve ECG Document for Display [CARD-6]

R

CARD-TF 2: 4.6

5.2 ECG Integration Profile Options
Many Actors have Options defined in order to accommodate variations in use across domains orimplementations. Options that may be selected for this Integration Profile are listed in the table
5.2-1 along with the Actors to which they apply. Certain of these Options are required for
implementation by actors in this Profile (although they may be truly optional in other Profiles).
Table 5.2-1: ECG - Actors and Options
Actor

Option Name

Optionality

Vol & Section

Display

No options--

Information Source

Summary of All Reports

R

ITI-TF 2: 3.11

Summary of Cardiology Reports

R

ITI-TF 2: 3.11

All other options of Retrieve Specific Info for
Display [ITI-11]

O

ITI-TF 2: 3.11

5.3 ECG Integration Profile Process Flow
This section describes the process and information flow for display of ECG documents retrieved
from an information source.
5.3.1 Case D1: Simple Display
This case provides for basic display of a list of ECG documents, and/or display of a specific ECG
document. It includes two simple processes, which may or may not be linked together.

__________________________________________________________________________
69
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
The first process provides a method for a display actor (and the person associated) to retrieve alist of ECG documents for a specific Patient ID from an Information Source Actor. The patient ID
is assumed to be unambiguous as fully qualified with the assigning authority. A number of
additional filtering keys may be used (last N documents, date range, etc.). The Information Source
Actor responds with a list of ECG documents for display. The Display Actor simply displays theinformation to the person that triggered the request. The Information Source Actor shall respondwith an error message when it does not support the specific type of request or does not hold any
records for the requested patient ID. See Figure 5.3-1.
Display

Information
SourcePrepare ECG
Information for
Display

Information
not found orinformation
type notsupported

Retrieve Specific Info [ITI-11]
or Retrieve ECG List [CARD-5]

Request for
Information ona patient
Display
Information

Retrieve Specific Info [ITI-11]
or Retrieve ECG List [CARD-5]

Request for
Information ona patient
Display Error

Figure 5.3-1 Retrieve ECG List Process Flow

The Display Actor may request the ECG List using the Retrieve Specific Info [ITI-11] transaction
with request type SUMMARY or SUMMARY-CARDIOLOGY, or using the Retrieve ECG List
[CARD-5] transaction with request type SUMMARY-CARDIOLOGY-ECG. The ITI-11
transaction returns the response as HTML, and the CARD-5 returns the response as XML with astylesheet; the Display Actor may thus select its desired response format by specifying the request
type.
The second process provides a method for the Display Actor (and the person associated) torequest a uniquely identified ECG document. The Information Source Actor responds to therequest by using one of the formats proposed by the Display Actor to provide the presentationready content of the ECG document it manages. The detailed presentation and the clinicalintegrity of the content of the document are under the control of the Information Source Actor.
The Display Actor simply displays the presentation-ready document content to the person thattriggered the request. The Information Source Actor shall respond with an error message when therequested document is unknown or when none of the formats acceptable to the Display Actor issuitable to present the requested document. See Figure 5.3-2.
__________________________________________________________________________
70
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Information
SourceDisplay

PrepareSelected
ECG Document
for Display

Retrieve ECG Document
for Display [CARD-6]

Requested
Document does
not exist or
client proposed
formats notsupported

Retrieve ECG Document
for Display [CARD-6]

Request for
ECG Document
Display
ECG Document
Content

Request for
ECG Document
Display Error

Figure 5.3-2 Retrieve ECG Document Process Flow

The main difference between the Retrieve ECG List and the Retrieve ECG Document transactions
is that the latter applies to a uniquely identifiable persistent object (i.e. retrieving the same
document instance at a different point in time will provide the same semantics for its presented
content). For the Retrieve ECG List transaction, this information is always related to a wellidentified patient (Patient ID), but its content, although of a specific type (ECGs) is generally
dynamic (i.e., retrieving the same list at a different point in time is likely to result in different
content; for example, a new ECG may have been recorded for the patient between two requests).
The Retrieve ECG Document process is not necessarily linked to the Retrieve ECG List process;a Display Actor may receive a document identifier by some other means (e.g., as a reference inanother clinical document).
5.3.2 Case D2: Advanced Display
This case provides for retrieval of a list of ECG documents, coupled with display of one or more
specific ECG documents, potentially in a synchronized manner. The list is structured in a mannerthat may facilitate display applications for serial comparison of ECGs, a common clinicalrequirement. In this case the Retrieve ECG Document process is closely linked to the Retrieve
ECG List process.
This case includes the same processes as case D1. However, in this case the Retrieve ECG List
process is limited to the Retrieve ECG List [CARD-5] transaction, with a structured XML
response returned from the Information Source Actor. The Display Actor is able to parse this__________________________________________________________________________
71
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
structured list, and select specific entries for retrieval using the Retrieve ECG Document [CARD6] transaction. By having a computer-processable XML list, multiple documents can be retrievedfor display in a single synchronized display application.

__________________________________________________________________________
72
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

6 Displayable Reports (DRPT)
This section reserved.

__________________________________________________________________________
73
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

7 Evidence Documents (ED)The Evidence Documents Profile defines ways for data recorded in the course of carrying out aprocedure step, such as observations, measurements, and results (i.e., evidence documents), to be
output by devices, such as acquisition systems and other workstations; to be stored and managed
by archival systems; and to be retrieved and presented or used by display and reporting systems.
This allows detailed non-image information, such as measurements, CAD results, procedure logs,
etc. to be made available as input to the process of generating a clinical Report, either as
additional evidence for the reporting physician, or in some cases for selected items in the
Evidence Document to be included in the report.
The full specification of the Evidence Documents Profile is found in RAD-TF 1:14. This section
adds the cardiology-specific options for that definition.

7.1 Actors/Transactions
Figure 7.1-1 shows the actors directly involved in the Evidence Documents Profile and therelevant transactions between them.

Evidence Creator

RAD-10: Storage↓
Commitment

Image
ManagerRAD-10: Storage
Commitment ↑Image Display↓ RAD-43: Evidence
Documents Stored

ReportCreator↓ RAD-44: Query Evidence Documents↓ RAD-45: Retrieve Evidence Documents

Image
Archive

RAD-43: Evidence↑ Documents Stored

Acquisition Modality

Figure 7.1-1. Evidence Documents Actor Diagram
Note: The Evidence Documents Stored [RAD-43] and Retrieve Evidence Documents [RAD-45]
Transactions are equivalent to the Images/Evidence Stored [CARD-2] and Retrieve
Images/Evidence [CARD-4] Transactions defined in the Cardiology Technical Framework
Volume 2 for the purpose of specifying options. Future editions of the Cardiology Technical__________________________________________________________________________
74
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Framework will harmonize the identification of these Transactions with the Radiology
Technical Framework.

7.2 Evidence Documents Profile – Cardiology Options
The Options defined for the Cardiology domain that may be selected for this Integration Profile
are listed in the table 7.2-1 along with the Actors to which they apply.
Table 7.2-1 Evidence Documents - Actors and Options
Actor
Evidence Creator

Acquisition Modality

Options

Vol & Section

Cath Evidence

CARD-TF 2: 4.2.4

Echo Evidence

CARD-TF 2: 4.2.5

Cath Evidence

CARD-TF 2: 4.2.4

Echo Evidence

CARD-TF 2: 4.2.5

Image Manager/
Image Archive

No options defined-

Image Display

Cath Evidence

CARD-TF 2: 4.4.2(Report Creator)

Echo Evidence

CARD-TF 2: 4.4.3

7.3 Evidence Documents Process Flow
The use of Evidence Documents in process flows for cardiology is described in Cath Profile Use
Case C9, and in Echo Profile Use Case E7.

__________________________________________________________________________
75
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Appendix A:

The Cardiac Catheterization Procedure in Perspective

It is important to understand the scope of the part of the Cardiac Catheterization Procedure(“cath”) that is being addressed in the Cardiology Technical Framework, and to put that into
perspective with regards to a broader picture. The cath procedure itself occurs inside of a clinicalcontext wherein a patient has a clinical presentation, diagnostic and/or interventional proceduresare performed, and events of interest are monitored after the procedure itself has concluded.
Clinicians may use the terms such as “case,” “encounter,” or “admission” to refer to this broader
scope. To help avoid confusion with other standards documents and nomenclature, this Appendix
introduces the term “Episode of Care”.

ReportAmendedReport(optional)

Export toRegistry(optional)…
PreProcedure
Evaluation

AdmissiontoFacility

Diagnostic Intervention
PostProcedure(optional) Procedure
EventsEnd ofEpisodeEvent

Long-Term
Follow-Up

Addressed in Year 1

The clinical activities associated with Cardiac Catheterization are shown schematically above.
The evidence gathering activities may actually start hours, days or weeks ahead of time as thepatient is evaluated before the procedure. The cath procedure itself refers to the events that occur
in the cath lab suite itself (this might include a patient prep area, the x-ray room or rooms that areused for the procedures, and a holding area where the patient is monitored before leaving the cathlab suite). Evidence will continue to be gathered after the actual procedure has finished, which
would typically include the recording of complications (if any), and subsequent patient outcome.
At some point in time, there is an event (that may be site-specific) that indicates that the cardiac
cath Episode of Care has concluded. In its simplest form, this might be represented by thepatient’s discharge from the facility. Any evidence that is gathered relating to events after thatpoint in time is no longer added directly to the Set of Results associated with the Episode of Care.
In Year 1 of the IHE for Cardiology Technical Framework, we have defined activities that occur
between the patient’s admission to the cath lab facility and departure from the cath lab suite. In
subsequent years, the Technical Framework is expected to be extended to include the entire
Episode of Care. This will be particularly important as support for national data registries is
added, and as models are included for the reporting activities related to the Set of Results.

__________________________________________________________________________
76
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Appendix B: Challenges of Workflow Management in Cardiac
Catheterization
B.1 Clinical Context: Diagnostic and Interventional Procedures
In Radiology, clinicians order very specific studies after evaluation of the patient’s history,
physical findings, and the results of other studies. However, requests for a Cardiac
Catheterization are handled clinically in a very different fashion. The referring clinician typicallyrequests a Cardiology Consultation (or perhaps a more specific Cardiac Catheterization
Consultation). The exact procedure(s) to be performed are generally selected in thecatheterization laboratory itself, as the initial information is gathered. Clinical activities are
selected as deemed appropriate by the performing physician. Moreover, unlike Radiology, theselected activities (“protocols”) are more clinically oriented, as opposed to being modality
oriented. Thus the x-ray modality typically makes no distinction between imaging for Coronary
Angiography and for Left Ventriculography, since the x-ray techniques are identical.
For logistical and administrative purposes, procedures in the cardiac catheterization laboratory are
divided somewhat arbitrarily into “Diagnostic” and “Interventional”, despite the fact that thedemarcation line between the two categories may be indistinct. It is rare, however, that anordering physician would make the distinction ahead of time and specifically order one or theother, except in the case of an order for interventional follow-up to a diagnostic exam (e.g., due toresource limitations at the time of the diagnostic exam).

B.2 Organizing the Workflow: Requested Procedures and Procedure
Steps
In the past (pre-IHE), a common (but not universal) practice in the cath lab has been to create a
new DICOM Study for the x-ray angiography (XA) data when the activities move from
Diagnostic to Interventional. This is indicative of an administrative desire to identify a distinction
between those two phases in a cath procedure. This is a less than ideal method, but in thatenvironment the only available “hammer” for that “nail” was the DICOM XA Study.
However, IHE provides several tools for managing the workflow and organizing the data,
principally the Requested Procedures, Scheduled Procedure Steps (SPS), and Performed
Procedure Steps (PPS). Moreover, IHE address the full multi-modality context of the cath lab,
not just XA. This section describes the required use of these IHE constructs.
The IHE Technical Framework data model offers three major levels of control for workflow:• Order: A request for a Departmental Service• Requested Procedure: Unit of work resulting in one or more reports, with associatedcodified, billable acts.
• Scheduled and Performed Procedure Step: the smallest unit of work in theworkflow that is scheduled (work to do) or performed (work done).
__________________________________________________________________________
77
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
B.2.1 Orders
The Order is what the referring clinician requests from the cardiology department. As describedabove, it generally represents a request for the “Cardiac Catheterization Consultation”.
B.2.2 Requested Procedures
The Requested Procedure represents the unit of work that the department uses for clinical and/or
administrative purposes. This is the unit for which one or more reports will be written, and whose
completion will be reported externally, e.g., for billing purposes. Generally, there will be one
Requested Procedure for each Order, but the IHE data model allows a department to create two or
more Requested Procedures for an Order.
As discussed below (see B.7 The Approach Adopted by IHE Cardiology), IHE Cardiology
strongly advises the use of a single Requested Procedure for a cardiac catheterization procedure,
although some institutions may desire to separate diagnostic and interventional phases to two
separate Requested Procedures. The Technical Framework does not require a Department System
Scheduler/Order Filler to be able to create multiple Requested Procedures from a single Order;that is application capability beyond IHE’s scope of interoperability. Institutions that desire suchcapability must request it in addition to any IHE integration capability.
B.2.3 Scheduled and Performed Procedure Steps
The SPS and PPS are the smallest units of the workflow that are scheduled or performed, whose
status is tracked, and that are associated with protocols, i.e., specific actions, techniques,
equipment usage, etc. associated with a step of a procedure. Scheduled and Performed Procedure
Steps are modality-specific. Thus for a multi-modality Requested Procedure, there would be
separate Procedure Steps for each modality, and therefore there is a 1:n cardinality relationshipbetween a Requested Procedure and its Scheduled Procedure Steps.
The Scheduled Procedure Step is always what has been scheduled; what actually gets performed
is in the IHE data model a totally separate entity, the Performed Procedure Step. The SPS doesnot “become” a PPS; the SPS may continue to exist even after the clinical procedure is complete,and may persist until the report for the Requested Procedure has been finalized. The PPS
similarly has an independent existence, and in fact is conceptually “permanent”, representing thehistorical actuality of the procedure.
Because what is actually performed may differ from what was scheduled, the SPS and PPS have
an n:m (many-to-many) cardinality relationship. The IHE data model even allows a PPS to berelated to multiple SPSs in different Requested Procedures, although the Cath Profile does notallow that case (see B.6 Grouped Procedures). An entity relationship diagram showing the
cardinality relationships of the IHE data model is given in RAD-TF 1: 3.4.3.

__________________________________________________________________________
78
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
B.2.4 Clinical Protocols and Procedure Step Protocols
As described in B.1 above, there are protocols that represent the clinical activities of the cathprocedure. Table B.2-1 provides a sample list of Protocols for Diagnostic and Interventional
procedure steps.
Table B.2-1. Cath Clinical Protocols

Diagnostic
Left Heart Catheterization
Right Heart Catheterization
Coronary Angiography
Pulmonary Arteriography
Aortography
Renal Arteriography
Femoral Arteriography
Carotid Arteriography
Left Ventriculography
Right Ventriculography
Fluoroscopic evaluation of valve function
Intracardiac echocardiography
Intravascular ultrasound imaging
Interventional
Intracoronary thrombolysis
Balloon angioplasty
Stent deployment
Rotational atherectomy
Brachytherapy
ASD/VSD Closure
Valvuloplasty
Scheduled and Performed Procedure Steps are modality-specific, and their associated protocols
would similarly be modality-specific, rather than clinical procedure-related. Nevertheless, it ispossible for appropriate modalities to report protocols of Performed Procedure Steps that
distinguish between Diagnostic and Interventional procedure phases. The IHE Technical
Framework provides flexibility for the configuration of modality protocols to meet the desired
workstep status tracking for a user institution.
A real world example of the use of Procedure Step protocols can be demonstrated by a Requested
Procedure for a cardiac catheterization. For that Requested Procedure there will be at least one
procedure step scheduled for each modality, but there may be multiple procedure steps
representing separate Diagnostic and Interventional clinical phases for each modality. This could
result in the set of Scheduled Procedure Steps for the single Requested Procedure shown in Table
B.2-2.
__________________________________________________________________________
79
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Table B.2-2. Scheduled Procedure Step Example
SPS Number

Modality

1

HD

SPS Protocol
Diagnostic Heart Catheterization Hemodynamics

2

XA

Diagnostic Heart Catheterization Angiography

3

HD

Interventional Heart Catheterization Hemodynamics

4

XA

Interventional Heart Catheterization Angiography

5

IVUS

Interventional Heart Catheterization Intravascular UltrasoundNote that when the procedure is performed there are several possible combinations of Performed
Procedure Steps related to the Scheduled Procedure Steps. There may be one PPS for every SPS.
There may be no (zero) PPSs for some of the SPSs (e.g., the interventional phase was deemed notnecessary, or an IVUS was never performed). There may be one PPS for all the SPSs assigned toa modality (e.g., the hemodynamics system does not support separation of an exam into multiple
PPSs). Conversely, an Acquisition Modality could perform several PPSs for a single SPS (e.g.,
the XA system performs quantitative analysis on the images and reports that as a separate PPS
from the image acquisition).
It should be noted that all of the combinations of SPS:PPS must be handled by a Department
System Scheduler/Order Filler.

B.3 Multi-Modality and Ad Hoc Scheduling
The cardiac cath lab is inherently multi-modality (hemodynamics, x-ray, IVUS, etc.), andtherefore more prone to data entry errors and patient safety issues. It is critical that the exact
same patient is selected on all pieces of equipment. A goal of IHE is to have a single selection ofa patient on a single piece of equipment, and then ensuring that patient’s information is available
at all of the other pieces of equipment within the cath lab, thereby eliminating data entry errors.
This goal is further complicated by the frequent ad hoc assignment of rooms to specific patient
procedures to accommodate the large proportion of emergent cases. The specific lab to be used isoften not determined until the patient is wheeled into one.
The Department System Scheduler/ Order Filler (DSS/OF) is responsible for procedurescheduling. In the multi-modality cath lab, this means creating a Scheduled Procedure Step foreach modality that may participate in the procedure. When a particular room and time can be
assigned for a procedure, there is no problem with using the simple Modality Worklist
information model definition of an SPS that presumes a specific assigned resource; however, thisis seldom possible in the real world. And even when such scheduling can be done, it may beoverridden by an emergency case.
To accommodate ad hoc scheduling, the DSS/OF may therefore typically schedule a procedure
with an SPS for a “generic resource” that could be selected by the modality in any particularroom.
__________________________________________________________________________
80
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
To facilitate the single selection of a patient within the environment of generic resourcescheduling, the Technical Framework has specified a Multi-Modality Procedure Update functionof the DSS/OF. The DSS/OF shall be able to designate one or more modalities in each lab(typically the hemodynamics system) as a “selector”; that modality is expected to select thepatient in the lab by choosing a Modality Worklist SPS, and starting a PPS. When that modality
sends its first Modality Procedure Step In Progress for a particular Requested Procedure, the
DSS/OF schedules SPSs for that Requested Procedure (and patient) for all modalities in that lab.
The other modalities in that lab can then obtain coordinated patient and Requested Procedure
identifiers using the Query Modality Worklist transaction.
Note:

There may be a time delay between the Modality Procedure Step In Progress from the firstmodality and the availability of SPSs for the other modalities in the Modality Worklist. It is
expected that this delay would measured in seconds or minutes, not hours. In the cath lab,there is typically a delay between the first modality’s MPPS and that of the other modalities,
usually sufficient to accommodate the delay in the DSS/OF. However, for clinical reasons,the other modalities may need to start their data acquisition without waiting for the Study
Instance UID provided in the Modality Worklist, and will therefore use a different Study
Instance UID. It is highly desirable to avoid the proliferation of Study Instance UIDs in asingle procedure. This version of the IHE Cardiology Technical Framework does not deal
with reconciliation of multiple Study Instance UIDs.

B.3.1 Unscheduled Case
The need for consistent patient and Requested Procedure identifiers is just as important, if not
more so, in the Unscheduled Case, where there is no available Requested Procedure to be sharedacross the multiple modalities (see cath use cases C3 and C5).
The Technical Framework requires that the Multi-Modality Procedure Update function of the
DSS/OF also includes an automatic creation of a Requested Procedure if the MPPS from theselector modality is unscheduled. Creation of this Requested Procedure is a necessary
prerequisite for the creation of the SPSs for all modalities in the lab.
As noted above, the Requested Procedure generally represents the unspecialized “Cardiac
Catheterization Consultation”. It is possible, therefore, to have a default Procedure type (codeand/or description) that may be used to auto-create the Requested Procedure. The DSS/OF may
also be able to select an appropriate Procedure type from a set, based on attributes such as
protocol in the received MPPS.
This approach differs somewhat from the approach in the Radiology Technical Framework. RADTF 2: 4.6.4.1.3 states:
If the Requested Procedure ID is transmitted empty (Unscheduled Performed Procedure
Step case), the Department System Scheduler/Order Filler and the Image Manager shallcreate an exception that must be manually resolved to link the Performed Procedure Step
to the appropriate procedure.
The Radiology Technical Framework intent is to force eventual reconciliation to associate the
PPS with an appropriate Requested Procedure.
__________________________________________________________________________
81
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
The fact that the Cardiology Technical Framework uses this condition as a trigger for the DSS/OF
to automatically create a Requested Procedure (and the multi-modality Scheduled Procedure
Steps) contradicts the letter of the radiology framework (i.e., manual reconciliation), but not theintent (i.e., reconciliation of the unscheduled PPS with a Requested Procedure).
It is the opinion of the Cardiology Technical Committee that the difference in approach between
Radiology and Cardiology Technical Frameworks does not represent a significant deviation inrequired or intended usage of the MPPS In Progress transaction, and that the Multi-Modality
Procedure Update option sufficiently characterizes the necessary functionality.

B.4

Modality Procedure Step Complete/Discontinue

This Technical Framework requires each modality in the multi-modality cath lab to individually
select an SPS from the Modality Worklist to start its PPS/acquisition. Likewise, each modality
must complete or discontinue any PPSs it has started.
The same functionality that facilitates single patient selection for all modalities, also facilitates
incorrect single patient selection. If the patient selection is incorrect on the initial piece ofequipment, the patient will be incorrect on all the modalities in the cath lab that have used SPSs
based on that initial selection. It is then crucial to “discontinue” that patient on all cathmodalities, thereby reducing misidentification errors.
Note:This version of the IHE Cardiology Technical Framework does not define a mechanism forcompletion or discontinuation of all in-progress MPPSs in the multi-modality lab with asingle user action; MPPSs must be completed individually at each modality.

B.5 Start and End Procedures
The Cardiac Cath Workflow Profile focuses on the workflow within the lab itself. However,given the interventional nature of cath, this Profile cannot ignore the immediate pre- and postcatheterization activities that occur within the cath lab suite. The cardiac cath lab environment
poses challenges due to its multi-modality nature discussed above, but also to its multi-location
nature – a single cath procedure may transition across as many as four different rooms, each with
its own equipment (a procedure preparation area, a diagnostic lab, an interventional lab, and arecovery holding area).
Pre-cath activities can include gathering critical lab information in advance, verifying theexistence of all blood analysis and other results necessary prior to beginning a cath procedure, lab
set up, notification of patient arrival, discussions with and signatures from patient, collection ofpatient vital signs, etc. Post-procedure activities include monitoring the patient for adverse
events, completing the exams on all equipment, cleaning the room, canceling procedure steps
which were not actually completed, etc. The Cath Workflow Profile cannot account for all ofthese activities, but does recognize that they exist.
For that reason there may be an optional “Start Procedure” function on the DSS/OF for the Cath
Workflow. Specifically, the Start Procedure function can provide the advantages of:__________________________________________________________________________
82
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________− Registering patient arrival to set the status (0040,0020) in the associated SPSs
− Using patient arrival status to reduce the worklist for broad queries provided to the labs
(when an individual room/suite assignment has not been made)− Ensuring that all pre-procedure information which is gathered will be accurately combinedwith the procedure information from the lab− Specify the lab/suite where the procedure will take place, which in turn, may simplify theselection the same patient on all equipment within a suite (a potential patient safety
feature)The corresponding optional “End Procedure” function on the DSS/OF can provide the advantagesof :− Verify the exam was manually completed on each piece of equipment.
− Cancel all SPSs for the Requested Procedure which, in turn, may help signify that theroom is no longer occupied (and even possibly indicate ready for cleaning or other postprocedure activities)− Trigger sending an Order Status Update message to the Order Placer
For these reasons, the DSS/OF internal Start Procedure and End Procedure functions are includedin the Cath Workflow Use Cases, and it is highly recommended that such functionality besupported in DSS/OF implementations..

B.6 Grouped Procedures
B.6.1 What are Grouped Procedures?
Grouped procedures are described in the IHE Radiology Technical Framework (RAD-TF-1:4.6).
The Grouped Procedure case provides a mechanism for facilitating workflow when an operator
combines the acquisition steps of two or more separate Requested Procedures, often for the sakeof acquisition efficiency and patient comfort. Viewing images and reporting, however, must still
be done on the individual Requested Procedures. Through the Grouped Procedure, a single
acquired image set (Study) is produced, but the workflow transactions allow separate viewing andinterpretation of the image subsets related to each of the Requested Procedures.
Grouped procedures in IHE Radiology are confined to a single modality, e.g., CT head and spine.
Each Modality Performed Procedure Step (MPPS) is related to multiple Scheduled Procedure
Steps (SPSs) and Requested Procedures.
One of the issues with Grouped Procedures is the identification of the Requested Procedures inrelation to the “performed Study”. DICOM identifies Requested Procedures by Study Instance
UID, and typically the images produced are stored under that same Study UID. In the Groupedcase, this is not possible, since there are multiple Requested Procedures.

__________________________________________________________________________
83
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________In the classic, single-modality Grouped case, study UIDs are relatively straightforward. Each
Requested Procedure (RP) identifies its own Order Filler-specified Study Instance UID. The
modality selects the multiple Scheduled Procedure Steps (SPSs) associated with the various RPs.
As there are multiple RP study UIDs referenced, the modality creates its own “I-Study” Study
Instance UID to store the images/evidence associated with the Grouped procedures acquisition(MPPS). Now all the images/evidence associated with the acquisition are contained under the
single “I-Study” UID, but this contains references to the multiple RP Study UIDs. (See RAD-TF2, Appendix A for further description of the Data Model used in Grouped cases.)
B.6.2 Why Grouped Case is a Problem with Multimodality Studies
Cardiac catheterization is also a natural candidate for grouped procedures; there are typicallymultiple procedures which should be billed and reported separately (i.e., the diagnostic andinterventional phases of the catheterization), but which share equipment, and for patient safety
and efficiency the procedures are performed together.
However, cardiac catheterization is a multi-modality process by nature, and this brings
complications to the classic grouped procedure approach outlined previously.
In the classic case, each modality creates its own I-Study UID to store the images/evidence it
creates in a Grouped case. But I-Study UIDs are (by definition) unique per modality, thus in a
multi-modality procedure the images/evidence relating to the procedure would be scattered acrossmultiple I-Study UIDs, one per modality. This negates the workflow benefits associated with alldata related to the procedure sharing a common I-Study UID.

B.7 The Approach Adopted by IHE Cardiology
IHE Cardiology strongly advises the use of a single Requested Procedure for cardiac
catheterization, even though there may be two reports (diagnostic and interventional) andseparate billing resulting from the procedure. A single Procedure Code for “Cardiac
Catheterization” is used by the Order Placer (not specifying Diagnostic or Interventional). This
allows all data for the procedure to be collected under the single Study Instance UID of theRequested Procedure.
There are several supporting arguments for this choice.
First, even in IHE Radiology (in the most recent version), there is not a strict 1:1 correspondence
between Requested Procedure and reporting/billing. The classic counter-example ismammography, where the exam will be read independently by two radiologists, who produce two
independent reports, but it is still a single Requested Procedure. The production of multiple
reports is an internal process of the Reporting Workflow. The cath case can be treated similarly it is a single Requested Procedure, but the reporting process will produce two documents. (IHE
Cardiology will address reporting and charge posting in subsequent years).
Second, cardiac cath is clinically a single procedure - the patient gets on the table once; theprocedure log conveys a continuous record of the patient from before entering the cath lab until__________________________________________________________________________
84
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
after leaving it; and the interventional data cannot be interpreted without the diagnostic data. The
clinical use of the cath exam data after the procedure similarly needs to be viewed as a whole toprovide context for any single item of data. As a result it makes little sense to separate the exam
into two Requested Procedures, which then need to be grouped for effective clinical practice.
Third, a single Requested Procedure simplifies the operations for a diagnostic cath that changes toan interventional - with or without a change of rooms. There is no need to worry about modalities(e.g., IVUS) that join the procedure only in the interventional phase having different study
information than those that joined at the start of the diagnostic phase.
Fourth, the ACC NCDR requires as single record for each “cath lab visit” when submitting data.
If an implementation is not using a single Requested Procedure for both the Diagnostic andInterventional phases of the exam, combining the data (post procedure) for submission to the
NCDR becomes much more difficult.
Even with a single Requested Procedure, it is possible (but optional) for separate MPPSs to becreated for data collected by a modality in the diagnostic and interventional phases. These
MPPSs can be derived from a single diagnostic/interventional Scheduled Procedure Step for themodality, or from separate diagnostic and interventional SPSs. Conversely, with a single
Requested Procedure, if the Order Filler schedules separate diagnostic and interventional SPSs, amodality can fulfill both with a single MPPS (this is not a Grouped Procedure case, since the
SPSs are from the same Requested Procedure).
However, an institution can still implement two Requested Procedures, but this would require all
the modalities to close out the data acquisition for the diagnostic phase, and start a newinterventional study. The Grouped Procedure case thus needs to be forbidden for the multimodality cath lab use case.
An issue to be resolved in future editions of the Technical Framework is how (and whether) to
support institutions that wish to have a separate Interventional Cath Order backfilled to the Order
Placer when an intervention is done. This may be related to inadequacies of current charge
posting systems, and may be remediated by use of the IHE RAD-TF Charge Posting Profile.

__________________________________________________________________________
85
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Appendix C: IHE Integration Statements
IHE Integration Statements are documents prepared and published by vendors to describe theintended conformance of their products with the IHE Technical Framework. They identify the
specific IHE capabilities a given product is designed to support in terms of the key concepts of
IHE: Actors and Integration Profiles (described in Volume I, section 2 of the Technical
Framework).
Users familiar with these concepts can use Integration Statements as an aid to determine whatlevel of integration a vendor asserts a product supports with complementary systems and whatclinical and operational benefits such integration might provide. Integration Statements areintended to be used in conjunction with statements of conformance to specific standards (e.g.
HL7, DICOM, W3C, etc.).
IHE provides a process for vendors to test their implementation of IHE Actors and Integration
Profiles. The IHE testing process, culminating in a multi-party interactive testing event called theConnect-a-thon, provides vendors with valuable feedback and provides a baseline indication of
the conformance of their implementations. The process is not, however, intended toindependently evaluate, or ensure, product compliance. In publishing the results of the Connecta-thon, and facilitating access to vendors’ IHE Integration Statements, IHE and its sponsoringorganizations are in no way attesting to the accuracy or validity of any vendor’s IHE Integration
Statements or any other claims by vendors regarding their products.
IMPORTANT -- PLEASE NOTE: Vendors have sole responsibility for the accuracy and validityof their IHE Integration Statements. Vendors’ Integration Statements are made available throughIHE simply for consideration by parties seeking information about the integration capabilities ofparticular products. IHE and its sponsoring organizations have not evaluated or approved any
IHE Integration Statement or any related product, and IHE and its sponsoring organizations shallhave no liability or responsibility to any party for any claims or damages, whether direct, indirect,
incidental or consequential, including but not limited to business interruption and loss of revenue,arising from any use of, or reliance upon, any IHE Integration Statement.

C.1 Structure and Content of an IHE Integration Statement
An IHE Integration Statement for a product shall include:
1.

The Vendor Name

2.

The Product Name (as used in the commercial context) to which the IHE
Integration Statement applies.

3.

The Product Version to which the IHE Integration Statement applies.

4.

A publication date.

5.

The following statement:__________________________________________________________________________
86
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________“This product is intended to implement all transactions required in the IHE Technical
Framework to support the IHE Integration Profiles, Actors and Options listed below:”
6.

A list of IHE Integration Profiles supported by the product and, for each Integration
Profile, a list of IHE Actors supported. For each integration profile/actor
combination one or more of the options defined in the IHE Technical Framework
may also be stated. Profiles, Actors and Options shall use the names defined by the
IHE Technical Framework Volume I. (Note: The vendor may also elect to indicate
the version number of the Technical Framework referenced for each Integration
Profile.)Note that implementation of the integration profile presumes implementation of all required
transactions for an actor; options include optional transactions or optional functions for required
transactions.
The statement shall also include references and/or internet links to the following information:
1.

The specific internet address (or universal resource locator [URL]) where thevendor’s Integration Statements are posted

2.

The specific URL where the vendor’s standards conformance statements (e.g., HL7,
DICOM, etc.) relevant to the IHE transactions implemented by the product are
posted.

3.

The URL of the IHE Initiative’s web page for general information on IHE(www.rsna.org/IHE).

An IHE Integration Statement is not intended to promote or advertise aspects of a product notdirectly related to its implementation of IHE capabilities.

C.2 Format of an IHE Integration Statement
Each Integration Statement shall follow the format shown below. Vendors may add a cover page
and any necessary additional information in accordance with their product documentation
policies.

__________________________________________________________________________
87
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________IHE Integration Statement
VendorDate

Product Name

Any Medical Systems Co.

12 Oct 2002

VersionIntegrateRAD

V2.3

This product implements all transactions required in the IHE Technical Framework to support the IHE Integration Profiles,
Actors and Options listed below:

Integration
ProfilesImplemented
Scheduled
Workflow

Simple Image andNumeric Report

Actors Implemented

Options
Implemented

Image Manager/Image Archive

none

Image Display

none

Image Creator

Performed Procedure
Step

Order Filler

PPS Exception
Management

Report Creator

noneInternet address for vendor’s IHE information:www.anymedicalsystemsco.com/ihe

Links to Standards Conformance Statements for the Implementation
HL7
DICOM

www.anymedicalsystemsco.com/hl7
www.anymedicalsystemsco.com/dicom/integrateRAD.pdf

Links to general information on IHE
In North America: www.rsna.org/IHE

In Europe: www.ihe-europe.org

In Japan: www.jira-net.or.jp/ihe-j__________________________________________________________________________
88
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Appendix D: GLOSSARY
Terms Specific to this Document
Actor: An entity within a use case diagram that can perform an action within a use case diagram.
Possible actions are creation or consumption of a message
Evidence Documents: Evidence Documents represent the uninterpreted information that is
primarily managed and used inside the imaging department, although distribution outside
the imaging department is not precluded. Evidence documents are non-image informationand include things such as measurements, CAD results, procedure logs, etc and are to be
encoded as DICOM SR documents.
Evidence Objects: All objects generated as a result of performing procedure steps on systems in
an imaging department. These objects are used by the reading physician in the process ofcreating a diagnostic report and are managed inside the imaging Department. Examples ofevidence objects include: Images, Presentation States, Key Image Notes and Evidence
Documents.
Expected Actions: Actions which should occur as the result of a trigger event
Interaction Diagram: A diagram which depicts data flow and sequencing of events
Process Flow Diagram: A graphical illustration of the flow of processes and interactions among
the actors involved in a particular example
Role: The actions of an actor in a use case.
Scope: A brief description of the transaction.
Trigger Event: An event such as the reception of a message or completion of a process, whichcauses another action to occur.
Use Case: A graphical depiction of the actors and operation of a system.

DICOM Terms
Basic Text SR Storage SOP Class: See DICOM Supplement 23
DICOM Model of the Real World: See DICOM PS 3.3
Enhanced SR Storage SOP Class: See DICOM Supplement 23
Grayscale Softcopy Presentation State Storage SOP Class: See DICOM PS 3.4
Grayscale Standard Display Function: DICOM PS 3.14
Imaging Service Request: See DICOM PS 3.3
Modality: See DICOM PS 3.3
Modality Worklist SOP Class: See DICOM PS 3.4
Modality Performed Procedure Step: See DICOM PS 3.3
Modality Performed Procedure Step Information Module: See DICOM PS 3.3__________________________________________________________________________
89
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Modality Performed Procedure Step Relationship Module: See DICOM PS 3.3
Modality Performed Procedure Step SOP Class: See DICOM PS 3.4
N-Event Report: See DICOM PS 3.7
Patient: See DICOM PS 3.3
Patient Identification Module: See DICOM PS 3.3
Print Presentation LUT SOP Class: See DICOM PS 3.4
Procedure Plan: See DICOM PS 3.3
Procedure Type: See DICOM PS 3.3
Protocol Code: See DICOM PS 3.3
Requested Procedure: See DICOM PS 3.3
Requested Procedure Module: See DICOM PS 3.3
Requested Procedure ID: See DICOM PS 3.3
Results Information Object Definition: See DICOM PS 3.3
Scheduled Procedure Step: See DICOM PS 3.3
Scheduled Procedure Step Module: See DICOM PS 3.3
Storage Commitment SOP Class: See DICOM PS 3.4
Structured Reporting Information Object Definitions: See DICOM PS 3.3
Structured Reporting SOP Classes: See DICOM PS 3.4
Structured Reporting Templates: See DICOM PS 3.16
Unique Identifier (UID): See DICOM PS 3.5

HL7 Terms
ADT: See HL7 version 2.3.1
Filler: See HL7 version 2.3.1
Observation: See HL7 version 2.3.1
Placer: See HL7 version 2.3.1
Universal Service ID: See HL7 version 2.3.1

Acronyms and Abbreviations
ACC: American College of Cardiology
ASE: American Society of Echocardiography
ECG: Electrocardiogram
ESC: European Society of Cardiology
HIMSS: Healthcare Information and Management Systems Society__________________________________________________________________________
90
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
HIS: Hospital Information System
ICE: Intracardiac Echocardiography
IHE: Integrating the Healthcare Enterprise
IOD: Information Object Definitions
IT: Information Technology
ITI: Information Technology Infrastructure (IHE Domain)
IVUS: Intravascular Ultrasound
MWL: Modality Worklist
MPPS: Modality Performed Procedure Step
NEMA: National Electrical Manufacturers Association
OID: Object Identifier
PACS: Picture Archive and Communication System
PCC: Patient Care Coordination (IHE Domain)
PPS: Performed Procedure Step
RAD: Radiology (IHE Domain)
RID: Retrieve Information for Display
RIS: Radiology Information System
RSNA: Radiological Society of North America
SCU: Service Class User
SCP: Service Class Provider
SPS: Scheduled Procedure Step
SR: Structured Report
TEE: Transesphogeal Echocardiography
TF: Technical Framework
TTE: Transthoracic Echocardiography
UID: Unique Identifier
UUID: Universally Unique Identifier
XA: X-ray Angiography__________________________________________________________________________
91
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Appendix E: Security Environment Considerations
IHE compliant systems usually process private healthcare information. This is subject to national
privacy regulations, and possibly other state and contractual requirements. The IHE profiles do
not fully define the security mechanisms necessary to protect this information. The ITI-TF Audit
Trail and Node Authentication (ATNA) Profile provides one component of this solution.
IHE assumes that actors will be installed on nodes with the following characteristics:• Each node has a security policy and procedure that applies to its operation.
This is assumed to be part of the healthcare enterprise security policy.
• Any user (human, or application process) external to the node boundaries is submitted to anaccess control procedure in which the user/application will be authenticated.
• All required audit trail events are captured and recorded.
The profiles in this framework assume the following environment:• Physical Security Environment• The equipment is assumed to be located in a physically protected and actively
monitored area. This is normally the case with modality equipment because of other
patient safety, privacy, and operational concerns. Similarly, the HIS systems andvarious archives are normally protected. Equipment like PACS workstations are
sometimes placed in unprotected areas, but it is usually located where hospital staff
monitors and limit access. It assumes that the threat of equipment modification isprotected against by means of the physical security mechanisms.
• The network equipment that connects the computers is also assumed to be physicallyprotected against unauthorized connections and unauthorized modifications. In thetreatment areas of most hospitals the network equipment is in ceilings, cableways,
locked cabinets, and other protected areas. There is usually staff present to monitor
that no unauthorized activity is taking place.
• Local procedures and operations will be in place to ensure that the physical security
assumptions are valid for other areas of the hospital, such as administrative offices,that may be at greater risk.
• Remote locations, especially home offices, are not physically protected. Other means
will be used to provide equivalent protection. This may include the use of technology
such as VPN connections or HTTPS encryption. Use of encryption or VPN is not acomplete replacement for physical security but may be part of an overall protection
system.
• The home computer that is used for both personal and professional purposes isdifficult to protect. It will be protected from inadvertent modification by malicious
software or its use will be prohibited.
• Network Security Environment__________________________________________________________________________
92
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________•In addition to the physical security of the network, there will be protection against
network access by unsupervised systems. This is typically provided by mechanisms
such as firewalls and VPNs.

The threat profile is assumed to be:• Accidental and inadvertent misuse• Individual abuse for personal gain, malice, revenge, or curiosity. The abusers are
assumed to have only limited access to the underlying systems and software. They are
not expert at the internal structure of the systems.
• Random untargeted abuse, such as from an Internet hacker.
The threat profile also assumes that the following threats are either not present or otherwise
protected.
• Individual abuse by a system administrator, system developer, or other expert.
• Military or hostile government action• Organized criminal attack
IHE addresses only those security requirements related to IT systems within the scope of IHE
healthcare applications. It does not address security requirements for defending against network
attacks, virus infection, etc.
IHE does not mandate the use of encryption because the performance impact of current
encryption algorithms is excessive. Most hospital networks provide adequate security throughphysical and procedural mechanisms. The additional performance penalty for encryption is notjustified for these networks. The profiles permit the use of encryption so that it can be used as partof an overall security plan.

__________________________________________________________________________
93
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Appendix F: Displayable Report Distribution Using the DRPT, RID
and XDS Profiles
This section is reserved.

Appendix G: Displayable Report Signing
This section is reserved__________________________________________________________________________
94
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Appendix H: Cardiology Summary of Relevant Profiles from Other
Domains
This appendix calls out specific Integration Profiles defined in the IHE Radiology and IT
Infrastructure Technical Frameworks. These Integration Profiles are sufficiently important to thecardiology domain that they have been explicitly included in the IHE Cardiology Technical
Framework. However, they are specified only by reference to their original definition in the otherTechnical Frameworks, with notes and use cases on their applicability to cardiology. There areno additional technical requirements defined in this Appendix.
The full specification of the Profiles identified in this Appendix can be found in the IHE
Technical Framework documents of other domains. These descriptions are provided for reference
related to their use in the Cardiology domain.

H.1 Consistent Time (CT)The full specification of the Consistent Time Integration Profile is found in ITI-TF 1:7.
The Consistent Time Integration Profile provides a means to ensure that the system clocks andtime stamps of the many computers in a network are well synchronized. This profile specifies
synchronization with a median error less than 1 second. This is sufficient for most procedure andsystem management purposes. The achievable accuracy is dependent on specific details of
network hardware and topology, and on details of computer hardware and software
implementation.
Figure H.1-1 shows the actors directly involved in the Consistent Time Profile and the relevanttransactions between them.
Time Server

Maintain Time [1]↑Time Client

Figure H.1-1: Consistent Time Profile Diagram

H.1.1 CT Actors
Time Client – Establishes time synchronization with one or more Time Servers using the
NTP protocol and either the NTP or SNTP algorithms. Maintains the local computer__________________________________________________________________________
95
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
system clock synchronization with UTC based on synchronization with the Time
Servers.
Time Server – Provides NTP time services to Time Clients. It is either directly synchronized
to a UTC master clock (e.g., satellite time signal) or is synchronized by being groupedwith a Time Client to other Time Server(s).
H.1.2 CT Transactions
Maintain Time - NTP transactions used to maintain time synchronization.
H.1.3 Cardiology Use Cases
Synchronization of a multi-modality procedure requires a common understanding of the current
time. Certain Actors participating in the Cath Workflow are required to participate in theConsistent Time Profile (see Sections 2.1 and 2.5).

H.2 Scheduled Workflow (SWF) and Patient Information Reconciliation(PIR)
The full specification of the Scheduled Workflow Profile is found in RAD-TF 1:3, and Patient
Information Reconciliation in RAD-TF 1:4.
The Scheduled Workflow Integration Profile establishes the continuity and integrity of basic
departmental imaging data. It specifies a number of transactions that maintain the consistency ofpatient and ordering information as well as providing the scheduling and imaging acquisition
procedure steps. This profile also makes it possible to determine whether images and otherevidence objects associated with a particular performed procedure step have been stored(archived) and are available to enable subsequent workflow steps, such as reporting.
The Patient Information Reconciliation Integration Profile extends the Scheduled Workflow
Integration Profile by offering the means to match images, diagnostic reports, and other evidence
objects acquired for a misidentified or unidentified patient (for example, during a trauma case)with the patient’s record. In the example of the trauma case, this integration profile allows
subsequent reconciliation of the patient record with images that are acquired (either without aprior registration or under a generic registration) before the patient’s identity can be determined.
Thus images can be acquired and interpreted immediately and later, when the patient’s official
registration and order information is entered into the ADT, Order Placer and Order Filler
Systems, this information is matched with the acquired image set and reports, greatly simplifying
these exception handling situations.
H.2.1 Cardiology Use Case for SWF and PIR
IHE Cardiology has defined specializations of the SWF and PIR Profiles for its Cardiac
Catheterization Workflow and Echocardiography Workflow Profiles.

__________________________________________________________________________
96
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
However, IHE Cardiology has not created specialized Workflow Profiles for nuclear cardiology,
cardiovascular MR, cardiovascular CT imaging, or standard X-rays commonly used in cardiology(e.g., chest X-rays). It is expected that the SWF and PIR Profiles will be used for thosemodalities.

H.3 Retrieve Information for Display (RID)
The full specification of the Retrieve Information for Display Profile is found in ITI-TF 1:3.
The Retrieve Information for Display (RID) Integration Profile provides simple and rapid readonly access to patient-centric clinical information that is located outside the user’s current
application but is important for better patient care (for example, access to lab reports fromcardiology department). It supports access to existing persistent documents in well-known
presentation formats such as CDA (Level 1), PDF, JPEG, etc. It also supports access to specific
key patient-centric information such as allergies, current medications, summary of reports, etc. forpresentation to a clinician.
Figure H.3-1 shows the actors involved in this Profile and the transactions between actors.

Retrieve Specific Info for Display [ITI-11]

Display
Retrieve Document for Display [ITI-12]

Information
SourceFigure H.3-1. Retrieve Information for Display Diagram

H.3.1 RID Process Flow
A clinical user, through the Display actor, requests information related to a patient. The request
may be constrained to a particular type of information (e.g., a list of laboratory reports, or a list of
current medications), or may include other filtering keys (last N documents, date range, etc.). The
Information Source actor responds with the requested information in a “ready for presentation”
format; the Display actor simply displays the information to the person that triggered the request.
The clinician may also request retrieval of a specific document for display, either from a list
returned from the Information Source, or using an access pointer obtained by some othermechanism (e.g., included as a reference in another document). The Display actor may request a
specific document presentation format for the retrieved document. Again, the Information Source
actor responds to the request, and may convert the requested document from its native storage
format to the requested presentation format.
H.3.2 Cardiology Use Cases
The Retrieve ECG for Display Profile is an extension of the RID Profile, and is based on the RID
actors and transactions. (See Section 5 of this document.)__________________________________________________________________________
97
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________In the Cardiology domain, this Profile may be used to obtain information held outside a
Cardiology department. In particular, this Profile may be used to obtain information critical to theperformance of a cardiac catheterization procedure, such as patient history and physical exam
data, advance medical directives, blood chemistry reports, and current medications. As such, theDisplay actor of this profile has a significant adjunct role for the Cath Workflow Profile, or for
any departmental clinical workstation that needs to present information from both the Cardiology
department and from the patient’s general electronic health record (EHR).
Additionally, this Profile may be used by systems within the cardiology department to provide
information to other departments or users, such as reports. As such, the Information Source actorof this profile has a significant adjunct role for the report repositories of the Displayable Report
Profile.

H.4 Cross-Enterprise Document Sharing (XDS)
The full specification of the Cross-Enterprise Document Sharing Integration Profile is found in
ITI-TF 1:10.
The Cross-Enterprise Document Sharing Integration Profile facilitates the registration,
distribution and access across health enterprises of patient electronic health records. CrossEnterprise Document Sharing provides a standards-based specification for managing the sharingof documents between any healthcare enterprises, ranging from private physician offices, toclinics, to acute care in-patient facilities.
The XDS Integration Profile assumes that these enterprises belong to one or more clinical affinity
domains. A clinical affinity domain is a group of healthcare enterprises that have agreed to work
together using a common set of policies and share a common infrastructure. Examples of affinity
domains include:• Community of Care supported by a Regional Health Information Organization (RHIO)• An Integrated Delivery Network (IDN)• Specialized or Disease-oriented Care Communities• Insurance Provider Supported Communities
Within a clinical affinity domain, certain common policies and business rules must be defined.
They include how patients are identified, consent is obtained, and access is controlled, as well as
the format, content, structure, organization and representation of clinical information. This
Integration Profile does not define specific policies and business rules; however, it has been
designed to accommodate a wide range of such policies to facilitate the deployment of standardsbased infrastructures for sharing patient clinical documents.
Figure H.4-1 diagrams the actors involved with this profile and the transactions between actors.

__________________________________________________________________________
98
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Patient Identity Source

Patient Identity Feed [ITI-8] ↓Query Registry[ITI-16] ←Document Registry

Document Consumer↑ Register
Document Set[ITI-14]

Document Source

Provide&Register
Document Set[ITI-15] →Retrieve Document[ITI-17] ←Document Repository

Figure H.4-1 Cross-Enterprise Document Sharing Diagram

Notes:

1. This Profile requires all actors be grouped with a Secure Node Actor as defined in
the IHE Audit Trail and Node Authentication (ATNA) Integration Profile (see ITI-TF
1:9).
2. The effective use of this Profile assumes the use of the Patient Identity CrossReference (PIX) Profile (see ITI-TF 1:5) to enable the Document Source systems to
obtain and apply the Patient ID used in the clinical affinity domain to documents
registered for sharing.
3. The effective use of this Profile requires profiling the specific document formats to
be used in the clinical affinity domain. The IHE Cardiology Technical Committee has
not yet established the appropriate document formats for the Cardiology domain, but
this may be the subject of a future recommendation. The Committee notes in particular
the XDS for Imaging (XDS-I) Profile being developed by the IHE Radiology
Technical Committee.
4. For cross-enterprise sharing of cardiology reports, the Document Source and/orDocument Repository actors of this profile may be associated with the report
repositories of the Displayable Report Profile and the Simple Image and Numeric
Report Profile.

H.4.1 XDS Process Flow
A clinician submits a set of documents to be shared (e.g., a History and Physical report, and an
ECG) through a Document Source Actor (e.g., his local EHR system). This system sends the
documents and the corresponding metadata to the Document Repository, using the Patient ID
used in the shared domain (which may be different than the ID used in the local EHR). The
Document Repository is responsible to persistently store these documents, and to register them in__________________________________________________________________________
99
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
the Document Registry using the Register Documents transaction by forwarding the document
metadata received from the Document Source Actor.
This document metadata will be used to create an XDS Document Entry in the registry. The
Document Registry Actor ensures that document metadata is valid before allowing documents tobe registered.
There may be several Document Repositories in the clinical affinity domain, but all register their
documents with a single Document Registry for the domain. A Document Repository may bebundled with the Document Source, or with the Document Registry, or may be an independent
system.
A care provider elsewhere in the network wishes to retrieve the patient’s shared documents (e.g.,in preparation for a diagnostic exam). That provider through a Document Consumer Actor issues
a Query Registry transaction to the Document Registry. The Document Registry Actor searches
the registry to locate documents that meet the provider’s specified query criteria. It will return alist of document entries that contain metadata found to meet the specified criteria including thelocations and identifier of each corresponding document in one or more Document Repositories.
The provider identifies the documents he is interested in seeing, and the Document Consumer
Actor initiates the Retrieve Document transaction. The Document Repository will return the
document that was specified by the Document Consumer.
H.4.2 Cardiology Use Cases
In the Cardiology domain, a principal use case would be for the sharing of documents among a
cardiologist’s office practice and the several secondary and tertiary care facilities to which the
cardiologist may refer the patient for specialized tests or procedures.
Although business relationships vary by country, in the many locales it is very common for a
cardiologist to practice at both a private clinic office as well as a hospital. The private clinic often
is the repository for information such as ECG waveforms and reports, echo images and reports,
medication information, some in-house lab measurements and reports, office visit notes, etc.
Hospitals are often the repository for information such as cath images and reports, echo images
and reports, ECG waveforms and reports, hemodynamic information, lab information, discharge
summaries, etc. The private clinic and the hospital are two distinct businesses. However, acardiologist would have privileges at both facilities and there is a mutual business arrangement
between the two facilities.
The first general use case is where patient presents at a hospital (e.g., CCU, cath lab, ED), forwhom critical information is located in the clinic. A more specific example of this case is wherea patient is admitted to ED after normal business hours with chest pain and the cardiologist on callcomes in to the ED. This patient was seen at the office the previous week and the medication
regimen was changed at that time. The patient is unable to tell the cardiologist the medicationand dosages which were prescribed and that information is locked away in the clinic office.
A second general use case is that where the cardiologist is physically located in a clinic office andneeds access to information generated and stored in the hospital repository. A more specific__________________________________________________________________________
100
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
example of this use case is that a patient is scheduled for a follow up visit in the cardiologist’s
office, but the cardiologist does not have immediate access to the cath report and discharge
summary created the previous week in the hospital.
Another use case is that of rural healthcare. A patient is seen at a rural hospital for routine cardiac
care. Later, that patient has a significant event and is taken by ambulance to a tertiary care
hospital with a cardiac center. A business relationship exists between the two facilities to provide
acute cardiac care. Once at the tertiary care site, the cardiologist on staff needs access to all of therecords currently located at the rural hospital.
H.4.3 XDS Content Profiles
XDS provides a general mechanism for sharing of documents between different healthcare
enterprises. However, certain use cases require the specification of the content or structure ofshared documents to ensure interoperability. This is the purpose of XDS Content Profiles.
H.4.3.1 XDS-MS Medical Summary
The full specification of the Cross-Enterprise Document Sharing of Medical Summaries Profile isfound in PCC TF-1:3.
By their nature, Medical Summaries form a class of clinical documents that contain the most
relevant portions of the patient medical record. As the name would indicate they have the purposeof summarizing, both abstracting the most important pieces of information from the EMR andrecording free-text summaries at the time of medical summary creation. Operationally, they arecommonly created at points in time of transfers of care from one provider to another or from one
setting to another.
The XDS-MS Profile facilitates transfer of care by defining a minimum set of “record entries”
that should be forwarded or made available to subsequent care provider(s) during specific transfer
of care scenarios. In addition, this integration profile defines the utilization requirements/options
for the receiving entity in order to ensure that the “care context” of the sending entity isappropriately maintained following the information transfer.
Most of the XDS cardiology use cases described in section H.4.2 would utilize the XDS-MS
content profile for exchanging a summary of an episode of care – the summary record of an officevisit, of an in-patient cath procedure, or of an emergency department encounter.
H.4.3.2 XDS-I Imaging
The full specification of the Cross-Enterprise Document Sharing for Imaging Profile is found in
RAD TF-1:18.
The XDS for Imaging (XDS-I) Profile extends and specializes XDS to support imaging“documents”, specifically including the following:__________________________________________________________________________
101
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. I: Integration Profiles______________________________________________________________________________•

Imaging studies that include images acquired on a broad range of different modalities, aswell as evidence documents (e.g. post-processing measurements/analysis outcome), andpresentation states.

•

Diagnostic reports resulting from the interpretation of one or more related imaging studies
provided in a ready-for-display form•

A selection of diagnostically significant images associated with the report content.

Figure H.4-2 shows the extended XDS actors and transactions used for XDS-I.
Patient Identity Source

Patient Identity Feed [ITI-8] ↓Query Registry [ITI-16]←
Document Registry

Imaging Document
Consumer↑ Register
Document Set[ITI-14]
Provide & Register Imaging
Document Set[RAD-54] →Imaging Document
SourceDocument Consumer

Retrieve Document[ITI-17] ←Document Repository
WADO Retrieve[RAD-55] ←Retrieve Images [RAD-16] ←Retrieve Presentation States [RAD-17] ←Retrieve Reports [RAD-27] ←Retrieve Key Image Note [RAD-31] ←Retrieve Evidence Documents [RAD-45] ←Figure H.4-2 Cross-Enterprise Document Sharing for Imaging Diagram__________________________________________________________________________
102
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNA