IHE Radiology Workflow: Adaptation to Cardiology Harry Solomon

March, 2004IHE Cardiology Technical Committee2 Access to Radiology Information Consistent access to images and reports IHE Radiology Integration Profiles Patient Information Reconciliation Unknown patients and unscheduled orders Consistent Presentation of Images Hardcopy and softcopy grayscale and presentation state Presentation of Grouped Procedures Subset a single acquisition Key Image Notes Exchange flagging significant images Simple Image and Numeric Reports Exchange simple reports with image links and, optionally, measurements Scheduled Workflow Admit, order, schedule, acquire images, notify of completed steps

March, 2004IHE Cardiology Technical Committee3 Integration Profiles to be Adapted for Cardiology Year 1 Patient Information Reconciliation Unknown patients and unscheduled orders Scheduled Workflow Admit, order, schedule, acquire images, notify of completed steps

March, 2004IHE Cardiology Technical Committee4 A Review of “Normal” Workflow Processes Topics:Topics: –HL7 Actors and Transactions in IHE –DICOM Actors and Transactions –Normal Workflow Processes –Patient and Order Update Processes –Patient Information Reconciliation –Summary

March, 2004IHE Cardiology Technical Committee5 HL7 Actors in Workflow HL7 Actors: ADT/Patient RegistrationADT/Patient Registration Order PlacerOrder Placer DSS / Order FillerDSS / Order Filler Image ManagerImage Manager

March, 2004IHE Cardiology Technical Committee6 ADT Actor

March, 2004IHE Cardiology Technical Committee7 ADT Actor Patient Registration transaction4.1 - Patient Registration transaction –Send Admit: A01 (In Patient), A04 (Out Patient), A05 (Pre- Admission)Admit: A01 (In Patient), A04 (Out Patient), A05 (Pre- Admission) Cancel: A11 (Cancel Admit), A38 (Cancel Preadmit)Cancel: A11 (Cancel Admit), A38 (Cancel Preadmit)

March, 2004IHE Cardiology Technical Committee8 ADT Actor (cont.) ADT Patient Update transaction ADT Patient Update transaction –Send Transfer: A02 (Patient Transfer)Transfer: A02 (Patient Transfer) Update Patient Class: A03 (Discharge), A06(Outpatient becomes Inpatient), A07 (Inpatient becomes Outpatient)Update Patient Class: A03 (Discharge), A06(Outpatient becomes Inpatient), A07 (Inpatient becomes Outpatient) Update Patient Information: A08 (Update)Update Patient Information: A08 (Update) Merge Patients: A40 (Merge)Merge Patients: A40 (Merge) Cancel: A12 (Cancel Transfer), A13 (Cancel Discharge)Cancel: A12 (Cancel Transfer), A13 (Cancel Discharge)

March, 2004IHE Cardiology Technical Committee9 Order Placer Actor

March, 2004IHE Cardiology Technical Committee10 Order Placer Actor Placer Order Management transaction4.2 - Placer Order Management transaction –Send New Order: ORM/NW (New Order)New Order: ORM/NW (New Order) Cancel: ORM/CA (Cancel Order), ORM/DC (Discontinue)Cancel: ORM/CA (Cancel Order), ORM/DC (Discontinue)

March, 2004IHE Cardiology Technical Committee11 Order Placer Actor (cont.) Patient Registration transaction4.1 - Patient Registration transaction –Receive A01 (In Patient), A04 (Out Patient), A05 (Pre-Admission), A11 (Cancel Admit), A38 (Cancel Preadmit)A01 (In Patient), A04 (Out Patient), A05 (Pre-Admission), A11 (Cancel Admit), A38 (Cancel Preadmit) Patient Update transaction Patient Update transaction –Receive A02 (Patient Transfer), A03 (Discharge), A06(Outpatient becomes Inpatient), A07 (Inpatient becomes Outpatient), A08 (Update), A12 (Cancel Transfer), A13 (Cancel Discharge), A40 (Merge)A02 (Patient Transfer), A03 (Discharge), A06(Outpatient becomes Inpatient), A07 (Inpatient becomes Outpatient), A08 (Update), A12 (Cancel Transfer), A13 (Cancel Discharge), A40 (Merge) Filler Order Management transaction4.3 - Filler Order Management transaction –Receive ORM/SN (New Order), ORM/SC (Status Update), ORM/OC (Cancel Order)ORM/SN (New Order), ORM/SC (Status Update), ORM/OC (Cancel Order)

