ACC, HIMSS and RSNA
Integrating the Healthcare EnterpriseIHE Cardiology Technical Framework
Supplement 2006-2007

Implantable Device Cardiac Observation
Profile (IDCO)

Published for Trial Implementation
June 8, 2006

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
Table of Contents

1
2

Foreword.................................................................................................................................. 4
Introduction.............................................................................................................................. 5
2.1 Choice of Standards ............................................................................................................ 6
2.2 Open Issues and Questions ................................................................................................. 6
2.3 Closed Issues....................................................................................................................... 6
Changes to Volume I – Integration Profiles ................................................................................... 8
2.2.x Implantable Device Cardiac Observation Profile ............................................................. 8
9 Implantable Device Cardiac Observation Profile (IDCO)..................................................... 11
9.1 Actors/ Transactions ......................................................................................................... 11
9.2 IDCO Integration Profile Options..................................................................................... 13
9.2.1 PIX-based Reconciliation Option ................................................................................... 13
9.3 IDCO Use Cases ............................................................................................................... 13
9.3.1 Use Case I1: Implantable Cardiac Device In-Clinic Followup ...................................... 13
9.3.2 Use Case I2: Implantable Cardiac Device In-Clinic Followup with Networked
Programmer that Translates Information........................................................................ 15
9.3.3 Use Case I3: Implantable Cardiac Device Remote Followup ........................................ 15
9.3.4 Use Case I4: Third Party Value-Added Services ........................................................... 15
9.4 IDCO Process Flow .......................................................................................................... 16
9.5 Patient Identification......................................................................................................... 21
H.5 Patient Identifier Cross-referencing Integration Profile (PIX) ............................................ 23
H.5.1 Cardiology Use Case...................................................................................................... 24
H.6 Audit Trail and Node Authentication (ATNA) ................................................................... 24
H.6.1 Cardiology Use Case...................................................................................................... 25
Appendix I: Observation Processors and Repositories - Extended Workflow Actor Groupings 25
I.1 Basic IDCO Report Display using Retrieve Information for Display Profile (RID)........ 26
I.2 IDCO Data Incorporation into a Report using Displayable Reports Profile (DRPT)....... 26
I.3 IDCO Discrete Data Storage using Evidence Documents Profile (ED) ........................... 27
I.4 IDCO Submission to an EHR using Cross Domain Document Sharing Profile (XDS)... 27
I.5 Observation Repository with a Database.......................................................................... 27
Changes to Volume II – Transactions........................................................................................... 29
4.12 Send Observation (CARD-12).......................................................................................... 29
4.12.1
Scope ....................................................................................................................... 29
4.12.2
Use Case Roles........................................................................................................ 29
4.12.3
Referenced Standards .............................................................................................. 30
4.12.4
Interaction Diagram................................................................................................. 30
4.12.5Observation Submission.......................................................................................... 30
4.12.5.1
Trigger Events................................................................................................... 30
4.12.5.2
Message Semantics ........................................................................................... 30
4.12.5.2.1 MSH Segment – Message Header ................................................................ 31
4.12.5.2.2 PID Segment – Patient Identification ........................................................... 32
4.12.5.2.3 PV1 Segment – Patient Visit (Optional)....................................................... 33__________________________________________________________________________
2
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
4.12.5.2.4 OBR Segment – Observation Request.......................................................... 33
4.12.5.2.5 OBX Segment with Encapsulated v3 Message............................................. 35
4.12.5.2.5.1 XML schema ........................................................................................... 41
4.12.5.2.5.2 IHE_IDCO_DeviceSummary->effectiveTime element constraints........ 43
4.12.5.2.5.3 ReusableDevice - Interrogation device – programmer............................ 43
4.12.5.2.5.4 recordTarget – Patient ............................................................................. 43
4.12.5.2.5.5 Interrogation device – Author ................................................................. 44
4.12.5.2.5.6 Performer ................................................................................................. 44
4.12.5.2.5.7 Encounter................................................................................................. 44
4.12.5.2.5.8 IHE_IDCO_DeviceSummary –> subject element constraints and multiple
device mappings.................................................................................................... 44
4.12.5.2.5.9 Implantable Cardiac Device – pulse generator........................................ 45
4.12.5.2.5.10 Leads...................................................................................................... 45
4.12.5.2.5.11 IEEE 1073.1.1.3 item mapping ............................................................. 46
4.12.5.2.5.12 Missing and out-of-type values ............................................................. 49
4.12.5.2.5.13 code mapping......................................................................................... 51
4.12.5.2.5.14 IEEE 1073.1.1.3 nomenclature Data Type mapping ............................. 51
4.12.5.2.5.15 IEEE 1073.1.1.3 Hierarchy Mapping ................................................... 53
4.12.5.2.5.16 IEEE 1073.1.1.3 nomenclature Automatic/Manual mapping .............. 56
4.12.5.2.6 OBX Segment with Encapsulated PDF [Optional]....................................... 56
4.12.5.2.7 OBR Segments – Pulse Generator and Lead Observation Results ............... 57
4.12.5.2.8 OBX Segments – Pulse Generator and Lead Observation Results............... 58
4.12.5.2.9 NTE Segment – Notes and Comments [Optional]........................................ 59
4.12.5.3
Expected Actions .............................................................................................. 60
4.12.5.3.1 HL7 Message Router .................................................................................... 60
4.12.6
Observation Forwarding.......................................................................................... 60
4.12.6.1
Trigger Events................................................................................................... 60
4.12.6.2
Message Semantics ........................................................................................... 60
4.12.6.3
Expected Actions .............................................................................................. 60
4.12.6.3.1 Observation Processor .................................................................................. 60
4.12.6.3.2 Observation Repository ................................................................................ 61
Appendix Z – IDCO Observation Message Examples ................................................................. 62
Appendix A – IEEE 1073.1.1.3 ICD Terms nomenclature .......................................................... 63
Usage of Discriminators ............................................................................................................. 64
XML Schema.............................................................................................................................. 65__________________________________________________________________________
3
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

1 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.
IHE maintain formal relationships with several standards bodies including HL7, DICOM andrefers recommendations to them when clarifications or extensions to existing standards arenecessary.
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 Association of Radiology (EAR) and European Congress of Radiologists (ECR), theCoordination Committee of the Radiological and Electromedical Industries (COCIR), Deutsche
Röntgengesellschaft (DRG), the EuroPACS Association, Groupement pour la Modernisation duSystème d'Information Hospitalier (GMSIH), Société Francaise de Radiologie (SFR), Società
Italiana di Radiologia Medica (SIRM), the European Institute for health Records (EuroRec), andthe European Society of Cardiology (ESC). In Japan IHE-J is sponsored by the Ministry of
Economy, Trade, and Industry (METI); the Ministry of Health, Labor, and Welfare; and MEDISDC; 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 andgeographic boundaries.
The IHE Technical Frameworks for the various domains (IT Infrastructure, Cardiology,
Laboratory, Radiology, etc.) defines specific implementations of established standards to achieve
integration goals that promote appropriate sharing of medical information to support optimal
patient care. It is expanded annually, after a period of public review, and maintained regularly
through the identification and correction of errata. The current version for these Technical
Frameworks may be found at www.ihe.net/Technical_Framework.
__________________________________________________________________________
4
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________The IHE Technical Framework identifies a subset of the functional components of the healthcare
enterprise, called IHE Actors, and specifies their interactions in terms of a set of coordinated,
standards-based transactions. It describes this body of transactions in progressively greater
depth. The volume I provides a high-level view of IHE functionality, showing the transactionsorganized into functional units called Integration Profiles that highlight their capacity to address
specific clinical needs. The subsequent volumes provide detailed technical descriptions of each
IHE transaction.
This supplement to the IHE Cardiology Technical Framework v2 is submitted for Trial
Implementation through March 2007.

Comments arising from Trial Implementation should be submitted to:
http://forums.rsna.org
Under the “IHE” forum, select the“IHE Cardiology Technical Framework Supplements 2006”
sub-forum.
The IHE Cardiology Technical Committee will address these comments and expects topublish the Final Text version in June 2007.

2 Introduction
This Supplement adds a new profile to the IHE Cardiology Technical Framework describing ameans to transfer information from an interrogated implantable cardiac device to information
management systems.
Cardiac electrophysiologists follow patients with implantable cardiac devices from multiple
vendors. These devices are categorized as pacemakers, implantable cardioverter defibrillators,
and cardiac resynchronization therapy devices. As part of patient follow-up an interrogation of a
cardiac device is performed (either in-clinic or remotely from a patient’s residence). Informationis collected about the device such as device identification, therapy settings, device diagnostics,
and device testing. These interrogations are performed by vendor proprietary equipment.
To improve workflow efficiencies Cardiology and Electro Physiology practices require themanagement of “key” summary implantable rhythm control device interrogation information in acentral system such as an EHR or a device clinic management system.

__________________________________________________________________________
5
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
To address this requirement, the Implantable Device Cardiac Observation (IDCO) Profile defines
a standard based translation and transfer of summary device interrogation information from theinterrogation system to the information management system.

2.1

Choice of Standards

The content of Implantable Device Cardiac Observation information has been standardized in
HL7 v3 Therapeutic Devices Domain / Implantable Cardiac Device Topic / Implantable Cardiac
Device Summary message. That message uses a highly structured XML-based format based on
the HL7 Reference Information Model (RIM), and specifies use of the IEEE 1073 Nomenclature
for Point-of-care Medical Device Communication – Implantable Device, Cardiac. That message
provides the defined content structure for the observation message of this profile.
However, the HL7 v3 message transport infrastructure is not broadly implemented, and isunlikely to be broadly implemented in the next few years. Because HL7 v2.x is the widely
supported version, this profile specifies conveying the v3 content as Encapsulated Data in a v2.x
ORU (unsolicited observation) message. When v3 message transport infrastructures become
available, it will be a relatively simple matter to replace the v2 message transport with a v3transport; since the content is already in the v3 format, minimal changes to the application
processing of the message would be needed.
Also, the IEEE 1073 Nomenclature for Point-of-care Medical Device Communication –Implantable Device, Cardiac is currently in the process of being balloted. The schema andstructure of the version of the nomenclature for use with this profile is available on the IHE
website at http://www.ihe.net/Technical_Framework/index.cfm#cardiology.

2.2Open Issues and Questions

None

2.3

Closed Issues

1. Scheduling is not within scope of this profile for year 1.
2. How do we integrate the IDCO actors into the EP Workflow? This is a future issue.
3. IEEE 1073.1.1.3 ICD Terms is currently being prepared for ballot. Final specifications are
not currently available for inclusion in the profile but will be referenced from the IHE site.
Specifications going to ballot should be available for reference by early July.
4. This profile mandates the use of PIX for cross-referencing device identifiers to patients.
Should PDQ also be referenced as another option for resolving patient IDs or should themethods of resolution be open to implementations (i.e. not specify PIX or PDQ)? No. PDQ
is not appropriate for this profile. PDQ would require a query for every message received.
5. This profile mandates the use of PAM to update patient demographics in the observations
stored in the Observation Repository. Is this necessary and appropriate for this profile? Yes.
__________________________________________________________________________
6
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
6. This profile does not require the use of ATNA. There are several implementation models forthis profile that do not require transmission of data over public networks including intrainstitutional, VPN, etc. However, when public networks are used, ATNA is one option for
secure transport over those networks. Should ATNA be required? ATNA should be required
for remote follow-ups. Referencing ATNA makes defining security for the profile easy.
7. This profile specifies an HL7 Message Router actor to distribute observations to multiple
recipients in an institution. Is the HL7 Message Router actor needed? What value does the
HL7 Message Router actor add to the integration profile? Should the HL7 Message Routerprovide the PIX consumer actor to match incoming observations with local patient
identifiers? The HL7 Message Router provides an approach for getting the integrationengine vendors directly involved in the IHE process. The HL7 Message Router will continue
to be used. The HL7 Message Router will be grouped with PIX consumer as to provide
patient identification reconciliation. With this grouping the HL7 Message Router provides aservice beyond pass-through routing.
8. Patient Identity Feeds are assumed to be part of the patient / device registration process,which will be required before an Observation Repository / Processor can receive CARD-12transactions. This profile does not specify the Patient Identity Feed transaction. If PIX isused, should the PIX Identity Source actor be specified for registration of the device with thepatient? Should it be grouped with the Observation Creator / Processor / Repository? No.
The Observation Creator is not positioned to participate in PIX at this time. This is apossibility for future versions of the profile.

__________________________________________________________________________
7
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

Changes to Volume I – Integration Profiles
Add to Section 1.7•

The IDCO profile specifies a mechanism for the creation, transmission, and processing of
discrete data elements and report attachments associated with cardiac device interrogations(observations).

Add to Section 2.1
Table 2-1 Integration Profile Dependencies

Integration Profile
IDCO

Depends On

