1 / 51

IHE Eye Care Scheduled Workflow “The Foundation of IHE Eye Care”

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

reuben-waller
Download Presentation

IHE Eye Care Scheduled Workflow “The Foundation of IHE Eye Care”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IHE Eye CareScheduled Workflow“The Foundation ofIHE Eye Care” Donald Van SycklePresident, DVS Consulting, Inc.www.dvsconsult.com

  2. Scheduled WorkflowAbstract / Scope • Backbone of IHE Eye Care • Integrates Registration, Ordering, Acquisition Workflow, Image and Evidence Documents and Secure Storage • Bridges HL7 and DICOM Standards

  3. Scheduled WorkflowValue 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

  4. Scheduled WorkflowValue 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

  5. Scheduled WorkflowValue 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

  6. Scheduled Workflow Profile Registration Report Repository report Workstation Orders Placed Image Manager & Archive AcquisitionModality Orders Filled acquisitioncompleted acquisitionin-progress acquisitioncompleted Modality PMS StorageServer EMR

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

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

  9. DICOMModality Worklist ScheduledProcedure Step One or more series of images, etc. AcquisitionModality PerformedProcedure Step Normal Workflow Typical workflow: One Order – One Procedure – One Report Eye Care Department ORDER A request for Eye CareService Set of Codifiable, Billable, Acts Report Requested Procedure

  10. DICOMModality Worklist ScheduledProcedure Step A Report One or more series of images One or more series of images, etc. ScheduledProcedure Step B AcquisitionModality DICOMModality Worklist PerformedProcedure Step P1 PerformedProcedure Step P2 AcquisitionModality Multiple Modality Steps Eye Care Department ORDER A request for Eye Care Service Set of Codifiable, Billable, Acts Requested Procedure 1

  11. Scheduled Workflow“Actors & Transactions” Actors: • ADT/Pt. Registration • Order Placer • DSS / Order Filler • PPS Manager • Image Manager /Archive • Acquisition Modality • Evidence Creator • Image Display

  12. Actors Transactions Optionality Section ADT Patient Registration Patient Registration [RAD-1] R RAD-TF 2: 4.1 Patient Update [RAD-12] R RAD-TF 2: 4.12 Order Placer Patient Registration [RAD-1] R RAD-TF 2: 4.1 Patient Update [RAD-12] R RAD-TF 2: 4.12 Placer Order Management [RAD-2] R RAD-TF 2: 4.2 Filler Order Management [RAD-3] R RAD-TF 2: 4.3 Department System Scheduler/Order Filler Patient Registration [RAD-1] R RAD-TF 2: 4.1 Patient Update [RAD-12] R RAD-TF 2: 4.12 Placer Order Management [RAD-2] R RAD-TF 2: 4.2 Filler Order Management [RAD-3] R RAD-TF 2: 4.3 Procedure Scheduled [RAD-4] R RAD-TF 2: 4.4 Query Modality Worklist [EYECARE-1] R EYECARE-TF 2: 4.1 Modality Procedure Step In Progress [RAD-6] R RAD-TF 2: 4.6 Modality Procedure Step Completed [RAD-7] R RAD-TF 2:4.7 Images Availability Query [RAD-11] O RAD-TF 2: 4.11 Procedure Updated [RAD-13] R RAD-TF 2: 4.13 Instance Availability Notification [RAD-49] O RAD-TF 3: 4.49 Acquisition Modality Query Modality Worklist [EYECARE-1] R EYECARE-TF 2: 4.1 Modality Procedure Step In Progress [RAD-6] R RAD-TF 2: 4.6 Modality Procedure Step Completed [RAD-7] R RAD-TF 2:4.7 Modality Images/Evidence Stored [EYECARE-2] R EYECARE-TF 2: 4.2 Storage Commitment [CARD-3] R 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.

  13. Scheduled Workflow“HL7 Actors & Transactions” HL7 Actors: • ADT/Patient Registration • Order Placer • DSS / Order Filler • Image Manager

  14. Process Diagram 1

  15. ADT Actor

  16. Scheduled WorkflowStandards 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)

  17. ADT Message

  18. ADT Key Segments • PID – Patient Identification • 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

  19. Scheduled WorkflowStandards 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)

  20. ORM Message

  21. Order Key Segments • PID – Patient Identification • 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

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

  23. 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”

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

  25. Order Placer • 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

  26. Order Filler • 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)

  27. 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)

  28. Scheduled Workflow“DICOM Actors & Transactions” DICOM Actors: • DSS / Order Filler • PPS Manager • Image Manager /Archive • Acquisition Modality • Evidence Creator • Image Display

  29. Process Diagram 2

  30. Acquisition Workflow Management DICOM: • Modality Worklist Management (MWL) • Modality Performed Procedure Step (MPPS)

  31. 0:n Imaging Serv. Req. (Order) 1:n RequestedProcedure Study Study Mgt 1:n ScheduledProcedure Step PerformedProcedure Step n:m 1:n 1:n Series Scheduling Series 1:n Work Tracking Image Image Image Image Work Products Image DICOM - Imaging Management Data Model Patient

  32. 0:n Imaging Serv. Req. (Order) 1:n 1:1 n:m RequestedProcedure I-Study Study Mgt 1:n ScheduledProcedure Step PerformedProcedure Step 1:n 1:n Modality Worklist Series Series Modality PerformedProcedure Step 1:n Image Image StorageCommitment Image Image Image DICOM - Service Classes Patient

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

  34. DICOM Query “Broad query” to get full patient list List of patient matches and appropriate data Acquisition Modality 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 …………… …….. ……. ………. ……. ……… Modality Worklist

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

  36. Attribute Name Tag Query Keys Matching Query Keys Return SCU SCP SCU SCP Scheduled Procedure Step * Scheduled Procedure Step Sequence (0040,0100) R+ R R+ R * >Scheduled Station AE Title (0040,0001) R+ R R+ R >Scheduled Procedure Step Start Date (0040, 0002) R+ R R+ R >Scheduled Procedure Step Start Time (0040,0003) O R R+ R >Modality (0008,0060) R+ R R+ R * >Scheduled Procedure Step ID (0040,0009) O O R+ R * >Scheduled Action Item Code Sequence (0040,0008) O O R+ R * >>Code Value (0008,0100) O O R+ R * >>Coding Scheme Designator (0080,0102) O O R+ R * >>Code Meaning (0080,0104) O O R+ R+ >Scheduled Procedure Step Description (0040,0007) O R+ R O Requested Procedure Requested Procedure Description (0032,1060) O O R+ R * Requested Procedure Code Sequen ce (0032,1064) O O R+ R * >Code Value (0008,0100) O O R+ R * >Coding Scheme Designator (0008,0102) O O R+ R * >Code Meaning (0008,0104) O O R+ R+ Requested Procedure ID (0040,1001) R+ R+ R+ R * Study Instance UID (0020,000D) O O R+ R * Referenced Study Se quence (0008,1110) O O R+ R * >Referenced SOP Class UID (0008,1150) O O R+ R * >Referenced SOP Instance UID (0008,1155) O O R+ R Imaging Service Request Accession Number (0008,0050) R+ R+ R+ R+ Referring Physician's Name (0008,0090) O O R+ R Patient I dentification Patient's Name (0010,0010) R+ R R+ R Patient ID (0010,0020) R+ R R+ R Patient Demographic Patients Birth Date (0010,0030) O O R+ R Patient's Sex (0010,0040) O O R+ R IHEModality WorklistMatching andReturn 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 keysare not shown (see TF)

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

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

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

  40. Modality MWL PPS ScheduledProcedureStep Requested Proc. Code Description SPSProtocol Codes Description Pr. Codes Protocols AA …… AB ……FD …….5E …….... ...... PerformedProtocol Codes(AB, FD) Protocol Codes AA & AB suggestedOperator changes AA to FD & accepts AB Acquisition Protocol Selection Use of Protocol Codes

  41. Patient Imaging Serv. Req. (Order) RequestedProcedure Study Study Mgt ScheduledProcedure Step PerformedProcedure Step Series Series ED Image Image ED Image The Concept of Performed Procedure Step 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)

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

  43. Image Management DICOM: • Image Storage • Storage Commitment • Query/Retrieve

  44. 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”

  45. Acquisition Modality Storage Commitment - Push Model DICOM Store images/evidence document Request the list of objects to be safely archived Storage Device Confirmation that the objects are now owned by the • 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

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

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

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

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

  50. 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 Standardwww.nema.medical.org • HL7 Standardwww.hl7.org • IHEConnectathon Oct. 2006 at RSNA HQ • IHEShowcase at Nov. 2006 AAO Conference • Vendor Products Integration Statements

More Related