IHE Cardiology Domain Overview Harry Solomon 27-July-2010.
-
Upload
alexina-oneal -
Category
Documents
-
view
214 -
download
0
Transcript of IHE Cardiology Domain Overview Harry Solomon 27-July-2010.
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
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
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]
®
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…
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
MSH|^~\$|… PID|1|0123456‑1||R… OBR|1|X89‑1501^…OBX|1|ED|11528-7^LN…
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
Enterprise Report Repository
Report Creator
Encapsulated Report Submission [CARD-7]
®
¯
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]
® Integrated Report Manager/ Repository
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…
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
MSH|^~\$|… PID|1|0123456‑1||R… OBR|1|X89‑1501^…OBX|1|ED|11528-7^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
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 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 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
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