Query Techniques for Accessing Imaging Information

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

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

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

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.

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

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

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

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: http:/medical.nema.org/DICOM/ Has expanded beyond radiology to other fields (dental, opthamology)

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

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

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

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

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

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

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)

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

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

DICOM Modules Patient Module (0x00100010,PN,“PATIENT^Name") # Patient's Name (0x00100020,LO,"5MR2") # Patient ID (0x00100030,DA,"19500112") # Patient's Birth Date (0x00100040,CS,"M ") # Patient's Sex (0x00101030,DS,"70") # Patient's Weight

DICOM Modules Series Module (0x00185100,CS,"HFS ") # Patient Position (0x0020000D,UI,"1.3.6.1.4.1.5962.1.2.5.20040826185059.5457") # Study Instance UID (0x0020000E,UI,"1.3.6.1.4.1.5962.1.3.5.1.20040826185059.5457") # Series Instance UID (0x00200010,SH,"5MR2") # Study ID (0x00200011,IS,"1 ") # Series Number (0x00200012,IS,"13") # Acquisition Number (0x00200013,IS,"5 ") # Instance Number

DICOM Modules Image Module (0x00280002,US,0x0001) # Samples per Pixel (0x00280004,CS,"MONOCHROME2 ") # Photometric Interpretation (0x00280010,US,0x0400) # Rows (0x00280011,US,0x0400) # Columns (0x00280030,DS,"0.195313","0.195313 ") # Pixel Spacing (0x00280100,US,0x0010) # Bits Allocated (0x00280101,US,0x000C) # Bits Stored (0x00280102,US,0x000B) # High Bit (0x00280103,US,0x0000) # Pixel Representation (0x00281050,DS,"1000") # Window Center (0x00281051,DS,"2000") # Window Width

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 1.2.840.113754) Series and Image are generated by the modality vendor (or creator of the object). Study Instance UID Series Instance UID Image Instance UID

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

CR Study – 2 Series/5 images Study Instance UID = 1.2.840.111111.111111 # Series Instance UID Study Instance UID 1 1.2.840.222222.222222.1 1.2.840.333333.333.1 2 3 1.2.840.333333.333.2 1.2.840.333333.333.3 4 1.2.840.222222.222222.2 1.2.840.333333.777.4 5 1.2.840.333333.787.5

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)

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

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

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

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)

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

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

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)

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

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

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> = <061610-999>

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> = 062010-771

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

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

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

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

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

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

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

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

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

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)

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

Sample Query Screen

Query by Name Example

Query by Accession Number

Status Screen Example - Active

Status Screen Example - Pending

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Questions ?