Cardiology Workflow & Display Requirements

1. Cardiology Workflow & Display Requirements ACCA IHE Workshop 2007 Bob Baumgartner, BSN, MBA McKesson Corporation IHE-Cardiology Planning Committee Administrative Co-Chair

2. Agenda • Cardiology Workflows General • Cath Workflow • Echo Workflow • Stress Workflow • Content Display Requirements • Stress Echo • Stress

3. Cardiology Workflows • Cardiology: the study of the • heart • its action • and diseases

4. The Problem This is an example of a cardiology workflow. Any questions! Workflow is the linchpin to data integrity

5. General Workflow

6. Agenda • Cardiology Workflows General • Cath Workflow • Echo Workflow • Stress Workflow • Content Display Requirements • Stress Echo • Stress

7. 7 6 5 8 10 9 11 4 3 2 1 Cath Lab • Multiple re-entry of Patient ID • Error prone • Results fragmented across systems • Results inconsistently time-tagged

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

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

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

11. Case 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. Case 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. Case 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. Case 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. Case 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. Case 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. Case 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. Case 7: Change Rooms During Procedure Department System Image Acquisition Acquisition Acquisition Acquisition Scheduler/ Manager Modality Room 1 Modality n Room 1 Modality Room 2 Modality n Room 2 Order Filler Query Modality Worklist [Rad-5] Modality Procedure Modality Procedure Perform Step In Progress [Card-1] Step In Progress [Card-1] Acquisition UpdateSchedule Query Modality Worklist [Rad-5] Modality Procedure Modality Procedure Perform Step In Progress [Card-1] Step In Progress [Card-1] Acquisition Modality Procedure Modality Procedure Step Discontinued [Rad-7] Step Discontinued [Rad-7] Reassign Procedure Query Modality Worklist [Rad-5] Modality Procedure Perform Modality Procedure Step In Progress [Card-1] Step In Progress [Card-1] Acquisition UpdateSchedule Query Modality Worklist [Rad-5] Modality Procedure Modality Procedure Perform Step In Progress [Card-1] Step In Progress [Card-1] Acquisition

19. Case 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. Case 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. Case 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. Agenda • Cardiology Workflows General • Cath Workflow • Echo Workflow • Stress Workflow • Content Display Requirements • Stress Echo • Stress

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

24. Case 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. Case 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. Case 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. Case 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. Case 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. Case 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. Case 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. Agenda • Cardiology Workflows General • Cath Workflow • Echo Workflow • Stress Workflow • Content Display Requirements • Stress Echo • Stress

32. Stress Testing • Image Intensive…multiple samples of 12 lead ECG during the protocol • Summary report usually one page in length • Physician will do comparisons to previous studies

33. Stress Options • Stress Echo • Began in the early – mid 1990’s • Observation of wall motion and ejection fractions with the heart under stress • High specificity for correlating ischemia to functional abnormalities • Can be done with exercise but mainly chemical • Nuclear Stress • Most often combined with exercise or chemical stress testing • Use of radioisotope to detect presence and resolution of ischemic regions of the heart • Scan immediately post • Scan 4 hours to 1 day later • Resolution of ischemic area determines viability of muscle

34. Stress Workflow Diagram

35. Stress Workflow – Actors and Options

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

37. Agenda • Cardiology Workflows General • Cath Workflow • Echo Workflow • Stress Workflow • Content Display Requirements • Stress Echo • Stress

38. Stage and Views • Stress Echo Option • Stage Number & View Number • Stage Code Sequence & View Code Sequence

39. Benefit: Stress Echo Viewing Consistency

40. Agenda • Cardiology Workflows General • Cath Workflow • Echo Workflow • Stress Workflow • Content Display Requirements • Stress Echo • Stress

41. Stress: Protocol and Stage Procedure Protocol Stages

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

43. Attribute Summary