IHE Cardiology Domain Overview Harry Solomon 27-July-2010.

IHE Cardiology

Domain Overview

Harry Solomon27-July-2010

Agenda

• Domain Update• Overview of existing profiles• New profiles

Domain Update

• Cardiology domain was established in 2004• Successful profile development during years 1-4:

• Cath, Echo and Stress Workflows• Retrieval and display of ECGs• Storage and exchange of evidence documents• Displayable reports

• 2008 domain became dormant due to lack of funding

• 2009 domain was re-established with new funding through ACC, ASE, ASNC, HRS

Echo Workflow

• Addresses ordering, scheduling, scheduling, storage and review of echo exams including:– TTE, TEE, Stress exams– Specifically deals with

intermittently connected modality

– Handling of compressed images

Cath Workflow

• Deals with complex cardiac catheterization Workflow:– Unordered /emergency exams– Coordination of imaging,

reporting and hemodynamic data

– Support for multi-modality workflow coordination

– Coordination of diagnostic imaging and interventional procedure information

Stress Testing Workflow

• Provides ordering and collecting multi-modality (ECG and imaging) data during diagnostic cardiac stress testing procedures– Manages ECG and imaging

workflow in an integrated manner

– Both echo and NM imaging

– Adherence to ACC/ASNC NM display requirements

Retrieve ECG for Display

• Access to ECGs from everywhere in the hospital: – Resting ECGs, Holter ECGs– Simplified and standardized

access to ECGs and viewing process

– No need for ‘printed ECGs’

Evidence Documents

• The IHE Radiology Evidence Documents Profile defines the storage, exchange, archive and display of clinical findings such as measurements, observations, and results created by acquisition modalities or workstations.

• IHE Cardiology adds named options for each class of cardiac imaging evidence, with some specific content and display requirements. • Cath• Echo• Stress• CTA/MRA

New Developments

• Displayable Reports profile (major update)– Distributes “display ready” PDF/CDA clinical reports from the reporting

app, to the department, to the enterprise. – 2009-10 update includes CDA format reports, better alignment with HL7

conventions and orders process, clarification of actors for legacy systems– Applicable to other domains

• Image Enabled Office– Address integration of imaging suite into an office EMR environment, to

support expected meaningful use criteria for imaging in 2015– Applicable to other domains

• Resting ECG Workflow– Similar to Scheduled Workflow to address ordering of a resting ECG (“12

lead“) test, performing the test, reporting and storage of the ECG data in a standardized format

More Information

http://www.ihe.net/Events/webinars2010.cfmIHE Webinar series 2010

http://www.ihe.net/Technical_Framework/index.cfmIHE Technical Frameworks and Supplements

New Trial Implementation versions to be released ~ Aug 1

http://wiki.ihe.net/index.php?title=CardiologyInformation on IHE Cardiology development activities

http://www.ihe.net/Events/webinars2010.cfm

http://www.ihe.net/Technical_Framework/index.cfm

http://wiki.ihe.net/index.php?title=Cardiology

Displayable Reports (DRPT)

Profile Overview


Example Displayable Reports

The Problem

• Most existing reporting applications operate with paper paradigm– Print / Scribble (signature) / Fax

• “Advanced” report management has some electronic capabilities– Free-text blob – Storage / database– Electronic signature

• Specialty reporting apps need to go beyond the blob– Inconsistent requirements for how to do this

Displayable Reports Profile Abstract / Scope

• Workflow for creation, signature/release, and distribution

• Management of PDF and CDA formatted clinical reports– Current apps output PDF, evolution to CDA – Both may embed graphics

• Report repository/archive– Archive at one level (nominally the department) required

• May leverage PACS– Additional archive at second level (enterprise) supported

• Web access to repository/registry– Supports additional integration use cases

DRPT Actor / Transaction Diagram

Integrated Report Manager/Repository

Encapsulated Report Storage [CARD-9]

Report Repository

ReportManager

Enterprise Report Repository

