Radiology Image Sharing Roadmap: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
Kevino (talk | contribs)
No edit summary
Kevino (talk | contribs)
Line 36: Line 36:
===DICOM Mechanisms===
===DICOM Mechanisms===


* C-Store  
* '''C-Store'''
** push across a typical network
** push across a typical network


* Retrieve
* '''Retrieve'''
** pull across a network, basically a C-Store invoked by the receiver
** pull across a network, basically a C-Store invoked by the receiver


* Part 10 - Files
* '''Part 10 - Files'''
** almost by definition push, asynchronous
** almost by definition push, asynchronous
** profiled for a large variety of media: CD, DVD, USB, ZIP, Email, FTP
** profiled for a large variety of media: CD, DVD, USB, ZIP, Email, FTP
Line 48: Line 48:
** includes a MIME type
** includes a MIME type


* Supplement 119 - Instance and Frame Level Retrieve  
* '''Supplement 119 - Instance and Frame Level Retrieve'''


* Part 18 - WADO - Web Access to Persistent DICOM Objects
* '''Part 18 - WADO''' - Web Access to Persistent DICOM Objects
** HTTP based pull across the web
** HTTP based pull across the web


* WG-10 Web Services
* '''WG-10 Web Services'''
** NADO - Notification of Availability of DICOM Objects
** NADO - Notification of Availability of DICOM Objects
** QIDO - Query by ID for DICOM Objects
** QIDO - Query by ID for DICOM Objects


* Supplement 118 - Application Hosting
* '''Supplement 118 - Application Hosting'''
** includes mechanisms for accessing objects
** includes mechanisms for accessing objects
** File based or abstract model
** File based or abstract model


* (DICOM Print)
* '''(DICOM Print)'''
** Push to hardcopy
** Push to hardcopy


===Current Image Sharing Profiles ===
===Current Image Sharing Profiles ===

Revision as of 00:13, 1 October 2008

<WARNING: Half-baked sketch follows>

Aspects of Image Sharing

Image Sharing should address Awareness, Selection and Access of image data.

There are different viable approaches to each of those three aspects of sharing.

Awareness

Knowing there are images that might be of use.

  • Sink Approach - depend on systems to push potentially useful images.
  • Notification Approach - depend on systems to tell you about potentially useful images.
  • Query Approach - ask systems what images are available
  • Subscribe Approach - sort of a cross between Query and Notification

Selection

Choosing images to make use of.

  • Query Approach - evaluate/select based on image details returned in the query
  • Notification Approach - see above; trust other system to have selected appropriately
  • Keep-or-Toss Approach - get all potential images, evaluate directly and toss unneeded ones

Access

Getting the images.

  • Sink Approach - see above
  • Pull Approach - retrieve selected images


Different approaches have advantages and disadvantages depending on many factors such as network bandwidth, local storage capacity, image persistence times, immediacy of access needs, quality of image metadata, dependence on new software/systems, configuration/maintenance overhead, security needs, privacy needs, etc., etc., etc.

Do we need to elabourate whether access is direct from the source, or indirect through an intermediary (sync issues)?

Do we need to elabourate whether access is synchronous/immediate, or asynchronous/delayed?

What do we have to work with

DICOM Mechanisms

  • C-Store
    • push across a typical network
  • Retrieve
    • pull across a network, basically a C-Store invoked by the receiver
  • Part 10 - Files
    • almost by definition push, asynchronous
    • profiled for a large variety of media: CD, DVD, USB, ZIP, Email, FTP
    • with/without compression
    • includes a MIME type
  • Supplement 119 - Instance and Frame Level Retrieve
  • Part 18 - WADO - Web Access to Persistent DICOM Objects
    • HTTP based pull across the web
  • WG-10 Web Services
    • NADO - Notification of Availability of DICOM Objects
    • QIDO - Query by ID for DICOM Objects
  • Supplement 118 - Application Hosting
    • includes mechanisms for accessing objects
    • File based or abstract model
  • (DICOM Print)
    • Push to hardcopy

Current Image Sharing Profiles

Grouped by primary intended application. Other applications are likely possible, but this reflects design intentions.

  • Local Network Push
    • SWF - Scheduled Workflow
    • PIR
    • Content: NM Image, Mammo Image, (Enhanced DICOM)
  • Local Network Pull
    • ARI - Access to Radiology Information
      • Basically DICOM Query/Retrieve
  • Media-based push
    • PDI - Portable Data for Imaging
      • Store images onto media
    • IRWF - Import Reconciliation Workflow
      • Import images from media (and "integrate" into local databases)
  • Regional Federated Network Pull
    • XDS-I - XDS for Imaging
      • Consumer pulls from Source based on manifest pushed to "public" repository;
  • Image Routing based on tags
    • TCE - Teaching Files and Clinical Trials
  • Other Referencing
    • KIN
    • CPI, PGP
    • Image Fusion

What are we trying to accomplish

Scenarios/Use Cases

Observed Needs/Failures