Enhanced DICOM Objects - Brief Proposal

From IHE Wiki
Revision as of 16:51, 25 August 2008 by Kevino (talk | contribs) (New page: ==1. Proposed Workitem: Enhanced DICOM Image Profile== * Proposal Editor: ''<Name of author/editor/contact for the proposal>'' * Editor: ''<Name of candidate Lead Editor for the Profile, ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

1. Proposed Workitem: Enhanced DICOM Image Profile

  • Proposal Editor: <Name of author/editor/contact for the proposal>
  • Editor: <Name of candidate Lead Editor for the Profile, if known>
  • Date:
  • Domain: Radiology

2. The Problem

DICOM has created new enhanced image object standards for CT and MR (and XR, PET and Ultrasound). Products have now entered the market that are capable of creating and processing these new objects.

Because of the intrinsic complexity of these new enhanced objects, and because some studies can reasonably be encoded in several different ways, it's almost inevitable that without further guidance vendors will create various, or even incompatible, encodings for the image objects acquired for the same clinical use cases.

Because of the new features and encoding, and because studies can reasonably be displayed in a variety of ways, some baseline implementation guidance for display behavior could be useful.

There have also been questions related to dealing with mixed environments where there is Enhanced data which needs to be made available to systems which only support the old objects.

An IHE profile that specifies the preferred consensus encoding and required baseline display behavior for the image objects for a selection of most common clinical use cases has the potential to circumvent such issues.

Profiles for a few clinical use cases have already be defined by WG16 and the committee for the advancement of DICOM, and have been demonstrated at the SCAR and RSNA conference by a number of vendors. DICOM WG16 has requested that these profiles be elaborated and promoted to IHE profiles.


3. Key Use Case

<Describe a short use case scenario from the user perspective. The use case should demonstrate the integration/workflow problem.>

<Feel free to add a second use case scenario demonstrating how it “should” work. Try to indicate the people/systems, the tasks they are doing, the information they need, and hopefully where the information should come from.>


4. Standards & Systems

<List existing systems that are/could be involved in the problem/solution.>

<If known, list standards which might be relevant to the solution>


5. Discussion

<Include additional discussion or consider a few details which might be useful for the detailed proposal>

<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>
<What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>
<What are some of the risks or open issues to be addressed?>


<This is the brief proposal. Try to keep it to 1 or at most 2 pages>