Dependency TypeITI-TF PIX Profile

The HL7 Message Router,
Observation Processor, andObservation Repository are
required to be grouped with thePatient Identifier Cross-Reference
Consumer actor.

ITI-TF PAM Profile

The Observation Repository is
required to be grouped with thePatient Demographic Consumer
Actor.

Comments

Add to Section 2.2
2.2.x Implantable Device Cardiac Observation Profile
The Implantable Device Cardiac Observation Integration Profile defines a mechanism for thecreation, transmission, and processing of discrete data elements and report attachments
associated with cardiac device interrogations (observations). It supports the uses cases for inclinic and remote implanted cardiac device follow-ups.

Add to Section 2.3
Observation Creator - A system that creates and transmits diagnostic or therapeutic
observational data.
Observation Processor - A system that receives clinical observations and further processes
them for inclusion within derivative products, such as clinical reports, databases, ortranscoded/reformatted results.

__________________________________________________________________________
8
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
Observation Repository - A system that receives clinical observations and stores them for
subsequent retrieval and display. The Observation Repository updates stored datawith updated demographics through out the lifecycle of the data.
HL7 Message Router – A system that receives HL7 messages, routes them to one or more
configured actors, and handles transport level acknowledgements. The HL7 Message
Router may also provide modification of the messages in accordance with specificprofiles.
Integration Profile

CATH

ECHO ECG

ED

IDCO

Actor
Acquisition Modality

X

X

ADT Patient Registration

X

X

Department System Scheduler/Order Filler

X

X

Evidence Creator

X

X

X

X

Image Archive

X

X

X

Image Display

X

X

X

Image Manager

X

X

X

Order Placer

X

X

Performed Procedure Step Manager

X

X

Report Creator

X

Time Client(note 1)

Display

X

Information Source

X

Observation Creator

X

Observation Repository

X

Observation ProcessorX

HL7 Message RouterX

Add to Section 2.4
Send Observations – Observations, measurements, or reports, are sent using an HL7
Observations message. [CARD-12]

Integration Profile

CATH ECHO ECG

ED

IDCO

Transaction
Patient Registration [RAD-1]

X

X

Placer Order Management [RAD-2]

X

X__________________________________________________________________________
9
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
Integration Profile

CATH ECHO ECG

ED

IDCO

Transaction
Filler Order Management [RAD-3]

X

X

Procedure Scheduled [RAD-4]

X

X

Query Modality Worklist [RAD-5]

X

X

Modality Procedure Step In Progress [CARD-1]

X

X

Modality Procedure Step Completed [RAD-7]

X

X

Modality Images/Evidence Stored [CARD-2]

X

X

X
X

Storage Commitment [CARD-3]

X

X

Patient Update [RAD-12]

X

X

Procedure Update [RAD-13]

X

X

Query Images [RAD-14]

X

X

Retrieve Images/Evidence [CARD-4]

X

X

Instance Availability Notification [RAD-49]

X

X

Query Evidence Documents [RAD-44]

Maintain Time [ITI-1]

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

X

Retrieve ECG List [CARD-5]

X

Retrieve ECG Document for Display [CARD-6]

X

Send Observations [CARD-12]

X

Patient Identity Query [ITI-9](note 2)

Patient Identity Feed [ITI-30](note 2)

Notes:

1. The Maintain Time transaction is not formally part of the Cath Workflow Profile, but it is required for theTime Client actor grouped with certain actors in that Profile.
2. The Patient Identity Query and Patient Identity Feed transactions are not formally part of the
Implantable Device Cardiac Observations Profile, but are required for the PIX Consumer and Patient
Demographics Consumer actors grouped with certain actors in that Profile.

Add to Section 2.5•••

The HL7 Message Router actor participating in the IDCO Profile shall be grouped with thePatient Identity Cross-Reference Consumer actor of the PIX Profile (ITI-TF).
The Observation Processor actor participating in the IDCO Profile shall be grouped with thePatient Identity Cross-Reference Consumer actor of the PIX Profile (ITI-TF) when the PIXbased Reconciliation Option is supported.
The Observation Repository actor participating in the IDCO Profile shall be grouped with thePatient Identity Cross-Reference Consumer actor of the PIX Profile (ITI-TF), and with thePatient Demographics Consumer actor of the PAM Profile (ITI-TF).

__________________________________________________________________________
10
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
Add the following new profile section

9

Implantable Device Cardiac Observation Profile (IDCO)

Cardiac electrophysiologists follow patients with implantable cardiac devices from multiple
vendors. These devices are categorized as pacemakers, implantable cardioverter defibrillators,
and cardiac resynchronization therapy devices. As part of patient follow-up an interrogation of a
cardiac device is performed (either in-clinic or remotely from a patient’s residence). Informationis collected about the device such as device identification, therapy settings, device diagnostics,
and device testing. These interrogations are performed by vendor proprietary equipment.
To improve workflow efficiencies Cardiology and Electro Physiology practices require themanagement of “key” summary implantable rhythm control device interrogation information in acentral system such as an EHR or a device clinic management system.
To address this requirement, the Implantable Device Cardiac Observation (IDCO) Profile defines
a standard based translation and transfer of summary device interrogation information from theinterrogation system to the information management system.
The IDCO profile specifies a mechanism for the creation, transmission, processing, and storageof discrete data elements and report attachments associated with cardiac device interrogations(observations).

9.1

Actors/ Transactions

Figures 9.1-1 and 9.1-2 show the actors and transactions directly involved in the IDCO
Integration Profile with bold and with solid lines. Grouped actors are shown italicized and withdotted lines. Other actors and transactions that may be indirectly involved because of their
participation in associated IHE Integration Profiles are not shown.
Note:

See Appendix I for examples of grouping IDCO actors with actors of other Profiles.

Figure 9.1-1 shows a full configuration where the Observation Creator sends a CARD-12transaction via an HL7 Message Router to an Observation Processor or Observation Repository.
Figure 9.1-2 shows an alternate configuration where the Observation Creator sends the CARD12 transaction directly to the Observation Processor and Observation Repository actors.

__________________________________________________________________________
11
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________PIX Consumer

Observation
CreatorSend
Observation[CARD - 12]

HL7 Message
Router

Send
Observation[CARD - 12]

Send
Observation[CARD - 12]

PIX Consumer(optional)
Observation
Processor

Observation
Repository
PIX Consumer
Patient
Demographics
Consumer

Figure 9.1-1. IDCO Actor Diagram

Send
Observation[CARD - 12]

PIX Consumer(option)Observation
Processor

Observation
CreatorSend
Observation[CARD - 12]

Observation
Repository
PIX Consumer
Patient
Demographics
Consumer

Figure 9.1-2. IDCO Actor Diagram (Alternate Configuration)

See section 9.5 Patient Identification for details concerning the grouped PIX Consumer andPatient Demographics Consumer actors.
Table 9.1-1 lists the transactions for each actor directly involved in the IDCO Profile. In order toclaim support of this Integration Profile, an implementation must perform the required
transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of options
defined by this Integration Profile that implementations may choose to support are listed in theappropriate actor profile; as specified in the Section column in the table defined below.

__________________________________________________________________________
12
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
Table 9.1-1. Implantable Device Cardiac Observation Integration Profile Actors and Transactions
ActorsTransactions

Optionality

Section in Vol. 2

Observation Creator

Send Observations [CARD-12]

R

CARD-TF 2: 4.12

HL7 Message Router

Send Observations [CARD-12]

R

CARD-TF 2: 4.12

Observation Repository

Send Observations [CARD-12]

R

CARD-TF 2: 4.12

Observation Processor

Send Observations [CARD-12]

R

CARD-TF 2: 4.12

9.2

IDCO Integration Profile Options

Many Actors have Options defined in order to accommodate variations in use across domains orimplementations. Options that may be selected for this Integration Profile are listed in the table9.2-1 along with the Actors to which they apply.
Table 9.2-1: IDCO - Actors and Options
Actor

Option Name

Observation Creator

None

Observation Repository

None

Observation Processor

PIX-based Reconciliation

HL7 Message Router

None

Vol & Section

CARD-TF 2: 4.12.5.2.7

9.2.1 PIX-based Reconciliation Option
The Observation Processor is required to reconcile the Patient ID from the Observation Creatorwith the Patient ID used in the local domain (see Section 9.5). Observation Processor claiming
this PIX-based Reconciliation Option shall be grouped with the Patient Identifier CrossReference Consumer actor of the IHE Patient Identifier Cross-Referencing Profile (PIX) to
perform the ID mapping.

9.3

IDCO Use Cases

9.3.1 Use Case I1: Implantable Cardiac Device In-Clinic Followup
Note: This use case is identical to HL7 v3 Implantable Cardiac Device Follow-Up Storyboard (POTD_ST000001).

Clinical Context:
Adam Everyman presents at the electrophysiology (EP) follow-up clinic for his appointment.
Adam will present for follow-up 7-10 days after implant and every 3-6 months thereafter,
depending on the therapy protocol.

__________________________________________________________________________
13
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
Dr. Ed Electrode, an Electrophysiologist - also referred to as a following physician, and Nancy
Nightingale, an R.N., work in the electrophysiology (EP) follow-up clinic.
Note: In the area of Electrophysiology, a "programmer" is a commonly used term to describe a
specialized computer that is capable of communicating with an implanted device. Programmers
are used to interrogate implanted devices and "program", or make changes to, implanted cardiac
device settings.
Nancy interrogates the device using the programmer and extracts the data (e.g., settings, status,
events) from the device. Nancy reviews the device data and captures the "current state" device
data from the programmer screen and/or prints out the settings and/or uses an informationtransfer mechanism (e.g., floppy disk, analog cable, etc.) to transmit device data, which is in a
proprietary format, to a translator system.
If the device data has been sent to the translator system, the clinician may desire to transmit data
to an electronic health record system (EHR) or device clinic management system. In this case, anecessary subset (pre-determined by the clinic and the entity responsible for the translator
system) of the data that represents the device's 'summary data' is converted from the proprietary
format and transmitted using HL7 messaging to the EP office EHR or device clinic management
system.
Dr. Ed Electrode reviews the device data and identifies appropriate changes to device settings.
Nancy Nightingale makes these changes via the programmer. Nancy then captures the "final
state" device data. Nancy then uses the information transfer mechanism to transmit device data,
which is in a proprietary format, to a translator system, which again converts the data into an
HL7 message and communicates the 'summary data' to the clinic's EHR or device clinic
management system. This second message will utilize the same HL7 message format as the first.
These summary reports are sent as unsolicited observation events.
For example a device summary could contain the following items:
Device Diagnostics
Events Counters
Device Observations
Programmed Therapy Settings
Clinician Comments
Note:Electrocardiograms are not currently addressed in the HL7 standards. They can be sent as a PDF attachment to
the HL7 message.

IHE Context:
In the use case the translator system equates to the Observation Creator actor and the EHR or
device clinic management system equates to the HL7 Message Router / Observation Processor /Observation Repository actors. The HL7 formatted implanted cardiac device interrogation
message is the CARD-12 transaction.
__________________________________________________________________________
14
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
9.3.2 Use Case I2: Implantable Cardiac Device In-Clinic Followup with Networked
Programmer that Translates Information
Clinical Context:
Same as in-clinic use case above with the following change. The programmer communicatesdirectly with an electronic health record system (EHR) or device clinic management system,
acting as a translator system.
IHE Context:
Same as in-clinic use case above with the following change. The programmer assumes the role
the actor Observation Creator.
9.3.3 Use Case I3: Implantable Cardiac Device Remote Followup
Clinical Context:
Portions of the previous use case also apply to Adam Everyman having his device followed
remotely. Adam will present to an interrogation device located outside of the clinic (e.g., in
Adam’s residence) which will capture the state of his implanted device and will transmit the
information to a translator system. The translator system converts the data into an HL7 message
and communicates the 'summary data' to the clinic's EHR.
IHE Context:
Same as in-clinic use case above. The Observation Creator, Processor, and Repository actors
should be grouped with the Secure Node actor of the ATNA Profile to secure communications
for remote follow-ups if data is sent across an un-trusted network.
9.3.4 Use Case I4: Third Party Value-Added Services
Clinical Context:
The translator system described in use cases I1 and I2 may be implemented as a service of a third
party, e.g., the device manufacturer or a monitoring service. This system may provide various
types of value-added services, such as data aggregation and analysis, trending, and statisticalreports. Such additional data may be appended to the standard device observation 'summary
data' message sent to the recipient system.
IHE Context:
Same as in-clinic use case above. The additional data aggregation or rendering can be sent as a
PDF attachment to the HL7 message.
These types of value-added services are likely to be provided by a party that will send the resultsover the Internet. In this case, use of the ATNA profile on the link between the Observation
Creator and the HL7 Message Router is recommended.

__________________________________________________________________________
15
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

9.4

IDCO Process Flow

