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

Final Text Version
Publication Date: June 8, 2006

Copyright © 2004 - 2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
Contents
1

Introduction.............................................................................................................................. 5
1.1 Overview of Technical Framework.................................................................................. 5
1.2 Overview of Volume II .................................................................................................... 5
1.3 Audience........................................................................................................................... 6
1.4 Relationship to Standards ................................................................................................. 6
1.5 Relationship to Real-world Architectures ........................................................................ 6
1.6 Comments......................................................................................................................... 7
1.7 Copyright Permission ....................................................................................................... 7
2 Conventions ............................................................................................................................. 8
2.1 The Generic IHE Transaction Model ............................................................................... 8
2.2 DICOM Usage Conventions............................................................................................. 9
2.3 HL7 Profiling Conventions ............................................................................................ 11
2.4 HL7 Implementation Notes ............................................................................................ 122.4.1 Network Guidelines .............................................................................................. 122.4.2 Message Control ................................................................................................... 122.4.3 Acknowledgment Modes ...................................................................................... 13
2.5 HL7 and DICOM Mapping Considerations ................................................................... 14
2.6 Use of Coded Entities and Coding Schemes .................................................................. 15
3 Framework Overview ............................................................................................................ 16
4 IHE Transactions ................................................................................................................... 17
4.1 Modality Procedure Step In Progress [CARD-1]........................................................... 17
4.1.1 Multi-Modality Procedure Update Option............................................................ 17
4.1.1.1 Expected Actions......................................................................................... 17
4.2 Modality Images/Evidence Stored [CARD-2] ............................................................... 19
4.2.1 Cardiac Cath Option ............................................................................................. 19
4.2.2 Echocardiography Option ..................................................................................... 19
4.2.3 Stress Echo Option................................................................................................ 20
4.2.4 Cath Evidence Option ........................................................................................... 23
4.2.5 Echo Evidence Option .......................................................................................... 24
4.3 Storage Commitment [CARD-3].................................................................................... 25
4.3.1 Intermittently Connected Modality Option........................................................... 25
4.3.1.1 Trigger Events ............................................................................................. 25
4.4 Retrieve Images/Evidence [CARD-4]............................................................................ 26
4.4.1 Stress Echo Option................................................................................................ 26
4.4.1.1 Expected Actions......................................................................................... 27
4.4.2 Cath Evidence Option ........................................................................................... 27
4.4.2.1 Expected Actions......................................................................................... 27
4.4.3 Echo Evidence Option .......................................................................................... 28
4.4.3.1 Expected Actions......................................................................................... 28
4.5 Retrieve ECG List [CARD-5] ........................................................................................ 29
4.5.1 Scope..................................................................................................................... 29__________________________________________________________________________
1
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
4.5.2 Use Case Roles ..................................................................................................... 29
4.5.3 Referenced Standard ............................................................................................. 29
4.5.4 Interaction Diagram .............................................................................................. 30
4.5.4.1 Request For ECG List ................................................................................. 30
4.5.4.2 Response with ECG List ............................................................................. 31
4.6 Retrieve ECG Document for Display [CARD-6]........................................................... 32
4.6.1 Scope..................................................................................................................... 32
4.6.2 Use Case Roles ..................................................................................................... 32
4.6.3 Referenced Standard ............................................................................................. 32
4.6.4 Interaction Diagram .............................................................................................. 32
4.6.4.1 Request For ECG Document....................................................................... 32
4.6.4.2 Delivery of ECG Document ........................................................................ 34
4.7 Encapsulated Report Submission [CARD-7] ................................................................. 37
4.8 Report Reference Submission [CARD-8] ...................................................................... 38
4.9 Encapsulated Report Storage [CARD-9]........................................................................ 39
4.10 Encapsulated Report Query [CARD-10]........................................................................ 40
4.11 Encapsulated Report Retrieve [CARD-11] .................................................................... 41
Appendix A:
Clarification on MPPS for Intermittently Connected Modality .................. 42
Appendix B:
Web Service Definition for Retrieve ECG for Display Transaction........... 43
Appendix C:
ECG List XML Specification...................................................................... 46
C.1 Schema ........................................................................................................................... 46
C.2 Example.......................................................................................................................... 51
Appendix D:
Coded Report Titles .................................................................................... 55__________________________________________________________________________
2
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

Foreword
Integrating the Healthcare Enterprise (IHE) is an initiative designed to stimulate the integrationof the information systems that support modern healthcare institutions. Its fundamental objective
is to ensure that in the care of patients all required information for medical decisions is bothcorrect and available to healthcare professionals. The IHE initiative is both a process and aforum for encouraging integration efforts. It defines a technical framework for the
implementation of established messaging standards to achieve specific clinical goals. It includes
a rigorous testing process for the implementation of this framework. And it organizes
educational sessions and exhibits at major meetings of medical professionals to demonstrate thebenefits of this framework and encourage its adoption by industry and users.
The approach employed in the IHE initiative is not to define new integration standards, but rather
to support the use of existing standards, HL7, DICOM, IETF, and others, as appropriate in 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) andEuropean 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é Francaise 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 Ministry of Health, Labor, and Welfare; and MEDIS-DC; cooperating organizations include
the Japan Industries Association of Radiological Systems (JIRA), the Japan Association of
Healthcare Information Systems Industry (JAHIS), Japan Radiological Society (JRS), Japan
Society of Radiological Technology (JSRT), and the Japan Association of Medical Informatics(JAMI). Other organizations representing healthcare professionals are invited to join in the
expansion of the IHE process across disciplinary and geographic boundaries.
The IHE Technical Frameworks for the various domains (IT Infrastructure, Cardiology,
Laboratory, Radiology, etc.) defines specific implementations of established standards to achieve
integration goals that promote appropriate sharing of medical information to support optimal
patient care. It is expanded annually, after a period of public review, and maintained regularly
through the identification and correction of errors. The current version for these Technical
Frameworks may be found at www.ihe.net.
The IHE Technical Framework identifies a subset of the functional components of the healthcare
enterprise, called IHE Actors, and specifies their interactions in terms of a set of coordinated,
standards-based transactions. It describes this body of transactions in progressively greater__________________________________________________________________________
3
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
depth. 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. This Volume II provides detailed technical descriptions of each IHE
transaction.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

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 errata. 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, standardsbased transactions. It describes this body of transactions in progressively greater depth. Volume I
provides a high-level view of IHE functionality, showing the transactions organized intofunctional units called Integration Profiles that highlight their capacity to address specific clinicalneeds. The present Volume II provide detailed technical descriptions of each cardiology-specific
IHE transaction.
The CARD-TF is part of the larger IHE Technical Framework, which comprises 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 in Volume I.

1.2 Overview of Volume II
Section 2 presents the conventions used in this volume to define the transactions implemented
under IHE.
Section 3 provides an overview of the concepts of IHE actors and transactions used in IHE todefine the functional components of a distributed healthcare environment.
Section 4 defines transactions CARD-1 to CARD-6 in detail, specifying the roles for each actor,
the standards employed, the information exchanged, and in some cases, implementation options
for the transaction.
The appendices following the main body of this volume provide clarification of technical detailsof the IHE data model and transactions. A glossary of terms and acronyms used in the IHE__________________________________________________________________________
5
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
Technical Framework, including those from relevant standards (currently HL7 and DICOM), is
provided in Volume I.

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
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, a user familiar with
the IHE concepts of Actors and Integration Profiles should be able to determine whether and towhat extent communications might be supported between products. 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 havebeen implemented in conformance with those standards, but not in full accordance with the IHE
Technical Framework.

1.5 Relationship to Real-world Architectures
The IHE Actors and transactions described in the IHE Technical Framework are abstractions of
the real-world healthcare information system environment. While some of the transactions are__________________________________________________________________________
6
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
traditionally performed by specific product categories (e.g. HIS, Electronic Patient Record, RIS,
PACS, Clinical Information Systems or imaging modalities), the IHE Technical Framework
intentionally avoids associating functions or actors with such product categories. For each actor,
the IHE Technical Framework defines only those functions associated with integrating
information systems. The IHE definition of an actor should therefore not be taken as thecomplete definition of any product that might implement it, nor should the framework itself betaken to comprehensively 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 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

1.7 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
to incorporate portions of the DICOM standard.
Material drawn from these documents is credited where used.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

2

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 shall beapplied.

2.1 The Generic IHE Transaction Model
Transaction descriptions are provided in section 4. In each transaction description, the actors, theroles they play, and the transactions between them are presented as use cases.
The generic IHE transaction description includes the following components:• Scope: a brief description of the transaction.
• Use case roles: textual definitions of the actors and their roles, with a simple diagram
relating them, e.g.:
Actor

Actor

Transaction••

Referenced Standards: the standards (stating the specific parts, chapters or sections
thereof) to be used for the transaction.
Interaction Diagram: a graphical depiction of the actors and transactions, with related
processing within an actor shown as a rectangle and time progressing downward, similarto:__________________________________________________________________________
8
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

Actor

Actor

Actor

MSG1
MSG2
MSG3

•

The interaction diagrams used in the IHE Technical Framework are modeled after thosedescribed in Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling
Language User Guide, ISBN 0-201-57168-4. Simple acknowledgment messages areomitted from the diagrams for brevity.
Message definitions: descriptions of each message involved in the transaction, the events
that trigger the message, its semantics, and the actions that the message triggers in thereceiver.

