1. September, 2005What IHE Delivers IHE Cardiology Profiles Information Technology Association of Canada Jon Elion MD, FACC Chief Medical Officer, Agfa Healthcare Co-Chair, IHE-Cardiology Planning Committee

2. 2 Bob Baumgartner, McKesson Anand Kumar and Glenn Marshall, Siemens Harry Solomon and Charles Parisot, GE Healthcare Bryan Jennings, Medical Micrographics Ellie Avraham, Kodak Health Imaging Tim Becker, University of Kiel Stephen Ferber, Technology Solutions Nicholas Steblay, Boston Scientific Kevin O’Donnell, Toshiba Medical Systems John Donnelly, IntePro Solutions Didi Davis, Eclipsys Special Thanks to the Contributors

3. 3 Topics Cardiology Workflows General  Cath Workflow  Echo Workflow  Stress Workflow Content Display Requirements  Retrieve ECG for Display  Stress Echo  Stress  Nuclear Cardiology  Displayable Reports

4. 4 Cardiology vs. Radiology CT scanners are rarely unplugged and wheeled down the hall Cardiac cath procedures are inherently multimodality It is rare for a cardiac cath to be ordered ahead of time Cardiology reports have graphics in addition to text Both disciplines have emergency cases, unregistered patients, and “John Doe” situations Cardiology has more procedures (as opposed to just images), and more structured results

5. 5 General Workflow

6. 6 Topics Cardiology Workflows General  Cath Workflow  Echo Workflow  Stress Workflow Content Display Requirements  Retrieve ECG for Display  Stress Echo  Stress  Nuclear Cardiology  Displayable Reports

7. 7 Cath Lab 1 2 3 4 5 6 7 Multiple re-entry of Patient ID Error prone Results fragmented across systems Results inconsistently time-tagged Custom solutions for data sharing Difficult to manage Not coordinated with HIS Unidentified patients (emergency) Un-ordered cath exams Diagnostic and interventional Ad hoc scheduling of cath labs Change of rooms during procedure 8 9 10 11

8. 8 Administrative Process Flow ADT Order Placer Image Manager Acquisition Modality Placer Order Mgmt - New [Rad-2] Department System Scheduler/ Order Filler Procedure Scheduled [Rad-4] Register/ Admit Patient Create Order Schedule Procedure Patient Registration [Rad-1] Select Patient Query Modality Worklist [Rad-5] Start Procedure

9. 9 Procedure Performance Process Flow Image Manager/ Image Archive Acquisition Modality Department System Scheduler/ Order Filler Modality Procedure Perform Acquisition Modality Images/ Evidence Stored [Card-2] Storage Commitment [Card-3] Modality Procedure Step In Progress [Card-1] Modality Procedure Step Completed [Rad-7] Modality Procedure Step In Progress [Card-1] Order Placer Order Status Update [Rad-3] Update Schedule Acquisition Modality n Query Modality Worklist [Rad-5] Modality Procedure Step In Progress [Card-1] Modality Procedure Step In Progress [Card-1] Perform Acquisition Modality Images/Evidence Stored [Card-2] Step Completed [Rad-7]

10. 10 Use Cases C1: Patient Registered at ADT, Ordered by the Order Placer C2: Patient Registered at ADT, Ordered by DSS/OF C3: Patient Registered at ADT, Procedure Not Ordered C4: Patient Registered at DSS/OF and Procedure Ordered C5: Patient Not Registered C6: Patient Updated During Procedure C7: Change Rooms During Procedure C8: Cancel Procedure C9: Post-Procedure Evidence Creation C10: EP Ablation / Implantation Lab (only for the EP lab)

11. 11 C1: Patient Registered at ADT and Procedure Ordered at the Order Placer Clinical Context  Corresponds to traditional Radiology workflow  Order placed in central system  Also deals with case where emergency identifier has been created  Common identifiers known ahead of time IHE Context  MPPS in Progress from first modality used to update worklists for others

12. 12 C2: Patient Registered at ADT and Procedure Ordered at DSS/OF Clinical Context  Slight difference to Case 1  Order placed NOT in central system but in department  Department system provides info to Central ordering system  Typical of many institutes, relieves need for HIS terminal in lab IHE Context  Filler Order Management (New Order) transaction [RAD-3] is sent from Department System Scheduler/Order Filler to the Order Placer.

