PDI large data sets - Detailed Proposal

From IHE Wiki
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:

  • At time of media writing, it often is not exactly known who will use the media in what way. Therefore, there is a tendency to write the complete study data to media instead of selecting a few key images that may rather serve a special target user group.
  • If a Tech burns the media, then she will often not select key images but just burn the whole study and report to the media.


Cardiologist practice and specialist referral:
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 general medicine physician.
Due to the large volume of the acquired images, 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 (3 CDs).
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.
During the next consultation, the referring physician who has cared for this patient over many years, wants to demonstrate the improvement to the patient who brings in the 2 CDs. As the physician has no imaging system, she reads in the first media on the office computer to show the patient the key images. Unfortunately, these are on the 2nd media, so she has to switch the CDs, which takes time.

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

DICOM allows data from one patient to be written on 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
  • on which CD the priors, a subset of images, measurements or the report can be found.


5. Technical Approach

The technical approach should tackle these two issues of large data sets exceeding one piece of CD:

  • compression: if DICOM objects can be compressed on a CD, this solves the problem of producing more than one CDs in many cases. Generally, it reduces the number of CDs to be burnt for large datasets.
  • media spanning: if the DICOMDIR contains information on all objects burnt to a number of media, applications and users may easier navigate and do less media flipping.
  • information, education: creators and users of media may benefit from finding key images and reports on media only, i.e. from avoiding information overload. IHE may promote selecting and burning key images for certain situations, e.g. for situations where CDs are produced for imformative rather than diagnostic or therapeutic follow-up.


<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

PDI: Portable Media Creator, Image Display, Portable Media Importer, Print Composer

New actors

none.

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