2.2 DICOM Usage Conventions
For some DICOM transactions described in this document, IHE has strengthened therequirements on the use of selected Type 2 and Type 3 attributes. These situations are explicitly
documented in section 4 and in the appendices.
IHE specifically emphasizes that DICOM Type 2 attributes (for instance, Patient Name, PatientID) shall be transmitted with zero length if the source system does not possess valid values forsuch attributes; in other words, the source system shall not assign default values to such
attributes. The receiving system must be able to handle zero-length values for such attributes.
IHE has also defined requirements related to the support for and use of matching and return keys
in DICOM queries by both Service Class Users (SCUs) and Service Class Providers (SCPs).
Matching keys are used to select instances for inclusion in the response by the query SCP to the
SCU, whereas return keys only return specific data and are not used for matching.
•Required matching key SCU:
A key that the Query SCU shall have the ability to offer to its user as a selection criterion. The
definition of the means offered to the user of the Query SCU to trigger the sending of a matching key
in the Query request is beyond the scope of IHE (e.g. enter a value, select an entry).

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________•••

Required matching key SCP:An IHE required matching key is processed by the Query SCP just as if it were a DICOM-required
matching key. In most cases, IHE-required matching keys are also DICOM-required matching keys.
Required return key SCU:
A key that the Query SCU requests from the Query SCP, receives in the query responses, and displays
for the user, if required. The definition of the means offered to the user of the Query SCU to request areturn key (e.g. by default, check a box) and to make it visible to the user is beyond the scope of IHE.
Required return key SCP:
IHE-required return keys specified within DICOM as type 1 or type 2 return keys are processed
according to their DICOM type. IHE-required return keys specified within DICOM as type 3 will beprocessed as if they were type 2.

Query Key Requirement Tables in the framework use the following legend to specify
requirements for SCUs and SCPs:
R
RequiredO
Optional
The following modifiers are also used:R+
The Requirement is an IHE extension of the DICOM requirements
R*
The attribute is not required to be displayed
Table 2.2-1 provides an example table defining matching and return keys.
Table 2.2-1. Images Query Matching and Return Keys
Attributes
Name

Tag

Query Keys Matching

Scheduled Human
Performers
Sequence(0040,4034)

R+

R

R+*

R

>Human Performer
Code Sequence(0040,4009)

R+

R

R+*

R

>>Code Value(0008,0100)

R+

R

R+*

R

>>Coding Scheme
Designator(0008,0102)

R+

R

R+*

R

>>Code Meaning(0008,0104)

-

-

R+

R

SCU

SCP

Query Keys Return
SCU

Notes

SCP

Query Keys
Matching SCU or
SCP do not use
the Code Meaning
values (“-“).

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________>Human Performer'sName(0040,4037)

R+

R+

R+

R+

>Human Performer's
Organization(0040,4036)

O

O

O

R+

Referenced Study
Component
Sequence(0008,1111)

O

O

O

O

>Referenced SOPClass UID

(0008,1150)

O

O

O

R

>Referenced SOP
Instance UID(0008,1155)

O

O

O

R

Input Information
Sequence(0040,4021)

O

O

R+*

R

2.3 HL7 Profiling Conventions
The HL7 tables included in this document have been modified from the HL7 2.3.1 standard
document. Such a modification is called a profile. Refer to the HL7 2.3.1 standard for themeanings of specific columns in the table.
The profiling tables in this document leverage the ongoing HL7 profile definition. To maintainthis specification at a generic level, the following differences have been introduced:• Message specifications do not indicate the cardinality of segments within a message.
• For fields composed of multiple components, there is no indication of the size of eachcomponent.
• Where a table containing enumerated values is referenced from within a segment profile
table, the enumerated values table is not always present.
• The number of times a repeating field can repeat is not indicated.
• The conditions that would require inclusion of conditional fields are not defined when
they depend on functional characteristics of the system implementing the transaction andthey do not affect data consistency.
The following terms refer to the OPT column, which has been profiled:R
Required
R2
This is an IHE extension. If the sending application has data for the field, it isrequired to populate the field. If the value is not known, the field may not be sent.
O
Optional
C
Conditional
IHE requires that Z-segments be present in HL7 transactions only when defined by the IHE
Technical Framework.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
According to the HL7 standard, if the value of a field is not present, the receiver shall not change
corresponding data in its database. However, if sender includes explicit NULL value (i.e., twodouble-quotes “”), it shall cause removal of any values for that field in the receiver’s database.
Table 2.3-1 provides a sample profile for an imaginary HL7 segment. Tables for real segments
are copied from the HL7 2.3.1 standard with modifications made only to the OPT column.
Table 2.3-1. Sample HL7 Profile
SEQ

LEN

DT

OPT

1

1

ST

R

TBL#

xx001

ITEM #

Element 1

ELEMENT NAME

2

4

ST

O

xx002

Element 2

3

180

HD

R2

xx003

Element 3

4

180

HD

C

xx004

Element 4

5

180

HD

O

xx005

Element 5

6

180

HD

R

xx006

Element 6

2.4 HL7 Implementation Notes
2.4.1 Network Guidelines
The HL7 2.x standard does not define a network communications protocol. The HL7 2.1
standard defines lower layer protocols in an appendix. These definitions were moved to the
Implementation Guide in 2.2 and subsequent versions, but are not HL7 requirements. The IHE
Framework makes these recommendations:
1.

Applications shall use the Minimal Lower Layer Protocol defined in Appendix C of the
HL7 Implementation Guide.

2.

An application that wants to send a message (initiate a transaction) will initiate a
network connection to start the transaction. The receiver application will respond withan acknowledgement or response to query but will not initiate new transactions on thisnetwork connection.

2.4.2 Message Control
According to the HL7 standard, each message shall begin with the MSH (message header)segment. Table 2.4-1 identifies all required fields in this message. This table shall be interpreted
according to the HL7 Standard unless otherwise noted in section 2.3.
Table 2.4-1. IHE Profile - MSH segment
SEQ

LEN

DT

OPT

TBL#

ITEM #ELEMENT NAME

1

1

ST

R

00001

Field Separator

2

4

ST

R

00002

Encoding Characters__________________________________________________________________________
12
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
3

180

HD

R

00003

Sending Application

4

180

HD

R

00004

Sending Facility

5

180

HD

R

00005

Receiving Application

6

180

HD

R

00006

Receiving Facility

7

26

TS

O

00007

Date/Time Of Message

8

40

ST

O

00008

Security

9

7

CM

R

00009

Message Type

10

20

ST

R

00010

Message Control ID

11

3

PT

R

00011

Processing ID

12

60

VID

R

00012

Version ID

13

15

NM

O

00013

Sequence Number

14

180

ST

O

00014

Continuation Pointer

15

2

ID

O

0155

00015

Accept Acknowledgment Type

16

2

ID

O

0155

00016

Application Acknowledgment Type

17

2

ID

O

00017

Country Code

18

6

ID

C

00692

Character Set

19

60

CE

O

00693

Principal Language Of Message

20

20

ID

O

01317

Alternate Character Set Handling
Scheme

0104

0211
0356

Adapted from the HL7 Standard, version 2.3.1
The IHE Technical Framework requires that applications support HL7-recommended values forthe fields MSH-1 Field Separator and MSH-2 Encoding Characters.
Field MSH-18 Character Set shall only be valued if the message utilizes character sets other thanISO IR-6, also known as ASCII.
Implementations supporting sequence number protocol (and using the field MSH-13 Sequence
Number) shall be configurable to allow them to perform transactions without such protocol.
2.4.3 Acknowledgment Modes
Applications that receive HL7 messages shall send acknowledgments using the HL7 Original
Mode (versus Enhanced Acknowledgment Mode).
The IHE Technical Framework provides for each HL7 message to be acknowledged by the HL7
ACK message sent by the receiver of an HL7 message to its sender. The segments of the ACK
message listed below are required, and their detailed descriptions are provided in tables 2.4-1,
2.4-2 and corresponding notes. The ERR segment is optional and may be included if the MSA-1
Acknowledgement Code field identifies an error condition.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
ACK

Acknowledgement
Message

Chapter in HL7
2.3.1

MSH

Message Header

2

MSA

Message Acknowledgement

2

[ERR]

Error Comments

2

Table 2.4-2. IHE Profile - MSA segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

0008

00018

Acknowledgment Code

R

00010

Message Control ID

ST

O

00020

Text Message

NM

O

00021

Expected Sequence Number

1

ID

O

00022

Delayed Acknowledgment Type

100

CE

O

00023

Error Condition

1

2

ID

R

2

20

ST

3

80

4

15

5
6

0102

ELEMENT NAME

Adapted from the HL7 standard, version 2.3.1
Field MSA-2 Message Control ID shall contain the Message ID from the MSH-10 Message
Control ID of the incoming message for which this acknowledgement is sent.
Table 2.4-3. IHE Profile - ERR segment
SEQ
1

LEN
80

DT
ID

OPT
R

TBL#

ITEM#
00024

ELEMENT NAME
Error code and location

Adapted from the HL7 standard, version 2.3.1

2.5 HL7 and DICOM Mapping Considerations
Field lengths are explicitly defined in the DICOM standard, but an HL7 element might consist ofmultiple components that do not have a defined maximum length. It is recognized that there aresome HL7 component lengths that could be longer than the DICOM attribute lengths. Data
values for mapped fields are required not to exceed the smaller of either the HL7 or the DICOM
field length definitions. Systems supporting alternative character sets must take into account the
number of bytes per character in such sets. All systems are required to support the DICOM
Default Character Set (ISO-IR 6 or ASCII). In addition, other character sets may be supported.
Maintaining consistency of data encoded using alternative character sets is outside of the scopeof the IHE Technical Framework.
Value Representations are not explicitly addressed. Attention shall be given to the mapping of
the HL7 representation and the DICOM representation. Examples of these include Patient Name,dates and times.
__________________________________________________________________________
14
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

