IHE Cardiology Michio Kimura Hamamatsu medical school Masaaki

IHE Cardiology Michio Kimura Hamamatsu medical school Masaaki Hirai Nihon Kohden Co. ,

Why IHE in cardiology? (1) • Cardiology workflow is complex • Multiple diagnostic tests are very common – Large number of manual demographic input steps is common. – This leads to inefficiency, invalid data in clinical archives and can lower the quality of care

Why IHE in cardiology? 　(2) • The Cardiology position in the IT technology adoption cycle makes the IHE an ideal foundation • The concepts of the IHE TF have broad general applicability, many can be directly leveraged in Cardiology • Some of Cardiology’s special requirements can be well met by the IHE TF • The TF could be adapted to meet Cardiology specific needs

Mission • In order to reduce medical errors, improve quality, and efficiency IHE shall develop intercommunication standards to manage order entry, acquisition, and billing, and provide a consistent display of images, waveforms, measurements, and reports leveraging existing IHE technical frameworks.

Cardiac examination workflow ECG Patient complaint Hemodynamics Catheterization Chest X-ray Stress ECG Labs Interventional Procedure Nucleus Echo、Stress Echo Holter ECG

Common needs • Cardiology departments have needs similar to Radiology departments – – – – Both are driven by imaging modalities Workflow is similar at a very high level Need to manage distributed departmental resources Desire an integrated patient-centered view Need for administrative reporting Need to improve lab efficiency via workflow management Legacy installed base technology issues

Complexity of Core Data • Radiology – Diagnostic Imaging • CT, MR, US, NM… • Scanned Film – Text Reports – Measurements • Cardiology – Diagnostic Imaging • XA, US, NM, CT, MR – Waveforms • ECG, Hemo, EP, Stress – Extensive numeric measurements – Lab data – Complex Reports • Stress, Holter, Cath

Cardiology Workflow Elements • Workflow elements in common with Radiology: – Patients are admitted – Demographics entered (often multiple times for the same patient) – Imaging studies are performed and read – Reports generated

Cardiology Workflow Elements • Additional Workflow elements: – Echo, ECG & lab data often prerequisites to treatment – Consumable materials and clinical data tied to procedures – Monitoring data is part of the Cath procedure – Echo as follow on to a Cath procedure – Interpretation generally uses multiple clinical inputs

Scheduled Workflow “Works” for Cardiology ECG nt cs, tie phi Pa gra les mo edu De Sch HIS ADT, OMG, (ORM) CIS (Performed Procedure Step Mgr, Order Placer/Filler Actors) Wa & vef Re orm por t ECG LAB Image & Reports DMWL MPPS CATH Patient Demographics, Schedules Storage Commitment Waveform & Report HEMODYNAMICS Pa en tie nt Sc De he mo du gr le ap s hi cs DM , M PP WL S tm mi CATH LAB C e rag om o St a ECHO LAB s ge s ort p Re & Im t DICOM Image Manager/ Archive & Report Repository

Scheduled Workflow “Works” for Cardiology • Minimizing redundant demographic input and producing valid header data in the clinical archive is important in Cardiology – Multiple modality inputs of Cardiology drives the value – Basic problem is well addressed by the Scheduled Workflow and Patient Reconciliation Integration Profiles in IHE Year 3

Patient Information Reconciliation Profile “Works” for Cardiology • Extends Scheduled Workflow – Handle unidentified patient (e. g. emergent) – Handle demographic information mistakes – Propagate changes to all affected systems, update all affected data • Reduces incorrectly identified or “lost” studies • Can reduce lost charge postings (billing)

Easy Wins for IHE in Cardiology • Workflow in the Cath lab can be streamlined – Minimize data re-entry – Automate pre-fetching • Since Scheduled Workflow leverages DICOM MPPS, near real time updates on Cath procedure status are possible • DICOM SR and Waveform allow the use of a common DICOM archive for waveform and imaging systems

