IHE Eye Care Scheduled Workflow “The Foundation of IHE Eye Care” Donald Van Syckle President, DVS Consulting, Inc. www.dvsconsult.com

Scheduled Workflow Abstract / Scope Backbone of IHE Eye Care Integrates Registration, Ordering, Acquisition Workflow, Image and Evidence Documents and Secure Storage Bridges HL7 and DICOM Standards June, 2006

Scheduled Workflow Value Proposition Preserve Order Continuity “Close the Loop” maintain accession number, manage procedures, avoid confusion with Filler #, Placer #, etc. Improve Patient Demographic Integrity Data entry errors always a problem significant occurrence significant consequences IHE enters once, pass info from system to system June, 2006

Scheduled Workflow Value Proposition Improve Workflow Efficiency Use of Worklists less time spent doing data entry/selection enables semi-automation of setup automatically fill in information into images and evidence documents for data integrity Reliable Storage Storage Commitment fewer lost studies more confidence in results June, 2006

Scheduled Workflow Value Proposition Improve Order Tracking MPPS from Modality to EMR & Image Storage Server more timely feedback of procedures performed more precise feedback (i.e provide codes to identify the actual procedure performed) Reduce Integration Effort at Site Get Vendors on the Same Page Provide Implementation Guidance Pre-test at Connectathon June, 2006

acquisition completed acquisition in-progress acquisition completed Scheduled Workflow Profile Report Repository Registration report Workstation PMS Storage Server Orders Placed Image Manager & Archive Orders Filled Specifies transactions that function to maintain the integrity of patient, image, and order information across systems Integrates modalities with information and imaging systems Biggest Value of IHE Smooth flow of patient, image and order information across systems Status updates of orders Acquisition Modality acquisition completed EMR acquisition in-progress acquisition completed Modality June, 2006

IHE Workflow Concepts IHE has selected three UNAMBIGUOUS HL7/DICOM TERMS : ORDER : A request for eye care service REQUESTED PROCEDURE : A Unit of work resulting in one Report (with associated codified, billable acts) 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’ June, 2006

Workflow Concept Mapping This 3 level workflow structure is user oriented: ORDER: A request for imaging service (Accession Number) Eye Care Physician REQUESTED PROCEDURE : Units of work resulting in one Report with associated codified, billable acts (Requested Procedure ID) Eye Care Physician : In Charge of producing the Report PROCEDURE STEP : The smallest unit of work in the workflow (modality worklist entry) TECHNICIAN (and Physician) In charge of acquiring images, evidence documents, etc. June, 2006

Normal Workflow Typical workflow: One Order – One Procedure – One Report Eye Care Department DICOM Modality Worklist ORDER A request for Eye Care Service Scheduled Procedure Step Acquisition Modality One or more series of images, etc. Performed Procedure Step Set of Codifiable, Billable, Acts Requested Procedure Report June, 2006

Multiple Modality Steps DICOM Modality Worklist Eye Care Department ORDER A request for Eye Care Service Scheduled Procedure Step A Acquisition Modality One or more series of images Performed Procedure Step P1 Report Set of Codifiable, Billable, Acts Requested Procedure 1 DICOM Modality Worklist Scheduled Procedure Step B Acquisition Modality One or more series of images, etc. Performed Procedure Step P2 June, 2006

Scheduled Workflow “Actors & Transactions” ADT/Pt. Registration Order Placer DSS / Order Filler PPS Manager Image Manager / Archive Acquisition Modality Evidence Creator Image Display Acq. Modality (Primary Radiology Data Source) Evidence Creator (Auxiliary Radiology Data Source) Image Manager/Archive (Primary Radiology Data Management) June, 2006