13. 13 C3: Patient Registered at ADT and Procedure Not Ordered Clinical Context  Slight difference to Case 2  Procedural information is NOT entered at the departmental system  The first modality must initiate the process of creating common procedure identifiers (usually hemo)  The common procedure identifiers are created by the departmental system based on the information available from the first modality  Can generate a “generic cath procedure” if no coded procedural type is available IHE Context  Upon receiving the first MPPS the DSS/OF will auto generate a Requested Procedure and its associated Scheduled Procedure Steps utilizing the Study UID provided in the first MPPS. All other modalities use the Query Modality Worklist transaction.

14. 14 C4: Patient Registered at DSS/OF and Procedure Ordered Clinical Context  This case accommodates the emergency case where there is not enough time to register the patient on ADT system  A temporary patient identifier is created at the department level  The order placer is notified only after the patient is registered and manually reconciled on the department system IHE Context  The DSS/OF assigns a temporary Patient ID with a temporary name and schedules the required procedures  The DSS/OF does not send the Filler Order Management (New Order) transaction to the Order Placer until the patient is registered on the ADT system and reconciliation occurs on the DSS/OF.

15. 15 C5: Patient Not Registered Clinical Context  This is the Emergent Case where the patient information is not known or there is not enough time to enter the information  A temporary ID is assigned by the department and entered at the first modality and forwards that information to the departmental system to be shared with the other modalities  Like in C4 information is sent to the Order Placer post patient registration and reconciliation on the departmental system IHE Context  Patient ID and name are selected based upon locally (usually department) base rules  The first modality will send an MPPS with the appropriate information to the DSS/OF which will in turn generate the appropriate requested procedure(s) using the Study UID assigned by the first modality

16. 16 C6: Patient Updated During Procedure Clinical Context  An unidentified patient may have been registered at the ADT and brought into the cath lab with the temporary ID  During the procedure the patient information is updated on the ADT which sends the patient update information  This can results is some of the information been associated with the temp ID and the rest with the permanent ID  The case defines how the reconciliation occurs. IHE Context  The modality may have requested information from the DSS/OF prior the patient update  The Image Manager needs to update the items stored to Image Archive as well as any subsequent items received.

17. 17 C7: Change Rooms During Procedure Clinical Context This is the case when the patient is moved due to any of the following reasons:  The change from a diagnostic to interventional procedure  The need to use the current room for another patient  Equipment failure NOTE: This case does not cover the scenario where a patient is moved to the holding area from a procedure room. IHE Context  Each modality will issue a MPS (Completed or Discontinued)  The DSS/OF will reassign the requested procedure to the new room  In the event the DSS/OF does not reassign, each modality in the new room would use the broad Modality Worklist Query  This insures consistency of the Study UID for all information

18. 18 Image Manager Acquisition Modality Room 1 Department System Scheduler/ Order Filler Modality Procedure Step Discontinued [Rad-7] Modality Procedure Step Discontinued [Rad-7] Modality Procedure Step In Progress [Card-1] Modality Procedure Step In Progress [Card-1] Acquisition Modality n Room 1 Query Modality Worklist [Rad-5] Perform Acquisition Perform Acquisition Modality Room 2 Acquisition Modality n Room 2 Query Modality Worklist [Rad-5] Modality Procedure Step In Progress [Card-1] Modality Procedure Step In Progress [Card-1] Modality Procedure Step In Progress [Card-1] Modality Procedure Step In Progress [Card-1] Query Modality Worklist [Rad-5] Perform Acquisition Perform Acquisition Query Modality Worklist [Rad-5] Modality Procedure Step In Progress [Card-1] Modality Procedure Step In Progress [Card-1] Reassign Procedure Update Schedule C7: Change Rooms During Procedure

19. 19 C8: Cancel Procedure Clinical Context  This case allows for the information systems to keep track of cancelled procedures allowing the cath lab staff to appropriately respond to queries regarding that patient. IHE Context  When the procedure is cancelled within the department the DSS/OF notifies the Order Placer system and Image Manager  The length of time this procedural information is maintained is determined by local policy.

