Enterprise Scanner Protocol Management - Proposal

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.

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.

• 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

• DICOM Sup121 - CT Protocol Storage (Final Text)
• DICOM Sup192 - Protocol Approval Storage (going to Letter Ballot)
• NEMA XR-29 Smart Dose
• NEMA XR-25 Dose Check

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

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
• Tim "Stick" Szczykutowicz, University of Wisconsin Madison ... creator of ProtocolShare.org has submitted a letter of support and agreed to participate in review.
• AAPM CT Protocols Committee ... publishers of Alliance for Quality CT - Protocols are drafting a letter of support and will participate in review.

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 equiped than the legacy DIMSE protocol.
• How should Defined Protocols and Performed Protocols be handled differently? Do they need different query transactions?

• 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