PDI large data sets - Detailed Proposal

From IHE Wiki
Revision as of 09:48, 12 September 2007 by Cdi (talk | contribs) (→‎3. Key Use Case)
Jump to navigation Jump to search

IHE Profile Proposal (Detailed)

1. Proposed Profile: Large data sets on Portable Media

  • Proposal Editor: Christoph Dickmann
  • Date: 2007-09-12
  • Version: N/A (Wiki keeps history)
  • Domain: Rad, incl. Mammography, Card, RO


Summary

The IHE PDI Profile defines how to write uncompressed DICOM data on a single CD. If a patient's study data exceeds the CD size, IHE PDI does not describe what to do. This is considered a shortcoming of the Profile in the field. For instance, Cardiology diagnostic exams often have a size of 800 MB, which just exceeds the 700 MB size of one CD media. In practice, compression is often used to make this patient data fit on one single CD in order to avoid media juggling and use less media (material & time).
DICOM defines media application profiles with compression. DICOM has not defined a mechanism to handle media spanning.
PDI should be extended by text how to write and use large data sets by using one or multiple media in a reliable manner.

2. The Problem

IHE Radiology has defined a reliable mechanism to create, (transport,) present, and import DICOM data on CD-ROM (cheap and widely used media) in the original, uncompressed format.
PDI does not explicitly define or recommend what to do in case the data to be burned by a Media Creator does not fit on a single media. However, the PDI Use Case 3 describes a scenario where voluminous data is to be exchanged by CD. Of course, this does not disallow a product implementing the Portable Media Creator to be able to burn CDs with additional DICOM media application profiles that allow compression.

IHE PDI was intended for general-purpose "simple" CD exchange to any unknown recipient with or without sophisticated workstations. Therefore, it was a design principle to use as few as possible DICOM media application profiles (i.e. exactly one: STD-GEN-CD).
PDI does not contain compression because

  • there was no general DICOM CD media profile that includes compressed images
  • modality-specific media profiles were considered inappropriate for a general/ simple CD exchange
  • DVD compression media profiles suffer from hardware incompatibilities.

Meanwhile, users have reacted to this fact and

  • requested PDI to explicitly cover a compression mechanism (which may reflect their local habits)
  • add extensions to otherwise PDI-using frameworks, which may result in wrong use of DICOM media (e.g. DVD compression on a PDI CD).

It seems helpful if IHE clarifies this situation.


3. Key Use Case

Use Case 3 - Operating Room Viewing (RAD TF-1, 15.3.1):
"Media data is used to enable diagnostic or therapeutic processes in environments without a reliable network connection. The volume of data can be very large and may contain image data, post-processing results and reports. In the operating room, the surgical staff receives the media and reads its contents using advanced viewing capabilities, which may include manipulating or processing images."
Even data of one single patient may not fit on 1 CD.
Media user perspective:

  • Preparation time increases if media content from more than one media is loaded onto the computer in order to have the images readily available during surgery.
  • Reading in DICOM objects from a newly inserted media is slower than accessing DICOM objects from internal storage or from an already accessed media.
  • Changing CDs in the operating theater also interrupts the procedure as this is done by a non-sterile person that may not be immediately at hand.


Media creator perspective:


Cardiologist practice:
After a cardiovascular diagnostic catheterization examination was completed, the Tech wants to give the patient her images on CD to be handed over to the referring physician.
Due to the image volume, the Portable Media Creator system needs to burn 2 CDs due to the volume of the acquired images. The Tech's preparation for the next patient is disturbed by needing to remove the completed first CD and to insert a second CD in order to burn all examination images.
For interventional studies, even more CDs may need to be produced.
Therefore, the Cardiologist practice will check if the Portable Media Creator function in the product can be switched off and instead, image compression can be switched on so that most patient studies will fit on one single CD.

4. Standards & Systems

There exist several DICOM media application profiles that allow storing compressed images, e.g. for CT, MR, XA, US images (DICOM part 11). However, none of them matches the STD-GEN-CD profile that is used in the current PDI specification. DICOM viewers that support JPEG-compressed images are not uncommon today.

DICOM allows data from one patient to span multiple media. However, there is no media-spanning information in the DICOMDIR, so that a receiver of one CD does not know if there exist additional CDs that complete the study data of a patient.

DICOM does not define a general-purpose CD profile that allows storage of compressed images. A similar DVD profile exists, however, DVDs still show a considerable number of read errors.


5. Discussion

IHE should tackle this issue of voluminous data on CD for improved real-world usability of PDI. There are several directions for investigation and action:

  • IHE should at least explain this situation in the Technical Framework, and suggest burning multiple CDs or key images only with IHE Portable Media Creators. IHE may recommend when to use modality-specific media application profiles that allow compression. IHE should also clearly state plans how to solve the issue in the future.
  • Ask DICOM to create an extension to the STD-GEN-CD profile that allows compression. This will first need DICOM to accept and finalize a Supplement workitem. When this is feasible and finished, add an option using this new DICOM media application profile to the
    • PDI Portable Media Creator to burn compressed DICOM images on CD,
    • reader and presentation actors.
  • Ask DICOM to create a disk spanning mechanism for media that adds information to each disk if it is part of a larger set of disks. This will first need DICOM to accept and finalize such a workitem. When this is feasible and finished, add an option using this new DICOM media spanning mechanism to the
    • PDI Portable Media Creator to burn compressed DICOM images on CD,
    • reader and presentation actors.




  • Move the Summary section to the end of Section 1
  • Expand details in the Use Case Section
  • Distribute material in the Discussion Section into the other bottom sections.


5. Technical Approach

<This section can be very short but include as much detail as you like. The Technical Committee will flesh it out when doing the effort estimation.>

<Outline how the standards could be used/refined to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>

<If a phased approach would make sense indicate some logical phases. This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>

Existing actors

<Indicate what existing actors could be used or might be affected by the profile.>

New actors

<List possible new actors>

Existing transactions

<Indicate how existing transactions might be used or might need to be extended.>

New transactions (standards used)

<Describe possible new transactions (indicating what standards would likely be used for each. Transaction diagrams are very helpful here. Feel free to go into as much detail as seems useful.>

Impact on existing integration profiles

<Indicate how existing profiles might need to be modified.>

New integration profiles needed

<Indicate what new profile(s) might need to be created.>

Breakdown of tasks that need to be accomplished

<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

7. Risks

<List technical or political risks that will need to be considered to successfully field the profile.>

8. Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

9. Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>


<Delete this Category Templates line since your specific Profile Proposal page is no longer a template.>