1. Query Techniques for Accessing Imaging Information

2. Session Information Session #: 754
Title: Query Techniques for Accessing Imaging Information
Date/Time: August 11, 2010 – 1:30 – 3:00
If this is not the session you signed up for, you are in the wrong room

3. Presented by Roy Seabolt VA VistA Imaging Team Harris Corporation
Silver Spring, MD

4. Introduction Presenter Background
Over 25 years of varied IT experience
Commercial Healthcare IT since 1996
VA Healthcare since 2009
Medical Imaging specialties include
Business Analysts (Patch 66 and Patch 116)
DICOM and HL7
Workflow Analysis and Redesign

5. Disclaimer
It should be noted that I am a contractor for the Department of Veterans Affairs and any mention of 3rd party products in this presentation is purely for reference purposes and in no way should be considered an endorsement of that product.
Contents may not necessarily reflective of VA policy.

6. Session Outline Uses of clinical image information
Building image access into workflow
How medical information standards improve image availability
Building effective queries
The future: cross-agency interoperability

7. Session Objectives At the end of this session:
Identify the clinicians and administrators who need to retrieve image information
Distinguish at least 3 purposes for using archived images
Explain the characteristics of VistA Imaging Query/Retrieve
Choose appropriate attributes for image identification
Build fast, effective queries for retrieving images
Target audience: VistA Imaging coordinators, CACs and CIS staff
When preparing this presentation, this is where I put my focus – meeting the learning objectives

8. DICOM What is DICOM? Digital Imaging & Communications in Medicine
Dictionary.com

9. Purpose of DICOM?
To facilitate communication between various imaging modalities and other components
The standard to allow a common set of rules and protocols between vendors in the Medicine field, specifically radiology (imaging)
Predecessor to the DICOM standard was ACR-NEMA 2.0
Introduced in 1993 at RSNA
Most widely adopted standard in use in the medical imaging field
DICOM Standard available at:
Has expanded beyond radiology to other fields (dental, opthamology)

10. Parts of the DICOM Standard
Introduction and Overview
Conformance
Information Object Definitions
Service Class Specifications
Data Structures and Encoding
Data Dictionary
Message Exchange
Network Message Support for Message Exchange
Medical Storage and File Format for Media Interchange
18 parts to the DICOM Standard – 100’s of page, 2008 standard, 2009 standard

11. Parts of the DICOM Standard
Media Storage Application Profiles
Media Formats and Physical Media for Media Interchange
Print Management Point-to-Point Communications Support
Grayscale Standard Display Function
Security Profiles
Content Mapping Resource
Explanatory Information
Web Access to DICOM Persistent Objects
Additional Supplements continuously added to the base as needed

12. Some Terms to Know cPACS – Commercial PACS
PACS – Picture Archival and Communication System. System designed to store and retrieve a patient’s medical Images. Historically Radiology-centered.
cPACS – Commercial PACS
Mini-PACS – Specialized PACS
Modality – an image capture/processing device that complies with the DICOM Standard.
DICOM Q/R – DICOM Query/Retrieve
DICOM Q/R – this is different from a traditional database Q/R

13. Some Terms to Know
Attribute tag: A unique identifier for an Attribute of an Information Object composed of an ordered pair of numbers (a Group Number followed by an Element number).
Message – Describes Command and Data Sets. The data sets generally contains the demographic header and assigned image(s).
Object – single file, multiple parts

14. Common Acronyms in DICOM
AET - Application Entity Title
DIMSE – DIcom Message Service Element
SCP – Service Class Provider
SCU – Service Class User
UID – Unique Identifier
Study Instance UID
Series Instance UID
SOP Instance UID
DIMSE – Messaging protocol
3 UID’s within a DICOM Object

15. DICOM Information Objects
Image – Original DICOM Object
Other Objects
Encapsulated PDF Files
Structured Reports
Radiation Therapy Plans
Waveform Files

16. DICOM Objects DICOM Images are a Composite Format
Image data of the actual picture (pixels)
A “Header” area at the beginning containing DICOM elements
Patient Identifying information
Exam information (Accession number, study date)
Image information (geometry, attributes)

17. DICOM Object Definitions
Each type of DICOM object:
Has a unique identifier (SOP Class UID)
Is composed of elements
Each element has a specific definition
Type 1 fields = Required
Type 2 fields = Required (must be present, but may be empty)
Type 3 fields – Optional
Tags (Elements)
Public Tags
Private Tags

18. DICOM Elements
Group/Element – Unique address representing each unit of information stored in the message header
Each Group - represents a type of information
Patient
General Study
Series
Image