2.6 Use of Coded Entities and Coding Schemes
IHE does not produce, maintain or otherwise specify a coding scheme or other resource forcontrolled terminology (coded entities). Where applicable, coding schemes required by the HL7
and DICOM standards take precedence. In the cases where such resources are not explicitly
identified by the standards, implementations may utilize any resource (including proprietary or
local) provided any licensing/copyright requirements are satisfied.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

3 Framework Overview
The IHE Technical Framework is based on actors that interact through transactions.
Actors are information systems or components of information systems that produce, manage, or
act on information associated with operational activities in the enterprise.
Transactions are interactions between actors that transfer the required information throughstandards-based messages.
Specific sets of actors and transactions are specified in the Integration Profiles (see CARD-TF
1).

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

4 IHE Transactions
This section defines each IHE transaction in detail, specifying the standards used, theinformation transferred, and the conditions under which the transaction is required or optional.

4.1 Modality Procedure Step In Progress [CARD-1]
This transaction is identical to Modality Procedure Step In Progress [RAD-6] (see RAD-TF 2:
4.6), with the addition of one option.
Also please see Appendix A: Clarification of MPPS for Intermittently Connected Modality
4.1.1 Multi-Modality Procedure Update Option
It is essential in the multi-modality environment for all modalities to have the same patient andRequest Procedure identifiers. However, due to the frequent emergency nature of cathprocedures, it is often impossible for the DSS/OF to prepare Scheduled Procedure Steps inadvance of the start of the procedure. See CARD-TF-1: Appendix B.
When a DSS/OF supports the MULTI-MODALITY PROCEDURE UPDATE option, it shall use
the first Modality Procedure Step In Progress that it receives for each Study Instance UID fromdesignated modalities to create Scheduled Procedure Steps for all the modalities that may
participate in that lab. This may also involve the automatic creation of a Requested Procedure
for an unscheduled Procedure Step.
The DSS/OF shall support configuration of the set of modality stations associated with a lab(room), and the designation of one or more of them as a selector (or triggering) modality. It shallalso support configuration of a default Procedure type (code and/or description) for that lab.
Note: The default Procedure type is not constrained to a single value for each lab (e.g., it may
be selected from a set based on attributes such as protocol in the MPPS).
4.1.1.1 Expected Actions
If the Modality Procedure Step In Progress identifies a Requested Procedure, the DSS/OF shallcreate the associated Scheduled Procedure Steps for the modality devices present in that lab (ifsuch SPSs do not already exist for the Requested Procedure).
If the Modality Procedure Step In Progress is unscheduled, the DSS/Order Filler shall
automatically create a Requested Procedure (with the configured default Procedure type for thatlab) based on the Patient ID and the Study Instance UID provided in the MPPS. The DSS/OF
shall create the associated Scheduled Procedure Steps for all the modalities in that lab.
Note: In the Modality Procedure Step In Progress transaction, the Requested Procedure is
identified in the Referenced Study Sequence in the Scheduled Step Attributes Sequence.
If the Referenced Study Sequence is zero length, the Performed Procedure Step isunscheduled. See RAD-TF-2: 4.6.4.1.3 and RAD-TF-2: Appendix A.
__________________________________________________________________________
17
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
When the Requested Procedure is automatically created in the unscheduled case, and there is anexisting ADT record for the patient, the DSS/OF shall generate and submit a new order to theOrder Placer, as specified in the Filler Order Management (New Order) transaction, and shallthen send a Procedure Scheduled transaction to the Image Manager. If there is no existing
patient ADT record (i.e., the modality provided a temporary patient ID), the DSS/OF does notsend 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 scopeof the Order Placer.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

4.2 Modality Images/Evidence Stored [CARD-2]
This transaction is identical to Modality Images Stored [RAD-8] and Evidence Documents
Stored [RAD-43] (see RAD-TF 2: 4.8 and RAD-TF 3: 4.43), with the addition of several
options.
4.2.1 Cardiac Cath Option
Image Archives supporting the CARDIAC CATH option are required to support all of the SOPclasses listed in Table 4.2-1 below.
Table 4.2-1. Cardiac Cath SOP Classes
SOP Class UID

SOP Class Name

1.2.840.10008.5.1.4.1.1.7

Secondary Capture Image Storage

1.2.840.10008.5.1.4.1.1.7.2

Multi-Frame Grayscale Byte Secondary Capture

1.2.840.10008.5.1.4.1.1.7.3

Multi-Frame Grayscale Word Secondary Capture

1.2.840.10008.5.1.4.1.1.6.1

Ultrasound Image Storage

1.2.840.10008.5.1.4.1.1.3.1

Ultrasound Multi-frame Image Storage

1.2.840.10008.5.1.4.1.1.9.1.2

General ECG Waveform Storage

1.2.840.10008.5.1.4.1.1.9.2.1

Hemodynamic Waveform Storage

1.2.840.10008.5.1.4.1.1.12.1

X-Ray Angiographic Image Storage

1.2.840.10008.5.1.4.1.1.88.11

Basic Text SR

1.2.840.10008.5.1.4.1.1.88.22

Enhanced SR

1.2.840.10008.5.1.4.1.1.88.33

Comprehensive SR

1.2.840.10008.5.1.4.1.1.88.40

Procedure Log Storage

Image Archives supporting the CARDIAC CATH option shall be able to negotiate and accept
the JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image
Compression for Ultrasound Multi-frame images, and shall support the YBR_FULL_422
photometric interpretation.
4.2.2 Echocardiography Option
Image Archives supporting the ECHOCARDIOGRAPHY option shall be able to negotiate andaccept the JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image
Compression for Ultrasound Multi-frame images, and shall support the YBR_FULL_422
photometric interpretation.
Image Archives supporting the ECHOCARDIOGRAPHY option are required to support all of
the SOP classes listed in Table 4.2-5. Acquisition Modalities supporting the
ECHOCARDIOGRAPHY option are required to support Ultrasound Multi-frame Image Storage.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
Table 4.2-5. Echocardiography SOP Classes
SOP Class UID

SOP Class Name

1.2.840.10008.5.1.4.1.1.7

Secondary Capture Image Storage

1.2.840.10008.5.1.4.1.1.6.1

Ultrasound Image Storage

1.2.840.10008.5.1.4.1.1.3.1

Ultrasound Multi-frame Image Storage

1.2.840.10008.5.1.4.1.1.88.59

Key Object Selection

1.2.840.10008.5.1.4.1.1.88.11

Basic Text SR

1.2.840.10008.5.1.4.1.1.88.22

Enhanced SR

1.2.840.10008.5.1.4.1.1.88.33

Comprehensive SR

4.2.3 Stress Echo Option
Two mechanisms are required by IHE for conveying Stage and View identification in stress echo
image SOP Instances:− Numbers: Stage Number (0008,2122) and View Number (0008,2128) number Stages andViews, starting with 1.
− Code Sequences: Stage Code Sequence (0040,000A) and View Code Sequence(0054,0220) provide standard coded identifiers for Stages and Views.
A Stage is a phase in the stress echo exam protocol. A View is a particular combination of thetransducer position and orientation at the time of image acquisition.
An additional option mechanism is defined in the DICOM Standard, but not required in IHE:
− Names: Stage Name (0008,2120) and View Name (0008,2127) specify non-standardized
textual names for Stages and Views.
While View Name (0008,2127) and Stage Name (0008,2120) enable correlating and labeling theimages for display, their value sets are undefined. Therefore, IHE requires the use of coded
identifiers to unambiguously describe the stage and view in the Stage Code Sequence and View
Code Sequence.
Acquisition Modality actors supporting the STRESS ECHO option are required to support a
number of attributes in Multiframe Ultrasound Images created for a stress echo procedure as
described in the following Table 4.2-2. Many of these requirements build on attributes which are
Type 2 or Type 3 in DICOM (such attributes are indicated with R+).
Table 4.2-2. Multiframe Ultrasound Image Attributes That Convey Staged Protocol
Related Information
Attribute Name

Tag

Requirement

Performed Procedure Step Description(0040,0254)

R+

Protocol Name

(0018,1030)

R+__________________________________________________________________________
20
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
Attribute Name

Tag

Requirement

Performed Protocol Code Sequence(0040,0260)

R+

Number of Stages(0008,2124)

R+

Number of Views in Stage(0008,212A)

R+

Stage Code Sequence(0040,000A)

R+ (note 2)

Stage Number(0008,2122)

R+

View Number(0008,2128)

R+ (note 1)

View Code Sequence(0054,0220)

R+ (note 2)

Notes: 1. Extra-protocol images (i.e., images not associated with the stress echo exam protocol) shallhave the View Number empty or omitted.
2. View Code Sequence uses a pre-coordinated code as specified in DICOM change proposal
CP 476; this change proposal was formally adopted in January 2005.

The Performed Protocol Code Sequence for stress test procedures shall use codes drawn from thesubset of DICOM Context Group 12001 shown in Table 4.2-3.
Table 4.2-3. Ultrasound Stress Protocol Codes
Coding Scheme
Designator(0008,0102)

Code Value(0008,0100)

Code Meaning(0008,0104)

SRT

P5-B3050

Exercise stress echocardiography

SRT

P5-B3051

Maximal stress echocardiography

SRT

P5-B3052

Submaximal stress echocardiography

SRT

P5-B3053

Treadmill exercise stress echocardiography

SRT

P5-B3054

Bruce treadmill stress echocardiography

SRT

P5-B3055

Modified Bruce treadmill stress echocardiography

SRT

P5-B3056

Naughton treadmill stress echocardiography

SRT

P5-B3058

Bicycle exercise stress echocardiography

SRT

