Difference between revisions of "Enterprise Scanner Protocol Management - Proposal"

From IHE Wiki
Jump to navigation Jump to search
 
(38 intermediate revisions by 4 users not shown)
Line 3: Line 3:
  
 
* Proposal Editor: Krishna Juluru
 
* Proposal Editor: Krishna Juluru
* Editor: Chris Lindop
+
* Proposal Contributors: Kevin O'Donnell, Chris Lindop, Chris Carr
 +
* Profile Editor: Kevin O'Donnell
 +
* Profile Contributors: Krishna Juluru (MSKCC), Tim Szczykutowicz (UWisc), Dianna Cody (MSKCC)
 
* Domain: Radiology
 
* Domain: Radiology
  
Line 9: Line 11:
 
There is currently no way to manage protocols centrally across devices. This creates inefficiency, inconsistency and chaos in the management of protocols at radiology sites.
 
There is currently no way to manage protocols centrally across devices. This creates inefficiency, inconsistency and chaos in the management of protocols at radiology sites.
  
DICOM is about to ballot Supplement 121 which defines SOP classes to distribute planned CT protocols and to record performed CT protocols. IHE Radiology has the Assisted Acquisition Protocol Setting Option in Scheduled Workflow, which enables the operator to use procedure codes provided in the modality worklist to select the acquisition protocol.
+
DICOM Supplement 121 (Final Text) defines SOP classes to distribute planned CT protocols and to record performed CT protocols. IHE Radiology has the Assisted Acquisition Protocol Setting Option in Scheduled Workflow, which enables the operator to use procedure codes provided in the modality worklist to select the acquisition protocol.
  
Defining the basic operations of a Protocol Manager actor and a few transactions between that actor and the Acquisition Modality actor and Image Manager/Archive would enable communication of protocol information and centralized management of protocols across devices.
+
A Protocol Manager actor using a few transactions would enable centralized management of protocols across Acquisition Modality devices.
  
 
Several vendors have implemented proprietary protocol management functions. Modality, PACS and EHR vendors would all benefit from having a standardized method for performing this function.
 
Several vendors have implemented proprietary protocol management functions. Modality, PACS and EHR vendors would all benefit from having a standardized method for performing this function.
Line 33: Line 35:
  
 
In the long run it would be nice to have this capability available for all modalities, but CT would be a good place to start. This alone would address a big problem.
 
In the long run it would be nice to have this capability available for all modalities, but CT would be a good place to start. This alone would address a big problem.
 +
 +
IHE REM lets sites observe and detect dose issues.  Taking corrective action often involves protocol changes which would be far more tractable with centralized protocol management.
  
 
==3. Key Use Case==
 
==3. Key Use Case==
  
Rather than an ad hoc manual process that involves physically visiting each device in an institution or group of institutions and on each device reviewing dozens or hundreds of protocols, using tools and doing much of this remotely would have a tremendous benefit.  The following use case is an example.  The tech cmte is expected to explore variants.
+
Rather than an ad hoc manual process that involves physically visiting each device in an institution or group of institutions and on each device reviewing dozens or hundreds of protocols, using tools and doing much of this remotely would have a tremendous benefit.  The following use case is an example.  The tech cmte may consider variants.
  
 
Protocol Review
 
Protocol Review
Line 49: Line 53:
 
::* E.g. when a "correct" version of the protocol is not available on another scanner to be simply copied.
 
::* E.g. when a "correct" version of the protocol is not available on another scanner to be simply copied.
 
::* Edits might include aligning names or descriptions, or setting dose notification popup thresholds for a group of protocols.
 
::* Edits might include aligning names or descriptions, or setting dose notification popup thresholds for a group of protocols.
 +
::* Mike notes that without this, he faces 23 different names for "CT Brain without Contrast" across 9 scanners spread over 7 facilities
 
:* Some edits will require the user interface and business logic of the scanner itself to perform correctly.  
 
:* Some edits will require the user interface and business logic of the scanner itself to perform correctly.  
 
::* The workstation may help the tech generate and print a list of such changes to visit the appropriate device then use the workstation to replicate the changes on additional scanners of the same model if needed.
 
::* The workstation may help the tech generate and print a list of such changes to visit the appropriate device then use the workstation to replicate the changes on additional scanners of the same model if needed.
 +
 +
 +