19. DICOM Modules Patient Module
(0x ,PN,“PATIENT^Name") # Patient's Name
(0x ,LO,"5MR2") # Patient ID
(0x ,DA," ") # Patient's Birth Date
(0x ,CS,"M ") # Patient's Sex
(0x ,DS,"70") # Patient's Weight

20. DICOM Modules Series Module (0x00185100,CS,"HFS ") # Patient Position
(0x D,UI," ") # Study Instance UID
(0x E,UI," ") # Series Instance UID
(0x ,SH,"5MR2") # Study ID
(0x ,IS,"1 ") # Series Number
(0x ,IS,"13") # Acquisition Number
(0x ,IS,"5 ") # Instance Number

21. DICOM Modules Image Module (0x00280002,US,0x0001) # Samples per Pixel
(0x ,CS,"MONOCHROME2 ") # Photometric Interpretation
(0x ,US,0x0400) # Rows
(0x ,US,0x0400) # Columns
(0x ,DS," ","  ") # Pixel Spacing
(0x ,US,0x0010) # Bits Allocated
(0x ,US,0x000C) # Bits Stored
(0x ,US,0x000B) # High Bit
(0x ,US,0x0000) # Pixel Representation
(0x ,DS,"1000") # Window Center
(0x ,DS,"2000") # Window Width

22. Instance UIDs (Unique Identifiers)
Every single image contains all three of these Instance UIDs.
The Instance UIDs are the key to the relationship
each Image within a Series and
each Series within a Study
The Study UID should be generated by the VI Text Gateway (will contain the VI root of )
Series and Image are generated by the modality vendor (or creator of the object).
Study Instance UID
Series Instance UID
Image Instance UID

23. Sample UID’s
Study (Study root - FDA) [HIS/RIS] xxxxxx.xxxx.x.xxx
Series Instance UID (modality) xxxxxx.xxxxxx.xxxxx
SOP Instance UID (modality/unique) xxxxxx.xxxxxx.xxxxxx.xxx

24. CR Study – 2 Series/5 images
Study Instance UID = #
Series Instance UID
Study Instance UID 1 2 3 4 5

25. Why is this important? Each DICOM Object stands alone
Database stores list of studies and pointers to DICOM Objects on the file system
DICOM Objects are not stored in database
Allows processing against the object independent of a database
Allows DIMSE communication on individual objects
Object definition travels with the object (copy)

26. DICOM – Validation Types of Validation VA Approved List
DICOM Modality Worklist
Image (object) Storage
Workstation – Query/Retrieve (NEW)
VA Approved List

27. DICOM Conformance Statements
Vendor DICOM Conformance Statement
Which DICOM operations vendor supports
How they support them
VistA Imaging DCS
Which DICOM operations VistA Imaging supports
How VistA Imaging supports them

28. Purpose of Modality Validation
Verify that vendor:
Performs DICOM operations based on what is stated in their DCS
Creates valid DICOM Objects (EPDF’s)
Verify that VistA Imaging:
Can communicate with modality device
Can perform necessary DICOM commands

29. Purpose of Q/R Validation
Verify that vendor:
Performs DICOM operations based on what is stated in their DCS
Vendor properly supports Query/Retrieve commands and can communicate with VistA Imaging PACS
Creates valid DICOM Objects (3D reconstruction)

30. What is DICOM Query/Retrieve?
Query/Retrieve is:
a mechanism used by DICOM Compliant medical devices to find
and retrieve studies (DICOM Objects) from another medical device containing the desired information using the protocols defined in the DICOM Standard

31. What can DICOM Q/R pull?
DICOM Q/R can access any supported DICOM object
DICOM (YES)
Non-DICOM (NO)
MRIs
Rich Text Reports US
Scanned Documents
CTs
Patient Photo’s
Dental Images
Digital Camera pictures
Ophthalmic Images
X-Rays
DICOM (NO)
Encapsulated PDF’s
Unsupported SOP Classes

32. Who would use DICOM Q/R?
Who would use DICOM Q/R to access DICOM Objects:
VistA Imaging Coordinators
CACs
CIS
Rad Techs (mammo’s, 3D workstations, CAD)
Cardiologist and other specialists
Mini-PACS users (US, dental)
cPACS users
File Room (ROI Request)

33. How Q/R improves Patient Care
Q/R from any facility/any 3rd party device
VA Minneapolis (Tour of duty)
Army
Germany
VA Palo Alto
(Training)
VA Richmond
Polytrama
Palo Alto – Basic Training – Injury - cPACS
Minneapolis – 1st Tour of Duty – Injury – VistA Imaging
Germany/Iraq – 2nd Tour of Duty – Injury  Richmond – Specialist mini-PACS
Tampa – Post trauma caregiver (parents) – 3D Reconstruction workstation
Pre-PACS and Post PACS workflow (data sharing)
San Antonio
Army
Austin
VA Tampa (Caregiver))
VA Medical Center
DoD Medical Treatment Facility