Table shows explicit references to requirements Actors Transactions Optionality Section ADT Patient Registration Patient Registration [RAD-1] R RAD-TF 2: 4.1 Patient Update [RAD-12] RAD-TF 2: 4.12 Order Placer Placer Order Management [RAD-2] RAD-TF 2: 4.2 Filler Order Management [RAD-3] RAD-TF 2: 4.3 Department System Scheduler/ Order Filler Procedure Scheduled [RAD-4] RAD-TF 2: 4.4 Query Modality Worklist [EYECARE-1] EYECARE-TF 2: 4.1 Modality Procedure Step In Progress [RAD-6] RAD-TF 2: 4.6 Modality Procedure Step Completed [RAD-7] RAD-TF 2:4.7 Images Availability Query [RAD-11] O RAD-TF 2: 4.11 Procedure Updated [RAD-13] RAD-TF 2: 4.13 Instance Availability Notification [RAD-49] RAD-TF 3: 4.49 Acquisition Modality Modality Images/Evidence Stored [EYECARE-2] EYECARE-TF 2: 4.2 Storage Commitment [CARD-3] CARD-TF 2: 4.3 Table shows explicit references to requirements Actors are defined Transactions are defined Reference to where the transaction is conveyed Rad-TF 2 4.6 Rad-TF = IHE Radiology 2 – Volume 2 4.6 – Section within Vol. June, 2006

Scheduled Workflow “HL7 Actors & Transactions” ADT/Patient Registration Order Placer DSS / Order Filler Image Manager June, 2006

Process Diagram 1 June, 2006

ADT Actor June, 2006

Scheduled Workflow Standards Used HL7 V2.3.1 Patient Registration – ADT Messages Admit: A01 (In Patient), A04 (Out Patient), A05 (Pre-Admission) Cancel: A11 (Cancel Admit), A38 (Cancel Preadmit) Patient Update – ADT Messages Transfer: A02 (Patient Transfer) Update Patient Class: A03 (Discharge), A06(Outpatient becomes Inpatient), A07 (Inpatient becomes Outpatient) Update Patient Information: A08 (Update) Merge Patients: A40 (Merge) Cancel: A12 (Cancel Transfer), A13 (Cancel Discharge) June, 2006

ADT Message ADT Segments Segment Name Chapter in HL7 2.3.1 MSH Message Header 2 EVN Event Type 3 PID Patient Identification PV1 Patient Visit [ALI] Patient Allergy Information ….. June, 2006

ADT Key Segments PID – Patient Identification PVI – Patient Visit ID, name, sex, birth date, address…. PVI – Patient Visit Specifics about the patient - doctors, billing, admission, discharge… AL1 - Patient Allergy information Contrast allergies, other allergies… Note: there is more information in an ADT message, this slide is just focusing on the key ones for imaging June, 2006

Scheduled Workflow Standards Used HL7 V2.3.1 Order Management – ORM Messages New Order: ORM/NW & ORM/SN (New Order) Order Status: ORM/SC (Status Change) Cancel: ORM/CA, ORM/DC & ORM/OC (Cancel Order) Procedure Details – ORM Messages Scheduled: ORM (Procedure Scheduled) Updated: ORM (Procedure Updated) June, 2006

ORM Message ORM Segments Segment Name Chapter in HL7 2.3.1 MSH Message Header 2 PID Patient Identification 3 PV1 Patient Visit ORC Order Common 4 ORB Order Details ….. June, 2006

Order Key Segments PID – Patient Identification PVI – Patient Visit ID, name, sex, birth date, address…. PVI – Patient Visit Specifics about the patient - doctors, billing, admission, discharge… ORC – Common Order Placer/Filler #s, status, provider, organization… OBR – Order Detail Universal Service ID, Priority, Sch. date/time, reason for study… Note: there is more information in an ORM message, this slide is just focusing on the key ones for eye care June, 2006

Specific or Generic Orders Generic Orders are when the procedure(s) are not known upfront or could also be automatic orders (defined by the clinic) A new patient triggers automatic orders for an auto-refraction device, a lensometer, a keratometer, and fundus photo… But not all may be performed. How do you know? DICOM MPPS Specific orders are used when the procedure(s) to perform are know upon schedule time Maybe after the doctor has meet with the patient When the orders are triggered is often decided by configuration on the Order Filler Patient arrives, based upon the appointment time, ….. This decision is outside of the IHE scope, driven by the clinic policies June, 2006