20. 20 C9: Post-Procedure Evidence Creation Clinical Context  Allows for imaging and other procedural data to be analyzed post-procedure using specialized software (e.g., QCA, QLV, derived images)  This case does NOT apply to core lab analysis for clinical trials or outcome analysis IHE Context  This analysis must be performed on a station that groups the Image Display and Evidence Creator Actors  The Evidence Creator notifies the IM/IA and DSS/OF of the activity via the MPPS In Progress and Complete transactions  The Evidence Creator stores its evidence to the IM/IA via the Storage Commit Transaction.

21. 21 C10: EP Ablation / Implantation Lab Clinical Context  Allows for the wide array of specialized equipment used in the EP lab  Provides demographic and time synchronization IHE Context  Initial implementation is an extension of the CATH profile  Support for use cases C1 – C9  Emergency use cases C3 and C5 are highly unusual in the EP lab.

22. 22 Topics Cardiology Workflows General  Cath Workflow  Echo Workflow  Stress Workflow Content Display Requirements  Retrieve ECG for Display  Stress Echo  Stress  Nuclear Cardiology  Displayable Reports

23. 23 Use Cases E1: Patient Registered at ADT and Procedure Ordered E2: Intermittently Connected Modality E3: Intermittently Connected Modality with ad hoc Procedure, Patient Registered, Scheduled Procedure E4: Intermittently Connected Modality with ad hoc Procedure, Patient Registered, Unscheduled Procedure E5: Intermittently Connected Modality with ad hoc Procedure, Patient Unregistered, Unscheduled Procedure E6: Stress Echo Staged Protocol E7: Echo Measurements Evidence Creation

24. 24 E1: Patient Registered at ADT and Procedure Ordered Clinical Context  Corresponds to traditional Radiology workflow  Order placed in central system  Also deals with case where emergency identifier has been created  Common identifiers known ahead of time IHE Context  The Scheduled Procedure Steps are obtained by the modality through Query Modality Worklist, the acquisition is performed and statused thought Modality Performed Procedure Step.

25. 25 E2: Intermittently Connected Modality Clinical Context  Allows for the mobile workflow typical of TTE and TEE  Assumes the modality is only intermittently connected to the network  Also covers the case of the modality being turned off IHE Context  Process flow identical to Case E1  Must be paired with an Image Manager/Image Archive that also supports Intermittent Connectivity  MPPS are stored and sent when connection established  Image Manage must queue N-Event Report messages for storage commitment

26. 26 E3: ICM with Ad Hoc Procedure, Patient Registered, Scheduled Procedure Clinical Context  This extends Case E2 to allow for a scheduled procedure but the modality can’t query the worklist since it is not connected to the network IHE Context  The modality will treat this as unscheduled procedure  The patient ID and demographics must be manually entered  The modality must create the Study Instance UID  Manual matching process at DSS/OF to reconcile the scheduled and performed procedure information  Post match the DSS/OF will reconcile with the Image Manager to correct for the Study Instance UID

27. 27 E4: ICM with Ad Hoc Procedure, Patient Registered, Unscheduled Procedure Clinical Context  This is the drive by echo or Stat echo performed without an order placed in the system IHE Context  This case is identical to other unscheduled procedure cases  Modality creates the Study Instance UID  When connected the modality will send a MPPS in Progress  DSS/OF will generate an exception for reconciliation  Patient demographic reconciliation should occur automatically based on patient ID  The Image Manager will use the Patient Update transaction to update the demographics

28. 28 E5: ICM with Ad Hoc Procedure, Patient Unregistered, Unscheduled Procedure Clinical Context  This case is similar to Case E4 except the patient is not yet registered. (Emergency Admit) IHE Context  Temporary Name and ID entered into the modality  DSS/OF will generate an exception  Manual match of the temporary ID with the Patient Registration information  Patient Update sent to the Image Manager

29. 29 E6: Stress Echo Staged Protocol Clinical Context  Allows for appropriate identification of Stages and Views during a stress echo IHE Context  Similar to Case E1  Type of stress protocol is specified in the Scheduled Protocol Code Sequence or Scheduled Step Description  Within the “perform acquisition” activity there are several stages but typically considered the same procedure step  A status of “Discontinued” can indicate technical failure to reach the end point of the exam.