March, 2004IHE Cardiology Technical Committee12 DSS / Order Filler Actor

March, 2004IHE Cardiology Technical Committee13 Department System Scheduler/Order Filler Actor Placer Filler Management transaction4.3 - Placer Filler Management transaction –Send New Order: ORM/SN (New Order)New Order: ORM/SN (New Order) Order Status: ORM/SC (Status Change)Order Status: ORM/SC (Status Change) Cancel: ORM/OC (Cancel Order)Cancel: ORM/OC (Cancel Order) Procedure Scheduled transaction4.4 - Procedure Scheduled transaction –Send ORM (procedure scheduled)ORM (procedure scheduled) Procedure Updated transaction Procedure Updated transaction –Send ORM (procedure updated)ORM (procedure updated)

March, 2004IHE Cardiology Technical Committee14 DSS/Order Filler Actor (Cont.) Patient Registration transaction4.1 - Patient Registration transaction –Receive A01 (In Patient), A04 (Out Patient), A05 (Pre-Admission), A11 (Cancel Admit), A38 (Cancel Preadmit)A01 (In Patient), A04 (Out Patient), A05 (Pre-Admission), A11 (Cancel Admit), A38 (Cancel Preadmit) Patient Update transaction Patient Update transaction –Receive A02 (Patient Transfer), A03 (Discharge), A06(Outpatient becomes Inpatient), A07 (Inpatient becomes Outpatient), A08 (Update), A12 (Cancel Transfer), A13 (Cancel Discharge), A40 (Merge)A02 (Patient Transfer), A03 (Discharge), A06(Outpatient becomes Inpatient), A07 (Inpatient becomes Outpatient), A08 (Update), A12 (Cancel Transfer), A13 (Cancel Discharge), A40 (Merge) Placer Order Management transaction4.2 - Placer Order Management transaction –Receive ORM/NW (New Order), ORM/CA (Cancel Order), ORM/DC (Discontinue)ORM/NW (New Order), ORM/CA (Cancel Order), ORM/DC (Discontinue)

March, 2004IHE Cardiology Technical Committee15 Administrative Normal Process Flow

March, 2004IHE Cardiology Technical Committee16 Procedure Performance Normal Process Flow

March, 2004IHE Cardiology Technical Committee17 Patient Update Before Order Entry

March, 2004IHE Cardiology Technical Committee18 Patient Update After Order Entry

March, 2004IHE Cardiology Technical Committee19 Patient Update After Procedure Scheduling

March, 2004IHE Cardiology Technical Committee20 Order Replacement By the Order Placer

March, 2004IHE Cardiology Technical Committee21 Order Replacement By the DSS/Order Filler

March, 2004IHE Cardiology Technical Committee22 Image Information Management Defined to facilitate communication between IS, PACS and Modality productsDefined to facilitate communication between IS, PACS and Modality products DICOM services in use are:DICOM services in use are: –Modality Worklist Management (MWL) –Modality Performed Procedure Step (PPS) –Storage –Storage Commitment –Query/Retrieve

March, 2004IHE Cardiology Technical Committee IHE Scheduled Workflow Concepts PROCEDURE STEP : The smallest unit of work in the workflow: Scheduled Procedure Step: ‘A unit of work to do’ Performed Procedure Step: ‘A unit of work done’ PROCEDURE STEP : The smallest unit of work in the workflow: Scheduled Procedure Step: ‘A unit of work to do’ Performed Procedure Step: ‘A unit of work done’ IHE has addressed this and other workflow processes by selecting three UNAMBIGUOUS TERMS : IHE has addressed this and other workflow processes by selecting three UNAMBIGUOUS HL7/DICOM TERMS : ORDER : A request for healthcare service ORDER : A request for healthcare service REQUESTED PROCEDURE : Units of work resulting in one Report with associated codified, billable acts