The IDCO Profile defines a transaction to support the exchange of unsolicited observations
created during an Implantable Device Cardiac Observation. The two basic process flows for the
IDCO profile is shown in Figures 9.4-1 and 9.4-2, and are described below.

__________________________________________________________________________
16
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

DeviceInterrogator

Observation Creator

HL7 Router

Observation Processor

Observation Repository

PIX Manager

Query Device (1)Receive Query Information

Send Interrogation (2)Validate and Review (3)Translate Information (4)Node Authentication [ITI-19] (5)Send Observation [CARD-12] (6)PIX Query [ITI-9] (7)Modify PID (8)Send Observation [CARD-12] (9)Process Observation (10)Send Observation [CARD-12] (11)Store Observation (12)Figure 9.4-1. Basic Process Flow in IDCO Profile with HL7 Message Router and Secured Connection__________________________________________________________________________
17
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

Note: Device and Interrogator actors and associated transactions are outside the scope of thisprofile.
Process Flow Steps for Figure 9.4-1
1) Query Device - The implanted cardiac Device is interrogated in a manufacturerproprietary manner by the Interrogator2) Send Interrogation – The Interrogator sends information in a manufacturer-proprietarymanner to the Observation Creator.
3) Validate and Review – The Observation Creator validates the information. This may
include the clinician reviewing and approving the information.
4) Translate Information – The Observation Creator translates the information into theproper HL7 format.
5) Node Authentication – Security is required for transactions that traverse un-trusted
networks. The ATNA Secure Node actor should be grouped with the Observation
Creator and HL7 Message Router actors in these situations. The Observation Creator isauthenticated by the HL7 Message Router using the ATNA Node Authentication [ITI-9]
transaction. A secured network connection must be established between the secured
nodes as defined by the ATNA Encryption Option.
6) Send Observation – The Observation Creator sends the device information to the HL7
Message Router using the CARD-12 transaction.
7) PIX Query – The HL7 Message Router matches the Patient ID provided by theObservation Creator to the internal Patient ID within the clinic domain using the PIXQuery ITI-9 transaction.
Note that the patient identifier used in the HL7 observation message is not the ID
used by the receiving system. The interrogation system will have no knowledge ofpatient ID other than the serial number of the device; since the device isimplanted into only one patient, it can serve as a type of patient ID. In this case,the “assigning authority” for the ID is the device manufacturer. The ID will be a
combination of the manufacturer, model number, and serial number of the device.
See section 9.5 for details concerning Patient ID reconciliation.
8) Modify PID – The HL7 Message Router modifies the PID segment of the CARD-12transaction supplying the appropriate Patient ID.
9) Send Transaction – The HL7 Message Router sends the device information to theObservation Processor using the CARD-12 transaction.
10) Process Observation – The Observation Processor further processes the observation
message for inclusion within derivative products, such as clinical reports, databases, ortrans-coded / reformatted results.
__________________________________________________________________________
18
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
11) Send Transaction – The HL7 Message Router sends the device information to theObservation Repository using the CARD-12 transaction.
12) Store Observation – The Observation Repository provides long-term storage of theobservation, and makes it available through mechanisms beyond the scope of this profile.
The Observation Repository must manage patient demographic updates for the life of thedata. It uses the PAM Profile to interact with the Patient Demographics Source toperform this function (actors not shown on model).

__________________________________________________________________________
19
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

DeviceInterrogator

Observation Creator

Observation Processor

Observation Repository

PIX Manager

Query Device (1)Send Interrogation

Send Interrogation (2)Validate and Review (3)Translate Information (4)Send Observation [CARD-12] (5)PIX Query [ITI-9] (6)Process Observation (7)Send Observation [CARD-12] (8)PIX Query [ITI-9] (9)Store Observation (10)Figure 9.4-2. Basic Process Flow in IDCO Profile with No HL7 Message Router__________________________________________________________________________
20
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
Process Flow Steps for Figure 9.4-2
1) Query Device - The implanted cardiac Device is interrogated in a manufacturer-proprietarymanner by the Interrogator2) Send Interrogation – The Interrogator sends information in a manufacturer-proprietarymanner to the Observation Creator.
3) Validate and Review – The Observation Creator validates the information. This may include
the clinician reviewing and approving the information.
4) Translate Information – The Observation Creator translates the information into the proper
HL7 format.
5) Send Observation – The Observation Creator sends the device information to the Observation
Processor using the CARD-12 transaction.
6) PIX Query – The Observation Processor matches the Patient ID provided by the Observation
Creator to the internal Patient ID within the clinic domain. It may do this using animplementation-specific ID mapping mechanism, or if it claims the PIX-based Reconciliation
Option it will use the PIX Query ITI-9 transaction.
7) Process Observation – The Observation Processor further processes the observation message
for inclusion within derivative products, such as clinical reports, databases, or trans-coded /reformatted results.
8) Send Transaction – The Observation Creator sends the device information to the Observation
Repository using the CARD-12 transaction.
9) PIX Query – The Observation Repository matches the Patient ID provided by theObservation Creator to the internal Patient ID within the clinic domain using the PIX Query
ITI-9 transaction.
10) Store Observation – The Observation Repository provides long-term storage of theobservation, and makes it available through mechanisms beyond the scope of this profile.
The Observation Repository must manage patient demographic updates for the life of thedata. It uses the PAM Profile to interact with the Patient Demographics Source to perform
this function (actors not shown on model).

9.5

Patient Identification

This profile specifies two actors, the Observation Repository and the Observation Processor, thatare the endpoints for observation messages. These actors must cross-reference patient identifiers
across the two Patient Identifier Domains: the device vendor systems providing the observations
and the clinics receiving the observations.

__________________________________________________________________________
21
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
IHE specifies the Patient Identifier Cross-Referencing Profile (PIX) as the mechanism to obtainsuch cross-references from a central server (the PIX Manager). The IDCO profile uses the PIXQuery (ITI-9) transaction for its actors to obtain cross-referencing information. The PIX
Consumer actor is grouped with the HL7 Message Router, the Observation Repository, andoptionally the Observation Processor. The PIX Manager actor is not specified within this profile
but is assumed to exist.
The Observation Processor may use an implementation-specific ID mapping mechanism, rather
than the PIX transaction. However, the HL7 Message Router and the Observation Repository
must use the PIX mechanism.
It is assumed that a Patient Identity Feed (ITI-8) transaction, or the equivalent, will occur toregister the cross-referencing of the device identity with the identity of the patient having thedevice. The identity feed can be manual or automatic per existing patient registration policies
and procedures. Configuration of the PIX Manager for matching the device identifier with thepatient record is considered out-of-scope for this profile.
The PIX Consumer actor will pass to the PIX Manager the patient identifier as specified in the
Send Observation (CARD-12) specification. The identifier is the concatenation of the device
model number and device serial number. The identifier assigning authority is the device
manufacturer. The PIX Manager returns the local patient identifier.
An alternate configuration has the HL7 Message Router actor grouped with the PIX Consumer
actor. In this case the HL7 Message Router will be responsible for obtaining patient
identification cross-referencing information and modifying the CARD-12 transaction
appropriately. In this configuration, the Observation Repository and Observation Processor willrecognize that the assigning authority for the Patient ID in the received observation matches the
local domain, and will therefore not need to perform reconciliation.
The PAM Patient Demographics Consumer actor is grouped with the Observation Repository toprovide support for the Patient Identity Feed (ITI-30) transaction to keep the patient
demographics data up to date.
Refer to the PIX and PAM profiles within the IHE IT Infrastructure Technical Framework formore information.

__________________________________________________________________________
22
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

Add to Appendix D Glossary
Implantable Device Cardiac (IDC): Implantable medical devices that treat heart rhythm
problems. These devices are categorized as pacemakers, implantable cardioverter defibrillators,
cardiac resynchronization therapy devices, and implantable monitors.

Add new Sections to Appendix H

H.5 Patient Identifier Cross-referencing Integration Profile (PIX)
The full specification of the Patient Identifier Cross-referencing Integration Profile (PIX)
Integration Profile is found in ITI-TF 1:5.
The Patient Identifier Cross-referencing Integration Profile (PIX) is targeted at healthcare
enterprises of a broad range of sizes (hospital, a clinic, a physician office, etc.). It supports the
cross-referencing of patient identifiers from multiple Patient Identifier Domains via thefollowing interactions:• The transmission of patient identity information from an identity source to the Patient
Identifier Cross-reference Manager.
• The ability to access the list(s) of cross-referenced patient identifiers either via a query/
response or via update notification.
Figure H.5-1 shows the actors and involved in this Profile and the transactions between actors.

Figure H.5-1 PIX Actors and Transactions__________________________________________________________________________
23
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
H.5.1 Cardiology Use Case
Cardiology patients are typically seen and treated in a variety of institutional contexts, each ofwhich may have its own Patient Identifier Domain. For effective patient care, it is required thatpatient identifiers across Patient Identifier Domains be cross-referenced so that patient records
containing clinical observations from one context can be matched to medical records in anothercontext.
One specific use case is the mapping of the patient identifier from an implanted cardiac device
observation to the identifier used in an electronic medical record system. Certain actors within
the IDCO Profile (see section 9) are required to participate in the PIX profile to support thismapping.

H.6 Audit Trail and Node Authentication (ATNA)
The full specification of the Audit Trail and Node Authentication (ATNA) Integration Profile isfound in ITI-TF 1:9.
The Audit Trail and Node Authentication (ATNA) Integration Profile establishes security
measures which, together with the Security Policy and Procedures of the enterprise, provide
patient information confidentiality, data integrity and user accountability. The goals of the Audit
Trail and Node Authentication Integration Profile are:•Access and authentication controls that prevent unauthorized access to information•

Integrity controls that safeguard the integrity and reliability of protected health information•

Accountability controls that provide user accountability through audit record generation anda centralized audit repository
Figure H.6-1 shows the actors and involved in this Profile and the transactions between actors.

__________________________________________________________________________
24
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

Figure H.6-1 ATNA Actors and Transactions

H.6.1 Cardiology Use Case
Cardiology patients are typically seen and treated in a variety of institutional contexts, whose
information systems are often in different security domains connected by public data
communications networks (the Internet). For effective patient care, data must be transported
across those networks, and it is required that network transmissions of protected healthinformation across un-trusted networks be appropriately secured. Certain actors of the XDS
profile are required to participate in the ATNA profile, and actors of the IDCO profile may alsouse ATNA when such transport across public networks is required.

Add New Appendix

Appendix I: Observation Processors and Repositories - Extended
Workflow Actor Groupings
The IDCO profile specifies two actors, the Observation Repository and the Observation
Processor, that are endpoints for observation messages within the defined workflow, but which
are actually transition points to other use of the observation data in other workflows. Thissection describes some of the use cases for these actors.

__________________________________________________________________________
25
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

I.1 Basic IDCO Report Display using Retrieve Information for
Display Profile (RID)
Retrieve Specific Info for Display [ITI - 11]

Observation
Repository

Information
SourceRetrieve Document for Display [ITI - 12]

Display

Figure I.1-1 Extended Actor Groupings - RID

The Observation Repository actor may be grouped with the Information Source actor of theRetrieve Information for Display (RID) Profile. The full specification of the Retrieve
Information for Display Profile is found in ITI-TF 1:3; a summary is included in Appendix H.3of this document (CARD-TF 1:H.3).
With this grouping, the system would store received observations, perhaps providing someaggregating function (e.g., managing replacement of individual observations with later results),
and serving the data in a ready-for-display format in response to a RID query transaction.
As an Observation Repository, the system is also required to be grouped with the Patient
Demographics Consumer actor, and thus to support update of patient demographic data in thestored observations.

I.2 IDCO Data Incorporation into a Report using Displayable
Reports Profile (DRPT)
Observation
Processor

ReportCreatorEncapsulated Report Submission [CARD - 7]

Report Manager

Figure I.2-1 Extended Actor Groupings - DRPTThe Observation Processor actor may be grouped with the Report Creator actor of the
Displayable Reports (DRPT) Profile.
With this grouping, the system would receive observations and provide a mechanism to create areport, perhaps combining the observations from several devices (e.g., implanted device
observations with electrophysiology lab evidence).
As a Report Creator, the created report would be forwarded to a Report Manager for signatureand distribution.

__________________________________________________________________________
26
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

I.3 IDCO Discrete Data Storage using Evidence Documents Profile(ED)
Modality Images/Evidence Stored [CARD - 2]

Observation
Processor

Evidence
CreatorStorage Committment [CARD - 3]

Image Manager

Figure I.3-1 Extended Actor Groupings - ED

The Observation Processor actor may be grouped with the Evidence Creator actor of the
Evidence Documents (ED) Profile.
Such a system would be able to generate Evidence Documents (DICOM Structured Reports)based on content in the Observation message. If the Observation comes from within the context
of an implant procedure, e.g., the record of the initial device settings, the derived evidence
document would be linked to the other images and evidence of the implant procedure via the
Study Instance UID.