30. 30 E7: Echo Measurements Evidence Creation Clinical Context  Measurements are normally obtained during the acquisition on the modality.  This case supports the ability to obtain additional measurements on the clinical workstation post acquisition and update the study data. IHE Context  This case is similar to Cath C9  The actor participates in both the ECHO and ED profiles  Generation of a DICOM SR with reference to original

31. 31 Topics Cardiology Workflows General  Cath Workflow  Echo Workflow  Stress Workflow Content Display Requirements  Retrieve ECG for Display  Stress Echo  Stress  Nuclear Cardiology  Displayable Reports

32. 32 So what is Stress Testing? Uses graded exercise or medication to increase the work of the heart (“stress”) Continuous 12 lead ECG monitoring during study (looking for arrhythmias, changes in ST segments) Used as a screening tool or to test effectiveness of therapy May be done “standalone” or with imaging (echo, nuclear)

33. 33 Stress Workflow Diagram

34. Stress Workflow – Actors and Options Actor Option Name Acquisition Modality Patient Based Worklist Query (optional) Broad Worklist Query PPS Exception Management (optional) Stress ECG Stress Echo Nuclear Medicine Image Manager/ Image Archive PPS Exception Management (optional) Intermittently Connected Modality Stress ECG Echocardiography Nuclear Medicine Availability of PPS-Referenced Instances (optional) Image Display Stress ECG Stress Echo Cardiac NM

35. 35 Use Cases Case S1: Cardiac Stress Test, ECG Only  Limited use with lower sensitivities and specificities  Screening tool only Case S2: Cardiac Stress Test with Imaging  More common use case Echocardiography – requires Consistent Time to combine clinical data from Stress Monitor and Echo Modality Echocardiography – requires Consistent Time to combine clinical data from Stress Monitor and Echo Modality

36. 36 Topics Cardiology Workflows General  Cath Workflow  Echo Workflow  Stress Workflow Content Display Requirements  Retrieve ECG for Display  Stress Echo  Stress  Nuclear Cardiology  Displayable Reports

37. 37 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-by- side synchronized display).

38. 38 RED Profile Scope Reused IHE-ITI RID as it existed:  Retrieve list of cardiology documents, including ECGs in ready-to-display format (HTML)  Retrieve single document, including an ECG  ECGs served in displayable format (PDF, SVG)  Compatibility with existing RID clients

39. 39 RED Scope (cont.) Make ECG-specific extensions to RID  Place requirements on ECG source to ensure high-quality ECG documents.  Add ECG-specific request for list of ECGs to be returned as XML allowing more client flexibility.  Add SVG (vector graphics) as allowed ECG document format.

40. 40 PDF ECG Source required to support PDF so it is compatible with existing RID clients. PDF is a common document type and most computers already have a viewer. ECG Source required to use vector graphics for waveforms in PDF.  Gives high quality line drawings at any screen resolution and zoom factor.  Rasterized (e.g. scanned, bitmapped) ECG “images” not allowed.

41. 41 Example ECG (PDF)

42. 42 Example 1200x Zoom ECG (PDF)

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

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

45. 45 ECG List XML Example

46. 46 ECG List XML Example Formatted with Style sheet

47. 47 Topics Cardiology Workflows General  Cath Workflow  Echo Workflow  Stress Workflow Content Display Requirements  Retrieve ECG for Display  Stress Echo  Stress  Nuclear Cardiology  Displayable Reports

48. 48 Views Apical two chamber Apical four chamber Apical long axis Parasternal long axis Parasternal short axis Parasternal short axis at the aortic valve level Parasternal short axis at the level of the mitral chords Parasternal short axis at the Mitral Valve level Parasternal short axis at the Papillary Muscle level Right Ventricular Inflow Tract View Right Ventricular Outflow Tract View Subcostal long axis Subcostal short axis Suprasternal long axis Suprasternal short axis Stage and Views  Stress Echo Option Stage Number & View Number Stage Number & View Number Stage Code Sequence & View Code Sequence Stage Code Sequence & View Code SequenceCodingSchemeDesignator(0008,0102) Code Value (0008,0100) Code Meaning (0008,0104) SRTP5-01201 Image acquisition at baseline SRTP5-01202 Pre-stress image acquisition SRTP5-01203 Mid-stress image acquisition SRTP5-01204 Peak-stress image acquisition SRTP5-01205 Image acquisition during recovery

