DICOM Profiles Whitepaper - Detailed Proposal: Difference between revisions

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

@@ Line 1: / Line 1: @@
 __NOTOC__
 ==1. Proposed Workitem: DICOM Profiles Whitepaper==
 * 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===
@@ Line 15: / 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.
-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==
-''<Summarize the integration problem. What doesn’t work, or what needs to work.>''
+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==
-''<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==
-''<List existing systems that are/could be involved in the problem/solution.>''
+DICOM Image SOP Classes (Especially the new ones, but also the poorly implemented ones)
-''<If known, list standards which might be relevant to the solution>''
+==5. Technical Approach==
+This would be a whitepaper outlining a process for managing and incorporating DICOM WG-developed profile material in IHE.
-==5. Technical Approach==
+===Breakdown of tasks that need to be accomplished===
-''<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.>''
+* 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
-''<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.>''
+* Document the consensus resolution in a whitepaper.
-===Existing actors===
+* Review the whitepaper with DICOM WG-6, WG-10, DSC
-''<Indicate what existing actors could be used or might be affected by the profile.>''
-===New actors===
+* Plan a pilot project to develop such a profile according to the agreed method.
-''<List possible new actors>''
-===Existing transactions===
-''<Indicate how existing transactions might be used or might need to be extended.>''
-===New transactions (standards used)===
+==6. Support & Resources==
-''<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===
+A number of Rad Tech Cmte members have experience working on DICOM Committees and thus know the processes on both sides.
-''<Indicate how existing profiles might need to be modified.>''
-===New integration profiles needed===
+DICOM WG-6 has briefly considered the idea but there is no formal commitment to it yet.  Need to discuss.
-''<Indicate what new profile(s) might need to be created.>''
-===Breakdown of tasks that need to be accomplished===
+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.
-''<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==
+Often the interest in such focussed profiles will be stronger in the modality-oriented DICOM working groups than in the broader IHE Radiology Committees.
-''<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.>''
+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==
-''<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==
@@ Line 80: / Line 98: @@
 Effort Evaluation (as a % of Tech Cmte Bandwidth):
-:* 35% for ...
+:* 15% - mostly documenting a proposed procedure
 Responses to Issues:
@@ Line 86: / Line 104: @@
 Candidate Editor:
-: TBA
+: Kevin O'Donnell