Encapsulated Report Query [CARD-10]Encapsulated Report Retrieve [CARD-11]

Report Reader

Report Creator

Encapsulated Report Submission [CARD-7]

Storage Commitment [RAD-10]

®

¯

¯¯

InformationSource

Report Reference Submission [CARD-8]

Display

Procedure Scheduled [RAD-4]Patient Update [RAD-12]Procedure Update [RAD-13]

®

DSS/ Order Filler

Encapsulated Report Submission [CARD-7]Report Reference Submission [CARD-8]

Patient Update [RAD-12]

®

Report Manager System Requirements

• Manage reporting cycle and clinical report repository• HL7v2 inputs (ADT, ORM) for current patients/procedures• HL7v2 input (MDM with encapsulated PDF or CDA) for new

reports• HL7v2 output to Enterprise Repository for signed reports

– MDM with encapsulated document or with reference pointer• Web server interface to clinical report repository (IHE RID)• Optional storage of report copy in DICOM object

– Encapsulated PDF or CDA– Claim conformance as separate “Report Manager” and “Report

Repository”

DRPT Diagram – Separate Report Manager and Report Repository

Encapsulated Report Storage [CARD-9]

Report Repository

ReportManager


Encapsulated Report Query [CARD-10]Encapsulated Report Retrieve [CARD-11]

Report Reader

Report Creator


Storage Commitment [RAD-10]

®

¯

¯¯

InformationSource


Display


®

DSS/ Order Filler


Patient Update [RAD-12]

®

MSH|^~\$|… PID|1|0123456‑1||R… OBR|1|X89‑1501^…OBX|1|ED|11528-7^LN…


HL7MSH|^~\$|… PID|1|0123456‑1||R… OBR|1|X89‑1501^…OBX|1|ED|11528-7^LN…

MSH|^~\$|… PID|1|0123456‑1||R… OBR|1|X89‑1501^…OBX|1|RP|11528-7^LN…

http://serv.hosp.org/app?requestType=DOCUMENT&documentUID=”1.2.3”&preferredContentType=”application/pdf”

HL7


HL7

HTTP

(0008,0005) IR_100(0008,0012) 20061113(0008,0013) 1109(0008,0016) 1.2.8401008.…

DICOM

DRPT Diagram – Integrated Report Manager / Repository

Report Repository

ReportManager


Report Creator


®

¯

InformationSource


Display


DSS/ Order Filler


® Integrated Report Manager/ Repository



HL7MSH|^~\$|… PID|1|0123456‑1||R… OBR|1|X89‑1501^…OBX|1|ED|11528-7^LN…

MSH|^~\$|… PID|1|0123456‑1||R… OBR|1|X89‑1501^…OBX|1|RP|11528-7^LN…

http://serv.hosp.org/app?requestType=DOCUMENT&documentUID=”1.2.3”&preferredContentType=”application/pdf”

HL7


HL7

HTTP

Enterprise Report Repository Requirements• Receive signed reports from department, and make them

available to the enterprise and beyond• HL7v2 input for signed reports from Report Manager

– MDM with encapsulated document or with reference pointer– At discretion of Enterprise Report Repository (Report Manager

configuration time)• If reference pointer option used, Enterprise Report

Repository or its clients can use Web interface to obtain document from departmental report repository (IHE RID)– Allows distributed enterprise storage architecture

New Transactions

•Encapsulated Report Submission [CARD-7] – HL7 MDM^T02 (new) and MDM^T10 (update)– OBX segments (2) with Study Unique ID and with encapsulated report– Report must be PDF or CDA– Additional OBX segments allowed to convey critical observations– Sent from Report Creator to Report Manager, and from Report Manager to

Enterprise Repository

•Report Reference Submission [CARD-8]– HL7 MDM^T01 (new) and MDM^T09 (update)– Identical to CARD-7 but with reference pointer rather than encapsulated