March, 2004IHE Cardiology Technical Committee IHE Radiology Addressed this Problem This 3 level workflow structuring concept is user oriented: ORDER: A request for imaging service (Accession Number) REQUESTED PROCEDURE : Units of work resulting in one Report with associated codified, billable acts (Requested Procedure ID) PROCEDURE STEP : The smallest unit of work in the workflow (modality worklist entry) CLINICIAN OR REFERING DOC: The Imaging Dept Customer RADIOLOGIST : In Charge of producing the Report the Report TECHNOLOGIST (and RADIOLOGIST) In charge of acquiring images, etc.

March, 2004IHE Cardiology Technical Committee25 Issues in Adaptation to Cardiology Ordering clinician is often also performing clinicianOrdering clinician is often also performing clinician Multi-modality, with same personnel operating all modalitiesMulti-modality, with same personnel operating all modalities Mandatory pre-procedure and post- procedure activitiesMandatory pre-procedure and post- procedure activities

March, 2004IHE Cardiology Technical Committee Normal Workflow Typical workflow: One Order – One Procedure – One Report ORDER A request for Radiologic Service Requested Procedure Radiology Department One or more series of images Report Set of Codifiable, Billable, Acts Acquisition Modality

March, 2004IHE Cardiology Technical Committee Acquisition Modality Multiple Modality Steps ORDER A request for Radiologic Service Radiology Department Set of Codifiable, Billable, Acts One or more series of images Performed Procedure Step P1 Scheduled Procedure Step B Requested Procedure 1 Scheduled Procedure Step A Report One or more series of images Performed Procedure Step P1 DICOM Modality Worklist

March, 2004IHE Cardiology Technical Committee28 Actors and Transactions Department System Scheduler / Order Filler Image Manager Performed Procedure Step Manager Acquisition Modality Modality Worklist Provided 5 Storage Commitment 10 Modality Images Stored 8 Image Display Image Archive Mod. Procedure Step In-Progress /Completed 6 7 Modality/Creator. Procedure Step In-Progress /Completed Modality/Creator. Procedure Step In-Progress /Completed Retrieve Images 16 Query Images 14

March, 2004IHE Cardiology Technical Committee29 Modality Worklist

March, 2004IHE Cardiology Technical Committee30 MWL Actors and Transaction Department System Scheduler / Order Filler Image Manager Performed Procedure Step Manager Acquisition Modality Modality Worklist Provided 5 Image Display Image Archive

March, 2004IHE Cardiology Technical Committee31 Modality Worklist MWL enables modality integration with information system’s managed dataMWL enables modality integration with information system’s managed data Prepare imaging procedure by including patient, scheduling and medical data (i.e. Patient Name/ID, procedure date/time, procedure codes, Accession Number, Requested Procedure ID.…)Prepare imaging procedure by including patient, scheduling and medical data (i.e. Patient Name/ID, procedure date/time, procedure codes, Accession Number, Requested Procedure ID.…) Avoids typing errors by fixing data entry problems at the source of image creationAvoids typing errors by fixing data entry problems at the source of image creation MWL is a “one way trip” (i.e. IS to Modality)MWL is a “one way trip” (i.e. IS to Modality) Not only to include HIS/RIS Data in DICOM Images, but to enable the workflow: “acquisition work to do” Not only to include HIS/RIS Data in DICOM Images, but to enable the workflow: “acquisition work to do”

March, 2004IHE Cardiology Technical Committee32 C-FIND-RQ (with matching and return keys) C-FIND-RSP (one per match plus final response) Modality DSS/ Order Filler Modality Worklist Explicit definition of required matching and return keys for the DSS and Modality.Explicit definition of required matching and return keys for the DSS and Modality. –what the modality may use to filter the response/what the DSS has to match on –what the modality can ask DSS to return (for display in MWL)/what the DSS shall be able to return

March, 2004IHE Cardiology Technical Committee33 Performed Procedure Step

March, 2004IHE Cardiology Technical Committee34 PPS Actors and Transactions Department System Scheduler / Order Filler Image Manager Performed Procedure Step Manager Acquisition Modality Image Display Image Archive Mod. Procedure Step In-Progress /Completed 6 7 Modality/Creator. Procedure Step In-Progress /Completed Modality/Creator. Procedure Step In-Progress /Completed

