IHE Cardiology Domain Overview Harry Solomon 27-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. – 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 IHE Webinar series IHE Technical Frameworks and Supplements New Trial Implementation versions to be released ~ Aug 1 Information on IHE Cardiology development activities

Displayable Reports (DRPT) Profile Overview Harry Solomon 27-July-2010

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 –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 Report Manager 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]       Information Source 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 Report Manager 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]       Information Source 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]  MSH|^~\$|… PID|1| ‑ 1||R… OBR|1|X89 ‑ 1501^… OBX|1|ED| ^LN… MSH|^~\$|… PID|1| ‑ 1||R… OBR|1|X89 ‑ 1501^… OBX|1|ED| ^LN… HL7 MSH|^~\$|… PID|1| ‑ 1||R… OBR|1|X89 ‑ 1501^… OBX|1|ED| ^LN… MSH|^~\$|… PID|1| ‑ 1||R… OBR|1|X89 ‑ 1501^… OBX|1|RP| ^LN… uestType=DOCUMENT&d ocumentUID=”1.2.3”&pref erredContentType=”applicat ion/pdf” HL7 MSH|^~\$|… PID|1| ‑ 1||R… OBR|1|X89 ‑ 1501^… OBX|1|ED| ^LN… HL7 HTTP (0008,0005) IR_100 (0008,0012) (0008,0013) 1109 (0008,0016) … DICOM

DRPT Diagram – Integrated Report Manager / Repository Report Repository Report Manager Enterprise Report Repository Report Creator Encapsulated Report Submission [CARD-7]   Information Source 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]   Integrated Report Manager/ Repository MSH|^~\$|… PID|1| ‑ 1||R… OBR|1|X89 ‑ 1501^… OBX|1|ED| ^LN… MSH|^~\$|… PID|1| ‑ 1||R… OBR|1|X89 ‑ 1501^… OBX|1|ED| ^LN… HL7 MSH|^~\$|… PID|1| ‑ 1||R… OBR|1|X89 ‑ 1501^… OBX|1|ED| ^LN… MSH|^~\$|… PID|1| ‑ 1||R… OBR|1|X89 ‑ 1501^… OBX|1|RP| ^LN… uestType=DOCUMENT&d ocumentUID=”1.2.3”&pref erredContentType=”applicat ion/pdf” HL7 MSH|^~\$|… PID|1| ‑ 1||R… OBR|1|X89 ‑ 1501^… OBX|1|ED| ^LN… 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

Image enabled Office (IEO) Profile Overview Harry Solomon 27-July-2010

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  Encapsulated Report Submission [CARD-7]  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 PPS Manager   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 – /IHERetrieveDICOMInfo?requestType=STUDY &studyUID= – /IHERetrieveDICOMInfo?requestType=SUMMARY &patientID= &lowerDateTime= &upperDateTime= &mostRecentResults= Image Manager responds with web-based display application –Any necessary plug-in downloadable from Image Mgr

Resting ECG Workflow (REWF) Profile Overview Barry Brown 27-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 SWF - Scheduled Workflow –Patient registration –Test ordering and scheduling –Acquisition and data storage –Data retrieval RAD PIR - Patient Information Reconciliation –Urgent ECGs acquired on unknown patients ITI CT - Consistent Time –Synch Acquisition Modality’s clock ITI PDQ - Patient Demographics Query –Acquisition Modality can query for demographics CARD DRPT - Displayable Reports –Distribute ECG reports CARD IEO - Image Enabled Office –Workflow in an office environment

Highlights Allows multi-vendor interoperability between 5 major subsystems: –Registration and ordering (HIS, CVIS) –ECG archival (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

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 and 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 New: CARD-12 Query Enhanced Modality Worklist –Patient queries can also match on Admission ID –Broad queries can also match on Scheduled Procedure Step Location New: 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

More Information IHE Webinar series IHE Technical Frameworks and Supplements New Trial Implementation versions to be released ~ Aug 1 Information on IHE Cardiology development activities