P5-B3060

Echocardiography with administered drug stress

SRT

P5-B3061

Dobutamine stress echocardiography

SRT

P5-B3062

High dose dobutamine stress echocardiography

SRT

P5-B3063

Low dose dobutamine stress echocardiography

SRT

P5-B3065

Arbutamine stress echocardiography

SRT

P5-B3066

Dipyridamole stress echocardiography

Adapted from DICOM PS3.16-2006__________________________________________________________________________
21
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________The Stage Code Sequence shall use codes drawn from the subset of DICOM Context Group
12002 shown in Table 4.2-4, supplemented by additional codes as necessary for the performed
stress echo protocol.
Table 4.2-4. Ultrasound Staged Protocol Stage Codes
Coding Scheme
Designator(0008,0102)

Code Value(0008,0100)

Code Meaning(0008,0104)

SRT

P5-01201

Image acquisition at baseline

SRT

P5-01202

Pre-stress image acquisition

SRT

P5-01203

Mid-stress image acquisition

SRT

P5-01204

Peak-stress image acquisition

SRT

P5-01205

Image acquisition during recovery

Adapted from DICOM PS3.16-2006
The View Code Sequence shall use the codes of DICOM Context Group 12226 (see Table 4.25).
Table 4.2-5. DICOM Context Group 12226 Echocardiography Image View
Coding Scheme
Designator

Code Value

Code Meaning

SRT

G-A19B

Apical two chamber

SRT

G-A19CApical four chamber

SRT

G-0395

Apical long axis

SRT

G-0396

Parasternal long axis

SRT

G-0397

Parasternal short axis

SRT

G-0398

Parasternal short axis at the aortic valve level

SRT

G-0399Parasternal short axis at the level of the mitral chords

SRT

G-039A

Parasternal short axis at the Mitral Valve level

SRT

G-039B

Parasternal short axis at the Papillary Muscle level

SRT

G-039C

Right Ventricular Inflow Tract View

SRT

G-039D

Right Ventricular Outflow Tract View

SRT

G-039E

Subcostal long axis

SRT

G-039F

Subcostal short axis

SRT

G-03A0Suprasternal long axis

SRT

G-03A1Suprasternal short axis

Adapted from DICOM PS3.16-2006__________________________________________________________________________
22
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
4.2.4 Cath Evidence Option
Acquisition Modality and Evidence Creator actors supporting the CATH EVIDENCE option are
required to support one or more of the SOP classes listed in Table 4.2-6 below.
Table 4.2-6. Cath Evidence SOP Classes
SOP Class UID

SOP Class Name

1.2.840.10008.5.1.4.1.1.88.22

Enhanced SR

1.2.840.10008.5.1.4.1.1.88.33

Comprehensive SR

1.2.840.10008.5.1.4.1.1.88.40

Procedure Log

IHE defines the following criteria for setting the value of the Completion Flag (0040,A491) in
SR evidence documents:
Completeness of an SR evidence document is defined in relation to the scope of theRequested Procedure and the scope of the Root Concept Name. I.e., a Completion Flag
(0040,A491) value of “COMPLETE” indicates that the document content includes all
significant observations within the topic of the root Concept Name (as restricted by any
Concept Modifiers) that are related to the Requested Procedure identified in the Referenced
Request Sequence (0040,A370). A Requested Procedure may thus have multiple Complete
SR Documents on different topics.
A document may be indicated as Complete only when the content has been attested orverified by an authorized user as meeting these criteria, and the user is identified in the SR
Document Instance.
Notes: 1.See DICOM PS3.3-2006, Section C.17.2.5, for discussion of attestation and verification.
2. Implementations are encouraged to use or reference this definition of Completeness in their
DICOM Conformance Statements.

The Acquisition Modality or Evidence Creator actor shall use one or more of the Templates
listed in Table 4.2-7 below.
Table 4.2-7. Cath Evidence Templates
Cath Evidence Templates
3001 Procedure Log
3202 Ventricular Analysis
3213 Quantitative Arterial Analysis
3250 Intravascular Ultrasound3500 Hemodynamics__________________________________________________________________________
23
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
These templates use subsidiary Template 300 for the formatting of individual measurements.
Template 300 provides for the encoding of a “Normality” flag (for abnormal values) throughsubsidiary Template 310, and for the encoding of the specific image source of the measurement
through subsidiary Template 320. IHE strongly recommends the use of these attributes whereappropriate.
4.2.5 Echo Evidence Option
Acquisition Modality and Evidence Creator actors supporting the ECHO EVIDENCE option are
required to support one or more of the SOP classes listed in Table 4.2-8 below.
Table 4.2-8. Echo Evidence SOP Classes
SOP Class UID

SOP Class Name

1.2.840.10008.5.1.4.1.1.88.22

Enhanced SR

1.2.840.10008.5.1.4.1.1.88.33

Comprehensive SR

The Acquisition Modality or Evidence Creator actor shall use one or more of the Templates
listed in Table 4.2-9 below.
Table 4.2-9. Echo Evidence Templates
Echo Evidence Templates
5100 Vascular Ultrasound5200 Echocardiography

These templates use subsidiary Template 300 for the formatting of individual measurements.
Template 300 provides for the encoding of a “Normality” flag (for abnormal values) throughsubsidiary Template 310, and for the encoding of the specific image source of the measurement
through subsidiary Template 320. IHE strongly recommends the use of these attributes whereappropriate.
See Section 4.2.4 for the IHE criteria for setting the value of the Completion Flag (0040,A491)
in SR evidence documents.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

4.3 Storage Commitment [CARD-3]
This transaction is identical to Storage Commitment [RAD-10] (see RAD-TF 2: 4.10), with theaddition of one option.
4.3.1 Intermittently Connected Modality Option
An INTERMITTENTLY CONNECTED MODALITY option is specified for the ImageManager, under which the Image Manager must queue N-Event Report messages if the modality
is not connected. The modality opening an Association (message channel) for Storage
Commitment shall serve as a trigger for the Image Manager to open a separate Association to theModality to send the queued N-Event Report messages. This option is required for the Cath
Workflow and Echo Workflow Profiles.
The purpose of this option is to alleviate the mobile devices from filling up their local storage
with images that are awaiting Storage Commitment response (indicating that the Image Manager
has successfully taken responsibility for the associated set of images) prior to deletion. The
Storage Commitment response cannot be received if the mobile device is not connected at thetime in which the Image Manager attempts to send the N-Event Report.
This option requires the Image Manager to send the N-Event Report message to the mobile
modality at the time that it reconnects to the Image Manager.
4.3.1.1 Trigger Events
The following event shall trigger queued N-Event Reports for the mobile device:• The acquisition modality makes a successful Association Negotiation with the ImageManager that has N-Event Reports pending
Note: The need to handle intermittently connected modalities applies equally to the ImageManager under the RAD-TF Scheduled Workflow Profile, but the RAD-10 transaction issilent on the manner. There are several possible approaches to meeting this requirement,
some of which require functionality on the Image Manager side of the transaction, someon Modality side. Without a clear specification, there will be significant interoperability
problems.
The IHE Cardiology Technical Committee has specified this Image Manager side
approach to minimize the complexity of implementation for the Modalities, and tominimize the differences in the overall data flow between the intermittently and the fulltime connected environments. The IHE Cardiology Technical Committee recognizes theimpact this may have on radiology, but determined that a definitive resolution was critical
for the Echocardiography Workflow Profile in the Cardiology Technical Framework. The
IHE Cardiology and Radiology Technical Committees will work towards resolution of acommon approach.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

4.4 Retrieve Images/Evidence [CARD-4]
This transaction is identical to Retrieve Images [RAD-16] and Retrieve Evidence Documents[RAD-45] (see RAD-TF 2: 4.16 and RAD-TF 3: 4.45), with the addition of several options.
4.4.1 Stress Echo Option
Image Display actors supporting the STRESS ECHO option shall be able to negotiate and accept
the JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image
Compression for Ultrasound Multi-frame images, and shall support the YBR_FULL_422
photometric interpretation.
Image Display actors supporting the STRESS ECHO option are required to support all of the
SOP classes listed in Table 4.4-1 below.
Table 4.4-1. Stress Echo Image SOP Classes
SOP Class UID

SOP Class Name

1.2.840.10008.5.1.4.1.1.6.1

Ultrasound Image Storage

1.2.840.10008.5.1.4.1.1.3.1

Ultrasound Multi-frame Image Storage

Image Display actors supporting the STRESS ECHO option are required to support all of theattributes listed in Table 4.4-2 below in ultrasound images.
Table 4.4-2. Stress Echo Display Attributes
Attribute Name

Tag

Requirement

Performed Protocol Code Sequence(0040,0260)

R+*>Code Meaning(0008,0104)

R+ (see note)

Protocol Name

(0018,1030)

R+ (see note)

Number of Stages(0008,2124)

R+

Number of Views in Stage(0008,212A)

R+

Stage Code Sequence(0040,000A)R+*>Code meaning(0008,0102)

R+

Stage Number(0008,2122)

R+

View Code Sequence(0054,0220)

R+*>Code Meaning(0008,0104)

R+

View Number(0008,2128)

R+

Note: The Performed Protocol Code Sequence Code Meaning attribute and the Protocol Nameattribute should contain similar information. If both are present in the image, Protocol
Name (rather than Performed Protocol Code Sequence Code Meaning) shall be displayed.
__________________________________________________________________________
26
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