report– Reference pointer is RID Retrieve Document for Display [ITI-12] URL– Sent from Report Manager to Enterprise Repository and to DSS/OF

New Transactions

•Encapsulated Report Storage [CARD-9] – DICOM Encapsulated PDF or Encapsulated CDA

•Encapsulated Report Query [CARD-10]– DICOM query keys specified for encapsulated document objects

DRPT Relationship to XDS, PDI

• DRPT deals with internal workflow for creation and sign-off of reports, XDS with external sharing of reports

• DRPT actors may be XDS Document Source or Document Repository– Report Manager / Report Repository– Integrated Report Manager Repository– Enterprise Report Repository

• DRPT managed PDF can be wrapped with CDA header as defined by XDS-SD

• Report encapsulated in DICOM object easily exportable to media in PDI with rest of imaging study data

Image enabled Office (IEO)

Profile Overview


Image Enabled Office Problem Statement

• Increasing number of clinical offices with both imaging equipment and electronic medical records – Lower cost imaging systems (e.g., portable ultrasound)– Deployment and meaningful use of EMRs is an explicit goal of the U.S.

government

• Imaging equipment needs to be integrated into the office environment workflow

• Imaging results need to be integrated into the EMR• Systems in an office environment must be more seamlessly

integrated than in an in-patient environment– Less IT-savvy staff

Image-Enabled Office (IEO) Profile Scope• Integration of an imaging suite (modalities, storage server, and

workstations) with an electronic health record system in an ambulatory office setting

• Fully bi-directional integration, including ordering/scheduling of an imaging exam, status reporting for that exam, report creation, and web-based imaging exam review integration

Out of Scope:• Exchange with other entities (supported by PDI, XDS and XDS-I

functionality)• Specialized content (supported by specialized workflow and

content profiles)

IEO Design Principles

• Leverage existing imaging workflow and equipment• Image Manager/Archive should be separate from EHR-S• Modalities and image workstations should operate with no

changes from Scheduled Workflow– Modality worklist, MPPS, image/evidence storage– Specialty reporting apps

• Simple EHR-S integration to imaging workflow management – Loose: emulation of ADT/CPOE with standard HL7 I/F to separate

manager actor (DSS/OF)– Tight: built-in or bolted-on Broker / Interface Engine

• Web-based integration between EHR-S and Image Manager– Web service invocation a la ITI Retrieve Info for Display

EHR-S

IEO Actor / Transaction Diagram

Acquisition Modality

Query Images Evidence […]Retrieve Images/Evidence [CARD-4] Image

Display

Modality Images /Evidence Stored [CARD-2]

Query Modality Worklist [RAD-5]

Procedure Step in Progress […] Procedure Step Completed […]

Report Creator


Procedure Scheduled [RAD-4]

Procedure Updated [RAD-13] Outpatient Update [CARD-16]

Notify Study Access [CARD-14]

Evidence Creator

Invoke Image Display Service [CARD-15]

Storage Commitment [CARD-3]

Integrated EHR-S

Image Manager / Image Archive

Patient Registration [RAD-1]

Outpatient Update [CARD-16] Placer Order Management [RAD-2]

Information Source

Display

® Encapsulated Report Storage [CARD-9]

DSS / OF PPSManager

Filler Order Management [RAD-3]

Electronic Health Record System (EHR-S) Requirements• Manage patient demographics, imaging orders, and clinical

data repository• HL7v2 outputs (ADT, ORM) and inputs (ORU, MDM)• Web server interface to clinical data repository (IHE RID)• Web client interface for imaging data display• DICOM workflow interface (MWL, MPPS)

– Loosely coupled via HL7 to workflow manager (DSS/OF) or– Proprietary coupling to broker / interface engine

• Claim conformance as “Integrated EHR-S”• Optional storage of imaging report copy in DICOM object

– Encapsulated PDF or CDA• No restriction on deployment model (on- or off-site)