Connectivity Challenges • DICOM MPPS is a limiting capability for integrating Cardio modalities. – New Imaging modalities are starting to have IHE Modality Actor support, but the legacy installed base will be an integration challenge. • Waveform modalities need to either adopt DICOM modality messaging and storage or the IHE TF needs to be extended to allow HL 7 or “other” methods. – There are underlying standards (IEEE, SCP-ECG) that could be leveraged by the IHE in the future. – MFER(ISO 11073 -92001) is available.

Clinical Challenges in Cardiology for the IHE • IS driven order creation in Cardiology is not generally available • GSPS and Key Image Note have value, but are clearly limited today – Cardiologists use motion images and color data that depicts cardiac function • Simple Image and Numeric Reports – Pictorial diagrams for anatomy, function and viability are needed for clinical reports – Extensions to manage specific frames of cine objects and waveform objects would be needed

Other Technology Challenges • Some Cardiology tasks are still hard to “do digital” – Pediatric Echo is just now able to enter the digital era • Huge volume of data required to “do a search mission” on a tiny fast beating heart • Extensive measurements needed to understand the clinical situation – EP data volume – Real-time critical care monitoring

Modality Connectivity in Cardiology • Critical care monitoring is out of scope for now. • Waveform systems are challenging. – Some Hemo systems and ECG information systems support HL 7 ADT and ORM messaging allowing functionality similar to DICOM MWL. – Others have proprietary connectivity capabilities which could be “rigged” to enable MWL “style” modality messaging

Cardiac Cath/Echo Actors & Transactions ADT Pt. Registration [RAD-1] ¯ Patient Update [RAD-12] ¯ DSS/ Order Filler ¯ Pt. Registration [RAD-1] ¯ Patient Update [RAD-12] ¬ Placer Order Management [RAD-2] ® Filler Order Management [RAD-3] Order Placer ¯ Procedure Scheduled [RAD-4] ¯ Patient Update [RAD-12] ¯ Procedure Updated [RAD-13] Modality PS in Progress [CARD-1] Modality PS Completed [RAD-7] Instance Availability Notification [RAD-49] ¬ Modality PS in Progress [CARD-1] ¬ Modality PS Completed [RAD-7] Evidence Creator Storage Commitment ¯ [CARD-3] Performed Procedure Step Mgr ® Modality PS in Progress [CARD 1] ® Modality PS Completed [RAD-7] ¬ Query Modality Worklist [RAD-5] ¯ Modality Image/Evidence Stored [CARD-2] ¯ Query Images [RAD-14] ¯ Retrieve Images/Evidence [CARD 4] ¯ Query Evidence [RAD-44] Image Manager Archive Storage Commitment [CARD 3 -1] ¬ Modality PS in Progress [CARD-1] ¬ Modality PS Completed [RAD-7] Image Display Modality Image/Evidence Stored [CARD-2] Acquisition Modality

Cardiac Cath Workflow Use Cases • Case C 1: Patient Registered at ADT and Procedure Ordered at the Order Placer • Case C 2: Patient Registered at ADT and Procedure Ordered at DSS/OF • Case C 3: Patient Registered at ADT and Procedure Not Ordered • Case C 4: Patient Registered at DSS/OF and Procedure Ordered • Case C 5: Patient Not Registered • Case C 6: Patient Updated During Procedure • Case C 7: Change Rooms During Procedure • Case C 8: Cancel Procedure • Case C 9: Post-Procedure Evidence Creation

Echo Use Cases • Case E 1: Patient Registered at ADT and Procedure Ordered • Case E 2: Intermittently Connected Modality • Case E 3: Intermittently Connected Modality with Ad Hoc Procedure, Patient Registered, Scheduled Procedure • Case E 4: Intermittently Connected Modality with Ad Hoc Procedure, Patient Registered, Unscheduled Procedure • Case E 5: Intermittently Connected Modality with Ad Hoc Procedure, Patient Unregistered, Unscheduled Procedure • Case E 6: Stress Echo Staged Protocol • Case E 7: Echo Measurements