I.4 IDCO Submission to an EHR using Cross Domain Document
Sharing Profile (XDS)
Observation
Processor

Document
SourceProvide and Register Document Set [ITI - 15]

Document
Repository

Figure I.4-1 Extended Actor Groupings - XDS

The Observation Processor actor may be grouped with the Document Source actor of the CrossEnterprise Document Sharing (XDS) Profile.
With this grouping, the system would create a medical summary report, perhaps combining theobservations from several devices (e.g., implanted device observations with electrophysiology
lab evidence), to be shared cross encounters, with referral doctors, etc. As a Document Source,
the created report would be forwarded to a Document Repository and, in turn, would be
registered at Document Registry and made available in community of care. Another possibility is
to share and publish the attached PDF report as is, if it was provided by Observation Creator.

I.5

Observation Repository with a Database

The Observation Repository actor may store received observations in a database suitable forlongitudinal patient studies, outcomes research, clinical trials, or data mining. While IHE does
not currently define any Profiles or Transactions for such a database actor, there are several suchtypes of systems which could participate in the IDCO Profile as an Observation Repository.
__________________________________________________________________________
27
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________Such a system would be required to be grouped with the Patient Demographics Consumer actor,
and thus to support update of patient demographic data in the stored observations.

__________________________________________________________________________
28
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

Changes to Volume II – Transactions
Add New Transaction

4.12 Send Observation (CARD-12)
This section corresponds to transaction CARD-12 of the IHE Technical Framework. Transaction
CARD-12 is used by the Observation Creator, HL7 Message Router, Observation Repository andObservation Processor actors.
4.12.1 Scope
In the Send Observation transaction, the Observation Creator sends the observation as an
unsolicited HL7 ORU message to the HL7 Message Router, and the HL7 Message Router sends
the observation as an unsolicited HL7 ORU message to the Observation Repository andObservation Processor actors. Optionally, the Observation Creator can send an unsolicited HL7
ORU message directly to the Observation Processor and Observation Repository.
4.12.2 Use Case Roles
Observation
Creator

HL7 Message
RouterSend Observation

Observation
Processor

Observation
Repository

Actor: Observation Creator
Role: Outputs the Observation as an HL7 ORU message upon completion of the observation.
This message contains the encapsulated XML data, and optionally discrete data for theobservation and/or a PDF document containing displayable data relating to the observation.
Actor: HL7 Message Router
Role: Receives the HL7 ORU message from the Observation Creator, reconciles patient
identification using transactions from the PIX profile, and outputs the message to eachconfigured destination actor.
Actor: Observation Processor
Role: Receives the HL7 ORU message and provides some implementation-specific processing.
This may include creation of reports, integration of information into electronic health records, orcreation of derived data (trends, analyses, reformatted data, population statistics, etc.). If needed,__________________________________________________________________________
29
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
it will reconcile patient identification using an implementation-specific mapping function or
using transactions from the PIX profile.
Actor: Observation Repository
Role: Receives the HL7 ORU message and provides long-tem storage of information contained
within the message. It makes this data available in some implementation-specific manner. If
needed, it will reconcile patient identification using transactions from the PIX profile. It
maintains demographic information consistency with the enterprise based on patient update
transactions of the PAM profile.
4.12.3 Referenced Standards
HL7 Messaging Standard v2.5
HL7 Messaging Standard v3
IEEE 1073.1.1.3 Implantable Cardiac Device Nomenclature
4.12.4 Interaction Diagram
Observation
Creator

HL7 Message
RouterObservation
Processor

Observation
Repository

HL7 ORU
Observation Submission
HL7 ORU
Observation Forwarding
HL7 ORU
Observation Forwarding

4.12.5 Observation Submission
4.12.5.1 Trigger EventsThe Observation Creator initiates the HL7 ORU message to the HL7 Message Router following
an implanted cardiac device interrogation, when it has assembled all the data desired to bereported.
4.12.5.2 Message Semantics
The message is an unsolicited v2.5 ORU message from the Observation Creator to the HL7
Message Router with a corresponding ACK message back to the Observation Creator. The__________________________________________________________________________
30
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
contents of the message (in OBX segments) are a required encapsulated Implantable Cardiac
Device Follow-up observation, an optional encapsulated PDF document, and an optional set ofindividual observations or measurements trans-coded into separate v2.5 OBX segments.
Refer to the HL7 2.5 Standard, Chapter 7 ORU Message for general message semantics.
Refer to the HL7 v3 Standard, Therapeutic Device Domain – Implantable Cardiac Device Topic,
and the subsections below for the content of the required OBX.
The constrained message structure is given in Table 4.12-1, with additional details provided in
sections below.
Table 4.12-1 ORU Message Structure
ORU

Observation Results Message

MSH[{ SFT }]PID[ PV1 ]OBR[{ NTE }]OBX[ {OBX} ][OBR

Message Header
Software Segment
Patient Identification
Patient Visit
Observations Request
Notes and comments
Observation result
Observation result--- optional Pulse Generator BEGIN
Observations Request for Pulse
Generator
Observation results

{OBX}
]

--- optional Pulse Generator END[{--- optional Lead grouping BEGIN

OBR
{OBX}
}]
[DSC]

Observations Request for Lead
Observation results--- optional Lead grouping END
Continuation Pointer4.12.5.2.1

Usage

Chapterin HL7Main OBR - clinical context
Implementation specific
HL7 v3-derived XML payload
PDF document payload

2
2
3
3
7
2
7
7
2

items related to the pulse
generator

7

May repeat for each leadreported2
items related to the lead2

MSH Segment – Message Header
Table 4.12-2 – MSH Segment

ELEMENT NAME

SEQ

DT
SEQ

DT

LEN

USAGE

CARD

TBL#

ITEM #Fixed

Ex. Values

Field Separator

1

ST

1

R

[1..1]

00001

Encoding Characters

2

ST

4

R

[1..1]

00002

^~\&

Sending Application

3

HD

227

RE

[0..1]

00003

Device Vendor
App
Vendor0361|

Sending Facility

4

HD

227

RE

[0..1]

00004

Receiving Application

5

HD

227

RE

[0..1]

00005

Clinic Application

Receiving Facility

6

HD

227

RE

[0..1]

00006

Clinic ID

Date/Time Of Message

7

TS

26

R

[1..1]

00007

20070117130129__________________________________________________________________________
31
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________ELEMENT NAME

SEQ

Message Type

DT
SEQ

9

Message Code1

Trigger Event

2

DT

LEN

USAGE

CARD

TBL#

MSG

15

R

[1..1]

ID

3

R[1..1]

0076
0003

ITEM #

Ex. Values

00009
Y

ID

3

R

[1..1]

Message Control ID

10

ST

20

R

[1..1]

Processing ID

11

ID

1

R

[1..1]

0103

00011

Version ID

12

ID

5

R

[1..1]

0104

00012

Character Set

18

ID

6

C

[1..*]

0211

00692

4.12.5.2.2

Fixed

ORU

Y

R01

00010

123450PY

2.5
8859/1PID Segment – Patient Identification
Table 4.12-3 – PID Segment

ELEMENT NAME

SEQ

Patient Identifier List

3

ID Number

DT
SEQ

1

DT

LEN

USAGE

CX

20

R

[1..*]

ST

199

R[1..1][1..1]

Assigning Authority

4

HD

227

R

Identifier Type Code

5

ID

50

R

CARD

TBL#

ITEM #Fixed

Ex. Values

00106
model:xxx/serial:yy
y
GDT
0203

MS

Patient Name

5

XPN

250

R

[1..*]

00108

Date/Time Of Birth

7

TS

26

RE

[0..1]

001100Smith^John
19590602

Sex

8

IS

1

RE

[0..1]

00111

M

Patient Address

11

XAD

250

RE

[0..1]

00114

PID-3.1 Patient Identifier List - ID Number contain a unique identifier for the patient assigned by
the Observation Creator. Identifier Type Code is constrained by Table 0203 listed below (others
can be included as defined in the 2.5 standard). An identifier of type MS is required. This will
be used by the Observation Processor / Repository actor to match the device interrogations withthe patient accounts. Assigning Authority is a unique name of the Observation Creator system orowning organization that creates the observation and will be coded using the IEEE P10731.1.3
IDC Nomenclature, MDC_IDC_DEVICE_MANUFACTURER term.
Table 4.12-4 Table 0203
Code

Description

Notes

Usage

MS

Model and Serial Number of Device

Model and Serial number shall beconcatenated together and must be
unique within an Assigning Authority.

R

IEEE E1073.1.1.3
MDC_IDC_DEVICE_MODEL and
MDC_IDC_DEVICE_SERIAL_NUMBER

The format of the ID shall befollowing:“model:xxx/serial:yyy”__________________________________________________________________________
32
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
Example:model:XZY987/serial:abc123
SS

Patient Social Security Number

4.12.5.2.3

Social Security number shall be
included if known.

RE

PV1 Segment – Patient Visit (Optional)
Table 4.12-5 – PV1 Segment

ELEMENT NAME

SEQ

DT

LEN

USAGE

Set ID - PV1

1

SI

4

R

Patient Class

2

IS

1

Location

3

PL

Attending Doctor

7

Visit Number

19

DT
SEQ

CARD

TBL#

ITEM #Fixed

Ex. Values[1..1]

00131

Y

1

R

[1..1]

00132

Y

R

80

O

[0..1]

00133

XCN

250

O

[0..1]

00137

CX

250

RE

[0..1]

00149

ClinicLocation

1234567890

Because this is an unsolicited observation and the Observation Creator will not be aware of an
associated order, this segment is optional. The Observation Creator may want to track theinterrogation as a visit using this segment. If information is provided here it must matchcorresponding information provided in the OBX segments.
PV1-7 Attending Doctor will be captured by the Interrogator / Observation Creator actor. If
present, PV1-7.1 Attending Doctor ID Number will be a unique identifier for each doctor in thecontext of the Interrogator / Observation Creator actor, not the Observation Processor /Repository actor.
PV1-19 Visit Number, ID Number will be a unique identifier generated by the Observation
Creator for each visit.

4.12.5.2.4

OBR Segment – Observation Request
Table 4.12-6 – OBR Segment

ELEMENT NAME

SEQ

COMP

DT

LEN

USAGE

CARD

TBL#

ITEM #FixedY

Ex. Values

Set ID – OBR

1

SI

4

R

[1..1]

00237

Placer Order Number

2

EI

427

RE

[1..1]

00216

1234567890

Filler Order Number

3

EI

427

R

[1..1]

00217

1234567891

Universal Service ID

4

CE

250

R

[1..1]

4.12-7(below) 00238

ST

256

R

[1..1]

Identifier

1

1

Follow-up__________________________________________________________________________
33
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________ELEMENT NAME

SEQ

Text

COMP

2

DT

LEN

USAGE

CARD

ST

256

R

[1..1]TBL#

ITEM #Fixed

Ex. Values
HL7 v2.5 device
observations for a
Follow-up

Observation Date/Time #

7

TS

26

R

[1..1]

00241

20060317160000+00
06

Observation End
Date/Time #

8

TS

26

RE

[0..1]

00242

20060317170000+00
06

Filler Field 1

20

ST

256

C

[0..1]

00253

Model:12345678/seri
al:123234345

Results Rpt/Status Chng Date/Time +
22

TS

24

RE

[0..1]

00255

20060317170000+00
06

Result Status +

25

ID

1

R

[1..1]

00258

F

Principal Result Interpreter 32

NDL

200

O

[0..1]

00264

Assistant Result
Interpreter

33

NDL

200

O

[0..*]

00265

Technician

34

NDL

200

O

[0..*]

00266

0123

OBR-2 Placer Order Number will usually be empty given that this is an unsolicited order.
OBR-3 Filler Order Number will contain a unique identifier for the observation / interrogation
session generated by the Observation Creator actor.
OBR-4.1-2 Universal Service ID, Identifier and Text can identify unique OBR segments thatpartition observations. The following table lists of values for these fields.
Table 4.12-7 OBR-4 Table
ID

Text

Implant

HL7 v2.5 device observations at Implant

Follow-up

HL7 v2.5 device observations for a Follow-up

OBR-25 Result Status values shall be one of the values in Table 4.12-8.
Table 4.12-8 Result Status
Value

Description

R

Results stored; not yet verified

P

Preliminary: A verified early result is available, final results not yet obtainedF

Final results; results stored and verified. Can only be changed with a corrected
result.

C

Correction to results__________________________________________________________________________
34
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
OBR-32 Principal Result Interpreter, OBR-33 Assistant Result Interpreter, and OBR-34
Technician if present shall at a minimum define components Name and Facility.

4.12.5.2.5

OBX Segment with Encapsulated v3 Message