March, 2004IHE Cardiology Technical Committee35 Performed Procedure Step Applies to ModalityApplies to Modality Convey details about procedure step(s) performedConvey details about procedure step(s) performed Conveys detailed statuses such as “in progress”, “completed” and “discontinued”Conveys detailed statuses such as “in progress”, “completed” and “discontinued” Provides “return trip” feedback such as:Provides “return trip” feedback such as: –Scheduled information obtained via MWL –What, when, and how was the procedure performed –Accession Number, Patient Name/ID, procedure step codes –List of images acquired/created, Study Instance UID …. Not only tells that the performed step is complete, But closes the workflow: “acquisition/creation work done” Not only tells that the performed step is complete, But closes the workflow: “acquisition/creation work done”

Images Stored

March, 2004IHE Cardiology Technical Committee37 Images Stored Actors and Transactions Department System Scheduler / Order Filler Image Manager Performed Procedure Step Manager Acquisition Modality Modality Images Stored 8 Image Display Image Archive

March, 2004IHE Cardiology Technical Committee38 Images Stored Applies to Modality and Image Creator Scheduled Procedure Step and Requested Procedure information is recorded. C-STORE (Images Stored) Modality or Image Creator Image Archive

March, 2004IHE Cardiology Technical Committee39 Storage Commitment

March, 2004IHE Cardiology Technical Committee40 Storage Commitment Actors and Transactions Department System Scheduler / Order Filler Image Manager Performed Procedure Step Manager Acquisition Modality Storage Commitment 10 Image Display Image Archive

March, 2004IHE Cardiology Technical Committee41 Storage Commitment Modalities obtain explicit agreement from a storage device (i.e. archive, etc.) that images (and other objects) will be reliably storedModalities obtain explicit agreement from a storage device (i.e. archive, etc.) that images (and other objects) will be reliably stored The duration of storage is defined by the storage device productThe duration of storage is defined by the storage device product Facilitates automated or simplified deletion of images on modalities, workstations, etc.Facilitates automated or simplified deletion of images on modalities, workstations, etc. Avoids accidental deletion of images on modalities and workstations

March, 2004IHE Cardiology Technical Committee42 C-STORE operations …. N-ACTION - (list of referenced image UIDs) N-EVENT-REPORT - (success or failure) Image Manager Storage Commit. - Push Model Images (or objects) are pushed to storage deviceImages (or objects) are pushed to storage device N-ACTION provides a list of UIDs for objects to be reliably stored (may be different AE than storage)N-ACTION provides a list of UIDs for objects to be reliably stored (may be different AE than storage) N-EVENT-REPORT confirmation from Storage to ModalityN-EVENT-REPORT confirmation from Storage to Modality Implementations must design for transactions being on multiple associationsImplementations must design for transactions being on multiple associations When N-EVENT-REPORT is sent by Storage Device is product dependent and may be hours after N- ACTIONWhen N-EVENT-REPORT is sent by Storage Device is product dependent and may be hours after N- ACTION Modality or Image Creator

March, 2004IHE Cardiology Technical Committee43 Image Query/Retrieve

March, 2004IHE Cardiology Technical Committee44 Department System Scheduler / Order Filler Image Manager Performed Procedure Step Manager Acquisition Modality Image Display Image Archive Retrieve Images 16 Query Images 14 Query/Retrieve Actors and Transaction

March, 2004IHE Cardiology Technical Committee45 Query Retrieve of Images Defines Matching keys for response filtering by Image ArchiveDefines Matching keys for response filtering by Image Archive Defines Return keys to be requested by Image DisplayDefines Return keys to be requested by Image Display Defines Returned attributes by Image Archive in query responsesDefines Returned attributes by Image Archive in query responses Defines Returned attributes required to be displayed on Image DisplayDefines Returned attributes required to be displayed on Image Display C-FIND-RQ (with matching and return keys) C-FIND-RSP (matches with return keys) Image Display Image Archive

March, 2004IHE Cardiology Technical Committee46 IHE Generic Keys for Query Retrieve of: - Images - SR R = Required by DICOM R+ = IHE Requirement to be displayed or entered (SCU), to be returned(SCP)