Example Use Case A new patient calls the clinic and set up an appointment for the future This triggers an A05 Pre-Admission message from the ADT/Pat. Reg. to the Order Placer and Order Filler The Order Placer creates multiple “automatic” orders using an ORM message (one for each possible procedure) to the Order Filler The Order Filler retains this information of “scheduled procedures” June, 2006

Example Use Case (con’t) The patient arrives for the appointment: This triggers an A04 Out-Patient message from the ADT/Pat. Reg. to the Order Placer and Order Filler The Order Placer determines it already has placed the “automatic” orders for this patient and does nothing The Order Filler recognizes the A04 and determines that the “held scheduled procedures” are now available to both the Image Manager (ORM) and Acquisition Modality (MWL) DICOM MPPS is used to specify what actually was performed on the patient (see later in the presentation) This Use Case uses the patient arrival in the clinic to trigger the knowledge of the scheduled procedures Another close example could be trigger by the date of the appointment At the beginning of the day the “scheduled procedure” in known by the system June, 2006

Order Placer is typically a PMS function Receive Patient Registration transactions A01 (In Patient), A04 (Out Patient), A05 (Pre-Admission), A11 (Cancel Admit), A38 (Cancel Pre-admit) Receive Patient Update transaction A02 (Patient Transfer), A03 (Discharge), A06(Outpatient becomes Inpatient), A07 (Inpatient becomes Outpatient), A08 (Update), A12 (Cancel Transfer), A13 (Cancel Discharge), A40 (Merge) Send Placer Order Management transaction New Order: ORM (New Order) Cancel: ORM/CA (Cancel Order), ORM/DC (Discontinue) Receive Filler Order Management transaction ORM (New Order), ORM (Status Update), ORM (Cancel Order) Order Placer is typically a PMS function June, 2006

Typical Order Fillers are department information systems (i.e. EMR) Receive Patient Registration transaction A01 (In Patient), A04 (Out Patient), A05 (Pre-Admission), A11 (Cancel Admit), A38 (Cancel Preadmit) Receive Patient Update transaction A02 (Patient Transfer), A03 (Discharge), A06(Outpatient becomes Inpatient), A07 (Inpatient becomes Outpatient), A08 (Update), A12 (Cancel Transfer), A13 (Cancel Discharge), A40 (Merge) Receive Placer Order Management transaction ORM (New Order), ORM (Cancel Order), ORM (Discontinue) Typical Order Fillers are department information systems (i.e. EMR) June, 2006

Order Filler Send Filler Management transaction New Order: ORM (New Order) Order Status: ORM (Status Change) Cancel: ORM (Cancel Order) Send Procedure Scheduled transaction to PACS ORM (procedure scheduled) Send Procedure Updated transaction ORM (procedure updated) June, 2006

Scheduled Workflow “DICOM Actors & Transactions” DSS / Order Filler PPS Manager Image Manager / Archive Acquisition Modality Evidence Creator Image Display Acq. Modality (Primary Radiology Data Source) Evidence Creator (Auxiliary Radiology Data Source) Image Manager/Archive (Primary Radiology Data Management) June, 2006

Process Diagram 2 June, 2006

Acquisition Workflow Management DICOM: Modality Worklist Management (MWL) Modality Performed Procedure Step (MPPS) June, 2006

DICOM - Imaging Management Data Model Patient Imaging Serv. Req. (Order) Requested Procedure Scheduled Procedure Step 1:n 0:n Scheduling Study Mgt Performed Procedure Step Work Tracking n:m Image Study Series 1:n Work Products June, 2006

DICOM - Service Classes Patient Imaging Serv. Req. (Order) Requested Procedure Scheduled Procedure Step 1:n 0:n 1:1 Modality Worklist Study Mgt Performed Procedure Step Modality Performed Procedure Step Image I-Study Series 1:n n:m Storage Commitment June, 2006

Modality Worklist MWL enables modality (i.e instruments) integration with PMS/EMR managed data Prepare acquisition procedure by including patient, scheduling and procedure data (i.e. Patient Name/ID, procedure date/time, procedure codes, Accession Number.…) Avoids typing errors by fixing data entry problems at the source of DICOM image or evidence creation MWL is a “one way trip” (i.e. PMS/EMR to Modality) Enables DICOM images and evidence documents to automatically include PMS/EMR data June, 2006