An encapsulated XML document containing the Implantable Cardiac Device Follow-up
observation shall be included in the Observation message. The XML document must be
encapsulated within an OBX-5 Observation Value field of the OBX segment.
Table 4.12-9 – OBX Segment
ELEMENT NAME

SEQ

COMP

DT

LEN

USAGE

CARD

Set ID - OBX

1

SI

4

R

[1..1]

Value Type

2

ID

2

R

[1..1]

Observation Identifier

3

CE

250

R

[1..1]

ST

20

R[1..1]

Identifier

1

Text
Name of Coding
SystemObservation Value

TBL#

ITEM #

Fixed

00569
0125

00570

Ex. Values
1

Y

ED

Y

IDC

00571

2

ST

80

R

[1..1]

Y

Implantable Cardiac
Device Follow-up
Observation

3

ST

20

R

[1..1]

Y

99IHE

ED

*

R

[1..1]

500573

Type of Data

2

ST

20

R

[1..1]Y

Application

Data Subtype

3

ST

20

R

[1..1]Y

XML

Encoding

4

ST

20

R

[1..1]

Y

Base64

Data

5

TX

*

R

[1..1]

Observation Result
Status

11

ID

1

R

[1..1]

Date/Time of the
Observation

14

TS

26

RE

[0..1]

Observation Method

17

CE

250

Encapsulated andBase64 binary encoded
XML File
0085

00579
00582

Y

F
20060317170000+0006

00936

Identifier

1

ST

20

R

[1..1]

MDC_IDC_SESSION_
TYPE

Text

2

ST

40

R

[1..1]In Clinic

Name of Coding
System

3

ST

12

R

[1..1]IEEE P10731.1.3

EI

128

O

[0..*]

Equipment Instance
Identifier

18

01479

Programmer XXXX

OBX-3 Observation Identifier shall have the coded value identifier “IDC” from Coding System“99IHE”, with Text meaning “Implantable Cardiac Device Follow-up Observation”.
__________________________________________________________________________
35
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
OBX-5.2 Type of Data component shall have the value “Application”
OBX-5.3 Data Subtype component shall have the value “XML”.
OBX-5.4 Encoding component shall have the value “Base64”.
OBX-5.5 Data component contains the encapsulated Base64-encoded XML document.
Note! The base64 encoded XML document must not include CR/LF characters, which are
forbidden within HL7 field text streams. Breaking a base64 encoded stream into lines of 76
characters or less is used for email in accordance with RFC 822, but is not applicable toencapsulated data in HL7.
The encapsulated XML document will consist of the message content specified by the HL7 v3
Therapeutic Device Domain / Implantable Device – Cardiac / Implantable Cardiac Device
Results Notification message, message wrappers (transmission and control act) shall not be
included. The Refined Message Implementation Model (RMIM) POTD_RM000001 is shown in
Figure 4.12-3, and the Hierarchical Message Description (HMD) POTD_HD000001 for themessage is defined in Table 4.12-10 following. Refer to the HL7 Therapeutic Devices
Implantable Cardiac Device Topic RMIM at
http://www.ihe.net/Technical_Framework/index.cfm#cardiology for more details.
The deviceObservation, patientObservation, deviceTherapy, and deviceTherapySettings classesof observations shall be coded using “IEEE 1073.1.1.3 Health Informatics - Point-of-Care
Medical Device Communication - Nomenclature - Implantable Cardiac Device” terms. (IEEE1073.1.1.3 specification forthcoming pending final balloting of the standard.)
OBX-17.1-3 Observation Method Identifier, Text, and Name of Coding system values shall be
coded using the IEEE P10731.1.3 IDC Nomenclature, MDC_IDC_SESSION_TYPE term.
OBX-18.1 Equipment Instance Identifier, Entity Identifier – A unique identifier for theequipment or software that was responsible for the production of the observation.

__________________________________________________________________________
36
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

Observation
component
typeCode*: <= COMP
contextControlCode: CS CNE [0..1]<= ContextControlPropagating "AP"contextConductionInd: BL [0..1]
sequenceNumber: INT [0..1]
priorityNumber: INT [0..1]

Note:
E.g.: Brady Settings
Pacing Output Settings
Atrial Tachy Settings
Ventricular Tachy Settings

0..1 roleName

CMET: (PAT)R_Patient[identified/confirmable](COCT_MT050002)

typeCode*: <= RCT
contextControlCode: CS CNE [0..1] <= "OP"1..1 patient

typeCode*: <= SBJ
contextControlCode: CS CNE [0..1]<= OP "ContextControlOverriding"

DeviceTherapySetting
0..* deviceTherapySetting

recordTarget

subjectclassCode*: <= OBS
moodCode*: <= EVN
code*: CE CWE [1..1] <= ImplantedCardiacDeviceControlVariable(Externally defined subset of IEEE 1073 vocabulary)
text: ED [0..1]
value: ANY [0..1]

classCode*: <= OBS
moodCode*: <= EVN
id*: SET<II> [1..*]
code*: CD CWE [1..1] <=DeviceInterrogation(The capturing or reading out of datastored in the
medical device)statusCode: CS CNE [0..1] <=ActStatus
effectiveTime*: TS [1..1]

1..1 patient *0..* deviceTherapySetting

controlVariableclassCode*: <= ACT
typeCode*: <= CTRLV
moodCode*: <= EVN
contextControlCode: CS CNE [0..1] <= "AN"id: SET<II> [0..*]contextConductionInd: BL [0..1] "false"
code*: CD CWE [1..1] <= MedicalDeviceAct
text: ED [0..1]
effectiveTime: TS [0..1]

DeviceTherapy

1..* assignedEntity

author0..* patientObservation

component
typeCode*: <= COMP
contextControlCode: CS CNE [0..1]<= ContextControlPropagating "AP"contextConductionInd: BL [0..1]
sequenceNumber: INT [0..1]
priorityNumber: INT [0..1]

typeCode*: <= SUBJ
contextControlCode: CS CNE [1..1] <= "ON"contextConductionInd: BL [0..1] "true"component3
typeCode*: <= COMP
contextControlCode: CS CNE [0..1] <= "AN"contextConductionInd: BL [0..1] "true"

typeCode*: <= COMP
contextControlCode: CS CNE [0..1] <= "AN"contextConductionInd: BL [0..1] "true"component1

componentOf

CMET: (ENC)
A_Encounter
typeCode*: <= COMP
[universal]
contextControlCode: CS CNE [1..1] <= "OP"
(COCT_MT010000)
contextConductionInd: BL [1..1] "false"
0..1 encounter *typeCode*: <= COMP
contextControlCode: CS CNE [0..1] <= "AN"contextConductionInd: BL [0..1] "true"

primaryPerformer
typeCode*: <= PPRF
contextControlCode: CS CNE[0..1] <= "OP"Note:This ACT changes the
subject from patient to
the device.

0..1 externalCardiacInterrogationDevice

reusableDevice

ExternalCardiacInterrogationDevice

typeCode*: <= RDV

classCode*: <= ASSIGNED
id: II [0..1]
code: CE CWE [0..1] <= DedicatedServiceDeliveryLocationRoleType

1..1 assignedDevice
1..1 assignedDevice *0..1 roleName

subject
typeCode*: <= SBJ
contextControlCode: CS CNE [0..1] <= "OP"CMET: (ASSIGNED)
R_AssignedDevice[universal](COCT_MT090300)

Organization

component
typeCode*: <= COMP
contextControlCode: CS CNE [0..1] <= "ON"contextConductionInd: BL [0..1] "true"

0..* deviceObservation

DeviceObservation

0..* deviceObservation

performer

Note:
Participant who assists inperforming the interrogationof the implanted device

component20..* organizer(COCT_MT090002)

0..* assignedEntity
typeCode*: <= PRF

0..* patientObservation

classCode*: <= ORGANIZER
moodCode*: <= EVN

CMET: (ASSIGNED)
R_AssignedEntity[identified/confirmable]

subject

0..* deviceTherapy

Organizer

0..1 roleName

typeCode*: <= AUT
time*: TS [1..1]
signatureCode: CE CNE [0..1] <= X
signatureText: ED [0..1]

PatientObservation
classCode*: <= OBS
moodCode*: <= EVN
id: II [0..1]
code*: CD CWE [1..1] <= CardiacDevicePatientObservationType
text: ED [0..1]
effectiveTime: IVL<TS> [0..1]
value: ANY [0..1]
interpretationCode: CE CNE [0..1]<= ObservationInterpretationNormality

Description: Implantable Cardiac Device Summary report.
This report contains a subset of current programmed settingsand device observations

MedicalDeviceAct0..* medicalDeviceActclassCode*: <= PROC
moodCode*: <= EVN
id: II [0..1]
code*: CE CWE [1..1] <= ImplantedCardiacDeviceTherapy (IEEE 1073)
text: ED [0..1]
activityTime: TS [0..1]

Implantable Cardiac Device Summary(POTD_RM000001)

classCode*: <= OBS
moodCode*: <= EVN
code*: CD CWE [1..1]<= CardiacDeviceSelfObservationType(IEEE1073)
text: ED [0..1]
effectiveTime: IVL<TS> [0..1]
value: ANY [0..1]
interpretationCode: CE CNE [0..1]<= ObservationInterpretationNormality
methodCode: CE CWE [0..1]<= ObservationMethod (IEEE 1073)

classCode*: <= ORG
determinerCode*: <= INSTANCE
id: SET<II> [0..*]name: BAG<EN> [0..*]Note:
Implantable Cardiac
Device or identified lead

0..1 assignedInterrogationDevice

InterrogationDeviceclassCode*: <= DEV
determinerCode*: <= INSTANCE
id: II [0..1] (e.g. Serial Number)desc: ED [0..1]
manufacturerModelName: SC CWE [0..1] <= ManufacturerModelName
softwareName: SC CWE [0..1] <= SoftwareName

component
typeCode*: <= COMP
contextControlCode: CS CNE [1..1]<= ContextControlPropagating "AP"contextConductionInd: BL [0..1]
sequenceNumber: INT [0..1]
priorityNumber: INT [0..1]

Figure 4.12-3 - POTD_RM000001__________________________________________________________________________
37
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
Table 4.12-10 - HMD
No

Element Name

Card

Mand

Conf

1

Observation

0..1

2

classCode

1..1

M

R

Act

CS

D

3

moodCode

1..1

M

R

Act

CS

D

4

id

1..*

M

R

Act

SET<II>

D

5

code

1..1

M

R

Act

CD

D

6

statusCode

0..1

Act

CS

D

7

effectiveTime

1..1

Act

TS

D

8

reusableDevice

0..1

Act

ReusableDevice

N

9

typeCode

1..1

Participation

CS

D

10

externalCardiacInterrogationDevice

1..1

Participation

ExternalCardiacInterrogationDevice

N

R

M

M

R

R

Rim Source
Sourceof Message Element Type

Src

Observation

ObservationN

11

classCode

1..1

Role

CS

D

12

id

0..1

Role

II

D

13

code

0..1

Role

CE

D

14

assignedInterrogationDevice

0..1

Role

InterrogationDeviceN

15classCode

1..1

M

R

EntityCSD

16

determinerCode

1..1

M

R

Entity

CS

D

17

id

0..1

Entity

II

D

18

desc

0..1

EntityEDD

19manufacturerModelName

0..1

DeviceSCD

20

softwareName

0..1

Device

SC

D

R

Act

RecordTarget

N

R

Participation

CS

D

Participation

CS

D

R

Participation

COCT_MT050002UV0C

Act

SET<Performer>

N

Participation

CS

D

21

recordTarget

1..1

22

typeCode

1..1

23

contextControlCode

0..1

24

patient

1..1

25

performer
performer

0..*

26
27
28

M

typeCode

1..1

assignedEntity

1..1

Participation

COCT_MT090002

C

1..*

Act

SET<Author2>

N

R

Participation

CS

D

R

Participation

TS

D

ParticipationCED

author29

typeCode

1..1

30

time

1..1

31

signatureCode

0..1

M

M

R

32

signatureText

0..1

Participation

ED

D

33

assignedEntity

1..1

Participation

COCT_MT090002

U

0..*

Act

SET<Subject1>

N

ActRelationship

CS

D

34

subject

35

typeCode

1..1

M

R

36

contextControlCode

1..1

ActRelationship

CS

D

37

contextConductionInd

0..1

ActRelationship

BL

D__________________________________________________________________________
38
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

No

Element Name

Card

Mand

Rim Source
Sourceof Message Element Type

Src

ActRelationship

MedicalDeviceAct

N

R

Act

CS

D

R

Act

CS

D

Act

SET<II>

D

R

Act

CD

D

0..1

Act

ED

D

effectiveTime

0..1

Act

TS

D

subject

1..1

Act

Subject3

N

38

medicalDeviceAct

1..1

39

classCode

1..1

M

40

moodCode

1..1

M