Image Manager / Archive (PACS) Requirements• Manage imaging repository• HL7v2 inputs (ADT, ORM) and output (ORU)• Web server interface for imaging data display• DICOM workflow interface (MPPS SCP)• No restriction on deployment model (on- or off-site)

Report Creator (image analysis app) Requirements• Grouped with Acquisition Modality or Image Display • Create report as HL7 CDA or as PDF sent in HL7v2 output

(MDM)– [CARD-7] Transaction from DRPT Profile– May have additional OBX’s with significant measurements

• Optional Web client interface to EHR-S repository (IHE RID)

New Transactions

•Notify Study Access [CARD-14]– Image Manager/Archive to EHR-S– HL7 ORU^R01– Trigger Event – availability of study images at Image Manager– OBX segments (2) with Study Unique ID and with display service URL

•Invoke Image Display Service [CARD-15]– EHR-S to Image Manager/Archive– Web service over HTTP– Invokes navigation / viewing study in standard web browser

•Outpatient Update [CARD-16]– Similar to Patient Update [RAD-12], only 2 outpatient-related trigger events– HL7 ADT^A08 and A40

Invoke Image Display Service [CARD-15]

• Access based on Study UID or Patient ID• Follows model of IHE ITI Retrieve Info for Display

web services– http://<location>/IHERetrieveDICOMInfo?requestType=STUDY

&studyUID=<studyUID>– http://<location>/IHERetrieveDICOMInfo?

requestType=SUMMARY&patientID=<patientID_HL7v2CX>&lowerDateTime=<LDT>&upperDateTime=<UDT>&mostRecentResults=<num>

• Image Manager responds with web-based display application– Any necessary plug-in downloadable from Image Mgr

IEO Relationship to XDS-I and PDI

• IEO deals with internal workflow for imaging study performance and reporting, XDS-I and PDI with external sharing of image study data

• IEO actors may be grouped with XDS-I Imaging Document Source, Imaging Document Repository, or Imaging Document Consumer

• IEO actors may be grouped with PDI Media Creator or Media Reader– And with Import Reconciliation Workflow Profile Importer actor

Resting ECG Workflow (REWF)

Profile Overview

Barry Brown27-July-2010

REWF Profile Scope

In Scope• Patient registration• Ordering and scheduling• Acquisition• Data storage• Data retrieval for reporting• Report distribution

Out of Scope• Reporting workflow

management• Clinical trial workflow

Use Cases

• Normal Priority, Scheduled ECGs– Patient is registered– ECG is ordered, scheduled, acquired, stored, reviewed, and reported

• Urgent ECG, Unidentified Patient– Unordered ECG– Patient demographics reconciliation

• Scheduled ECG While Offline– Order reconciliation

Other Cases Not Completely Covered

• Patient Demographics for Unscheduled ECGs– Acquisition Modality should be grouped with PDQ Consumer

• Clinical Trials– Much thought was given to clinical trial workflow, but it deserves its own

profile in a future year

• Physician Offices– ECGs are often (implicitly) ordered and acquired in a single step while a

patient is being examined– The new Image Enabled Office profile covers office-based ECG workflow

Related Profiles• RAD Scheduled Workflow (SWF)

– Patient registration– Test ordering and scheduling– Acquisition and data storage– Data retrieval

• RAD Patient Information Reconciliation (PIR)– Urgent ECGs acquired on unknown patients

• ITI Consistent Time (CT)– Synch Acquisition Modality’s clock

• ITI Patient Demographics Query (PDQ)– Acquisition Modality can query for demographics

• CARD Displayable Reports (DRPT)– Distribute ECG reports

• CARD Image Enabled Office (IEO)– Workflow in an office environment

Highlights

• Allows multi-vendor interoperability between 5 major subsystems:– Registration and ordering (HIS, CVIS)– ECG archive (PACS, ECG Management)– Acquisition devices (Electrocardiographs)– ECG analysis and reporting workstations (ECG or PACS Workstations)– ECG report consumers (EMR)

• Uses HL7 transactions for HIS and EMR• Uses DICOM transactions for acquisition devices and workstations