4.4.1.1 Expected Actions
The Image Display actor may organize and present multiple images based on Stage and View forclinical comparison. Stage Number (0008,2122), View Number (0008,2128), Stage Code
Sequence (0040,000A), and View Code Sequence (0008,2240) are mandated for the stress echo
Modality (see section 4.2.3), and may be used by the Image Display Actor to determine theStage and View of each image unambiguously.
4.4.2 Cath Evidence Option
Image Display actors supporting the CATH EVIDENCE option are required to support all of the
SOP classes listed in Table 4.4-5 below.
Table 4.4-5. Cath Evidence SOP Classes
SOP Class UID

SOP Class Name

1.2.840.10008.5.1.4.1.1.88.22

Enhanced SR

1.2.840.10008.5.1.4.1.1.88.33

Comprehensive SR

1.2.840.10008.5.1.4.1.1.88.40

Procedure Log

4.4.2.1 Expected Actions
The Image Display actor may optimize display for the Templates listed in Table 4.2-7 above.
Note:

An Image Display that supports a DICOM SR SOP Class is required (by the DICOM
Standard) to unambiguously render all legal SOP Instances within that SOP Class, regardlessof the Template used to create it. See DICOM PS3.4 Annex O.

Any measurements that have a subsidiary “HAS PROPERTIES” Content Item with Concept
Name (121402, DCM, “Normality”) and a Value from Table 4.4-6 shall be rendered with areadily visible emphasis (e.g., font, bold, text or background color, specialized window area,etc.).
Table 4.4-6. DICOM Context Group 222 Abnormal Value Flag codes
Coding Scheme

Code Value

Code Meaning

SRT

R-42037

Abnormal

SRT

R-002C4

Abnormally High

SRT

R-002C5

Abnormally Low

Adapted from DICOM PS3.16-2006__________________________________________________________________________
27
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

4.4.3 Echo Evidence Option
Image Display actors supporting the ECHO EVIDENCE option are required to support all of the
SOP classes listed in Table 4.2-7 below.
Table 4.4-7. Echo Evidence SOP Classes
SOP Class UID

SOP Class Name

1.2.840.10008.5.1.4.1.1.88.22

Enhanced SR

1.2.840.10008.5.1.4.1.1.88.33

Comprehensive SR

4.4.3.1 Expected Actions
The Image Display actor may optimize display for the Templates listed in Table 4.2-9 above.
Note:

An Image Display that supports a DICOM SR SOP Class is required (by the DICOM
Standard) to unambiguously render all legal SOP Instances within that SOP Class, regardlessof the Template used to create it. See DICOM PS3.4 Annex O.

Any measurements that have a subsidiary “HAS PROPERTIES” Content Item with Concept
Name (121402, DCM, “Normality”) and a Value from Table 4.4-6 shall be rendered with areadily visible emphasis (e.g., font, bold, text or background color, specialized window area,etc.).

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

4.5 Retrieve ECG List [CARD-5]
This transaction is derived from Retrieve Specific Information for Display [ITI-11] (see ITI-TF2: 3.11), but is an independent transaction.
4.5.1 Scope
This transaction involves the query for a list of ECG documents, primarily for presentation
purposes. This may occur when a user attempts to lookup ECGs associated with a certain patientthat are stored on a different system. Note that the retrieved list is always related to a wellidentified patient (Patient ID), but its content is generally dynamic (i.e., retrieving the same Listat a different point in time is likely to result in different content); for example, a new ECG may
have been recorded between two requests.
To support a wide range of display capabilities, the information provided is formatted as XML
with a reference to a default style sheet. The XML format shall be done according to the schema
specified in Appendix C, and is explicitly harmonized with the HL7 v3 Reference Information
Model.
4.5.2 Use Case Roles

Display

Information Source

Retrieve ECG List

Actor: Display
Role: A system that requests an ECG list, and displays it.
Actor: Information Source
Role: A system that provides ECG lists in response to the request from the Display Actor, in apresentation-ready format.
4.5.3 Referenced Standard
Please refer to ITI-TF-2: 3.11.3, Referenced Standards__________________________________________________________________________
29
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
4.5.4 Interaction Diagram
Information Source

Display
Request For ECG List
Response With ECG List

Figure 4.5-1 Request for ECG List

4.5.4.1 Request For ECG List
4.5.4.1.1 Trigger Events
The following event will trigger a Request for ECG List:• User of the Display Actor needs to review a list of ECGs that are part of a patient’s
clinical history with the intent of selecting a specific ECG off the list for subsequent
retrieval as a persistent object via the Retrieve ECG for Display Transaction
4.5.4.1.2 Message Semantics
Please refer to ITI-TF-2: 3.11.4.1.2, Message Semantics for Request for Specific Information –Summary message.
ITI-TF-2: 3.11.4.1.2 Table 3.11.4-2 lists the web service request types for ITI-11. Thistransaction shall support the request type listed in Table 4.5.4-1.
Table 4.5.4-1 Web Service Request TypesrequestType value
SUMMARY-CARDIOLOGY-ECG

Description
List of ECG documents

4.5.4.1.3 Expected Actions
Please refer to ITI-TF-2: 3.11.4.1.3, Expected Actions for Request For Specific Information –Summary message.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
4.5.4.2 Response with ECG List
4.5.4.2.1 Trigger Events
This message is sent by the Information Source Actor in response to the Request For ECG List
web service request.
4.5.4.2.2 Message Semantics
The Information Source Actor shall support the requestType parameters specified in section
4.5.4.1.2.
Note:

The Retrieve ECG for Display Profile requires the Information Source Actor to also support
the SUMMARY and SUMMARY-CARDIOLOGY options of the Retrieve SpecificInformation [ITI-11] transaction. If the Information Source Actor only manages ECGs, its
response to SUMMARY, SUMMARY-CARDIOLOGY, and SUMMARY-CARDIOLOGYECG will have the same content (but different formats). However, if it manages other types of
documents, it responds with only a list of ECG documents in response to a SUMMARYCARDIOLOGY-ECG request. It always includes ECG documents it manages when
responding to SUMMARY and SUMMARY-CARDIOLOGY requests.

The Information Source shall set an expiration of zero to ensure no caching. The message shallbe formatted according the XML schema defined in Appendix C. The XML shall reference a
default server-side style sheet so the Display Actor can display the list without further
processing. Appendix C includes an example style sheet, but that particular one is not required.
Appendix C also includes a sample XML instance to help illustrate how the list shall beformated.
The Display Actor may request the Information Source Actor to provide a list of documents ofdifferent types pertaining to a particular patient. The exact content of the list is determined by the
Information Source Actor and may be regulated by the institution policy. It shall contain thehyperlink to a persistent object so that it can be retrieved by using the Retrieve ECG For Display
Transaction. The link shall be formatted as a web service request in accordance with therequirements in Section 4.6. It may also contain other hyperlinks representing the invocation ofother services.
4.5.4.2.3 Expected Actions
The Display Actor shall render the received response for the user. Note that the contents of thelist may be parsed for specific data to enable more advanced display applications.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

4.6 Retrieve ECG Document for Display [CARD-6]
This transaction is derived from Retrieve Document for Display [ITI-12] (see ITI-TF-2: 3.12).
4.6.1 Scope
This transaction involves the retrieval of an ECG document (persistent object) for presentation
purposes. The uniquely identifiable persistent object means that retrieving the same document
instance at a different point in time will provide the same semantics for its presented content.
The information content of the document is immutable even if the presentation of such content isprovided with the use of different formats, stylesheets, etc.
4.6.2 Use Case Roles
Please refer to ITI-TF-2: 3.12.2, Use Case Roles for Retrieve Document for Display transaction.
4.6.3 Referenced Standard
Please refer to ITI-TF-2: 3.12.3, Referenced Standards for Retrieve Document for Displaytransaction.
4.6.4 Interaction Diagram
Please refer to ITI-TF-2: 3.12.4, Interaction Diagram for Retrieve Document for Displaytransaction.
4.6.4.1 Request For ECG Document
4.6.4.1.1 Trigger Events
The request for a document is triggered when a user of the Display Actor needs to review aparticular document that is stored by the Information Source Actor.
4.6.4.1.2 Message Semantics
The Retrieve ECG Document for Display transaction is performed by the invocation of a web
service. The Display Actor shall generate the web service request whenever a user needs toreview the document stored as part of a patient’s clinical history on the Information Source
Actor.
Note: For comparison, please refer to ITI-TF-2: 3.12.4.1.2, Message Semantics for Request for
Persistent Document message. With repect to that transaction, this transaction has thefollowing differences in sematics:
1. In addition to accepting OIDs as the value for a documentUID, this transaction allows
persistent ECG documents to be referenced by UUID.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
2. Instead of the content types listed in ITI-TF-2 Tables 3.12.4-1 and 3.12.4-3, thistransaction allows only the content types “Application/pdf” and “Image/svg+xml”.
The web service request shall include the following parameters (keys) to identify the document
to be returned and its format. See Table 4.6.4-1.
Table 4.6.4-1 Query Keys
Parameter Name REQ

Description

ValuesrequestType

R

This parameter is required to have avalue of “DOCUMENT”.

“DOCUMENT”

documentUID

R

Identifies document’s UID as known toboth actors.

This value shall be a properly defined Object
identifier (OID) as specified in ITI-TF-2,
Appendix B, or a Universal Unique identifier(UUID) as specified in DCE 1.1 RPC (seenote).

preferredContentType

R

This parameter is required to identify
the preferred format in which the
document is to be provided (as MIME
content type).

Display may specify one of the following
formats:

Note:

Application/pdf (see note)
Image/svg+xml