Modality Worklist Acquisition Modality DICOM Query “Broad query” to get full patient list List of patient matches and appropriate data EMR Modalities display the list of patients scheduled today Name ID Accession # Procedure Protocol Time Joe Smith 1234-8 678-1236 92135 OCT Disc 8:30am Jane Jones 24689 132001-9 92135 OCT Disc 9:00am Frank Able 978567 94650970 921xx OCT Macula 10:00am …………… …….. ……. ………. ……. ……… June, 2006

Modality Worklist Modalities display information for single patient Acquisition Modality DICOM Query “Patient Specific” to get a single patient A patient match and appropriate data EMR Modalities display information for single patient Name ID Accession # Procedure Protocol Time Joe Smith 1234-8 678-1236 92135 OCT Disc 8:30am June, 2006

IHE Modality Worklist Matching and Return Keys Query Keys Matching Query Keys Return Attribute Name Tag SCU SCP Scheduled Procedure Step Scheduled Procedure Step Sequence (0040,0100) R+ R * >Scheduled Station AE Title (0040,0001) >Scheduled Procedure Step Start Date (0040, 0002) >Scheduled Procedure Step Start Time (0040,0003) O >Modality (0008,0060) >Scheduled Procedure Step ID (0040,0009) >Scheduled Action Item Code Sequence (0040,0008) >>Code Value (0008,0100) >>Coding Scheme Designator (0080,0102) >>Code Meaning (0080,0104) >Scheduled Procedure Step Description (0040,0007) Requested Procedure Requested Procedure Description (0032,1060) Requested Procedure Code Sequen ce (0032,1064) >Code Value >Coding Scheme Designator (0008,0102) >Code Meaning (0008,0104) Requested Procedure ID (0040,1001) Study Instance UID (0020,000D) Referenced Study Se quence (0008,1110) >Referenced SOP Class UID (0008,1150) >Referenced SOP Instance UID (0008,1155) Imaging Service Request Accession Number (0008,0050) Referring Physician's Name (0008,0090) Patient I dentification Patient's Name (0010,0010) Patient ID (0010,0020) Patient Demographic Patients Birth Date (0010,0030) Patient's Sex (0010,0040) IHE Modality Worklist Matching and Return Keys R = Required by DICOM R+ = IHE-2 Requirement to be displayed or entered (SCU), to be returned (SCP) R+’ = IHE-2 Requirement may not be displayed All Required SCP Return keys are not shown (see TF) June, 2006

Minor Extensions for Eye Care Issuer of Patient ID Enhanced MWL to support the attribute Issuer of Patient ID Modalities may have longitudinal data requirements, therefore need to uniquely identify patients visual field analyzers persistently store longitudinal data in order to perform glaucoma progression analysis If the Issuer of Patient ID is a trusted source, it should determine patient identity based on the (Issuer of Patient ID, Patient ID) Without this information, it probably has to rely on information such as patient name and date of birth Patient and Broad Queries Modalities are required to support both the Broad and Patient queries, therefore, leaving the decision to the eye care facility June, 2006

Modality Performed Procedure Step Conveys detailed statuses such as “in progress”, “completed” and “discontinued” Provides “return trip” feedback such as: Scheduled information obtained via MWL Accession Number, Patient Name/ID, scheduled procedure step codes, Study Instanced UID, etc. What, when, and how was the “actual” procedure performed List of all images and/or evidence documents acquired The operator on the modality is required to convey the “actual” procedure performed in MPPS, therefore, enables procedure billing if the Charge Posting Profile is implemented June, 2006

MPPS – Modality Feedback Acquisition Modality The operator: Views worklist, selects patient, confirms protocol or selects actual protocol Acquisition in progress, linked to SPS, etc. Protocol Codes OCT Disc OCT Macula OCT Lesion OCT yyy….. Acquisition is completed, what procedure was performed, list of data created, etc. Closes the loop between what was ordered and what was performed Ends the acquisition EMR Name ID Accession # Procedure Protocol Time Joe Smith 1234-8 678-1236 92135 OCT Disc 8:30am June, 2006