49. 49 Benefit: Viewing Consistency

50. 50 Topics Cardiology Workflows General  Cath Workflow  Echo Workflow  Stress Workflow Content Display Requirements  Retrieve ECG for Display  Stress Echo  Stress  Nuclear Cardiology  Displayable Reports

51. 51 Stress: Protocol and Stage Procedure : Exercise Stress Protocol: Bruce Stages:  Standard Bruce has 7 stages Stage 1: 1.7 mph @ 10 % grade Stage 1: 1.7 mph @ 10 % grade Stage 7: 6.0 mph @ 22 % grade Stage 7: 6.0 mph @ 22 % grade Important Note: A procedure can be considered complete irrespective of the protocol being complete!

52. 52 Attribute Summary Concept Modality Worklist EchoECGNM Requested Procedure Requested Procedure Code Sequence (0032,1064) Procedure Code Sequence (0008,1032) Protocol Scheduled Protocol Code Sequence (0040,0008) Performed Protocol Code Sequence (0040,0260) CID 12001* Performed Protocol Code Sequence (0040,0260) CID 3261 Performed Protocol Code Sequence (0040,0260) CID 3261** Protocol Stage Number Acquisition Context Sequence (0040,0555) >(109055, DCM, “Protocol Stage”) Patient State Stage Number (0008,2122) Stage Code Sequence (0040,000A) CID 12002* Acquisition Context Sequence (0040,0555) >(109054, DCM, “Patient State”) CID 3262 Acquisition Context Sequence (0040,0555) >(109054, DCM, “Patient State”) CID 3101

53. 53 Topics Cardiology Workflows General  Cath Workflow  Echo Workflow  Stress Workflow Content Display Requirements  Retrieve ECG for Display  Stress Echo  Stress  Nuclear Cardiology  Displayable Reports

54. 54 Nuclear Cardiology Image formats  Stress and Rest raw data review  Stress and Rest processed data  Gated SPECT data  Quantitative data  Screen captures, “snap shots” Color maps  Gray scale is default  Color overlays can be applied

55. 55 Perfusion Display Standard perfusion display Stress/Rest  Short axis  Horizontal long axis  Vertical long axis

56. 56 Perfusion Display - Color Standard perfusion display Stress/Rest  Short axis  Horizontal long axis  Vertical long axis Color map can be overlaid on the image

57. 57 Gated SPECT Display Apical, mid and basal short axis slices Mid-ventricle vertical and horizontal long axis slices

58. 58 Quantitative Display Output from 3 rd party quantitative perfusion and gated software can be displayed

59. 59 Topics Cardiology Workflows General  Cath Workflow  Echo Workflow  Stress Workflow Content Display Requirements  Retrieve ECG for Display  Stress Echo  Stress  Nuclear Cardiology  Displayable Reports

60. 60 Purpose of Displayable Reports Profile DRPT provides a methodology to create, finalize, archive, read, revise and distribute cardiology clinical reports from the department to the enterprise and beyond

61. 61 Example Displayable Reports

62. 62 Displayable Reports Profile Actors Report Creator – A system that generates and transmits clinical reports. Report Manager – A system that manages the status of reporting, and distributes reports to report repositories. Report Repository – A departmental system that receives reports and stores them for long-term access. Enterprise Report Repository – A system that receives reports and/or references (pointers) to reports, and stores them for access throughout the healthcare enterprise. Report Reader – A system that can query/retrieve and view reports encoded as DICOM objects.

63. 63 Displayable Reports Profile Transaction Diagram

64. 64 DRPT and XDS Displayable Reports Profile specifies production of reports within an organization Cross-enterprise Document Sharing (XDS) Profile specifies distribution of reports outside the organization Typically, only a subset of internally generated reports will be shared outside

65. September, 2005What IHE Delivers PDQ-IDC Present & Future Issues

