1 / 41

IHE Cardiology

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

jenny
Download Presentation

IHE Cardiology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Agenda • Domain Update • Overview of existing profiles • New profiles

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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’ Retrieve ECG for Display

  8. 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

  9. 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

  10. More Information http://www.ihe.net/Events/webinars2010.cfm IHE Webinar series 2010 http://www.ihe.net/Technical_Framework/index.cfm IHE Technical Frameworks and Supplements New Trial Implementation versions to be released ~ Aug 1 http://wiki.ihe.net/index.php?title=Cardiology Information on IHE Cardiology development activities

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

  12. Example Displayable Reports

  13. 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

  14. 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

  15. DRPT Actor / Transaction Diagram Report Creator Encapsulated Report Submission [CARD-7] ¯ Integrated Report Manager/Repository Procedure Scheduled [RAD-4] Patient Update [RAD-12] Procedure Update [RAD-13] Enterprise Report Repository ® Encapsulated Report Submission [CARD-7] Report Manager  ® Report Reference Submission [CARD-8] Report Reference Submission [CARD-8] DSS/ Order Filler Patient Update [RAD-12] ® Encapsulated Report Storage [CARD-9] ¯ Storage Commitment [RAD-10] ¯ Information Source Report Repository Display ­ Encapsulated Report Query [CARD-10] Encapsulated Report Retrieve [CARD-11] ­ Report Reader

  16. 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”

  17. HL7 MSH|^~\$|… 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|ED|11528-7^LN… MSH|^~\$|… PID|1|0123456‑1||R… OBR|1|X89‑1501^… OBX|1|ED|11528-7^LN… HL7 HL7 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” MSH|^~\$|… PID|1|0123456‑1||R… OBR|1|X89‑1501^… OBX|1|ED|11528-7^LN… HTTP DICOM (0008,0005) IR_100 (0008,0012) 20061113 (0008,0013) 1109 (0008,0016) 1.2.8401008.… DRPT Diagram – Separate Report Manager and Report Repository Report Creator Encapsulated Report Submission [CARD-7] ¯ Procedure Scheduled [RAD-4] Patient Update [RAD-12] Procedure Update [RAD-13] Enterprise Report Repository ® Encapsulated Report Submission [CARD-7] Report Manager  ® Report Reference Submission [CARD-8] Report Reference Submission [CARD-8] DSS/ Order Filler Patient Update [RAD-12] ® Encapsulated Report Storage [CARD-9] ¯ Storage Commitment [RAD-10] ¯ Information Source Report Repository Display ­ Encapsulated Report Query [CARD-10] Encapsulated Report Retrieve [CARD-11] ­ Report Reader

  18. HL7 MSH|^~\$|… 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|ED|11528-7^LN… MSH|^~\$|… PID|1|0123456‑1||R… OBR|1|X89‑1501^… OBX|1|ED|11528-7^LN… HL7 HL7 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” MSH|^~\$|… PID|1|0123456‑1||R… OBR|1|X89‑1501^… OBX|1|ED|11528-7^LN… HTTP DRPT Diagram – Integrated Report Manager / Repository Report Creator Encapsulated Report Submission [CARD-7] ¯ Procedure Scheduled [RAD-4] Patient Update [RAD-12] Procedure Update [RAD-13] Integrated Report Manager/ Repository Enterprise Report Repository ® Encapsulated Report Submission [CARD-7] Report Manager  ® Report Reference Submission [CARD-8] Report Reference Submission [CARD-8] DSS/ Order Filler Information Source Report Repository Display

  19. 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

  20. 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

  21. 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

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

  23. 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

  24. 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)

  25. 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

  26. IEO Actor / Transaction Diagram Integrated EHR-S EHR-S Information Source Display  Encapsulated Report Submission [CARD-7]  Notify Study Access [CARD-14]  Invoke Image Display Service [CARD-15] • Encapsulated Report Storage • [CARD-9]  Patient Registration [RAD-1]  Placer Order Management [RAD-2]  Procedure Scheduled [RAD-4]  Outpatient Update [CARD-16]  Outpatient Update [CARD-16]  Filler Order Management [RAD-3]  Procedure Updated [RAD-13] Report Creator PPS Manager DSS / OF Query Images Evidence […] Retrieve Images/ Evidence [CARD-4] Image Display Image Manager / Image Archive    Procedure Step in Progress […]  Query Modality Worklist [RAD-5] Procedure Step Completed […] Evidence Creator  Modality Images /Evidence Stored [CARD-2] Acquisition Modality  Storage Commitment [CARD-3]

  27. 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)

  28. 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)

  29. 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)

  30. 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

  31. 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

  32. Resting ECG Workflow (REWF) Profile Overview Barry Brown 27-July-2010

  33. REWF Profile Scope In Scope Out of Scope Reporting workflow management Clinical trial workflow • Patient registration • Ordering and scheduling • Acquisition • Data storage • Data retrieval for reporting • Report distribution

  34. 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

  35. 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

  36. 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.

  37. Actor / Transaction Diagram

  38. 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)

  39. “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

  40. 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

  41. More Information http://www.ihe.net/Events/webinars2010.cfm IHE Webinar series 2010 http://www.ihe.net/Technical_Framework/index.cfm IHE Technical Frameworks and Supplements New Trial Implementation versions to be released ~ Aug 1 http://wiki.ihe.net/index.php?title=Cardiology Information on IHE Cardiology development activities

More Related