– ECG waveforms stored as DICOM General ECG Waveform objects– ECG measurements and interpretations stored as DICOM Structured Reports

• An “Integrated ECG Manager” actor makes it easier for traditional ECG management products to adopt this profile

Actor / Transaction Diagram

Order Placer

DSS/OF Report Creator

Acquisition Modality

Report ManagerADT

Evidence Creator

Image Display

Image Manager Image Archive

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

↑ Modality Image/Evidence Stored [CARD-2]

← Query Cardiology Images/Evidence [CARD-13]← Retrieve Image/Evidence [CARD-4]

Integrated ECG Manager

↓ Placer Order Management [RAD-2]↑ Filler Order Management [RAD-3]

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

↓ Query Cardiology Images/Evidence [CARD-13]↓ Retrieve Image/Evidence [CARD-4]

PPS Manager

MPPS In Progress [CARD-1] →MPPS Completed [RAD-7] →

Creator PPS In Progress [RAD-20] →Creator PPS Completed [RAD-21] →

↑ MPPS In Progress [CARD-1]↑ MPPS Completed [RAD-7]

↑ MPPS In Progress [CARD-1]↑ MPPS Completed [RAD-7]↑ Creator PPS In Progress [RAD-20] ↑ Creator PPS Completed [RAD-21]

↑ Query Enhanced Modality Worklist [CARD-12]

↑ Storage Commitment [CARD-3]

↑ Creator PPS In Progress [RAD-20]↑ Creator PPS Completed [RAD-21]

↓ Procedure Scheduled [RAD-4]↓ Patient Update [RAD-12]↓ Procedure Update [RAD-13]↑ Instance Availability Notification [RAD-49]

Encapsulated Report Submission [CARD-7] →

Time Client

Familiar Actors and Transactions

• Actors reused from other profiles:– ADT (SWF)– Order Placer (SWF)– DSS/OF (SWF)– Image Manager / Image Archive (SWF)– PPS Manager (SWF)– Acquisition Modality (SWF)– Evidence Creator (SWF)– Image Display (SWF)– Time Client (CT)– Report Creator (DRPT)– Report Manager (DRPT)

“Integrated ECG Manager” Actor

• Integrated ECG Manager is an optional integration of the actors in the “middle”

• Makes it easier for traditional ECG management products to adopt this profile without having to expose transactions between the integrated actors

• Individual actors are still present so traditional departmental management and archive products can treat Resting ECG Workflow like other scheduled workflows

New Transactions

• CARD-12 Query Enhanced Modality Worklist– Patient queries can also match on Admission ID– Broad queries can also match on Scheduled Procedure Step Location

• CARD-13 Query Cardiology Images/Evidence– Query returns Performed Protocol Step Code Sequence to distinguish

General ECG Waveform objects used for resting ECG from other tests and monitoring sessions

Modified Transactions

• CARD-2 Modality Images/Evidence Stored– Acquisition Modality and Image Archive actors must be able to store

General ECG Waveform and Enhanced SR (ECG Report template)

• CARD-4 Retrieve Images/Evidence– Report Creator and Image Display actors must be able to display General

ECG Waveform and Enhanced SR (ECG Report template)

• CARD-7 Encapsulated Report Submission– Specifies displayable Resting ECGs (PDFs) should meet minimum display

requirements– Basic measurements and interpretation should be included as discrete data

in OBX segments

More Information

http://www.ihe.net/Events/webinars2010.cfmIHE Webinar series 2010

http://www.ihe.net/Technical_Framework/index.cfmIHE Technical Frameworks and Supplements

New Trial Implementation versions to be released ~ Aug 1

http://wiki.ihe.net/index.php?title=CardiologyInformation on IHE Cardiology development activities

http://www.ihe.net/Events/webinars2010.cfm

http://www.ihe.net/Technical_Framework/index.cfm

http://wiki.ihe.net/index.php?title=Cardiology