66. 66 Challenge of PDQ-IDC Implementation PDQ (ITI-21): Patient Demographic Query IDC: Implantable Devices (Cardiac) (IEEE standard 1073: ACC designated nomenclature) In an urgent and/or emergent patient, how do we import demographic information into an IT infrastructure? information into an IT infrastructure?

67. 67 Implantable Cardiac Devices Pacemakers – therapy for heart rate problems Defibrillators – therapy for life threatening heart rhythms Cardiac Resynchronization – therapy for congestive heart failure

68. 68 Current State of the Art IDC: Implantable Defibrillators, Cardiac  Can also be pacemakers, single or dual chamber The patient and/or MD cannot easily identify their device unless they happen to have their ID card with them. In an emergent or urgent case where patient is unconscious, or unknown, how do we identify the device?  Vendor limitation from programmer to IDC  No central registry, domestically or internationally

69. 69 Present-Day Solutions X-Ray the device Contact technical services at mfg, if available Interrogate the device with the appropriate programmer. Problems:  Time consuming  Trial and error method  Unsafe, if patient is in a life-threatening arrhythmia  Vendors may not be geared up or staffed to answer immediately.

70. 70 PDQ-IDC Real World Implementation Model

71. 71 Summary Is the due-diligence which this effort requires worth the changes that the vendors and providers must make?  Short answer---Yes! The lives of the patients and time saving for the clinicians are significant if--- PDQ-IDC communication is completed!

72. What IHE Delivers Implantable Device Cardiac Observations (IDCO) Profile

73. 73 Device Interrogations Implant Clinic Home The act of retrieving data from implanted cardiac devices. Done at implant or during patient follow-ups. Information includes Patient and Device Observations, and Therapy Settings

74. 74 Implantable Cardiac Device Follow-up Problems and Opportunities Electrophysiologists follow patients with implantable cardiac devices from multiple vendors Information stored in the device is collected by an “interrogating” device (vendor proprietary)  In-Clinic – Programmer  Remote – Communicator / Data Collector Access to follow-up information often requires clinicians to use multiple vendor specific systems, complicating efficiency and quality of workflows Aggregation of data into a clinical management system or EMR requires manual (paper) processes

75. 75 IDCO Value Proposition Enable management of follow-up information in a central system such as an Device Clinic Management System or EMR Improve efficiency and quality of related clinical processes  Single point of access for information  Automation of current manual processes for data collection, aggregation and analysis  Standardization of workflow processes  Enabling of analytics

76. IDCO Profile Systems Model

77. 77 IDCO Actors and Transaction

78. 78 IDCO Actors Observation Creator: System that creates and transmits diagnostic or therapeutic observational data. Observation Processor and Repository: Systems that receives, processes and stores clinical observations Grouped with PIX and PAM actors for patient identification and demographics management (not required first year).

79. 79 IDCO Actors Alternative Actor configuration HL7 Router - A system that receives HL7 messages, routes them to one or more configured actors, and handles transport level acknowledgements. Router will manage patient identification cross-referencing

80. 80 IDCO Transaction CARD-12  Unsolicited HL7 v2.5 ORU message  OBX contains XML payload based on HL7 v3 IDC message  XML payload coded using ISO/IEEE 11073.1.1.3 IDC nomenclature containing Device Observations, Patient Observations, Device Therapy Settings  Options for standard v2.5 OBX and embedded PDF report  Audit Trail and Node Authentication (ATNA) profile recommended for remote follow-ups across non-trusted networks

81. What IHE Delivers Evidence Documents Profile

82. 82 Evidence Documents Problem Cardiology is measurement intensive More and more modalities and workstations provide digital measurements More and more sites are doing electronic reporting  … to improve efficiency, turnaround time and reduce errors Current “state of the art”? -> Screen dump a paper report  Introduces multiple unnecessary error points:  A series of numbers that could be misread, misspoken, misheard and mistyped  Introduces additional unnecessary effort and delay

83. 83 Evidence Documents Scope Covers creation, storage and retrieval of evidence documents Evidence Documents:  contain observations such as measurements, procedure logs, analytical results, etc.  are inputs to the interpretation process (like images)  generally created, managed and used entirely inside the department  Are not diagnostic reports Diagnostic Reports are:  Outputs from the interpretation process  Generally created inside the department and distributed outside