41

id

0..*

42

code

1..1

43

text

44
45
46

typeCode

1..1

Participation

CS

D

47

contextControlCode

0..1

Participation

CS

D

48

patient

1..1

Participation

COCT_MT050002UV0

U

1..1

Act

PrimaryPerformer

N

49

primaryPerformer

M

Conf

M

R

50

typeCode

1..1

Participation

CS

D

51

contextControlCode

0..1

R

Participation

CS

D

52

assignedDevice

1..1

Participation

COCT_MT090300UV0

C

0..*

Act

SET<ControlVariable>

N

53

controlVariable

54

typeCode

1..1

ActRelationship

CS

D

55

contextControlCode

0..1

ActRelationship

CS

D

56

contextConductionInd

0..1

ActRelationship

BL

D

57

deviceTherapySetting

1..1

ActRelationshipDeviceTherapySetting

N

M

R

58

classCode

1..1

M

R

Act

CS

D

59

moodCode

1..1

M

R

Act

CS

D

60

code

1..1

M

R

Act

CE

D

61

text

0..1

Act

ED

D

62

value

0..1

Observation

ANY

D

63

component

0..*

Act

SET<Component7>

N

64

typeCode

1..1

ActRelationship

CS

D

65

contextControlCode

0..1

ActRelationship

CS

D

66

contextConductionInd

0..1

ActRelationship

BL

D

67

sequenceNumber

0..1

ActRelationship

INT

D

68

priorityNumber

0..1

ActRelationship

INT

D

69

deviceTherapySetting

1..1

ActRelationshipDeviceTherapySetting

R

0..*

Act

SET<Component1>

N

M

R

70

component1

71

typeCode

1..1

ActRelationship

CS

D

72

contextControlCode

0..1

ActRelationship

CS

D

73

contextConductionInd

0..1

ActRelationship

BL

D

74

organizer

1..1

ActRelationship

Organizer

N

Act

CS

D

75

classCode

1..1

M

M

R

R

__________________________________________________________________________
39
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

No

Card

Mand

Conf

Rim Source
Sourceof Message Element Type

Src

76

Element Name
moodCode

1..1

M

R

Act

CS

D

77

subject

1..1

R

Act

Subject2

N

R

Participation

CS

D

Participation

CS

D

R

Participation

COCT_MT090300UV0U

Act

SET<Component2>

N

ActRelationship

CS

D

ActRelationship

CS

D

78

typeCode

1..1

79

contextControlCode

0..1

80

assignedDevice

1..1

M

81

component

0..*

82

typeCode

1..1

83

contextControlCode

0..1

84

contextConductionInd

0..1

ActRelationship

BL

D

85

deviceObservation

1..1

ActRelationshipDeviceObservation

N

M

R

86

classCode

1..1

M

R

Act

CS

D

87

moodCode

1..1

M

R

Act

CS

D

88

code

1..1

M

R

Act

CD

D

89

text

0..1

Act

ED

D

90

effectiveTime

0..1

Act

IVL<TS>

D

91

value

0..1

Observation

ANY

D

92

interpretationCode

0..1

Observation

CE

D

93

methodCode

0..1

Observation

CE

D

94

component

0..*

Act

SET<Component8>

N

95

typeCode

1..1

ActRelationship

CS

D

96

contextControlCode

1..1

ActRelationship

CS

D

97

contextConductionInd

0..1

ActRelationship

BL

D

98

sequenceNumber

0..1

ActRelationship

INT

D

99

priorityNumber

0..1

ActRelationship

INT

D

100

deviceObservation

1..1

ActRelationshipDeviceObservation

R

Act

SET<Component3>

N

ActRelationship

CS

D

M

R

101

component2

0..*

102

typeCode

1..1

103

contextControlCode

0..1

ActRelationship

CS

D

104

contextConductionInd

0..1

ActRelationship

BL

D

105

patientObservation

M

R

ActRelationshipPatientObservation

N

106

classCode

1..1

1..1
M

R

Act

CS

D

107

moodCode

1..1

M

R

Act

CS

D

108

id

0..1

Act

II

D

109

code

1..1

Act

CD

D

110

text

0..1

Act

ED

D

111

effectiveTime

0..1

Act

IVL<TS>

D

112

value

0..1

Observation

ANY

D

113

interpretationCode

0..1

Observation

CE

D

M

R

__________________________________________________________________________
40
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

No

Element Name

Card

Rim Source
Sourceof Message Element Type

Src

Act

SET<Component6>

N

ActRelationship

CS

D

ActRelationship

CS

D

ActRelationship

BL

D

ActRelationship

INT

D

ActRelationship

INT

D

1..1

ActRelationshipPatientObservation

R

0..*

Act

SET<Component4>

N

114

component

0..*

115

typeCode

1..1

116

contextControlCode

0..1

117

contextConductionInd

0..1

118

sequenceNumber

0..1

119

priorityNumber

0..1

120

patientObservation

Mand

M

Conf

R

121

component3

122

typeCode

1..1

ActRelationship

CS

D

123

contextControlCode

0..1

ActRelationship

CS

D

124

contextConductionInd

0..1

ActRelationship

BL

D

125

deviceTherapy

1..1ActRelationshipDeviceTherapyN

126

classCode

1..1

M

R

Act

CS

D

127

moodCode

1..1

M

R

Act

CS

D

128

id

0..1

Act

II

D

129

code

1..1

Act

CE

D

130

text

0..1

Act

ED

D

131

activityTime

0..1

Act

TS

D

R

Act

Component5

N

R

ActRelationship

CS

D

M

M

R

R

132

componentOf

0..1

133

typeCode

1..1

134

contextControlCode

1..1

ActRelationship

CS

D

135

contextConductionInd

1..1

ActRelationship

BL

D

136

encounter

1..1

ActRelationship

COCT_MT010000UV0

C

M

R

4.12.5.2.5.1 XML schema
The IDCO profile defines constraints for the IDC RMIM usage in CARD-12 transaction at the
XML schema level.
The XML document that is encoded in the OBX.5 segment shall be constructed based on the
XML schema defined by this profile – shown below.
Further descriptions of constraints follow in subsequent sections of this document.

__________________________________________________________________________
41
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________<?xml version="1.0" encoding="UTF-8" standalone="no"?><!-- edited with XMLSpy v2006 U (http://www.altova.com) by Jürgen Kerstna (St. Jude Medical
AB) --><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:hl7-org:v3"
xmlns:mif="urn:hl7-org:v3/mif" targetNamespace="urn:hl7-org:v3"
elementFormDefault="qualified"><xs:annotation>__________________________________________________________________________
42
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________<xs:documentation>Manual creation IHE - Cardiology EP ICDI profile.xsl
version 2.0</xs:documentation></xs:annotation><xs:include schemaLocation="../coreschemas/infrastructureRoot.xsd"/><xs:include schemaLocation="../coreschemas/NarrativeBlock.xsd"/><xs:include schemaLocation="POTD_HD000001.xsd"/><xs:element name="IHE_IDCO_DeviceSummary"
type="POTD_HD000001.Observation"><xs:annotation><xs:documentation>Root of the CARD-12 transaction payload in IDCO
integration profile. It is of Observation type, which is from HL7 IDC RMIM</xs:documentation></xs:annotation></xs:element></xs:schema>
4.12.5.2.5.2 IHE_IDCO_DeviceSummary->effectiveTime element constraints
IHE_IDCO_DeviceSummary ->effectiveTime element is set to the timestamp of the session that
captured the device summary data. It shall have a meaning of the
MDC_IDC_PREVIOUS_SESSION_DATE_TIME item defined in the IEEE 1073.1.1.3
nomenclature. If OBX-14 is set in the HL7 2.5 OBX segment, these values shall match.
4.12.5.2.5.3 ReusableDevice - Interrogation device – programmer
This is optional but recommended.
The element reusableDevice->externalCardiacInterrogationDevice>assignedInterrogationDevice shall have two child elements created:•

manufacturerModelName – name of the programmer used to interrogate the data•

softwareName – name and version of the programmer application used to interrogate thedata in this message.

Both elements are of SC type – Character String. The code is optional and can be present, if the
manufacturer has its own code tables defined, but the values shall also be stored as st element
values. If the OBX-18 Equipment Instance Identifier is set in the HL7 v2.5 OBX segment, thesevalues shall match.
4.12.5.2.5.4 recordTarget – Patient
The element recordTarget->patient->patientPerson specifies the patient of this observation•

Sequence of id elements shall match the PID segment of HL 2.5 wrapper of this XML
document__________________________________________________________________________
43
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________•

It is strongly recommended that the demographics data in other elements – name,administrativeGenderCode, birthTime – be populated if available.

4.12.5.2.5.5 Interrogation device – Author
This element is required. author->assignedEntity->assignedPerson shall be the clinician who is
responsible for the interrogation.
•

assignedEntity->id element shall contain the clinical ID of the clinician•

assignedEntity->assignedPerson->name element shall contain at least family and given
elements•

Author->assignedEntity->representedOrganization element shall contain the informationof the clinic/hospital where interrogation took place and where the Author belongs to.

There may be several instances of author elements provided; each of them shall represent
assignedPerson. If OBR-32 Principal Result Interpreter or OBR-33 Assistant Result Interpreter
are set in the HL7 2.5 OBR segment, these values shall match.
4.12.5.2.5.6 Performer
This element is optional. According to RMIM, performer is “participant who assists inperforming the interrogation of the device”. There maybe none to several assistants specified in
the message. This profile does not constrain this element. If OBR-34 Technician is set in the
HL7 2.5 OBR Segment, these values shall match.
4.12.5.2.5.7 Encounter
This is optional and not constrained by this profile. However, if information about theinterrogation/clinic/hospital is available, this can be provided in medicalDeviceAct>componentOf->encounter element.
4.12.5.2.5.8 IHE_IDCO_DeviceSummary –> subject element constraints andmultiple device mappings
IDC Summary incorporates data and IEEE 1073 defines terms that may be related to different
physical devices. For example there are terms for the pulse generator device itself or connectedleads.
IDC RMIM model and generated XML schema is designed with this in mind, but it can beachieved in different ways. The following multiple device mapping constraints are required forunambiguous XML document content.
The cardinality of medicalDeviceAct is constrained to 1, i.e. the root element
IHE_IDCO_DeviceSummary of Observation type shall have one and only one child subject
element.
__________________________________________________________________________
44
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
medicalDeviceAct ->effectiveTime element shall be omitted, as its timestamp is the same as
IHE_IDCO_DeviceSummary ->effectiveTime.
4.12.5.2.5.9 Implantable Cardiac Device – pulse generator
The medicalDeviceAct ->primaryPerformer->assignedDevice element specifies the Implantable
Cardiac Device.
It contains only minimal information required for its identification. All its other descriptive items
defined in the IEEE1073.1.1.3 nomenclature are stored as DeviceObservation elements.
•

assignedDevice shall have 1 instance of child id element, no other elements or attributes
are required
o id.extension is set to the combination of IEEE1073.1.1.3 nomenclature terms
MDC_IDC_DEVICE_MODEL and MDC_IDC_DEVICE_SERIAL_NUMBER,
formatted by same rules that apply to PID-3.1 in HL7 2.5 PID segment(“model:xxx/serial:yyy”)
o id.root is optional and shall be set to UID of the manufacturer, if available

This Organizer has to have a child subject->assignedDevice element, which is carbon copy ofthe medicalDeviceAct ->primaryPerformer->assignedDevice.
Note! assignedDevice is referred via two different paths with strong 1..1 cardinality:
1. medicalDeviceAct->primaryPerformer->assignedDevice
2. medicalDeviceAct->component1->organizer->subject->assignedDevice
We end up with 2 identical instances for assignedDevice that represents Pulse Generator.
These two elements shall refer to the same device by containing identical ID of the device for
lookup.
There shall be one instance of medicalDeviceAct ->component1->Organizer element created for
Implantable Cardiac Device.
All DeviceObservation that belong to the Implantable Cardiac Device shall be child elements ofthis Organizer.
4.12.5.2.5.10 Leads
Each lead is represented with one instance of medicalDeviceAct ->component1->Organizer
element. The cardinality of medicalDeviceAct ->component1 shall be number of leads +1.
The Organizer->subject->assignedDevice element shall be created•assignedDevice shall have 1 instance of child id element, no other elements or attributes
are required__________________________________________________________________________
45
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
o id.extension is set to the combination of IEEE1073.1.1.3 nomenclature terms
MDC_IDC_LEAD_MODEL and MDC_IDC_LEAD_SERIAL_NUMBER,
formatted by same rules that apply to PID-3.1 in HL7 2.5 PID segement(“model:xxx/serial:yyy”)
o id.root is optional and shall be set to UID of the manufacturer, if available
4.12.5.2.5.11 IEEE 1073.1.1.3 item mapping
The nomenclature defines items that are divided into Observation Groups. These groups
correspond to four different HL7 IDC RMIM observation groups. This section defines the
mapping between IEEE and RMIM/XML observation groupsIEEE
1073.1.1.3