Displayable Reports (DRPT) • Case R 1: Report manager provides local storage and distribution of reports • Case R 2: Image manager/archive provides storage and distribution of reports • Case R 3: Multiple Reports on one Requested Procedure • Case R 4: Preliminary, Final and Corrected Reports

ECG Profile Transaction Diagram Retrieve Specific Info for Display [ITI-11] Retrieve ECG List [CARD-5] Display Retrieve ECG Document for Display [CARD-6] Information Source

ECG Needs • ECGs Accessible Everywhere! • Need broad distribution of ECGs using ubiquitous technology (Web). – Allow medical applications to easily retrieve and display ECGs in a platform/vendor neutral way. • High-quality ECG documents. Avoid artifacts on zoomed ECGs and arbitrary display geometries. – Vector images required (not rasterized) • Facilitate apps for serial comparison (side-byside synchronized display). MFER

ECG Profile Abstract / Scope • Provide ECGs and related documents to enterprise • Reuse IHE-ITI RID – Retrieve list of documents; retrieve single document – ECGs served in ready-to-display format (MFER, [PDF, SVG *IHE-J option]) • Limited extension for ECG-specific needs – Add requirements on display format and quality – [Include XML-based ECG report list *IHE-J option]

Out of Scope • • ECG acquisition and reading workflow. ECG raw data interchange. Export of reports to external repository. Central management and configuration of ECG devices

ECG Profile Value Proposition • Use ubiquitous HTTP Get mechanism as defined in IHE-ITI RID – Standardized URLs • USE MFER(ISO 11073 -92011) for ECG display *IHE-J national extention • [Use PDF for easy integration with existing display applications *IHE-J option] • [PDF vector graphics supports scalable waveforms *IHE-J option] • [XML list of ECGs for serial comparison apps *IHE-J option]

MFER: ISO/11073 -92001 (measuring R-R interval with caliper)

MFER zoom-in view (measuring with scale)

CDA report with MFER

Example ECG in (vector)PDF Format

Example ECG in SVG Format

ECG Profile Actors • Display – A system that can request and display preformatted (“presentation-ready”) data using Web technologies. • Information Source – A system that responds to requests for patient-related ECG data by encoding it in a presentation-ready format using Web technologies. • Same actors as RID Profile

ECG Profile Transactions • Retrieve Specific Info for Display [ITI-11] – Uses HTTP Get query parameters “SUMMARY” or “SUMMARY-CARDIOLOGY” – [Response list of documents (including ECGs) in ready-todisplay format (XHTML) *IHE-J option] • Retrieve ECG List [CARD-5] – Uses HTTP Get query parameter “SUMMARYCARDIOLOGY-ECG” – [Response list of ECGs in processable format (HL 7 RIMderived XML) *IHE-J option] • Retrieve ECG Document for Display [CARD-6] – MFER – [Response ECG served in PDF *IHE-J option] – [SVG allowed if Display actor asks for it and Information Source supports it *IHE-J option]

Use Case D 1: Simple Display • Display actor requests list of ECG documents for a specific patient ID. – RID profile SUMMARY-CARDIOLOGY request returns list as HTML. – [ECG profile SUMMARY-CARDIOLOGY-ECG request returns list as XML with stylesheet. *IHE-J option] • Display actor requests a specific ECG document using a unique document ID. – The ID of the requested document may not have been obtained from the previously retrieved list.

MFER: ISO/11073 -92001 (measuring R-R interval with caliper)

Use Case D 2: Advanced Display • Display actor requests list of ECG documents for a specific patient ID using ECG profile request type. – [List of ECGs returned as structured XML. *IHE-J option] • Display actor parses structured document list to select related ECGs for serial comparison, for example. • Display actor requests the specific ECG documents using the unique document IDs obtained in structured list above. • Display actor displays the ECGs in a meaningful way

Advanced MFER ECG display (3 x 4)

Advanced MFER ECG display (6 x 2)

IHE exhibition show in Japanese Circulation Society conference

Future profiles • Hemodynamics • IVUS • Data harvesting • Stress ECG/Echo • Holter ECG