84. 84 Evidence Documents Use Case Electronic Distribution of measurements Evidence Document Stored Storage Commitment Query / Retrieve ….. Findings: Image Refs.: Header : Report Type: Echo EF ….. WallMotion

85. 85 Evidence Documents Image References Echocardiography Measurement Patient: Doe, John Technologist: der Payd, N Measurements: Mitral valve diameter 3.1cm - shown in image at [ ] Ventricular length, diastolic 5.97 cm - shown in image at [ ] Ventricular volume, diastolic 14.1 ml - inferred from [ ] - inferred from VLZ algorithm

86. 86 Evidence Documents Value proposition Measurements are managed in same study folder as images Data is structured and uses coded concepts and vocabulary Coded data can be searched, processed, databased (locally, national registry), … Avoids detour through “paper-space”

87. 87 Evidence Documents Technical Basis Based on:  DICOM Structured Report (SR) Objects  Storage Commitment  Query/Retrieve Addresses creation/distribution of the content Scheduling and progress reporting could easily be supported by also implementing an appropriate IHE workflow profile

88. 88 Evidence Documents Cath Evidence Option Acquisition Modalities / Evidence Creators: Shall use one or more of the following templates:  3001 Procedure Log  3202 Ventricular Analysis  3213 Quantitative Arterial Analysis  3250 Intravascular Ultrasound  3500 Hemodynamics Image Displays: Shall unambiguously render ALL of the above  Includes providing visual emphasis for measurements flagged “abnormal”  Support of the templates is implicit in support of the DICOM Objects  Displays may optimize display for the templates

89. 89 Evidence Documents Echo Evidence Option Acquisition Modalities / Evidence Creators: Shall use one or more of the following templates:  5100 Vascular Ultrasound  5200 Echocardiography Image Displays: Shall unambiguously render ALL of the above  Includes providing visual emphasis for measurements flagged “abnormal”  Support of the templates is implicit in support of the DICOM Objects  Displays may optimize display for the templates

90. 90 Evidence Documents Other Templates:  3900 CT/MR Cardiovascular Analysis  4000 Mammography CAD  4100 Chest CAD  4200 Breast Imaging Report  5000 OB-Gyn Ultrasound Report

91. September, 2005What IHE Delivers Data Harvesting: Retrieve Form for Data Capture (RFD)

92. 92 Data Harvesting for Cardiology Why bother Why bother  ACC-NCDR,  ICD/Pacemaker Registry,  STS Originally planned for year 3  Deferred to allow ITI – RFD  HIGH priority year 4

93. 93 Retrieve Form for Data Capture A standard way of displaying external data capture forms inside an EHR. Many-to-many integration – any EHR can retrieve forms from many external systems. Low barrier of entry for EHR and external systems. Flexible profile to accommodate both low-tech and sophisticated implementations.

94. 94 RFD Profile Initial Phase  Define standard format for forms  Define standard method for retrieving and submitting forms Content Profile Phase  Provide domain-specific form requirements  Enable form population from EHR mapped data

95. 95 RFD Actors Form Filler  Retrieves a List of XForms from a Form Manager  Queries a Form Manager for a List of Available FormIDs Form Manager  Supplies a List of XForms upon request  Supplies a List of Available FormIDs Form Receiver  Receives the submitted Instance Data

96. 96 RFD Transactions Retrieve Forms  Supply a FormID to Form Manager to retrieve a List of XForms Query Form Manager  Supply a set of (name,value) pairs to a Form Manager to retrieve a List of FormIDs Submit Form  XForm Submit action, Posting Instance Data to a Form Receiver Archive Form  Think of this as a Carbon Copy feature  Optional XForm Submit action for Form Fillers to use

97. 97 Actors and Transactions

98. 98 Goals of XForms Rich, XML-based, forms to meet the needs of business and consumer web applications Support for desktop browsers and other mobile devices Decoupled data, logic, and presentation Reduce/eliminate the need for script Support for structured form data in all XML Advanced forms logic

99. 99 RFD at Connectathon RFD is not yet a published profile Publication comes after deadline for Connectathon Profiles RFD will be special case at Connectathon Landen Bain and others will orchestrate tests Goal: 3 EHR and 3 EDC Vendors for HIMSS

100. 100