POTD_HD000001.Observation

All groups

Mapping details
The code element
stores the identity ofthis observation
item. See section
14.5.2.5.13 fordetails.
The id element shallnot be created, codeis used for identity
The effectiveTime
element might not bepresent, if theobservation sharesthe effectiveTime ofObservation
element, but it might
be set to distinguishseveral instances ofoccurrence of same
type of observation.
(Example:
MDC_IDC_CAPACITOR_CH
ARGE_ENERGY requires
timestamp of the delivered
shock )__________________________________________________________________________
46
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
IEEE
1073.1.1.3

POTD_HD000001.Observation

DeviceObservation

Mapping details
The value is stored
in the value elementof corresponding
type (see section
14.5.2.5.14) and isrequired.
The text element is
optional and if
present then it holds
a free text comment
about thisobservation.
Note! The
nullFlavor attributeof the value element
shall be used insteadof the value attributein case where value
does not exist, butthere is a need tocommunicate thereason of absence!
The nullFlavor
attribute and value
elements aremutually exclusive.

__________________________________________________________________________
47
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
IEEE
1073.1.1.3

POTD_HD000001.Observation

Patient
Observation

Mapping details
The value is storedin value element ofcorresponding type(see section
14.5.2.5.14) and isrequired.
All that applies fortext element andnullFlavor attributeforDeviceObservation
applies here as well.

DeviceTherapy
Setting

The value is storedin value element ofcorresponding type(see section
14.5.2.5.14) and isrequired.
All that applies fortext element andnullFlavor attributeforDeviceObservation
applies here as well.

__________________________________________________________________________
48
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
IEEE
1073.1.1.3

POTD_HD000001.Observation

Mapping details

DeviceTherapy

The value of String
type is stored in the
text element
The activityTime
element shall becreated if it isdifferent from
effectiveTime of thisObservation.
The nullFlavor
attribute of text
element is used if
text is missing.

4.12.5.2.5.12 Missing and out-of-type values
Sometimes there is no value captured for a certain item, but the Observation Creator wants todenote the fact that the value is not available. In this case the HL7 v3 NullFlavor mechanism
shall be used. The value element shall not contain the value attribute. Instead, the nullFlavor
attribute shall be used to code the reason for the missing value as determined by the Observation
Creator system. The codes are from the Table 3 in HL7 v3 ballot specification section Data
Types - Abstract Specification.
code

name

definitionNI

NoInformation

No information whatsoever can be inferred from thisexceptional value. This is the most general exceptional
value. It is also the default exceptional value.

OTH

other

The actual value is not an element in the value domain of
a variable. (e.g., concept not provided by required code
system).

NINF

negative
infinity

Negative infinity of numbers.

PINF

positive infinity

Positive infinity of numbers.

UNK

unknown

A proper value is applicable, but not known.

ASKU

asked but
unknown

