Difference between revisions of "DICOM Profiles Whitepaper - Detailed Proposal"

From IHE Wiki
Jump to navigation Jump to search
 
(5 intermediate revisions by the same user not shown)
Line 3: Line 3:
  
 
* Proposal Editor: Kevin O'Donnell (Toshiba)
 
* Proposal Editor: Kevin O'Donnell (Toshiba)
* Editor: ''<Name of candidate Lead Editor for the Profile, if known>''
+
* Editor: Kevin O'Donnell (Toshiba)
* Domain: Radiology, Cardiology
+
* Domain: Radiology, Cardiology, Eyecare?
  
 
===Summary===
 
===Summary===
Line 13: Line 13:
 
IHE should figure out the details of how we could collaborate with DICOM on "simple profiles" like these.  The idea has been floated in DICOM that they could develop these implementation guides for single SOP Classes, IHE could review them and they could be added to the list of profiles and tested at Connectathons.
 
IHE should figure out the details of how we could collaborate with DICOM on "simple profiles" like these.  The idea has been floated in DICOM that they could develop these implementation guides for single SOP Classes, IHE could review them and they could be added to the list of profiles and tested at Connectathons.
  
This would allow DICOM to apply the in-depth expertise that went into specifying the object in the first place to documenting how it was intended to be used.  
+
This would allow DICOM working groups to apply the in-depth expertise that went into specifying the object in the first place to documenting how it was intended to be used.  
  
IHE would continue to do profiles that combine multiple services, spanning multiple standards, etc.
+
This collaborative authoring with external resources is not being proposed for profiles that combine multiple services, span multiple standards, etc.
  
 
==2. The Problem==
 
==2. The Problem==
  
 +
There is a class of profiles which basically involve:
 +
:* re-iterating the DICOM specification
 +
:* explaining how a single DICOM SOP Class was intended to be used in a particular use case, sometimes for it's sole intended purpose.
  
 +
One could argue that the DICOM Working Group that wrote the SOP Class spec. in the first place:
 +
:* is better able to address those two points than the IHE Radiology Technical Committee
 +
:* has more focussed interest in the topic than the IHE Radiology Technical Committee
 +
:* has already pulled together the relevant representatives from different vendors
 +
 +
On the other hand, the IHE process is helpful in terms of
 +
:* providing the Connectathon testing process which vendors seem to find very helfpul
 +
:* bringing such profiles to the attention of PACS/Display vendors
 +
 +
IHE should evaluate if there is a way for these two groups to collaborate to get the best of both worlds.
  
  
 
==3. Key Use Case==
 
==3. Key Use Case==
  
''<Describe a short use case scenario from the user perspective.  The use case should demonstrate the integration/workflow problem.>''
+
Profiles that would fall into this category of "Image Content Profiles" include:
 +
:* CT/MR Perfusion Imaging
 +
:* MR Diffusion Imaging
 +
:* Multi-stack Spine Imaging
 +
:* Cardiac Imaging
 +
:* DICOM Encoded Image
  
''<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.>''
+
The existing NM Image and Mammo Image Profiles might also be considered more sophisticated examples of the same kind of profile.
  
 +
Note: we are not proposing re-writing existing profiles.
  
 
==4. Standards & Systems==
 
==4. Standards & Systems==
Line 35: Line 54:
 
==5. Technical Approach==
 
==5. Technical Approach==
  
This would be a whitepaper outlining a process for managing and incorporating DICOM-developed profiles in IHE.
+
This would be a whitepaper outlining a process for managing and incorporating DICOM WG-developed profile material in IHE.
  
 
===Breakdown of tasks that need to be accomplished===
 
===Breakdown of tasks that need to be accomplished===
  
* Discuss and resolving issues like:
+
* Discuss and resolve issues like:
 
:* do these profiles get added to the Radiology TF, the DICOM standard, or both
 
:* do these profiles get added to the Radiology TF, the DICOM standard, or both
 +
:** strong opinions have been expressed that they NOT be added to DICOM
 
:* who is responsible for maintaining them
 
:* who is responsible for maintaining them
:* do they use the IHE Profile Template
+
:* do they use the standard IHE Profile Template
 
:* who develops test plans & test tools for them
 
:* who develops test plans & test tools for them
 
:* how do we splice the annual IHE cycle with the per-supplement DICOM process
 
:* how do we splice the annual IHE cycle with the per-supplement DICOM process
 +
:* when and how often is the work reviewed in the Radiology Technical Committee
 
:* how do we approve/coordinate such work items between IHE and DICOM
 
:* how do we approve/coordinate such work items between IHE and DICOM
  
 
* Document the consensus resolution in a whitepaper.
 
* Document the consensus resolution in a whitepaper.
 +
 +
* Review the whitepaper with DICOM WG-6, WG-10, DSC
  
 
* Plan a pilot project to develop such a profile according to the agreed method.
 
* Plan a pilot project to develop such a profile according to the agreed method.
Line 53: Line 76:
  
 
==6. Support & Resources==
 
==6. Support & Resources==
 +
 +
A number of Rad Tech Cmte members have experience working on DICOM Committees and thus know the processes on both sides.
 +
 
DICOM WG-6 has briefly considered the idea but there is no formal commitment to it yet.  Need to discuss.
 
DICOM WG-6 has briefly considered the idea but there is no formal commitment to it yet.  Need to discuss.
  