March, 2004IHE Cardiology Technical Committee47 Image Specific Query Matching and Return Keys

Patient Information Reconciliation

March, 2004IHE Cardiology Technical Committee49 “Trauma Case” Emergency Department PatientEmergency Department Patient No patient identification:No patient identification: –Patient unconscious –Life-threatening situation –Urgent procedure - no time for registration No ordering and/or scheduling of a procedureNo ordering and/or scheduling of a procedure

March, 2004IHE Cardiology Technical Committee50 “Real-World” Scenario The patient is delivered to the department where it is assigned a temporary departmental Patient ID and/or name.The patient is delivered to the department where it is assigned a temporary departmental Patient ID and/or name. The order is then entered by the DSS/Order Filler and with this Patient ID and/or name, the procedure is performed on the Acquisition Modality.The order is then entered by the DSS/Order Filler and with this Patient ID and/or name, the procedure is performed on the Acquisition Modality.

March, 2004IHE Cardiology Technical Committee51 “Real-World” Scenario Image Manager obtains departmental Patient ID from the images or through MPPS.Image Manager obtains departmental Patient ID from the images or through MPPS. DSS/Order Filler sends Order message to the Order Filler.DSS/Order Filler sends Order message to the Order Filler. ADT does not know about departmental Patient IDADT does not know about departmental Patient ID

March, 2004IHE Cardiology Technical Committee52 “Real-World” Scenario When ADT eventually registers or reconciles patient information, it sends messages to all systems.When ADT eventually registers or reconciles patient information, it sends messages to all systems. EACH system has to perform reconciliation of departmental patient record to the one provided by ADT.EACH system has to perform reconciliation of departmental patient record to the one provided by ADT. Multiple points of reconciliation!Multiple points of reconciliation! Even worse when more than one departmentEven worse when more than one department

March, 2004IHE Cardiology Technical Committee53 Current problems Unidentified patient’s information must be properly entered into all systems, both enterprise-wide and departmentalUnidentified patient’s information must be properly entered into all systems, both enterprise-wide and departmental High possibility of error while entering patient information into the systems by handHigh possibility of error while entering patient information into the systems by hand High possibility of mismatch of local information with that provided by ADTHigh possibility of mismatch of local information with that provided by ADT

March, 2004IHE Cardiology Technical Committee54 Current problems - cont’d Each system will have to perform manual merge of initial patient record into one supplied by ADTEach system will have to perform manual merge of initial patient record into one supplied by ADT Multiple points of reconciliation - high risk possibility of data being unsynchronizedMultiple points of reconciliation - high risk possibility of data being unsynchronized High possibility of mismatch of local information with that provided by ADTHigh possibility of mismatch of local information with that provided by ADT

March, 2004IHE Cardiology Technical Committee55 Unidentified Patient Use Cases Local policy calls for ADT to pre-register ER patients (“John Doe”, “Jane Doe”):Local policy calls for ADT to pre-register ER patients (“John Doe”, “Jane Doe”): –Case 1: Unidentified Patient registered at ADT and order is placed at Order Placer. –Case 2: Unidentified Patient registered at ADT and order is placed at DSS/Order Filler. –Case 3: Unidentified Patient registered at ADT but acquisition completed at Modality prior to order.

March, 2004IHE Cardiology Technical Committee56 Unidentified Patient Use Cases Local policy allows departments to register ER patients with Departmental IDs:Local policy allows departments to register ER patients with Departmental IDs: –Case 4: Unidentified Patient assigned temporary Departmental ID and scheduled at DSS/Order Filler. –Case 5: Image Acquisition completed prior to assigning temporary Departmental ID or Order (Patient ID entered at the Modality).

March, 2004IHE Cardiology Technical Committee57 Unidentified Patient - Case 1 ADT Order Placer Image Manager Modality MWLProvided [5] Department System Database/Scheduler/ Order Filler Placer Order Mgmt NewOrder [2] Procedure Scheduled [4] Patient Reconciliation J.Doe ->J.Smith Patient Update [12] Schedule Procedure Images Acquired ModalityProcedure Step Completed [7] Modality Procedure Step Completed [7] RegisterJ.Doe Patient Update [12] Patient Registration [1]