See IANA registry for details about PDF, such as version. Applications creating PDF may use
this MIME type for other versions of PDF up to 1.3. Receivers shall support documents
encoded in this version and previous versions.
The UUID is specified in Open Group, DCE 1.1 Remote Procedure Call specification,
Appendix A (http://www.opengroup.org/onlinepubs/9629399/apdxa.htm).

Formal definition of the web service in WSDL is provided in Appendix B.
The only binding required for both the Display Actor and Information Source Actor is thebinding to the HTTP-GET. In this binding the sample message will be formatted as follows:
http://<location>/<IHERetrieveDocument>?requestType=DOCUMENT&documentUID=1.2.3&preferredContentType=application%2fpdf
where <location> is the address of the service specified in the <service> tag of WSDL definition.
IHERetrieveDocument is the operation location specified in the <operation> tag of the WSDL
definition. This location shall be implementation-independent.
In addition, the Display Actor shall support the following fields of the HTTP protocol for request
and response:__________________________________________________________________________
33
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
Table 4.6.4-2 HTTP Request and Response Fields
HTTP
Field
AcceptREQ
O

Description

ValuesThis field is used to specify certain media
types which are acceptable for the response

At least one of the following values:
Application/pdf
Image/svg+xml*/*
Other values may be included as well

AcceptLanguage

O

This field is similar to Accept, but restricts theset of natural languages that are preferred as a
response to the request.

Any valid value according to RFC2616

Expires

R

This field gives the date/time after which the
response is considered stale

Any valid value not to exceed one week

The Display Actor shall provide list of content types it supports in the HTTP Accept field. If the
HTTP Accept Field is absent, it means that any content type is acceptable by the Display Actor.
The preferredContentType parameter shall specify the content type desired by the Display Actor.
The value of the preferredContentType parameter of the request shall be one of the values fromthe Table 4.6.4-1 and shall not contradict values specified in the HTTP Accept field.
The Information Source shall provide info in preferredContentType if capable, otherwise it shall
only use a type specified in the Accept Field as appropriate given the information to be returned.
If necessary, the Display Actor may perform the request to the web service utilizing HTTPS
protocol.
4.6.4.1.3 Expected Actions
Please refer to ITI-TF-2:3.12.4.1.3, Expected Actions for Request for Persistent Document
message.
The Information Source may provide an HTTP Redirect response of 301 - Moved Permanently,
302 – Found, 303 – See Other, or 307 – Temporary Redirect. The Display Actor shall issue an
HTTP GET to the redirect target URI, but if a loop is detected, it may report an error..
4.6.4.2 Delivery of ECG Document
4.6.4.2.1 Trigger Events
Please refer to ITI-TF-2: 3.12.4.2.1, Trigger Events for Delivery of Persistent Document
message.
4.6.4.2.2 Message Semantics
Please refer to ITI-TF-2: 3.12.4.2.2, Message Semantics for Delivery of Persistent Document
message.
__________________________________________________________________________
34
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
ECG documents retrieved using this transaction must meet the following minimum
requirements:
4.6.4.2.2.1 Minimum Demographics
The ECG document shall include at the least the patient’s name and patient’s ID. The
Cardiology Technical Framework does not support the delivery of anonymous ECG documentsin this transaction.
4.6.4.2.2.2 Minimum Recording Context
The ECG document shall state when the ECG waveforms were recorded from the patient. The
document shall include the date and time (to the resolution recorded by the device) of therecording. It is assumed the date/time is local to wherever the recording was made, unlessspecific timezone information is provided.
4.6.4.2.2.3 Minimum Waveform Fidelity
ECG documents that include waveforms shall encode those waveforms at diagnostic quality.
Note:

There is no standard for diagnostic quality of softcopy ECG display. The ANSI/AAMI EC11-1991 standard specifies diagnostic quality for hardcopy recording of ECGs. It is the
responsibility of the document source to provide equivalent quality, presuming typicalpersonal computer display capabilities.

4.6.4.2.2.4 Minimum Waveform Information
ECG waveforms shall include an indication of voltage and time scale by usage of standard
calibration pulse (1 mV high, 200 ms wide), and a nominal 1 mm grid. Statements about
mm/time and mm/mV, e.g. “25 mm/s 10 mm/mV” are recommended, but are optional. If
different leads have different gains (e.g., precordial chest leads at half gain), sufficient
information must be given to determine the gain of each lead.
The actual size of the displayed ECG document is under control of the user at the display client.
Thus, the information source cannot control that the nominal 1 mm squares on the backgroundgrid are always displayed as a 1 mm square on the screen of the display device. The aspect ratio
shall be fixed, so that the grid squares will always be displayed as squares, not rectangles; achange in aspect ratio may make the ECG interpretation difficult for those accustomed to reading
ECGs at the standard 1 mm x 1 mm fixed aspect ratio. There should be major axes every 5 mmin both dimensions drawn with darker or thicker lines, corresponding to 200 ms and 500 uV
when the report scaling is 25mm/s and 10 mm/mV. The minor axes at 1 mm intervals (at 40 ms
and 100 uV when the report scaling is 25 mm/s and 10 mm/mV) may be drawn using fainter or
thinner lines, or by using small “dots”.
ECG waveforms shall include lead labels. The rendered waveform shall include an indication
denoting the transition from one lead to the next in a waveform “line”.
ECG waveforms shall include statement of frequency content, e.g. “0.05 – 150 Hz”.
__________________________________________________________________________
35
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________
4.6.4.2.2.5 Minimum Interpretation Information
If the interpretation statements are included, the ECG document shall also include a statement if
interpretation is confirmed or unconfirmed, e.g., “Unconfirmed Report”, “Confirmed Report”.
4.6.4.2.2.6 Required Request Types
Information Source must support the Application/pdf format.
To meet the waveform quality requirements, the Information Source shall use vector graphics tominimize aliasing effects. This means the Information Source shall generate PDF “content” (i.e.,
vector drawing commands) to be rendered on the display device, versus generating a PDF“image” (i.e., a rasterized bitmap). To do this, the Information Source needs to generate the PDF
content using PDF vector drawing commands.
Note:

There exist a number of tools available for this purpose, including the Adobe PDF Library
SDK, and libraries from other vendors such as PDFLIB (www.pdflib.com). Many common
PDF tools (e.g., current versions of Adobe Acrobat Distiller) do not create vector drawing
commands.

The Information Source may additionally support the Image/svg+xml MIME type format.
Note:

Scalable Vector Graphics (SVG) is well suited to this application, but requires an SVG
browser plugin (such as the Adobe SVG plugin for Internet Explorer). An XML document
using SVG has the capability for embedding JavaScript commands, which could be used for
local reformatting of the ECG image (such as changing the format from 3x4 1R to 6x2, etc.).

Note that applications that serve ECGs using raster formats do not conform to this transaction,
but may conform to the Retrieve Information for Display Profile.
4.6.4.2.3 Expected Actions
Please refer to ITI-TF-2: 3.12.4.2.3, Expected Actions for Delivery of Persistent Document
message.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

4.7 Encapsulated Report Submission [CARD-7]
This section reserved.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

4.8 Report Reference Submission [CARD-8]
This section reserved.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

4.9 Encapsulated Report Storage [CARD-9]
This section reserved.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

4.10 Encapsulated Report Query [CARD-10]
This section reserved.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

4.11 Encapsulated Report Retrieve [CARD-11]
This section reserved.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

Appendix A:
Modality

Clarification on MPPS for Intermittently Connected

When an Acquisition Modality is only intermittently connected to the network, in particularwhen it is not connected during the performance of a procedure, it may not be able to send
Modality Procedure Step In Progress [CARD-1 and RAD-6] and Modality Procedure Step
Completed [RAD-7] transactions in real time.
The trigger events for these transactions (user begins or completes a procedure step) remain thesame as specified in those transaction definitions, but the message remains queued fortransmission until the modality reconnects to the network.
The Acquisition Modality shall send both an MPPS N-CREATE (with status IN PROGRESS)and an MPPS N-SET (with status COMPLETED or DISCONTINUED) message. The
Acquisition Modality shall not send the MPPS N-SET until is receives a response from the
Performed Procedure Step Manager for the MPPS N-CREATE.
The expected actions of the Performed Procedure Step Manager, DSS/OF, and Image Manager
are the same as specified in the Modality Procedure Step In Progress and Modality Procedure
Step Completed transaction definitions.

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

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

Appendix B:
Web Service Definition for Retrieve ECG for Display
Transaction
The following is the WSDL definition of web services used in the Transactions CARD-5 and
CARD-6. Note that there are portions of this definition that need to be replaced during
implementation, such as the service location, which is here bound to http://localhost/. Also, thedefinitions of summaryRequestType, listRequestType and contentType shall correspond to thecapabilities of the Information Source Actor.
<?xml version="1.0" encoding="utf8"?><definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:s0="http://rsna.org/ihe/IHERetrieveForDisplay"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://rsna.org/ihe/IHERetrieveForDisplay"
xmlns="http://schemas.xmlsoap.org/wsdl/"><!-- Defines the types available for the parameters --><!-- May also include the return type defintiions --><types><s:schema elementFormDefault="qualified"targetNamespace="http://rsna.org/ihe/IHERetrieveForDisplay"><!-- Add any items that control the returned values list or type here --><!-- Add or remove items in the actual supplied WSDL to show the available types. --><s:simpleType name="summaryRequestType"><s:restriction base="s:string"><s:enumeration value="SUMMARY" /><s:enumeration value="SUMMARY-CARDIOLOGY" /><s:enumeration value="SUMMARY-CARDIOLOGY-ECG" /></s:restriction></s:simpleType><!-- Please list all content types available, and remove those not available. --><s:simpleType name="contentType"><s:restriction base="s:string"><s:enumeration value="text/html" /></s:restriction></s:simpleType><!-- Indicates that this item is a returned rows restriction --><s:simpleType name="ReturnedResultCount" type="s:positiveInteger" /><!-- Please use the string "Search" as a prefix for all search criteria, and list below --><!-- Indicates that this item is a search string --><s:simpleType name="SearchString" type="s:string" /></s:schema></types><message name="RetrieveSummaryInfoHttpGetIn"><!-- Add other parameters here if they are available, using types defined above. --><part name="requestType" type="summaryRequestType" /><part name="patientID" type="SearchString" /><part name="lowerDateTime" type="s:dateTime" /><part name="upperDateTime" type="s:dateTime" /><part name="mostRecentResults" type="ReturnedResultCount" /></message>__________________________________________________________________________
43
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________<message name="RetrieveSummaryInfoHttpGetOut"><!-- If a complex type is defined for the return value, then it is suggested that --><!-- it be used here instead of s0:string. If a complex type is allowed as one --><!-- of the options, but an arbitrarily formatted string is also allowed, then create --><!-- a union type here that allows either option. --><part name="Body" element="s0:string" /></message><message name="RetrieveDocumentHttpGetIn"><!-- Add other parameters here if they are available, using types defined above. --><!-- It is recommended that one of the sub-types of SearchUID is chosen here --><!-- Especially if SearchStudyUID is allowed, then the display client can know that --><!-- it is permissable to use a dicom uid here --><part name="documentUID" type="SearchString" /><part name="contentType" type="contentType" /></message><message name="RetrieveDocumentHttpGetOut"><!-- If a complex type is defined for the return value, then it is suggested that --><!-- it be used here instead of s:string. If a complex type is allowed as one --><!-- of the options, but an arbitrarily formatted string is also allowed, then create --><!-- a union type here that allows either option. --><part name="Body" element="s:string" /></message><portType name="IHERetrieveForDisplayHttpGet"><operation name="RetrieveSummaryInfo"><input message="s0:RetrieveSummaryInfoHttpGetIn" /><output message="s0:RetrieveSummaryInfoHttpGetOut" /></operation><operation name="RetrieveDocument"><input message="s0:RetrieveDocumentHttpGetIn" /><output message="s0:RetrieveDocumentHttpGetOut" /></operation></portType><binding name="IHERetrieveForDisplayHttpGet" type="s0:IHERetrieveForDisplayHttpGet"><http:binding verb="GET" /><operation name="RetrieveSummaryInfo"><http:operation location="/IHERetrieveSummaryInfo" /><input><http:urlEncoded /></input><output><mime:content type="text/html" /></output></operation><operation name="RetrieveDocument"><http:operation location="/IHERetrieveDocument" /><input><http:urlEncoded /></input><!-- The type of the output should be restricted on a per-server basis to the types --><!-- actually provided. --><output><mime:content type="application/pdf" /><mime:content type="image/svg+xml" /></output></operation></binding><!-- Bind the actual service here --><service name="IHERetrieveForDisplay"><port name="IHERetrieveForDisplayHttpGet" binding="s0:IHERetrieveForDisplayHttpGet">__________________________________________________________________________
44
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________<http:address location="http://localhost/" /></port></service>__________________________________________________________________________
45
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

Appendix C:

ECG List XML Specification

When the list of ECG documents is requested, the list shall be returned as XML. The XML
schema is based on the HL7 V3 Reference Information Model (RIM).
Notes: 1. The following schema and example are available as a zipped file at www.ihe.net andwww.acc.org.
2. The specific codes to be used for document types and statuses are in discussion.
Implementers are advised make these configurable within the applications.

IHEDocumentList(AABB_RM444448)

This contains information about a set of documents
returned from an IHE “Request List of ECGs” request.

0..1 assignedAuthor

AssignedAuthor

authorclassCode*: <= ASSIGNED
id: II [0..1]

typeCode*: <= AUT
noteText: ED [0..1]

Organization
classCode*: <= ORG
determinerCode*: <= INSTANCE
id: II [0..1]
name: ON [0..1]
0..1 providerOrganization

IHEDocumentList

1..1 patient *classCode*: <= ACT
recordTarget
moodCode*: <= EVN
typeCode*: <= RCT
code*: CD CWE [1..1] <=ActCode
activityTime: TS [0..1]

PatientRole
classCode*: <= PAT
id*: II [1..1]

component
typeCode*: <= COMP
0..* documentInformation
0..1 patientPatient

0..1 assignedDevice

DeviceDocumentInformation

PatientclassCode*: <= DEV
determinerCode*: <= INSTANCE
id: II [0..1]
code: CE CWE [0..1] <=EntityCode
manufacturerModelName: SC CWE [0..1] <=ManufacturerModelName
softwareName: SC CWE [0..1] <=SoftwareName

classCode*: <= ACT
moodCode*: <= EVN
id*: II [1..1]
code: CD CWE [0..1] <=ActCode
title: ST [0..1]
text: ED [0..1]
statusCode: CS CNE [0..1]
effectiveTime: TS [0..1]

classCode*: <= PSN
determinerCode*: <= INSTANCE
name: PN [0..1]
administrativeGenderCode: CE CWE [0..1] <=AdministrativeGenderbirthTime: TS [0..1]

C.1

Schema<?xml version="1.0" encoding="UTF-8" standalone="no"?><xs:schema targetNamespace="urn:hl7-org:v3" xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:msg="urn:hl7-org:v3/mif"
xmlns:hl7="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns="urn:hl7-org:v3" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"><xs:include schemaLocation="../dt/datatypes.xsd"/><xs:include schemaLocation="../voc/voc.xsd"/><!-****************************************************************************************************************** XML schema for message type .
* Generated by XMLITS version 1.1, Copyright (C) 2002, 2003 by Health Level 7, Inc.
*
* Copyright (c) 2002, 2003, Health Level Seven. All rights reserved.
* Redistribution and use in source and binary forms, with or without* modification, are permitted provided that the following conditions* are met:
* 1. Redistributions of source code must retain the above copyright__________________________________________________________________________
46
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright* notice, this list of conditions and the following disclaimer in the* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software* must display the following acknowledgement:*This product includes software developed by Health Level Seven.
* THIS SOFTWARE IS PROVIDED BY HEALTH LEVEL SEVEN, INC. AND CONTRIBUTORS "AS IS" AND* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF* SUCH DAMAGE.
*********************************************************************************************************************--><xs:group name="AABB_MT444448"><xs:sequence><xs:element name="IHEDocumentList" type="AABB_MT444448.IHEDocumentList"/></xs:sequence></xs:group><xs:element name="IHEDocumentList" type="AABB_MT444448.IHEDocumentList"/><xs:complexType name="AABB_MT444448.IHEDocumentList"><xs:sequence><xs:element name="code" type="CD"/><xs:element name="activityTime" type="TS" minOccurs="0"/><xs:element name="recordTarget" type="AABB_MT444448.RecordTarget"/><xs:element name="author" type="AABB_MT444448.Author" minOccurs="0"/><xs:element name="component" type="AABB_MT444448.Component" minOccurs="0" maxOccurs="unbounded"/></xs:sequence><xs:attribute name="type" type="Classes" default="ActHeir"/><xs:attribute name="classCode" type="ActClass"/><xs:attribute name="moodCode" type="ActMood"/><xs:attribute name="templateId" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="typeID" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="realmCode" use="optional"><xs:simpleType><xs:list itemType="cs"/></xs:simpleType></xs:attribute><xs:attribute name="nullFlavor" type="cs" use="optional"/></xs:complexType><xs:complexType name="AABB_MT444448.RecordTarget"><xs:sequence><xs:element name="patient" type="AABB_MT444448.PatientRole"/></xs:sequence><xs:attribute name="type" type="Classes" default="Participation"/><xs:attribute name="typeCode" type="ParticipationType"/><xs:attribute name="templateId" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute>__________________________________________________________________________
47
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________<xs:attribute name="typeID" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="realmCode" use="optional"><xs:simpleType><xs:list itemType="cs"/></xs:simpleType></xs:attribute><xs:attribute name="nullFlavor" type="cs" use="optional"/></xs:complexType><xs:complexType name="AABB_MT444448.PatientRole"><xs:sequence><xs:element name="id" type="II"/><xs:element name="patientPatient" type="AABB_MT444448.Patient" minOccurs="0"/><xs:element name="providerOrganization" type="AABB_MT444448.Organization" minOccurs="0"/></xs:sequence><xs:attribute name="type" type="Classes" default="Patient"/><xs:attribute name="classCode" type="RoleClass"/><xs:attribute name="templateId" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="typeID" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="realmCode" use="optional"><xs:simpleType><xs:list itemType="cs"/></xs:simpleType></xs:attribute><xs:attribute name="nullFlavor" type="cs" use="optional"/></xs:complexType><xs:complexType name="AABB_MT444448.Patient"><xs:sequence><xs:element name="name" type="PN" minOccurs="0"/><xs:element name="administrativeGenderCode" type="CE" minOccurs="0"/><xs:element name="birthTime" type="TS" minOccurs="0"/></xs:sequence><xs:attribute name="type" type="Classes" default="Person"/><xs:attribute name="classCode" type="EntityClass"/><xs:attribute name="determinerCode" type="EntityDeterminer"/><xs:attribute name="templateId" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="typeID" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="realmCode" use="optional"><xs:simpleType><xs:list itemType="cs"/></xs:simpleType></xs:attribute><xs:attribute name="nullFlavor" type="cs" use="optional"/></xs:complexType><xs:complexType name="AABB_MT444448.Organization"><xs:sequence><xs:element name="id" type="II" minOccurs="0"/>__________________________________________________________________________
48
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________<xs:element name="name" type="ON" minOccurs="0"/></xs:sequence><xs:attribute name="type" type="Classes" default="Organization"/><xs:attribute name="classCode" type="EntityClass"/><xs:attribute name="determinerCode" type="EntityDeterminer"/><xs:attribute name="templateId" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="typeID" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="realmCode" use="optional"><xs:simpleType><xs:list itemType="cs"/></xs:simpleType></xs:attribute><xs:attribute name="nullFlavor" type="cs" use="optional"/></xs:complexType><xs:complexType name="AABB_MT444448.Author"><xs:sequence><xs:element name="noteText" type="ED" minOccurs="0"/><xs:element name="assignedAuthor" type="AABB_MT444448.AssignedAuthor"/></xs:sequence><xs:attribute name="type" type="Classes" default="Participation"/><xs:attribute name="typeCode" type="ParticipationType"/><xs:attribute name="templateId" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="typeID" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="realmCode" use="optional"><xs:simpleType><xs:list itemType="cs"/></xs:simpleType></xs:attribute><xs:attribute name="nullFlavor" type="cs" use="optional"/></xs:complexType><xs:complexType name="AABB_MT444448.AssignedAuthor"><xs:sequence><xs:element name="id" type="II" minOccurs="0"/><xs:element name="assignedDevice" type="AABB_MT444448.Device" minOccurs="0"/></xs:sequence><xs:attribute name="type" type="Classes" default="RoleHeir"/><xs:attribute name="classCode" type="RoleClass"/><xs:attribute name="templateId" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="typeID" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="realmCode" use="optional"><xs:simpleType><xs:list itemType="cs"/>__________________________________________________________________________
49
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________</xs:simpleType></xs:attribute><xs:attribute name="nullFlavor" type="cs" use="optional"/></xs:complexType><xs:complexType name="AABB_MT444448.Device"><xs:sequence><xs:element name="id" type="II" minOccurs="0"/><xs:element name="code" type="CE" minOccurs="0"/><xs:element name="manufacturerModelName" type="SC" minOccurs="0"/><xs:element name="softwareName" type="SC" minOccurs="0"/></xs:sequence><xs:attribute name="type" type="Classes" default="Device"/><xs:attribute name="classCode" type="EntityClass"/><xs:attribute name="determinerCode" type="EntityDeterminer"/><xs:attribute name="templateId" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="typeID" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="realmCode" use="optional"><xs:simpleType><xs:list itemType="cs"/></xs:simpleType></xs:attribute><xs:attribute name="nullFlavor" type="cs" use="optional"/></xs:complexType><xs:complexType name="AABB_MT444448.Component"><xs:sequence><xs:element name="documentInformation" type="AABB_MT444448.DocumentInformation"/></xs:sequence><xs:attribute name="type" type="Classes" default="ActRelationship"/><xs:attribute name="typeCode" type="ActRelationshipType"/><xs:attribute name="templateId" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="typeID" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="realmCode" use="optional"><xs:simpleType><xs:list itemType="cs"/></xs:simpleType></xs:attribute><xs:attribute name="nullFlavor" type="cs" use="optional"/></xs:complexType><xs:complexType name="AABB_MT444448.DocumentInformation"><xs:sequence><xs:element name="id" type="II"/><xs:element name="code" type="CD" minOccurs="0"/><xs:element name="title" type="ST" minOccurs="0"/><xs:element name="text" type="ED" minOccurs="0"/><xs:element name="statusCode" type="CS" minOccurs="0"/><xs:element name="effectiveTime" type="TS" minOccurs="0"/></xs:sequence><xs:attribute name="type" type="Classes" default="ActHeir"/><xs:attribute name="classCode" type="ActClass"/><xs:attribute name="moodCode" type="ActMood"/>__________________________________________________________________________
50
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________<xs:attribute name="templateId" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="typeID" use="optional"><xs:simpleType><xs:list itemType="oid"/></xs:simpleType></xs:attribute><xs:attribute name="realmCode" use="optional"><xs:simpleType><xs:list itemType="cs"/></xs:simpleType></xs:attribute><xs:attribute name="nullFlavor" type="cs" use="optional"/></xs:complexType></xs:schema>

C.2

ExampleExample XML instance returned from a query for SUMMARY-CARDIOLOGY-ECG:<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet href = 'IHEDocumentList.xsl' type = 'text/xsl'?><IHEDocumentList xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:schemaLocation="urn:hl7-org:v3 ../schema/AABB_MT444448.xsd" type="Observation" classCode="ACT"><code code="SUMMARY-CARDIOLOGY-ECG" codeSystem="1.2.3.4.5" displayName="Summary of ECG Documents"/><!-- When this document was created by Information Source Actor --><activityTime value="20040608215104"/><recordTarget><patient><!-- Patient Identifier (a.k.a. Medical Record Number)"root" is UID scoping the local ID, usually identifying the Organization that assigned it"extension" is ID assigned by the Organization --><id root="1.3.6.1.4.1.20029.10.2332.23" extension="324414"/><patientPatient><name><family>Smith</family><given>John</given></name><administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/><birthTime value="19650423"/></patientPatient><providerOrganization><id root="1.3.6.1.4.1.20029.10.2332.23"/><name>XYZ Memorial Hospital</name></providerOrganization></patient></recordTarget><author><noteText><!-- URL of the list author --><reference value="http://192.168.100.146/IHERetrieveSummaryInfo?requestType='SUMMARY-CARDIOLOGYECG'&amp;patientID='12345'"/></noteText><assignedAuthor><!-- Optional role-specific ID of authoring device, e.g. hospital-assigned tracking ID --><id root="1.2.3.4.5" extension="123"/><assignedDevice><!-- Optional role-independent ID of authoring device, e.g. serial number -->__________________________________________________________________________
51
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________<id root="1.2.3.4.5" extension="123"/><!-- Optional code specifying the type of device --><code code="ECG_MANAGER" codeSystem="1.2.3.4.5" displayName="ECG Manager"/><manufacturerModelName>ABC ECG Management System</manufacturerModelName><softwareName>Standard Edition, V2.12</softwareName></assignedDevice></assignedAuthor></author><component><documentInformation><!-- Unique Identifier of document, and be OID or UUID --><id root="61d1a24f-b47e-41aa-ae95-f8ac302f4eeb"/><!-- Type of document --><code code="28010-7" codeSystem="2.16.840.1.113883.5.22" displayName="EKG Report"/><!-- Optional title of the document --><title>Resting 12-Lead ECG</title><text><!-- URL of the document --><reference
value="http://192.168.100.146/IHERetrieveDocument?requestType='DOCUMENT'&amp;documentUID='61d1a24f-b47e-41aa-ae95f8ac302f4eeb'&amp;preferredContentType='application/pdf'"/></text><!-- Status of the document, need a vocabulary to define these codes --><statusCode code="CONFIRMED" codeSystem="1.2.3.4.5"/><!-- Acquisition time of the data used to make the report, e.g. device time of cardiograph when it recorded the ECG --><effectiveTime value="20040423134502"/></documentInformation></component><component><documentInformation><id root="61d1a24f-b47e-41aa-ae95-f8ac302f4eec"/><code code="28010-7" codeSystem="2.16.840.1.113883.5.22" displayName="Resting 12-Lead ECG"/><title>Resting 12-Lead ECG</title><text><reference
value="http://192.168.100.146/IHERetrieveDocument?requestType='DOCUMENT'&amp;documentUID='61d1a24f-b47e-41aa-ae95f8ac302f4eec'&amp;preferredContentType='application/pdf'"/></text><statusCode code="CONFIRMED" codeSystem="1.2.3.4.5"/><effectiveTime value="20040423134745"/></documentInformation></component></IHEDocumentList>

Example style sheet:<?xml version='1.0'?><xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"><xsl:template match="/"><html><head><title> <xsl:value-of select="IHEDocumentList/recordTarget/patient/patientPatient/name/family"/>,<xsl:value-of select="IHEDocumentList/recordTarget/patient/patientPatient/name/given"/></title></head><body><h2>List of ECG's for <xsl:value-of select="IHEDocumentList/recordTarget/patient/patientPatient/name/family"/>,<xsl:value-of select="IHEDocumentList/recordTarget/patient/patientPatient/name/given"/></h2>__________________________________________________________________________
52
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________<b> Gender:</b> <xsl:value-of
select="IHEDocumentList/recordTarget/patient/patientPatient/administrativeGenderCode/@code"/><br/><b> DOB:</b> <xsl:value-of select="IHEDocumentList/recordTarget/patient/patientPatient/birthTime/@value"/><br/><b> List Created:</b> <xsl:value-of select="IHEDocumentList/activityTime/@value"/><br/><br/><table border="2" bgcolor="lightcyan"><tr><th>Type</th><th>Status</th><th>Date</th><th>ECG Document</th></tr><xsl:for-each select="/IHEDocumentList/component/documentInformation"><tr><td><xsl:value-of select="code/@displayName"/></td><td><xsl:value-of select="statusCode/@code"/></td><td><xsl:value-of select="effectiveTime/@value"/></td><td><a> <xsl:attribute name = "HREF"> <xsl:value-of select="text/reference/@value"/></xsl:attribute> Get Document</a>
</td>
</tr>
</xsl:for-each></table></body></html></xsl:template></xsl:stylesheet>

Display based on example instance and style sheet:__________________________________________________________________________
53
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions________________________________________________________________________________________________________________________________________________________
54
Version 2.1 Final Text – 2006/06/08

Copyright © 2004,2005,2006: ACC, HIMSS, RSNAIHE Cardiology Technical Framework, vol. II: Transactions______________________________________________________________________________

Appendix D:

Coded Report Titles

This section reserved.

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

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