Enterprise Scanner Protocol Management - Proposal

From IHE Wiki
Jump to navigation Jump to search

1. Proposed Workitem: Enterprise Scanner Protocol Management

  • Proposal Editor: Krishna Juluru
  • Editor: <Name of candidate Lead Editor for the Profile, if known>
  • Domain: Radiology


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.

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.

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 is expected to explore 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 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.

4. Standards and Systems


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


  • DICOM Sup121 - CT Protocol Storage
  • NEMA XR-29 (Smart Dose), XR-25 (Dose Check)

5. Technical Approach

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

This would likely be a new profile with one or two transactions between the Acquisition Modality actor and a new Protocol Manager actor.

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

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

  • Acquisition Modality
  • Image Manager

New actors

  • Protocol Manager

Existing transactions

  • Reuse Storage Commitment as is?

New transactions (standards used)

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

  • New DICOM Query Transaction (Query protocols by RIS or Modality)
  • New DICOM object transfer transaction (push or pull TBA)

Impact on existing integration profiles

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.

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

<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 volume 1 to include:
    • Use cases
    • Swim lane Diagram
    • Transaction Diagram (protocol movement transaction)

At the face-to-face:

  • Decide whether modalities will be required to push to the Manager (in response to a trigger?) or will the Manager query/pull only
  • Decide if UI features will be mandated on the Manager (comparison screens, etc.) Note that this should be out-of-scope
  • Decide what features will be mandated on the Modality, if any other than supporting the transactions (overwrite/delete local protocols, etc.)
  • Decide what will be required from the DICOM Supplement.
  • Decide if this is a DICOMWeb or DIMSE transaction

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

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 Sup121 going to Final Text (which will require that it goes to letter ballot at the Sept WG6 meeting and passes ballot so it can be Final Texted at the Nov or Jan WG6 meetings)
  • Depends on vendors migrating to an open standard from their current proprietary formats

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

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

  • 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA, Chris Lindop