ACC, HIMSS and RSNA

Integrating the Healthcare Enterprise

IHE Cardiology

10

Cardiology Data Handling

White Paper
June 8, 2007

15

Rev 2.04

Cardiology Data Handling White Paper

2007-06-08

Introduction
20

25

The purpose of this white paper is to present background information to assist with
understanding the requirements and potential solutions for improving methods for the gathering
and collating medical information for supporting Clinical Documentation Systems for
Cardiology. This white paper is a step toward publishing of a cross-domain IHE data handling
approach in the 2008-2009 timeframe. Originally, this document took the form of a Profile
Proposal from the IHE-Cardiology Planning Committee. It then became apparent that the
Query for Existing Data (QED) profile from the Patient Care Coordination Committee would
meet many of the requirements (see http://wiki.ihe.net/index.php?title=Query_for_Existing_Data).
This document has undergone a major revision to detail the data-handling requirements for
Cardiology, including use cases and the known relationship(s) with the QED Profile.

30

Comments on this document may be submitted to:

http://forums.rsna.org under the IHE - Integrating the Healthcare
Enterprise forum
35

Select the Cardiology Technical Framework Supplements 2007-2008 for Trial

Implementation sub-forum.
Topics of Particular Interest for Feedback
1. Five data-handling activities are described in the first section (below). Is this list
complete? Correct?

40

45

50

2. The ability to specify the Definitions and Authorities is essential to assure data integrity
and accuracy when exchanging clinical information among disparate systems (see the
discussion in the Concepts, Definitions and Authorities section, and in Recommendation
#3). How might this best be accomplished?
3. Clinical Documentation Systems are faced with determining and preserving the clinical
context of an observation. There are pre-coordinated and post-coordinated approaches to
this problem (see the discussion in the Concepts, Definitions and Authorities section, and
also Recommendation #4). What approaches should be taken to address this issue?
4. Given the types of data-handling activities described and the use cases that we need to
address, is the Query for Existing Data (QED) Profile the correct way to address the
integration task?
5. Recommendation #2 calls for extending QEDs Problem List and Allergy Profile to
include a list of diagnoses and procedures performed. What problems, if any, can be
anticipated in trying to implement these extensions?

55

6. The ability for a Clinical Documentation System to also function as an Information

Source is potentially very powerful (see Recommendation #1). How might this be
accomplished? Should this be done only by letting there be Query for an Evidence
Page 2
Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

2007-06-08

Document? Should it be possible to Query inside of an Evidence Document for one or

more of its elements? How important is it to handle the clinical context in which the
observation was made?
60

65

7. The Data Correction activity that is described has the potential to greatly improve the
accuracy and integrity of medical data if automated means to assist the process are
developed. How important is this to accomplish? Since the data-handling activities
described may occur concurrently within a Clinical Documentation environment, do we
need to determine when these activities are mutually exclusive, chronologically
sequential, asynchronous, iterative, etc?

Page 3
Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

2007-06-08

Data-Handling Activities in Cardiology

There are several distinct data-related activities that are carried out by a typical Cardiology
Clinical Documentation System. While these will be discussed separately, they typically coexist to a greater or lesser extent within a single application. These include:
70

75

80

1. Initial Manual Data Collection: This refers to applications that assist with the initial
collection of targeted and specifically-defined data about the patient. The data could be
collected by any one of a variety of methods, including (but not limited to) interview,
filling out forms (paper or electronic), through the performance of laboratory tests,
imaging studies, or physician interpretation of any of these. A typical computer
application for Data Collection has a Graphical User Interface (GUI) that allows the entry
of information about the patients history, physical examination findings, lab data,
physiologic parameters, etc. Most vendors have proprietary software to accomplish this
task, sometimes supplemented with interfaces to handle the import of evidence
documents from a modality (for example, echocardiographic measurements via DICOM
SR). This aspect of data collection is also addressed by the IHE Retrieve Form for Data
Capture profile (RFD), as described in the Introduction of the RFD Technical Framework
Supplement:
The Retrieve Form for Data-capture Profile (RFD) provides a method for
gathering data within a users current application to meet the
requirements of an external system. RFD supports the retrieval of forms
from a form source, display and completion of a form, and return of
instance data from the display application to the source application.

85

90

95

100

105

2. Query for Existing Data: This refers to the process of performing a query/retrieve
operation for information that already exists electronically in the enterprise for the
purpose of incorporating that information into a clinical document. In the current
standards and implementations, the data communication has existed largely as a push
model. That is, a Data Source might make its information available as an Evidence
Document (DICOM-SR, HL/7 CDA document, etc.) While this model works well for
discrete well-circumscribed sets of data (for example measurements from an echo cart, or
QCA/QVA analysis system), it is not practical when confronted with the massive
amounts and variety of information that might be stored in an Electronic Health Record
(EHR). Standardized methods for querying or pulling information have thus far been
sparsely defined and rarely implemented, and lack sufficient mechanisms to incorporate
the necessary data definitions and vocabularies. The Query for Existing Data (QED)
Profile from the Patient Care Coordination domain can meet many of these requirements.
3. Review of Imported Data: Presenting data that is about to be imported into a data set is
a commonly-implemented step in clinical workflow. This gives the clinician the
opportunity to select one or more values from among multiple values (if present), resolve
any conflicts that may appear with existing data and review decisions that may have been
made by the import function of the Clinical Documentation System. This review step can
be applied to data from either step #1 (for example, evidence documents) or step #2

Page 4
Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

2007-06-08

above. This activity is most likely to be a feature of a clinical application, and is not
likely to require being addressed by an IHE Profile.
110

115

4. Data Correction: This is a complex topic that is presented only briefly here. After data
is gathered from potentially several different sources, the connection to the data source is
typically lost. That is, no record is kept of the connection between the data source and
data consumer. There may be an opportunity to improve data accuracy and integrity if
this connection was preserved, keeping track of the source of the data and documents. If
these sources are associated with a long-term archive, there is potential for bidirectional data correction and updating to occur:
a. The original source of the data may get corrected or updated information, in
which case it may be desirable to make the updates available to any system that
has accessed the information. This could be implemented either as a push from
the original data source (announcing the availability of the updated information),
or as a pull from the consuming system. In this second case, the consuming
system would not know ahead of time that there updates existed, but could do a
final double-check of any data it has imported before finalizing a data set.

120

b. The data my be created, updated or corrected in the Clinical Documentation

system, in which case the originated data source may be interested to learn of the
update.

125

130

135

5. Data Submission: This refers to the process of packaging and transmitting data to a
registry. This might be done using web pages to enter and submit the data, or using
specialized software that collects the information, checks it for suitability, and then
prepares it for submission to the registry. Data submissions can be done on a patient-bypatient basis, or might be done in a batch mode on a periodic basis. Data Submission
approaches vary based on the needs of the recipient organization. Since the requirements
are well-defined and there are few clinical pain points in this aspect of data handling,
Data Submission will not be addressed further in this document. Standardization of this
process may prove useful to address with a new profile from the IHE Quality Domain to
simplify the creating of new registries, and/or the maintenance of existing ones.

Use Cases

140

145

So what is the pain point we have been asked to address by the IHE-Cardiology Planning
Committee? It is to provide methods to assist with the retrieval of data that already exists
electronically, and to permit its collation and integration into information workflows. The two
most common Cardiology use cases in this regard are described below. These use cases do not
fully reflect all of the data handling activities described above, but rather, they have been
selected as they directly address the charge provided by the IHE-Cardiology Planning
Committee:
1. The incorporation of data into clinical documentation systems: A patient is scheduled
for cardiac catheterization (either elective or emergent), and the process of creating the
report of the procedure is begun (cath report). In many cases this starts before the
procedure begins, other times not until afterward. While there are as yet no published
Page 5
Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

150

2007-06-08

guidelines from professional societies to detail the components that should go into a cath
report, one that is generally accepted as important is to document the review of factors
that relate to the risk of the administration of contrast media. These risks include:
a. Non-modifiable risks: older age, diabetes mellitus, pre-existing renal failure,
advanced congestive heart failure, low ejection fraction, acute myocardial
infarction, cardiogenic shock and renal transplant
b. Modifiable risks: volume of contrast media, hypotension, anemia and blood loss,
dehydration, low serum albumin level (<35 g/l), ACE inhibitors, diuretics, nonsteroidal anti-inflammatory drugs, nephrotoxic antibiotics, intra-aortic balloon
pump, and metformin administration

155

160

165

Note that while many of these factors exist in electronic form elsewhere in the hospital,
the current practice is to review paper or electronic displays of the data and then type
them back into the clinical documentation system that is creating the cath report. A
system that facilitates this data interchange would impact 100% of the cath reports
produced electronically, improving the quality of care and of the documentation, and
reducing medical risk to the patient and legal liability of the physician.
Here is how these data elements can to be addressed (or possibly not addressed) by QED
and related profiles:
a. Age: from Patient Demographics Query (PDQ)
b. Diagnosis of diabetes mellitus, renal failure, congestive heart failure, acute MI,
cardiogenic shock, renal transplantation, dehydration, blood loss: This could be
done via QED/Query Problems and Allergies if this were expanded to handle
coded procedures and diagnoses (see Recommendation #2).

170

c. Ejection Fraction: Not handled by current profiles unless the Ejection Fraction
analysis was done by a Quantitative Ventricular Analysis (QVA) system that
created an evidence document (DICOM-SR). Information from an ejection
fraction from another source (nuclear study, echocardiogram, etc.) would not be
available to be queried. Consideration should be given to having a clinical
documentation system behave like a lab system, and be able to be queried via
QED/Query Lab Results for something like this (see Recommendation #1).

175

d. Volume of contrast media administered: Not available as information that can be

queried by current profiles. This information is not available until the end of the
cath study)

180

e. Hypotension: QED/Query Vital Signs

f. Anemia, low serum albumin, BUN, creatinine: QED/Query Lab Results
g. Medications include ACE inhibitors, diuretics, non-steroidal anti-inflammatory
drugs, nephrotoxic antibiotics, metformin: QED/Query Medications
h. Use of the intra-aortic balloon pump: Not available as information that can be
queried by current profiles.

185

Page 6
Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

190

195

2. Data Registries: The task of collecting data for national registries, clinical trials and
other related research activities is overwhelming for most hospitals. These activities are
important not only to advance our clinical knowledge, but also directly impact a
hospitals ability to provide the necessary documentation for pay-for-performance
scenarios. In many states in the U.S., and in several other countries, participation in data
registries is a requirement for cardiac catheterization laboratories. As with the use case
for clinical documentation systems (above), it would be very helpful to improve the
ability of computer systems to assist in this process. During the interaction with the
software that is collecting and collating data for submission to the data registry, and
physician or nurse would ask for all pertinent data from other clinical systems to be
collected and presented on screen for review. Upon review, the appropriate data can be
confirmed and imported into the data registry for that patient. This is a good fit with the
QED profile intent.

Analysis of Data Handling Requirements

200

205

210

2007-06-08

In order to help discover the kind of data handling challenges that might araise, a complete
analysis of the entire set of data elements for the American College of Cardiologys National
Cardiovascular Data Registry (NCDR) was done (see Appendix C). This data set was selected
to be used as an example to show the kind of information that needs to be gathered and collated
by a Clinical Documentation System (Data Client). The data elements in the NCDR are
similar to those encountered in other Cardiology registries such as the European Society of
Cardiologys Cardiology Audit and Registration Data Standards (CARDS), the French
National Registry of Acute Coronary Syndromes, the National Cardiac Databases for Australia,
etc. From the analysis, several challenges for data handling were discovered (see Appendix C
for the full details), including:
1. Candidate data elements to be handled by QED. A query is sent to a data source. The
Data Client is responsible for matching up the timestamp of the lab test with that of the
procedure being document in order to provide the necessary context to the data elements.

215

220

225

2. Information that cannot be handled using existing profiles due to the need for specific
data definitions. In some cases, the data element could be constructed from its individual
components (see Query example for ST Elevation MI in Appendix B, for example).
These are incompletely handled by the current QED Profile specification, but could be
handled if QED is extended to handle an information source that deals with coded
procedures and diagnoses.
3. Information available through Patient Demographic Query (PDQ).
4. Information that can be obtained from the Patient Care Coordination profiles for PreProcedure History and Physical (PPHP) and/or the Medical Summaries Profiles. The
local application is responsible for matching up timestamps with the procedure being
documented to select the most recent procedures for PCI and CABG, and for CABG this
admission (that is what the NCDR data elements call for). Alternatively, these data
elements could be handled as part of the Data Interchange profile, as the definitions are
reasonably universal.
Page 7
Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

230

235

2007-06-08

5. Information that might be obtained directly from evidence documents (by querying an
Evidence/Image manager) or easily derived from the information in the evidence
document. The local application is responsible to assure that the data being returned
matches the procedure being reported on. These might be handled by QED/Query for
Lab Data if the scope of Lab is extended.
6. Information that is specific to the local application, and not handled by using Data
Interchange to collect the information from other Data Sources. In many cases, however,
the information may be interesting to other Data Clients (that is, might be necessary to
make it available to a query response).

Concepts, Definitions and Authorities

240

245

250

255

260

265

Current medical information standards do not provide a mechanism for specifying the definition
used for a term. Such a capability is vital for the proper interpretation of information that is
exchanged among disparate systems. The classic example in Cardiology is Unstable Angina.
While this concept has a unique SNOMED identifier (4557003), there are a large number of
definitions that have been used for this concept over the years. It is often helpful to know, not
only that the patient had unstable angina, but also to know the definition that was used to make
that determination. A formal way of specifying this concept modifier is needed.
Here is another simple example of the importance of definitions to assure data accuracy and
integrity. A hemodynamics system may provide a way to entering data about the patients
history. A data element, for example, might specify if the patient is a Cigarette Smoker (YES or
NO). But the data registry that is ultimately to receive this information has a different set of
choices for Cigarette Smoker: YES, NO, or FORMER. A NO value selected from the choices
YES or NO has a very different meaning than a NO value selected from YES, NO, or
FORMER. It is very important to be able to qualify the Cigarette Smoker concept with its
definition (either the list of choices from which the answer is selected, or the Authority that
created the definition, for example, NCDR).
It should be possible to address pre-coordinated terms (fully qualified concepts, information
model, etc.) as well as terms that exist inside of a clinical context (post-coordinated).
Clinical laboratory systems typically return a numeric value corresponding to the result of the
test that was performed, for example, a serum creatinine level. This lab result is identified with a
date-time stamp in a Hospital Information System reflecting the time that the sample was
collected. A Clinical Documentation System might extend it further with information about the
clinical context associated with the value (in the creatinine example, it might be identified as the
last creatinine value obtained before the cardiac catheterization).
A pre-coordinated term could be created that fully reflects the concept of The Last Creatinine
Obtained Before the Cardiac Catheterization. While this eases the burden to the Clinical
Documentation System of interpreting the significance of the value, the list of such terms
obviously expands rapidly and is not likely to be practical. A post-coordinated approach
provides some structure to the information, so that the clinical context in which the observation
was made is defined. This is highly flexible, but does impose some degree of a burden on a
clinical system that might have to traverse the branches of an information model to figure it out.

Page 8
Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

270

275

Another example may help to clarify this further. There are SNOMED terms that define (in
increasing level of specificity) Intracardiac Pressure (165077006), Ventricular Pressure
(251069003), Left Ventricular Pressure (276769008), and Left Ventricular End-Diastolic
Pressure (LVEDP, 276781007). These might be considered pre-coordinated terms in that very
high levels of detail can be specified based on the identifier used. Clinically, however, it is often
desirable to describe the LVEDP at baseline and again after the performance of the left
ventriculogram. This is a clinical context that does not currently have a pre-coordinated term
that fully describes it. One approach would be to add baseline and post-contrast descendants
to LVEDP and create unique SNOMED identifiers for them. The alternative is to provide a postcoordination mechanism to describe the clinical context (baseline and post-contrast) for the
LVEDP observations.

Recommendations

280

285

290

2007-06-08

1. A formalization should be established for an approach that treats a Clinical

Documentation System like a lab system with regards to being an Information Source?
In this manner, it could be an actor to respond to a QED/Query for Lab Data (for
example, to respond with an Ejection Fraction). This would be a major expansion in the
scope of Lab information, extending beyond clinical chemistries and to now include
any clinical laboratory (whoever the results are obtained).
2. QED Problem List & Allergies profile should be expanded to include diagnoses and
procedures (for example, to gather a list of procedures performed, such as PCIs and
CABGs). What coding scheme should be used for this? Again, a simple concept that
would be a powerful extension of the QED approach.
3. A mechanism needs to be established to better handle concept definitions (like Unstable
Angina) so that it could take into account the definition used for the data element (see
the discussion in this white paper on Concepts, Definitions and Authorities).

295

4. A consistent approach for the use of pre-coordinated and post-coordinated terms

should be established.

Page 9
Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

2007-06-08

Appendix A: Different Levels of Data Complexity

It is instructive to look at some of the information that might be of interest to a Data Client, and
the queries needed to retrieve the information from Data Sources. For this discussion, several
levels of query complexity can be derived:
300

305

Simple: Queries for lab results. The response includes units, value, and DATETIME of
collection. Examples: BUN, creatinine, hemoglobin, hematocrit

Definition-Based: Need to specify the desired aspects of the data element definition.
Response includes DATETIME of the finding as well as its value. Examples: ST
Elevation MI, Unstable Angina.

Intermediate: All of Simple, plus the need to specify the normal range or diagnostic
limit for the lab (and possibly the specific specimen). Example: cardiac enzymes (CK,
troponin, etc.)

Derived: A data value derived from two or more other data elements. Example: Body
Surface Area (BSA). Actually, the Data Source may have this value already available
for a Simple Query, or alternatively, the Data Client could request Patient Height and
Patient Weight and compute the BSA from that. In the case that the Data Source has a
BSA value available directly, it might optionally say how it was derived (there are
several possible formulas that could be used to derive BSA from Height and Weight). In
this case there are elements of Definition-Based queries/responses that could be used.

Complex: There are, of course, all levels of Complex Queries that could be needed.
One straight-forward example can illustrate the concept, though, and that is Ejection
Fraction from Any Source. What is needed here by the Data Client is an Ejection
Fraction value that could be derived from any one of a number of sources. This is similar
to the Derived example (above), in that a Data Source might provide an Ejection Fraction
response directly (because it either had the value already stored and responded as a Nave
Data Source, or it understood an Information Model and put a response together itself
responding as an Intelligent Data Source).. Alternatively, the Data Client might query for
many simple Ejection Fraction (EF) values (EF determined by echocardiography, EF
determined by ventriculography, EF determined radionuclide angiography, etc.) and
apply the logic itself to derive the Ejection Fraction from Any Source value.

310

315

320

325

Page 10
Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

2007-06-08

Appendix B: Sample Data Derivations

Last Creatinine
The Data Client would like to know the last creatinine prior to day of the cath procedure
(NCDR.3 data element #440)
330

9 Query for all available serum creatinine levels (TIMEDATE of the result along with the
actual lab value should be returned).
9 Combine the responses to this query with information about the procedure date and make
a determination if the data meets the data element definitions

335

9 Present the information for human review before allowing the data element to be
populated with this information
Derived Findings: STEMI and non-STEMI
This logic shows how to determine if the patient had a STEMI or non-STEMI
9 Query for the raw data that is used to make the diagnosis of STEMI or non-STEMI
(EKG findings, biochemical markers)

340

9 Combine the responses to this query and determine which definition(s) are met by the
data
9 Present the information for human review before allowing the data element to be
populated with this information
Prior Myocardial Infarction (MI)

345

The Data Client would like to know if the patient has had a prior MI (more than 7 days before
this admission; NCDR.3 data element #420)
9 Query directly for STEMI or non-STEMI (the date of the diagnoses should be returned)
9 Alternative: Attempt to make the diagnosis using the STEMI and non-STEMI as per the
STEMI logic example above

350

9 Combine the responses this query with the admission date and make a determination if
the data meets the data element definitions
9 As always, present the information for human review before allowing the data element to
be populated with this information

Page 11
Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

2007-06-08

Appendix C: Analysis of NCDR 3.0 Data Elements

355

The section shows a comprehensive analysis of all of the current data elements in NCDR 3.0,
and how they could be handling could be facilitated by a Data Interchange approach. The
NCDR was chosen to serve as a prototype, as the types of data elements gathered are typical of
those in many other international registries of clinical problems in Cardiology.
1. Laboratory data to be handled by QED:
439
440
1112
1113
1114
1115
1116
1117
1118
1119
1120
1122

360

Creatinine Assessed on Admission

Last Creatinine
CK-MB Pre-Procedure Baseline Assessed
CK-MB Pre-Procedure Baseline
CK-MB Post-Procedure Peak Assessed
CK-MB Post-Procedure Peak
Troponin - Pre-Procedure Baseline Assessed
Troponin - Pre-Procedure Baseline
Troponin - Post-Procedure Peak Assessed
Troponin - Post-Procedure Peak
Post Procedure Creatinine Assessed
Post Procedure Creatinine Level

2. Non-lab data to be handled by Data Interchange:

454
420
424
442
444
450
452
456
460
470
480
500

Chronic Lung Disease

Previous MI (>7 Days)
CHF - Previous History
Renal Failure
Renal Failure Dialysis (to distinguish other
indications for the patient having undergone dialysis)
Cerebrovascular Disease
Peripheral Vascular Disease
Hypertension
History of Tobacco Use
Dyslipidemia
Family History of CAD age <55
CHF - Current Status

3. Information available through Patient Demographic Query (PDQ):

210
220
230
240
250
252
260

Patient First Name

Patient M.I.
Patient Last Name
Patient Social Security Number
Patient DOB
Patient Age (derivable from #250)
Gender (??)
Page 12

Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

270
1156

2007-06-08

Race/Ethnicity (??)
Date of Death

4. Information that can be obtained from the Patient Care Coordination profiles:
410
412
426
428
430
490
492
494
496
510
520
530
540
550
560
1100
1102

Height (cm)
Weight (kg) (should be from a recent point in time)
Previous Valvular Surgery
Cardiac Transplant
Diabetes
Previous PCI
Previous PCI - Date
Previous CABG
Previous CABG - Date
NYHA
Cardiogenic Shock
Non-Invasive Test
Non-Invasive Test - Outcome
Admission Sx Presentation
Time Period: Sx Onset to Admission
CABG During This Admission - Status
CABG During This Admission - Date

5. Information that might be obtained directly from evidence documents:

600
610
612
614
632
650
652
654
656
658
660
661
662
663
664
665
666
667
668
669
670

Date of Procedure
Right Heart Cath Procedure
Left Heart Cath Procedure
PCI Procedure
Fluoroscopy Time
Left Ventricular Function Assessed
Left Ventricular Wall Motion
Ejection Fraction Done
Ejection Fraction Percentage
Ejection Fraction Method
LM Assessed
LM Stenosis Percent
Proximal LAD Assessed
Proximal LAD Stenosis Percent
Mid/Distal LAD Assessed
Mid/Distal LAD Stenosis Percent
CIRC Assessed
CIRC Stenosis Percent
RCA Assessed
RCA Stenosis Percent
Ramus Assessed
Page 13

Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

671
674
675
676
677
678
679
680
681
682
683
740
744
746
750
810
900
902
910
912
920
922
950
952

2007-06-08

Ramus Stenosis Percent

Proximal LAD Graft Assessed
Proximal LAD Graft Stenosis Percent
Mid/Distal LAD Graft Assessed
Mid/Distal LAD Graft Stenosis Percent
CIRC Graft Assessed
CIRC Graft Stenosis Percent
RCA Graft Assessed
RCA Graft Stenosis Percent
Ramus Graft Assessed
Ramus Graft Stenosis Percent
Mitral Valve Disease - Stenosis
Mitral Valve Disease - Insufficiency
Aortic Valve Disease - Stenosis
Aortic Valve Disease - Insufficiency
Coronary Lesion >=50% in a Major Artery
Lesion Counter
Segment Number
Segment Pre-Stenosis Percent
Segment Post-Stenosis Percent
Pre-Procedure TIMI Flow
Post-Procedure TIMI Flow
Lesion Risk
Lesion Length

6. Information that is specific to the local application:

100
110
120
130
140
150
160
170
180
242
310
320
321
330
350
352
360
361

Transmission Number
Participant ID
Participant Name
Timeframe of data submission
Software Vendor's Name Identification
Vendor's software version (name and number)
NCDR Version
Diagnostic Cath - Minimum Data Set
Data Submission File Password
Unique Patient ID
Date of Admission (available from ADT)
Admission Status (available from ADT)
Inpatient Status (available from ADT)
Insurance Payer (available from ADT)
Medication ID (a future profile could obtain from a
Medical Administration Records, MARS)
Medication Administration (see #340 comment)
Reserved 1
Reserved 2
Page 14

Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

362
432
602
634
640
642
695
696
697
698
702
703
704
710
712
714
724
726
728
730
732
802
803
804
812
814
816
818
820
930
932
934
936
938
940
941
942
944
954
960
962
964
965
966
967

2007-06-08

Reserved 3
Diabetes Control
Procedure Counter
Contrast Volume
IABP
IABP Timing
Percutaneous Entry Location
Closure Device Counter
Closure Device
Closure Device - Successful
Catheterization Operator's UPIN
Catheterization Operator's Name
Cardiac Cath Status
Valvular Heart Disease
Arrhythmia
R/O CAD
Positive Stress Test
Other Diagnostic Cath Indications
Other Cardiac Indications
Other Miscellaneous Indications
Transplant Indications
PCI Primary Operator's UPIN
PCI Primary Operator's Name
PCI Status
Acute PCI
Date/Time of Arrival
Reperfusion Date/Time
Transfer for Primary PCI
Date/Time ED Presentation at Referring Facility
Previously Treated Lesion
Previously Treated -Balloon
Previously Treated -Stent
Previously Treated -Radiation
Previously Treated -Other/Unknown Device
Previously Treated -Date Available
Previously Treated Lesion Date
Segment In Graft
Location in Graft
Bifurcation Lesion
Intracoronary Device Counter
Intracoronary Devices Used
Intracoronary Devices Diameter
Intracoronary Device Length
Intracoronary Device Primary Indicator
Intracoronary Devices Barcode
Page 15

Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

970
972
974
976
978
1130
1140
1141
1150
1152
1154
1158
1160
1000
1010
1020
1030
1040
1050
1060
1070
1080
1081
1085
1086
1087
1088
1089
1092
1094
1096
1097
1098
1099

2007-06-08

Transient No Reflow Phenomenon During Procedure

Dissection in Segment
Acute Closure In Segment
Successful Reopening
Perforation in Segment
Blood Products
Smoking Cessation Counseling
Cardiac Rehab Referral
Date of Discharge (also available from ADT)
Discharge Status
Discharge Location
Primary Cause of Death
Death in Lab
Comp-Periprocedural MI
Comp-Cardiogenic Shock
Comp-Congestive Heart Failure
Comp-CVA/Stroke
Comp-Tamponade
Comp-Thrombocytopenia
Comp-Contrast Reaction
Comp-Renal Failure
Comp-Emergency PCI
Comp-Letely Useless Code
Comp-Bleeding - Percutaneous Entry Site
Comp-Bleeding - Retroperitoneal
Comp-Bleeding - Gastrointestinal
Comp-Bleeding - Genital/Urinary
Comp-Bleeding - Other/Unknown
Comp-Vascular - Access Site Occlusion
Comp-Vascular - Peripheral Embolization
Comp-Vascular - Dissection
Comp-Vascular - Pseudoaneurysm
Pseudoaneurysm Treatment
Comp-Vascular - AV Fistula

Page 16
Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

2007-06-08

Appendix D: Sample Definitions

365

The following definitions are taken from the NCDR 3.0 documentation, and are included here
just to provide examples for discussion.
Unstable Angina
370

The patient was hospitalized for unstable angina documented in the medical record with serial
ECGs and biochemical profiles. One of the following criteria are necessary:
1) Angina at rest (usually prolonged >20 minutes).
2) New onset angina (<2 months) exertional angina of at least Canadian Cardiovascular
Society Classification (CCSC) Class III.

375

3) *new per guidelines* Increasing angina - previously diagnosed angina that has become
distinctly more frequent, longer in duration, or lower in threshold (i.e., increased by
greater than or equal to 1 CCS class to at least CCS Class III severity).
ST Elevation Myocardial Infarction (STEMI)
Indicate whether the patient was hospitalized for an ST Elevation Myocardial Infarction
(STEMI) documented in the medical record.

380

At least one of the following biochemical indicators for detecting myocardial necrosis must be
present:
1) Troponin T or I:
a. Maximal concentration of troponin T or I > the MI decision limit on at least one
occasion during the first 24 hours after the index clinical event.

385

2) CK-MB:
a. Maximal value of CK-MB > 2 x the upper limit of normal on one occasion during
the first hours after the index clinical event; or
b. Maximal value of CK-MB, preferable CK-MB mass, > upper limit of normal on
two successive samples.

390

3) Total CK
a. In the absence of availability of a troponin or CK-MB assay, total CK > 2 x the
upper limit of normal, or the B fraction of CK may be employed, but these last
two biomarkers are considerably less satisfactory than CK-MB.
and one of the following ECG changes:

395

400

1) ST-segment elevation: New or presumed new ST segment elevation at the J point in two
or more contiguous leads with the cut-off points >=0.2 mV in leads V1, V2, or V3, or
>=0.1 mV in other leads; OR
2) Development of any Q wave in leads V1 through V3, or the development of a Q-wave >
or = to 30 ms (0.03s) in leads I, II, aVL, aVF, V4, V5, or V6. (Q wave changes must be
present in any two contiguous leads, and be > or = to 1mm in depth.)
Page 17
Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA

Cardiology Data Handling White Paper

2007-06-08

References:
405

1. IT Infrastructure Technical Framework Supplement 2006-2007: Patient Identifier CrossReference (PIX) and Patient Demographic Query (PDQ), Trial Implementation Version,
November 6, 2006.
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Suppl_PIX_PDQ_HL7v3_TI_20
06_11_06.pdf

410

2. IT Infrastructure Technical Framework Supplement 2006-2007: Retrieve Form for Data

Capture (RFD), Trial Implementation Version , September 22, 2006
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Suppl_RFD_TI_2006_09_25.pdf

3. IHE Patient Care Coordination Technical Framework Volumes 1, 2 & 3 Revision 1.0
2005-2006, Final Text, August 11, 2006,
http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_Final_20060812.pdf

415

4. IHE Patient Care Coordination Technical Framework Supplement 2006-2007: Exchange

of Personal Health Record Content (XPHR), Trial Implementation, August 12, 2006
http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_XPHR_Exchanging_PHR_Cont
ent_20060812.pdf

420

5. IHE Patient Care Coordination Technical Framework Supplement 2006-2007, Preprocedure History and Physical (PPHP), Draft for Trial Implementation, August 15, 2006
http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_PPHP_Preprocedure_History_a
nd_Physical_TI_2006_08_15.pdf

6. IHE Patient Care Coordination Technical Framework Volumes 1, 2 & 3 Revision 1.0
2005-2006, Final Text, August 11, 2006
425

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

7. IHE Patient Care Coordination Technical Framework proposal for Query for Existing
Data (QED): http://wiki.ihe.net/index.php?title=Query_for_Existing_Data

Page 18
Rev. 2.04

Copyright 2007: ACC/HIMSS/RSNA