Query Techniques for Accessing Imaging Information

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

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

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

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:http:/medical.nema.org/DICOM/

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

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

12. Some Terms to Know • 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

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

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

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 • (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

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

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

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

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

24. CR Study – 2 Series/5 images • Study Instance UID = 1.2.840.111111.111111

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 • 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

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

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

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 DICOMGateway GetrequestedInfo QueryRequest Database 3D Reconstruction Workstation DICOM Q/R Process RetrieveRequest Getimages SendingImages Images

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

40. DICOM Query/Retrieve Services • The complete cycle consists of 3 Services defined in the DICOM Standard:

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 CheckDatabase 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. DICOMGateway GetrequestedInfo QueryRequest Database 3D Reconstruction Workstation DICOM Q/R Process RetrieveRequest Getimages SendingImages Images

46. Study Level keys for Query/Retrieve

47. Choosing the Appropriate Key

48. Sample Query Screen

49. Query by Name Example

50. Query by Accession Number