34. Examples of Q/R use
A Q/R User can be any device that supports standard DICOM Query and Retrieve Request functionality
DICOM objects can be sent to any device that supports Storage Server functionality
Some devices that support the above:
3D reconstruction workstations
Orthopedic Template workstations
Digital Mammo modalities
cPAC and mini-PACS

35. Traditional Database Query
Single user, single database, single storage system
SQL Database
SELECT <ALL> FROM <Name of data source> WHERE <Criteria> = <Value>
SELECT <ALL> FROM Orders where <Accession Number> = < >

36. Traditional Database Query
SQL Database
Single database
Single storage system
SQL Query
SELECT <ALL> FROM <Source> WHERE <field name> = <Criteria>
SELECT <ALL> FROM <Orders> WHERE <Accession_Nbr> =

37. DICOM Query Retrieve Machine to machine interface
User control over Study selection
Real-time data retrieval
Uses messages and commands based on the DICOM Standard to execute request

38. DICOM Q/R Retrieve Multi-step process
Query Master database
Retrieve from multiple data stores
Uses DICOM Services (messages) to execute
C-FIND
C-MOVE
C-STORE
DICOM Gateway
Get requested Info
Query Request
Database
3D Reconstruction Workstation
DICOM Q/R Process
Retrieve Request
Get images
Sending Images
Images

39. Send DICOM Message SCU SCP Associate-Request Associate-Accept Message
Release-Request
Release-Response

40. DICOM Query/Retrieve Services
The complete cycle consists of 3 Services defined in the DICOM Standard:
Function
Service
Role
Query
C-FIND
SCU
Retrieve
C-MOVE
SCU/SCP
C-Store
SCP

41. DICOM C-FIND Service
C-Find - implements an SCU role using the C-FIND message service.
this is a very simple operation rather akin to a SQL query, whereby a dataset is passed from the SCU to the SCP containing 2 sorts of attribute:
Those which need to be matched
Those to be returned to the SCU
The SCP responds by sending a number of matching datasets, followed by a "complete" response to say that it has finished.
Response list is returned of all studies meeting QUERY criteria
Patient Name
Patient ID
Study Accession Number
Study Instance UID

42. Q/R C-Find Request Example
A 3D Reconstruction Workstation is playing the role of the Query Requestor.
The User at the 3D workstation plans to build a 3D reconstruction image of a CT study.
The User must first query VistA to see if the CT study is available.
The User performs a Query Request to VistA from the 3D workstation.
The User receives a response list containing the desired CT study. The User now knows the CT study is available on VistA.
Query
3D Reconstruction Workstation
DICOM Q/R Process
Check Database
Database
Response List

43. DICOM C-Move Service
C-Move – This requests the C-MOVE SCP to act as a C-STORE SCU and to copy composite instance to a requested AET using the C-Move message service.
It sends query keys (Study Instance UID) to an SCP and awaits responses.
It will accept associations for the purpose of receiving images sent as a result of the C-MOVE request. Note that the use of the term "move" is a misnomer. The C-MOVE operation actually performs an image copy (no images will be deleted from the SCP)
SCP can be anywhere in the network

44. DICOM C-Store Serve
C-Store - The most basic DICOM operation, otherwise known as "DICOM Push" allows an SCU to send a Composite Instance to an SCP.
it is used to send images from a modality to PACS
or create the delivery mechanism for C-MOVE - Store selected DICOM Objects from the initial DICOM Query request
Writes the DICOM Object to storage

45. Q/R C-Move/C-Store Retrieve Example
The 3D Reconstruction Workstation is taking the role of the Move Requestor and Storage Server.
The User knows the study is available on VistA.
The User selects the study and indicates that the images should be sent from VistA to the 3D workstation (This is a Move Request).
The DICOM Gateway retrieves the images for the CT study and sends each image to the 3D workstation. Sending of images continues until the complete CT study is sent to the 3D workstation.
The User may now perform the 3D reconstruction.
DICOM Gateway
Get requested Info
Query Request
Database
3D Reconstruction Workstation
DICOM Q/R Process
Retrieve Request
Get images
Sending Images
Images

46. Study Level keys for Query/Retrieve
Description
Matching Type
Tag
Query/Retrieve Level (“STUDY”)
(0008,0052)
Study Date R
(0008,0020)
Study Time
(0008,0030)
Study ID
(0020,0010)
Patient's Name
(0010,0010)
Patient ID
(0010,0020)
Accession Number
(0008,0050)
Study Instance UID
UNIQUE
(0020,000D)
Modalities in Study O
(0008,0061)
Referring Physician’s Name
(0008,0090)
Study Description
(0008,1030)