Information was sought but not found (e.g., patient was
asked but didn't know)__________________________________________________________________________
49
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
code

name

NAV

temporarily
unavailable

definition
Information is not available at this time but it is expectedthat it will be available later.

NASK not asked

This information has not been sought (e.g., patient was
not asked)

TRC

trace

The content is greater than zero, but too small to bequantified.

MSK

maskedThere is information on this item available but it has notbeen provided by the sender due to security, privacy orother reasons. There may be an alternate mechanism forgaining access to this information. Note: using this null
flavor does provide information that may be a breach ofconfidentiality, even though no detail data is provided. Its
primary purpose is for those circumstances where it isnecessary to inform the receiver that the information
does exist without providing any detail.

NA

not applicable

No proper value is applicable in this context (e.g., last
menstrual period for a male).

not present

Value is not present in a message. This is only defined inmessages, never in application data! All values notpresent in the message must be replaced by theapplicable default, or no-information (NI) as the default ofall defaults.

NP

The same mechanism shall be used to encode missing or out-of-type values for observations.
Example of denoting missing value:<deviceTherapySetting classCode="OBS" moodCode="EVN"><code code="MDC_IDC_SENSED_AVDELAY" codeSystemName="IEEE P1073.1.1.3"
codeSystemVersion="1.0" codeSystem=”HL7 MDC OID” displayName=" Sensed AV Delay " /><value nullFlavor="OTH" xsi:type="PQ" /></deviceTherapySetting>

Additional to null values defined in the table above, IEEE P1073.1.13 code tables can define
possible out-of-type null values.
Example of denoting out-of-type value:
MDC_IDC_PACING_VENTRICULAR_OFFSET has numeric values with exceptional value“Off”. Because the value element is typed, only numeric values can be set. In this case value
attribute shall not be created, and the nullFlavor attribute shall be set to “OFF”
Example:<deviceTherapySetting classCode="OBS" moodCode="EVN">__________________________________________________________________________
50
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________<code code="MDC_IDC_PACING_VENTRICULAR_OFFSET" codeSystemName="IEEE P1073.1.1.3"
codeSystemVersion="1.0" codeSystem=”HL7 MDC OID” displayName=" V-V Delay" /><value nullFlavor="OFF" xsi:type="PQ" /></deviceTherapySetting>“OFF” is defined in Table 20 of the IEEE1073.1.13 nomenclature. The ordinary type is PQ.
4.12.5.2.5.13 code mapping
Each observation item is defined by its code element.
code element attributeIEEE 1073.1.1.3 field

ExampleCode

Reference ID“MDC_IDC_BATTERY_LIFE”

codeSystemuid of IEEE 1073.1.1.3

TBD -codeSystemName

IEEE 1073.1.1.3 ICD terms“IEEE P1073.1.1.3”

codeSystemVersion

Used version“1.0”

displayName

IEEE Common Name“Battery Life”

Example:<code code="MDC_IDC_BATTERY_LIFE" codeSystemName="IEEE P1073.1.1.3"
displayName="BatteryLife"/>

4.12.5.2.5.14 IEEE 1073.1.1.3 nomenclature Data Type mapping
The nomenclature defines several data types for values of its items. IHE_IDCO.xsd defines
corresponding XML data types for each of these types. The value element type in RMIM is
defined as ANY. That means the actual type definition is up to the profiles of this message. IHE
IDCO is such profile and hereby defines actual data types.
IHE_IDCO data type

Applicable
IEEE 1073
types

Mapping details

ExampleST

String (notenumerated)

The value is stored
in the element.
None of theattributes are used.

<value xsi:type= "ST”>this is stringvalue</value>__________________________________________________________________________
51
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
IHE_IDCO data type

Applicable
IEEE 1073
types

Mapping details

ExampleCD

Enumerated

As minimum
displayName
attribute isrequired. If thecode is defined byany code table,
then the code andcodeSystemName
shall also bepresent. If thetable is normative
then codeSystem
attribute shall be
set<value code="BOL"
codeSystemName= "IEEEP1073.1.1.3"
displayName="Beginning of Life"xsi:type="CD" />TS

Timestamp

The value is stored
in the value
attribute, which isa simple XML ts
type<value value="20060117"
xsi:type="TS"/>

PQ

Number(x,y) The value is astored valueU
attribute which is
Number(x)Uof the XML typewith Units
real.
specified
The unit is stored
in the unit
attribute, which isof the XML
simple type cs,
and is coded witha UCUM unit code
as string specified
in UCUM c/s
column of theIEEE 1073.1.1.3
nomenclature<value unit="1/min" value="100.0"
xsi:type= "PQ"/>__________________________________________________________________________
52
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
IHE_IDCO data type

Applicable
IEEE 1073
types

Mapping details

ExampleST

Complextypes which
consist of
two or more
sub-values

The complex typeconsists of morethan one subobservation item.
The parent of thecomplex type willcontain the
concatenatedvalues for reportdisplay purposes.
Also see section
4.12.5.2.5.15 formore information
about Hierarchy
Mapping.

<value xsi:type= "ST”> 0.8 V @ 0.5
ms </value>

Also see section
4.12.5.2.5.15 for more
information about
Hierarchy Mapping.

<value value="5" xsi:type="INT" />INTThe value is stored
in the value
Number(x,0)
attribute which isof XML type int.
With nounits
specified

REAL

Number(x,y) The value is stored There is no items ofin the value
such type in current
nomenclature
attribute which is
Where y!=0 of XML type real.

Number(x)With nounits
specified

4.12.5.2.5.15

IEEE 1073.1.1.3 Hierarchy Mapping

The HL7 IDC RMIM specifies a possible hierarchy for each item in each observation group(excluding DeviceTherapy).

__________________________________________________________________________
53
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

This means that an observation item may have sub-items, if the IEEE1073.1.1.3 nomenclature
specifies so. There are 2 types of hierarchical items.
Sub-Items of Complex type
An example of such case is
MDC_IDC_LEAD_PACE_THRESHOLD_CONFIGURATION_IMPLANT. In this case, thisitem in the IEEE1073.1.1.3 nomenclature is followed by two sub-elements, each of them of type
PQ. The sub-items shall be in the sequence specified in the IEEE1073.1.1.3 nomenclature. The
sequenceNumber attribute is required.
<deviceObservation classCode="OBS" moodCode="EVN"><code code="MDC_IDC_LEAD_PACE_THRESHOLD_IMPLANT" codeSystemName="IEEEP1073.1.1.3" codeSystemVersion="1.0" displayName="Lead Pace Threshold at Implant Amplitude@ Pulse Width" /><value xsi:type= "ST”> 0.8 V @ 0.5 ms </value><component contextControlCode="AP" typeCode="COMP"><sequenceNumber value="1" /><deviceObservation classCode="OBS" moodCode="EVN"><code code="MDC_IDC_LEAD_PACE_THRESHOLD_IMPLANT_AMPLITUDE"
codeSystemName="IEEE P1073.1.1.3" codeSystemVersion="1.0" displayName="LeadPace Threshold at Implant Amplitude" /><value unit="V" value="0.8" xsi:type="PQ" /></deviceObservation></component><component contextControlCode="AP" typeCode="COMP"><sequenceNumber value="2" /><deviceObservation classCode="OBS" moodCode="EVN"><code code="MDC_IDC_LEAD_PACE_THRESHOLD_IMPLANT_PULSE_WIDTH"
codeSystemName="IEEE P1073.1.1.3" codeSystemVersion="1.0" displayName="LeadPace Threshold at Implant Pulse Width" /><value unit="ms" value="0.5" xsi:type="PQ" /></deviceObservation></component></deviceObservation>__________________________________________________________________________
54
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

Generic hierarchies
Any item may have sub-items. Which ones have is specified in the IEEE1073.1.1.3
nomenclature, where sub-items have their parent’s referenceID set, as well as their sequencenumber. The hierarchy can be more than one level. The sub-items shall be inserted in the orderof their sequence number within their parent item. The sequenceNumber attribute is required andelements order in XML must follow the sequence numbering within their parent.
Example:<deviceTherapySetting classCode="OBS" moodCode="EVN"><code code="MDC_IDC_TACHY_THERAPY_ZONE_PARAMETERS" codeSystemName="IEEE P1073.1.1.3"
codeSystemVersion="1.0" displayName="Therapy Zone Parameters" /><value code="Afib" codeSystemName="IEEE1073.1.1.3" displayName="Afib" xsi:type="CD" /><component contextControlCode="AP" typeCode="COMP"><sequenceNumber value="1" /><deviceTherapySetting classCode="OBS" moodCode="EVN"><code code="MDC_IDC_TACHY_THERAPY_STATUS" codeSystemName="IEEE P1073.1.1.3"
codeSystemVersion="1.0" displayName="Therapy Status" /><text>The status (i.e., On or Off) of the device therapy functions</text><value code="On" codeSystemName="IEEE1073.1.1.3" displayName="On" xsi:type="CD" /></deviceTherapySetting></component><component contextControlCode="AP" typeCode="COMP"><sequenceNumber value="2" /><deviceTherapySetting classCode="OBS" moodCode="EVN"></component><component contextControlCode="AP" typeCode="COMP"><sequenceNumber value="3" /><deviceTherapySetting classCode="OBS" moodCode="EVN"><code code="MDC_IDC_TACHY_ATP_THERAPY" codeSystemName="IEEE P1073.1.1.3"
codeSystemVersion="1.0" displayName="ATP Therapy" /><text>ATP therapy parent, its value is ATP number - i.e. 1 or 2 - which means ATP1 or ATP2
etc.</text><value value="1" xsi:type="INT" /><component contextControlCode="AP" typeCode="COMP"><component contextControlCode="AP" typeCode="COMP"></deviceTherapySetting></component><component contextControlCode="AP" typeCode="COMP"><component contextControlCode="AP" typeCode="COMP"><component contextControlCode="AP" typeCode="COMP"><sequenceNumber value="6" /><deviceTherapySetting classCode="OBS" moodCode="EVN"><code code="MDC_IDC_TACHY_ADDITIONALSHOCKS" codeSystemName="IEEE P1073.1.1.3"
codeSystemVersion="1.0" displayName="Number Of Additional Shocks" /><text>Number Of Additional Shocks: The number of additional max energy shocks in the zone
programmed for delivery.</text><value value="3" xsi:type="INT" /></deviceTherapySetting></component></deviceTherapySetting>__________________________________________________________________________
55
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
4.12.5.2.5.16

IEEE 1073.1.1.3 nomenclature Automatic/Manual mapping

The IEEE1073.1.1.3 nomenclature allows specifying for each DeviceObservation andPatientObservation whether it is automatically device-determined or manually clinician
determined during the device session, if applicable (the value is not N/A). In nomenclature thecolumn IEEE Automatic/Manual is used to specify this.
PatientObservation-> interpretationCode and DeviceObservation-> interpretationCode element
shall be created to set the value.
The type of interpretationCode element is CE – coded entry.
It shall be populated as following:
XML attribute

Values

Optionality

Code“A”,”M”

R

displayName“Automatic”, “Manual”

O

All other attributes
4.12.5.2.6

O

OBX Segment with Encapsulated PDF [Optional]

Optionally, observations or additional analyses can be provided in an encapsulated PDF
containing displayable information.
Table 4.12-13 – OBX Segment
ELEMENT NAME

SEQ

COMP

DT

LEN

USAGE

CARD

Set ID - OBX

1

SI

3

R

[1..1]

Value Type

2

ID

2

R

[1..1]

Observation Identifier

3

CE

80

R

[1..1]TBL#

ITEM #

Fixed

00569
0125

00570

Ex. Values
1

Y

ED

00571

Identifier

1

ST

40

R

[1..1]Y

18750-0

Text

2

ST

80

R

[1..1]

Y

CardiacElectrophysiology Report

Name of Coding System

3

ST

12

R

[1..1]

Y

LN

ED

*

RE

[0..1]

Observation Value

5

00573

Encapsulated PDF

Type of Data

2

ST

10

R

[1..1]Y

Application

Data Subtype

3

ST

10

R

[1..1]Y

PDF

Encoding

4

ST

10

R

[1..1]

Y

Base64

Data

5

TX

*

R

[1..1]

Observation Result Status

11

ID

1

R

[1..1]

Date/Time of the
Observation

14

DTM

8

RE

[0..1]

Encapsulated andBase64 binary encoded
PDF File
0085

00579
00582

Y

F
20060317170000+0006__________________________________________________________________________
56
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________ELEMENT NAME
Observation Method

SEQ

COMP

17

DT

LEN

USAGE

CARD

TBL#

CE

ITEM #Fixed

Ex. Values

00936

Identifier

1

ST

20

R

[1..1]

MDC_IDC_SESSION_T
YPE

Text

2

ST

40

R

[1..1]In Clinic

Name of Coding System

3

ST

12

R

[1..1]IEEE P10731.1.3

ST

50

RE

[1..*]

Equipment Instance
Identifier

18

01479

Programmer XXXX

OBX-3 is report ID from LOINC coding system, and shall be set to 18750-0^Cardiac
Electrophysiology Report^LN.

OBX-5.2 Type of Data component shall have the value “Application”
OBX-5.3 Data Subtype component shall have the value “PDF”.
OBX-5.4 Encoding component shall have the value “Base64”.
OBX-5.5 Data component contains the encapsulated Base64-encoded PDF document.
Note! The base64 encoded PDF stream must not include CR/LF characters, which are
forbidden within HL7 field text streams. Breaking a base64 encoded stream into lines of 76
characters or less is used for email in accordance with RFC 822, but is not applicable toencapsulated data in HL7.
OBX-17.1-3 Observation Method, Identifier, Text & Name of Coding system – values will be
coded using the IEEE P10731.1.3 IDC Nomenclature, MDC_IDC_SESSION_TYPE term.
OBX-18 Equipment Instance Identifier – A unique identifier for the equipment or software thatwas responsible for the production of the observation.
The attached PDF shall contain in its content the device ID, patient ID and name if known, andthe dates of the procedure and document.
Note: If the PDF content is electrocardiogram see the CARD-6 Retrieve ECG Document for
Display for recommendations on the message semantics of an ECG document. The limitationsof an ECG collected by an IDC may make some of those recommendations inappropriate.
4.12.5.2.7

OBR Segments – Pulse Generator and Lead Observation Results

The ORU message may include discrete OBX segments for individual observations also reported
in the XML payload. An OBR Segment shall be used for each set of such OBX segments toestablish the equipment context for the observations (i.e., whether they apply to the pulse
generator, or to a specific lead).
The OBR segment shall be formatted in accordance with Section 4.12.5.2.4, with the additional
constraints specified in this section.
__________________________________________________________________________
57
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
OBR-20 Filler Field 1 shall be used for device context. This field must be present. It shallcontain the concatenated model-serial number of the Implanted Cardiac Device, Lead, or otherdevice component (“model:xyz/serial:123”) that is being reported on and will be coded using theIEEE P10731.1.3 IDC Nomenclature, MDC_IDC_DEVICE_MODEL, MDC_IDC_DEVICE_SERIAL_NUMBER terms.
4.12.5.2.8

OBX Segments – Pulse Generator and Lead Observation Results

Discrete OBX segments for individual observations also reported in the XML payload may be
encoded into separate OBX segments as individual observations or measurements. These OBX
segments shall be preceded by an appropriate OBR segment (see 4.12.5.2.7) to set the context for
observations dealing with the implantable devices or leads.
Table 4.12-14 – OBX Segment
ELEMENT NAME

SEQ

COMP

DT

LEN

USAGE

CARD

Set ID - OBX

1

SI

4

R

[1..1]

Value Type

2

ID

2

R

[1..1]

Observation Identifier

3

CE

250

R

[1..1]

TBL#

0125

ITEM #Fixed

Ex. Values

00569

1

00570

DTM

00571

Identifier

1

ST

80

R

[1..1]

MDC_IDC_DEVICE_IM
PLANT_DATE

Text

2

ST

256

R

[1..1]The implant date of thedeviceName of Coding System

3

ST

20

R

[1..1]IEEE P10731.1.3

20

C[1..1]

00572

3.1

00573

20060317

Observation Sub-ID

4

ST

Observation Value

5varies *RE[0..1]

Units

6

CE

250

RE

[0..1]

Observation Result Status 11

ID

1

R

[1..1]

0085 00579

Date/Time of the
Observation

14

TS

26

RE

[0..1]

00582

Observation Method

17

CE

250

Y

F
20060317170000+0006

00936

Identifier

1

ST

80

R

[1..1]

MDC_IDC_SESSION_
TYPE

Text

2

ST

256

R

[1..1]In Clinic

Name of Coding System

3

ST

20

R

[1..1]IEEE P10731.1.3

EI

256

O

[0..*]

Equipment Instance
Identifier

18

01479

Programmer XXXX

OBX-2 Value Type – The HL7 data type of the Observation Value will depend on the IEEEP10731.1.3 term data type, as shown in Table 4.12-15.

__________________________________________________________________________
58
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
Table 4.12-15 – HL7 to IEEE Data Type Matching
HL7 v2 data type
ST
CWE
DTM
NM
ST

Applicable IEEE 1073 types
String, not enumerated
String, enumerated values
Date / Time
Number(x,y), Number(x,0), Number(x)Complex – For complex data types multiple observation values may
be provided. One for each discrete data element and one for the
combined. For combined elements that HL7 type shall be ST.

OBX-3.1 Observation Identifier, Identifier – Must be coded with the IEEE P10731.1.3 IDC
Nomenclature Reference ID field for associated observation.
OBX-3.2 Observation Identifier, Text – Must be coded with the IEEE P10731.1.3 IDC
Nomenclature Common Name field for associated observation.
OBX-4 Observation Sub-ID – Used to organize hierarchical relationships within sets ofobservations or composite (complex data type) observations. Use a dot notation to represent
hierarchical relationships.
OBX-5 Observation Value – This is the actual value of the observation.
OBX-6 Unit – Must be coded with the IEEE P10731.1.3 IDC Nomenclature Unit field for
associated observation.
OBX-17.1-3 Observation Method, Identifier, Text & Name of Coding system – These values
will be coded using the IEEE P10731.1.3 IDC Nomenclature, MDC_IDC_SESSION_TYPE
term.
OBX-18 Equipment Instance Identifier – A unique identifier for the equipment or software thatwas responsible for the production of the observation

4.12.5.2.9

NTE Segment – Notes and Comments [Optional]
Table 4.12-16 – NTE Segment – Notes and Comments

ELEMENT NAME

SEQ

COMP

DT

LEN

USAGE

CARD

TBL#

ITEM #

Set ID - NTE

1

SI

4

O

[1..1]

00096

Source of comment

2

CX

20

O

[1..1]

00097

Comment

3

FT

65536

O

[1..*]

01318

Fixed

Ex. Values

Y

L

1

NTE-3 Comments – Contains any notes, comments needed that are not included as part of anobservation.

__________________________________________________________________________
59
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
4.12.5.3 Expected Actions
4.12.5.3.1

HL7 Message Router

The HL7 Message Router shall return the standard HL7 acknowledgement message to theObservation Creator actor.
Upon receipt of this message, the HL7 Message Router shall reconcile the Patient ID in themessage with the Patient ID of the assigning authority domain of the local institution, using the
PIX Profile transactions. It shall update the PID-3 and PID-5 fields to reflect the local institution
Patient ID and name. The HL7 Message Router shall not otherwise modify the content of theobservation report it receives. After performing this update the HL7 Message Router shall routethe message to all configured recipients. Recipients include Observation Processor and/or
Observation Repository actors.

4.12.6 Observation Forwarding
4.12.6.1 Trigger Events
The HL7 Message Router initiates the HL7 ORU message to the configured Observation
Processor and Observation Repository recipients when it has received the message from theObservation Creator.
4.12.6.2 Message Semantics
The message semantics are identical to the HL7 ORU message used in Observation Submission(see 4.12.5.2).
4.12.6.3 Expected Actions
4.12.6.3.1

Observation Processor

The Observation Processor actor shall return the standard HL7 acknowledgement message to theObservation Creator or the HL7 Message Router actor.
Upon receipt of this message, if the Patient ID has not been reconciled with the local assigningauthority, the Observation Processor shall reconcile the Patient ID in the message with thePatient ID of the assigning authority domain of the local institution. If the Observation Processor
supports the PIX-based Reconciliation Option, it shall use the PIX Profile transactions (PIX ITI9) to perform the reconciliation.
The Observation Processor will perform additional actions that are specific to that application.
Reference section 4.12.2 for a description of the types of actions this actor may support.

__________________________________________________________________________
60
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
4.12.6.3.2

Observation Repository

The Observation Repository actor shall return the standard HL7 acknowledgement message to
the Observation Creator or HL7 Message Router actors.
Upon receipt of this message, if the Patient ID has not been reconciled with the local assigningauthority, the Observation Repository shall reconcile the Patient ID in the message with thePatient ID of the assigning authority domain of the Observation Repository using the PIX Profiletransactions (PIX ITI-9).
The Observation Repository shall store the received data and make it available through meansthat are specific to that application. Reference section 4.12.2 for a description of the types ofactions this actor may support.
The demographic data in the stored data is updated by means of the Patient Demographics
Consumer actor grouped with the Observation Repository actor (PAM Profile transaction ITI30). Any such updates shall be applied to data made available by this application.

__________________________________________________________________________
61
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

Appendix Z – IDCO Observation Message Examples
HL7 v2.5 message and v3 XML data payload examples are available in the IDCO SDK
published at http://www.ihe.net/Technical_Framework/index.cfm#cardiology.

__________________________________________________________________________
62
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

Appendix A – IEEE 1073.1.1.3 ICD Terms nomenclatureThis nomenclature terms are provided in machine parse-able XML document. This appendix
provides the XML schema of the nomenclature.

All four observation groups have base type ObservationItem__________________________________________________________________________
63
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________

Usage of Discriminators
The nomenclature uses discriminators that provide suffixes to the base term. The discriminators
are defined by following:__________________________________________________________________________
64
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNAIHE Technical Framework Supplement - Implantable Device Cardiac Observations______________________________________________________________________________
If the ObservationItem has discriminator specified, multiple terms are derived based on thediscriminator table. The DSuffix is concatenated to the base reference ID for each Discrim
element of the specified discriminator.

XML Schema
The nomenclature schema and XML specification are available as part of SDK at fromhttp://www.ihe.net/Technical_Framework/index.cfm#cardiology.

__________________________________________________________________________
65
Rev. 06 Trial Implementation - 2006-06-08

Copyright © 2006: ACC/HIMSS/RSNA