March, 2004IHE Cardiology Technical Committee58 Patient Name/ID Path - Case 1

March, 2004IHE Cardiology Technical Committee59 Unidentified Patient - Case 2 ADT Order Placer Image Manager Modality MWLProvided [5] Department System Database/Scheduler/ Order Filler Filler Order Mgmt New Order[3] Procedure Scheduled [4] Patient Reconciliation J.Doe ->J.Smith Patient Update [12] Schedule Procedure Images Acquired ModalityProcedure Step Completed [7] Modality Procedure Step Completed [7] RegisterJ.Doe Patient Update [12] Patient Registration [1]

March, 2004IHE Cardiology Technical Committee60 Patient Name/ID Path - Case 2

March, 2004IHE Cardiology Technical Committee61 Unidentified Patient - Case 3 ADT Order Placer Image Manager Modality Department System Database/Scheduler/ Order Filler Filler Order Mgmt New Order [3] Procedure Scheduled [4] Patient Reconciliation J.Doe ->J.Smith Patient Update [12] Schedule Procedure Images Acquired ModalityProcedure Step Completed [7] Modality Procedure Step Completed [7] RegisterJ.Doe Patient Update [12] Patient Registration [1]

March, 2004IHE Cardiology Technical Committee62 Patient Name/ID Path - Case 3

March, 2004IHE Cardiology Technical Committee63 Unidentified Patient - Case 4 ADT Order Placer Image Manager Modality MWLProvided [5] Department System Database/Scheduler/ Order Filler Filler Order Mgmt New Order [3] Procedure Scheduled [4] Patient Reconciliation J.Doe ->J.Smith Patient Update [12] Schedule Procedure for J.Doe Images Acquired ModalityProcedure Step Completed [7] Modality Procedure Step Completed [7] RegisterJ.Smith Patient Registration [1]

March, 2004IHE Cardiology Technical Committee64 Patient Name/ID Path - Case 4

March, 2004IHE Cardiology Technical Committee65 Unidentified Patient - Case 5 ADT Order Placer Image Manager Modality Department System Database/Scheduler/ Order Filler Filler Order Mgmt New Order [3] Procedure Scheduled [4] Patient Reconciliation J.Doe ->J.Smith Patient Update [12] Schedule Procedure Images Acquired for J.Doe ModalityProcedure Step Completed [7] Modality Procedure Step Completed [7] RegisterJ.Smith Patient Registration [1]

March, 2004IHE Cardiology Technical Committee66 Patient Name/ID Path - Case 5

March, 2004IHE Cardiology Technical Committee67 System Requirements Participating systems - ADT, Order Placer, Order Filler and Image Manager communicate updates via HL7Participating systems - ADT, Order Placer, Order Filler and Image Manager communicate updates via HL7 All systems must support ADT^A40:All systems must support ADT^A40: –PID-3 field for new Patient ID –MRG-1 field for old Patient ID Data Type for Patient ID must be CXData Type for Patient ID must be CX Assigning Authority must be included with Patient IDAssigning Authority must be included with Patient ID

March, 2004IHE Cardiology Technical Committee68 System Requirements Order Filler and Image Manager may encounter Patient ID without assigning authority conveyed in MPPS via DICOMOrder Filler and Image Manager may encounter Patient ID without assigning authority conveyed in MPPS via DICOM OF and IM will assume assigning authority (configurable, but the same)OF and IM will assume assigning authority (configurable, but the same) OF and IM shall be able to recognize valid Patient IDOF and IM shall be able to recognize valid Patient ID

March, 2004IHE Cardiology Technical Committee69 Policy Requirements Institution shall choose whether pre- registration of ER patients happens at the ADT levelInstitution shall choose whether pre- registration of ER patients happens at the ADT level OF and IM shall be configured to the same assigning authorityOF and IM shall be configured to the same assigning authority Order Filler shall be able to distinguish valid Patient ID from invalid oneOrder Filler shall be able to distinguish valid Patient ID from invalid one In Cases 4 and 5, OF must reconcile patient info before orderingIn Cases 4 and 5, OF must reconcile patient info before ordering