47. Choosing the Appropriate Key
Description
Matching Type
Key
Query/Retrieve Level (“STUDY”)
N/A
Study Date R
Poor
Study Time
Study ID
Good
Patient's Name
Patient ID
Excellent
Accession Number
Study Instance UID
UNIQUE
Modalities in Study O
Referring Physician’s Name
Study Description

48. Sample Query Screen

49. Query by Name Example

50. Query by Accession Number

51. Status Screen Example - Active

52. Status Screen Example - Pending

53. Q/R Pending – Possible Reasons
Images offline
Platter not online
Archived images, need to mount media
Pending – Timeout
Media not mounted in a timely manner

54. Q/R Failures Device not configured: Study not found (images lost)
On Server (SCU_List.DIC)
On Client
Study not found (images lost)
Duplicate Study Instance UID’s

55. DICOM Q/R Specifics DICOM Objects Only Supported SOP Classes Only
Study/Root Level Queries Only
Single Study at a time
Does not support:
Patient Level Retrieval
Series Level Retrieval
Must be configured on Server (GW) and Client

56. Moving studies in VistA Imaging
Manual Send from DICOM Gateway (Known as the “Manual PUSH” model)
Clinical user request a Technical user to send study to DICOM destination
Technical user enters the study into the DICOM Gateway
The DICOM gateway pulls the DICOM objects from the server and builds a queue of DICOM files
The DICOM Gateway sends the objects to the DICOM destination
Technical user notifies Clinical user – study ready
Clinical user views study at DICOM destination

57. Moving studies in VistA Imaging
Routing Processor on the DICOM Gateway (Known as the “Automatic PUSH” model)
DICOM objects are received at the DICOM gateway through normal daily operations
DICOM Gateway is configured to identify qualifying studies required by other DICOM destinations
DICOM Gateway automatically sends qualifying studies to qualified DICOM destination

58. DICOM Query Retrieve Machine to machine interface
User control over Study selection
Real-time data retrieval
Study Level Retrieve Only
DICOM Gateway
Get requested Info
Query Request
Database
3D Reconstruction Workstation
DICOM Q/R Process
Retrieve Request
Get images
Sending Images
Images

59. Key Functional Differences
Manual Send Vs. Query/Retrieve
MS: Requires more than one person to complete the process
Q/R: Only the Clinical user is needed to complete the process
Routing Process Vs. Query/Retrieve
RP: Generates significant network traffic
QR: Only generates necessary network traffic
RP: Can only send when DICOM object is initially received
Q/R: Can send DICOM objects anytime
Q/R – Increased Flexibility
Defined by a Standard followed by most medical devices

60. Q/R - Security Query/Retrieve uses multiple levels of security
Standard Access and Verify code for communication with VistA
Secondary menu decides which users are allowed to use Query/Retrieve
Table with list of devices that may perform queries
Table with list of devices that may receive images
 If the user (study requester) does not have valid Access/Verify codes, the application will shutdown. It will not listen for Query or Retrieve requests.
HIPAA
Log kept of connections receiving images
VistA has no knowledge of who may view images on receiving system or where they may travel. Thus, the VA requires agreement between sites

61. Query/Retrieve – Security
Patient Safety:
Must have Business Agreements
Must use VPN (outside VA firewall)
No Object Level encryption
Additional workflow protections for sensitive patients

62. Summary The DICOM Standard is a framework
The DICOM Standard is constantly evolving and being updated
DICOM Q/R is part of the DICOM Standard
For DICOM Q/R to work successfully, both the SCP and the SCU must be DICOM compliant

63. Summary DICOM Q/R operates differently than a database SQL query
DICOM Q/R uses 3 DICOM commands
C-FIND
C-MOVE
C-STORE
DICOM Q/R performs at the Study level
DICOM Q/R operates in real-time

64. Summary Devices using DICOM Q/R Rad Techs – CT – 3D Reconstruction
Mammo Techs – MG – Digital Mammo
Mini-PACS– Cardiologists/Dental
cPACS – Sharing information between VistA Imaging and commercial PACS vendor

65. Summary Users of DICOM Q/R File room staff – CD-burning
Rad Techs – CT 3D Reconstruction
Mammo Techs – Digital Mammo
Specialists – Orthopedics/Cardiology
PACS Administrators

66. Summary Query selection criteria are important Study Instance UID
Patient ID
Accession Number

67. Summary DICOM Q/R improves patient care: Operates in real-time
Operates across geographical boundaries
Provides the study data to the caregiver, when they need it, where they need it

68. Upcoming Q/R Events Patch 66 – Release date Patch 116 – In development
Support for Patch 34
Q/R New SOP Classes
Incorporate necessary security logging
Audit logging
Patient Safety logging
Planned release date

69. Questions ?