DICOM WG-16 is the source of two of the work item proposals for profiles that would fit this mold, and was also the source of the previous such profiles.
+
DICOM WG-16 is the source of two of the work item proposals for profiles that would fit this mold, and was also the source of two previous such profiles.
  
 
Often the interest in such focussed profiles will be stronger in the modality-oriented DICOM working groups than in the broader IHE Radiology Committees.  
 
Often the interest in such focussed profiles will be stronger in the modality-oriented DICOM working groups than in the broader IHE Radiology Committees.  
  
 
==7. Risks==
 
==7. Risks==
''<List technical or political risks that will need to be considered to successfully field the profile.>''
+
This has the potential to increase the number of profiles released in IHE Radiology.  Some consideration should be given to the issue of [[IHE Pipeline Impedance Matching|IHE Domain Capacity]] raised recently.
 +
 
 +
DICOM might not choose to contribute to any profiles.
  
 
==8. Open Issues==
 
==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.>''
+
See items listed in the Breakdown of Tasks above.
  
 
==9. Tech Cmte Evaluation==
 
==9. Tech Cmte Evaluation==
Line 70: Line 98:
  
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):
:* 35% for ...
+
:* 15% - mostly documenting a proposed procedure
  
 
Responses to Issues:
 
Responses to Issues:
Line 76: Line 104:
  
 
Candidate Editor:
 
Candidate Editor:
: TBA
+
: Kevin O'Donnell

Latest revision as of 23:48, 21 October 2009

1. Proposed Workitem: DICOM Profiles Whitepaper

  • Proposal Editor: Kevin O'Donnell (Toshiba)
  • Editor: Kevin O'Donnell (Toshiba)
  • Domain: Radiology, Cardiology, Eyecare?

Summary

A couple of the existing and proposed Radiology Profiles boil down to properly creating and displaying objects from a single Storage SOP Class. i.e. do one piece of DICOM correctly.

DICOM recently produced a sophisticated guide for creating 3D X-Ray objects.

IHE should figure out the details of how we could collaborate with DICOM on "simple profiles" like these. The idea has been floated in DICOM that they could develop these implementation guides for single SOP Classes, IHE could review them and they could be added to the list of profiles and tested at Connectathons.

This would allow DICOM working groups to apply the in-depth expertise that went into specifying the object in the first place to documenting how it was intended to be used.

This collaborative authoring with external resources is not being proposed for profiles that combine multiple services, span multiple standards, etc.

2. The Problem

There is a class of profiles which basically involve:

  • re-iterating the DICOM specification
  • explaining how a single DICOM SOP Class was intended to be used in a particular use case, sometimes for it's sole intended purpose.

One could argue that the DICOM Working Group that wrote the SOP Class spec. in the first place:

  • is better able to address those two points than the IHE Radiology Technical Committee
  • has more focussed interest in the topic than the IHE Radiology Technical Committee
  • has already pulled together the relevant representatives from different vendors

On the other hand, the IHE process is helpful in terms of

  • providing the Connectathon testing process which vendors seem to find very helfpul
  • bringing such profiles to the attention of PACS/Display vendors

IHE should evaluate if there is a way for these two groups to collaborate to get the best of both worlds.


3. Key Use Case

Profiles that would fall into this category of "Image Content Profiles" include:

  • CT/MR Perfusion Imaging
  • MR Diffusion Imaging
  • Multi-stack Spine Imaging
  • Cardiac Imaging
  • DICOM Encoded Image

The existing NM Image and Mammo Image Profiles might also be considered more sophisticated examples of the same kind of profile.

Note: we are not proposing re-writing existing profiles.

4. Standards & Systems

DICOM Image SOP Classes (Especially the new ones, but also the poorly implemented ones)

5. Technical Approach

This would be a whitepaper outlining a process for managing and incorporating DICOM WG-developed profile material in IHE.

Breakdown of tasks that need to be accomplished

  • Discuss and resolve issues like:
  • do these profiles get added to the Radiology TF, the DICOM standard, or both
    • strong opinions have been expressed that they NOT be added to DICOM
  • who is responsible for maintaining them
  • do they use the standard IHE Profile Template
  • who develops test plans & test tools for them
  • how do we splice the annual IHE cycle with the per-supplement DICOM process
  • when and how often is the work reviewed in the Radiology Technical Committee
  • how do we approve/coordinate such work items between IHE and DICOM
  • Document the consensus resolution in a whitepaper.
  • Review the whitepaper with DICOM WG-6, WG-10, DSC
  • Plan a pilot project to develop such a profile according to the agreed method.


6. Support & Resources

A number of Rad Tech Cmte members have experience working on DICOM Committees and thus know the processes on both sides.

DICOM WG-6 has briefly considered the idea but there is no formal commitment to it yet. Need to discuss.

DICOM WG-16 is the source of two of the work item proposals for profiles that would fit this mold, and was also the source of two previous such profiles.

Often the interest in such focussed profiles will be stronger in the modality-oriented DICOM working groups than in the broader IHE Radiology Committees.

7. Risks

This has the potential to increase the number of profiles released in IHE Radiology. Some consideration should be given to the issue of IHE Domain Capacity raised recently.

DICOM might not choose to contribute to any profiles.

8. Open Issues

See items listed in the Breakdown of Tasks above.

9. Tech Cmte Evaluation

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

Effort Evaluation (as a % of Tech Cmte Bandwidth):

  • 15% - mostly documenting a proposed procedure

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Kevin O'Donnell