Acquisition Protocol Selection Use of Protocol Codes Modality Pr. Codes Protocols AA …… AB …… FD ……. 5E …… .... ...... Scheduled Procedure Step MWL Requested Proc. Code Description SPS Protocol Codes Description Performed Protocol Codes (AB, FD) PPS Protocol Codes AA & AB suggested Operator changes AA to FD & accepts AB June, 2006

The Concept of Performed Procedure Step Image Patient Imaging Serv. Req. (Order) Requested Procedure Scheduled Procedure Step Study Mgt Performed Procedure Step Study Series ED A PPS is an “Atomic Imaging/Measurements Exam” A PPS Starts and Ends. It is never resumed ! A PPS produces one or more series of images/evidence documents Once a PPS is completed, images/evidence documents cannot be added to a series Additional PPS can always be performed A Study usually holds the work product for a Requested Procedure A Study may be multi-modality (I.e. multiple instruments) June, 2006

Extension for Eye Care Require that the modality be able to select the “actual” procedure/protocol performed Called, Billing and Material Management Feature already defined by the radiology workflow, Eye Care makes it mandatory June, 2006

Image Management DICOM: Image Storage Storage Commitment Query/Retrieve June, 2006

Storage Commitment Transfer ownership of images and/or evidence documents to a secure storage device Allows modalities to manage its local storage Facilitates simplified deletion of data on modalities, workstations, etc. Avoids accidental deletion of data Some people call it “permission to delete” June, 2006

Storage Commitment - Push Model Acquisition Modality DICOM Store images/evidence document Request the list of objects to be safely archived Confirmation that the objects are now owned by the Storage Device Called the “push model” because data is sent to storage system first The storage device must retain the confirmation until it is acknowledge by the modality i.e. it must queue up responses if the modality is temporally not connected to the network The storage device must be able to storage “ALL” the data in the objects June, 2006

DICOM Storage Storage includes both images and evidence documents, currently defined: Ophthalmic 8 and 16 bit Photography Image Storage Ultrasound Image and Multi-frame Storage Stereometric Relationship Storage DICOM Structured Reporting DICOM Encapsulated PDF Others will be supported upon completion into DICOM Modalities, Image Display and Evidence Creators must be able to support at least one of the above objects Image Archives must be able to storage all objects defined June, 2006

Compression Both Lossless and Lossy JPEG required for the images objects Ophthalmic 8 and 16 bit Photography Image Storage Ultrasound Image and Multi-frame Storage Stereometric Relationship Storage Acquisition Modalities must be able to “configure” the compression choices based upon the eye care facility preferences Other compressions and rules may be considered when new DICOM objects are supported June, 2006

Query/Retrieve Extension Query is used by Image Display and Evidence Creators to pull images/evidence documents Added option to request Issuer of Patient ID Added requirement to request the Document Title for Encapsulated PDF Support for Lossless and Lossy JPEG required June, 2006

IHE Generic Keys for Query Retrieve of: - Images - Evid. Doc. - SR R = Required and the SCU shall be able to display R+ = IHE Requirement on top of DICOM June, 2006

More information…. IHE Web site: www.ihe.net Technical Frameworks ihe_eyecare_tf_TI_vol1_2006_06_01 (Trial Implementation version) ihe_eyecare_tf_TI_vol2_2006_06_01 (Trial Implementation version) ihe_tf_rev6.0ft_vol1_2005-05-18-FINAL (Radiology) ihe_tf_rev6.0ft_vol2_2005-05-18-FINAL (Radiology) ihe_CARD_tf_vol2_2.1_FT (Cardiology) Standards used by IHE Eye Care DICOM Standard www.nema.medical.org HL7 Standard www.hl7.org IHE Connectathon Oct. 2006 at RSNA HQ IHE Showcase at Nov. 2006 AAO Conference Vendor Products Integration Statements June, 2006

June, 2006