It would interact well with some of the dose management features of MITA XR-29.
  
 
==4. Standards and Systems==
 
==4. Standards and Systems==
Line 62: Line 70:
  
 
Standards
 
Standards
* DICOM Sup121 - CT Protocol Storage
+
* [ftp://medical.nema.org/medical/dicom/final/sup121_ft.pdf| DICOM Sup121 - CT Protocol Storage] (Final Text)
* NEMA XR-29 (Smart Dose), XR-25 (Dose Check)
+
* DICOM Sup192 - Protocol Approval Storage (going to Letter Ballot)
 +
* [https://www.nema.org/Standards/Pages/Standard-Attributes-on-CT-Equipment-Related-to-Dose-Optimization-and-Management.aspx| NEMA XR-29 Smart Dose]
 +
* [https://www.nema.org/Standards/Pages/Computed-Tomography-Dose-Check.aspx| NEMA XR-25 Dose Check]
  
 
==5. Technical Approach==
 
==5. Technical Approach==
This would be a new profile with potentially 7 new transactions. 
+
===New integration profiles needed===
 +
* Acquisition Protocol Management (APM?)
  
[[File:DIAGRAM ESPM rev 1.jpeg| Figure 1. ESPM Transaction Diagram ‎]]
+
===Impact on existing integration profiles===
 +
* Assisted Protocol Setting Option in Scheduled Workflow might be modified/replaced.
  
 
+
===New actors===
It would interact well with some of the dose management features of MITA XR-29.
+
* Protocol Manager
 
 
In terms of phases, it would need to limit to CT Protocols initially since that's the only one DICOM has standardized so far.  (DICOM felt that CT protocols was a good choice to trial this technology and if it worked out well, expand to other modalities). There is work starting in DICOM for Angiography protocols.  This profile would have to follow that path too.
 
  
 
===Existing actors===
 
===Existing actors===
 
* Acquisition Modality
 
* Acquisition Modality
* Image Manager
+
* Image Manager?
* DSS/Order Filler
+
* DSS/Order Filler?
  
===New actors===
+
===New transactions (standards used)===
* Protocol Manager
+
* Query Protocol - e.g. Protocol Manager queries modalities for (all?) protocols
* Protocol Creator
+
* Retrieve Protocol - e.g. Protocol Manager pulls all relevant protocols
* Protocol Repository
+
* Store Protocol - e.g. Protocol Manager pushes protocols to modalities
  
 +
* Query Approval - e.g. Modality queries Protocol Manager for approvals of given protocol
 +
* Retrieve Approval - e.g. Modality pulls relevant approvals
 +
* Store Approval - e.g. Protocol Manager pushes approvals to modalities
  
===Existing transactions===
+
Transactions would handle instances.  Although DICOM currently only has CT Protocols, the transactions would be agnostic about the payload (CT, MR, XA, etc).  As DICOM defines other modality protocol objects, they could be easily added to this profile, perhaps as named options.
* Reuse Storage Commitment as is?
 
  
===New transactions (standards used)===
+
Sup121 is structured to specifically address the need for vendor-specific "private" tags to support the many engineering differences between different scanner models.   
''<Describe possible new transactions (indicating what standards would likely be used for each.  Transaction diagrams are very helpful hereFeel free to go into as much detail as seems useful.>''
 
* New DICOM Query Transaction (Query protocols by RIS or Modality)
 
* New DICOM object transfer transaction (push or pull TBA)
 
  
===Impact on existing integration profiles===
+
Note the protocols being managed and approved are the "Defined" protocols that are not patient specific (i.e. the stored protocols on the CT console). Sup121 also defines an object for "Performed" protocols which contain the exact values used for a particular patient scan and can be stored in the study folder with the images and other study objects.
  
Assisted Protocol Setting Option in Scheduled Workflow could link to the stored protocols.  Not clear that there would be a direct impact on the SWF.b profile option.
+
===Existing transactions===
 
+
* Storage Commitment - reuse as is, if needed.
===New integration profiles needed===
 
Enterprise Scanner Protocol Management would be a new integration profile. No other new profiles are required.
 
  
 
===Breakdown of tasks that need to be accomplished===
 
===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.>''
 
''<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.>''
  
Prior to the face-to-face meeting in Dec,  
+
* Draft specific use case details
* Draft volume 1 & 2 to include:
+
** Central protocol review (core)
**Use cases
+
** Protocol Library (optional)
**Swim lane Diagram
+
* Clone Query Image and revise for protocols based on query model in Sup121
**Transaction Diagram (protocol movement transaction)
+
* Clone Query Image and revise for approvals based on query model in Sup192
 
+
* Clone Store/Retrieve Images twice, once for protocols, once for approvals
Resolve open issues prior to the face-to-face:
+
* Define baseline features of Protocol Manager
 +
** Filter protocol sets
 +
** Display and compare protocols
 +
** Approve protocols
 +
** Push sets to target modalities
 +
** Edit Dose Check Thresholds?
 +
* Define baseline features of Modality
 +
** Check for approvals on given protocol
 +
** Consider overwrite/disapproval behaviors
 +
** Notify tech of execution of unapproved protocol
  
 
==6. Support & Resources==
 
==6. Support & Resources==
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''
 
  
''<Identify anyone who as indicated an interest in implementing/prototyping the Profile if it is published this cycle.>''
+
* RSNA members have expressed strong interest
 +
** The proposal is submitted by a member of the Radiology Informatics Cmte
 +
* AAPM CT Protocols Committee ... publishers of [http://www.aapm.org/pubs/CTProtocols/ Alliance for Quality CT - Protocols] are drafting a letter of support and will participate in review.
 +
* Tim "Stick" Szczykutowicz, University of Wisconsin Madison ... creator of [http://www.protocolshare.org/| ProtocolShare.org] has submitted a letter of support and agreed to participate in development.
 +
* Thomas Jumpertz, working with Dr. Mildenberger in Mainz, has also written in support and connected the profile to related work they would like to do in Europe.
  
 
It would be good for IHE to get involved to promote a cross-vendor, standards-based solution.  Currently some vendors provide proprietary solutions that only work for one vendors scanners (and sometimes not for all models).  Many sites have scanners from more than one vendor.
 
It would be good for IHE to get involved to promote a cross-vendor, standards-based solution.  Currently some vendors provide proprietary solutions that only work for one vendors scanners (and sometimes not for all models).  Many sites have scanners from more than one vendor.
Line 121: Line 140:
 
==7. Risks==
 
==7. Risks==
  
* Depends on Sup121 going to Final Text
 
:* Current Status: missed letter ballot at the Sept WG6 meeting by a few hours.  Will go to letter ballot after the Nov 8-12 WG6 meeting and Final Text at the Jan 18-22 WG6 meeting.
 
:* Seems like the timeline still align with the public comment publication schedule. Is the supplement in decent shape that it is expected to be final text as planned?
 
 
* Depends on vendors migrating to an open standard from their current proprietary formats
 
* Depends on vendors migrating to an open standard from their current proprietary formats
* Is there a candidate profile editor?
+
* Be careful to avoid too much specification of GUI.  Stick to communication and broad behavior.
  
 
==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.>''
 
''<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.>''
 +
 +
* What UI capabilities, if any, will be required (comparison screens, etc.) Note that this should be ''out-of-scope''
 +
* Are the transactions REST (DICOMWeb/FHIR) or DIMSE or both?  Note that in order to support the change management aspect, RESTful services may be better equipped than the legacy DIMSE protocol.
 +
* Should Performed Protocols be included? Should creation of them by scanners be required, optional or not discussed?  Should protocol managers be required to support collecting and reviewing them?
 +
:* Existing query/retrieve transactions would largely work for Performed Protocols since they are patient objects.
 +
* Once protocols are approved by radiologists, etc. at the management workstation, should those be pushed to the modalities or query/on-demand?  And what behaviors should be required/recommended on the modality for "unapproved" protocols?
 +
:* Important to involve users and vendors in these discussions.
 +
  
 
* Will modalities push to the Manager (in response to a trigger?) or will the manager query retrieve?
 
* Will modalities push to the Manager (in response to a trigger?) or will the manager query retrieve?
:* *[Balaji Raman-GECT] Protocol Manager should also query modality and retrieve protocols. The use case for this scenario is as follows: if there are new protocols created from already pushed protocols, we would like to know who modified it and check what parameters got changed.
+
:* [Balaji Raman-GECT] Protocol Manager should also query modality and retrieve protocols. The use case for this scenario is as follows: if there are new protocols created from already pushed protocols, we would like to know who modified it and check what parameters got changed.
* What UI capabilities, if any, will be required (comparison screens, etc.) Note that this should be ''out-of-scope''
+
:* Alternatively, with a triggered-push, the modalities don't need to implement a Query SCP.
* What features will be mandated on the Modality, if any other than supporting the transactions? (overwrite/delete local protocols, etc.)
+
* Can the Protocol Manager create new protocols and if so where would those be stored?
* What will be required from the DICOM Supplement.
+
:* No. DICOM Sup121 presumed that it would be difficult for various vendor modalities to externalize the logic for composing new protocols (e.g. interactions between related parameters).
* Are the transactions REST (DICOMWeb/FHIR) or DIMSE or both?  Note that in order to support the change management aspect, RESTful services may be better equiped than the legacy DIMSE protocol.
+
:* A product could choose to implement one or more Acquisition Modality actors that are really console SW without a gantry and group them with a Protocol Manager actor but that's beyond this profile.  
* Will the modalities have protocols pushed back from the manager or will they query/retrieve protocols from a repository?
 
:* Can the Protocol Manager create new protocols and if so where would those be stored?
 
::* DICOM Sup121 presumed that it would be difficult for various vendor modalities to externalize the logic for composing new protocols (e.g. interactions between related parameters).
 
::* A product could choose to implement one or more Acquisition Modality actors that are really console SW without a gantry and group them with a Protocol Manager actor.  
 
* How should Defined Protocols and Performed Protocols be handled differently? Do they need different transactions? Different actors?
 
 
* How should version control of protocols be handled?
 
* How should version control of protocols be handled?
 
:* DICOM does not allow such instances to be modified.  New instances must be created.
 
:* DICOM does not allow such instances to be modified.  New instances must be created.
Line 146: Line 165:
  
 
* [Siemens] DICOM WGs 2 and 28 are looking into taking this approach to angiography as well. The supplement should be general enough to deal with additional protocol SOP classes. Also a use case in order to monitor protocol changes for legal reasons should be listed.
 
* [Siemens] DICOM WGs 2 and 28 are looking into taking this approach to angiography as well. The supplement should be general enough to deal with additional protocol SOP classes. Also a use case in order to monitor protocol changes for legal reasons should be listed.
* [Agfa] Is there any modification / enhancement anticipated to the Assisted Acquisition Protocol Setting Option to facilitate better integration with this profile?
+
* [Agfa] Evaluate modification / enhancement to the Assisted Acquisition Protocol Setting Option to facilitate better integration with this profile
 +
 
 +
Toshiba Patent # 8,386,273 is issued, but it addresses repeat patient positioning, rather than protocoling, per se.
  
 
==9. Tech Cmte Evaluation==
 
==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):
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):
:* 35%
+
:* 30% (+-5%)
 +
::* The Planning Committee should use 30% as the estimate.  The +- is part of trying to improve the estimation process.
  
 
Responses to Issues:
 
Responses to Issues:
Line 159: Line 179:
  
 
Candidate Editor:
 
Candidate Editor:
: Chris Lindop
+
: Kevin O'Donnell

Latest revision as of 10:01, 29 September 2016

1. Proposed Workitem: Enterprise Scanner Protocol Management

  • Proposal Editor: Krishna Juluru
  • Proposal Contributors: Kevin O'Donnell, Chris Lindop, Chris Carr
  • Profile Editor: Kevin O'Donnell
  • Profile Contributors: Krishna Juluru (MSKCC), Tim Szczykutowicz (UWisc), Dianna Cody (MSKCC)
  • Domain: Radiology

Summary

There is currently no way to manage protocols centrally across devices. This creates inefficiency, inconsistency and chaos in the management of protocols at radiology sites.

DICOM Supplement 121 (Final Text) defines SOP classes to distribute planned CT protocols and to record performed CT protocols. IHE Radiology has the Assisted Acquisition Protocol Setting Option in Scheduled Workflow, which enables the operator to use procedure codes provided in the modality worklist to select the acquisition protocol.

A Protocol Manager actor using a few transactions would enable centralized management of protocols across Acquisition Modality devices.

Several vendors have implemented proprietary protocol management functions. Modality, PACS and EHR vendors would all benefit from having a standardized method for performing this function.

The standards are nearing maturity for implementation and an IHE profile would provide an effective implementation guide that acts as a extension of other widely implemented IHE profiles.

2. The Problem

Although imaging protocols in different scanners may have the same name and are intended to achieve the same diagnostic outcome, the contents of the protocols often differ in details such as:

  • procedure step name (series name)
  • procedure step sequence
  • procedure step parameters

This has consequences in both clinical and research settings. Inconsistent series names can lead to failures of hanging protocols and failures of image processing pipelines in research. Wrong procedure step sequence can lead to scan delays and incorrect timing of post-contrast phases. Variability in scan parameters can lead to difficulties in following lesions over time, and variability in image quantification, not to mention unnecessary radiation.

There is a need to standardize imaging protocols within an institution, and between institutions. Currently, at most institutions, this standardization is performed manually by a lead technologist who visits every scanner and checks the uniformity the protocols.

Value Statement: Manual management of imaging protocols involves a visit to every scanner in an institution and is a time-consuming and error prone process. The problem is exacerbated when scanner software is upgraded and existing protocols are deleted. The institution’s ability to implement desirable changes to protocols is also limited due to this manual process.

A better solution would be a system and process that could manage all scanner protocols within an institution from a central access point. This would enable standardization across scanners, quick updates of protocols, and monitoring of protocols for quality assurance purposes.

In the long run it would be nice to have this capability available for all modalities, but CT would be a good place to start. This alone would address a big problem.

IHE REM lets sites observe and detect dose issues. Taking corrective action often involves protocol changes which would be far more tractable with centralized protocol management.

3. Key Use Case

Rather than an ad hoc manual process that involves physically visiting each device in an institution or group of institutions and on each device reviewing dozens or hundreds of protocols, using tools and doing much of this remotely would have a tremendous benefit. The following use case is an example. The tech cmte may consider variants.

Protocol Review

  • Lead tech or radiologist visits a protocol management workstation
  • The workstation pulls the full set of protocols from all the scanners in the institution or group of institutions
  • Features on the workstation let the tech
  • organize the protocols by device model, clinical purpose, patient type, etc.
  • see what protocols have been added or changed recently or since the last review
  • compare parameter values across selected protocols, e.g. to find undesired differences, or confirm necessary differences are in place
  • The workstation allows the tech to push the appropriate protocol sets out to specific devices or groups of devices
  • The tech might be allowed to make certain simple edits to protocols
  • E.g. when a "correct" version of the protocol is not available on another scanner to be simply copied.
  • Edits might include aligning names or descriptions, or setting dose notification popup thresholds for a group of protocols.
  • Mike notes that without this, he faces 23 different names for "CT Brain without Contrast" across 9 scanners spread over 7 facilities
  • Some edits will require the user interface and business logic of the scanner itself to perform correctly.
  • The workstation may help the tech generate and print a list of such changes to visit the appropriate device then use the workstation to replicate the changes on additional scanners of the same model if needed.


It would interact well with some of the dose management features of MITA XR-29.

4. Standards and Systems

Systems

  • Modalities
  • Protocol Management System
  • Radiology Information Systems
  • Dose Management Systems
  • PACS

Standards

5. Technical Approach

New integration profiles needed

  • Acquisition Protocol Management (APM?)

Impact on existing integration profiles

  • Assisted Protocol Setting Option in Scheduled Workflow might be modified/replaced.

New actors

  • Protocol Manager

Existing actors

  • Acquisition Modality
  • Image Manager?
  • DSS/Order Filler?

New transactions (standards used)

  • Query Protocol - e.g. Protocol Manager queries modalities for (all?) protocols
  • Retrieve Protocol - e.g. Protocol Manager pulls all relevant protocols
  • Store Protocol - e.g. Protocol Manager pushes protocols to modalities
  • Query Approval - e.g. Modality queries Protocol Manager for approvals of given protocol
  • Retrieve Approval - e.g. Modality pulls relevant approvals
  • Store Approval - e.g. Protocol Manager pushes approvals to modalities

Transactions would handle instances. Although DICOM currently only has CT Protocols, the transactions would be agnostic about the payload (CT, MR, XA, etc). As DICOM defines other modality protocol objects, they could be easily added to this profile, perhaps as named options.

Sup121 is structured to specifically address the need for vendor-specific "private" tags to support the many engineering differences between different scanner models.

Note the protocols being managed and approved are the "Defined" protocols that are not patient specific (i.e. the stored protocols on the CT console). Sup121 also defines an object for "Performed" protocols which contain the exact values used for a particular patient scan and can be stored in the study folder with the images and other study objects.

Existing transactions

  • Storage Commitment - reuse as is, if needed.

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

  • Draft specific use case details
    • Central protocol review (core)
    • Protocol Library (optional)
  • Clone Query Image and revise for protocols based on query model in Sup121
  • Clone Query Image and revise for approvals based on query model in Sup192
  • Clone Store/Retrieve Images twice, once for protocols, once for approvals
  • Define baseline features of Protocol Manager
    • Filter protocol sets
    • Display and compare protocols
    • Approve protocols
    • Push sets to target modalities
    • Edit Dose Check Thresholds?
  • Define baseline features of Modality
    • Check for approvals on given protocol
    • Consider overwrite/disapproval behaviors
    • Notify tech of execution of unapproved protocol

6. Support & Resources

  • RSNA members have expressed strong interest
    • The proposal is submitted by a member of the Radiology Informatics Cmte
  • AAPM CT Protocols Committee ... publishers of Alliance for Quality CT - Protocols are drafting a letter of support and will participate in review.
  • Tim "Stick" Szczykutowicz, University of Wisconsin Madison ... creator of ProtocolShare.org has submitted a letter of support and agreed to participate in development.
  • Thomas Jumpertz, working with Dr. Mildenberger in Mainz, has also written in support and connected the profile to related work they would like to do in Europe.

It would be good for IHE to get involved to promote a cross-vendor, standards-based solution. Currently some vendors provide proprietary solutions that only work for one vendors scanners (and sometimes not for all models). Many sites have scanners from more than one vendor.

7. Risks

  • Depends on vendors migrating to an open standard from their current proprietary formats
  • Be careful to avoid too much specification of GUI. Stick to communication and broad behavior.

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

  • What UI capabilities, if any, will be required (comparison screens, etc.) Note that this should be out-of-scope
  • Are the transactions REST (DICOMWeb/FHIR) or DIMSE or both? Note that in order to support the change management aspect, RESTful services may be better equipped than the legacy DIMSE protocol.
  • Should Performed Protocols be included? Should creation of them by scanners be required, optional or not discussed? Should protocol managers be required to support collecting and reviewing them?
  • Existing query/retrieve transactions would largely work for Performed Protocols since they are patient objects.
  • Once protocols are approved by radiologists, etc. at the management workstation, should those be pushed to the modalities or query/on-demand? And what behaviors should be required/recommended on the modality for "unapproved" protocols?
  • Important to involve users and vendors in these discussions.


  • Will modalities push to the Manager (in response to a trigger?) or will the manager query retrieve?
  • [Balaji Raman-GECT] Protocol Manager should also query modality and retrieve protocols. The use case for this scenario is as follows: if there are new protocols created from already pushed protocols, we would like to know who modified it and check what parameters got changed.
  • Alternatively, with a triggered-push, the modalities don't need to implement a Query SCP.
  • Can the Protocol Manager create new protocols and if so where would those be stored?
  • No. DICOM Sup121 presumed that it would be difficult for various vendor modalities to externalize the logic for composing new protocols (e.g. interactions between related parameters).
  • A product could choose to implement one or more Acquisition Modality actors that are really console SW without a gantry and group them with a Protocol Manager actor but that's beyond this profile.
  • How should version control of protocols be handled?
  • DICOM does not allow such instances to be modified. New instances must be created.
  • Attributes exist to point to "prior" instances from new instances. Profiling of certain Label/Name attributes might be helpful.
  • [Siemens] DICOM WGs 2 and 28 are looking into taking this approach to angiography as well. The supplement should be general enough to deal with additional protocol SOP classes. Also a use case in order to monitor protocol changes for legal reasons should be listed.
  • [Agfa] Evaluate modification / enhancement to the Assisted Acquisition Protocol Setting Option to facilitate better integration with this profile

Toshiba Patent # 8,386,273 is issued, but it addresses repeat patient positioning, rather than protocoling, per se.

9. Tech Cmte Evaluation

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

  • 30% (+-5%)
  • The Planning Committee should use 30% as the estimate. The +- is part of trying to improve the estimation process.

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Kevin O'Donnell