Exchanging Imaging Data

1. Exchanging Imaging Data Cor Loef

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 as 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. Multiframeobjects: 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, 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); stored 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? Push, Pulling Objects (Storage SOP Classes), Finding Objects (Information model/FIND) and Retrieving Objects (Move/Get)

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

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

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

17. Query/Retrieve Service class: • Simple Query, NOT a full SQL: • Query: Perform basic image information queries using small set of common key attributes (“FIND”) • Retrieve: Either from remote AE (“GET”), or Xfer from one AE to the other (“MOVE”) • Note: “GET” rarely supported • Extended with 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 performs a match of all the keys specified in the identifier of the request against the information it has, depending on level specified (Patient, Study, Series, Image) • SCP provides Response for each match with values of all key fields and requested, known attributes • Can also Cancel if needed

22. Query/Retrieve Service class: Q/R SOP Classes use: • C-Move: • Upon providing unique key values by the SCU, the SCP initiates C-Store for the SOP instances indicated. SCP becomes SCU for Store; requires separate Association • C-Move responses with status pending can be issued till all the C-Stores are completed or after each Store (see conf statement) • Can also issue Cancel at any time

23. Protocols, Files, Storage • Protocols: • DICOM is a communication standard defining the protocol (PDU, TCP/IP, addressing: port #, AE title) • Files: • DICOM ALSO defines a standard for exchanging files on media: encapsulated with “group 2” also known as Part-10 files • Media includes CD, DVD, flash media • The part-10 file format is extended for exchange using emails (WADO)

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

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: • Storage: • DICOM does NOT define how to archive images (there is NO archive standard) • Some vendors preserve the images in a DICOM format, some pre-process the 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, and exchanged using 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