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

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

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

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

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

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

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’
June, 2006

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

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

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

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

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

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

14. Process Diagram 1
June, 2006

15. ADT Actor
June, 2006

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

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

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

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

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

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

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
June, 2006

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”
June, 2006

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
June, 2006

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

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

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)
June, 2006

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

29. Process Diagram 2
June, 2006

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

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

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

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
June, 2006

34. 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 OCT Disc :30am
Jane Jones OCT Disc :00am
Frank Able xx OCT Macula 10:00am
…………… …… …… ……… …… ………
June, 2006

35. 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 OCT Disc 8:30am
June, 2006

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

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
June, 2006

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
June, 2006

39. 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 OCT Disc :30am
June, 2006

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

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

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
June, 2006

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

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”
June, 2006

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

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
June, 2006

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
June, 2006

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
June, 2006

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
June, 2006

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_ FINAL (Radiology)
ihe_tf_rev6.0ft_vol2_ FINAL (Radiology)
ihe_CARD_tf_vol2_2.1_FT (Cardiology)
Standards used by IHE Eye Care
DICOM Standard
HL7 Standard
IHE Connectathon Oct at RSNA HQ
IHE Showcase at Nov AAO Conference
Vendor Products Integration Statements
June, 2006

51. June, 2006