Exchanging Imaging Data

1. Exchanging Imaging Data Cor Loef Philips

2. Exchanging Imaging Data • Objective: This presentation will answer the following question: • What are the types of DICOM objects and how do we move them around, i.e. over a network as well as on media?

3. Exchanging Imaging Data • Agenda • Main Classes of Objects: Images, Presentation States, Structured Reports, Encapsulated Objects • Pushing Objects, Pulling Objects, Finding Objects and Retrieving Objects • DICOM: a Protocol vs a File Format vs a product Internal Data Representation • Use of Media: CDs, Memory Sticks, Email, WADO

4. IE’s Modules Attributes Information Object Definition (IOD):

5. Information Object Definition (IOD): • DICOM Composite Objects: • For persistent, “permanent” objects using DIMSE-C commands (C-Store, C-Move, C-Find…) • Multiple IE’s: relate to DICOM Information Model (Patient-Study-Series-Image…) • Cannot be changed or modified, if so, create a new object with new SOP Instance UID

6. Multi-frame Objects: Vector • Ultrasound Multiframe • Nuclear Medicine • XA and RF • New objects: MR, CT, PET, XA-XRF (new), X-Ray 3D, US 3D • VL and Ophthalmology • Any future new objects: NM (new)

7. Structured Reports: • Same structure as Images: • “main body” contains report and/or other information (measurements, etc.) instead of pixels • Same structure for header • Same study information • Modality is “SR” • Has a tree structure

8. SR example (IHE simple report):

9. SR example (Key Image/Object Note KON):

10. Encapsulated Objects (SC and PDF): • Some objects are difficult to encode as “native” objects: • Secondary Capture (SC): • Digitized film, captured video, scanned documents • Encapsulated PDF: • typically for bone scans and eye care (topographic maps)

11. Softcopy Presentation State: • - Present images (almost) identical on softcopy media in standard manner • Separation of Stored Image Instances from Display characteristics and changes • Includes shutters, image annotation, spatial transformation, display annotation

12. Softcopy Presentation State: • Solution: • - Create Composite object containing the presentation state parameters ONLY (no images) • Link this Composite object to one or more images (Series, Images) • Store within same Study; Modality “PR” • - Communicate with regular Storage service (C_Store); Retrieve with Query/Retrieve service

13. How do we move these objects around? Pushing, Pulling Objects (Storage SOP Classes), Finding Objects (Information model/FIND), Retrieving Objects (Move/Get)

14. Information System Printer Modality Archive PACS Display Storage Service class: Modality Push/PACS Push DICOM C-Store

15. Storage Service class: • Transfer composite objects (e.g. images, reports, RT plans, waveforms) from one AE to another • One AE functions as the SCU, the other as SCP • SOP classes use C-Store DIMSE-C service • Information is stored in some medium, accessible for some time (Issue! Might need Storage commitment!)

16. Information System Printer Modality Archive PACS Display Query/Retrieve Service class: Modality Pull/PACS Pull SCU/SCP DICOM C-Find DICOM C-Move

17. Query/Retrieve Service class: • Simple Query, NOT full SQL: • Query: Basic image information query (“FIND”) using small set of common key attributes • Retrieve: Either from remote AE (“GET”), or Xfer from one AE to the other (“MOVE”) • Note: “GET” rarely supported • Extensions allow retrieval of selected frames of a multi-frame

18. Query/Retrieve Service class: Note: Most vendors also support a proprietary, direct protocol SQL database (Informix, Sybase, Oracle) DICOM I/F

19. Query/Retrieve Service class: • Key Attributes: • U: Unique • R: Required • O: Optional Image IOD Pat name Pat ID ---- ---- ---- Keys

20. Keys for FIND:

21. Query/Retrieve Service Class: Q/R SOP Classes use: • C-Find: • SCP matches all keys specified in the request against it’s database • May be at Patient, Study, Series or Image level • SCP provides Response for each match containing values for all keys and all requested, known attributes • Can Cancel if needed

22. Query/Retrieve Service Class: Q/R SOP Classes use: • C-Move: • SCU provides unique key values for needed SOP instances • SCP initiates C-Store(s) as SCU (on a separate Association) • SCP can issue C-Move responses with status pending until all C-Stores are completed or after each Store (see Conformance Statement) • Can issue Cancel at any time

23. Protocols, Files, Storage • Protocols: • DICOM defines a standard communication protocol (PDU, TCP/IP, addressing: port #, AE title) • Files: • DICOM also defines a standard for files on media: “Part-10 files” = meta information + a SOP instance • Media includes CD, DVD, Memory Sticks, etc. • Part-10 file format is also extended for zip files, email, and web access (WADO)

24. DICOM Media: • Meta-file header: • Transfer syntax (encoding) • SOP Class • Who generated it • Compliant with standard OS’s • DICOMDIR required for exchange media • Index/database of files

25. DICOM Media Specifications: DICOM Application Entity Basic Dir. Service / Object Pairs Part 10 DICOM File Format Part 11 Media Formats: e.g. File data structures Physical Media: e.g. CD-R; 90 mm MOD, etc. Part 12

26. Protocols, Files, Storage: • Device Internal Storage: • DICOM defines how images go in/out of device • DICOM does NOT define how to archive images (there is NO archive standard) • Some vendors keep images in DICOM format, some pre-process images using a compression method, either standard or proprietary • Migration of both PACS databases and archives are common when changing releases, vendors, etc.

27. Conclusion: • DICOM objects include: • not only images • but also SR’s, Presentation States, and encapsulated objects • DICOM images are moved around using: • the DICOM protocol • the DICOM Part-10 file definition • There is NO DICOM archiving standard, some archives store “natively”, some do not

28. Thank you! Cor Loef: cor.loef@philips.com www.philips.com